top - download
⟦6315eb665⟧ Wang Wps File
Length: 91860 (0x166d4)
Types: Wang Wps File
Notes: PC/PDS/001 - ISSUE 2
Names: »6212A «
Derivation
└─⟦05b6108d7⟧ Bits:30006238 8" Wang WCS floppy, CR 0624A
└─ ⟦this⟧ »6212A «
WangText
)…08…)…0e…)
(…86…1
…02…
…02… …02…
…02…PC/PDS/001
…02…851001…02……02…
PROTOCOL CONVERTER
PACKAGE DESIGN SPECIFICATION…02…ISSUE
1.2…02… PC
4.2 P̲A̲C̲K̲A̲G̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲S̲
In the following subsections software packages are
specified.
Software units are described using a Program Design
Language (PDL).
Programs specified in this PDL, also called pseudo
code programs, are very similar to programs written
in a high order machine independent language as for
instance PASCAL, the difference being that PDL allows
use of informal plain English statements as long as
the structure of the program is kept formal. Data are
described by PASCAL-like structured types.
4.2.1 C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲ ̲(̲C̲I̲)̲
4.2.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
CI performs the following tasks:
a) Read a command from the VDU and check for
…08…break/attention…08…. Echo the line if requested.
b) Check to see if the command keyword(s) matches
the legal keywords. If not, classify the command
as …08…unknown…08…. Check whether the keyword is legal
in the current system mode. If not, classify the
command as …08…unacceptable…08….
c) Read the parameters relevant for the command indicated
by the keyword. If an illegal parameter has been
entered or is missing, the command is classified
as …08…parameter error…08…. In case of a LOGON command,
prompt for the line with userid and DINDAC password
and switch off the VDU echo.
d) Perform the function requested including …08…break…08…,
syntax errors or a legal command. …08…Break…08… provokes
a prompt for a new command on the VDU and resets
the record used for keeping track of the previous
command, if any. Errors in the command syntax will
be flagged using one of the error messages:
…08…UNKNOWN COMMAND…08…
…08…UNACCEPTABLE COMMAND…08…
…08…PARAMETER ERROR…08…
Such error messages are followed by a mode prompt
for a new command. Commands accepted by CI are
encoded into a suitable format and sent to packages
responsible for their execution as AMOS …08…messages…08….
Message formats are described in section 4.2.1.3.1.
An overview of command keywords, system modes and
packages receiving the commands is given in Table
4.2.1.1-1.
In case of a LOGON command, a special ENABLE STATUS
RESPONSE command is issued to TRC following the
LOGON command. This command allows TRC to notify
the operator (via CI) if a link failure occurs.
A MAINTENANCE command will cause CI to change the
global system mode from LOCAL to MAINTENANCE mode.
During initialization, CI sets the system mode
to LOCAL and generates a result line as described
below using INIT as command keyword. Changing modes
as a result of commands LOGON, LOGOFF, and TEST
is the responsibility of TRC.
e) Receive answers to AMOS messages previously sent.
Upon completion of the commands LOGON, LOGOFF,
SHOW STATISTICS, RESET STATISTICS, TEST, and VERIFY,
the following line is presented to the operator:
…0c…$$…0c… (command keyword) EXECUTED, RESULT = (hex number).
The hexadecimal number consists of 4 digits of
which the leftmost is used for identification of
the package generating the result. A further error
description is contained in the two rightmost digits.
Packages generate result codes with the following
base numbers: …06…1 …02… …02… …02… …02… …02… …02…
CI: #
9000
TRC: #
A000
CPA: #
B000
CSPA: #
C000
MAC: #
D000
CSLP: #
E000
CLP: #
F000
When the result line has been written, a prompt
for a new command is output to the VDU. The prompt
contains a letter indicating the current system
mode.
Furthermore, a successfully completed SHOW STATISTICS
command will cause the ordinary line printed on
the VDU to be followed by:
(end system name) : FRAMES TRANSMITTED :
(count)
FRAMES RETRANSMITTED :
(count)
FRAMES RECEIVED ERROR FREE:
(count)
FRAMES RECEIVED WITH ERROR:
(count)
where (end system name) is 'CAMPS', 'SCARS' or
'CCIS'.
(count) is a decimal integer.
In addition to the ordinary keywords displayed
as a part of the result line, the following text
may occur in the result line:
'UNEXPECTED ANSWER'
'CLOSE DOWN'
…08…UNEXPECTED ANSWER…08… is used for notifying the operator
of CI…08…s reception of an answer to a command which
is no longer filed for execution in CI.
'CLOSE DOWN' is used for indicating an abnormal
condition in PC such as a link error. However only
result lines indicating errors, i.e.
'CLOSE DOWN' with a result which is not ok, are
displayed.
The command syntax is described in Reference 17, p64.
A LOGON command line is followed by a prompt for the
CCIS userid and password:
$*$LOGID$PASSWORD/DNM=$*$LOGid$password/DNM
---------------------
The operator enters the characters (underlined) immediately
following the prompt. The strings 'id' and 'password'
are from one to twelwe characters each. Only ASCII
characters 32 through 126 may be used.
The characters underlined are not displayed.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
^COMMAND ^LEGAL ^COMMAND SENT ^
^KEYWORD ^MODES ^TO PACKAGE ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
…02…^ ^ ^ ^
^MAINTENANCE ^LOCAL ^CI ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^ ^ ^
^LOGON ^LOCAL ^TRC ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^ ^ ^
^LOGOFF ^OPERATIONAL ^TRC ^
^ ^TEST ^ ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^ ^ ^
^SHOW ^OPERATIONAL, ^CLP, ^
^STATISTICS ^TEST ^CSLP ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^ ^ ^
^RESET ^OPERATIONAL, ^CLP, ^
^STATISTICS ^TEST ^CSLP ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^ ^ ^
^TEST ^OPERATIONAL ^TRC ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
^ ^ ^ ^
^VERIFY ^TEST ^TRC ^
^ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^
TABLE 4.2.1.1-1 CI COMMAND KEYWORDS
4.2.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The CI functions listed in section 4.2.1.1 are
implemented as four sets of SW entities:
- CI Mainprogram
- Read Command procedure
- Perform Function procedure
- Receive Answer procedure
The CI mainprogram basically consists of two functions
executing in an endless loop:
- Read Command
- Perform Function
Answers to commands sent during a previous call of
Perform Function will be serviced by the Receive Answer
procedure. These answers may be received asynchronously
whenever the Read Command procedure has been entered.
When started CI will request AMOS to lookup the LTU
driver processes SCADRV and CISDRV. As soon as both
these processes are reported alive CI will issue a
bootload command to each of them. Upon succesful completion
of the bootload command the line: INIT EXECUTED, RESULT
= 0000 is presented to the operator. If the bootload
operation fails within 30 seconds, the system re-enters
MAINTENANCE mode.
FIGURE 4.2.1.2-1
CI SOFTWARE
4.2.1.3 P̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
4.2.1.3.1 C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲ ̲D̲a̲t̲a̲
Some data used in the Command Interpreter are declared
in VDU Driver Data description.
CONST.
local ̲mode = 76;"ASCII L
operational ̲mode = 79;"ASCII O
test ̲mode = 84;"ASCII T
maintenance ̲mode = 77;"ASCII M
left ̲par = 91;"used in mode ̲line
right ̲par = 93;
id ̲size = 35;"size of id ̲passwrd array-1
name ̲size = 18;"command keyword size
max ̲ci ̲events = 21;"number of keyword strings
bnanswer = 2;"bit number set in mask
bninterrupt = 7;
bndelay = 8;
bmanswer = 1 SHIFTLL bnanswer; "bit mask
bminterrupt = 1 SHIFTLL bninterrupt;
bmdelay = 1 SHIFTLL bndelay;
ci ̲result ̲base = #9000;"base for completion
"codes
max ̲ci ̲events = 16;
TYPE
name ̲block =
RECORD "elements in keyword table
name : ARRAY(O..name ̲size) OF CHAR;
identifier: ci ̲functions;
legal ̲mode1,
legal ̲mode2 : integer;
END;
ci ̲functions = ( "constants for function id
escape, "break/attention
unknown, "keyword wrong
unacceptable, "keyword ok, wrong mode
param ̲error, "error in param line
maintenance, "local mode com
logon, "op. or test mode com
logoff, "op. or test mode com
show ̲stat, "op. or test mode com
reset ̲stat, "op. or test mode com
test, "operational mode com
verify, "test mode com
simulate, "test mode com
close ̲down, "bad system status
unexpected ̲answer, "answer has no matching com.
check, "used for write ̲result ̲vdu
dump,
init ̲system);
end ̲systems = ( "end system constant
camps,
scars,
ccis,
unknown ̲system);
user ̲input =
RECORD
end ̲sys ̲camps : boolean; "true if CAMPS
scamps ̲speed, "baudrate CAMPS or SCARS
scamps ̲sci : ARRAY (0..3) OF CHAR;
"trailing zones
ccis ̲speed : integer;
ccis ̲sci : ARRAY (0..3 OF CHAR;
"trailing zerrors
id ̲pass : ARRAY(O..id ̲size) OF CHAR;
"…08…$*$LOGid$psw/DNM…08…,null
verify ̲dest, "which side should reflect
verify ̲length : integer;
simulation : end ̲system;(not used)
vdu ̲speed : integer;
END;
message ̲record = "com. administration record
RECORD
occupied : boolean;
event ̲id : integer;"OS event index
ci ̲function : ci ̲functions;
end ̲system : end ̲systems;
END;
trc ̲command ̲id =
( trc ̲logon ̲id,
trc ̲logoff ̲id,
trc ̲test ̲id,
trc ̲verify ̲id,
trc ̲enable ̲status ̲id );
trc ̲command = " command buffer sent from CI to TRC
RECORD
id : trc ̲command ̲id;
params : ARRAY(0..3) OF integer;
END;
trc ̲logon ̲cmd =
RECORD
id : trc ̲command ̲id;
scamps ̲params: address;
ccis ̲params : address;
END;
scamps ̲logon ̲params =
RECORD
speed : integer; "baud rate
system : end ̲systems; "camps or scars
sci :ARRAY(0..3)OF CHAR; "3 letters
"(trailing
0's)
END;
ccis ̲logon ̲params =
RECORD
speed : integer; "baud rate
id ̲pass "$*$LOGid$password/DNM
: ARRAY(0..35) OF char; "left adjusted,
"trailing O's
sci : ARRAY(0..3)OF CHAR;"3 letters
"(trailing
0's)
END;
trc ̲verify ̲cmd =
RECORD
id: : trc ̲command ̲id;
system : end ̲system; "camps, scars or
ccis
length : integer; "length of test
"message
END;
trc ̲response = " response buffer returned from TRC
to CI "
RECORD
id : trc ̲command ̲id; " command replied
cc : completion ̲code;
result : ARRAY(0..2) OF integer;
END;
lp ̲command ̲id =
(dummy ̲id,
cslp ̲reopen ̲link ̲id,
cslp ̲set ̲up ̲lines ̲id,
cslp ̲disc ̲lines ̲id,
cslp ̲set ̲up ̲link ̲id,
cslp ̲disc ̲link ̲id,
lp ̲request ̲input ̲id,
lp ̲request ̲output ̲id,
lp ̲cancel ̲input ̲id,
lp ̲cancel ̲output ̲id,
cslp ̲statistics ̲id,
clp ̲open ̲link ̲id,
clp ̲close ̲link ̲id,
clp ̲show ̲statistics ̲id,
clp ̲reset ̲statistics ̲id,
lp ̲cancel ̲command ̲id,
bootload ̲id);
lp ̲command =
RECORD
id : lp ̲command ̲id;
params : ARRAY(0..3) OF integer;
END
lp ̲response =
RECORD
id : lp ̲command ̲id;
cc : completion ̲code;
bytes : integer;
fill : ARRAY(0..1) OF integer;
END;
clp ̲show ̲statistics ̲cmd =
RECORD
id : lp ̲command ̲id;
addr : addrss:
fill : ARRAY (0..2) OF integer;
END;
clp ̲reset ̲statistics ̲cmd =
RECORD
id : lp ̲command ̲id;
fill : ARRAY (0..3) OF integer;
END;
cslp ̲statistics ̲cmd =
RECORD
id : lp ̲command ̲id;
addr : addrss:
fill : ARRAY (0..2) OF integer;
END;
cslp ̲response
RECORD
frames ̲transmitted,
frames ̲retransmitted,
frames ̲received: integer "unsigned 16 bit integers
from
"ltudrv
frame ̲errors : ARRAY (0..3) OF byte;
"(o) = crc errors, (1) = too long frames,
"(2) = too short frames, (3) = dcd drops (not
used)
END;
clp ̲response
RECORD
frames ̲transmitted,
frames ̲retransmitted,
frames ̲received ̲error ̲free,
frames ̲received ̲with ̲error : integer;"16 bit
unsigned
"CR80 integers
END;
ci ̲results = ( "completion codes for C1
ok ̲cc, "ok is 0
unexpected ̲answer ̲cc,
illegal ̲id ̲cc,
ltu ̲driver ̲timed ̲out,
unexpected ̲eventtype,
initialization ̲error);
VAR
mode ̲line, unknown ̲line, unacceptable ̲line,
param ̲error ̲line, password ̲line
: ARRAY(0..line ̲limit) OF CHARS;
id ̲pass : ARRAY(0..id ̲size-1) OF CHARS;
command ̲names : ARRAY(0..max ̲ci ̲events) OF name ̲block;
user ̲input ̲params : user ̲input;"all parameters input
command ̲record, "update during send message
enable ̲status ̲record : message ̲record;
scamps ̲params : scamps ̲logon ̲params
ccis ̲params : ccis ̲logon ̲params;
trc ̲message : trc ̲command;
lp ̲message : cslp ̲statistics ̲cmd;
cslp ̲params : cslp ̲response;
clp ̲results : clp ̲response; "normalized format
cslp ̲params : cslp ̲response;
answer : general response;
ci ̲result : integer;
I̲N̲I̲T̲
mode ̲line = cr, lf, left ̲par, sp, right ̲par, null;
unknown ̲line = cr, lf, …08…UNKNOWN COMMAND…08…, cr, lf, null;
unacceptable ̲line = cr, lf,…08…UNACCEPTABLE COMMAND…08…,
cr, lf, null;
param ̲error ̲line = cr, lf,…08…PARAMETER ERROR…08…, cr, lf,
null;
password ̲line = cr, lf, …08…$*$LOGID$PASSWORD/DNM =…08…,
null;
clp ̲message.addr = ADDRESS(clp ̲params); "statistics
cslp ̲message.addr = ADDRESS(cslp ̲params); "statistics
command ̲names( 0)=…08…MAINTENANCE (:0:) …08…, null,
maintenance, local ̲mode, local ̲mode:
command ̲names( 1)=…08…M …08…, null,
maintenance, local ̲mode, local ̲mode;
command ̲names( 2)=…08…LOGON (:0:) …08…, null,
logon, local ̲mode, local ̲mode;
command ̲names( 3)=…08…LOGOFF (:0:) …08…, null,
logoff, operational ̲mode, test ̲mode;
command ̲names( 4)=…08…SHOW STATISTICS (:0:)…08…, null,
show-stat, operational ̲mode, test ̲mode;
command ̲names( 5)=…08…S …08…, null,
show-stat, operational ̲mode, test ̲mode;
command ̲names( 6)=…08…RESET STATISTICS (:0:)…08…, null,
reset ̲stat, operational ̲mode, test ̲mode;
command ̲names( 7)=…08…R …08…, null,
reset ̲stat, operational ̲mode, test ̲mode;
command ̲names( 8)=…08…TEST (:0:) …08…, null,
test, operational ̲mode, operational ̲mode;
command ̲names( 9)= …08…T …08…, null,
test, operational ̲mode, operational ̲mode;
command ̲names(10)=…08…VERIFY (:0:) …08…, null,
verify, test ̲mode, test ̲mode;
command ̲names(11)=…08…V …08…, null,
verify, test ̲mode, test ̲mode;
command ̲names(12)=…08…SIMULATE (:0:) …08…, null,
simulate, local ̲mode, local ̲mode;
command ̲names(13)=…08…S …08…, null,
simulate, local ̲mode, local ̲mode;
command ̲names(14)=…08…CLOSE DOWN (:0:) …08…, null
enable ̲status, local ̲mode, test ̲mode;
command ̲names(15)=…08…UNEXPECTED ANSWER …08…, null,
unexpected
̲answer,
local
̲mode,
operational
̲mode;
command ̲names(16)=…08…CHECK (:0:) …08…, null,
check, maintenance ̲mode, maintenance ̲mode;
command ̲names(17)=…08…C …08…, null,
check, maintenance ̲mode, maintenance ̲mode;
command ̲names(18)=…08…DUMP (:0:) …08…, null,
dump, maintenance ̲mode, maintenance ̲mode;
command ̲names(19)=…08…D …08…, null
dump, maintenance ̲mode, maintenance ̲mode;
command ̲names(20)=…08…INIT (:0:) …08…, null,
init ̲system, maintenance ̲mode, maintenance ̲mode;
command ̲names(21)=…08…I …08…, null,
init ̲system, maintenance ̲mode, maintenance ̲mode;
4.2.1.3.2 V̲D̲U̲ ̲D̲r̲i̲v̲e̲r̲ ̲D̲a̲t̲a̲
CONST
null = 0; "ASCII special characters
bel = 7; "ASCII 12 through 126 are
bs = 8; "…08…normal…08… characters
lf = 10;
cr = 13;
esc = 27;
del = 127;
line ̲limit = 80;
TYPE
ascii ̲group = (
back ̲space,
line ̲feed,
delete ̲line,
escape, "used for …08…attention/break…08…
carriage ̲return,
normal ̲char);
VAR
bs ̲line, lf ̲line, new ̲line, del ̲line,
break ̲line : ARRAY(0..line ̲limit) OF
CHAR;
user ̲buffer : ARRAY(0..line ̲limit) OF
CHAR;
first ̲char, echo ̲requested, read ̲new ̲line,
output ̲to ̲vdu "write line is executing
: boolean;
out ̲char ̲ptr, out ̲char ̲count, in ̲buffer ̲ptr,
in ̲char ̲ptr, in ̲char ̲count
: integer;
INIT
bs ̲line = bs, sp, bs, null;
lf ̲line = lf, null;
new ̲line = lf, cr, null;
del ̲line = bel, lf, cr, null;
break ̲line = …08…*break*…08…, bel, cr, null;
4.2.1.4 P̲a̲c̲k̲a̲g̲e̲ ̲D̲e̲s̲i̲g̲n̲
4.2.1.4.1 C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲ ̲P̲s̲e̲u̲d̲o̲ ̲C̲o̲d̲e̲
(a)
CI MAINPROGRAM START
init ̲ci:
lookup and send message to SCADRV & CISDRV and await
answer with timeout 32 sec.
await ready signals from both ltu drivers
set default values in user ̲input ̲params
MONITOR(switch ̲mode, new ̲mode: = local ̲mode)();
IF ltu driver bootload not ̲ok THEN
perform ̲function (ci ̲function: = maintenance)( )
ELSE
BEGIN
insert …08…L…08… in mode ̲line array
write ̲line ̲vdu (ADDRESS(mode ̲line))();
write ̲result ̲vdu (ci ̲function: = init ̲system,
ci ̲result: = ok ̲cc)( )
END
WHILE A=A DO
BEGIN "endless loop
read ̲command()(ci ̲function)
perform ̲function(ci ̲function)();
END; "while a=a
(b)
PROCEDURE enter ̲wait ̲event
() "no input
() "no output
input :
none
output :
none
function:
wait for an event of one of the following types
- IO interrupt event (intrpt from VDU)
- answer to a kernel message previously sent
call the pertinent procedure for servicing the
event
procedures called:
process ̲vdu ̲interrupt
receive ̲answer
external data:
eventmask, eventtype, event : integer;
answer : general ̲response;
local data:
none
BEGIN "procedure enter ̲wait ̲event
WHILE A=A DO
BEGIN "set up the eventmask and wait
eventmask:= bmanswer IOR bminterrupt;"answers &
"interrupts
waitevent(eventmask,ADDRESS(answer),delay:=0)
(eventtype,event);
CASE eventtype OF
bnanswer : receive ̲answer(ADDRESS(answer),
eventtype,event)();
bninterrupt : process ̲vdu ̲interrupt()(); "VDU driver
OTHERWISE : goto init ̲ci; "fatal error
END; "while a=a
END; "procedure enter ̲wait ̲event
(c)
PROCEDURE read ̲command
() "no input
(ci ̲function: ci ̲functions);
input :
none
output :
ci ̲function = constant identifying a command or
indicating …08…break…08… on VDU. In case of a legal
command, the record user ̲input ̲params contains
all necessary parameters including default values
function:
initialize the reading of a command from the VDU
-
when a command has been entered, analyze the keyword
and fetch the associated parameters
procedures called:
analyze ̲command
external data:
system ̲mode: integer
local data:
none
BEGIN "procedure read ̲command
read ̲line ̲vdu(read ̲new ̲line:= true, echo ̲requested:=
true)(); " enter line in user ̲buffer
MONITOR(read ̲mode)(system ̲mode);"read mode from
"common area
analyze ̲command(ADDRESS(user: ̲buffer),system ̲mode)
(ci ̲function);
IF ci ̲function = logon THEN
BEGIN "enter password
write ̲line ̲vdu(ADDRESS(password ̲line))();
read ̲line ̲vdu(read ̲new ̲line:=true,
echo ̲requested:= false)();
IF in ̲char ̲count LT id ̲size THEN
user ̲input ̲params.id ̲pass:=
first 36 characters in user ̲buffer;"terminated
ELSE "by null
ci ̲function:= param ̲error;
END; "end of special logon servicing
END; "procedure read ̲command
(d)
PROCEDURE analyze ̲command
(ptr, system ̲mode: integer)
(ci ̲functions)
input :
pointer to user ̲buffer containing command line.
system ̲mode containing the current mode of system
output :
ci ̲function identifying an error in the input line
or a legal command
function:
set the user ̲input ̲params stack to default values
except for user ̲input ̲params. simulation
Fetch the command keyword(s) and check the system
mode.
Fetch the additional parameters and update the
user ̲input ̲params record.
procedures called:
read ̲parameters
external data:
user ̲input ̲params
command ̲names: data structure containing keywords
local data:
index in array command ̲names
mode1, mode2, user ̲char ̲count: integer;
"legal modes and current index in user ̲buffer
BEGIN "procedure analyze ̲command
set user ̲input ̲params to default values except
for user ̲input ̲params. simulation
IF user ̲buffer(0) = esc THEN "escape value
ci ̲function:= escape
ELSE
BEGIN "normal command
compare keywords to elements of array command ̲names
user ̲char ̲count points at char following keyword(s)
IF keyword is not recognized THEN
ci ̲function:= unknown "illegal keyword(s)
ELSE
BEGIN "keyword(s) has been recognized
index:= element in array command ̲names
ci ̲function:= command ̲names(index).identifier;
mode1:= command ̲names(index).legal ̲mode1;
mode2:= command ̲names(index).legal ̲mode2;
IF mode1 NE system ̲mode LOGAND
mode2 NE system ̲mode THEN
ci ̲function:= unacceptable "wrong mode
ELSE
BEGIN "mode check was ok, now fetch parameters
read ̲parameters(ci ̲function, user ̲char ̲count)
(result) "read into user ̲input
̲p
IF result NE ok THEN
ci ̲function:=param ̲error;
END; "fetch parameters
END; "end legal keywords
END; "user ̲buffer was not …08…escape…08…
END; "procedure analyze command
(e)
PROCEDURE read ̲parameters
(ci ̲function: ci ̲functions,
user ̲char ̲count : integer)
(result: results) " ok or not ̲ok
input :
function identifier.
index in input line just after keyword(s)
output:
result = ok or not ̲ok
function:
read the parameters requested and insert them in
the common record user ̲input ̲params
procedures called:
TBD
external data:
user ̲input ̲params,
user ̲buffer
local data:
TBD
BEGIN "procedure read ̲parameters
result:= ok;
CASE ci ̲function OF
maintenance: ; "no parameters
logon : read logon parameters "not incl. idpsw!
logoff : ; "no parameters
show ̲stat : ; "no parameters
reset ̲stat : ; "no parameters
test : ; "no parameters
verify : read verify parameters
simulate : read simulate parameter "end systen
name
OTHERWISE result:= not ̲ok;
END; "procedure read parameters
(f)
PROCEDURE perform ̲function
(ci ̲function: ci ̲functions)
()
input :
ci function identifier
output :
none
function:
If …08…escape…08… cancel the command ̲record.
Generally, send a OS ̲message to TRC or either
of the LTU ̲drivers(statistic commands). Answers
to the commands may be received as soon as the
…08…read ̲line…08…procedure is entered. Answers are
serviced by procedure receive ̲answer.
procedures called:
TBD
external data:
command ̲record, enable ̲status ̲record: message ̲record;
event ̲mask, system ̲mode: integer;
answer: general ̲response;
local data:
TBD
BEGIN "perform ̲function
CASE ci ̲function OF
escape:
BEGIN
cancel command ̲record
prompt for new command using array mode ̲line
END; "escape
unknown,
unacceptable,
param ̲error:
BEGIN "write syntax error message CASE
ci
̲function
OF
unknown: write ̲line ̲vdu(ADDRESS(unknown ̲line))();
unacceptable: write ̲line ̲vdu(ADDRESS
(unacceptable ̲line))();
param ̲error: write ̲line ̲vdu(ADDRESS(param ̲error
̲line))
END; "case end
MONITOR(read ̲mode)(system ̲mode); "read mode
insert ASCII value of system mode in mode ̲line
write ̲line ̲vdu(ADDRESS(mode ̲line))(); "prompt f.
command
END; "syntax/parameter error
maintenance:
BEGIN
MONITOR(switch ̲mode, new ̲mode:= maintenance)();
masterclear system
END;
logon:
BEGIN
trc ̲logon ̲message.id:= trc ̲logon ̲id;
trc ̲logon ̲message.scamps ̲params:=
ADDRESS(scamps ̲params);
trc ̲logon ̲message.ccis ̲params:=
ADDRESS(ccis ̲params);
move parameters from user ̲input ̲params "input record
to scamps ̲params
move parameters from user ̲input ̲params "input record
to ccis ̲params
command ̲record.occupied:= true; "update record
command ̲record.ci ̲function:= logon; "to new com
send ̲message(trc, trc ̲logon ̲message)(event)
command ̲record.event ̲id:= event; "command is sent
enable ̲status ̲record.occupied:= true;
enable ̲status ̲record.ci ̲function:= enable ̲status;
trc ̲message.id:= trc ̲enable ̲status ̲id;
send ̲message(trc, trc ̲message)(event);
enable ̲status ̲record.event ̲id:= event;"allow answer
END; "case entry logon
logoff:
BEGIN
trc ̲message.id:= trc ̲logoff ̲id;
command ̲record.occupied:= true;
command ̲record.ci ̲function:= logoff;
send ̲message(trc, trc ̲message)(event)
command ̲record.event ̲id:= event;
reinitialize ALL parameters in user ̲input ̲params
END; "logoff
test:
BEGIN
trc ̲message.id:= trc ̲test ̲id;
command ̲record.occupied:= true;
command ̲record.ci ̲function:= test;
send ̲message(trc, trc ̲message)(event);
command ̲record.event ̲id:= event;
END; "test
verify:
BEGIN
trc ̲verify ̲message.id:= trc ̲verify ̲id;
trc ̲verify ̲message.system:=
user ̲input ̲params.verify ̲dest;"const. end ̲system
trc ̲verify ̲message.length:=
user ̲input ̲params.verify ̲length;
command ̲record.occupied:= true;
command ̲record.ci ̲function;
send ̲message(trc, trc ̲verify ̲message)(event);
command ̲record.event ̲id:= event;
END; "verify
simulate: ;"no action as procedure …08…read ̲parameters…08…
"has entered an indication of simulation in
"user ̲input ̲params if so requested from the vdu
"a request for simulation is only cancelled by logoff
show ̲stat:
BEGIN
clp ̲message.id:= clp ̲show ̲statistics ̲id;
command ̲record.occupied:= true;
command ̲record.ci ̲function:= show ̲stat;
command ̲record.end ̲system:= CCIS; "send to CCIS
first
send ̲message(clp, clp ̲message)(event);
command ̲record.event ̲id:= event;
eventmask:= bmanswer IOR bmdelay; "timeout and
answer
await ̲answer(eventmask,ADDRESS(answer),delay:=2
sec)
(eventtype,event);
receive ̲answer(ADDRESS(answer),eventtype,event)();
cslp ̲message.id:= cslp ̲show ̲statistics ̲id;
command ̲record.occupied:= true;
command ̲record.ci ̲function:= show ̲stat;
command ̲record.end ̲system:= SCARS; "send to SCAMPS
send ̲message(cslp, cslp ̲message)(event);
command ̲record.event ̲id:= event;
eventmask:= bmanswer IOR bmdelay; "timeout and
answer
await ̲answer(eventmask,ADDRESS(answer),delay:=2
sec)
(eventtype,event);
receive ̲answer(ADDRESS(answer),eventtype,event)();
END; "show statistics
reset ̲stat:
BEGIN
clp ̲message.id:= clp ̲reset ̲statistics ̲id;
command ̲record.occupied:= true;
command ̲record.ci ̲function:= reset ̲stat;
send ̲message(clp, clp ̲message)(event);
command ̲record.event ̲id:= event;
eventmask:= bmanswer IOR bmdelay;
await ̲answer(eventmask,ADDRESS(answer),delay:=2
sec)
(eventtype,event);
receive ̲answer(ADDRESS(answer),eventtype,event)();
cslp ̲message.id:= cslp ̲reset ̲statistics ̲id;
command ̲record.occupied:= true;
command ̲record.ci ̲function:= reset ̲stat;
send ̲message(cslp, cslp ̲message)(event);
command ̲record.event ̲id:= event;
eventmask:= bmanswer IOR bmdelay;
await ̲answer(eventmask,ADDRESS(answer),delay:=2
sec)
(eventtype,event);
receive ̲answer(ADDRESS(answer),eventtype,event)();
END; "reset statistics
OTHERWISE ; "no action, illegal commands must
be
"trapped prior to …08…perform ̲function…08…
END; "procedure perform ̲function
(g)
PROCEDURE receive ̲answer
(answer: general ̲response, "record for answer
eventtype, "is it answer, or delay ?
event) "index used by OS kernel
() "no output
input :
pointer to kernel message answer.
Event identifying the message to which the answer
belongs.
output :
none
function:
receive the answer and examine the command ̲record
and the enable ̲status ̲record in order to identify
the answer.
If eventtype is bndelay or the answer is illegal
set result code to …08…timed ̲out…08… or
…08…unexpected ̲answer…08…, respectively
In case of a good answer to a show statistics command,
write the statistic result.
Prompt for a new command.
procedures called:
write ̲result ̲vdu
write ̲statistics
external data:
trc ̲answer,
clp ̲answer,
cslp ̲answer: used for specific responses
answer: record used for all responses
command ̲record, enable ̲status ̲record:
used for administration of answers
command ̲names: table of keywords
local data:
system ̲mode: integer; "for reading system ̲mode
no ̲prompt: boolean; "avoid prompt if set during reception
"of enable status response
BEGIN "procedure receive ̲answer
no ̲prompt:= false; "initialization to general value
ci ̲function:= maintenance; "initial dummy value
IF NOT((command ̲record.occupied=true LOGAND
command ̲record.event ̲id = event) LOGOR
(enable ̲status ̲record.occupied=true LOGAND
enable ̲status ̲record.event ̲id=event)) THEN
ci ̲function:= unexpected ̲answer;
IF ci ̲function = unexpected ̲answer LOGOR
eventtype = bndelay THEN "error or timed out
BEGIN "time out in await answer or unexpected answer
"collect garbage answers here
IF eventtype = bndelay THEN
BEGIN
ci ̲result:= ci ̲result ̲base IOR timed ̲out ̲cc;
IF ci ̲function NE unexpected ̲answer THEN
ci ̲function:= command ̲record.ci ̲function;
clear command ̲record;
END
ELSE
ci ̲result:= ci ̲result ̲base IOR
unexpected ̲answer ̲cc;
write ̲result ̲vdu(ci ̲function, ci ̲result)();
END "delay or illegal answers
ELSE
BEGIN "the event ̲id is present in a valid
"command ̲record or status ̲record and
"eventtype is not delay
IF enable ̲status ̲record.occupied=true LOGAND
enable ̲status ̲record.event ̲id=event THEN
BEGIN "receive status response from TRC
ci ̲function:= enable ̲status ̲record.ci ̲function;
copy answer to trc ̲answer; "five words record
IF trc ̲answer.id NE trc ̲enable ̲status ̲id THEN
ci ̲result:=ci ̲result ̲base IOR illegal ̲id ̲cc;
ELSE
ci ̲result:= trc ̲answer.cc; "TRC result
IF ci ̲result NE ok ̲cc THEN
BEGIN
write ̲result ̲vdu(ci ̲function, ci ̲result)();
no ̲prompt:= true; "no result and prompt if
END;
END; "enable status response servicing
ELSE
BEGIN "normal answer corresp. t. command ̲rec.
ci ̲function:= command ̲record.ci ̲function;
CASE ci ̲function OF
maintenance, "not likely
logon,
logoff,
test,
verify:
BEGIN "trc ̲answer
copy answer record to trc ̲answer
ci ̲result:= trc ̲answer.cc; "completion code
write ̲result ̲vdu(ci ̲function, ci ̲result)();
IF ci ̲function = logon LOGAND ci ̲result = ok
THEN
send enable ̲status command
END;
show ̲stat,
reset ̲stat:
BEGIN "answers sent from LTU
ci ̲result:= answer.result; "completion code
write ̲result ̲vdu(ci ̲function,ci ̲result)();
IF ci ̲function = show ̲stat THEN
BEGIN "display statistics on VDU
IF command ̲record.end ̲system = CCIS THEN
BEGIN "clp statistics
copy …08…answer…08… to …08…clp ̲answer…08…
write ̲statistics ̲vdu(end ̲system:= CCIS
clp ̲answer)();
END
ELSE
BEGIN
copy …08…answer…08… to …08…cslp ̲answer…08…
write ̲statistics ̲vdu(end ̲system:= command
̲record.
end
̲system
cslp ̲answer)();
END; "cslp statistics
END; "show statistics
END; "statistics
clear command ̲record "release record
END; "normal answer
END; "legal event
MONITOR(read ̲mode)(system ̲mode);"read current mode
insert system ̲mode of value 76, 79, 84 (ASCII) into
array …08…mode ̲line…08… instead of space.
IF no ̲prompt=false THEN "avoid double prompt if enable
"status rsp is received
write ̲line ̲vdu(ADDRESS(mode ̲line))(); "PROMPT for
com
END; "procedure receive ̲answer
(h)
PROCEDURE write ̲result ̲vdu
(ci ̲function: ci ̲functions,
ci ̲result: integer)
() "no output
input :
ci ̲function: constant identifying a command entered
or an abnormal situation
ci ̲result: hexadecimal integer containing result
output :
none
function:
look up the text string corresponding to the
ci ̲function. The string is a command keyword or
an error message. In both cases the text is
fetched from the array …08…command ̲names…08….
Type the following on a new line:
(17 char text string) EXECUTED, RESULT= (ci ̲result)
procedures called:
write ̲line ̲vdu
write ̲hex ̲vdu
external data:
array …08…command ̲names…08… containing keywords
local data:
TBD
BEGIN "procedure write ̲result ̲vdu
"pseudo code
END; "procedure write ̲result ̲vdu
(i)
PROCEDURE write ̲statistics ̲vdu
(end ̲system: end ̲systems
answer: general ̲response) "five words
() "no output
input :
boolean indicating CAMPS/SCARS or CCIS
answer: clp or cslp answer record with an address
field pointing at four words of statistics information
of type clp ̲response ̲params or cslp ̲response ̲params
output :
none
function:
type the following on the VDU starting on a new line:
(end system name): FRAMES TRANSMITTED :
(count)
FRAMES RETRANSMITTED :
(count)
FRAMES RECEIVED ERRRO FREE :
(count)
FRAMES RECEIVED WITH ERROR :
(count)
where (end system name) is 'CAMPS', 'SCARS' or 'CCIS'.
(count) is a decimal integer.
procedures called:
write ̲line ̲vdu
write ̲hex ̲vdu "procedure for writing a number on
the
VDU .
external data:
four words contained in a record of type
clp ̲response ̲params or cslp ̲response ̲params.
local data:
BEGIN "procedure write ̲statistics
"pseudo code
END; "procedure write ̲statistics
4.2.1.4.2 V̲D̲U̲ ̲D̲r̲i̲v̲e̲r̲ ̲P̲s̲e̲u̲d̲o̲ ̲C̲o̲d̲e̲
(a)
PROCEDURE process ̲vdu ̲interrupt
() "no input
() "no output
input :
none
output :
none
function:
this procedure receives an IO interrupt from
the VDU. It is investigated whether the VDU
interrupt is caused by input, output, or
…08…attention…08… (break). A break is serviced and
then considered as input character …08…escape…08….
procedures called:
move ̲char ̲to ̲buffer "service input
write ̲new ̲char ̲from ̲buffer "service output
external data:
character read from vdu
first ̲char: boolean used for fetching new char
pointers and byte counts for IO arrays
local data:
interrupt ̲cause ̲code for case clause
break ̲set: boolean for flagging break
BEGIN "procedure process interrupt
sense break on SCM
IF break is set THEN
BEGIN "reset break flag in hardware
clear break on SCM
break ̲set:= true;
END
ELSE
break ̲set:= false;
interrupt ̲cause:= ignore ̲interrupt; "initialize
sense VDU status word "read SCM status word
IF output is ready THEN
interrupt ̲cause:= output ̲interrupt;
IF (input is ready LOGOR break ̲set=true) LOGAND
output ̲to ̲vdu = false THEN
interrupt ̲cause:= input ̲interrupt;
CASE interrupt ̲cause OF
input ̲interrupt:
BEGIN
IF break ̲set=true THEN
character:= esc "escape indicates break
ELSE
read character from SCM;
move ̲character ̲to ̲buffer(character)(); "no return
END;
output ̲interrupt:
write ̲new ̲char ̲from ̲buffer
(out ̲char ̲ptr, first ̲char:= false)(); "no return
OTHERWISE:
BEGIN
clear interrupt;
enter ̲wait ̲event; "enter calling context immediately
END;
END; "procedure process ̲interrupt
(b)
PROCEDURE write ̲new ̲char ̲from ̲buffer
(out ̲char ̲ptr: integer, "pointer to character
first ̲char: boolean) "start of line
() "no output
input :
pointer to next char to be output, first ̲char is
true at start of new line
output :
character sent to VDU
function:
output character until null is met, then return to
the calling procedure
procedures called:
enter ̲wait ̲event
external data:
out ̲buffer global array with characters terminated
by the null character
out ̲char ̲ptr, out ̲char ̲count for fetching chars
local data:
link
out ̲character
BEGIN
IF first ̲char = true THEN
BEGIN
save link
out ̲char ̲count:= 0;
END;
clear break on SCM
out ̲character:= out ̲buffer(out ̲char ̲count);
IF out ̲character NE null LOGAND
out ̲char ̲count LT line ̲limit THEN
BEGIN
out ̲char ̲count:= out ̲char ̲count+1;
sense if VDU is ready
write character on VDU
enter ̲wait ̲event()();
END;
"return to calling context
END; "procedure write ̲new ̲char ̲from ̲buffer
(c)
PROCEDURE write ̲line ̲vdu
(out ̲char ̲ptr: integer)
() "no output
input :
out ̲char ̲ptr points at first char in line to
be written. The character string must be
terminated by at least one null character,
ASCII 0
output :
none
function:
initiate the writing of one line to the VDU -
return when finished
procedures called:
write ̲new ̲char ̲from ̲buffer
external data:
out ̲char ̲ptr: pointer to characters
local data:
none
BEGIN "procedure write ̲line ̲vdu
output ̲to ̲vdu:= true;
write ̲new ̲char ̲from ̲buffer
(out ̲char ̲ptr, first ̲char:= true)
()
output ̲to ̲vdu:= false;
END; "procedure write ̲line ̲vdu
(d)
PROCEDURE move ̲char ̲to ̲buffer
(character: char)
()
input :
character just read
output :
line received terminated by cr.
Special characters: delete line and …08…attention…08…
(break) are returned as the characters ASCII
27 and 127, respectively. All character strings
are terminated with one or more null…08…s.
function:
check character and service special characters.
Echo normal characters if requested. Exit by
calling read ̲line ̲vdu with read ̲new ̲line = false.
procedures called:
read ̲line ̲vdu with read ̲new ̲line:= false
write ̲line ̲vdu for echoing characters
external data:
user ̲buffer: ARRAY(0..line ̲limit) OF CHAR;
echo ̲requested: boolean;
local data:
char ̲group: ASCII ̲group; "back ̲space, line ̲feed etc.
ptr: integer; "local pointer
BEGIN "procedure move ̲char ̲to ̲buffer
examine character
char ̲group:=
back ̲space or
line ̲feed or
delete ̲line or "ASCII 127
escape or "substitutes …08…break…08…
carriage ̲return or
normal ̲char "character between 32 (sp) and 126
CASE char ̲group OF
back ̲space:
BEGIN
IF in ̲char ̲count GT 0 THEN
BEGIN
user ̲buffer(in ̲char ̲count):= null;
in ̲char ̲count:= in ̲char ̲count-1;
write ̲line ̲vdu(ptr:=ADDRESS(bs ̲line))(); "echo
END;
END;
line ̲feed:
BEGIN
write ̲line ̲vdu(ptr:=ADDRESS(lf ̲line))(); "echo
lf
END;
delete ̲line:
BEGIN
clear user ̲buffer
in ̲char ̲count:= 0;
user ̲buffer(in ̲char ̲count):= del;
write ̲line ̲vdu(ptr:=ADDRESS(del ̲line))();
END;
escape:
BEGIN
clear user ̲buffer
in ̲char ̲count:= 0;
user ̲buffer(in ̲char ̲count):= esc;
write ̲line ̲vdu(ptr:=ADDRESS(break ̲line))()
read ̲line ̲vdu(read ̲new ̲line:= false,
echo ̲requested:= true);
END;
carriage ̲return:
BEGIN "deliver line to user through read ̲line ̲vdu
write ̲line ̲vdu(ptr:=ADDRESS(new ̲line))(); "lf cr
read ̲line ̲vdu(read ̲new ̲line:= false,
echo ̲requested:= true)();
END;
normal ̲char:
BEGIN
in ̲char ̲count:= in ̲char ̲count+1;
IF in ̲char ̲count LT line ̲limit THEN
BEGIN
user ̲buffer(in ̲char ̲count):= character;
IF echo ̲requested = true THEN
write ̲line ̲vdu(ptr:=ADDRESS(character,null))();
END
ELSE "substitute with null and deliver line
BEGIN
user ̲buffer(in ̲char ̲count):= null;
write ̲line ̲vdu(ptr:=ADDRESS(new ̲line))();
read ̲line ̲vdu (read ̲new ̲line: = false,
echo ̲requested: = true)();
END; "line length exceeded
END; "case normal character
OTHERWISE:
enter ̲wait ̲event()();
END; "end procedure move ̲char ̲to ̲buffer
(e)
(PROCEDURE read ̲line ̲vdu
(read ̲new ̲line,
echo ̲requested: boolean)
() "no output
input :
read ̲new ̲line is true when the reading of a line
is initiated. echo ̲requested is true when the
line should be echoed.
output :
the line read is delivered in the array
user ̲buffer. Carriage return is omitted. Lines
are terminated by ASCII null.
function:
initialize the buffer used for intermediate
storage of characters read from the VDU. Wait
for more characters or other events. If
read ̲new ̲line is false, data are delivered in
the array user ̲buffer.
procedure called:
enter ̲wait ̲event
external data:
user ̲buffer
local data:
none
BEGIN
IF read ̲new ̲line = true THEN
BEGIN "initiate reading a new line
save link
initialize user ̲buffer to null…08…s
enter ̲wait ̲event()();
END
…02……02…ELSE
BEGIN "line has been read
deliver line
END;
END; "line delivered in user ̲buffer at return
4.2.1.5 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
CI sends the following commands to TRC for execution:
- LOGON
- LOGOFF
- TEST
- VERIFY
LOGON parameters are sent to TRC in the record trc
̲logon ̲message of type trc ̲logon ̲cmd.
LOGOFF and TEST commands are sent to TRC in the record
trc ̲message of type trc ̲command.
VERIFY parameters are sent to TRC encoded into the
record trc ̲verify ̲message of type trc ̲verify ̲cmd.
Answers from TRC are received in the record trc ̲answer
of type trc ̲response.
CI sends the following commands to CLP and CSLP for
execution:
- SHOW STATISTICS
- RESET STATISTICS
Commands are sent to CLP and CSLP as a record named
lp ̲message of type cslp ̲statistics ̲cmd.
Answers to CI from CLP and CSLP as one response record
named answer of type clp ̲response and or cslp ̲response,
respectively.
All command messages and command answers are sent to
and received from packages as AMOS messages and answers.
The operator is not prompted for new PC commands before
the previous command has been executed and an answer
has been received.
In case of a locked situation the operator may provoke
the prompt by entering a 'break/ attention' character.
Reentering commands without having received an answer
to the previous ones will eventually cause a system
crash due to buffer resource limitations.
4.2.2 T̲r̲a̲f̲f̲i̲c̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲ ̲(̲T̲R̲C̲)
TRC performs the traffic control functions and supervises
the system in operational and test mode.
4.2.2.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
TRC performs external functions on request from the
command Interpreter (CI) and applies functions on the
PA interface for controlling the Protocol Adapter packages
CSPA and CPA representing CAMPS/SCARS and CCIS respectively.
The TRC functional responsibilities are grouped in
the following categories:
- Line control
- Transfer control
- Test control
4.2.2.1.1 L̲i̲n̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
TRC controls the opening and closure of the links to
the two end-systems.
The following functions are performed:
a) S̲y̲s̲t̲e̲m̲ ̲M̲o̲d̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
TRC controls and updates the system ̲mode variable
reflecting the current state of processing as being
either:
- local ̲mode,
- operational ̲mode,
- test ̲mode
b) L̲o̲g̲o̲n̲
On request, Logon commands are communicated to
CSPA and CPA for opening links to both end ̲systems.
If successfull, system ̲mode is changed from local
̲mode to operational ̲mode.
c) C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲
Logoff commands are communicated to CSPA and/or
CPA in the following cases:
- Logoff request from CI
- Link disconnected
- Detection of unrecoverable error
Close Down includes change of system ̲mode to local
̲mode and sending Error Report to CI (see d)).
d) E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲
Error Report is sent to CI as a response to the
trc ̲enable ̲status command when a Close Down occurs.
4.2.2.1.2 T̲r̲a̲n̲s̲f̲e̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲
TRC controls the transfer of transactions through the
system in operational mode.
a) T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲A̲c̲k̲n̲o̲w̲l̲e̲d̲g̲e̲m̲e̲n̲t̲
Figures 4.2.2.1.2-1 through -3 show how transactions
passing the Protocol Converter are transmitted
and acknowledged by end-systems.
The rule applied by end-systems is to wait for
acknowledgement of one transaction before the next
transaction is dispatched. If the acknowledgement
does not arrive within the time limit applied by
the end-system, either transmission of a new transaction
or retransmission will take place by the end ̲system.
PC will always accept a new incoming transaction.
However, if the last transaction in the same direction
has not been acknowledged, PC will cancel the old
transaction which will not be acknowledged.
C̲A̲M̲P̲S̲/̲S̲C̲A̲R̲S̲ P̲C̲ C̲C̲I̲S̲(̲D̲I̲N̲D̲A̲C̲)̲ C̲C̲I̲S̲(̲T̲O̲P̲)̲
send A receive A; send A receive A
receive super ̲ack send super ̲ack
receive ack(A) send ack(A) release A receive
A
FIGURE 4.2.2.1.2-1…01…CAMPS/SCARS TO CCIS UNIDIRECTED TRANSMISSION
C̲A̲M̲P̲S̲/̲S̲C̲A̲R̲S̲ P̲C̲ C̲C̲I̲S̲(̲D̲I̲N̲D̲A̲C̲)̲ C̲C̲I̲S̲(̲T̲O̲P̲)̲
accept B send B
receive B send B; receive B send B
send super ̲ack(B) receive
super ̲ack B
send ack(B) receive ack(B)
send ack(B) receive ack(B)
receive super ̲ack send super ̲ack
(ack(B)) (ack(B)
release ack(B) receive ack(B)
FIGURE 4.2.2.1.2-2…01…CCIS TO CAMPS/SCARS UNIDIRECTED TRANSMISSION
C̲A̲M̲P̲S̲/̲S̲C̲A̲R̲S̲ P̲C̲ C̲C̲I̲S̲(̲D̲I̲N̲D̲A̲C̲)̲ C̲C̲I̲S̲(̲T̲O̲P̲)̲
accept B send B
send A receive B; send B; send B
receive A
send super ̲ack(B) receive
super ̲ack(B)
receive B send A receive A
send ack(B) receive ack (B)
receive super ̲ack(A) send super ̲ack(A)
release A receive A
send ack(B) receive ack(B)
receive ack(A) send ack(A)
receive super ̲ack send super ̲ack
(ack(B)) (ack(B)
release ack(B) receive ack(B)
FIGURE 4.2.2.1.2-3…01…CAMPS/SCARS CCIS BIDIRECTED TRANSMISSION
b) T̲r̲a̲n̲s̲f̲e̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲l̲o̲w̲
Figure 4.2.2.1.2-4 shows how TRC controls the transfer
and acknowledgement of a transaction from CAMPS/SCARS
to CCIS.
Flow in the opposite direction is treated in the
same way. TRC sees no difference between the CAMPS/SCARS
and the CCIS side.
TRC handles flow in both directions concurrently.
The control flow is designed to maximize the throughput.
Whenever the pc ̲trans buffer contains sufficient
data to transmit a block, the pa ̲request ̲output
command is issued.
C̲S̲P̲A̲ T̲R̲C̲ C̲P̲S̲
pa ̲request ̲input
ok (pa ̲request ̲input) (block)
* *
pa ̲request ̲input
ok (pa ̲request ̲input) (block)
pa ̲request ̲input
pa ̲request ̲output
(block)
ok (pa ̲request ̲output)
* *
ok (pa ̲request ̲input (last block)
* *
pa ̲request ̲output
(last block)
pa ̲send ̲ack ok (pa ̲request ̲output)
ok (pa ̲send ̲ack)
FIGURE 4.2.2.1.2-4…01…CAMPS/SCARS TO CCIS FLOW THROUGH TRC
c) S̲C̲I̲ ̲C̲h̲e̲c̲k̲
The SCI check serves the purpose of verifying that
the origin and destination of transactions passing
PC are in accordance with the end systems specified
in the logon command. When logging on from PC the
operator supplies two SCI values, one for each
end system to which the PC is to be connected.
These values identify the end system configuration
as two directed channels. All transactions passing
PC also contain a SCI value as part of the E1 format.
This SCI must for each direction be the same for
all transactions and equal the value supplied at
logon.
When the first block of a transaction arrives to
PC, the SCI value is compared with the SCI value
defined at logon for the given direction. If not
equal, the check has failed.
The following figure 4.2.2.1.2-5 shows the end-system
configurations to which a SCI value must be defined
(marked by X).…06…1 …02… …02…
…02… …02…
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲s̲i̲t̲e̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲2̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲3̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
channel
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
CAMPS - CCIS X X X
CCIS - CAMPS X X X
SCARS - CCIS X
X
CCIS - SCARS X
X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FIGURE 4.2.2.1.2-5
PC APPLICABLE CHANNELS…06…1 …02… …02… …02… …02…
d) T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲L̲e̲n̲g̲t̲h̲ ̲C̲h̲e̲c̲k̲
On response to a pa ̲request ̲input which delivers
a block of input the accummulated length is checked
not to exceed a threshold depending on transaction
type.
The total length limits defined in figure 4.2.2.1.2-6
include E1 header and trailer, text and line delimeters.
Message type Value Total Length Limit
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Display C tll2
Comment D tll3
Transaction ack. E 9
Channel check F 57
Final number G 54
Narrative M tll1
Data N tll1
Susdup display O tll2+4
Susdup comment…02…P tll3+4
Susdup narrative Q tll1+4
Susdup data R tll1+4
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FIGURE 4.2.2.1.2-6
TOTAL LENGTH TABLE
t̲l̲l̲1̲ is 12000 characters
t̲l̲l̲2̲ is based on the following calculation of
the size of a display message with a text
part containing 20 lines of 80 characters
(+3 linedelimeters) each:
E̲1̲ ̲f̲o̲r̲m̲a̲t̲ ̲l̲i̲n̲e̲ L̲e̲n̲g̲t̲h̲ ̲(̲c̲h̲a̲r̲s̲)̲
B 9
C 40
D1 9
D2 33
E 11
F 12
J (104+20*83) 1764
G 7
̲ ̲ ̲ ̲ ̲ ̲ ̲
t112 = 1885
t̲l̲l̲3̲ is based on the following calculation of
the size of a comment message with a text
part containing 20 lines of 80 characters
(+3 line delimeters) each:
E̲1̲ ̲F̲o̲r̲m̲a̲t̲ ̲l̲i̲n̲e L̲e̲n̲g̲t̲h̲ ̲(̲c̲h̲a̲r̲s̲)
B 9
C 28
D1 9
D2 33
E 11
F 12
J (48+20*83) 1708
G 7
̲ ̲ ̲ ̲ ̲ ̲ ̲
tll3 = 1817
Since end-systems will check the total length of incoming
transactions PC only performs a transaction length
check based on approximate limits. Thus PC considers
a transaction to be oversized when the following limits
are exceeded:
1) 2000 chars for transaction types C,D,F,G,O,P
2) 12004 chars for transaction types M,N,Q,R
Transaction type E is handled in a special way by PC
and must be exactly 9 characters long.
e) E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The following errors are considered unrecoverable:
- link ̲down
- protocol ̲failure
- sci ̲error
- pc ̲system ̲error
The following errors are considered recoverable:
- message ̲control ̲error
- new ̲transaction
- transaction ̲length ̲error
On detection of a recoverable error, the transaction
affected is cancelled in both directions.
On detection of an unrecoverable error, both transactions
are cancelled in both directions and a close down
is performed. An error message is sent to CI.
4.2.2.1.3 T̲e̲s̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲
TRC controls the system in on-line test ̲mode.
a) trc ̲test Function
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Test mode is entered when TRC receives the trc
̲test command from CI. System ̲mode is changed to
test ̲mode.
b) trc ̲verify Function
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
TRC performs the verify function as follows:
- Generate E1 transaction of specified length
for specified destination. The transaction
is loaded to pc ̲trans buffer for the relevant
flow ̲direction.
- Transmit the transaction (and receive acknowledgement).
- Receive a transaction in the pc ̲trans buffer
for the opposite flow direction (and generate
acknowledgement).
- Compare the content of the two buffers. The
test is passed if content of the text part
of the transaction is the same.
- Send response indicating whether test is passed
or failed.
For verification towards CCIS, the test message
is sent to the program with KEY = …08…KEN …08…. This
program will send the message back automatically.
For verification towards CAMPS/SCARS, the mechanism
for reflecting the message will be procedural (operator
intervention).
4.2.2.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
a) S̲t̲a̲t̲i̲c̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The TRC package is organized in four modules:
1) TRC ̲MAIN ̲CONTROL
implementing main control and initialization.
2) TRC ̲LINE ̲CONTROL
implementing line control functions.
3) TRC ̲TRANSFER ̲CONTROL
implementing transfer control functions
4) TRC ̲TEST ̲CONTROL
implementing test control functions
Figure 4.2.2.2-1 contains an overview of module
content.
M̲O̲D̲U̲L̲E̲S̲ P̲R̲O̲C̲E̲D̲U̲R̲E̲S̲
TRC ̲MAIN trc
init ̲pc ̲trc
execute ̲trc ̲command
trc ̲system ̲error
TRC ̲LINE ̲CONTROL trc ̲logon
trc ̲logoff
trc ̲enable ̲status
close ̲down
send ̲and ̲wait
TRC ̲TRANSFER ̲CONTROL transfer
get ̲direction
clear ̲buffer
check ̲sci
check ̲total ̲length
schedule ̲request
send ̲pa ̲request ̲input
send ̲pa ̲request ̲output
send ̲pa ̲send ̲ack
cancel ̲trans
TRC ̲TEST ̲CONTROL trc ̲test
trc ̲verify
FIGURE 4.2.2.2-1
TRC PACKAGE SOFTWARE
b) D̲y̲n̲a̲m̲i̲c̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The TRC package is implemented as a single process.
The TRC process is driven by external events of
the following kind:
1) command requested from CI
(operator commands)
2) response to command sent from TRC to CSPA
3) response to command sent from TRC to CPA
The TRC process waits for an external event. When
one arrives, a procedure is called for taking appropriate
action and after completion control is returned
to the general waiting point.
Figure 4.2.2.2-2 depicts the procedure call structure.
4.2.2.3 P̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
Figure 4.2.2.3-1 gives an overview of the TRC package
data together with the globally defined transaction
buffers pc ̲trans. The figure summarises the variables
by name, details are explained below.
TRC data declarations:
TYPE
pa ̲op ̲desc = "descriptor of operation to CPA, CSPA
RECORD
state: op ̲state;
receiver: process ̲name;
event ̲id: event;
com: pa ̲command;
END;
op ̲state =
( op ̲none, " no request pending
op ̲wait ̲response " pending request
);
VAR
in ̲op, " two request ̲input descriptors
out ̲op, " two request ̲output descriptors
ack ̲op: " two send ̲ack descriptors
ARRAY( flow ̲direction ) OF pa ̲op ̲desc;
FIGURE 4.2.2.2-2
TRC PROCEDURE CALL STRUCTURE
TYPE
trc ̲op ̲desc = " descriptor of operation from CI
RECORD
state: op ̲state;
event ̲id: event;
com: trc ̲command;
resp: trc ̲response;
END;
VAR
trc ̲op, " one general trc op descriptor
status ̲op: trc ̲op ̲desc; " one enable ̲status op
" descriptor
test ̲tsn: "TSN counters used in test
mode
ARRAY(flow ̲direction) OF integer;
CONST
delay = 3 min; "timeout value in waitanswer
FIGURE 4.2.2.3-1
TRC DATA OVERVIEW
4.2.2.4 P̲a̲c̲k̲a̲g̲e̲ ̲D̲e̲s̲i̲g̲n̲
PDL descriptions of package procedures are given in
appendix 1.
4.2.2.5 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
TRC applies the following interfaces:
a) T̲R̲C̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Receives commands:
trc ̲logon
trc ̲logoff
trc ̲enable ̲status
trc ̲test
trc ̲verify
b) P̲A̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲(̲b̲o̲t̲h̲ ̲C̲S̲P̲A̲ ̲a̲n̲d̲ ̲C̲P̲A̲)̲
Sends commands:
pa ̲logon
pa ̲logoff
pa ̲request ̲input
pa ̲request ̲output
pa ̲send ̲ack
pa ̲cancel
4.2.3 C̲A̲M̲P̲S̲/̲S̲C̲A̲R̲S̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲A̲d̲a̲p̲t̲e̲r̲ ̲(̲C̲S̲P̲A̲)̲
CSPA is responsible for the X25 level 3 protocol functions
towards CAMPS/SCARS and transfers blocks of data to/from
the pc ̲trans buffer on request from TRC.
4.2.3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
CSPA performs the external functions specified in the
PA interface (cf. section 4.1.5.3) and applies functions
on the CSLP interface (cf. section 4.1.5.4).
The CSPA functional responsibilities are grouped as
follows:
- Transfer of blocks
- Framing and control
4.2.3.1.1 T̲r̲a̲n̲s̲f̲e̲r̲ ̲o̲f̲ ̲B̲l̲o̲c̲k̲s̲
CSPA transfers blocks of data to/from the global transaction
buffer pc ̲trans and requests corresponding frames to
be transmitted/received to/from CAMPS/SCARS by CSLP.
Figure 4.2.3.1.1-1 shows the control flow involved
in blockwise reception of a transaction from CAMPS/SCARS
to PC through CSPA, including acknowledgement.
Figure 4.2.3.1.1-2 shows the control flow involved
in blockwise transmission of a transaction from PC
to CAMPS/SCARS through CSPA, including acknowledgement.
C̲S̲L̲P̲ C̲S̲P̲A̲ T̲R̲C̲
cslp ̲request ̲input pa ̲request ̲input
-----------------------------------------------------------------------
ok (cslp ̲request ̲ ok (pa ̲request ̲input) (block)
input) (frame) (frame)
* *
cslp ̲request ̲input pa ̲request ̲input
ok (cslp ̲request ̲ ok (pa ̲request ̲input) (last block)
input)(last frame) (last frame)
cslp ̲request ̲output pa ̲send ̲ack
(E1 trans ack)
ok (cslp ̲request ̲ ok (pa ̲send ̲ack)
output)
FIGURE 4.2.3.1.1-1…01…CAMPS/SCARS TO PC COMPLETED TRANSMISSION
C̲S̲L̲P̲ C̲S̲P̲A̲ T̲R̲C̲
cslp ̲request ̲input pa ̲request ̲input
-----------------------------------------------------------------------
(frame out) cslp ̲request ̲output pa ̲request ̲output
(frame) (block)
ok (cslp ̲request ̲ ok (pa ̲request ̲output)
output)
* *
(frame out) cslp ̲request ̲output pa ̲request ̲output
(last frame) (last frame)
ok (cslp ̲request ̲
output)
ok (cslp ̲request ̲
input)(E1 trans ack)
cslp ̲request ̲input
ok (pa ̲request ̲output)
FIGURE 4.2.3.1.1-2…01…PC TO CAMPS/SCARS COMPLETED TRANSMISSION
4.2.3.1.2 F̲r̲a̲m̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲
a) O̲u̲t̲g̲o̲i̲n̲g̲ ̲B̲l̲o̲c̲k̲s̲
For outgoing transactions, CSPA supplies a header
to each block of data.
This header consists of a Line Control Field and
a Message Control Field (cf. section 2.1.3.1).
The header and data block form a frame information
field which is transferred to CSLP on request.
The Line Control Field contains dummy information
(is not used).
The content and format of the Message Control Field
is described in Figure 2.1.3.1-1. The content of
the field
- TYP
is transferred from the corresponding field of
the global transaction descriptor pc ̲trans(cf.
4.1.4.2b)).
The content of the field
- PRC
is the converted value of the corresponding field
in pc ̲trans. Conversion is done according to 2.2.2.7
c).
b) I̲n̲c̲o̲m̲i̲n̲g̲ ̲B̲l̲o̲c̲k̲s̲
For incoming transactions, CSPA validates and removes
the frame header (Line Control Field and Message
Control Field).
If first block of a transaction, the fields:
- TYP
- PRC
- CLS
of the global transaction descriptor pc ̲trans are
loaded as follows:
- TYP is TYP of Message Control Field
- PRC is converted value of PRC of Message
Control Field
- CLS is CLS of E1 format line C of data block.
Validation of Message Control Field is as follows:
1) I̲F̲L̲ ̲-̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲F̲i̲e̲l̲d̲ ̲L̲e̲n̲g̲t̲h̲
Check that value is in legal range.
2) B̲S̲N̲ ̲-̲ ̲B̲l̲o̲c̲k̲ ̲S̲e̲q̲u̲e̲n̲c̲e̲ ̲N̲u̲m̲b̲e̲r̲
F̲i̲r̲s̲t̲ ̲f̲r̲a̲m̲e̲ of transaction:
check that value is 1
o̲t̲h̲e̲r̲w̲i̲s̲e̲:
check that value equals BSN of previously received
frame + 1
3) B̲T̲Y̲ ̲-̲ ̲B̲l̲o̲c̲k̲ ̲T̲y̲p̲e̲
Check that value is in legal range.
F̲i̲r̲s̲t̲ ̲f̲r̲a̲m̲e̲ of transaction:
check that value is A or D
o̲t̲h̲e̲r̲w̲i̲s̲e̲:
check that value is B or C
4) P̲R̲C̲ ̲-̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲P̲r̲e̲c̲e̲d̲e̲n̲c̲e̲
F̲i̲r̲s̲t̲ ̲f̲r̲a̲m̲e̲ of transaction:
check that value is in legal range
o̲t̲h̲e̲r̲w̲i̲s̲e̲:
check that value is in the same for all frames
of transaction
5) T̲Y̲P̲ ̲-̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲t̲y̲p̲e̲
F̲i̲r̲s̲t̲ ̲f̲r̲a̲m̲e̲ of transaction:
check that value is in legal range
o̲t̲h̲e̲r̲w̲i̲s̲e̲:
check that value is the same for all frames of
transaction
4.2.3.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
a) S̲t̲a̲t̲i̲c̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The CSPA package is organized in three modules:
1) CSPA ̲MAIN ̲CONTROL
implementing main control and initialization.
2) CSPA ̲OPERATION
implementing the transfer functions and frame
control.
3) CSPA ̲CSLP ̲COMMUNICATION
implementing the communication to/from CSLP.
Figure 4.2.3.2-1 shows an overview of module contents.
M̲O̲D̲U̲L̲E̲S̲ P̲R̲O̲C̲E̲D̲U̲R̲E̲S̲
CSPA ̲MAIN ̲CONTROL cspa
init ̲cspa
new ̲cspa ̲command
terminate ̲cspa ̲op
cspa ̲system ̲error
CSPA ̲OPERATION cspa ̲logon
cspa ̲logoff
cspa ̲request ̲output
cspa ̲request ̲input
cspa ̲send ̲ack
cspa ̲cancel
make ̲frame
get ̲frame
transmit ̲preempt
init ̲trans ̲descs
close ̲link
CSPA ̲CSLP ̲COMMUNICATION handle ̲cslp ̲response
send ̲cslp ̲request ̲input
send ̲cslp ̲request ̲output
send ̲and ̲wait ̲ctl ̲cslp
cancel ̲cslp ̲command
FIGURE 4.2.3.2-1
CSPA PACKAGE SOFTWARE
b) D̲y̲n̲a̲m̲i̲c̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The CSPA package is implemented as a single process.
The CSPA process is driven by external events of
the following kind:
1) command requested from TRC
2) response to command sent from CSPA to CSLP
The CSPA process waits for an external event. When
one arrives, a procedure is called for taking appropriate
action and after completion control is returned
to the general waiting point.
Figure 4.2.3.2-2 depicts the procedure call structure.
4.2.3.3 P̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
Figure 4.2.3.3-1 gives an overview of the CSPA package
data. The figure summarises the variables by name,
details are explained below.
CSPA data declarations:
a) c̲s̲p̲a̲ ̲o̲p̲e̲r̲a̲t̲i̲o̲n̲s̲
TYPE
cspa ̲op ̲desc = "cspa operation descriptor
RECORD
state: cspa ̲op ̲state;
event ̲id: integer; "to be returned
in response
com: pa ̲command; "command buffer
from TRC
END;
cspa ̲op ̲state = "state of pending operation
( cspa ̲op ̲none, "no pending command
cspa ̲op ̲wait ̲start, "not started
cspa ̲op ̲wait ̲cslp ̲response "cslp request sent
);
VAR
cspa ̲op ̲tab: "table of cspa operation descriptors
ARRAY( pa ̲command ̲id ) OF cspa ̲op ̲desc;
cspa ̲resp: pa ̲response;
FIGURE 4.2.3.2-2
CSPA PROCEDURE CALL STRUCTURE
FIGURE 4.2.3.3-1
CSPA DATA OVERVIEW
b) t̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲s̲
TYPE
cspa ̲trans ̲desc = "describes current state of transaction
RECORD
state: cspa ̲transaction ̲state;
sci ̲tsn: ARRAY(0..5) OF char; "sci & tsn
of trans
mcf: cspa ̲mes ̲ctl ̲fld; "message contr
field
END;
cspa ̲transaction ̲state = "state of transaction processing
( no ̲trans,
trans ̲in,
wait ̲ack,
sending ̲ack,
trans ̲out
);
cspa ̲frame ̲info ̲field = "level 3 frame info field
RECORD
lcf: integer; "line control field
"(not used)
mcf: cspa ̲mes ̲ctl ̲fld; "message control
field
text: ARRAY(0..scamps ̲frame ̲limit-9) OF char;
END;
cspa ̲mes ̲ctl ̲fld = "message control field
RECORD
ifl: byte; "frame ̲info ̲field length (9..128)
bsn: byte; "block sequence number (1..100)
spare: char; "not used
bty: char; "block type (A,B,C,D)
prc: char; "precedence (1,2,3,4,5,6)
typ: char; "(C,D,E,F,G,M,N,O,P,Q,R)
END;
VAR
cspa ̲trans ̲in, "incoming transaction
cspa ̲trans ̲out, "outgoing transaction
: cspa ̲trans ̲desc;
c) c̲s̲l̲p̲ ̲o̲p̲e̲r̲a̲t̲i̲o̲n̲s̲
TYPE
io ̲op ̲cslp ̲desc = "descriptor of operation to/from
cslp
RECORD
state: op ̲cslp ̲state;
com: cslp ̲command;
resp: cslp ̲response;
bytes: integer; "bytes in buf
buf: address; of to/from ̲cslp ̲buf
END;
ctl ̲op ̲cslp ̲desc = "descriptor of control op to cslp
RECORD
state: op ̲cslp ̲state;
com: cslp ̲command;
resp: cslp ̲response;
END;
op ̲cslp ̲state = "state of cslp operation
( op ̲cslp ̲none, "no pending operation
op ̲cslp ̲wait ̲response, "pending operation
op ̲cslp ̲got ̲response "response received
);
VAR
cspa ̲from ̲cslp, "describes input
from CSLP
cspa ̲to ̲cslp "describes output
to CSLP
: io ̲op ̲cslp ̲desc;
cspa ̲ctl ̲cslp "describes control
op to cslp
: ctl ̲op ̲cslp ̲desc;
CONST
delay = 2 min; "timeout value in
waitanswer
4.2.3.4 P̲a̲c̲k̲a̲g̲e̲ ̲D̲e̲s̲i̲g̲n̲
PDL descriptions of package procedures are given in
appendix 2.
4.2.3.5 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
CSPA applies the following interfaces:
a) P̲A̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Receives commands:
pa ̲logon
pa ̲logoff
pa ̲request ̲input
pa ̲request ̲output
pa ̲send ̲ack
pa ̲cancel
b) C̲S̲L̲P̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Sends commands:
cslp ̲reopen
cslp ̲set ̲up ̲lines
cslp ̲set ̲up ̲link
cslp ̲request ̲input
cslp ̲request ̲output
cslp ̲cancel ̲command
cslp ̲close
4.2.4 C̲A̲M̲P̲S̲/̲S̲C̲A̲R̲S̲ ̲L̲o̲w̲ ̲L̲e̲v̲e̲l̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲ ̲(̲C̲S̲L̲P̲)̲
See Reference 15, X25 LAP (CAMPS) Product Specification
4.2.5 C̲C̲I̲S̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲A̲d̲a̲p̲t̲e̲r̲ ̲(̲C̲P̲A̲)̲
CPA is responsible for the DINDAC level segment control
functions and transfers blocks of data to/from the
pc ̲trans buffer on request from TRC.
4.2.5.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
CPA performs the external functions specified in the
PA interface (cf. section 4.1.5.3) and applies functions
on the CLP interface (cf. 4.1.5.5).
The CPA functional responsibilities are grouped as
follows:
- Transfer of blocks
- Segmentation and control
- DINDAC service messages
4.2.5.1.1 T̲r̲a̲n̲s̲f̲e̲r̲ ̲o̲f̲ ̲B̲l̲o̲c̲k̲s̲
CPA transfers blocks of data to/from the global transaction
buffer pc ̲trans and requests corresponding segments
to be transmitted/received to/from CCIS by CLP.
Figures 4.2.5.1.1-1 and -2 show the control flow involved
in blockwise transmission of a transaction from PC
to CCIS including acknowledgement.
Figures 4.2.5.1.1-3 and -4 show the control flow involved
in blockwise reception of a transaction from CCIS including
acknowledgement.
T̲R̲C̲ C̲P̲A̲ C̲L̲P̲ C̲C̲I̲S̲ ̲(̲G̲R̲T̲S̲)̲
pa ̲request ̲ clp ̲request
input input
----------------------------------------------------------------------
pa ̲request ̲ clp ̲request ̲ break
output (block) output (segment)
transmit data
ETB
(subsegment)
transmit data
* *
ETX
(last subsegment)
ok (pa ̲request ok (clp ̲request ̲ transmit data
̲output) output)
* *
pa ̲request ̲ clp ̲request ̲ ETB
output output (subsegment)
(last block) (last segment)
transmit data
ETX
(last subsegment)
ok (clp ̲request ̲ ETX
input) (super ack/nak)
ok (clp ̲request ̲
output)
clp ̲request ̲input ack ̲no ̲request
ok/error (pa ̲
request ̲output)
FIGURE 4.2.5.1.1-1…01…PC TO CCIS COMPLETED TRANSMISSION
T̲R̲C̲ C̲P̲A̲ C̲L̲P̲ C̲C̲I̲S̲ ̲(̲G̲R̲T̲S̲)̲
pa ̲request ̲ clp ̲request
input input
----------------------------------------------------------------------
pa ̲request ̲ clp ̲request ̲ break
output (block) output
(segment)
transmit data
ETB
(subsegment)
transmit data
ETX
(last subsegment)
ok (clp ̲request ̲ ETX
input) (super nak)
ok (clp ̲request ̲
output)
clp ̲request ̲input ack ̲no ̲request
error (pa ̲request
̲output)
FIGURE 4.2.5.1.1-2…01…PC TO CCIS TRANSMISSION INTERRUPTED BY CCIS
T̲R̲C̲ C̲P̲A̲ C̲L̲P̲ C̲C̲I̲S̲ ̲(̲G̲R̲T̲S̲)̲
pa ̲request ̲ clp ̲request
input input
-----------------------------------------------------------------------
ETB (subsegment)
ack ̲no ̲request
* * * *
(block) ok (pa ̲request ̲ ok (clp ̲request ETX
input)(segment) input) (last subsegment)
* *
pa ̲request ̲ clp ̲request ̲ ack ̲no ̲request ETB
input input (subsegment)
ack ̲no ̲request
* * * *
ok(clp ̲request ̲ ETX
(last segment) input) (last subsegment)
clp ̲request ̲input ack ̲no ̲request
(last block) ok (pa ̲request ̲ transmit data
input)
pa ̲request ̲ clp ̲request ̲ ETX
input output(super ack) (super ack)
*
ok (clp ̲request ̲
output)
pa ̲send ̲ack clp ̲request ̲ break
output (E1 trans
ack) transmit data
ETX
(last subsegment)
ok (clp ̲request ̲ ETX
input) (super ack)
ok (clp ̲request ̲
output)
clp ̲request ̲input ack ̲no ̲request
ok (pa ̲send ̲ack)
̲output)
* "transmit data" or "subsegment"
FIGURE 4.2.5.1.1-3…01…CCIS TO PC COMPLETED TRANSMISSION
T̲R̲C̲ C̲P̲A̲ C̲L̲P̲ C̲C̲I̲S̲ ̲(̲G̲R̲T̲S̲)̲
pa ̲request ̲ clp ̲request ̲
input input
-----------------------------------------------------------------------
ETB (subsegment)
ack ̲no ̲request
* *
error (pa ̲ ok (clp ̲request ETX
request ̲input) input) (last subsegment)
(bad segment)
pa ̲cancel clp ̲request ̲
input
clp ̲request ̲ break
output (super nak)
transmit data
ETX
(super ack)
*
ok (clp ̲request ̲
output)
ok (pa ̲cancel)
pa ̲send ̲input
* "transmit data" if "super nak" contains "next ̲to ̲transmit" = PC
"subsegment" (possibly * NOMSG) if "super nak" contains
"next ̲to ̲transmit" = CCIS
FIGURE 4.2.5.1.1-4…01…CCIS TO PC TRANSMISSION INTERRUPTED BY PC
4.2.5.1.2 S̲e̲g̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲
a) O̲u̲t̲g̲o̲i̲n̲g̲ ̲B̲l̲o̲c̲k̲s̲
For outgoing transactions, CPA supplies a DINDAC
segment header to each block.
The content and format of this segment header is
described in Figure 2.1.4.1-1.
The contents of fields:
- TYP
- PRC
- CLS
are transferred from corresponding fields of the
common transaction descriptor pc ̲trans (cf. 4.1.4.2
b)).
Field KEY is as follows:
If system ̲mode = test ̲mode, KEY = …08…KEN …08…
otherwise KEY = …08…PCTHDL …08….
Field SUB is as follows:
If system ̲mode = test ̲mode, SUB = 'QQ'
otherwise SUB = 'AA'
b) I̲n̲c̲o̲m̲i̲n̲g̲ ̲B̲l̲o̲c̲k̲s̲
For incoming transactions, CPA validates and removes
the DINDAC segment header.
If first segment of transaction, the contents of
fields:
- TYP
- PRC
- CLS
are transferred to corresponding fields of the
common transaction descriptor pc ̲trans (cf. 4.1.4.2b)).
Validation of DINDAC segment header fields is as
follows:
1) C̲D̲N̲ ̲-̲ ̲C̲h̲a̲n̲n̲e̲l̲ ̲D̲e̲s̲i̲g̲n̲a̲t̲o̲r̲
F̲i̲r̲s̲t̲ ̲s̲e̲g̲m̲e̲n̲t̲ of transaction:
check that value is 3 letters, and equals corresponding
SCI value supplied by operator at logon.
Check that value is the same for all segments
of a transaction.
2) C̲S̲N̲ ̲-̲ ̲C̲h̲a̲n̲n̲e̲l̲ ̲S̲e̲q̲u̲e̲n̲c̲e̲ ̲N̲u̲m̲b̲e̲r̲
F̲i̲r̲s̲t̲ ̲s̲e̲g̲m̲e̲n̲t̲ of transaction:
check that value is in legal range and equals
CSN of previously received transaction + 1
(wrap around to 000).
If first transaction after logon PC sets incoming
CSN to value received.
Check that value is the same for all segments
of a transaction.
3) S̲E̲G̲ ̲-̲ ̲S̲e̲g̲m̲e̲n̲t̲ ̲N̲u̲m̲b̲e̲r̲
Check that value is in legal range.
F̲i̲r̲s̲t̲ ̲s̲e̲g̲m̲e̲n̲t̲ of transaction:
check that value is 1.
O̲t̲h̲e̲r̲ ̲s̲e̲g̲m̲e̲n̲t̲:
check that value equals SEG of previously received
segment + 1.
4) E̲O̲T̲ ̲-̲ ̲E̲n̲d̲ ̲o̲f̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲
Check that value is in legal range.
5) P̲R̲C̲ ̲-̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲P̲r̲e̲c̲e̲d̲e̲n̲c̲e̲
F̲i̲r̲s̲t̲ ̲s̲e̲g̲m̲e̲n̲t̲ of transaction:
check that value is in legal range.
Check that value is the same for all segments
of a transaction.
6) C̲L̲S̲ ̲-̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲C̲l̲a̲s̲s̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
F̲i̲r̲s̲t̲ ̲s̲e̲g̲m̲e̲n̲t̲ of transaction:
check that value is in legal range.
Check that value is the same for all segments
of a transaction.
7) T̲Y̲P̲ ̲-̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲T̲y̲p̲e̲
F̲i̲r̲s̲t̲ ̲s̲e̲g̲m̲e̲n̲t̲ of transaction:
check that value is in legal range.
Check that value is the same for all segments
of a transaction.
8) K̲E̲Y̲ ̲-̲ ̲P̲r̲o̲g̲r̲a̲m̲ ̲K̲e̲y̲w̲o̲r̲d̲
Check that value is the same for all segments
of a transaction.
9) S̲U̲B̲ ̲-̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲S̲u̲b̲j̲e̲c̲t̲ ̲C̲o̲d̲e̲
Check that value is the same for all segments
of a transaction.
10) P̲R̲N̲ ̲-̲ ̲P̲r̲e̲c̲e̲d̲e̲n̲c̲e̲ ̲o̲f̲ ̲N̲e̲x̲t̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲
Check that value is in legal range.
11) P̲S̲N̲ ̲-̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲S̲e̲q̲u̲e̲n̲c̲e̲ ̲N̲u̲m̲b̲e̲r̲
No check performed.
12) S̲I̲Z̲ ̲-̲ ̲L̲e̲n̲g̲t̲h̲ ̲o̲f̲ ̲S̲e̲g̲m̲e̲n̲t̲
Check that value is in legal range.
4.2.5.1.3 D̲I̲N̲D̲A̲C̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Service messages are exchanged between CPA and the
DINDAC level protocol of the CCIS end system.
The service messages handled by CPA are:
- super ̲ack
- super ̲nak
- bust
- no ̲msg
Service messages are distinguished from data segments
by the following 3 character service message prefix:
…0c…$$…0c… *
a) S̲u̲p̲e̲r̲ ̲a̲c̲k̲
The super ̲ack is used by the r̲e̲c̲e̲i̲v̲e̲r̲ of a
transaction to communicate a positive acknowledgement
of a complete transaction.
The following figure shows the layout of the super
̲ack service message.
F̲I̲E̲L̲D̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲B̲Y̲T̲E̲S̲ ̲ ̲ ̲ ̲ ̲ ̲T̲Y̲P̲E̲ ̲ ̲ ̲ ̲ ̲V̲A̲L̲U̲E̲
̲ ̲
…0c…$$…0c… SERVICE PREFIX 3 char *
SUPER ̲ACK ̲ID 1 char +
CDN 3 char
CSN 3 char 000..999
fill 1 char blank
NEXT ̲TO ̲TRANSMIT 1 char 0..1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Figure 4.2.5.1.3-1 SUPER ̲ACK FORMAT
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The fields are interpreted as follows:
1) CDN
Channel designator. Three letter code identifying
the channel
2) CSN
Channel sequence number. CDN, CSN identifies
the transaction being acknowledged. These two
fields are identical to the corresponding fields
of the segment header of the transaction being
acknowledged.
3) NEXT ̲TO ̲TRANSMIT
This field indicates whether PC or CCIS shall
be the next to transmit. Values are:
0 : receiver of super ack shall transmit next.
1 : sender of super ack shall transmit next.
When CPA s̲e̲n̲d̲s̲ a super ̲ack NEXT ̲TO ̲TRANSMIT=1
if CPA has a queued output request of precedence
not less than the precedence of waiting output
in CCIS if any, otherwise
NEXT ̲TO ̲TRANSMIT = 0.
If CPA r̲e̲c̲e̲i̲v̲e̲s̲ a super ̲ack with NEXT ̲TO ̲TRANSMIT
= 1 indicating that CCIS is the next to transmit,
PC will queue any output request to allow input
of transaction from CCIS.
If CPA r̲e̲c̲e̲i̲v̲e̲s̲ a super ̲ack with
NEXT ̲TO ̲TRANSMIT = 0 indicating that PC is
the next to transmit and there is no output
request ready, then PC will be ready to receive
a transaction from CCIS.
b) S̲u̲p̲e̲r̲ ̲n̲a̲k̲
The super ̲nak is used to communicate a negative
acknowledgement of an i̲n̲c̲o̲m̲i̲n̲g̲ transaction
The super ̲nak may be sent whenever a segment of
a transaction has been received the effect being
the cancellation of the entire transaction.
CPA will s̲e̲n̲d̲ a super ̲nak in the following situations:
- When an error in the segment header is detected.
- When an output request of precedence flash
or superflash is queued and incoming transaction
is of lower precedence.(override)
- When a bust service message has been received.
CPA will r̲e̲c̲e̲i̲v̲e̲ a super ̲nak in the following situations:
- When a segment is sent with an error in the
segment header.
- When CCIS has a high precedence transaction
to send.(override).
- When CPA has sent a bust service message.
The following figure shows the layout of the super
̲nak service message.
F̲I̲E̲L̲D̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲B̲Y̲T̲E̲S̲ ̲ ̲ ̲ ̲T̲Y̲P̲E̲ ̲ ̲ ̲ ̲V̲A̲L̲U̲E̲
̲ ̲ ̲
…0c…$$…0c… SERVICE ̲PREFIX 3 char *
SUPER ̲NAK ̲ID 1 char -
CDN 3 char
CSN 3 char 000..999
NAK ̲REASON 1 char
NEXT ̲TO ̲TRANSMIT 1 char 0..1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲
Figure 4.2.5.1.3-2 SUPER ̲NAK FORMAT
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲
The fields are interpreted as follows:
1) CDN
Channel designator
2) CSN
Channel sequence number. Normally this is the
CSN of the transaction being nak'ed. Exceptions
depend on NAK ̲REASON.
3) NAK ̲REASON
This field identifies the reason for sending
the super ̲nak. Values to be sent and received
are:
V̲a̲l̲u̲e̲ M̲e̲a̲n̲i̲n̲g̲
1 i̲n̲v̲a̲l̲i̲d̲ ̲C̲D̲N̲. CSN of super ̲nak is
that of last transaction received
ok.
2 i̲n̲v̲a̲l̲i̲d̲ ̲C̲S̲N̲.̲ CSN of super ̲nak is
that of last transaction received
ok. Receiver of super ̲nak shall set
outgoing CSN to CSN of super ̲nak
+1.
3 i̲n̲v̲a̲l̲i̲d̲ ̲s̲e̲g̲m̲e̲n̲t̲ ̲n̲u̲m̲b̲e̲r̲
4 i̲n̲v̲a̲l̲i̲d̲ ̲p̲r̲e̲c̲e̲d̲e̲n̲c̲e̲
5 i̲n̲v̲a̲l̲i̲d̲ ̲c̲l̲a̲s̲s̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
6 i̲n̲v̲a̲l̲i̲d̲ ̲t̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲t̲y̲p̲e̲
7 i̲n̲v̲a̲l̲i̲d̲ ̲k̲e̲y̲w̲o̲r̲d̲
8 b̲u̲s̲t̲ ̲r̲e̲s̲p̲o̲n̲s̲e̲ Sent when a bust message
is received.
9 s̲t̲o̲p̲ ̲t̲r̲a̲n̲s̲m̲i̲t̲t̲i̲n̲g̲ Sent in order
to override an incoming transaction.
A t̲h̲r̲o̲t̲t̲l̲e̲ ̲t̲r̲a̲n̲s̲m̲i̲t̲ ̲l̲i̲n̲e̲. Stop transmit,
continue to receive. Not sent by
PC. If received, system is closed
down.
B t̲e̲x̲t̲ ̲e̲r̲r̲o̲r̲. Sent by PC on detection
of invalid SUB, PRN, SIZ, or EOT
field.
C i̲n̲v̲a̲l̲i̲d̲ ̲m̲u̲l̲t̲i̲p̲l̲e̲ ̲k̲e̲y̲w̲o̲r̲d̲.
not used
4) NEXT ̲TO ̲TRANSMIT
This field indicates whether PC or CCIS shall
be the next to transmit. Values are:
0: receiver of Super ̲nak shall transmit
next
1: sender of super ̲nak shall transmit
next
When CPA s̲e̲n̲d̲s̲ a super ̲nak NEXT ̲TO ̲TRANSMIT
= 1 if CPA has a queued output request of precedence
not less than the precedence of waiting output
in CCIS if any, otherwise NEXT ̲
TO ̲TRANSMIT = 0.
If CPA r̲e̲c̲e̲i̲v̲e̲s̲ a super ̲nak with NEXT ̲TO ̲TRANSMIT
= 1 indicating that CCIS is the next to transmit.
PC will queue any output request to allow input
of transaction from CCIS.
If CPA r̲e̲c̲e̲i̲v̲e̲s̲ a super ̲nak with NEXT ̲TO ̲TRANSMIT
= 0 indicating that PC is the next to transmit
and there is no output request ready. then
PC will be ready to receive a transaction from
CCIS.
c) B̲U̲S̲T̲
The bust message is used by the s̲e̲n̲d̲e̲r̲ of a transaction
in order to cancel the entire transaction.
The receiver of the bust message shall set incoming
CSN to that of last transaction received ok. Receiver
responds to bust by sending super ̲nak with NAK
̲REASON = bust ̲response.
A bust message may not be sent after the last segment
has been transmitted.
The following figure shows the layout of the bust
service message.
F̲I̲E̲L̲D̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲B̲Y̲T̲E̲S̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲T̲Y̲P̲E̲ ̲ ̲ ̲ ̲
̲V̲A̲L̲U̲E̲
…0c…$$…0c… SERVICE ̲PREFIX 3 char
*
BUST ̲ID 4 char
BUST
fill 15 char
PRN 1 char
0..5
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Figure 4.2.5.1.3-3 BUST FORMAT
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
The PRN field is used to communicate the precedence
of the next transaction to be sent, if any.
PRN = O indicates no message to send
CPA will send a bust message when an error has
been detected in an outgoing transaction and the
last segment has not been transmitted.
CPA will accept a bust message before the last
segment of a transaction has been received.
d) N̲o̲ ̲M̲e̲s̲s̲a̲g̲e̲
The no ̲message service message is sent when the
other side expects a message but there is no longer
a message to send from the first side. The other
side expects a message when:
1) The first side has indicated the desire to
send a message by setting PRN field (precedence
of next message) to a value different from
0 in the last message transmitted.
2) The other side has responded with a super ̲ack
or super ̲nak containing NEXT ̲TO ̲TRANSMIT field
equal first side.
CPA will send a no ̲message if the situation mentioned
above with PC as first side occurs.
CCIS will also send a no ̲message if only situation
2) occurs with CCIS as first side.
CPA will accept a no ̲message from CCIS and CLP
will be triggered to send an 'ack ̲no ̲request'.
The following figure shows the layout of the no
̲msg service message.
F̲I̲E̲L̲D̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲B̲Y̲T̲E̲S̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲T̲Y̲P̲E̲ ̲ ̲ ̲ ̲
̲V̲A̲L̲U̲E̲
…0c…$$…0c… SERVICE ̲PREFIX 3 char
*
NO ̲MSG ̲ID 5 char
NOMSG
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Figure 4.2.5.1.3-4 NO ̲MSG FORMAT
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
4.2.5.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
a) S̲t̲a̲t̲i̲c̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The CPA package is organized in three modules:
1) CPA ̲MAIN ̲CONTROL
implementing main control and initialization.
2) CPA ̲OPERATION
implementing the transfer functions and segment
control.
3) CPA ̲CLP ̲COMMUNICATION
implementing the communication to/from CLP.
Figure 4.2.5.2-1 shows an overview of module contents.
M̲O̲D̲U̲L̲E̲S̲ P̲R̲O̲C̲E̲D̲U̲R̲E̲S̲
CPA ̲MAIN ̲CONTROL cpa
init ̲cpa
new ̲cpa ̲command
schedule ̲activity
decide ̲override
terminate ̲cpa ̲op
cpa ̲system ̲error
decide ̲next ̲to ̲transmit
CPA ̲OPERATION cpa ̲logon
cpa ̲logoff
cpa ̲request ̲output
cpa ̲request ̲input
cpa ̲send ̲ack
cpa ̲cancel
make ̲segment
get ̲segment
init ̲trans ̲descs
CPA ̲CLP ̲COMMUNICATION handle ̲clp ̲response
analyze ̲clp ̲input
send ̲clp ̲request ̲input
send ̲clp ̲request ̲output
send ̲and ̲wait ̲to ̲clp
transmit ̲super ̲ack
transmit ̲super ̲nak
transmit ̲bust
cancel ̲clp ̲command
FIGURE 4.2.5.2-1
CPA PACKAGE SOFTWARE
b) D̲y̲n̲a̲m̲i̲c̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The CPA package is implemented as a single process.
The CPA process is driven by external events of
the following kind:
1) command requested from TRC
2) response to command sent from CPA to CLP
The CPA process waits for an external event. When
one arrives, a procedure is called for taking appropriate
action and after completion control is returned
to the general waiting point.
Figure 4.2.5.2-2 depicts the procedure call structure.
4.2.5.3 P̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
Figure 4.2.5.3-1 gives an overview of the CPA package
data. The figure summarizes the variables by name,
details are explained below.
CPA data declarations:
a) c̲p̲a̲ ̲o̲p̲e̲r̲a̲t̲i̲o̲n̲s̲
TYPE
cpa ̲op ̲desc = " cpa operation descriptor
RECORD
state: cpa ̲op ̲state;
event ̲id: integer; "to be returned in
response
com: pa ̲command; "command buffer from
TRC
END;
cpa ̲op ̲state = "state of pending operation
( cpa ̲op ̲none, "no pending command
cpa ̲op ̲wait ̲start, "not started (link
busy)
cpa ̲op ̲wait ̲clp ̲response "clp request sent
);
VAR
cpa ̲op ̲tab: "table of cpa operation descriptors
ARRAY( pa ̲command ̲id ) OF cpa ̲op ̲desc;
cpa ̲resp: pa ̲response;
FIGURE 4.2.5.2-2
CPA PROCEDURE CALL STRUCTURE
FIGURE 4.2.5.3-1…01…CPA DATA OVERVIEW
b) t̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲s̲
TYPE
cpa ̲transaction ̲state = "state of transaction processing
( no ̲trans,
trans ̲in,
wait ̲ack,
sending ̲ack,
trans ̲out
);
cpa ̲trans ̲desc = "describe current state of transaction
RECORD
seg ̲head: cpa ̲segment ̲header;
csn ̲val: integer; "channel sequence num
0..999
old ̲csn ̲val: integer; "csn of previous transaction
seg ̲val: integer; "segment number 1..99
psn ̲val: integer; "process sequence num
0..999
siz ̲val: integer; "segment size in bytes
override: boolean; "true iff input to be
overridden
nak ̲reason: integer; "error code to send in
super ̲nak
END;
cpa ̲segment = "transaction segment
RECORD
head: cpa ̲segment ̲header;
text: ARRAY(0..ccis ̲segment ̲limit-size(head)+1)
OF char;
END;
cpa ̲segment ̲header = "dindac segment header
RECORD "range of values;
cdn: ARRAY(0..2) OF char; "alpha
csn: ARRAY(0..2) OF char; "(000..999)
seg: ARRAY(0..1) OF char; "(01..99)
eot: char; "(T,space)
prc: char; "(Y,Z,O,P,R)
cls: char; "(T,S,C,R,U)
typ: char; "(C,D,E,F,G,M,N,O,P,Q,R)
key: ARRAY(0..7) OF char; "
sub: ARRAY(0..1) OF char; "
prn: char; "(0..5)
spare:char; "not used
psn: ARRAY(0..5) OF char; "(000001..999999)
siz: ARRAY(0..3) OF char; "(0035..ccis ̲segment
̲limit)
END;
ntt ̲type = "next ̲to ̲transmit values"
(undef., "both sides may transmit
pc, "pc is next to transmit
dindac); "dindac is next to transmit
VAR
next ̲to ̲transmit: ntt ̲type;
VAR
cpa ̲state: cpa ̲transaction ̲state;
cpa ̲trans ̲in, "incoming transaction
cpa ̲trans-out "outgoing transaction
: cpa ̲trans ̲desc;
c) c̲l̲p̲ ̲o̲p̲e̲r̲a̲t̲i̲o̲n̲s̲
TYPE
io ̲op ̲clp ̲desc = "descriptor of operation to/from
clp
RECORD
state: op ̲clp ̲state;
event ̲id: event;
com: clp ̲command;
resp: clp ̲response;
bytes: 0 .. ccis ̲segment ̲limit - 1; "bytes
in buf
buf: address; "of to/from ̲clp ̲buf;
mess ̲type: cpa ̲message ̲type;
clp ̲action integer;
END;
ctl ̲op ̲clp ̲desc = "descriptor of control operation
to clp
RECORD
state: op ̲clp ̲state;
com: clp ̲command;
resp: clp ̲response;
END;
op ̲clp ̲state = "state of clp operation
( op ̲clp ̲none, "no pending operation
op ̲clp ̲wait ̲response, "pending operation
op ̲clp ̲got ̲response "response received
);
VAR
cpa ̲from ̲clp, "describes input from
CLP
cpa ̲to ̲clp "describes output
from CLP
: io ̲op ̲clp ̲desc;
cpa ̲ctl ̲clp "describes control
op to clp
: ctl ̲op ̲clp ̲desc;
d) s̲e̲r̲v̲i̲c̲e̲ ̲m̲e̲s̲s̲a̲g̲e̲s̲
cpa ̲message ̲type = "message types exchanged with
DINDAC
( cpa ̲data ̲segment,
…0c…$$…0c… cpa ̲no ̲msg, " * NOMSG
…0c…$$…0c… cpa ̲bust, " * BUST
…0c…$$…0c… cpa ̲super ̲ack, " * +
…0c…$$…0c… cpa ̲super ̲nak, " * -
);
cpa ̲super ̲ack ̲format =
RECORD
…0c…$$…0c… pref: ARRAY(0..2) OF char; " *
super ̲ack ̲id: char; " +
cdn: ARRAY(0..2) OF char;
csn: ARRAY(0..2) OF char;
fill: char; "not
used
next ̲to ̲transmit: char;
END;
cpa ̲super ̲nak ̲format =
RECORD
…0c…$$…0c… pref: ARRAY(0..2) OF char; " *
super ̲nak ̲id: char; " -
cdn: ARRAY(0..2) OF char;
csn: ARRAY(0..2) OF char;
nak ̲reason: char;
next ̲to ̲transmit: char;
END;
cpa ̲bust ̲format =
RECORD
…0c…$$…0c… pref: ARRAY(0..2) OF char; " *
bust ̲id: ARRAY(0..3) OF char; "BUST
fill: ARRAY(0..14) OF char; "not
used
prn: char;
END;
cpa ̲no ̲msg ̲format =
RECORD
…0c…$$…0c… pref: ARRAY(0..2) OF char; " *
no ̲msg ̲id: ARRAY(0..4) OF char; "NOMSG
END;
CONST
delay = 2 min; "timeout value in waitanswer
"clp completion code tested for in request ̲output
resp:
clp ̲link ̲busy = #D2 + clp ̲id;
4.2.5.4 P̲a̲c̲k̲a̲g̲e̲ ̲D̲e̲s̲i̲g̲n̲
PDL descriptions of package procedures are given in
appendix 3.
4.2.5.5 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
CPA applies the following interfaces:
a) P̲A̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Receives commands:
pa ̲logon
pa ̲logoff
pa ̲request ̲input
pa ̲request ̲output
pa ̲send ̲ack
pa ̲cancel
b) C̲L̲P̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Sends commands:
clp ̲open ̲link
clp ̲close ̲link
clp ̲request ̲input
clp ̲request ̲output
clp ̲cancel ̲command
