top - download
⟦b03bc51cb⟧ Wang Wps File
Length: 96779 (0x17a0b)
Types: Wang Wps File
Notes: CPS/SDS/033
Names: »1995A «
Derivation
└─⟦82445de73⟧ Bits:30006087 8" Wang WCS floppy, CR 0139A
└─ ⟦this⟧ »1995A «
WangText
…00……00……00……00……00…I…0a……00……00…I…0b…I…01…I…02…H…08…H…0f…H G…09…G…0f…G…06…F…0b…F…01…F…07…E…0d…D
C…0a…C…00…C…05…B…0c…B
A…0b…A…02…A…07…@…0c…@…0d…@ @…06…@…07…?…0e…?…0f…? ?…05…?…07…>…08…>…0d…>
>…07…=…0b…=…0e…=…02…=…06…<…0a…<…0d…<…01…<…06…;…86…1 …02… …02… …02…
…02…CPS/SDS/033
…02…831101 …02……02…
TRAFFIC HANDLING
DETAILED DESIGN SPECIFICATION…02…ISSUE 1 …02…CAMPS
4.2.5 I̲N̲C̲O̲M̲I̲N̲G̲ ̲T̲R̲A̲N̲S̲P̲O̲R̲T̲ ̲S̲U̲B̲P̲A̲C̲K̲A̲G̲E̲
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̲
The Incoming Transport Subpackage (ITS) supplies the
modules for handling of the incoming traffic of messages.
The ITS receives the message lines through the IOC
and stores them into the External Message Format (EMF).
When a complete message has been received, it is forwarded
to the Analysis Process through the Analysis Queue
(ANQ or OAQ).
The ITS supports the following types of incoming transport
subprocesses:
- TRC/POINT TO POINT
- NICS TARE
- SCARS/CCIS
- PTR.
- OCR
Messages from the first four types of subprocesses
are forwarded to the Analysis Process (AAS) contained
in THP and described in this document.
Messages from the OCR are forwarded to the Analysis
Process contained in TEP.
Each transport subprocess has its own ITS-function
which is running independent of the other subprocesses
(Ref.section 4.2.3).
The functional components of the ITS are divided into
the following main groups:
- Incoming Traffic Control
- Incoming Message Handling
- Error Handling
- Message Line Detection
The functional components mentioned above are described
in the following sections and depicted in figure 4.2.5-1
to 4.2.5-5.
Figure 4.2.5-1 to 4.2.5-5
4.2.5.1.1 I̲n̲c̲o̲m̲i̲n̲g̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Incoming Traffic Control takes care of the functions
which shall be executed when an operation is received
from the Transport Control (TCS) within the subprocess.
The following functions are included:
a) S̲t̲a̲r̲t̲ ̲U̲p̲
This operation will make the Incoming Transport
initiate transfer of message lines from IOC.
b) S̲t̲o̲p̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲
The transfer of message lines from the IOC is immediately
stopped.
No message lines are received before a start up
operation has been received.
c) C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲
Two Close Down functions exist:
1) I̲n̲i̲t̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲ makes the Incoming Transport
finish the message in progress, but no new
message transfer is initiated.
2) F̲i̲n̲a̲l̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲ works as a stop Transport.
4.2.5.1.2 I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲
The Message Handling contains the functions which are
related to the basic flow control of messages through
the Incoming Transport.
4.2.5.1.2.1 B̲u̲f̲f̲e̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲
This component includes the control logic for handling
of buffers assigned for reception of messages from
IOC and storage of a message in the External Message
Format. The structure of these functions is described
in section 4.2.5.3.
4.2.5.1.2.2 M̲e̲s̲s̲a̲g̲e̲ ̲S̲t̲a̲r̲t̲
The detection of a message start initiates creation
of a new CIF containing the fields of the External
Message Format. Also the error checking and detection
of message format lines are initiated.
a) T̲R̲C̲/̲P̲O̲I̲N̲T̲ ̲T̲O̲ ̲P̲O̲I̲N̲T̲
A new message is started when one of the following
sequences are detected in the LTUX:
VZCZC or ZCZC.
If the channel is closed a report is forwarded
to the supervisor.
If the channel is open the timer function related
to the supervision of the incoming traffic is cancelled.
The timer is located in the local timer table and
controls the transmission of "Self Addressed Channel
Check Message".
b) N̲I̲C̲S̲ ̲T̲A̲R̲E̲
A new message is started when the start of message
(SOM) block is received from IOC, i.e. the next
line received is considered as format line 1.
If the channel is closed a report is forwarded
to the supervisor.
If the channel is open the timer function related
to the supervision of the incoming traffic is cancelled.
c) S̲C̲A̲R̲S̲/̲C̲C̲I̲S̲
A new message is started when the start of message
block (SOM) is received from IOC. The SOM contains
the message type and precedence of the message.
These parameters are stored in the ACP127 Parameter
Field of the External Message Format.
When a message start is detected the timer function
related to supervision of the incoming traffic
is cancelled.
If the message type is equal to 'E' (Transaction
Acknowledgement) no CIF is created. In this case
an operation is transferred to Transport Control
(TCS), and the timer function (above) is updated.
d) P̲T̲R̲
A new message is detected when one of the following
sequences are detected in the LTUX:
VZCZC or ZCZC
e) O̲C̲R̲
A new message is started when the Start of Message
Block (SOM) is received from the IOC. The message
start is detected by the LTUX which generates the
SOM for the IOC.
4.2.5.1.2.3 M̲e̲s̲s̲a̲g̲e̲ ̲E̲n̲d̲
The detection of a Message End will stop the error
checking and detection of ACP127 Format Lines.
The CIF in which the message has been stored is transferred
to the Analysis and checkpointed in the AAQ.
a) T̲R̲S̲/̲P̲O̲I̲N̲T̲ ̲T̲O̲ ̲P̲O̲I̲N̲T̲
The message end is detected when one of the following
sequences is received:
NNNN or NNN
The message End sequence(s) are detected by the
LTUX.
If the channel is open the timer function for supervision
of the incoming traffic is activated.
b) N̲I̲C̲S̲ ̲T̲A̲R̲E̲
The message end is detected when the end of message
block (EOM) is received.
A message acknowledgement is transferred to IOC.
If the channel is open the timer function for supervision
of the incoming traffic is activated.
c) S̲C̲A̲R̲S̲/̲C̲C̲I̲S̲
The message end is detected when the EOM block
is received from IOC.
An operation is transferred to the Transport Control
(TCS) to let it initiate a transmission of a Transaction
Acknowledgement on the outgoing channel.
The timer function for supervision of the incoming
traffic is activated.
d) P̲T̲R̲
The message end is detected when one of the following
sequences is received:
NNNN or NNN.
These sequences are detected by the LTUX.
e) O̲C̲R̲
The message end is available when the End of Message
Block (EOM) is received from the IOC. The Message
End is detected by the LTUX which generates the
EOM for the IOC.
4.2.5.1.2.4 M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲e̲e̲m̲p̲t̲i̲o̲n̲
The incoming message may be preempted.
A preemption is detected if a message line is equal
to the following sequence:
ZPH space ZPH
The message processing is terminated, and the message
will be transferred to the Analysis with a preemption
indication inserted in the queue element following
the message.
Characters received after preemption are discarded
until detection of a new start of message sequence.
A report is transferred to the supervisor's printer
each time a message is preempted.
This function is defined for:
TRC/POINT TO POINT and SCARS/CCIS.
4.2.5.1.2.5 P̲a̲g̲e̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲
The Incoming transport will detect if the incoming
message has been divided by means of the page sequence:
End of page function
Page identification
If the sequence above is detected, it will be removed,
i.e. it is not included in the message transferred
to the Analysis
The Page Detection is cancelled for the text part of
a Data Message.
The function above is defined for:
TRC/POINT TO POINT, NICS TARE,
SCARS/CCIS and PTR
4.2.5.1.2.6 T̲S̲N̲ ̲U̲p̲d̲a̲t̲i̲n̲g̲
The Incoming Transport updates the expected Transmission
Serial Number for the incoming message.
Each time a new message is received the TSN stored
in the first format line is compared to the expected
TSN.
If the received TSN is equal to 001, the expected TSN
(for next message) is set to 002.
If the received TSN is equal to the expected TSN, the
expected TSN is incremented with one. At wrap around
the expected TSN will take the value 001.
In the case that the received TSN differs from the
values mentioned above a TSN discontinuity occurs.
This situation is described in section 4.2.5.1.3.8.
Any message with TSN equal to 001 received from TRC/POINT
TO POINT or NICS TARE will make the ITS transfer an
operation to the TCS in order to initiate transmission
of a ZID ASM containing the TI of the last message
received prior to the reset.
The functions above are not included in PTR and OCR
ITS.
4.2.5.1.2.7 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲A̲c̲k̲n̲o̲w̲l̲e̲d̲g̲e̲
The Transaction Acknowledge is a specific function
which is defined for SCARS/CCIS Incoming Transport.
The ITS examines if the incoming message contains a
Transaction Acknowledge for a message which has been
transmitted on the outgoing channel. If so the Transaction
TSN is extracted from the Acknowledgement and transferred
to the Transport Control, which takes care of the sequence
of transactions on the outgoing channel.
Note: An incoming message containing a transaction
acknowledgement will not be transferred to the Analysis.
Each time a new incoming message has been checkpointed
at the AAQ (i.e. transferred to the Analysis) the ITS
will send an operation to the Transport Control with
the TSN of the message. This initiates a transmission
of a Transaction Acknowledgement on the outgoing channel.
4.2.5.1.3 E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The Incoming Transport performs a number of error checks
for each message line received from the IOC.
The Error Handling contains the functions which are
connected to the message error check.
The following sections describe the message errors
handled by the Incoming Transport.
A survey of error handling functions for each type
of transport are shown on figure 4.2.5-1 to 4.2.5-4.
4.2.5.1.3.1 C̲o̲n̲s̲e̲c̲u̲t̲i̲v̲e̲ ̲S̲t̲a̲r̲t̲ ̲S̲e̲q̲u̲e̲n̲c̲e̲
This function will detect the situation that two valid
"SOTF" sequences are received without an intervening
"end of transmission" function.
The function is defined for: TRC/POINT TO POINT and
PTR.
a) T̲R̲C̲/̲P̲O̲I̲N̲T̲ ̲T̲O̲ ̲P̲O̲I̲N̲T̲
The message will be terminated upon detection of
the second SOTF and an error indication is inserted
…86…1 …02… …02… …02… …02…
in the queue element which follows the message to the
Analysis.
A report is forwarded to the supervisor's printer.
The second SOTF is assumed to be the SOTF of a
new message.
b) P̲T̲R̲
The message is discarded upon detection of the
second SOTF.
A report indicating the situation is forwarded
to the supervisor's printer.
The second SOTF is assumed to be the SOTF of a
new message.
4.2.5.1.3.2 I̲l̲l̲e̲g̲a̲l̲ ̲E̲n̲d̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲(̲E̲O̲T̲F̲)̲
This function will check if a valid "EOTF" sequence
is available within the text part of the message, i.e.
between format line 11 and 13.
The function is defined for: TRC/POINT TO POINT, NICS
TARE, SCARS/CCIS and PTR.
a) T̲R̲C̲/̲P̲O̲I̲N̲T̲ ̲T̲O̲ ̲P̲O̲I̲N̲T̲
The message will be terminated upon detection of
this EOTF and the message forwarded to the Analysis
with an error mark inserted into the queue element
following the message.
A report is forwarded to the supervisor's printer.
All characters are discarded until a valid start
of message sequence is detected.
b) N̲I̲C̲S̲ ̲T̲A̲R̲E̲
As for TRC/POINT TO POINT.
c) S̲C̲A̲R̲S̲/̲C̲C̲I̲S̲
As for TRC/POINT TO POINT.
d) P̲T̲R̲
As for TRC/POINT TO POINT.
4.2.5.1.3.3 T̲o̲o̲ ̲L̲o̲n̲g̲ ̲L̲i̲n̲e̲
Each message line received from the IOC will be checked
for the number of characters.
This function is defined for:
TRC/POINT TO POINT, NICS TARE, SCARS/CCIS and PTR.
a) TR̲C̲/̲P̲O̲I̲N̲T̲ ̲T̲O̲ ̲P̲O̲I̲N̲T̲
In case that a message line received from the IOC
contains 69 characters but has no legal "end of
line" function, this is considered as an error.
A report is forwarded to the supervisor's printer
and an error mark is inserted in the queue element
which follows the message to the Analysis.
This error check is not performed for the text
part of a data message.
b) N̲I̲C̲S̲/̲T̲A̲R̲E̲
As for TRC/POINT TO POINT.
c) S̲C̲A̲R̲S̲/̲C̲C̲I̲S̲
As for TRC/POINT TO POINT
Note: For VDU ̲pages and comments the limit is
80 characters.
d) P̲T̲R̲
As for TRC/POINT TO POINT.
4.2.5.1.3.4 O̲v̲e̲r̲s̲i̲z̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲
This error occurs if more than 12000 characters of
a message has been received without detection of an
"end of transmission function".
The function is defined for:
TRC/POINT TO POINT, NICS TARE, SCARS/CCIS, PTR and
OCR.
a) T̲R̲C̲/̲P̲O̲I̲N̲T̲ ̲T̲O̲ ̲P̲O̲I̲N̲T̲
This error will cause the message to be automatically
terminated and a report is forwarded to the supervisor's
printer.
An error mark is inserted in the queue element
which follows the message to the Analysis.
All characters received from the IOC are discarded
until detection of a valid "SOTF" sequence.
b) N̲I̲C̲S̲ ̲T̲A̲R̲E̲
As for TRC/POINT TO POINT.
c) S̲C̲A̲R̲S̲/̲C̲C̲I̲S̲
As for TRC/POINT TO POINT.
d) P̲T̲R̲/̲O̲C̲R̲
As for TRC/POINT TO POINT.
4.2.5.1.3.5 1̲4̲0̲ ̲I̲d̲e̲n̲t̲i̲c̲a̲l̲ ̲C̲o̲n̲s̲e̲c̲u̲t̲i̲v̲e̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲s̲
This error occurs if more than 140 identical consecutive
characters are received within the same message.
The error check is not performed for the text part
of a data message.
The error is defined for: TRC/POINT TO POINT and PTR.
a) T̲R̲C̲/̲P̲O̲I̲N̲T̲ ̲T̲O̲ ̲P̲O̲I̲N̲T̲
This error will cause the message to be automatically
terminated and a channel report is forwarded to
the supervisor's printer.
An operation is sent to the Transport Control to
make it initiate transmission of an ASM (if specified
by the Supervisor).
An error mark is inserted in the queue element
following the message to the analysis.
All characters received from the IOC are discarded
until detection of a valid "SOTF" sequence.
b) P̲T̲R̲
The message is discarded and a report is forwarded
to the supervisor's printer. All characters are
discarded until detection of a new SOTF sequence.
4.2.5.1.3.6 1̲0̲0̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲s̲ ̲b̲e̲t̲w̲e̲e̲n̲ ̲t̲w̲o̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
This function detects if more than 100 characters are
received between the previous "end of message" function
and the detection of a new "SOTF" sequence.
The error is defined for:
TRC/POINT TO POINT and PTR.
a) T̲R̲C̲/̲P̲O̲I̲N̲T̲ ̲T̲O̲ ̲P̲O̲I̲N̲T̲
This error will cause a report to be forwarded
to the supervisor's printer.
All characters received from the IOC are discarded
until detection of a valid "SOTF" sequence.
b) P̲T̲R̲
As for TRC/POINT TO POINT.
4.2.5.1.3.7 H̲a̲l̲t̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲
If during the reception of a message, no characters
are received for a specific period the incoming transport
will receive an error code from the IOC indicating
that the message has been interrupted.
This error is defined for TRC/POINT TO POINT, NICS
TARE, SCARS/CCIS, PTR and OCR.
a) T̲R̲C̲/̲P̲O̲I̲N̲T̲ ̲T̲O̲ ̲P̲O̲I̲N̲T̲
This error will cause the message to be automatically
terminated.
An error mark is inserted in the queue element
which follows the message to the Analysis.
A report is forwarded to the supervisor's printer.
If more characters are received from the IOC they
will be discarded until detection of the next legal
"SOTF" sequence.
b) N̲I̲C̲S̲ ̲T̲A̲R̲E̲
As for TRC/POINT TO POINT.
c) S̲C̲A̲R̲S̲/̲C̲C̲I̲S̲
As for TRC/POINT TO POINT.
d) P̲T̲R̲ ̲a̲n̲d̲ ̲O̲C̲R̲
The message is terminated and discarded, and a
report is forwarded to the supervisor's printer.
New characters are discarded until detection of
the next "SOTF" sequence.
4.2.5.1.3.8 E̲r̲r̲o̲r̲s̲ ̲i̲n̲ ̲F̲o̲r̲m̲a̲t̲ ̲L̲i̲n̲e̲ ̲1̲
After detection of a valid start of message sequence
the Incoming Transport will check the first line of
the message for a number of errors.
If some elements of the first message line are missing
the Incoming Transport will insert the expected values
before the message is transferred to the Analysis.
The following description defines the errors to be
detected for each type of transport.
a) T̲R̲C̲/̲P̲O̲I̲N̲T̲ ̲T̲O̲ ̲P̲O̲I̲N̲T̲
Format Line 1 transferred to the Analysis always
takes the following view:
'SOTF' Designator TSN 5 sp UU/HH,
with
'SOTF' : VZCZC
Designator : three letters
TSN : three or four digits
UU/HH : security warning prosign
The following errors may occur:
M̲i̲s̲s̲i̲n̲g̲ ̲D̲e̲s̲i̲g̲n̲a̲t̲o̲r̲: Format Line 1 contains less
than three characters after the 'SOTF' sequence.
The Incoming Transport inserts the expected designator
and the expected TSN.
I̲l̲l̲e̲g̲a̲l̲ ̲D̲e̲s̲i̲g̲n̲a̲t̲o̲r̲: At least one of the three characters
following the 'SOTF' sequence is not a letter ('A'..'Z').
The Incoming Transport inserts the expected designator.
D̲e̲s̲i̲g̲n̲a̲t̲o̲r̲ ̲M̲i̲s̲m̲a̲t̲c̲h̲: The designator following the
'SOTF' sequence is not equal to the expected designator.
The false designator follows the message to the
Analysis without any change.
M̲i̲s̲s̲i̲n̲g̲ ̲T̲S̲N̲: Format Line 1 contains less than six
characters after the 'SOTF' sequence. The Incoming
Transport inserts the expected TSN.
I̲l̲l̲e̲g̲a̲l̲ ̲T̲S̲N̲: At least one of the three characters
following the designator is not a digit. The Incoming
Transport inserts the expected TSN.
T̲o̲o̲ ̲l̲o̲w̲ ̲T̲S̲N̲: The TSN following the designator is
less than the expected TSN. The false TSN follows
the message to the Analysis without any change.
(TSN = 001 is not defined as an error. Ref. section
4.2.5.1.2.6).
T̲o̲o̲ ̲h̲i̲g̲h̲ ̲T̲S̲N̲: The TSN following the designator
is higher than the expected TSN. The received TSN
follows the message to the Analysis without any
change.
The Incoming Transport will adjust the expected
TSN (ref.sec.4.2.5.1.2.6).
All the TSN errors described above will cause a
report to be forwarded to the supervisor's printer.
Furthermore a log record indicating TSN-discontinuity
will be created and sent to the Transport Control
which communicates with the Log Package.
The queue element following the message to the
Analysis is marked with a code indicating the result
of the error check for format line 1. Also the
ACP127-Parameter Field of the External Message
Format containing the message is supplied with
error codes (ref. ICD009 sec. 5.6.1).
S̲e̲c̲u̲r̲i̲t̲y̲ ̲W̲a̲r̲n̲i̲n̲g̲ ̲P̲r̲o̲s̲i̲g̲n̲: If the last two characters
of the received format line 1 is equal to 'UU'
or 'HH' the sequence
5 sp UU/HH EOLF
is appended to the TSN. Otherwise the Incoming
Transport will terminate the line after TSN.
b) N̲I̲C̲S̲ ̲T̲A̲R̲E̲
As for TRC/POINT TO POINT.
c) S̲C̲A̲R̲S̲/̲C̲C̲I̲S̲
If the message is received in ACP127 format the
procedure is the same as for NICS TARE.
If the message is received in E1 format the 'SOTF!
sequence is not available. The first three characters
(of format line B) are expected to be the designator:
Designator TSN EOLF
The Incoming Transport inserts the 'SOTF' sequence
in front of the designator before the message is
transferred to Analysis
4.2.5.1.4 M̲e̲s̲s̲a̲g̲e̲ ̲L̲i̲n̲e̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲
The Message Line Detection supplies the functions which
are related to the detection of ACP127 Format Lines.
This serves the following purposes:
- storing of message lines into the External
Message Format (EMF), i.e. in the Header Field,
Text Field and Corrections Field.
- updating of the ACP127 Parameter Field of the
External Message Format.
The Incoming Transport will detect the following
Format Lines:
FL 1
FL 3
FL 4
FL 6
FL 10
FL 11
FL l3
FL 14
FL 15
FL 16
4.2.5.1.4.1 D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲F̲o̲r̲m̲a̲t̲ ̲L̲i̲n̲e̲ ̲1̲ ̲(̲F̲L̲ ̲1̲)̲
The FL 1 (SOTF sequence) is detected if a message line
contains one of the following sequences:
VZCZC or ZCZC
The function above is defined for TRC/POINT TO POINT,
NICS TARE, SCARS/CCIS and PTR.
4.2.5.1.4.2 D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲F̲o̲r̲m̲a̲t̲ ̲L̲i̲n̲e̲ ̲3̲ ̲(̲F̲L̲ ̲3̲)̲
The FL 3 is detected if the first three characters
of a message line following FL 1 are equal to the sequence:
DE (space).
The ACP127 Parameter Field within the External Message
Format is updated with a pointer to FL 3.
After detection of the sequence above the FL 3 check
is dismantled.
The function is defined for: TRC/POINT TO POINT, NICS
TARE, SCARS/CCIS and PTR.
4.2.5.1.4.3 D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲F̲o̲r̲m̲a̲t̲ ̲L̲i̲n̲e̲ ̲4̲ ̲(̲F̲L̲ ̲4̲)̲
The FL 4 is detected if the first four characters of
a message line following FL 1 are equal to one of the
sequences:
ZNR space or ZNY space
After detection of this sequence the FL 4-check is
dismantled.
The purpose of the FL 4 detection is to examine if
the message is a "data message", i.e. to examine if
a "special Handling Designator" has been included in
FL 4.
The Incoming Transport will consider the message to
be a Data message if one of the following sequences
are detected in FL 4:
/DDDXX
/XDDDX
/XXDDD
with X indicating an alphabetic character.
If a data message is detected a mark is inserted in
the queue element following the message to the Analysis.
The function is defined for: TRC/POINT TO POINT, NICS
TARE and PTR.
4.2.5.1.4.4 D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲F̲o̲r̲m̲a̲t̲ ̲L̲i̲n̲e̲ ̲6̲ ̲(̲F̲L̲ ̲6̲)̲
The FL 6 is detected if the first three characters
of a message line following FL 1 are equal to the sequence:
FM space .
If this sequence is detected the FL 6-check is dismantled.
The purpose of the FL 6 detection is to insert a pointer
to the line in the ACP127 Parameter Field of the External
Message Format, which is transmitted to the Analysis.
The function is defined for: TRC/POINT TO POINT, NICS
TARE, SCARS/CCIS and PTR.
4.2.5.1.4.5 D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲F̲o̲r̲m̲a̲t̲ ̲L̲i̲n̲e̲ ̲1̲0̲ ̲(̲F̲L̲ ̲1̲0̲)̲
The FL 10 is detected if the first two characters of
a message line following FL 1 is equal to the sequence:
GR.
If this sequence is detected the FL 10-check is dismantled.
The purpose of the FL 10 detection is to insert a line
pointer in the ACP127 Parameter Field of the External
Message Format, which is transmitted to the Analysis.
The function is defined for:
TRC/POINT TO POINT, NICS TARE, SCARS/CCIS and PTR.
4.2.5.1.4.6 D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲F̲o̲r̲m̲a̲t̲ ̲L̲i̲n̲e̲ ̲1̲1̲ ̲(̲F̲L̲ ̲1̲1̲)̲
The FL 11 is detected if a message line only contains
two characters equal to the sequence: BT.
All message lines received prior to FL 11 have been
stored in the "Header Field" of the External Message
Format.
All message lines which are received after FL 11 will
be stored in the "Text Field" until FL 13 is detected.
Note: FL 11 is not stored.
The function is defined for: TRC/POINT TO POINT, NICS
TARE, SCARS CCIS and PTR.
4.2.5.1.4.7 D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲F̲o̲r̲m̲a̲t̲ ̲L̲i̲n̲e̲ ̲1̲3̲ ̲(̲F̲L̲ ̲1̲3̲)̲
The FL 13 is detected if a message line received after
FL 11 only contains two characters equal to the sequence:
BT.
4.2.5.1.4.8 D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲F̲o̲r̲m̲a̲t̲ ̲L̲i̲n̲e̲ ̲1̲4̲ ̲(̲F̲L̲ ̲1̲4̲)̲
The FL 14 is detected if the first two characters of
the message line following FL 13 are equal to: GR.
If FL 14 is detected, the four characters up to end
of line (Group Count) next to "GR" are inserted in
the ACP127 Parameter Field of the External Message
Format (EMF) which is transmitted to the Analysis.
If the message line following FL 13 is not equal to
FL 14 or FL 15, it is stored in the Correction Field
of the EMF (Ref.note in sec. 5.2.5.1.4.9).
4.2.5.1.4.9 D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲F̲o̲r̲m̲a̲t̲ ̲L̲i̲n̲e̲ ̲1̲5̲ ̲(̲F̲L̲ ̲1̲5̲)̲
The FL 15 is detected if the first character of the
message line following FL 13 or FL 14 is equal to "
"
( = when received from IOC).
If FL 15 is detected the four characters (Station Serial
Number) next to " " are inserted in the ACP127 Parameter
Field of the External Message Format (EMF) which is
transmitted to the Analysis.
N̲o̲t̲e̲: The message lines between FL 13 and FL 16 (end
of message) are not stored in the EMF if they are equal
to one of following three sequences:
. . .
. . .
. . .
(FL 13) BT (FL 13) BT (FL 13) BT
(FL 14) GR... (FL 14) GR... (FL 15)
...
(FL 15) ... (FL 16) NNNN (FL 16) NNNN
(FL 16) NNNN
If the message lines between FL 13 and FL 16 differ
from the sequences above, they are all stored in the
Correction Field of the EMF.
4.2.5.1.4.10 D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲F̲o̲r̲m̲a̲t̲ ̲L̲i̲n̲e̲ ̲1̲6̲ ̲(̲F̲L̲ ̲1̲6̲)̲
The FL 16 is detected if a message line received after
FL 1 is equal to one of the following sequences:
NNNN or NNN
which indicates the end of the message.
4.2.5.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The software structure of the Incoming Transport is
based on a coroutine running under control of the CSF
Coroutine Monitor.
The principle placing of this coroutine in a transport
subprocess has been described in section 4.2.3.2.
The software structure of the ITS contains a number
of modules which are closely related to the functional
breakdown described in section 4.2.5.1.
The module disposition for each type of Incoming Transport
is shown on figure 4.2.5.2-1 and 4.2.5.2-2.
Each module contains a number of procedures related
to a specific function within the Incoming Transport.
These procedures are described in section 4.2.5.4 during
the Module Design.
4.2.5.2.1 I̲n̲c̲o̲m̲i̲n̲g̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Incoming Traffic Control Module supplies the coroutine
which takes care of the basic control logic of the
Incoming Transport.
All other functions are initiated from this coroutine
which includes the main waiting point, IT ̲OPSEM (ref.
4.2.3.3.2.3).
From here the coroutine receives operations, which
determine the actions to be performed in the Incoming
Transport.
The coroutine calls the "Incoming Message Handling
Module" each time a buffer with message lines is received
from the IOC through the waiting point.
The "Incoming Start Stop Module" is called if a start-up,
a stop or a close down is received from the TCS.
To each type of Incoming Transport a specific Incoming
Traffic Control Module is designed.
4.2.5.2.2 I̲n̲c̲o̲m̲i̲n̲g̲ ̲S̲t̲a̲r̲t̲ ̲S̲t̲o̲p̲
This module includes the procedures which takes care
of:
- Start Up
- Stop Transport
- Close Down.
The module is activated from the Incoming Traffic Control
as a result of a command received from Transport Control
(TCS).
The module is common to all types of transport.
4.2.5.2.3 I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
This module supplies the main logic for handling of
the flow of message lines through the Incoming Transport
as described in section 4.2.5.1.2.
All functions related to error checking of message
lines, detection of format lines and storage of message
lines in the External Message Format are activated
from this module.
Handling of buffers from the IOC and creation of CIF's
are performed through the "Incoming Buffer Control
Module".
Detection or decoding of message lines are realized
by means of the "Message Line Detection Module".
For each type of transport a specific Incoming Message
Handling Module is designed.
4.2.5.2.4 M̲e̲s̲s̲a̲g̲e̲ ̲L̲i̲n̲e̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲
The Message Line Detection Module supplies a number
of procedures specially designed for detection of the
following set of ACP127 format lines:
FL 1
FL 3
FL 4
FL 6
FL 10
FL 11
FL 13
FL 14
FL 15
FL 16
The functions related to these detections are described
in section 4.2.5.1.4.
This module is activated from the Incoming Message
Handling Module in order to store a message in the
External Message Format.
The module makes use of the Interpreter Module (a common
subpackage module) to decode the message lines.
The module is common to all types of transport.
4.2.5.2.5 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
The Common Subpackage Procedures have been divided
into three modules:
I̲n̲c̲o̲m̲i̲n̲g̲ ̲B̲u̲f̲f̲e̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲
This module contains a number of procedures which support
the following functions:
- reading of records (message lines) from a buffer
received from IOC.
- creation of a CIF containing the External Mes-
sage Format.
- writing of message lines into a CIF.
The module is common to all types of transport.
I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲ ̲M̲o̲d̲u̲l̲e̲
The Interpreter Module supplies a number of common
procedures which facilitates the decoding or detection
of message lines.
M̲e̲s̲s̲a̲g̲e̲ ̲C̲h̲e̲c̲k̲ ̲M̲o̲d̲u̲l̲e̲
This module supplies a number of common procedures
intended for checking specific characteristics of the
incoming message lines, i.e. Page Start, Oversized
Message, Illegal EOTF etc.
4.2.5.2.6 T̲R̲S̲ ̲A̲u̲x̲i̲l̲i̲a̲r̲y̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
These procedures are common to all types of transport
and supports the following functions within the ITS:
- Timer Updating
- Send and Receive functions related to semaphores
- Maintenance of pools for operations
- Updating of indicators (Flags)
- Transfer of reports to supervisor's printer
Note: These procedures are located in the TRS (see
4.2.3.6).
Figure 4.2.5.2-1 and 4.2.5.2-2
4.2.5.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
4.2.5.3.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
This section describes the main data structure and
control logic within the ITS.
Three buffers have been introduced to support the flow
of message lines through the ITS (see figure 4.2.5.2.1-1)
The message lines are received from the IOC stored
in a buffer (IOC-BUFFER) made available to the IOC
through a call to the IOS Procedure, "READ BYTES".
Two buffers are used for this purpose in order to make
it possible for the ITS to read message lines from
one buffer while the other is filled by IOC.
The ITS packs the message line into the External Message
Format (EMF) by moving the lines to INP-EMF-BUFFER.
Here it is checked if the line is identical to one
of the ACP127 Format Lines, which are detected by the
ITS. As a result of the detection of Format Lines
a field list, describing the fields of the EMF, is
updated.
During the detection of format lines the ITS will extract
information to be stored in ACP ̲PARAMETER ̲
FIELD of the EMF. The information is saved into INP
̲ACP ̲PARAM until the end of message is detected.
When all lines have been moved from the IOC ̲BUFFER,
this is made available for the IOC again, and the ITS
will wait for the other buffer to be returned.
When the message start is detected a CIF (Camps Information
File) is created with the fields of the External Message
Format.
Each time the INP ̲EMF ̲BUFFER has been filled with message
lines these are transferred to the CIF together with
the field list, which describes in which fields the
lines are to be stored.
Any time the end of the message is detected, the remaining
message lines stored in INP ̲EMF ̲BUFFER are transferred
to the CIF. At this moment also the ACP127 Parameters
are transferred.
At last a queue element referencing the CIF is forwarded
to the Analysis (i.e.AAQ) by which a checkpointing
takes place.
figure 4.2.5.2.1-1
4.2.5.3.2 I̲O̲C̲ ̲I̲n̲p̲u̲t̲ ̲B̲u̲f̲f̲e̲r̲
The ITS receives the message lines from IOC by means
of two input buffers (IOC ̲BUFFER).
A buffer is made available for the IOC through a System
Call (READ ̲BYTES). The answer is associated to the
main waiting point IT ̲OPSEM by means of an operation
which is returned to IT ̲OPSEM when the buffer has been
filled with characters.
The IOC ̲BUFFER is always assigned a specific operation
together with the parameters necessary for the System
Call. The data structure is described in section 4.2.3.5.7.3.
4.2.5.3.3 I̲n̲p̲u̲t̲ ̲B̲u̲f̲f̲e̲r̲s̲ ̲t̲o̲ ̲E̲x̲t̲e̲r̲n̲a̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲o̲r̲m̲a̲t̲
The ITS will pack the message lines into the External
Message Format by means of the following data structures
(see figure 4.2.5.2.3-1):
a) I̲N̲P̲ ̲E̲M̲F̲ ̲B̲U̲F̲
Array of characters for construction of the External
Message Format (EMF).
b) A̲C̲P̲ ̲P̲A̲R̲A̲M̲ ̲B̲U̲F̲
Record with a structure equal to the ACP127-PARAMETER
̲FIELD within the EMF. The buffer is updated during
detection of format lines and is transferred to
the EMF when the end of message has been found.
c) F̲I̲E̲L̲D̲ ̲L̲I̲S̲T̲
Data record with calling parameters for the System
Call (WRITE ̲CIF), which transfer the message lines
from the INP ̲EMF ̲BUF to the CIF containing the
External Message Format (EMF)
The FIELD LIST specifies for each field of the
EMF the first position to be stored and the number
of characters to be transferred to the specified
field. If the number is zero the transfer will
continue with the next field in the list The characters
shall be stored consecutively in the INP ̲EMF ̲BUF
in the sequence indicated by the FIELD ̲LIST.
Figure 4.2.5.2.3-1
4.2.5.3.4 C̲r̲e̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲C̲I̲F̲ ̲f̲o̲r̲ ̲I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲
Each time the start of a message is detected a CIF
containing the fields of the External Message Format
is created.
The CIF is created with a reference to the Channel
Command Queue, (CCQ).
When the end of message is detected, the CIF is forwarded
to the Analysis through AAQ. The queue element referencing
CCQ is dismantled and a checkpoint is made at AAQ.
The structure of the CIF to be created and the View
Attributes describing its fields are shown on figure
4.2.5.2.4-1 to 4.2.5.2.4-3.
The fields of the EMF are:
Text Field
ACP127 Parameter Field
ACP127 Header Field
ACP127 Corrections Field
The structure of the EMF is defined in DBD section
10.2.
Prior to the System Call, "CREATE ̲CIF", the VIEW ̲ATTRIBUTES,
specifying the CIF, shall be updated as shown on figure
4.2.5.2.4-2.
The Access Profile (bit 0-2) is updated with the classification
which is stored in the Circuit Profile for external
channels and in the Device Profile for the PTR.
Figure 4.2.5.2.4-1 to 3
4.2.5.3.5 I̲n̲c̲o̲m̲i̲n̲g̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲M̲a̲s̲k̲s̲
a) I̲n̲c̲o̲m̲i̲n̲g̲ ̲S̲t̲a̲t̲e̲ (see fig. 4.2.5.3.4-1)
Specifies the state of the Incoming Traffic Control.
b) I̲n̲p̲u̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲M̲a̲s̲k̲ (see fig. 4.2.5.3.4-2)
Specifies the state of the Incoming Message Handling.
c) F̲o̲r̲m̲a̲t̲ ̲L̲i̲n̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲M̲a̲s̲k̲ (see fig. 4.2.5.3.4-3)
Specifies the format lines to be detected during
the Message Line Detection.
Figure 4.2.5.3.4-1 to 3.
4.2.5.4 M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.5.4.1 T̲R̲C̲/̲P̲T̲O̲P̲ ̲I̲n̲c̲o̲m̲i̲n̲g̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲C̲o̲n̲t̲r̲o̲l̲
4.2.5.4.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̲
This module supplies the TP ̲IT ̲COROUTINE which contains
the main waiting point of the Incoming Transport for
TRC/POINT TO POINT.
The TP ̲IT ̲COROUTINE receives operations from the IT
̲OPSEM semaphore and decodes the operationtype. The
following operations are received:
- Start of Transport
- Stop Transport
- Close Down
- Acknowledge for Discontinuity Log
- IOC Buffer Reply
The functions related to each type of transport are
described in section 4.2.5.1.1.
4.2.5.4.1.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) TP ̲IT ̲COROUTINE
b) TP ̲IT ̲COROUTINE (R6): OK
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R6 LINK (kept)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None There is no return from the TP ̲IT ̲COROUTINE
which is implemented with an endless loop.
4.2.5.4.1.3 M̲o̲d̲u̲l̲e̲ ̲c̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
TP ̲IT ̲COROUTINE
FIND ̲OPERATION
4.2.5.4.1.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
IT ̲OPSEM : Main Waiting Point
IT ̲OPERATION : Save area for operation
received from IT ̲OPSEM.
All data used are defined in section 4.2.3.5.
4.2.5.4.1.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
M̲o̲d̲u̲l̲e̲ ̲E̲n̲t̲r̲y̲: (see flowgram 4.2.5.4.1.5-1)
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲T̲P̲ ̲I̲T̲ ̲C̲O̲R̲O̲U̲T̲I̲N̲E̲
(R6) C D LINK
N̲o̲t̲e̲: This procedure is implemented with an endless
loop in order to make it run under control of the CSF
COROUTINE MONITOR.
The procedure contains a WAITING ̲POINT (IT ̲OPSEM) through
which it receives operations from the TCS and buffers
returned as a reply to the system call READ ̲BYTES which
has been associated to IT ̲OPSEM.
M̲o̲d̲u̲l̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲:̲
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲F̲I̲N̲D̲ ̲O̲P̲E̲R̲A̲T̲I̲O̲N̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R Pointer to Transport Parameters
R6) C D LINK
This procedure finds the next operation related to
the SYSCALL READ ̲BYTES and containing a SYSCALL ̲READY
indication.
The number of the next operation is stored into INP
̲IOC ̲SEQUENCE. If the CP ̲TYPE field of an operation
contains the number the address of the operation is
returned.
PROCEDURE TP ̲IT ̲COROUTINE
EQUIVALENCE (PARAM ̲BASE, TRP: TRANSPORT ̲PARAMETERS)
START
LOOP "Forever"
READ ̲PARAM ̲BASE
WAIT ̲TRS ̲OPSEM (TRP.IT ̲OPSEM) "Main Waiting Point"
(TRP.IT ̲OPERATION)
CASE TRP.IT ̲OPERATION.OP ̲TYPE
TRS ̲START ? INCOM ̲START ̲STOP (START)
TRS ̲STOP ? INCOM ̲START ̲STOP (STOP)
TRS ̲CLOSE ? INCOM ̲START ̲STOP (CLOSE)
IOC ̲REPLY ? FIND ̲OPERATION
TRS ̲LOG ̲ACK ? RESET ̲INDICATOR (TRP.INCOM
̲STATE ̲MASK
(LOG ̲ACK): OK
OTHERWISE? TRS ̲INTERNAL ̲ERROR
(TP ̲IT ̲COROUTINE,
TRS ̲OP ̲ERROR,
OP ̲TYPE)
END CASE
END LOOP
RETURN
Flowgram 4.2.5.4.1.5-1
4.2.5.4.2 N̲I̲C̲S̲ ̲T̲A̲R̲E̲ ̲I̲n̲c̲o̲m̲i̲n̲g̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲C̲o̲n̲t̲r̲o̲l̲
4.2.5.4.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̲
Equal to TRC/PTOP Incoming Traffic Control (sec. 4.2.5.4.1.1).
4.2.5.4.2.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) NT ̲IT ̲COROUTINE
b) NT ̲IT ̲COROUTINE (R6): OK
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R6 LINK
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None The NT ̲IT ̲COROUTINE is implemented with
an endless loop.
4.2.5.4.2.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
NT ̲IT ̲COROUTINE
FIND ̲OPERATION
4.2.5.4.2.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Equal to TRC/PTOP Incoming Traffic Control (sec. 4.2.5.4.1.4).
4.2.5.4.2.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
Equivalent to TRC/PTOP Incoming Traffic Control (sec.
4.2.5.4.1.5)
NT ̲IT ̲COROUTINE : See flowgram 4.2.5.4.2.5-1.
PROCEDURE NT ̲IT ̲COROUTINE
EQUIVALENCE (PARAM ̲BASE, TRP: TRANSPORT ̲PARAMETERS)
START
LOOP "Forever"
READ ̲PARAM ̲BASE
WAIT ̲TRS ̲OPSEM (TRP.IT ̲OPSEM) "Main Waiting Point"
CASE TRP.IT ̲OPERATION.OP ̲TYPE
TRS ̲START ? INCOM ̲START ̲STOP (START)
TRS ̲STOP ? INCOM ̲START ̲STOP (STOP)
TRS ̲CLOSE ? INCOM ̲START ̲STOP (CLOSE)
IOC ̲REPLY ? FIND ̲OPERATION
TRS ̲LOG ̲ACK ? RESET ̲INDICATOR (TRP.INCOM ̲STATE
̲MASK
LOG ̲ACK): OK
OTHERWISE ? TRS ̲INTERNAL ̲ERROR
(NT ̲IT ̲COROUTINE,
TRS ̲OP ̲ERROR,
OP ̲TYPE)
END CASE
END LOOP
RETURN
Flowgram 4.2.5.4.2.5-1
4.2.5.4.3 S̲C̲A̲R̲S̲/̲C̲C̲I̲S̲ ̲I̲n̲c̲o̲m̲i̲n̲g̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲C̲o̲n̲t̲r̲o̲l̲
4.2.5.4.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̲
Equal to TRC/PTOP Incoming Traffic Control (sec. 4.2.5.4.1.1).
4.2.5.4.3.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) SC ̲IT ̲COROUTINE
b) SC ̲IT ̲COROUTINE (R6): OK
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R6 LINK (destr.)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None The SC ̲IT ̲COROUTINE is implemented with
an endless loop.
4.2.5.4.3.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
SC ̲IT ̲COROUTINE
FIND ̲OPERATION
4.2.5.4.3.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Equal to TRC/PTOP Incoming Traffic Control (sec. 4.2.5.4.1.4).
4.2.5.4.3.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
Equivalent to TRC/PTOP Incoming Traffic Control (sec.
4.2.5.4.1.5).
SC ̲IT ̲COROUTINE : See flowgram 4.2.5.4.3.5-1
PROCEDURE SC ̲IT ̲COROUTINE
EQUIVALENCE (PARAM ̲BASE, TRP: TRANSPORT ̲PARAMETERS)
START
LOOP "Forever"
READ ̲PARAM ̲BASE
WAIT ̲TRS ̲OPSEM (TRP.IT ̲OPSEM) "Main Waiting Point"
(TRP.IT ̲OPERATION)
CASE TRP.IT ̲OPERATION.OP ̲TYPE
TRS ̲START ? INCOM ̲START ̲STOP (START)
TRS ̲STOP ? INCOM ̲START ̲STOP (STOP)
TRS ̲CLOSE ? INCOM ̲START ̲STOP (CLOSE)
IOC ̲REPLY ? FIND ̲OPERATION
TRS ̲LOG ̲ACK ? RESET ̲INDICATOR (TRP.INCOM ̲STATE
̲MASK
(LOG ̲ACK): OK
OTHERWISE? TRS ̲INTERNAL ̲ERROR
(SC ̲IT ̲COROUTINE,
TRS ̲OP ̲ERROR,
OP ̲TYPE)
END CASE
END LOOP
RETURN
Flowgram 4.2.5.4.3.5-1
4.2.5.4.4 P̲T̲R̲ ̲I̲n̲c̲o̲m̲i̲n̲g̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲C̲o̲n̲t̲r̲o̲l̲
4.2.5.4.4.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Equal to TRC/PTOP Incoming Traffic Control (sec. 4.2.5.4.1.1),
except for the Acknowledge for Discontinuity log.
4.2.5.4.4.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) PTR ̲IT ̲COROUTINE
b) PTR ̲IT ̲COROUTINE (R6): OK
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R6 LINK (destr.)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None The PTR ̲IT ̲COROUTINE is implemented with
an endless loop.
4.2.5.4.4.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
PTR ̲IT ̲COROUTINE
FIND ̲OPERATION
4.2.5.4.4.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Equal to TRC/PTOP Incoming Traffic Control (sec. 4.2.5.4.1.4).
4.2.5.4.4.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
Equivalent to TRC/PTOP Incoming Traffic Control (sec.4.2.5.4.1.5)
PTR ̲IT ̲COROUTINE : See flowgram 4.2.5.4.4.5-1.
PROCEDURE PTR ̲IT ̲COROUTINE
EQUIVALENCE (PARAM ̲BASE, TRP: TRANSPORT ̲PARAMETERS)
START
LOOP "Forever"
READ ̲PARAM ̲BASE
WAIT ̲TRS ̲OPSEM (TRP.IT ̲OPSEM) "Main Waiting Point"
(TRP.IT ̲OPERATION)
CASE TRP.IT ̲OPERATION.OP ̲TYPE
TRS ̲START ? INCOM ̲START ̲STOP (START)
TRS ̲STOP ? INCOM ̲START ̲STOP (STOP)
TRS ̲CLOSE ? INCOM ̲START ̲STOP (CLOSE)
IOC ̲REPLY ? PTR ̲INCOMING ̲MSG ̲HANDLING
OTHERWISE ? FIND ̲OPERATION
(PTR ̲IT ̲COROUTINE,
TRS ̲OP ̲ERROR,
OP ̲TYPE)
END CASE
END LOOP
RETURN
Flowgram 4.2.5.4.4.5-1
4.2.5.4.5 I̲n̲c̲o̲m̲i̲n̲g̲ ̲S̲t̲a̲r̲t̲ ̲S̲t̲o̲p̲
4.2.5.4.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̲
This module supplies the procedures for performing
the functions related to the following operations received
from Transport Control:
- Start Up
- Stop Transport
- Close Down
The functions above are described in section 4.2.5.1.1.
The module is common for all types of transport.
4.2.5.4.5.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) INCOM ̲START ̲STOP (FUNCTION ̲ID)
b) INCOM ̲START ̲STOP (R0,R1,R2,R3,R4,R5,R7,R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
C̲a̲l̲l̲i̲n̲g̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲ ̲
R1 FUNCTION ̲ID (TRS ̲OP ̲TYPE)
R6 LINK (Kept)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
̲ All registers destroyed
4.2.5.4.5.2 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
INCOM ̲START ̲STOP
ITS ̲START ̲UP
4.2.5.4.5.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲s̲
Ref. section 4.2.3.5.
4.2.5.4.5.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
All procedures within this module are reentrant.
M̲o̲d̲u̲l̲e̲ ̲E̲n̲t̲r̲y̲ (Flowgr. 4.2.5.4.5.5-1)
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲N̲C̲O̲M̲ ̲S̲T̲A̲R̲T̲ ̲S̲T̲O̲P̲
(R0 D
R1 C D FUNCTION (TRS ̲OP ̲TYPE)
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMS
R6 C D LINK
This procedure is the entry point of IN ̲START ̲STOP
module. Three functions are handled:
- TRS ̲START
- TRS ̲STOP
- TRS ̲CLOSE
M̲o̲d̲u̲l̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲:̲
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲T̲S̲ ̲S̲T̲A̲R̲T̲ ̲U̲P̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMS
R6 C D LINK
This procedure takes care of the start up functions
related to the incoming transport:
- Init of control masks and variables for reading
message lines through the system call READ ̲BYTES.
- Making all buffers stored in INP ̲IOC ̲POOL available
to the IOS by initiating the system call READ
̲BYTES.
PROCEDURE INCOM ̲START ̲STOP (FUNCTION ̲ID)
EQUIVALENCE (PARAM ̲BASE,TRP:TRANSPORT ̲PARAMETERS)
START
SAVE ̲LINK (LINK) (PARAM ̲BASE)
CASE ̲FUNCTION ̲ID
TRS ̲START ? ITS ̲START ̲UP
TRS ̲STOP ?
CASE CHECK ̲INDICATOR (TRP ̲INCOM ̲STATE ̲MASK,
TRS ̲INPUT ̲START ̲UP) : BOOLEAN
FALSE ? SEND ̲TRS ̲OPSEM(INP ̲CLOSE ̲ACK,
PRIORITY ̲0
TC ̲OPSEM)
END CASE
SET ̲INDICATOR (TRP.INCOM ̲STATE ̲MASK,
TRS ̲INPUT ̲STOP)
CANCEL ̲TRS ̲SYSCALL (IOC ̲REPLY,
INPUT ̲IOC ̲POOL)
TRS ̲CLOSE ? SET ̲INDICATOR (TRP.INCOM ̲STATE ̲MASK,
TRS ̲INPUT ̲CLOSE ̲DOWN)
END CASE
RESTORE ̲LINK
RETURN
Flowgram 4.2.5.4.5.5-1
4.2.5.4.6 T̲R̲C̲/̲P̲T̲O̲P̲ ̲I̲n̲c̲o̲m̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
4.2.5.4.6.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module supplies the procedures which take care
of the flow of message through the Incoming Transport
for TRC/POINT TO POINT.
The module is activated from the IOC through the main
waiting point "IT ̲OPSEM".
The following functions are initiated from this module:
a) Check of IOC Reply.
b) Reading of message lines from the IOC ̲BUFFER.
c) Message ERROR checking including:
-Consecutive SOTF
-100 characters
-Oversized message
-140 Identical characters
-Illegal EOTF sequence
d) Analysis of Formal Line 1.
e) Preemption Handling
f) Page Handling.
g) Detection of Formal Lines.
4.2.5.4.6.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) TP ̲INCOMING ̲MESSAGE ̲HANDLING
b) TP ̲INCOMING ̲MESSAGE ̲HANDLING (R6) : OK
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲
R6 LINK (destr.)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None (All registers destroyed)
4.2.5.4.6.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
The procedures supplied by TP ̲INCOMING ̲MESSAGE ̲HANDLING
are depicted on figure 4.2.5.4.6.3-1
Figure 4.2.5.4.6.3-1
4.2.5.4.6.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
All data structures used by this module is defined
in section 4.2.3.5
4.2.5.4.6.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
M̲o̲d̲u̲l̲e̲ ̲E̲n̲t̲r̲y̲ ̲P̲o̲i̲n̲t̲:̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲T̲P̲ ̲I̲N̲C̲O̲M̲I̲N̲G̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲H̲A̲N̲D̲L̲I̲N̲G̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure supplies the entry point for the TP
̲MSG ̲HND Module.
The procedure handles the buffers returned from IOC
as result of the systemcall READ ̲BYTES.
IOC ̲RECORDS stored in the buffer are moved one by one
to the INP ̲EMF ̲BUFFER and decoded.
If a record is accepted as a message line the INP ̲FIELD
̲LIST and the INP ̲ACP ̲PARAMS are updated. Furthermore
the INP ̲EMP ̲INDEX is incremented to the next idle position
of INP ̲EMF ̲BUFFER.
This goes on until the buffer has been emptied. Then
the buffer is made available to the IOC again through
a new READ ̲BYTES.
M̲o̲d̲u̲l̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲T̲P̲ ̲I̲N̲P̲U̲T̲ ̲S̲T̲O̲P̲ ̲C̲H̲E̲C̲K̲
(R1 D
R4 D
R7 D
R6) C D LINK
BOOLEAN
This procedure examines if it is permitted to make
a buffer available for the IOC through the system call
READ ̲BYTES.
Exists: True - Buffer should be returned to pool.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲O̲C̲ ̲R̲E̲P̲L̲Y̲ ̲C̲H̲E̲C̲K̲
(R0 C D COMPLETION CODE RECEIVED FROM IOC
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure examines the completion codes received
when the reply for the system call READ ̲BYTES is returned.
The following reply codes are handled:
OK - The buffer has been returned because an
END ̲OF ̲MESSAGE ̲SEQUENCE has been detected.
MORE ̲DATA- More data will follow in the next buffer.
LSL ̲SOTF - The buffer has been returned because an
SOTF sequence has been detected.
LSL ̲TIME ̲OUT-The buffer has been returned because
timeout has occurred in the LTUX.
Disconnected and LTUX ̲DEVICE ̲ERROR -
The buffer has been returned because of
TMS ̲DISCONNECTION or DEVICE ̲ERROR.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲O̲C̲ ̲R̲E̲C̲O̲R̲D̲ ̲C̲H̲E̲C̲K̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
ERROR ̲OK
This procedure examines the type of the received
IOC ̲RECORD and decides from the type of the previous
IOC ̲RECORD which of the following actions are to take
place:
- Too long line
- Ident char check
- Check of page start
- Decoding of message line
Exists: Error - no further decoding is needed
Okay - decoding may continue
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲T̲P̲ ̲D̲E̲C̲O̲D̲E̲ ̲M̲S̲G̲ ̲L̲I̲N̲E̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure will decode the IOC ̲RECORD stored in
the INP ̲EMF ̲BUF at the position indicated by INP ̲EMF
̲INDEX.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲T̲P̲ ̲M̲S̲G̲ ̲L̲I̲N̲E̲ ̲D̲E̲T̲E̲C̲T̲I̲O̲N̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure examines if the message line stored
in INP ̲EMF ̲BUF at the position indicated by INP ̲EMF
̲INDEX is equal to one of the format lines specified
by FLX ̲CTR ̲MASK.
For each bit position equal to '1' the DETECT ̲MSG ̲LINE
module is called.
Each time a format line is detected the FLX ̲CTR ̲MASK
is updated with a new mask taken from TRS ̲DETECTION
̲MASK defined in TRS ̲DATA module.
PROCEDURE TP ̲INCOMING ̲MESSAGE ̲HANDLING
EQUIVALENCE (PARAM ̲BASE, TRP: TRANSPORT ̲PARAMETERS)
START
SAVE ̲LINK(LINK)(PARAM ̲BASE)
CASE WAIT ̲SYSTEM ̲CALL (TRP.IT ̲OPERATION ̲ADDR)
(TRS ̲IOC ̲OPERATION.FILE): ERROR ̲OK
ERROR ? CHECK ̲IOC ̲COMPLETION ̲CODE
OKAY ?
END CASE
LOOP "READ MESSAGE LINE"
CASE READ ̲MSG ̲LINE(TRP.IT ̲OPERATION ̲ADDR):READ ̲MSG ̲
LINE ̲RESULT
COMPLETE ̲LINE ? DECODE ̲IOC ̲RECORD
IOC ̲BUFFER ̲EMPTY ? EXIT LOOP
EMF ̲BUFFER ̲FULL ? WRITE ̲TRS ̲CIF
END CASE
END LOOP
IOC ̲REPLY ̲CHECK
MESSAGE NOT READY ?
WRITE ̲TRS ̲CIF
SEND ̲MSG ̲TO ̲ANALYSIS
SET ̲TP ̲INCOM ̲TIMER
CASE TP ̲INPUT ̲STOP ̲CHECK ( ): BOOLEAN
TRUE ? RETURN ̲IOC ̲OPERATION
FALSE ? INIT ̲IOC ̲INPUT
END CASE
RESTORE ̲LINK ( ) (LINK,PARAM ̲BASE)
RETURN
Flowgram 4.2.5.4.6.5-1
Principle
4.2.5.4.7 N̲I̲C̲S̲ ̲T̲A̲R̲E̲ ̲I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
4.2.5.4.7.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module supplies the procedures which take care
of the flow of messages through the Incoming Transport
for NICS TARE.
The module is activated from the NICS TARE Incoming
Traffic Control each time a buffer is returned from
the IOC through the main waiting point "IT ̲OPSEM".
The following functions are initiated from this module:
a) Check of IOC Reply
b) Reading of message lines from the IOC ̲BUFFER to
the INP ̲EMF ̲BUFFER
c) Message Error Checking including:
- Oversized Message
- Illegal EOTF
d) Detection of SOM Block from IOC
e) Analysis of Format Line 1
f) Page Handling
g) Detection of Format Lines
4.2.5.4.7.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) NT ̲INCOMING ̲MESSAGE ̲HANDLING
b) NT ̲INCOMING ̲MESSAGE ̲HANDLING(R6): OK
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R6 LINK (destr)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None (All registers destroyed)
4.2.5.4.7.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
The procedures included in the NT ̲INCOMING ̲MESSAGE
̲HANDLING are depicted on figure 4.2.5.4.7.3-1.
The READ ̲MSG ̲LINES procedure is external and supplied
by the INCOMING BUFFER CONTROL.
4.2.5.4.7.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
All data structures used by this module are defined
in section 4.2.3.5.
4.2.5.4.7.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
M̲o̲d̲u̲l̲e̲ ̲E̲n̲t̲r̲y̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure supplies the entry point for the NT
̲MSG ̲HND module.
The procedure handles the buffers returned from IOC
as result of the systemcall READ ̲BYTES.
IOC ̲RECORDS stored in the buffer are moved one by one
to the INF ̲EMF ̲BUFFER and decoded.
If a record is accepted as a message line the
INP ̲FIELD ̲LIST and the INP ̲ACP ̲PARAMS are updated.
Furthermore the INP ̲EMF ̲INDEX is incremented to the
next idle position of INP ̲EMF ̲BUFFER.
This goes until the buffer has been empties. Then the
buffer is made available to the IOC again through a
new READ ̲BYTES.
Figure 4.2.5.4.7.3-1
M̲o̲d̲u̲l̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲N̲T̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲T̲O̲ ̲A̲N̲A̲L̲Y̲S̲I̲S̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure will send the message to the analysis
as prescribed in CPS/ICD/009 sec.5.6.1.1
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲E̲N̲D̲ ̲M̲S̲G̲ ̲A̲C̲K̲N̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure sends an acknowledge IOC ̲RECORD to the
NICS ̲TARE ̲ACK ̲CONNECTION.
The procedure is called each time a message has been
checkpointed at the analysis.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲O̲C̲ ̲R̲E̲P̲L̲Y̲ ̲C̲H̲E̲C̲K̲
(R0 D Completion Code Received from IOC
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure examines the completion codes received
when the reply for the system call READ ̲BYTES is returned.The
following reply codes are handled:
OK: The buffer has been returned because an
END ̲OF ̲MESSAGE ̲SEQUENCE has been detected.
MORE ̲DATA: More data will follow in the next buffer.
Disconnected and LTU ̲DEVICE ̲ERROR: The buffer has been
returned because of TMS ̲DISCONNECTION or
DEVICE ̲ERROR.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲N̲T̲ ̲I̲N̲P̲U̲T̲ ̲S̲T̲O̲P̲ ̲C̲H̲E̲C̲K̲
(R1 D
R4 D
R7 D
R6) C D LINK
BOOLEAN
This procedure examines if it is permitted to make
a buffer available for the IOC through the system call
READ ̲BYTES.
Exists: TRUE - Buffer should be returned to pool.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲N̲T̲ ̲D̲E̲C̲O̲D̲E̲ ̲M̲S̲G̲ ̲L̲I̲N̲E̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure decodes the type of each IOC ̲RECORD
and finds the actions to be performed from the NT ̲ACTION
table defined at the start of this module.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲N̲T̲ ̲M̲S̲G̲ ̲L̲I̲N̲E̲ ̲H̲N̲D̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure controls the sequence of message line
handling. The following maintasks are initiated:
- Too long line check
- Preemption sequence check
- Page handling
- Format line detection
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲N̲T̲ ̲F̲L̲1̲ ̲C̲H̲E̲C̲K̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure initiates handling of format line 1
for messages received in ACP ̲127 or E1.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲N̲T̲ ̲M̲S̲G̲ ̲S̲T̲A̲R̲T̲ ̲H̲N̲D̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 D
R6) C D LINK
This procedure supplies the actions to be performed
when an IOC ̲RECORD with SOM flag has been received.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲N̲T̲ ̲M̲S̲G̲ ̲L̲I̲N̲E̲ ̲D̲E̲T̲E̲C̲T̲I̲O̲N̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure examines if the message line stored
in INF ̲EMF ̲BUF at the position indicated by INP ̲EMF
̲INDEX is equal to one of the format lines specified
by
FLX ̲CTR ̲MASK.
For each bit position equal to '1' the DECTECT ̲MSG
̲LINE module is called.
Each time a format line is detected the FLX ̲CTR ̲MASK
is updated with a new mask taken from TRS ̲DETECTION
̲MASK defined in TRS ̲DATA module.
PROCEDURE NT ̲INCOMING ̲MESSAGE ̲HANDLING
EQUIVALENCE(PARAM ̲BASE,TRP: TRANSPORT ̲PARAMETERS)
START
SAVE ̲LINK(LINK)(PARAM ̲BASE)
CASE WAIT ̲SYSTEM ̲CALL(TRP.IT ̲OPERATION.ADDR)
(TRS ̲IOC ̲OPERATION.FILE) : ERROR ̲OK
ERROR ? CHECK IOC ̲COMPLETION ̲CODE
OKAY ?
END CASE
LOOP "Read Msg.Lines"
CASE READ ̲MSG ̲LINE(TRP.IT ̲OPERATION ̲ADDR): READ ̲MSG ̲
LINE ̲RESULT
COMPLETE ̲LINE ? NT ̲DECODE ̲MSG ̲LINE
IOC ̲BUFFER ̲EMPTY ? EXIT ̲LOOP
EMF ̲BUFFER ̲FULL ? WRITE ̲TRS ̲CIF
END CASE
END LOOP
IOC ̲REPLY ̲CHECK
Message Not Ready ?
NT ̲MESSAGE ̲TO ̲ANALYSIS
SEND ̲MSG ̲ACKN
SET ̲NT ̲INCOM ̲TIMER
CASE NT ̲INPUT ̲STOP ̲CHECK ( ): BOOLEAN
TRUE ? RETURN ̲IOC ̲OPERATION
FALSE ? INIT ̲IOC ̲INPUT
END CASE
RESTORE ̲LINK( )(LINK,PARAM ̲BASE)
RETURN
Flowgram 4.2.5.4.7.5-1
Principle
4.2.5.4.8 S̲C̲A̲R̲S̲/̲C̲C̲I̲S̲ ̲I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
4.2.5.4.8.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module supplies the procedures which take care
of the flow of messages through the Incoming Transport
for SCARS/CCIS.
The module is activated from the SCARS/CCIS Incoming
Traffic Control each time a buffer is returned from
the IOC through the main waiting point "IT ̲OPSEM".
The following functions are initiated from this module:
a) Check of IOC Reply
b) Reading of message lines from the IOC ̲BUFFER to
the INP ̲EMF ̲BUFFER
c) Message Error Checking including:
- Oversized Message
- Illegal EOTF
d) Detection of SOM Block from IOC
e) Analysis of Format Line 1/Format Line B
f) Page Handling
g) Preemption Handling
h) Detection of format lines
4.2.5.4.8.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) SC ̲INCOMING ̲MESSAGE ̲HANDLING
b) SC ̲INCOMING ̲MESSAGE ̲HANDLING (R6) : OK
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R6 LINK (kept)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None (All registers destroyed)
4.2.5.4.8.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
The components of the SC ̲INCOMING ̲MESSAGE ̲HANDLING
are depicted on figure 4.2.5.4.8.3-1 and 4.2.5.4.8.3-2.
4.2.5.4.8.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
All data structures used by this module are defined
in section 4.2.3.5.
4.2.5.4.8.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
M̲o̲d̲u̲l̲e̲ ̲E̲n̲t̲r̲y̲ (Flowgram 4.2.5.4.8.5-1)
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲C̲ ̲I̲N̲C̲O̲M̲I̲N̲G̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲H̲A̲N̲D̲L̲I̲N̲G̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure supplies the entry point for the
SC ̲MSG ̲HND module.
The procedure handles the buffers returned from IOC
as result of the system call READ ̲BYTES.
IOC ̲RECORDS stored in the buffer are moved one by one
to the INP ̲EMF ̲BUFFER and decoded.
If a record is accepted as a message line the
INP ̲FIELD ̲LIST and the INP ̲ACP ̲PARAMS are updated.
Furthermore the INP ̲EMF ̲INDEX is incremented to the
next idle position of INP ̲EMF ̲BUFFER.
This goes on until the buffer has been emptied. Then
the buffer is made available to the IOC again through
a new READ ̲BYTES.
Figure 4.2.5.4.8.3-1
Figure 4.2.5.4.8.3-2
M̲o̲d̲u̲l̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲:̲
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲C̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲T̲O̲ ̲A̲N̲A̲L̲Y̲S̲I̲S̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure will send the message to the analysis
as described in CPS/ICD/009 5.6.1.1.
When the message has been checkpointed at AAQ transmission
of a transaction acknowledge is initiated by sending
an operation to the TCS.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲O̲C̲ ̲R̲E̲P̲L̲Y̲ ̲C̲H̲E̲C̲K̲
(R0 C D Completion code received from IOC
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure examines the completion codes received
when the reply for the system call READ ̲BYTES is returned.
The following reply codes are handled:
OK - The buffer has been returned because an
END ̲OF ̲MESSAGE ̲SEQUENCE has been detected.
MORE ̲DATA - More data will follow in the next buffer.
DISCONNECTED, LTU ̲DEVICE ̲ERROR AND LTU ̲BLOCK ̲ERROR
TMS ̲DISCONNECTION or DEVICE ̲ERROR.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲C̲ ̲I̲N̲P̲U̲T̲ ̲S̲T̲O̲P̲ ̲C̲H̲E̲C̲K̲
(R1 D
R4 D
R7 D
R6) C D LINK
BOOLEAN
This procedure examines if it is permitted to make
a buffer available for the IOC through the system call
READ ̲BYTES
EXITS: TRUE - buffer should be returned to pool.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲C̲ ̲D̲E̲C̲O̲D̲E̲ ̲M̲S̲G̲ ̲L̲I̲N̲E̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure decodes the type of each IOC ̲RECORD
and finds the action to be performed from the SC ̲ACTION
table at the start of this module.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲C̲ ̲M̲S̲G̲ ̲L̲I̲N̲E̲ ̲H̲N̲D̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure controls the sequence of message line
handling. The following maintasks are initiated:
- TOO LONG LINE CHECK
- PREEMPTION SEQUENCE CHECK
- PAGE HANDLING
- FORMAT LINE DETECTION
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲C̲ ̲F̲L̲1̲ ̲C̲H̲E̲C̲K̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure initiates handling of format line 1
for messages received in ACP ̲127 or E1.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲A̲N̲A̲L̲Y̲S̲I̲S̲ ̲M̲A̲I̲N̲T̲Y̲P̲E̲ ̲
(R1 R Maintype for analysis
R5 D
R7 C R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure returns the maintype for the message:
UNIDENTIFIED ̲CCIS or UNIDENTIFIED ̲SCARS
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲C̲ ̲M̲S̲G̲ ̲S̲T̲A̲R̲T̲ ̲H̲N̲D̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 D
R6) C D LINK
This procedure supplies the actions to be performed
when an IOC ̲RECORD with SOM flag has been received.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲T̲R̲A̲N̲S̲ ̲A̲C̲K̲ ̲C̲H̲E̲C̲K̲
(R0 D
R1 D
R2 C D SC ̲ACTION ̲TYPE
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure handles the TRANSACTION ̲ACKNOWLEDGE
received from SCARS/CCIS.
SC ̲ACTION ̲TYPE = ACT ̲ACK: validity check is
performed.
SC ̲ACTION ̲TYPE = ACT ̲ACK ̲READY: a legal transaction
has been received.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲C̲ ̲M̲S̲G̲ ̲L̲I̲N̲E̲ ̲D̲E̲T̲E̲C̲T̲I̲O̲N̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure examines if the message line stored
in INP ̲EMF ̲BUF at the position indicated by INP ̲EMF
̲INDEX is equal to one of the format lines specified
by
FLX ̲CTR ̲MASK.
For each bit position equal to '1' the DETECT ̲MSG ̲LINE
module is called.
Each time a format line is detected the FLX ̲CTR ̲MASK
is updated with a new mask taken from TRC ̲DETECTION
̲MASK defined in TRS ̲DATA module.
PROCEDURE SC ̲INCOMING ̲MESSAGE ̲HANDLING
EQUIVALENCE(PARAM:BASE, TRP: TRANSPORT ̲PARAMETERS)
START
SAVE ̲LINK(LINK)(PARAM ̲BASE)
CASE WAIT ̲SYSTEM ̲CALL (TRP.IT ̲OPERATION.ADDR)
(TRS ̲IOC ̲OPERATION.FILE): ERROR ̲OK
ERROR ? Check IOC Completion Code
OKAY ?
END CASE
LOOP "Read Msg.Line"
CASE READ ̲MSG ̲LINE (TRP.IT ̲OPERATION.ADDR):
READ ̲MSG ̲LINE ̲RESULT
COMPLETE ̲LINE ? SC ̲DECODE ̲MSG ̲LINE
IOC ̲BUFFER ̲EMPTY ? EXIT LOOP
EMF ̲BUFFER ̲FULL ? WRITE ̲TRS ̲CIF
END CASE
END LOOP
IOC ̲REPLY ̲CHECK
Message not Ready ?
SC ̲MESSAGE ̲TO ̲ANALYSIS
CASE SC ̲INPUT ̲STOP ̲CHECK ( ): BOOLEAN
TRUE ? RETURN ̲IOC ̲OPERATION
FALSE ? INIT ̲IOC ̲INPUT
END CASE
RESTORE ̲LINK ( )(LINK,PARAM ̲BASE)
RETURN
Flowgram 4.2.5.4.8.5-1
Principle
4.2.5.4.9 P̲T̲R̲ ̲I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
4.2.5.4.9.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module supplies the procedures which support the
flow of messages through the Incoming Transport for
PTR.
The module is activated from the PTR Incoming Traffic
Control each time a buffer is returned from the IOC
through the main waiting point "IT ̲OPSEM".
The following functions are initiated from this module:
a) Check of IOC Reply
b) Reading of message lines from the IOC ̲BUFFER to
the INP ̲EMF ̲BUFFER
c) Message Error Checking including:
- Two consecutive SOTF sequences
- Illegal EOTF sequence
- Too many characters between messages
- Oversized message
- 140 identical characters
d) Page Handling
e) Analysis of Format Line 1
f) Detection of Format Lines
4.2.5.4.9.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) PTR ̲INCOMING ̲MESSAGE ̲HANDLINE
b) PTR ̲INCOMING ̲MESSAGE ̲HANDLING (R6) : OK
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
R6 LINK (kept)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None (All registers destroyed)
4.2.5.4.9.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
The procedures supplied by PTR ̲INCOMING ̲MESSAGE ̲HANDLING
are depicted on figure 4.2.5.4.9.3-1.
4.2.5.4.9.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲s̲
All data used by this module are defined in section
4.2.3.5.
4.2.5.4.9.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
M̲o̲d̲u̲l̲e̲ ̲E̲n̲t̲r̲y̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲P̲T̲R̲ ̲I̲N̲C̲O̲M̲I̲N̲G̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲H̲A̲N̲D̲L̲I̲N̲G̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure supplies the entry point for the
PTR ̲MSG ̲HND module.
The procedure handles the buffers returned from IOC
as result of the system call READ ̲BYTES.
IOC ̲RECORDS stored in the buffers are moved one by
one to the INP ̲EMF ̲BUFFER and decoded.
If a record is accepted as a message line the
INP ̲FIELD ̲LIST and the INP ̲ACP ̲PARAMS are updated.
Furthermore the INP ̲EMF ̲INDEX is incremented to the
next idle position of INP ̲EMF ̲BUFFER.
This goes on until the buffer has been emptied. Then
the buffer is made available to the IOC again through
a new READ ̲BYTES.
Figure 4.2.5.4.9.3-1
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲O̲C̲ ̲R̲E̲P̲L̲Y̲ ̲C̲H̲E̲C̲K̲
(R0 C D Completion code received from IOC
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure examines the completion codes received
when the reply for the system call READ ̲BYTES is returned.
The following reply codes are handled:
OK - The buffer has been returned because an
END ̲OF ̲MESSAGE ̲SEQUENCE has been detected.
MORE ̲DATA - More data will follow in the next buffer.
LSL ̲SOTF - The buffer has been returned because an
SOTF sequence has been detected.
LSL ̲TIME ̲OUT - The buffer has been returned because
a timeout has occurred in the LTUX-
DISCONNECTED and LTUX ̲DEVICE ̲ERROR -The buffer has
been
returned because of TMS ̲DISCONNECTION
or DEVICE ̲ERROR.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲P̲T̲R̲ ̲D̲E̲C̲O̲D̲E̲ ̲M̲S̲G̲ ̲L̲I̲N̲E̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure will decode the IOC ̲RECORD stored in
the INP ̲EMF ̲BUF at the position indicated by INP ̲EMF
̲INDEX.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲P̲T̲R̲ ̲I̲N̲P̲U̲T̲ ̲S̲T̲O̲P̲ ̲C̲H̲E̲C̲K̲
(R1 D
R4 D
R7 D
R6) C D LINK
BOOLEAN
This procedure examines if it is permitted to make
a buffer available for the IOC through the system call
READ ̲BYTES
EXITS: TRUE - buffer should be returned to pool.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲H̲E̲C̲K̲ ̲D̲E̲D̲I̲C̲A̲T̲E̲D̲ ̲P̲T̲R̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
BOOLEAN
This procedure checks if a PTR is dedicated.
EXITS: TRUE - PTR has been dedicated
FALSE - PTR normal
P̲R̲O̲C̲E̲D̲U̲R̲E̲ ̲I̲O̲C̲ ̲R̲E̲C̲O̲R̲D̲ ̲C̲H̲E̲C̲K̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
ERROR ̲OK
This procedure examines the type of the received
IOC ̲RECORD and decides from the type of the previous
IOC ̲RECORD which of the following actions are to take
place:
- TOO LONG LINE
- IDENT CHAR CHECK
- CHECK OF PAGE START
- DECODING OF MESSAGE LINE
EXITS: ERROR -No further decoding is needed
OKAY -Decoding may continue
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲P̲T̲R̲ ̲M̲S̲G̲ ̲L̲I̲N̲E̲ ̲D̲E̲T̲E̲C̲T̲I̲O̲N̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure examines if the message line stored
in INP ̲EMF ̲BUF at the position indicated by INP ̲EMF
̲INDEX is equal to one of the format lines specified
by
FLX ̲CTR ̲MASK.
For each bit position equal to '1' the DETECT ̲MSG ̲LINE
module is called.
Each time a format line is detected the FLX ̲CTR ̲MASK
is updated with a new mask taken from TRS ̲DETECTION
̲MASK defined in TRS ̲DATA module.
PROCEDURE PTR ̲INCOMING ̲MESSAGE ̲HANDLING
EQUIVALENCE(PARAM ̲BASE,TRP: TRANSPORT ̲PARAMETERS)
START
SAVE ̲LINK(LINK)(PARAM ̲BASE)
CASE WAIT ̲SYSTEM ̲CALL(TRP.IT ̲OPERATION.ADDR)
(TRS ̲IOC ̲OPERATION.FILE): ERROR ̲OK
ERROR ? Check IOC Completion Code
OKAY ?
END CASE
LOOP "Read Msg.Line"
CASE READ ̲MSG ̲LINE(TRP.IT ̲OPERATION.ADDR):
READ ̲MSG ̲LINE ̲RESULT
COMPLETE ̲LINE ? PTR ̲DECODE ̲MSG ̲LINE
IOC ̲BUFFER ̲EMPTY ? EXIT ̲LOOP
EMF ̲BUFFER ̲FULL ? WRITE ̲TRS ̲CIF
END CASE
END LOOP
IOC ̲REPLY ̲CHECK
Message Not Ready ?
Message Error Detected ? Dismantle Created CIF
SEND ̲MESSAGE ̲TO ̲ANALYSIS
CASE PTR ̲INPUT ̲STOP ̲CHECK( ): BOOLEAN
TRUE ? RETURN ̲IOC ̲OPERATION(TRP.IT ̲OPERATION.ADDR)
FALSE ? INIT ̲IOC ̲INPUT(TRP.IT ̲OPERATION.ADDR)
END CASE
RESTORE ̲LINK( )(LINK,PARAM ̲BASE)
RETURN
Flowgram 4.2.5.4.7.5-1
Principle
4.2.5.4.10 M̲e̲s̲s̲a̲g̲e̲ ̲L̲i̲n̲e̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲
4.2.5.4.10.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The Message Line Detection module includes procedures
for detection of the following ACP127 Format Lines:
FL 1
FL 3
FL 4
FL 6
FL10
FL11
FL13
FL14
FL15
FL16
The functions related to the detection of each format
line are described in section 4.2.5.1.4.
The module is called from the Message Handling Modules
during the decoding of message lines.
4.2.5.4.10.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) MESSAGE ̲LINE ̲DETECT(LINE ̲ID)
(CC): (FOUND, NOT ̲FOUND)
b) MESSAGE ̲LINE ̲DETECT (R1,R6,R7) : (FOUND, NOT ̲FOUND)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
R1 Line Id (destr.)
R6 LINK (kept)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R7 CC (FOUND, NOT ̲FOUND)
4.2.5.4.10.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
a) M̲E̲S̲S̲A̲G̲E̲ ̲L̲I̲N̲E̲ ̲D̲E̲T̲E̲C̲T̲
Makes a call to the procedure taking care of the
line detection specified in the call (ref. 4.2.5.4.10.2).
b) C̲H̲E̲C̲K̲ ̲F̲L̲1̲
Detects the "SOTF" sequence (ref. 4.2.5.1.4.1)
c) C̲H̲E̲C̲K̲ ̲F̲L̲3̲
Detects the "DE Sp " sequence (ref. 4.2.5.1.4.2)
d) C̲H̲E̲C̲K̲ ̲F̲L̲4̲
Detects the "ZNR Sp " or "ZNY Sp " sequence
(ref. 5.2.5.1.4.3)
e) C̲H̲E̲C̲K̲ ̲F̲L̲6̲
Detects the "FM Sp " sequence (ref. 4.2.5.1.4.4
f) C̲H̲E̲C̲K̲ ̲F̲L̲1̲0̲
Detects the "GR Sp " sequence (ref. 4.2.5.1.4.5)
g) C̲H̲E̲C̲K̲ ̲F̲L̲1̲1̲
Detects the "BT" sequence for Text start
(ref. 4.2.5.1.4.6)
h) C̲H̲E̲C̲K̲ ̲F̲L̲1̲3̲
Detects the "BT" sequence for Text end
(ref. 4.2.5.1.4.7)
i) C̲H̲E̲C̲K̲ ̲F̲L̲1̲4̲
Detects the "GR Group Count " sequence
(ref. 4.2.5.1.4.8)
j) C̲H̲E̲C̲K̲ ̲F̲L̲1̲5̲
Detects the " Station Serial no. " sequence
(ref. 4.2.5.1.4.9)
k) C̲H̲E̲C̲K̲ ̲F̲L̲1̲6̲
Detects the "NNNN" sequence (ref. 4.2.5.1.4.10)
Figure 4.2.5.4.10.3-1
4.2.5.4.10.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
All the data structures used within this module are
defined in section 4.2.3.5.
4.2.5.4.10.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
MESSAGE ̲LINE ̲DETECT (Flowgram 4.2.5.4.10.5-1)
This module makes use of the common procedures defined
in section 4.2.5.6.1.
PROCEDURE MESSAGE ̲LINE ̲DETECT (LINE ̲ID)
(CC): (FOUND, NOT ̲FOUND)
START
SAVE ̲LINK(LINK)(PARAM ̲BASE)
CASE LINE ̲ID
FL1 ? CHECK ̲FL1
FL3 ? CHECK ̲FL3
FL4 ? CHECK ̲FL4
FL6 ? CHECK ̲FL6
FL10 ? CHECK ̲FL10
FL11 ? CHECK ̲FL11
FL13 ? CHECK ̲FL13
FL14 ? CHECK ̲FL14
FL15 ? CHECK ̲FL15
FL16 ? CHECK ̲FL16
END CASE
RESTORE ̲LINK
RETURN
Flowgram 4.2.5.4.10.5-1
4.2.5.4.11 T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲F̲l̲1̲ ̲C̲h̲e̲c̲k̲
4.2.5.4.11.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module supplies the procedures which take care
of the analysis of format line 1, Fl1 as prescribed
in paragraph 4.2.5.1.3.8.
The module will handle the Fl1 syntax as it appears
in ACP127 and E1 format.
The following subjects are included:
- Channel Designator Check
- Transmission Serial Number Check
- Check of security Warning Prosign
If the SOTF Sequence, the Channel Designator or the
Transmission Serial Number are missing/invalid, the
module will replace the missing/invalid element with
the expected sequence.
Note: If the sequences specified above are valid
but differ from the expected sequences, they
will not be replaced.
4.2.5.4.11.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) ACP ̲FLl ̲CHECK (with/without SOTF,MESSAGE ̲TYPE)
b) ACP ̲FL1 ̲CHECK (R0,R1,R2,R3,R4,R5,R7,R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R0 BOOLEAN (FALSE NO SOTF)
R1 Message Type (Qel maintype)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None
Figure 4.2.5.4.11.3-1
4.2.5.4.11.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
The procedures included in the TRS ̲FL1 ̲CHECK module
are depicted on figure 4.2.5.4.11.3-1.
4.2.5.4.11.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
All data structures used by this module are defined
in paragraph 4.2.3.5.
4.2.5.4.11.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
M̲o̲d̲u̲l̲e̲ ̲E̲n̲t̲r̲y̲ ̲P̲o̲i̲n̲t̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲A̲C̲P̲ ̲F̲L̲1̲ ̲H̲A̲N̲D̲L̲I̲N̲G̲
(R0 C D BOOLEAN (False:FL1 has no SOTF Sequence)
R1 C D Message type transmitted to analysis
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure is the entry point for the TRS ̲FL1 ̲CHECK
module.
The following actions are activated:
- check for missing designator
- check for invalid designator
- check for designator match
- check for missing TSN
- check for invalid TSN
- check for TSN match
- check for security prosign
- construction of format line 1 for analysis
- updating of expected TSN
M̲o̲d̲u̲l̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲U̲P̲D̲A̲T̲E̲ ̲E̲R̲R̲O̲R̲ ̲L̲I̲S̲T̲
(R1 C D Error type to be stored
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure updates the error list within the
TRS ̲ACP ̲PARAMETER ̲TYPE.
Error types to be stored are all related to errors
detected in FL1.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲L̲L̲E̲G̲A̲L̲ ̲D̲E̲S̲I̲G̲N̲A̲T̲O̲R̲ ̲H̲A̲N̲D̲L̲I̲N̲G̲
(R0 D
R1 C D Error code for ERROR ̲LIST
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMS
R6) C D LINK
This procedure takes care of error reporting for:
- Missing Designator
- Invalid Designator
Expected incoming, TSN and previous incoming TSN are
updated.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲L̲L̲E̲G̲A̲L̲ ̲T̲S̲N̲ ̲H̲A̲N̲D̲L̲I̲N̲G̲
(R0 D
R1 C D Error code for ERROR ̲LIST
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMS
R6) C D LINK
This procedure takes care of error reporting for:
- Missing TSN
- Invalid TSN
Expected TSN and previous incoming TSN are updated.
4.2.5.4.12 O̲C̲R̲ ̲I̲n̲c̲o̲m̲i̲n̲g̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲C̲o̲n̲t̲r̲o̲l̲
4.2.5.4.12.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module supplies the OCR ̲IT ̲COROUTINE which contains
the main waiting point of the Incoming Transport for
OCR.
The OCR ̲IT ̲COROUTINE receives operations from the
IT ̲OPSEM semaphore and decodes the operation type.
The following operations are received:
- Start of Incoming Traffic
- Stop Incoming Traffic
- Close Down
- IOC Buffer Reply.
4.2.5.4.12.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) OCR ̲IT ̲COROUTINE
b) OCR ̲IT ̲COROUTINE (R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R6 LINK (destr)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None There is no return from the OCR ̲IT ̲COROUTINE
which is implemented with an endless loop.
4.2.5.4.12.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
OCR ̲IT ̲COROUTINE
FIND ̲OPERATION
4.2.5.4.12.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
All data used are defined in section 4.2.3.5.
4.2.5.4.12.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
M̲o̲d̲u̲l̲e̲ ̲E̲n̲t̲r̲y̲ (See flowgram 4.2.5.4.12.5-1)
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲O̲C̲R̲ ̲I̲T̲ ̲C̲O̲R̲O̲U̲T̲I̲N̲E̲
(R6) C D LINK
NOTE:
This procedure is implemented with an endless loop
in order to make it run under control of the CSF COROUTINE
MONITOR.
The procedure contains a WAITING ̲POINT (IT ̲OPSEM) through
which it receives operations from the TCS and buffers
returned as a reply to the system call
READ ̲BYTES which have been associated to IT ̲OPSEM.
M̲o̲d̲u̲l̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲F̲I̲N̲D̲ ̲O̲P̲E̲R̲A̲T̲I̲O̲N̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure finds the next operation related to
the syscall READ ̲BYTES and containing a SYSCALL ̲READY
indication.
The number of the next operation is stored into
INP ̲IOC ̲SEQUENCE. If the OP ̲TYPE field of an operation
contains the number, the address of the operation is
returned.
PROCEDURE OCR ̲IT ̲OPERATION
EQUIVALENCE (PARAM ̲BASE,TRP: TRANSPORT ̲PARAMETERS)
START
LOOP "forever"
READ ̲BASE( ) (PARAM ̲BASE)
WAIT ̲TRS ̲OPSEM (TRP.IT ̲OPSEM)
(TRP ̲IT ̲OPERATION)
CASE TRP.IT ̲OPERATION. OP ̲TYPE
TRS ̲START ? INCOM ̲START ̲STOP(TRS ̲START)
TRS ̲STOP ? INCOM ̲START ̲STOP(TRS ̲STOP)
TRS ̲CLOSE ? INCOM ̲START ̲STOP(TRS ̲CLOSE)
IOC ̲REPLY ? FIND ̲OPERATION
OTHERWISE ? TRS ̲INTERNAL ̲ERR(TRS ̲OP ̲ERROR,
OCR ̲IT ̲COROUTINE,
OP ̲TYPE
END CASE
END LOOP
RETURN
Flowgram 4.2.5.4.1.5-1
4.2.5.4.13 O̲C̲R̲ ̲I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
4.2.5.4.13.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module supplies the procedures which take care
of the flow of messages through the incoming transport
for an OCR.
The module is activated each time a buffer is returned
from IOC through the main waiting point IT ̲OPSEM.
The following functions are included:
- IOC ̲RECORD ̲CHECK
- OCR ̲INPUT ̲STOP ̲CHECK
- IOC ̲REPLY ̲CHECK
- OCR ̲INCOMING ̲MESSAGE ̲HANDLING (ENTRY ̲POINT)
4.2.5.4.13.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) OCR ̲INCOMING ̲MESSAGE ̲HANDLING
b) OCR ̲INCOMING ̲MESSAGE ̲HANDLING(R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
R6 LINK (destr.)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None (All registers destroyed)
4.2.5.4.13.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
The components of this module are depicted on figure
4.2.5.4.13.3-1.
4.2.5.4.13.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲s̲
All data used by this module are defined in section
4.2.3.5.
4.2.5.4.13.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
M̲o̲d̲u̲l̲e̲ ̲E̲n̲t̲r̲y̲: (Flowgram 4.2.5.4.13.5-1)
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲O̲C̲R̲ ̲I̲N̲C̲O̲M̲I̲N̲G̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲H̲A̲N̲D̲L̲I̲N̲G̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure supplies the entry point for the OCR
̲MSG ̲HND module.
The procedure handles the buffers returned from IOC
as result of the system call READ ̲BYTES.
IOC ̲RECORDS stored in the buffer are moved one by one
to the INP ̲EMF ̲BUFFER and decoded.
If a record is accepted as a message line the INP ̲FIELD
̲LIST and the INP ̲ACP ̲PARAMS are updated.
Furthermore the INP ̲EMF ̲INDEX is incremented to the
next idle position of INP ̲EMF ̲BUFFER.
This goes on until the buffer has been emptied. Then
the buffer is made available to the IOC again through
a new READ ̲BYTES.
M̲o̲d̲u̲l̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲O̲C̲ ̲R̲E̲C̲O̲R̲D̲S̲ ̲C̲H̲E̲C̲K̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure examines the type of the received
IOC ̲RECORD and decides from the OCR ̲ACTION record table
which actions are to take place.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲O̲C̲ ̲R̲E̲P̲L̲Y̲ ̲C̲H̲E̲C̲K̲
(R0 C D Completion code received from IOC
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R POINTER TO TRANSPORT PARAMETERS
R6) C D LINK
This procedure examines the completion codes received
when the reply for the system call READ ̲BYTES is returned.
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲O̲C̲R̲ ̲I̲N̲P̲U̲T̲ ̲S̲T̲O̲P̲ ̲C̲H̲E̲C̲K̲
(R1 D
R4 D
R7 D
R6) C D LINK
BOOLEAN
This procedure examines if it is permitted to make
a buffer available for the IOC through the system call
READ ̲BYTES.
EXITS: TRUE - Buffer should be returned to pool.
Figure 4.2.5.4.13.3-1
PROCEDURE OCR ̲INCOMING ̲MESSAGE ̲HANDLING
EQUIVALENCE (PARAM ̲BASE, TRP:TRANSPORT ̲PARAMETERS)
START
SAVE ̲LINK(LINK)(BARAM ̲BASE)
CASE WAIT ̲SYSTEM ̲CALL (TRP.IT ̲OPERATION ̲ADDR)
(TRS ̲IOC ̲OPERATION ̲FILE): ERROR ̲OK
ERROR ? CHECK IOC Completion Code
OKAY ?
END CASE
LOOP "Read Msg. Lines"
CASE READING ̲MSG ̲LINE (TRP.IT ̲OPERATION ̲ADDR):
READ ̲MSG ̲LINE ̲RESULT
COMPLETE ̲LINE ? IOC ̲RECORD ̲CHECK
IOC ̲BUFFER ̲EMPTY ? EXIT ̲LOOP
EMF ̲BUFFER ̲FULL ? WRITE ̲TRS ̲CIF
END CASE
END LOOP
IOC ̲REPLY ̲CHECK
Message Not Ready ?
SEND ̲MSG ̲TO ̲ANALYSIS(UNIDENTIFIED ̲OCR,
INPUT ̲ERROR ̲MASK,
TRS ̲OCR ̲ANQ ̲REF)
CASE OCR ̲INPUT ̲STOP ̲CHECK( ): BOOLEAN
TRUE ? RETURN ̲IOC ̲OPERATION
FALSE ? INIT ̲IOC ̲INPUT
END CASE
RESTORE ̲LINK( )(LINK,PARAM ̲BASE)
RETURN…01…Flowgram 4.2.5.4.13.5-1
Principle
4.2.5.5 I̲T̲S̲,̲ ̲C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
All the data structures used by the Incoming Transport
have been defined in section 4.2.3.5.
4.2.5.6 I̲T̲S̲.̲ ̲C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
Three common modules are identified for the ITS:
- Interpreter Module (INTERPRETER ̲COM)
- INCOMING Buffer Module (ITS ̲BUF ̲COM)
- Message Check Module (MSG ̲CHECK ̲COM)
4.2.5.6.1 I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲ ̲M̲o̲d̲u̲l̲e̲
The Interpreter Module supplies a number of procedures
to be used for interpretation of message lines received
through the IOC.
The following functions are included:
- COMPARE ̲STRING
- SEARCH ̲STRING
- COMPARE ̲NUMBER
- CHECK ̲DIGITS
- CHECK ̲LETTERS
- CHECK ̲CR ̲LF
4.2.5.6.1.1 C̲o̲m̲p̲a̲r̲e̲ ̲S̲t̲r̲i̲n̲g̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲O̲M̲P̲A̲R̲E̲ ̲S̲T̲R̲I̲N̲G̲
R1 D
R2 D
R3 C D No.of characters to be compared
R4 C D Start addr. for buffer
R5 C D Start index within buffer
R7 C D Start addr. for specified string
R6) C D LINK
ERROR ̲OK
This procedure compares a number of characters within
a buffer with a specified string.
EXIT POINTS: OK Buffer characters equal to string
Error At least one character differs.
4.2.5.6.1.2 S̲e̲a̲r̲c̲h̲ ̲S̲t̲r̲i̲n̲g̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲E̲A̲R̲C̲H̲ ̲S̲T̲R̲I̲N̲G̲
(R0 D
R1 D
R2 D No.of characters within specified string
R3 C D No.of characters to be searched
R4 C D Start addr. for buffer
R5 C D Start index for buffer
R7 C D Start addr. for specified string
R6) C D LINK
ERROR ̲OK
This procedure will search for a specified string within
a buffer.
EXIT POINTS: OKAY String has been found
Error String has not been found
4.2.5.6.1.3 C̲o̲m̲p̲a̲r̲e̲ ̲N̲u̲m̲b̲e̲r̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲O̲M̲P̲A̲R̲E̲ ̲N̲U̲M̲B̲E̲R̲
(R0 C K Specified binary number
R1 R Number to be compared
R2 D
R3 C D No.of digits
R4 C K Buffer start addr.
R5 C D Buffer start index
R7 R Completion codesspecified string
R6) C D LINK
ERROR ̲OK
This procedure compares a specified binary number with
a string of digits. The string of digits are converted
into a binary number which is returned.
Completion codes: TSN ̲MATCH ̲TSN ̲TOO ̲HIGH ̲TSN ̲TOO ̲
LOW ̲TSN ̲ONE
4.2.5.6.1.4 C̲h̲e̲c̲k̲ ̲D̲i̲g̲i̲t̲s̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲H̲E̲C̲K̲ ̲D̲I̲G̲I̲T̲S̲
(R2 C R No. of characters to be checked
R3 R No.of consecutive characters
R4 C K Start address for buffer
R5 C D Start index
R6) C D LINK
This procedure finds the number of consecutive ASCII
digits from a specified start index within a buffer
(array of bytes).
4.2.5.6.1.5 C̲h̲e̲c̲k̲ ̲L̲e̲t̲t̲e̲r̲s̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲H̲E̲C̲K̲ ̲L̲E̲T̲T̲E̲R̲S̲
(R2 C D No. of characters to be checked
R3 R No.of consecutive characters
R4 C K Start address for buffer
R5 C D Start index
R6) C D LINK
This procedure finds the number of consecutive ASCII
letters from a specified start index within a buffer
(array of bytes).
4.2.5.6.1.6 C̲h̲e̲c̲k̲ ̲C̲a̲r̲r̲i̲a̲g̲e̲ ̲R̲e̲t̲u̲r̲n̲/̲L̲i̲n̲e̲ ̲F̲e̲e̲d̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲H̲E̲C̲K̲ ̲C̲R̲ ̲L̲F̲
(R2 C D No. of characters to be checked
R3 R No.of LF characters in line
R4 C K Start address for buffer
R5 C D Start index
R6) C D LINK
ERROR ̲OK
This procedure checks if a line only contains CR and
LF, if so the number of LF is returned.
…06…1 …02… …02… …02… …02… …02… …02… …02…
EXITS: ERROR- At least one character differs
from CR or LF.
Okay - All characters are equal to CR
or LF.
4.2.5.6.2 I̲n̲c̲o̲m̲i̲n̲g̲ ̲B̲u̲f̲f̲e̲r̲ ̲M̲o̲d̲u̲l̲e̲
This module supplies a number of procedures taking
of buffer control within the incoming transport.
The following functions are included:
- Init transfer of message lines from IOC
- Reading message lines from the IOC buffer
- Updating of ACP ̲PARAMETERS
- Updating of field list
- Creation of a CIF
- Writing of message lines into a CIF
- Send message to analysis.
4.2.5.6.2.1 I̲n̲i̲t̲ ̲I̲n̲p̲u̲t̲ ̲f̲r̲o̲m̲ ̲I̲O̲C̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲N̲I̲T̲ ̲I̲O̲C̲ ̲I̲N̲P̲U̲T̲
(R0 D
R1 D
R2 D
R3 D
R4 C D Pointer to TRS ̲IOC ̲OPERATION
R5 D
R7 R Pointer to Transport Parameters
R6) C D LINK
This procedure makes a buffer available for the IOC
through the system call READ ̲BYTES.
The buffer must be referenced by an operation defined
as the data structure TRS ̲IOC ̲OPERATION.
The procedure appends a syscall no. to the OP ̲TYPE
of the operation. The syscall no. is taken from INP
̲IOC ̲SEQUENCE of the running subprocess.
The procedure associates the IOC ̲REPLY to the main
waiting point for the incoming transport (IT ̲OPSEM).
4.2.5.6.2.2 R̲e̲a̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲L̲i̲n̲e̲ ̲F̲r̲o̲m̲ ̲I̲n̲p̲u̲t̲ ̲B̲u̲f̲f̲e̲r̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲R̲E̲A̲D̲ ̲M̲S̲G̲ ̲L̲I̲N̲E̲
(R0 D
R1 D
R2 D
R3 D
R4 C D Pointer to TRS ̲IOC ̲OPERATION
R5 D
R7 R Pointer to Transport Parameters
R6) C D LINK
READ ̲MSG ̲LINE ̲RESULT;
This procedure reads a message line (IOC ̲RECORD) from
the IOC ̲BUFFER related to the TRS ̲IOC ̲OPERATION.
The message line is stored into the INP ̲EMF ̲BUFFER
of the running subprocess.
The following exits may occur:
IOC ̲BUF ̲EMPTY: Only a part of an IOC ̲RECORD is available
in the IOC ̲BUFFER. This part has been
transferred to the INP ̲EMF ̲
BUFFER. The succeeding parts must follow
in the next buffer received from IOC.
EMF ̲BUF ̲FULL: The remaining part of the INP ̲EMF ̲
BUFFER cannot hold the IOC ̲RECORD.
No characters from the IOC ̲RECORD has
been transferred.
COMPLETE ̲LINE: A total message line (IOC ̲RECORD) has
been transferred from the IOC ̲BUFFER
to the INP ̲EMF ̲BUFFER.
The procedure updates the INPUT ̲LINE ̲TYPE data structure
within the running subprocess to keep track of the
state of IOC ̲RECORD being transferred.
4.2.5.6.2.3 U̲p̲d̲a̲t̲e̲ ̲A̲C̲P̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲U̲P̲D̲A̲T̲E̲ ̲A̲C̲P̲ ̲P̲A̲R̲A̲M̲S̲
(R1 C D INIT ̲SWITCH
R2 C D FIELD ̲ID
R3 C D IOC ̲RECORD ̲LENGTH
R5 D
R7 R Pointer to Transport Parameters
R6) C D LINK
This procedure updates the ACP ̲PARAMETERS for the running
subprocess.
If INIT ̲SWITCH is equal to true the parameters are
prepared for input of a new message.
If INIT ̲SWITCH is false only the TEXT ̲PARAMETERS are
updated (this means LINE ̲COUNT and END ̲OFFSET of the
specified field).
4.2.5.6.2.4 U̲p̲d̲a̲t̲e̲ ̲F̲i̲e̲l̲d̲ ̲L̲i̲s̲t̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲U̲P̲D̲A̲T̲E̲ ̲F̲I̲E̲L̲D̲ ̲L̲I̲S̲T̲
(R1 C D BOOLEAN (true:init, false: NO ̲INIT
R2 C D FIELD ̲ID
R3 C D Value to be added to record length
R7 R Pointer to Transport Parameters
R6) C D LINK
This procedure updates the field list for the incoming
transport of the running subprocess.
If the init switch has been set to TRUE the field list
is initialized:
- No. of fields is set to NO ̲OF ̲INP ̲FIELDS
- FILED ̲GROUP ̲ID is updated for each filed
RECORD ̲LENGTH and FIELD ̲BYTE ̲ADDRESS is reset.
If init switch is false the RECORD ̲LENGTH of the specified
field(R2) is incremented with the content of R3.
If INIT ̲SWITCH is false and FIELD ̲ID differs from one
of the EMF ̲FIELDS, the procedure resets the
RECORD ̲LENGTH for all fields within the FIELD ̲LIST.
4.2.5.6.2.5 C̲r̲e̲a̲t̲e̲ ̲C̲I̲F̲ ̲F̲o̲r̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲R̲E̲A̲T̲E̲ ̲T̲R̲S̲ ̲C̲I̲F̲
(R0 C D PROFILE.LEAST
R1 D PROFILE.MOST
R2 D
R3 C D Pointer to queue ref. for new CIF
R4 D
R5 D
R7 R Pointer to Transport Parameters
R6) C D LINK
This procedure creates a CIF according to the information
specified in an external declared
FIELD ̲INFORMATION data structure which shall be initialized
before the call.
The procedure moves the field into the VIEW ̲ATTRIBUTES
of the running subprocess.
When the CIF has been created, it is opened for write
operations.
The INP ̲FIELD ̲LIST is made ready for write operations.
The INP ̲ACP ̲PARAMS are initialized in order ro receive
a new message.
4.2.5.6.2.6 W̲r̲i̲t̲e̲ ̲I̲n̲t̲o̲ ̲C̲I̲F̲ ̲F̲o̲r̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲W̲R̲I̲T̲E̲ ̲T̲R̲S̲ ̲C̲I̲F̲
(R0 D
R1 C D CLOSED ̲OPEN
R2 C D BOOLEAN(CORRECTION ̲FIELD ̲ACTIVE)
R3 D
R4 D
R5 D
R7 R Pointer to Transport Parameters
R6) C D LINK
This procedure executes a write operation into a CIF
as prescribed by the field list of the running subprocess.
If the close switch is equal to closed the procedure
also writes the ACP ̲PARAMETERS into the ACP ̲PARAMETER
̲
FIELD. If the CORRECTION ̲FIELD is passive (indicated
by R2) the procedure will indicate this in the INP
̲FIELD ̲
LIST and the INP ̲ACP ̲PARAMS before write operation
is activated. After completion of the write operation
the CIF is closed.
When the write operation has taken place the field
list is initialized.
4.2.5.6.2.7 S̲e̲n̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲T̲o̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲E̲N̲D̲ ̲M̲S̲G̲ ̲T̲O̲ ̲A̲N̲A̲L̲Y̲S̲I̲S̲
(R0 C D Maintype
R1 C D Flags
R2 C D INF
R3 C D Pointer to queue ref. for ANQ
R4 D
R5 D
R7 R Pointer to Transport Parameters
R6) C D LINK
This procedure will send a message stored in a CIF
to the ANALYSIS.
SEND ̲PARAMS is updated as specified by CALL ̲PARAMETERS.
After send a checkpoint is made at the analysis. This
function also dismantles the view from the queue at
which the CIF has been created (CCQ1).
4.2.5.6.3 M̲e̲s̲s̲a̲g̲e̲ ̲C̲h̲e̲c̲k̲ ̲M̲o̲d̲u̲l̲e̲
This module supplies a number of common procedures
used by the incoming transport.
The following functions are included:
- Check of too long line
- Check of characters between two messages (max
100)
- Check of consecutive identical characters (max
140)
- Check of oversized message
- Check of illegal ECTF (missing BT)
- Check of consecutive SOTF
- Preemption handling
- Page handling
4.2.5.6.3.1 C̲h̲e̲c̲k̲ ̲T̲o̲o̲ ̲L̲o̲n̲g̲ ̲L̲i̲n̲e̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲H̲E̲C̲K̲ ̲T̲O̲O̲ ̲L̲O̲N̲G̲ ̲L̲I̲N̲E̲
(R0 C D Max line length
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R Pointer to Transport Parameters
R6) C D LINK
This procedure checks if the line specified by the
data structure INPUT ̲LINE contains more characters
than specified by max.line length.
If so a report is generated for the supervisor's printer
and the INPUT ̲ERROR ̲MASK (for the analysis) is updated
with a TOO ̲LONG ̲LINE indication.
The check is not done for the text part of a data message.
4.2.5.6.3.2 C̲h̲e̲c̲k̲ ̲1̲0̲0̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲s̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R Pointer to Transport Parameters
R6) C D LINK
This procedure counts the characters received between
two messages.
If more than MAX ̲CHAR ̲BETWEEN ̲MSG is received a report
is generated for the supervisor's printer.
4.2.5.6.3.3 C̲h̲e̲c̲k̲ ̲I̲d̲e̲n̲t̲i̲c̲a̲l̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲s̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲D̲E̲N̲T̲I̲C̲A̲L̲ ̲C̲H̲A̲R̲ ̲C̲H̲E̲C̲K̲
(R0 D
R1 C D INIT ̲SWITCH (BOOLEAN)
R2 C D No. of characters to be checked
R3 D
R4 D
R5 D
R7 R Pointer to Transport Parameters
R6) C D LINK
This procedure checks if a max. limit of consecutive
characters are received within a message.
If so the following actions take place:
- The INPUT ̲ERROR ̲MASK (for the analysis) is updated
with IDENTICAL ̲CHAR.
- The INPUT ̲CTR ̲MASK is updated with MESSAGE ̲READY
+ AUTOMATICALLY ̲TERMINATED indication.
- A report is generated for the supervisor's printer.
The check is not performed for the text part of a data
message.
4.2.5.6.3.4 O̲v̲e̲r̲s̲i̲z̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲H̲E̲C̲K̲ ̲O̲V̲E̲R̲S̲I̲Z̲E̲D̲ ̲M̲E̲S̲S̲A̲G̲E̲
(R0 D
R1 D
R2 D
R3 C D IOC ̲RECORD ̲LENGTH
R4 D
R5 D
R7 R Pointer to Transport Parameters
R6) C D LINK
This procedure will check if the characters received
for a specific message exceeds the maximum number of
characters allowed for a message.
If so a report is transmitted to the supervisor's printer
and the INPUT ̲ERROR ̲MASK is updated with OVERSIZED
̲MESSAGE indication. The INPUT ̲CTR ̲MASK is updated with
indication for: MESSAGE ̲READY and AUTOMATICALLY ̲TERMINATED.
4.2.5.6.3.5 C̲h̲e̲c̲k̲ ̲I̲l̲l̲e̲g̲a̲l̲ ̲E̲O̲T̲F̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲L̲L̲E̲G̲A̲L̲ ̲E̲O̲T̲F̲ ̲C̲H̲E̲C̲K̲
(R1 D
R2 D
R4 D
R7 R Pointer to Transport Parameters
R6) C D LINK
This procedure examines if the EOTF has been received
during input of the text field. This means that the
BT sequence from format line 13 is missing.
4.2.5.6.3.6 C̲h̲e̲c̲k̲ ̲C̲o̲n̲s̲e̲c̲u̲t̲i̲v̲e̲ ̲S̲O̲T̲F̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲O̲N̲S̲E̲C̲U̲T̲I̲V̲E̲ ̲S̲O̲T̲F̲ ̲C̲H̲E̲C̲K̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R Pointer to Transport Parameters
R6) C D LINK
This procedure examines if two consecutive SOTF sequences
have been received without intervenient EOTF sequence.
If so a report is transmitted to the supervisor's printer.
4.2.5.6.3.7 P̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
E̲x̲p̲o̲r̲t̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲P̲A̲G̲E̲ ̲H̲A̲N̲D̲L̲I̲N̲G̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R Pointer to Transport Parameters
R6) C D LINK
BOOLEAN
This procedure supplies the functions related to the
detection of an incoming message.
4.2.5.6.3.8 C̲h̲e̲c̲k̲ ̲P̲r̲e̲e̲m̲p̲t̲i̲o̲n̲
(R0 D
R1 D
R2 D
R3 D
R4 D
R5 D
R7 R Pointer to Transport Parameters
R6) C D LINK
BOOLEAN
This procedure checks if the line specified by the
data structure INPUT ̲LINE contains the preemption sequence
defined by ZPH ZPH. If so the following actions take
place:
- The INPUT ̲ERROR ̲MASK (for the analysis) is updated
with PREEMPTED ̲MSG indication.
- The INPUT ̲CTR ̲MASK is set to MESSAGE ̲READY + AUTOMATICALLY
̲TERMINATED.
- A report is generated for the supervisor's printer.
EXITS: TRUE- Preemption detected
FALSE- Preemption not detected.
4.2.5.7 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
a) I̲T̲S̲ ̲t̲o̲ ̲A̲A̲S̲
- Incoming Message for Analysis (ref. ICD 009
sec. 5.6.1)
b) I̲T̲S̲ ̲t̲o̲/̲f̲r̲o̲m̲ ̲T̲C̲S̲
- Operations between the IT ̲COROUTINE and the
TC ̲COROUTINE have all been defined in section
4.2.3.7 for each type of transport.
c) I̲T̲S̲ ̲t̲o̲ ̲T̲E̲P̲
Reports (ref. CPS/ICD/009, sec. 5.2.2.13). See
also section 4.2.3.6.4.
d) I̲T̲S̲ ̲t̲o̲ ̲L̲O̲G̲
Channel Discontinuity Log
(ref. CPS/ICD/009, sec. 5.4.2.3)
Note: The ITS stores the log information in a
THP ̲LOG ̲RECORD and sends a record pointer
to TCS, which takes care of the communication
with LOG PACKAGE.
e) I̲T̲S̲ ̲t̲o̲ ̲O̲A̲S̲
- Incoming Message for OCR Analysis (ref.ICD
009 sec.
