top - download
⟦e0673733a⟧ Wang Wps File
Length: 60693 (0xed15)
Types: Wang Wps File
Notes: CPS/SDS/033
Names: »1697A «
Derivation
└─⟦af82dd301⟧ Bits:30006082 8" Wang WCS floppy, CR 0127A
└─ ⟦this⟧ »1697A «
WangText
…00……00……00……00……00…
…02……00……00…
…07…
…0a…
…0f… …09… …0f……05……01……05……02……05…
…05… …05……05……05……06……05……0b……05……0c……06……01……06……07……06……08……06……0f……07……01……07……02……07……07……07……08……07……0e……07……0f……08… …08……05……08……06……08……0b……09……00……09……06……0b…
…0b……07……1c……00……1c……01……1c… …1c……08……1c……09……1c……0b……86…1 …02… …02… …02…
…02…CPS/SDS/033
…02…KNB/831101…02……02…
TRAFFIC HANDLING
DETAILED DESIGN SPECIFICATION…02…ISSUE 1…02…CAMPS
4.2.1 A̲C̲P̲1̲2̲7̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲
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̲
The ACP127 Analysis Subpackage receives messages for
analysis from the Transport Subpackage.
The messages are received in an External message format
(mainly ACP127) and delivered to other packages in
an Internal message format after analysis.
Depending on the originator of the message the analysis
is subdivided into three parts:
- Incoming analysis
- Complete analysis
- PTR analysis
Independent of the analysis type are the common functions:
- Format Line Control and Internal Format Conversion.
The functional Break-down depicted in figures 4.2.1.1-1
to 4.2.1.1-5 describes how the functions are interrelated
to each other.
4.2.1.1.1 C̲o̲m̲m̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The functions depicted in figures 4.2.1.1-3 and 4.2.1.1-4
are the common functions, which are:
a) Format Line control of message types in ACP127-format.
b) Detection of Garble characteristics based on Format
Line Control.
c) Detection of inconsistency between logically related
parameters.
d) Detection of errors and acceptable deviations into
each format-line.
e) Detection of pilot
f) Detection of readdressed messages
g) Creation of an error-list (ACP-PARAMETER ̲FIELD)
to be presented together with the erroneous message
in case of garble correction
h) Creation of a Routing-list (PLA ̲RI ̲FIELD) to be
used for routing-purposes by the ACP127 conversion
subpackage for outgoing messages.
i) Creation of a list of addresses (ADDRESS ̲FIELD)
used when presenting the message in format E1.
4.2.1.1.2 I̲n̲c̲o̲m̲i̲n̲g̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The message originators for incoming analysis are NICS
TARE, TRC/Point-to-Point, SCARS or CCIS.
Besides the common functions described in section 4.2.1.1.1
the following functions as depicted in figures 4.2.1.1-1,
4.2.1.1-2 and 4.2.1.1-5 are provided in this analysis:
a) Reception Error Handling based upon information
received from the Transport Subpackage.
That is:
- 140 identical characters
- halted message
- preempted message
- oversized message
- too long line
- received TSN too low
b) Format Line Control of messages received in SCARS/CCIS
E1 format
- detection of E1 pilot
- detection of garble characteristics
- detection of acceptable deviations and errors
associated to the E1 Format lines.
c) Handling of message types in E1 format received
from SCARS or CCIS
- Already released message
- message for release (CCIS only)
- message for coordination (CCIS only)
- comments
- VDU-pages
d) Handling of received abbreviated service messages
- channel number reset
- channel check
- channel continuity
- channel test
- channel test reply
- channel open
- channel close
- flash acknowledge
e) Initiate automatic generation of ASM in case of:
- receipt of messages with precedence flash (Flash
Acknowledge)
- receipt of channel test
(channel test reply ASM)
f) Relaying of messages containing relay instructions.
g) Log, statistics and retrieval keys
- invalid message log
- incoming message log
- statistics incoming message
- retrieval keys incoming message
h) Final route determination:
- Encrypted messages to the dedicated PTP
- Service messages and not recognized ASM types
to the supervisor position.
- Plaindress and Data Messages to message distribution
for distribution to terminal positions
- Released message from CCIS to the ACP127 conversion
subpackage for processing as an outgoing message.
- Comments and VDU-pages from CCIS to MDP for
distribution to a terminal position indicated
by a SCD in FL D1 or FL D2.
- Message for coordination to MDP for distribution
to a terminal prepare position indicated by
an SCD in FL D4. This procedure will be executed
so that the receiver of the message takes the
responsibility (becomes the originator).
- Message to be released by CAMPS. This function
will be executed by directing the message to
a release position via MDP based upon the SCD
in FL D3. The releaser takes responsibility
for the message by becoming the message originator.
- Illegal messages (garbled or with format line
errors) to the incoming message service position
for garble correction.
- Messages preceded with a pilot and messages
with too low or missing TSN to the incoming
MSO for inspection.
g) In case MSO invocation had been needed the MSO
first involved will be activated for further corrections.
4.2.1.1.3 C̲o̲m̲p̲l̲e̲t̲e̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The message originators of complete messages are the
low speed teleprinters operating as PTR's.
Besides the common functions described in section 4.2.1.1.1
the main functions are as depicted in figure 4.2.1.1-1.
The complete entered message types are always considered
outgoing and will therefore after a successful analysis
be queued to the ACP127 conversion subpackage for onward
processing.
There are no special individual functions to be detailed
described; however, it shall be emphasized that the
complete analysis compared with the incoming analysis
do not perform:
- relaying
- ASM-handling
- flash acknowledge
- log, statistics and retrieval-keys
4.2.1.1.4 P̲T̲R̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The originator of a message for PTR analysis is the
dedicated PTR. Besides the common functions described
in section 4.2.1.1.1 the main functions are as depicted
in figure 4.2.1.1-1.
The messages received from the dedicated PTR are, depending
on whether FL1 is complete or not, considered respectively
incoming or outgoing.
The incoming message is considered a codress message
that has been off-line decrypted and now is entered
in plaindress still containing FL10 with the group
count and is bound for internal distribution after
analysis. Retrieval keys will be delivered as if the
message had been incoming
The outgoing message is considered a plaindress message
that has been punched at the PTP, off-line encrypted
and now entered in codress or encrypted plaindress
for analysis, conversion and finally transmission.
The PTR analysis is dedicated above described message
types.
FIGURE 4.2.1.1-1…01…FUNCTIONAL BREAK-DOWN…01…ACP127-ANALYSIS
FIGURE 4.2.1.1-2…01…FUNCTIONAL BREAK-DOWN…01…E1 ANALYSIS CONTROL
FIGURE 4.2.1.1-3…01…FUNCTIONAL BREAK-DOWN…01…ACP127-ANALYSIS CONTROL
FIGURE 4.2.1.1-4…01…FUNCTIONAL BREAK-DOWN…01…INTERNAL FORMAT CONVERSION
FIGURE 4.2.1.1-5…01…FUNCTIONAL BREAK-DOWN…01…ASM HANDLING
4.2.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The ACP127 Analysis Subpackage is implemented in one
process (Analysis Process) who serves one queue (Analysis
Queue).
The Analysis Queue (ANQ) consists of 4 subqueues from
which the Analysis Process will receive its input.
Input to the Analysis Process will be executed in accordance
with the subqueue-organization; that is commands will
be executed before messages.
a) C̲o̲m̲m̲a̲n̲d̲ ̲S̲u̲b̲q̲u̲e̲u̲e̲
The Command subqueue will contain commands from
SSC for Close-down etc.
b) R̲e̲s̲p̲o̲n̲s̲e̲ ̲S̲u̲b̲q̲u̲e̲u̲e̲
The Response subqueue is used for messages input
to Analysis with a Reply Request.
In this case after reentering of messages after
garble correction or message inspection.
c) T̲r̲a̲f̲f̲i̲c̲ ̲S̲u̲b̲q̲u̲e̲u̲e̲.
The Traffic Subqueue is used for message input
from the Transport subpackage.
d) L̲o̲g̲ ̲C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲ ̲S̲u̲b̲q̲u̲e̲u̲e̲
The Log Completion subqueue will contain QEL's
indicating completion of incoming message Log.
The structure of the Analysis Process is depicted in
figure 4.2.1.2-1.
These drawings illustrate the break-down of the Analysis
Process into modules.
A detailed description of each module will be given
in section 4.2.1.4.
Fig. 4.2.1.2-1…01…SOFTWARE STRUCTURE ANALYSIS PROCESS
4.2.1.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
The Data Flow and Control Logic of the Analysis Subpackage
is to a great extent equivalent to the incoming message
flow of CAMPS.
The following description in this section will concentrate
on:
- Message Types
- Normal Message Flow
- Special Message Flow
- Message Control Logic
4.2.1.3.1 M̲e̲s̲s̲a̲g̲e̲ ̲T̲y̲p̲e̲s̲
The message-type of a message forwarded for analysis
can be extracted via the parameters delivered from
the Transport subpackage in the ACP-Parameter Field
and via the QEL ̲INFO; these are:
SC ̲MESSAGE ̲TYPE
LINE ̲OFFSET ̲FL5
LINE ̲OFFSET ̲FL10
NO ̲OF ̲TEXT ̲LINES
QEL ̲HEADER.TFC ̲WORD.DATA
QEL ̲HEADER.SUBTYPE
Using these parameters it is possible to determine
the message type before the analysis begins; the only
exceptions are the service message types that are recognized
via the SIC = SVC of FL12B.
For analysis purpose the following graduation into
message-types is used.
B̲e̲f̲o̲r̲e̲ ̲a̲n̲a̲l̲y̲s̲i̲s̲
- ASM
- Abbreviated
- Codress
- Plaindress
- Encrypted plaindress
- Comment
- VDU-page
A̲f̲t̲e̲r̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
See fig. 4.2.1.3.1-1 for message-types after analysis.
The message-types depicted are identical to the QEL
̲HEADER.MAINTYPE; these maintypes are assigned after
a successful analysis.
The Flags illustrate:
- all messages entered to analysis are considered
as NON CAMPS originated (incl. the complete entered
messages via PTR)
- the message-types that can contain relay-instructions.
- the message-types that can be preceeded with a
physical pilot
- the message-type that can be subject for readdressal.
(containing at least 2 FL5's)
The subtype identifies the originating source.
- From NICS ̲TARE
- From TRC ̲Point ̲to ̲point
- From SCARS
- From CCIS
- From NORMAL ̲PTR
- From DEDICATED ̲PTR
Depending on this originating source (in the interface
Transport Subpackage to Analysis Subpackage represented
via the QEL ̲HEADER.MAINTYPE as "unidentified Item from....")
some message-types are pre-dedicated.
- message received from CCIS are always in CCIS ̲E1
̲format or CCIS ̲E1 ̲modified ̲Format (the last category
= ASM's)
- messages entered via the dedicated PTR can only
be Plaindress (incoming) or Encrypted Plaindress/Codress
(Outgoing)
- VDU ̲PAGES and comments can only be received from
SCARS or CCIS.
Fig. 4.2.1.3.1-1…01…MESSAGE ̲TYPES FOR ANALYSIS
4.2.1.3.2 N̲o̲r̲m̲a̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲l̲o̲w̲
The normal message flow is associated to the message-type
and the originating source described in section 4.2.1.3.1.
In general messages received from NICS ̲TARE or TRC/Point
̲to ̲points are considered as incoming to CAMPS while
messages received from SCARS, CCIS and the Normal ̲PTR
are considered as outgoing; messages entered via the
dedicated PTR is depending on the message-type (FL1
complete or not) either incoming or outgoing.
Depending on the message-type the destination source
after analysis is in general for incoming messages:
- Encrypted messages for Punch
- Service messages for Supervisor
- Other messages for Distribution
Outgoing messages are after analysis forwarded for
conversion.
In the following a more detailed description will be
supplied related to each originating source.
4.2.1.3.2.1 M̲e̲s̲s̲a̲g̲e̲s̲ ̲o̲r̲i̲g̲i̲n̲a̲t̲e̲d̲ ̲f̲r̲o̲m̲ ̲N̲I̲C̲S̲ ̲T̲A̲R̲E̲ ̲o̲r̲ ̲T̲R̲C̲/̲P̲o̲i̲n̲t̲
̲t̲o̲ ̲P̲o̲i̲n̲t̲
See fig. 4.2.1.3.2-1 for details.
The received message is always considered as incoming
to CAMPS.
After a successful analysis the messages are sent to
the destination-source as depicted in accordance with
the message-type. (For distribution, for supervisor
or for punch). If the message received contains T-instructions
(FL4) with a CAMPS relevant RI, the message will be
relayed via the Conversion Subpackage.
If the message contains RI's in FL2 belonging to SCARS
and/or CCIS the message will be sent for conversion
to be distributed for SCARS/CCIS.
Should the message contain CAMPS non relevant RI's
in FL2, then it will be rejected to MSO for garble
correction; should it, however, be reentered from garble
correction still containing non CAMPS relevant RI's
in FL2 (misrouted/missent) then it will be sent for
conversion as an outgoing message.
Fig. 4.2.1.3.2-1…01…MESSAGE FROM NICS ̲TARE OR …01…POINT ̲TO ̲POINT
4.2.1.3.2.2 M̲e̲s̲s̲a̲g̲e̲s̲ ̲o̲r̲i̲g̲i̲n̲a̲t̲e̲d̲ ̲f̲r̲o̲m̲ ̲S̲C̲A̲R̲S̲
See fig. 4.2.1.3.2-2 for details. The received message
is mainly considered as outgoing from CAMPS but the
possibility of an incoming message to CAMPS is not
excluded.
Comments and VDU-pages are always considered as incoming
to CAMPS.
- Comments for distribution
- VDU-pages for UMAN (display-file).
Should the received message from SCARS contain CAMPS
relevant RI's in FL2, the procedures previously described
for an incoming message will be executed, otherwise
the message will be sent for conversion as an outgoing
message (or both). Relay-instructions will be examined
but no relaying performed based on such instruction.
A message preceeded with a pilot will be sent to MSO
for inspection only if the associated message contains
CAMPS relevant RI's in FL2.
A suspected duplicate Comment or VDU-page is determined
by means of the message indicator received in the first
data-frame; it will always be inspected by the MSO.
Fig. 4.2.1.3.2-2…01…MESSAGE FROM SCARS
4.2.1.3.2.3 M̲e̲s̲s̲a̲g̲e̲s̲ ̲f̲r̲o̲m̲ ̲C̲C̲I̲S̲
See fig. 4.2.1.3.2-3 for details. The received message
from CCIS is always in CCIS-E1-format. The destination
source for VDU-pages and comments are as described
for messages from SCARS.
An abbreviated Service Message enveloped in a modified
̲E1 ̲format (channel-check and Final-Number-message)
is used internal to the Traffic Handling Package. The
remaining message types are all of a Plaindress-type
and can be subdivided into:
- released messages
- messages for release
- messages for coordination
- message for distribution
A released message will be sent for conversion to be
routed and formatted into ACP127 before transmission.
A message for release and a message for coordination
will be sent for distribution to be delivered to the
specified SCD, if the message-type is plaindress or
plaindress-data; otherwise the message will be rejected
for garble correction.
Messages not containing above described characteristics
will be distributed as normal incoming messages in
accordance with the message-type (in CCIS E1-Format)
A suspected duplicate message from CCIS is determined
by means of the message indicator received in the first
data-frame: such message is always sent for inspection
at a MSO position except if the message is already
released and contains no local pla's.
Fig. 4.2.1.3.2-3…01…MESSAGE FROM CCIS
4.2.1.3.2.4 M̲e̲s̲s̲a̲g̲e̲s̲ ̲f̲r̲o̲m̲ ̲n̲o̲r̲m̲a̲l̲ ̲P̲T̲R̲
See fig. 4.2.1.3.2-4 for details. Messages originated
from a normal PTR will be considered as outgoing and
sent for conversion after a successful analysis. Should
FL2 contain CAMPS relevant RI's it will be rejected
to MSO for garble correction.
4.2.1.3.2.5 M̲e̲s̲s̲a̲g̲e̲s̲ ̲f̲r̲o̲m̲ ̲d̲e̲d̲i̲c̲a̲t̲e̲d̲ ̲P̲T̲R̲
See fig. 4.2.1.3.2-5 for details. A message entered
via the dedicated PTR with a complete FL1 is considered
as incoming and will be sent to MDP for distribution;
the message is a previously analyzed encrypted message
that now has been reentered after decryption; if the
message contains non CAMPS RI's these will be ignored
(delivery has previously been done to these RI's).
A message entered with an incomplete FL1 is considered
as an encrypted outgoing message and will be sent for
conversion after analysis; the message is a previously
punched Plaindress message for off-Line encryption
that now is reentered in an encrypted format.
Fig. 4.2.1.3.2-4…01…MESSAGE FROM NORMAL PTR
Fig. 4.2.1.3.2-5…01…MESSAGE FROM DEDICATED PTR
4.2.1.3.3 S̲p̲e̲c̲i̲a̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲l̲o̲w̲
The special Message flow is associated to the involvement
of MSO for garble correction or inspection before further
analysis processing.
4.2.1.3.3.1 G̲a̲r̲b̲l̲e̲ ̲C̲o̲r̲r̲e̲c̲t̲i̲o̲n̲
A message can be classified as garbled in 4 stages:
- at reception
- before analysis
- during analysis
- after analysis
a) A̲t̲ ̲r̲e̲c̲e̲p̲t̲i̲o̲n̲
During the reception procedures the following types
of errors might have been detected:
- oversized message
- too long line
- No EOTF
- more than 140 identical characters
- halted message
Such errors are reported to the Analysis Process
via the QEL ̲INFO.
b) B̲e̲f̲o̲r̲e̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
The analysis will start with a message type determination;
if this determination ends with the following result,
the message will be considered as garbled:
- not possible to determine message-type
- message-type not valid for that originating-source
- the message contains a text-ending-field with
corrections.
c) D̲u̲r̲i̲n̲g̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
During analysis the following types of errors can
be detected
- errors into format lines
- not expected format line - inconsistency
between
contents
of
format-lines
- logical invalid data.
d) A̲f̲t̲e̲r̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
The garble detects after analysis is of logical
nature and associated to originator/destination.
- incoming message with non CAMPS relevant RI
FL2.
- outgoing message with CAMPS relevant RI FL2.
- Incoming plaindress message without any local
PLA.
4.2.1.3.3.2 M̲e̲s̲s̲a̲g̲e̲ ̲I̲n̲s̲p̲e̲c̲t̲i̲o̲n̲
MSO will be invocated for inspection of a message in
the following situations:
- Pilot inspection
- TI inspection
The function is to inspect the message and decide whether
it shall be reentered for further processing or be
stopped; the message contents will not be changed.
a) P̲i̲l̲o̲t̲ ̲I̲n̲s̲p̲e̲c̲t̲i̲o̲n̲
Is applicable to an incoming message preceeded
with a pilot or indicated to be preceeded with
such; an incoming message is previously defined
as a message considered as incoming to CAMPS and
in this situation more precise:
- messages received from NICS ̲TARE
- messages received from TRC/POINT ̲to ̲point
- messages containing CAMPS relevant RI's FL2
received from SCARS
- messages received from CCIS for distribution
at CAMPS
MSO can retrieve the message using SSN and/or DTG
in order to detect a redundant message.
b) T̲I̲ ̲I̲n̲s̲p̲e̲c̲t̲i̲o̲n̲
Inspection of the Transmission Identifier is applicable
to any error related to the Designator or Transmission
serial Number of FL1 detected during reception
procedures
- missing designator
- illegal designator
- unknown designator
- missing TSN
- Too low TSN
- Too high TSN
The correct expected TI has been assigned the message
automatically; the supplementary error-code displayed
in front of FL1 will explain the reason causing
the inspection. MSO has the possibility to examine
the discontinutity Log or the Supervisor Reports
in order to detect a redundant message.
4.2.1.3.4 M̲e̲s̲s̲a̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
When a QEL referencing a message view has been
collected from the ANQ, all relevant ACP-fields
will be read (1 disc access)
ACP ̲parameter Field
ACP ̲header Field
Text ̲field (if present)
ACP ̲Text ̲ending ̲field (if present)
See fig. 4.2.1.3.4-1 for details associated to
specified message types.
R = read
W = write
4.2.1.3.4.1 R̲e̲a̲d̲ ̲m̲e̲s̲s̲a̲g̲e̲
The Text ̲field might not be present if the message
is received garbled (no "BT" detected) or because
the message contains no BT's.
- Abbreviated Service Message
- Comment
- VDU-page
If it contains a text-field only the first 500
characters will be read (approx. 8 lines text)
The text-ending-field will be read in case the
message is reentered after garble correction; it
contains the SSN and maybe group count. (FL 14
+ FL 15) to be analyzed again.
4.2.1.3.4.2 W̲r̲i̲t̲e̲ ̲m̲e̲s̲s̲a̲g̲e̲
After finished analysis the following fields will
normally be written into the view received, before
it is forwarded to its destination sources:
administration ̲field
address ̲field
PLA ̲RI ̲field
The Text-field will be separated from the ACP ̲header
and written out if ASM, Comment or VDU-page.
No address ̲field and PLA ̲RI ̲field will be written
if comment or VDU ̲page.
If the message has been reentered from garble correction
the ACP ̲parameter ̲field will in general also be
written in case the message should be for punch.
If the message is determined to be garbled only
the administration field will be written containing
as a minimum the information for a deletion log.
4.2.1.3.4.3 M̲e̲s̲s̲a̲g̲e̲ ̲V̲i̲e̲w̲
In principle the view received will be updated
with missing fields and then forwarded to its destination
- the analysis process will normally not create
new Views.
However, there is one exception; if a message has
been sent for garble correction and again is reentered,
the corrected message contains an incomplete ACP
̲parameter ̲field. Therefore it is necessary in this
situation to create a new view and after analysis
to update this view with a new ACP ̲parameter ̲Field.
See the normal conditions and special conditions
in the flow depicted in figure 4.2.1.3.4-2.
Fig. 4.2.1.3.4-1…01…MESSAGE FIELDS
Fig. 4.2.1.3.4-2…01…MESSAGE CONTROL LOGIC
4.2.1.4 M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.1.4.1 A̲n̲a̲l̲y̲s̲i̲s̲ ̲M̲o̲d̲u̲l̲e̲
4.2.1.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̲
Analysis of messages received from NICS TARE, TRC/Point
to point, SCARS, CCIS or a Paper Tape Reader.
During the analysis the received messages are converted
from the external message format into the internal
message format. Ref. functional description 4.2.1.1.
4.2.1.4.1.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Ref. interface description 4.2.1.7
4.2.1.4.1.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
See fig. 4.2.1.4-1 for structure Analysis Module.
a) I̲n̲i̲t̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲ ̲M̲o̲d̲u̲l̲e̲
ref. 4.2.1.4.2
b) A̲n̲a̲l̲y̲s̲i̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲M̲o̲d̲u̲l̲e̲
ref. 4.2.1.4.7
c) F̲i̲n̲i̲s̲h̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲ ̲M̲o̲d̲u̲l̲e̲
ref. 4.2.1.4.25
4.2.1.4.1.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
ref. Data descriptions 4.2.1.5
4.2.1.4.1.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The Analysis Module is the main-module of the ACP127
̲analysis Subpackage. After initialization the following
modules are activated sequentially:
- Init Analysis
- Analysis Control
- Finish Analysis
Init Analysis will prepare the received message for
analysis whereafter Analysis Control will perform the
actual analysis ending with Finish Analysis for updates
of IMF ̲fields and delivery to other Subpackages.
The Analysis Control Module is not activated in case
the wait ̲queue indicates the command ̲subqueue or the
message has been received garbled. In the first case
a Close-down command has been received from the ANQ
or the QEL received/the View received is erroneous.
Fig. 4.2.1.4-1…01…STRUCTURE ANALYSIS MODULE
A̲N̲A̲L̲Y̲S̲I̲S̲
PRE ̲INITIALIZATION
WAIT ̲QUEUE = MAIN
LOOP FOREVER
INIT ̲ANALYSIS
WAIT ̲QUEUE = COMMAND
SEND ̲FOR ̲GARBLE
SEND ̲FOR ̲INSPECTION
or
PREEMPTED ̲MSG?
ANALYSIS ̲CONTROL
FINISH ̲ANALYSIS
END FOREVER LOOP
EXIT
4.2.1.4.2 I̲n̲i̲t̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲ ̲M̲o̲d̲u̲l̲e̲
4.2.1.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̲
The functions of the Init Analysis Module are:
- Reception of the next QEL from the Analysis Queue.
- Input of the message referenced via the QEL into
the Analysis Buffer.
- Raw ̲analysis of the header and text-ending after
reentering of a garbled message.
- Inspection of error detected during reception procedures.
- Determination of message ̲type for use during the
Analysis Control procedures.
4.2.1.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) INIT ̲ANALYSIS
b) INIT ̲ANALYSIS (R6)
4.2.1.4.2.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
See fig. 4.2.1.4-2 for structure Init Analysis
module.
a) Q̲E̲L̲ ̲R̲e̲c̲e̲p̲t̲i̲o̲n̲ ̲M̲o̲d̲u̲l̲e̲
ref. 4.2.1.4.3 for description
b) V̲i̲e̲w̲ ̲R̲e̲c̲e̲p̲t̲i̲o̲n̲ ̲M̲o̲d̲u̲l̲e̲
ref. 4.2.1.4.4 for description
c) G̲a̲r̲b̲l̲e̲ ̲R̲e̲e̲n̲t̲e̲r̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
ref. 4.2.1.4.5 for description
d) R̲e̲c̲e̲p̲t̲i̲o̲n̲ ̲E̲r̲r̲o̲r̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
Examines the error-code supplied by the Incoming
Transport Subpackage and flags the message for
garble, for inspection or as preempted.
e) M̲e̲s̲s̲a̲g̲e̲ ̲T̲y̲p̲e̲ ̲D̲e̲t̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲ ̲M̲o̲d̲u̲l̲e̲
ref. 4.2.1.4.6 for description
4.2.1.4.2.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
QEL DATA (4.2.1.5.3)
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
WAIT ̲QUEUE
QEL ̲ATTRIBUTE
SEND ̲FOR ̲INSPECTION (m)
SEND ̲FOR ̲GARBLE ̲CORRECTION (m)
PREEMPTED ̲MSG (m)
RECEIPT ̲ERROR (NO ̲ERROR,
TI ̲INSPECTION,
CTR ̲CHAR,
TOO ̲LONG ̲LINE,
NO ̲EOTF,
MISSING ̲BT,
OVERSIZED ̲MSG,
HALTED ̲MSG,
IDENTICAL ̲CHAR,
PREEMPTED,
BLOCK ̲ERROR)
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
VALID ̲QEL: INTEGER
4.2.1.4.2.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The Init Analysis Module will start its processing
by activating the QEL ̲Reception Module from where it
will return with the next QEL from the Analysis Queue;
this is also the waiting point in case the Analysis
Queue is empty. If the QEL received it not of the selfcontained
type (SSC-command/Log Completion) and it is valid,
the view Reception Module is activated - in case an
error occurred during this procedure, the Wait-queue
is set to the Command-queue where the QEL-reception
module next will be waiting upon a SSC-command.
A message reentered from Garble Correction will be
examined and details collected for the final Message-type
Determination. But if the message during above described
procedure or by the reception procedures (Incoming
Transport Subpackage) should be classified as garble
there is no need for message Type determination because
the message will be forwarded to garble correction
or be discarded after an invalid log (Finish Analysis)
Fig. 4.2.1.4-2…01…STRUCTURE INIT ANALYSIS MODULE
I̲N̲I̲T̲ ̲A̲N̲A̲L̲Y̲S̲I̲S̲
SEND ̲FOR ̲PARAMS, WRITE ̲PARAMS = FALSE
LOOP RECEPTION:
QEL ̲RECEPTION
WAIT ̲QUEUE = COMMAND? EXIT LOOP
VIEW ̲RECEPTION ( ) (CC)
WAIT ̲QUEUE = COMMAND EXIT LOOP
OR CC = OK?
END RECEPTION ̲LOOP
QEL ̲HEADER.SUBTYPE = FOR ̲ANALYSIS
OR FROM ̲INSPECTION?
GARBLE ̲REENTERING
QEL ̲HEADER.FLAG = ZERO?
RECEPTION ̲ERROR
MESSAGE ̲TYPE ̲DETERMINATION
RETURN
R̲E̲C̲E̲P̲T̲I̲O̲N̲ ̲E̲R̲R̲O̲R̲
RECEIPT ̲ERROR = QEL ̲HEADER.FLAG
CASE RECEIPT ̲ERROR OF:
TI ̲INSPECTION: SEND ̲FOR ̲INSPECTION = TRUE
CTR ̲CHAR: SEND ̲FOR ̲GARBLE = TRUE
TOO ̲LONG ̲LINE: SEND ̲FOR ̲GARBLE = TRUE
NO ̲EOTF: SEND ̲FOR ̲GARBLE = TRUE
MISSING ̲BT: SEND ̲FOR ̲GARBLE = TRUE
OVERSIZED ̲MSG: SEND ̲FOR ̲GARBLE = TRUE
HALTED ̲MSG: SEND ̲FOR ̲GARBLE = TRUE
IDENTICAL ̲CHAR: SEND ̲FOR ̲GARBLE = TRUE
PREEMPTED: PREEMPTED ̲MSG = TRUE
BLOCK ̲ERROR: SEND ̲FOR ̲GARBLE = TRUE
END RECEIPT ̲ERROR CASE
RETURN
4.2.1.4.3 \ Q̲E̲L̲ ̲R̲e̲c̲e̲p̲t̲i̲o̲n̲ ̲M̲o̲d̲u̲l̲e̲
4.2.1.4.3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Input of the next QEL waiting in the analysis queue.
Validation of the QEL ̲HEADER in relation to the
reception subqueue
- Commands
- Log Completions
- QEL's referencing a message-view
4.2.1.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) QEL ̲RECEPTION
b) QEL ̲RECEPTION (R6)
4.2.1.4.3.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
See fig. 4.2.1.4-3 for structure QEL Reception
Module.
a) P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲E̲r̲r̲o̲r̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
ref. 4.2.1.6.1.2 for description
b) V̲a̲l̲i̲d̲a̲t̲e̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
Validation of a QEL received from the Command
Subqueue.
c) V̲a̲l̲i̲d̲a̲t̲e̲ ̲M̲S̲0̲ ̲Q̲E̲L̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲
Validation of a QEL received from the RESPONSE
subqueue.
d) V̲a̲l̲i̲d̲a̲t̲e̲ ̲M̲S̲G̲ ̲Q̲E̲L̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
Validation of maintype and flag-values of QEL's
supposed to reference a message-view.
e) D̲a̲t̲a̲ ̲E̲r̲r̲o̲r̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
ref. 4.2.1.6.1.1 for description
4.2.1.4.3.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲r̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
QEL Data (4.2.1.5.3)
TEP ̲THP (CPS/ICD/009 5.2.1)
TRS ̲AAS (CPS/ICD/009 5.6.5)
SSC ̲TO/FROM THP (CPS/ICD/009 4.2.1.4)
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
QUEUE ̲REF (m)
QEL ̲ATTRIBUTE (m)
QEL ̲REF (m)
RECEIVE ̲SUBQUEUE (m)
WAIT ̲QUEUE (m)
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
VALID ̲QEL: INTEGER
4.2.1.4.3.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The QEL ̲Reception module is controlled by the Init
Analysis Module.
It will start its processing with the call "RECEIVE
̲FIRST ̲QEL" with a wait ̲indication.
When a QEL arrives to the Analysis Queue, the contents
of the QEL ̲HEADER will be examined.
A QEL Received from the command-subqueue should
be a SSC ̲command for Close-down; if not, it is
assumed that the QEL is from SSC and sent to Analysis
with a Send Request; therefore a NOT ̲OK answer
is prepared for the Finish Analysis Procedures.
A QEL received from the Log-Comp ̲Subqueue is not expected
and considered as erroneous.
Other QEL's should reference a message view and are
validated in accordance with that assumption. The Data
Error module will be activated in case the validation
fails (send QEL to GAQ and dismantle QEL) and a new
QEL will be collected from the ANQ.
Fig. 4.2.1.4-3…01…STRUCTURE QEL ̲RECEPTION
Q̲E̲L̲ ̲R̲E̲C̲E̲P̲T̲I̲O̲N̲
LOOP VALID ̲QEL:
VALID ̲QEL = TRUE
WAIT = TRUE
QUEUE ̲REF.MAIN ̲QUEUE = ANQ
QUEUE ̲REF.SUB ̲QUEUE = WAIT ̲QUEUE
RECEIVE ̲FIRST ̲QEL (WAIT, QUEUE ̲REF,
QEL ̲ATTRIBUTE)
(QEL ̲REF, RECEIVE.SUBQUEUE,
CC) : ERROR ̲OK
ERROR? PROCESSING ̲ERROR (CC, RECEIVE ̲FIRST ̲QEL,
NO ̲ACCEPT) ( )
CASE RECEIVE ̲SUBQUEUE OF:
COMMAND: VALIDATE ̲COMMAND
RESPONSE: VALIDATE MSO ̲QEL
VALID ̲QEL? VALIDATE MSG ̲QEL
TRAFFIC: VALIDATE MSG ̲QEL
LOG ̲COMP: DATA ̲ERROR (NOT ̲EXPECTED ̲QEL)
VALID ̲QEL = FALSE
END RECEIVE ̲SUBQUEUE CASE
END VALID ̲QEL LOOP
RETURN
V̲A̲L̲I̲D̲A̲T̲E̲ ̲C̲O̲M̲M̲A̲N̲D̲
WAIT ̲QUEUE = COMMAND
QEL ̲HEADER.MAINTYPE NE SSC ̲COMMAND?
QEL ̲HEADER.SUBTYPE NE CLOSE ̲DOWN?
SEND ̲QEL ̲HEADER.FLAG = OK
SEND ̲QEL ̲HEADER.FLAG = NOT ̲OK
RETURN
V̲A̲L̲I̲D̲A̲T̲E̲ ̲M̲S̲O̲ ̲Q̲E̲L̲
QEL ̲HEADER.SUBTYPE =
FROM ̲GARBLE ̲CORRECTION QEL ̲HEADER.FLAG = ZERO?
or
FROM ̲INSPECTION?
VALID ̲QEL = FALSE
DATA ̲ERROR (ILLEGAL ̲QEL) ( )
RETURN
V̲A̲L̲I̲D̲A̲T̲E̲ ̲M̲S̲G̲ ̲Q̲E̲L̲
QEL ̲HEADER.MAINTYPE =
FROM ̲NICS ̲TARE,
FROM ̲TRC ̲POINT ̲TO ̲POINT, QEL ̲HEADER.FLAG =
FROM ̲SCARS, ITS ̲ERROR ̲TYPE?
FROM ̲CCIS,
FROM ̲NORMAL ̲PTR
or
FROM ̲DEDICATED ̲PTR?
VALID ̲QEL = FALSE
DATA ̲ERROR (INVALID ̲QEL) ( )
RETURN
4.2.1.4.4 V̲i̲e̲w̲ ̲R̲e̲c̲e̲p̲t̲i̲o̲n̲ ̲M̲o̲d̲u̲l̲e̲
4.2.1.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̲
Input of a message for analysis into the analysis buffer.
Setup of pointers and assignment of EMF record-structure
to the referenced fields of the message-view.
Validation of the minimum expected number of fields.
4.2.1.4.4.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Input:
Output: R5 = CC; View OK/NOT ̲OK
C̲a̲l̲l̲ ̲s̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲:̲
a) VIEW ̲RECEPTION( )(CC)
b) VIEW ̲RECEPTION (R5, R6)
4.2.1.4.4.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
See fig. 4.2.1.4-4 for structure View Reception module
a) P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲E̲r̲r̲o̲r̲ ̲M̲o̲d̲u̲l̲e̲
ref. 4.2.1.6.1.2 for description
b) P̲r̲e̲p̲a̲r̲e̲ ̲F̲i̲e̲l̲d̲ ̲L̲i̲s̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
Build up of the Field-List to be used during READ
̲VIEW based upon the USED ̲LENGTH of the Field-information.
c) D̲a̲t̲a̲ ̲E̲r̲r̲o̲r̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
ref. 4.2.1.6.1.1 for description
d) M̲o̲v̲e̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
ref. 4.2.1.6.1.6 for description
e) I̲n̲s̲e̲r̲t̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
ref. 4.2.1.6.1.7 for description
f) V̲i̲e̲w̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲e̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
Assignment of type-structure associated to the
Field type definitions. (ACP ̲PARAMETER ̲FIELD and
Administration-field).
If the ACP ̲parameter ̲field is on an odd address
in the analysis buffer, the field will be moved
to an even address first.
4.2.1.4.4.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
View Data (4.2.1.5.4)
Analysis Buffer (4.2.1.5.1)
ACP ̲Parameter ̲Field (DBD/001 10.2.2)
Administration ̲Field (DBD/001 10.1.1)
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲\̲
VIEW ̲REF
VIEW ̲ATTRIBUTE (m)
RECEIVE ̲FIELD ̲LIST (m)
ACP ̲HEADER ̲POINTER (m)
TEXT ̲POINTER (m)
TEXT ̲ENDING ̲POINTER (m)
ACP ̲PARAMETER ̲POINTER (m)
ADMINISTRATION ̲POINTER (m)
ADDRESS ̲POINTER (m)
PLA ̲RI ̲POINTER (m)
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
FIELD ̲NO: INTEGER
FIELD ̲POINTER: INTEGER
4.2.1.4.4.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The view attributes containing information about the
presence of field-groups and the length of these are
first requested. Next the view is opened and a field-list
prepared based upon the field-information of the view-attribute.
The view is considered erronous and will be delivered
to the Data Error procedure if either the ACP-Header-field
or/and the ACP-Parameter-field is not present.
Finally the view is read into the analysis buffer and
the type-structure assigned the ACP-parameter-field
and the Administration-field.
Fig. 4.2.1.4-4…86…1 …02… …02… …02… …02… …02…
V̲I̲E̲W̲ ̲R̲E̲C̲E̲P̲T̲I̲O̲N̲ ̲( ) (CC)
VIEW ̲REF = QEL ̲REF
GET ̲VIEW ̲ATTRIBUTES(VIEW ̲ATTRIBUTE,VIEW ̲REF)
(CC) : ERROR ̲OK
ERROR? PROCESSING ̲ERROR (CC, GET ̲VIEW ̲ATTRIBUTES
NO ̲ACCEPT) ( )
OPEN ̲VIEW (VIEW ̲REF)(CC) : ERROR ̲OK
ERROR? PROCESSING ̲ERROR (CC, OPEN ̲VIEW,
NO ̲ACCEPT) ( )
PREPARE FIELD ̲LIST ( ) (CC)
CC = NOT ̲OK?
READ ̲VIEW (MAX ̲EMF ̲SIZE, RECEIVE ̲FIELD ̲LIST,
VIEW ̲REF, ANALYSIS ̲BUFFER)
(RECEIVE ̲FIELD ̲LIST, CC): ERROR ̲OK
ERROR? PROCESSING ̲ERROR (CC, READ ̲VIEW,
NO ̲ACCEPT)( )
VIEW ̲INITIALIZE
RETURN
P̲R̲E̲P̲A̲R̲E̲ ̲F̲I̲E̲L̲D̲ ̲L̲I̲S̲T̲ ̲( ) (CC)
USING VIEW ̲ATTRIBUTE. FIELD ̲INFORMATION
FIELD ̲POINTER = ZERO
FIELD ̲NO = ZERO
USED ̲LENGTH(ACP-HEADER) = ZERO? DATA ̲ERROR
(VIEW ̲ERROR)( )
CC = NOT ̲OK
INCREMENT FIELD ̲NO
USING RECEIVE ̲FIELD ̲LIST(FIELD ̲NO)
FIELD ̲GROUP ̲ID = ACP ̲HEADER
FIELD ̲BYTE ̲ADDRESS = ZERO
FIELD ̲RECORD ̲LENGTH = USED ̲LENGTH(ACP ̲HEADER)
ACP ̲HEADER ̲POINTER = FIELD ̲POINTER
FIELD ̲POINTER = USED ̲LENGTH(ACP ̲HEADER)
USED ̲LENGTH(TEXT) = ZERO?
INCREMENT FIELD ̲NO
USING RECEIVE ̲FIELD ̲LIST(FIELD ̲NO)
FIELD ̲GROUP ̲ID = TEXT
FIELD ̲BYTE ̲ADDRESS = ZERO
FIELD ̲RECORD ̲LENGTH = MAX ̲TEXT
MAX ̲TEXT LE USED ̲LENGTH(TEXT)?
FIELD ̲RECORD ̲LENGTH = USED ̲LENGTH(TEXT)
TEXT ̲POINTER = FIELD ̲POINTER
FIELD ̲POINTER = FIELD ̲POINTER + (USED ̲LENGTH(TEXT)
Continue
continued PREPARE ̲FIELD ̲LIST
USED ̲LENGTH(TEXT ̲ENDING) = ZERO?
INCREMENT FIELD ̲NO
USING RECEIVE ̲FIELD ̲LIST (FIELD ̲NO)
FIELD ̲GROUP ̲ID = TEXT ̲ENDING
FIELD ̲BYTE ̲ADDRESS = ZERO
FIELD ̲RECORD ̲LENGTH = USED ̲LENGTH(TEXT ̲ENDING)
TEXT ̲ENDING ̲POINTER = FIELD ̲POINTER
FIELD ̲POINTER = FIELD ̲POINTER + USED ̲LENGTH(TEXT ̲ENDING)
USED ̲LENGTH(ACP ̲PARAMS) = ZERO? DATA ̲ERROR
(VIEW ̲ERROR)( )
CC = NOT ̲OK
INCREMENT FIELD ̲NO
USING RECEIVE ̲FIELD ̲LIST(FIELD ̲NO)
FIELD ̲GROUP ̲ID = ACP ̲PARAMS
FIELD ̲BYTE ̲ADDRESS = ZERO
FIELD ̲RECORD ̲LENGTH = USED ̲LENGTH(ACP ̲PARAMS)
ACP ̲PARAMS ̲POINTER = FIELD ̲POINTER
FIELD ̲POINTER = FIELD ̲POINTER + USED ̲LENGTH(ACP ̲PARAMS)
RECEIVE ̲FIELD ̲LIST. FIELD ̲ELEMENT = FIELD ̲NO
CC = OK
RETURN…86…1 …02… …02… …02… …02… …02…
V̲I̲E̲W̲ ̲I̲N̲I̲T̲I̲A̲L̲I̲Z̲E̲
ACP ̲PARAMS ̲POINTER = EVEN ̲ADDRESS?
LOOP ODD ̲ADDRESS;
FIELD ̲POINTER + 1(CHAR) = FIELD ̲POINTER(CHAR)
FIELD ̲POINTER = ACP ̲PARAMS ̲POINTER?
INCREMENT ACP ̲PARAMS
̲POINTER
EXIT LOOP
DECREMENT FIELD ̲POINTER
END ODD ̲ADDRESS ̲LOOP
EQUIVALENCE ACP ̲PARAMS ̲POINTER TO
ACP ̲PARAMS ̲FIELD ̲TYPE
ADMINISTRATION ̲POINTER = ACP ̲PARAMS ̲POINTER +
ACP ̲PARAMS ̲SIZE
EQUIVALENCE ADMINISTRATION ̲POINTER TO
ADMINISTRATION ̲FIELD ̲TYPE
ADDRESS ̲POINTER = ADMINISTRATION ̲POINTER +
ADMINISTRATION ̲FIELD ̲SIZE
PLA ̲RI ̲POINTER = ADDRESS ̲POINTER + MAX ̲ADDRESS ̲SIZE
EQUIVALENCE PLA ̲RI ̲POINTER TO PLA ̲RI ̲FIELD ̲TYPE
RETURN
4.2.1.4.5 G̲a̲r̲b̲l̲e̲ ̲R̲e̲e̲n̲t̲e̲r̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
4.2.1.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̲
The functions of the Garble Reentering Module are to
examine the header and text-ending field of a message
reentered after garble correction at a Message Service
Position. The text-part has been separated into the
text-field and need not be examined. The purpose of
this examination is to pick up the missing elements
of the ACP ̲Parameter-Field normally supplied by the
Incoming Transport Subpackage.
4.2.1.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) GARBLE ̲REENTERING
b) GARBLE ̲REENTERING (R6)
4.2.1.4.4.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
See fig. 4.2.1.4-4 for structure Garble Reentering
module.
a) E̲x̲a̲m̲i̲n̲e̲ ̲H̲e̲a̲d̲e̲r̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
This procedure will examine one FL of the header
and supply the following offsets into the ACP ̲Parameter
̲Field
- FL3 ̲OFFSET
- FL6 ̲OFFSET
- FL10 ̲OFFSET
b) E̲x̲a̲m̲i̲n̲e̲ ̲T̲e̲x̲t̲ ̲e̲n̲d̲i̲n̲g̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
This procedure will examine the text-part located
after FL13 (second BT) for validation ̲SSN and Group
Count. These data-elements will be transferred
to the ACP ̲parameter ̲field to be used for consistency
check FL3/FL15.
c) F̲L̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
Ref. 4.2.1.6.1.3 for description
d) F̲L̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
Ref. 4.2.1.6.2.6 for description
4.2.1.4.4.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲r̲e̲f̲e̲r̲e̲n̲c̲e̲s̲:̲
ACP ̲parameter Field (DBD/001 10.2.2)
ACP ̲Header Field (DBD/001 10.2.3)
ACP ̲Text ̲Correction
Field (DBD/001 10.2.4)
Analysis Buffer (4.2.1.5.1)
Analysis Control Date (4.2.1.5.6)
QEL Data (4.2.1.5.3)
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
FL ̲POINTER (m)
FL ̲LENGTH (m)
FL ̲AREA (m)
ACP ̲HEADER ̲POINTER
TEXT ̲ENDING ̲POINTER
ACP ̲PARAMS.FL3 ̲OFFSET (m)
ACP ̲PARAMS.FL6 ̲OFFSET (m)
ACP ̲PARAMS.FL10 ̲OFFSET (m)
ACP ̲PARAMS.SSN (m)
ACP ̲PARAMS.GROUP ̲COUNT (m)
SEND ̲FOR ̲GARBLE (m)
QEL ̲ATTRIBUTE (m)
WRITE ̲ACP ̲PARAMS (m)
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
None
4.2.1.4.5.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The header-part of the message reentered from Garble
Correction is first examined; this examination results
in detection of FL3, FL6 and FL10; this result is again
used for a message type determination. The Text-ending-part
of the message is next examined; this text-ending part
is supposed to contain FL14 with the Group Count (if
encrypted message) and the validation Station Serial
Number and nothing else; if it contains more the message
is considered garbled and will be sent for additional
Garble Correction.
Fig. 4.2.1.4-5…01…STRUCTURE GARBLE REENTERING
G̲A̲R̲B̲L̲E̲ ̲R̲E̲E̲N̲T̲E̲R̲I̲N̲G̲
FL ̲POINTER = ACP ̲HEADER ̲POINTER
FL ̲LENGTH = FL ̲POINTER + IOC ̲BYTE ̲COUNT
FL ̲POINTER = FL ̲POINTER + IOC ̲RECORD ̲SIZE
LOOP HEADER:
EXAMINE ̲HEADER
FL ̲CONTROL( )(FL ̲AREA)
FL ̲AREA NE HEADER? EXIT LOOP
END HEADER LOOP
TEXT ̲ENDING ̲POINTER = ACP ̲PARAMETER ̲POINTER?
FL ̲POINTER = TEXT ̲ENDING ̲POINTER
FL ̲LENGTH = FL ̲POINTER + IOC ̲BYTE ̲COUNT
FL ̲POINTER = FL ̲POINTER + IOC ̲RECORD ̲SIZE
LOOP TEXT ̲ENDING:
EXAMINE ̲TEXT ̲ENDING
FL ̲CONTROL( )(FL ̲AREA)
FL ̲AREA NE TEXT ̲ENDING? EXIT LOOP
END TEXT ̲ENDING LOOP
RETURN
E̲X̲A̲M̲I̲N̲E̲ ̲H̲E̲A̲D̲E̲R̲
ACP ̲PARAMS.DE ̲OFFSET NE ZERO?
FL (1..3) = "DE "? ACP ̲PARAMS.FL3 ̲OFFSET =
(FL ̲POINTER - 3)
ACP ̲PARAMS.FM ̲OFFSET NE ZERO?
FL (1..3) = "FM "? ACP ̲PARAMS.FL6 ̲OFFSET =
(FL ̲POINTER - 3)
ACP ̲PARAMS. GR ̲OFFSET NE ZERO?
FL (1..2) = "GR"? ACP ̲PARAMS. FL10 ̲OFFSET =
(FL ̲POINTER - 3)
RETURN
E̲X̲A̲M̲I̲N̲E̲ ̲T̲E̲X̲T̲ ̲E̲N̲D̲I̲N̲G̲
FL(1..1) NE "L"?
FL ̲LENGTH GT 5?
FL ̲LENGTH LT 4?
FL ̲LENGTH = 5? ACP ̲PARAMS.SSN = (FL 2..5)
ACP ̲PARAMS.SSN (1..1) = "0"
ACP ̲PARAMS.SSN(2..5) = FL(2..4)
ACP ̲PARAMS.SSN = DIGITS?
FL(1..2) NE "GR" ?
FL ̲LENGTH GT 6?
FL ̲LENGTH LT 3?
ACP ̲PARAMS.GROUP ̲COUNT = SPACE
FL(2..FL ̲LENGTH) NE DIGITS?
ACP ̲PARAMS.GROUP ̲COUNT(1..(FL ̲LENGTH -2))
= FL(3..FL ̲LENGTH)
SEND ̲FOR ̲GARBLE =
TRUE
QEL ̲HEADER.FLAG NE
NO ̲ERROR?
QEL ̲HEADER.FLAG =
FL14 ̲CORRECTIONS
RETURN
4.2.1.4.6 M̲e̲s̲s̲a̲g̲e̲ ̲T̲y̲p̲e̲ ̲D̲e̲t̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲ ̲M̲o̲d̲u̲l̲e̲
4.2.1.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̲
The functions of this module are to determine the message-type
to be used during the Analysis Control procedures.
The message type determination is based on the information
collected during Reception Procedures, that is
- Number of EMF ̲Fields
- Offsets to Format-Lines
4.2.1.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) MESSAGE ̲TYPE ̲DETERMINATION
b) MESSAGE ̲TYPE ̲DETERMINATION (R6)
4.2.1.4.6.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
See fig. 4.2.1.4-6 for structure Message Type Determination
Module.
a) D̲e̲t̲e̲r̲m̲i̲n̲e̲ ̲S̲C̲-̲T̲y̲p̲e̲
Builds up the message-mask based on the SCARS/CCIS
message-type delivered in the first data-block
during Reception procedures. Also validation of
the message-type relevant for respectively SCARS
and CCIS.
b) D̲e̲t̲e̲r̲m̲i̲n̲e̲ ̲A̲C̲P̲ ̲T̲Y̲P̲E̲
Builds up the message-mask based on the additional
information (offsets etc.) from the ACP-parameter
field.
All messages which could contain ACP-format-lines
will pass through this procedure (incl. CCIS narrative
messages)
c) C̲h̲e̲c̲k̲ ̲M̲S̲G̲ ̲t̲y̲p̲e̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
Builds up the Analysis-message-type based on the
contents of the message-mask or rejects non recognized
combination.
4.2.1.4.6.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
ACP ̲Parameter-field (DBD/001 10.2.2)
Message Type Data (4.2.1.5.7)
QEL Data (4.2.1.5.3)
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
ANALYSIS ̲MSG ̲TYPE (m)
INTERNAL ̲ASM ̲TYPE (m)
EXTERNAL ̲ASM ̲TYPE (m)
ABBREVIATED ̲TYPE (m)
PLAINDRESS ̲TYPE (m)
DATA ̲TYPE (m)
ENCRYPTED ̲TYPE (m)
COMMENT ̲TYPE (m)
VDU ̲PAGE ̲TYPE (m)
MESSAGE ̲MASK (m)
QEL ̲HEADER
QEL ̲INFO.TFC ̲WORD
SEND ̲FOR ̲GARBLE
QEL ̲HEADER.FLAG (m)
ACP ̲PARAMS.DE ̲OFFSET
ACP ̲PARAMS.FM ̲OFFSET
ACP ̲PARAMS.GR ̲OFFSET
ACP ̲PARAMS.SC ̲MSG ̲TYPE
ACP ̲PARAMS.TEXT ̲TO ̲OFFSET
SEND ̲FOR ̲GARBLE (m)
SEND ̲FOR ̲INSPECTION (m)
C) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
ACP: BOOLEAN
4.2.1.4.6.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
Messages received from SCARS or CCIS are first examined
in the Determine SC-Type procedure; if the SC ̲message-type
is not in correspondance with the expected range of
valid message ̲types from that external network, the
message will be rejected; messages of type narrative
or Data will be examined also by the next procedure.
Messages classified to be of some ACP ̲type should contain
FL3 ("DE"); if not rejection.
Otherwise the message will be examined by the Determine
ACP procedure where the message-mask is build-up using
the ACP ̲parameter ̲field information. The final check
for message type detects illegal message-mask combinations
or determines the message-type to be used during the
Analysis Control Procedures.
Fig. 4.2.1.4-6…01…STRUCTURE MESSAGE TYPE DETERMINATION
M̲E̲S̲S̲A̲G̲E̲ ̲T̲Y̲P̲E̲ ̲D̲E̲T̲E̲R̲M̲I̲N̲A̲T̲I̲O̲N̲
ANALYSIS ̲MSG ̲TYPE = ALL
INTERNAL ̲ASM ̲TYPE = FALSE
EXTERNAL ̲ASM ̲TYPE = FALSE
ABBREVIATED ̲TYPE = FALSE
PLAINDRESS ̲TYPE = FALSE
DATA ̲TYPE = FALSE
ENCRYPTED ̲TYPE = FALSE
COMMENT ̲TYPE = FALSE
VDU ̲PAGE ̲TYPE = FALSE
MESSAGE ̲MASK = ZERO
QEL ̲HEADER.MAINTYPE =
FROM ̲CCIS OR DETERMINE ̲SC ̲TYPE( )(ACP,CC)
FROM ̲SCARS?
CC = NOT ̲OK?
ACP = FALSE?
ACP ̲PARAMS.DE ̲OFFSET = ZERO?
DETERMINE ̲ACP ̲TYPE
CHECK ̲MSG ̲TYPE ( )(CC)
CC = NOT ̲OK? SEND ̲FOR ̲GARBLE = TRUE
QEL ̲HEADER.FLAG = ZERO?
QEL ̲HEADER.FLAG = UNIDENTIFIED ̲MSG
RETURN
D̲E̲T̲E̲R̲M̲I̲N̲E̲ ̲S̲C̲ ̲T̲Y̲P̲E̲ ( )(ACP,CC)
CONTINUE = FALSE
ACP = FALSE
CC = OK
SC ̲MSG ̲TYPE = ACP.PARAMS.SC ̲MSG ̲TYPE
CASE SC ̲MSG ̲TYPE
C: VDU ̲PAGE ̲TYPE = TRUE
BIT 7 or MESSAGE ̲MASK
BIT 6 or MESSAGE ̲MASK
D: COMMENT ̲TYPE = TRUE
BIT 7 or MESSAGE ̲MASK
BIT 5 or MESSAGE ̲MASK
F: INTERNAL ̲ASM ̲TYPE = TRUE
BIT 4 or MESSAGE ̲MASK
ACP = TRUE
G: INTERNAL ̲ASM ̲TYPE = TRUE
BIT 4 or MESSAGE ̲MASK
ACP = TRUE
OTHERWISE: CONTINUE = TRUE
END SC ̲MSG ̲TYPE CASE
CONTINUE
CONTINUED DETERMINE ̲SC ̲TYPE
CASE FROM ̲CCIS:
H: PLAINDRESS ̲TYPE = TRUE
BIT 0 or MESSAGE ̲MASK
BIT 7 or MESSAGE ̲MASK
I: PLAINDRESS ̲TYPE = TRUE
DATA ̲TYPE = TRUE
BIT 0 or MESSAGE ̲MASK
BIT 2 or MESSAGE ̲MASK
BIT 7 or MESSAGE ̲MASK
L: PLAINDRESS ̲TYPE = TRUE
BIT 0 or MESSAGE ̲MASK
BIT 7 or MESSAGE ̲MASK
M: PLAINDRESS ̲TYPE = TRUE
DATA ̲TYPE = TRUE
BIT 0 or MESSAGE ̲MASK
BIT 2 or MESSAGE ̲MASK
BIT 7 or MESSAGE ̲MASK
OTHERWISE: CC = NOT ̲OK
END FROM ̲CCIS CASE
CONTINUE
CONTINUED DETERMINE ̲SC ̲TYPE
CASE FROM ̲SCARS:
A: ACP = TRUE
B: ACP = TRUE
DATA ̲TYPE = TRUE
BIT2 or MESSAGE ̲MASK
OTHERWISE: CC = NOT ̲OK
END FROM ̲SCARS CASE
SC ̲MSG ̲TYPE = QEL ̲HEADER.SUBTYPE =
I,K,L or M FROM ̲INSPECTION?
SEND ̲FOR ̲INSPECTION = TRUE
RETURN
D̲E̲T̲E̲R̲M̲I̲N̲E̲ ̲A̲C̲P̲ ̲T̲Y̲P̲E̲
ACP ̲PARAMS.TEXT ̲TO ̲OFFSET = ZERO? INTERNAL ̲ASM ̲TYPE
= TRUE
BIT 4 or MESSAGE
̲MASK
ACP ̲PARAMS.FM ̲OFFSET NE ZERO? PLAINDRESS ̲TYPE=
TRUE
BIT 0 or MESSAGE
̲MASK
ABBREVIATED ̲TYPE = TRUE
BIT 1 or MESSAGE ̲MASK
QEL ̲INFO.TFC ̲WORD = DATA? BIT2 or MESSAGE ̲MASK
DATA ̲TYPE = TRUE
ACP ̲PARAMS.GR ̲OFFSET NE ZERO" ENCRYPTED ̲TYPE =
TRUE
BIT 3 or MESSAGE
̲MASK
RETURN
C̲H̲E̲C̲K̲ ̲M̲S̲G̲ ̲T̲Y̲P̲E̲ ̲( )(CC)
CC = OK
CASE MESSAGE ̲MASK OF:
#1 : ANALYSIS ̲MSG ̲TYPE = PLAIN
#2 : -"- = ABB ̲PLAIN
#5 : -"- = PLAIN
#6 : -"- = ABB ̲PLAIN
#9 : -"- = PLAIN ̲ENCRYPT
#10: -"- = ASM
#A : -"- = ABB ̲PLAIN ̲ENCRYPT
#81: -"- = PLAIN
#85: -"- = PLAIN
#89: -"- = PLAIN ̲ENCRYPT
#A0: -"- = COMMENT
#C0 -"- = VDU ̲PAGE
OTHERWISE: CC = NOT ̲OK
END CASE MESSAGE ̲MASK
RETURN
4.2.1.4.7 A̲n̲a̲l̲y̲s̲i̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲M̲o̲d̲u̲l̲e̲
4.2.1.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̲
The functions of the Analysis Control Module are:
- analysis of messages in ACP127-format
- analysis of messages in CCIS ̲E1 format
- analysis of comments and VDU-pages
- control of format-line sequencing in accordance
with predefined temporary message-type
- initiate parameter control and detection of pilot,
readdressal and relay-instructions via control
of Format-Line-analysis modules.
- initiate build-up of Internal message format via
control of Format-Line-analysis modules
- initiate detection of ASM to be handled internal
into THP via the ASM Control Module.
- Check of Logical relationship in routing Logic
(CAMPS ̲RI/Local HQ)
- determination of route(s) after successful analysis
(if not garbled)
4.2.1.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) ANALYSIS ̲CONTROL
b) ANALYSIS ̲CONTROL (R6)…86…1 …02… …02… …02… …02…
…02…
4.2.1.4.7.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
See fig. 4.2.1.4-7(1) for structure Analysis Control
Module.
a) S̲C̲ ̲a̲n̲a̲l̲y̲s̲i̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
Analysis of messages in CCIS ̲E1 format, Comments
and VDU ̲pages.
Controls via the SC ̲Guide ̲table the following analysis
̲modules for format ̲line detection, parameter control
and IMF build-up:
- FL1 analysis (4.2.1.4.8)
- FLC analysis (4.2.1.4.9)
- FL ̲D1 analysis (4.2.1.4.10)
- FL ̲D analysis (4.2.1.4.11)
- FL ̲EF analysis (4.2.1.4.12)
- FLJ analysis (4.2.1.4.13)
- FL control (4.2.1.6.1.3)
See fig. 4.2.1.4-7(2) for structure
b) A̲C̲P̲ ̲a̲n̲a̲l̲y̲s̲i̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
Analysis of messages in ACP127-format and narrative
messages in CCIS ̲E1 format from FL5 (=FLJ).
Controls via the ACP ̲guide ̲table the following
analysis-module for format line detection, parameter
control and IMF build-up:
- FL1 analysis (4.2.1.4.8)
- FL2 analysis (4.2.1.4.14)
- FL3 analysis (4.2.1.4.15)
- FL4 analysis (4.2.1.4.16)
- FL4A analysis (4.2.1.4.17)
- FL5 analysis (4.2.1.4.18)
- FL6 analysis (4.2.1.4.19)
- FL7-8 analysis (4.2.1.4.20)
- FL9 analysis (4.2.1.4.21)
- FL10 analysis (4.2.1.4.22)
- FL12 analysis (4.2.1.4.23)
- FL control (4.2.1.6.1.3)
See fig. 4.2.1.4-7(3) for structure
c) A̲S̲M̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲M̲o̲d̲u̲l̲e̲
Ref. 4.2.1.4.24 for description
d) R̲o̲u̲t̲i̲n̲g̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
Check of logical relationship between Local/external
RI's detected in FL2 and Local/external PLA's detected
in FL7/8. Determination of route(s) for the message
after analysis to be used in case the message is
not garbled or shall be inspected at an incoming
MSO-position.
e) E̲r̲r̲o̲r̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
Ref. 4.2.1.6.1.4 for description
Error-codes: UNIDENTIFIED ̲FORMAT ̲LINE
NO ̲LOCAL ̲HQ ̲FOUND
4.2.1.4.7.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
Analysis Buffer (4.2.1.5.1)
QEL ̲Data (4.2.1.5.3)
Analysis Control
Data (4.2.1.5.6)
Message Type Data (4.2.1.5.7)
ACP ̲Header field (DBD/001 10.2.3)
Text field (DBD/001 10.1.5)
ACP ̲Parameter field (DBD/001 10.2.2)
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
ACP ̲HEADER ̲RECORD
TEXT ̲RECORD
SC ̲GUIDE ̲TABLE
ACP ̲GUIDE ̲TABLE
FL ̲NUMBER (m)
HQ ̲MASK
COMMENT ̲TYPE
VDU ̲PAGE ̲TYPE
INTERNAL ̲ASM ̲TYPE
ENCRYPTED ̲TYPE
PLAINDRESS ̲TYPE
SERVICE ̲TYPE
ANALYSIS ̲MSG ̲TYPE
SEND ̲FOR ̲PARAMETERS (m)
ACP ̲HEADER ̲POINTER
QEL ̲HEADER.MAINTYPE
ACP ̲PARAMS.FM ̲OFFSET
PLAINDRESS ̲ENTRY
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
GUIDE ̲INDEX : INTEGER
ANALYSIS: BOOLEAN
SC ̲STOP: INTEGER
ANALYSIS ̲FL : FL ̲TYPE
PREV ̲FL : FL ̲TYPE
FL ̲AREA : FL ̲AREA ̲TYPE
FL ̲POINTER : INTEGER
FL ̲LENGTH : INTEGER
NEW ̲FL : BOOLEAN
4.2.1.4.7.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The message received for analysis control procedures
has previously been assigned a temporary message-type;
to this analysis-message-type is associated a sequence
of format-lines which shall be in correct order to
fulfil the analysis; the sequencing of format-lines
are obtained via the SC and ACP-Guide tables; messages
received from CCIS, VDU-pages and Comments are analyzed
using the SC-Guide-table, while messages assumed to
be in ACP127 format are analyzed using the ACP-Guide-table;
If a message received from CCIS is of plaindress-type
it will be analyzed using both described Guide-tables
(Plaindress-entry in ACP-Guide table). The logic of
the Guide tables is like this:
- the Guide-record equal to the Guide-index shall
be used.
- if the Guide-msg-type do not match the analysis-msg-type
or indicate all, the Guide-index shall be incremented
and the following Guide-record selected.
- the Next-FL (scalar type = FL) points out the next
format Line analysis module to be activated.
- the PREV ̲FL is a parameter the called analysis
module shall receive in order to determine analysis
of additional FL etc.
- when the called analysis module returns, it delivers
the result (OK, NOT ̲OK, STOP)
- if STOP the analysis will be aborted since the
analysis module detected a very bad condition (Format
̲Line from the wrong message-field)
- if not ̲ok the guide ̲index will be assigned the
value from the STEP ̲FALSE field.
- if OK the guide-index will be assigned the value
from the STEP ̲TRUE field.
- if the guide-index now has been assigned the value
= ZERO, the analysis has been successfully completed
- or if the guide ̲index equals the garble ̲value (-
1) the analysis shall be terminated for garble-correction
- else the guide ̲index again points out the next
guide ̲record for next FL ̲analysis.
Fig. 4.2.1.4-7(1)…01…STRUCTURE ANALYSIS CONTROL MODULE
Fig. 4.2.1.4-7(2)…01…STRUCTURE SC-ANYLYSIS CONTROL
Fig. 4.2.1.4-7 (3)…01…STRUCTURE ACP ANALYSIS
A̲N̲A̲L̲Y̲S̲I̲S̲ ̲C̲O̲N̲T̲R̲O̲L̲
FL ̲AREA = HEADER
FL ̲POINTER = ACP ̲HEADER ̲POINTER
FL ̲LENGTH = FL ̲POINTER + IOC ̲BYTE ̲COUNT
FL ̲NUMBER, GUIDE ̲INDEX = ONE
QEL ̲HEADER.MAINTYPE = FROM ̲CCIS?
COMMENT
or SC ̲ANALYSIS ̲CONTROL(GUIDE ̲INDEX)
VDU ̲PAGE (GUIDE ̲INDEX,
ANALYSIS ̲CC)
ANALYSIS ̲CC = NOT ̲OK?
COMMENT
OR
VDU ̲PAGE?
ASM?
GUIDE ̲INDEX = PLAINDRESS ̲ENTRY
ACP ̲ANALYSIS ̲CONTROL (GUIDE ̲INDEX)
(ANALYSIS ̲CC)
ANALYSIS ̲CC = NOT ̲OK?
ASM? ASM ̲CONTROL (FL ̲POINTER)( )
ROUTING ̲CONTROL( )(CC)
CC = NOT ̲OK? ERROR ̲COLLECTION (NO ̲LOCAL ̲HQ ̲FOUND)(
)
ERROR ̲COLLECTION(UINDENTIFIED ̲FORMAT ̲LINE)(
)
RETURN
S̲C̲ ̲A̲N̲A̲L̲Y̲S̲I̲S̲ ̲C̲O̲N̲T̲R̲O̲L̲ (GUIDE ̲INDEX)
(GUIDE ̲INDEX, ANALYSIS ̲CC)
ANALYSIS ̲CC = OK
ANALYSIS = TRUE
SC ̲STOP = ZERO
(PLAIN ̲ENCRYPT SC ̲STOP = ACP ̲HEADER ̲POINTER
OR PLAIN? +ACP.PARAMS.FM-OFFSET
LOOP SC ̲ANALYSIS:
GUIDE ̲RECORD = SC ̲GUIDE ̲TABLE(GUIDE ̲INDEX)
LOOP GUIDE ̲MSG ̲TYPE:
GUIDE ̲MSG ̲TYPE = ALL? EXIT LOOP
GUIDE ̲MSG ̲TYPE = ANALYSIS ̲MSG ̲TYPE EXIT
LOOP
INCREMENT GUIDE ̲INDEX
END LOOP GUIDE ̲MSG ̲TYPE
CASE NEXT ̲FL OF:
FL1: FL1 ̲ANALYSIS (FL ̲POINTER, PREV ̲FL,
NEXT ̲FL, FL ̲AREA)
(RESULT)
FLC: FLC ̲ANALYSIS -"-
FLD1: FLD1 ̲ANALYSIS -"-
FLD2: FLD ̲ANALYSIS -"-
FLD3: FLD ̲ANALYSIS -"-
FLD4: FLD ̲ANALYSIS -"-
continue
continued SC ̲ANALYSIS ̲CONTROL
FLE: FLEF ̲ANALYSIS (FL ̲POINTER, PREV ̲FL
NEXT ̲FL, FL ̲AREA)
(RESULT)
FLF: FLEF ̲ANALYSIS -"-
FLJ1: FLJ ̲ANALYSIS -"-
FLJ2: FLJ ̲ANALYSIS -"-
FLJ3: FLJ ̲ANALYSIS -"-
END NEXT ̲FL CASE
CASE RESULT OF:
OK: GUIDE ̲INDEX = STEP ̲TRUE
NOT ̲OK: GUIDE ̲INDEX = STEP ̲FALSE
STOP: GUIDE ̲INDEX = GARBLE ̲ANALYSIS
END RESULT CASE
CASE GUIDE ̲INDEX OF:
GARBLE ̲ANALYSIS: ANALYSIS = FALSE
ANALYSIS ̲CC = NOT ̲OK
STOP ̲ANALYSIS: ANALYSIS = FALSE
OTHERWISE: FL ̲CONTROL ( )(FL ̲AREA)
FL ̲POINTER NE SC ̲STOP?
ANALYSIS = FALSE
END GUIDE ̲INDEX CASE
END SC ̲ANALYSIS LOOP
RETURN
A̲C̲P̲ ̲A̲N̲A̲L̲Y̲S̲I̲S̲ ̲C̲O̲N̲T̲R̲O̲L̲ (GUIDE INDEX)(ANALYSIS ̲CC)
ANALYSIS ̲CC = OK
ANALYSIS = TRUE
LOOP ACP ̲ANALYSIS:
GUIDE ̲RECORD = ACP ̲GUIDE ̲TABLE(GUIDE ̲INDEX)
LOOP GUIDE ̲MSG ̲TYPE:
GUIDE ̲MSG ̲TYPE = ALL? EXIT LOOP
GUIDE ̲MSG ̲TYPE = ANALYSIS ̲MSG ̲TYPE? EXIT LOOP
INCREMENT GUIDE ̲INDEX
END LOOP GUIDE ̲MSG ̲TYPE
CASE NEXT ̲FL OF:
FL1: FL1 ̲ANALYSIS (FL ̲POINTER, PREV ̲FL,
NEXT ̲FL, FL ̲AREA)
(RESULT)
FL2: FL2 ̲ANALYSIS -"-
FL3: FL3 ̲ANALYSIS -"-
FL4: FL4 ̲ANALYSIS -"-
FL5: FL5 ̲ANALYSIS -"-
FL6: FL6 ̲ANALYSIS -"-
FL7: FL7 ̲8 ̲ANALYSIS -"-
FL8: FL7 ̲8 ̲ANALYSIS -"-
FL9: FL9 ̲ANALYSIS -"-
FL10: FL10 ̲ANALYSIS -"-
continue …86…1 …02… …02… …02… …02… …02… …02…
…02…
continued ACP ̲ANALYSIS ̲CONTROL
FL1A: FL1 ̲ANALYSIS (FL ̲POINTER, PREV ̲FL,
NEXT ̲FL, FL ̲AREA)
(RESULT)
FL4A: FL4A ̲ANALYSIS -"-
FL12A: FL12 ̲ANALYSIS -"-
FL12B: FL12 ̲ANALYSIS -"-
FL12C: FL12 ̲ANALYSIS -"-
FL12D: FL12 ̲ANALYSIS -"-
END NEXT ̲FL CASE
CASE RESULT OF:
OK: GUIDE ̲INDEX = STEP ̲TRUE
NOT ̲OK: GUIDE ̲INDEX = STEP ̲FALSE
STOP: GUIDE ̲INDEX = GARBLE ̲ANALYSIS
END RESULT CASE
CASE GUIDE ̲INDEX OF:
GARBLE ̲ANALYSIS: ANALYSIS = FALSE
ANALYSIS ̲CC = NOT ̲OK
STOP ̲ANALYSIS: ANALYSIS = FALSE
OTHERWISE: FL ̲CONTROL ( )(FL ̲AREA)
END GUIDE ̲INDEX CASE
END ACP ̲ANALYSIS LOOP
RETURN
R̲O̲U̲T̲I̲N̲G̲ ̲C̲O̲N̲T̲R̲O̲L̲ ̲( )(CC)
CC = OK
COMMENT ̲TYPE? SEND ̲FOR ̲DISTRIBUTION = TRUE
VDU ̲PAGE ̲TYPE? SEND ̲FOR ̲UMAN = TRUE
SCD? SEND ̲FOR ̲DISTRIBUTION = TRUE
QEL ̲HEADER.MAINTYPE NE FROM ̲CCIS?
SEND ̲FOR ̲COORDINATION?
SEND ̲FOR ̲RELEASE?
SEND ̲FOR ̲CONVERSION? HQ ̲MASK = ZERO?
SEND ̲FOR ̲DISTRIBUTION = TRUE
SEND ̲FOR ̲RELAYING? CAMPS ̲LOCAL ̲RELAYING = TRUE?
SEND ̲FOR ̲DISTRIBUTION = FALSE
SEND ̲FOR ̲DISTRIBUTION = FALSE?
EXTERNAL ̲ASM ̲TYPE? SEND ̲FOR ̲SUPERVISOR = TRUE
SEND ̲FOR ̲DISTRIBUTION = FALSE
INTERNAL ̲ASM ̲TYPE? SEND ̲FOR ̲DISTRIBUTION = FALSE
PLAINDRESS ̲TYPE? HQ ̲MASK NE ZERO?
CC = NOT ̲OK
SERVICE ̲TYPE? SEND ̲FOR ̲SUPERVISOR = TRUE
SEND ̲FOR ̲DISTRIBUTION = FALSE
ENCRYPTED ̲TYPE? SEND ̲FOR ̲PUNCH = TRUE
SEND ̲FOR ̲DISTRIBUTION = FALSE
RETURN
