top - download
⟦3f692714e⟧ Wang Wps File
Length: 26229 (0x6675)
Types: Wang Wps File
Notes: FIX/1000/PSP/038 4.2.5
Names: »5200A «
Derivation
└─⟦e48583e73⟧ Bits:30006141 8" Wang WCS floppy, CR 0514A
└─ ⟦this⟧ »5200A «
WangText
…00……00……00……00……00…-…02……00……00…-
,…09…,…0a…,…0b…,…0e…,…0f…, +…08…+…09…+…00…+…07…*…08…*…0f…*…02…*
…0f… 5200A/bna…02…FIX/1000/PSP/0038
…02…MLA/850529…02……02…
FIKS SYSTEM SPECIFICATION
…02……02…FK 7809…0e…
4.2.5 N̲I̲C̲S̲-̲T̲A̲R̲E̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲N̲T̲S̲)̲
4.2.5.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲u̲m̲m̲a̲r̲y̲
The NTS subsystem provides the functions/programs for
the interchange of ACP127 formatted messages between
the FIKS network and the NICS-TARE network.
The point to point connection between FIKS and NICS-TARE
is a 600 baud synchronous full duplex channel. The
link control protocol employed by this channel is the
LITSYNC Error Detection and Connection Protocol …0e…1)…0f…
(EDC), which ensures an error-free transmission across
the link.
Messages for transmission to the NICS-TARE network
are enqueued in the NICS-TARE Transmission Queue (NT)
by the MSS subsystem. Upon transmission, the message
is dequeued from NT and an acknowledgement (ACK), which
confirms a successfully transmission of this specific
message, is returned to the MSS. Inbound messages received
from the NICS-TARE network are enqueued in the ACP/SMF
conversion queue (CQ1) by the NTS subsystem for onward
processing by the MSS.
Control and supervision of the NTS is performed by
the NSC subsystem. Unrecoverable errors (line loss)
are reported to the NSC for display on the Supervisor
Positions VDU. Channel control, i.e. setup, open and
close, are a subset of the supervisors interactive
functions that monitor the NTS subsystem.
1) Ref. Doc. FIX/1163/SPC/0005, Issue 1, 800313.
4.2.5.2 S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲
Figure 4.2.5.2-1 illustrates the flow of data and control
between the NTS and the other subsystems within the
SCC.
Figure 4.2.5.2-1
Block Diagram
4.2.5.3 D̲e̲s̲i̲g̲n̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
The functions provided by the NTS are implemented by
means of 3 functional seperate submodules within the
NTS:
- Input/Output Message Processing Submodule (IOMP)
- The Litsync Protocol Submodule (EDC)
- LTU Driver (DLTU)
The intersubmodule communication/handshaking is by
means of AMOS system messages, QE elements and a critical
region used for intermediate buffering of outbound
and inbound messages.
The functional relations between these submodules are
depicted in Figure 4.2.5.3-1.
Figure 4.2.5.3-1
Communication Link. Functional Breakdown
4.2.5.3.1 I̲O̲M̲P̲ ̲S̲u̲b̲m̲o̲d̲u̲l̲e̲
The IOMP submodule performs two major functions:
- Outbound Message Processing
- Inbound Message Processing
Figure 4.2.5.3-2 illustrates flow of data and control
between the IOMP and other SCC subsystems/submodules.
4.2.5. O̲u̲t̲b̲o̲u̲n̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
3.1.1
Outbound messages queued in NT by the MSS and pending
for transmission are retrieved by the IOMP submodule.
The message files are divided up into data structures
(blocks), which conform to the requirements for the
EDC protocol, and in accordance with the actual block
size on the channel. Blocks are held in memory buffers,
which are allocated from a buffer pool managed by the
NTS, and used for inter NTS-submodule data exchange.
Blocks generated by the IOMP are queued in the Outbound
Block Queue (OBQ) for further processing by the EDC
submodule.
Upon transmission of the last block of a message (an
EOM block), an acknowledgement is received from the
EDC submodule. This acknowledgement served two purposes:
the release of a transmitted message from the NTS queue,
and to forward an acknowledgement to the MSS used for
inter SCC message synchronization (check pointing).
4.2.5. I̲n̲b̲o̲u̲n̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
3.1.2
Inbound messages blocks are delivered to the IOMP by
the EDC submodule in the Inbound Block Queue (IBQ).
The IOMP performs the reassembling of blocks into a
message file. When a complete message has been assembled
it is queued in the conversion queue CQ1 for further
processing by the MSS, and an acknowledgement is issued
to the EDC submodule.
The acknowledgement for receipt of a complete message
is forwarded to NICS-TARE, by the EDC submodule.
4.2.5. C̲h̲a̲n̲n̲e̲l̲ ̲C̲o̲n̲t̲r̲o̲l̲
3.1.3
The input and output channels are monitored/controlled
by supervisor commands received via the NSC subsystem.
The supervisor has the facilities to setup, open and
close the channel. Channel setup includes the initial
value of the block size to be used for blocking of
outbound messages. Block-size changes require a new
setup command and that the channel is closed.
Figure 4.2.5.3-2
IOMP Submodule Interfaces
4.2.5.3.2 E̲D̲C̲ ̲S̲u̲b̲m̲o̲d̲u̲l̲e̲
The EDC submodule provides the link control protocol
employed by the NICS-TARE link. The LITSYNC protocol
handles a full duplex line as two seperate simplex
lines, an input and an output channel. That further
implies that the EDC submodule functionally is breaked
down into input channel and output channel handling
subprograms.
Figure 4.2.5.3-3 illustrates the data and control flow
between EDC submodule and other subsystems/submodules
within the SCC.
4.2.5. E̲D̲C̲ ̲O̲u̲t̲p̲u̲t̲ ̲C̲h̲a̲n̲n̲e̲l̲
3.2.1
Pending data blocks, are retrieved from OBQ, as soon
as the channel is available, i.e. less than two segments
in progress. The data blocks are framed in EDC envelopes
sequence numbered in consecutive order, and queued
in the Pending Block Queue (PBQ).
During error free operation, blocks in PBQ are enqueued
in the Block Transmit Queue (BTQ) in consecutive order
and upon transmission moved to the Awaiting Acknowledgement
Queue (AAQ).
BTQ holds both outbound data blocks and control blocks
generated by both the input and output channel.
To minimize the turn around time for responses to incoming
requests, only a limited number of data blocks are
queued in BTQ at the same time.
Under error conditions retransmission of a specific
block may be required. A request for retransmission
(NAK) designate an EDC-block in AAQ, which is interspersed
in the stream of "first-transmission" of blocks retrieved
from PBQ.
When an acknowledgement is received from NICS-TARE
for receipt of a series of blocks held in the AAQ,
these blocks are released and the channel will be available
for transmission of subsequent blocks, which may be
pending in PBQ.
If an unrecoverable error is detected on the output
channel, which is wither retransmission limit exceeded
or a reported timeout of a response to a request for
response, then a report is issued to the supervisor
position VDU. In the former case the supervisor may
change the block-size on the channel in an attempt
to recover. In the latter case a switchover to the
stand-by SCC may be required.
4.2.5. E̲D̲C̲ ̲I̲n̲p̲u̲t̲ ̲C̲h̲a̲n̲n̲e̲l̲
3.2.2
EDC blocks received from the LTU-driver, Block Receive
Queue (BRQ) are validated for correct frame check sequence
(CRC) parity check and sequence number.
During error free operations, EDC blocks are received
in sequence i.e. consecutive sequence numbers in received
blocks. The data blocks carried in the EDC blocks are
immediately enqueued in IBQ for onward processing by
IOMP as long as the EDC blocks are received in correct
order.
A received EDC block out-of-sequence may either be
a response to a retransmission request (NAK), or a
subsequent block where interjacent blocks has been
lost caused by transmission errors. In the latter case,
the data block is stored in the Intermediate Storage
Queue (ISQ), and the missing EDC blocks are requested
retransmitted by means of NAK blocks. A data block
held in ISQ will only remain there until all younger
blocks have been received and processed, where upon
it is enqueued in ISQ in proper sequence.
When an end of message block has been processed and
dequeued from IBQ by the IOMP submodule, an acknowledgement
is issued, and by the EDC submodule forwarded to NICS-TARE
to signal the receipt of a complete message (check
pointing).
Figure 4.2.5.3-3
EDC-Submodule Interfaces
4.2.5.3.3 L̲T̲U̲-̲D̲r̲i̲v̲e̲r̲ ̲S̲u̲b̲m̲o̲d̲u̲l̲e̲ ̲(̲D̲L̲T̲U̲)̲
The LTU-driver performs all the operation required
to handle the synchronous LTU device. The DLTU provides
the interface/layer between the block mode EDC protocol
and the character-mode LTU-device. Like the EDC submodule
the LTU driver operates seperately the LTU input channel
and output channel in a load sharing mode.
4.2.5. D̲L̲T̲U̲ ̲O̲u̲t̲p̲u̲t̲ ̲C̲h̲a̲n̲n̲e̲l̲
3.3.1
During idle line condition, i.e. no blocks pending
in the BTQ, continuous SYNC1 characters re transmitted
to keep either side of the link synchronized. Transmission
of an EDC-block is initiated by transmittting the SYNC1,
SYNC2 sequence to indicate start of EDC block to NICS-TARE.
At the same time as EDC block is transmitted, character
by character, a frame checksum (CRC) is calculated,
and appended to the tailend of the very same block.
EDC blocks are returned to the EDC submodule upon transmission,
either to be deleted or saved for later retrieval.
4.2.5. D̲L̲T̲U̲ ̲I̲n̲p̲u̲t̲ ̲C̲h̲a̲n̲n̲e̲l̲
3.3.2
During idle line condition, continuous SYNC1 characters
are received. In this state the DLTU hunts from the
SYNC1 and SYNC2 character sequence which indicates
that what is to follow is the beginning of the next
EDC block.
When the "block-mode" is entered (SYNC1, SYNC2 detected)
an EDC block is assembled and stored in a block-buffer.
The calculated frame check characters (CRC) is compared
to that received in the tailend of the EDC block. If
unequal a CRC-error indication is flagged in the block
buffer. Assembled EDC blocks are queued in BRQ for
retrieval by the EDC submodule for forward processing.
Blocks are enqueued in BRQ in the order received.
4.2.5.3.4 Q̲u̲e̲u̲e̲s̲
The following queues external to NTS are used:
- CQ1 Conversion queues. Contains a reference to
a message sent for ACP - SMF conversion.
- NT Transmission to NICS-TARE queue. Contains a
reference to a message to be sent to NICS-TARE
network.
4.2.5.3.5 F̲i̲l̲e̲s̲
The only file used is:
- AMF - ACP127 message file. Contains messages to
be sent to the NICS-TARE systems, that is converted
messages received from the FIKS network. Also used
by the intercept module.
Figure 4.2.5.4
Visual Table of Contents
4.2.5.5 S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲ ̲H̲I̲P̲O̲ ̲D̲i̲a̲g̲r̲a̲m̲
The HIPO overview is shown in Figure 4.2.5.5-1.
Figure 4.2.5.5-1a
NICS-TARE Communications,
Transmit to NICS-TARE,
Overview HIPO
Figure 4.2.5.5-1
NICS-TARE Communications,
Receive from NICS-TARE,
Overview HIPO
4.2.6 I̲n̲t̲e̲r̲ ̲S̲C̲C̲ ̲H̲a̲n̲d̲s̲h̲a̲k̲i̲n̲g̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲I̲S̲H̲)̲
4.2.6.1 F̲u̲n̲c̲t̲i̲o̲n̲
The ISH subsystem implements those functions which
are necessary to implement the protocol between the
two SCC's for the purpose of remote SCC supervision
and narrative message synchronization.
Further, the subsystem supports the communication between
the NSS and the SCC subsystems which interface to the
FIKS NODE/MEDEs.
The following functions are recognized:
- M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
Incoming messages are distributed i.e. enqueued
in the appropriate queues, depending on being a
narrative message or a control message.
Further, it is detected is a control message, i.e.
keep alive message, is to be handled by the ISH
and in this case control is given to the appropriate
ISH module.
- S̲C̲C̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲
This function supports the monitoring of the remote
SCC by means of keep alive messages. If the monitoring
of the remote SCC shows a SCC failure, this is
reported to the NSC subsystem.
- N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲S̲y̲n̲c̲h̲r̲o̲n̲i̲z̲a̲t̲i̲o̲n̲
This function supports that narrative messages
sent from the FIKS network to the SCC or NICS-TARE,
which are sent to both SCC's, are synchronized.
This implies that narrative messages processed
and transmitted from the active SCC are deleted
at the stand-by SCC.
S̲t̲a̲t̲u̲s̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲
This function supports periodically generation of keep
alive messages. The messages are after generation sent
to the remote SCC. If the sending SCC is active, the
identification of processed messages since last keep
alive message are included in the keep alive message.
I̲n̲t̲e̲r̲n̲a̲l̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
At start/restart of the SCC, which means that the SCC
processor is attempting from off-line mode to enter
stand-by mode, the status of the remote SCC will be
checked for the purpose to decide whether the SCC may
enter the stand-by mode or not. If the SCC enters the
stand-by mode, the messages with SCC or NICS-TARE as
destination, which might be stored, intermediate, at
the collocated NODE/MEDE will be moved to the stand-by
SCC. These functions are handled by the SCC and collocated
N/M interface function.
Comments to block diagram Figure 4.2.6.2-1.1.
M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
1. A message stored on the IMF is enqueued to the
ISH.
2. The message is a control message which is handled
by the NSC or
3. The message is a control message handled by the
ISH, i.e. the SCC to SCC protocol or
4. The message is a narrative message, i.e. handled
by the MSS.
4a. The narrative message is moved from the IMF to
the TSF as a consequence of the size of the narrative
message queue that has exceeded a predefined value.
Figure 4.2.6.2-1.1
Inter SCC Handshaking Subsystem
Block Diagram
Comments to block diagram Figure 4.2.6.2-1.2.
S̲C̲C̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲
1. A message handled by the ISH is received.
1a. A timeout on receipt of a keep alive message is
occuring.
2. The status of the remote SCC is controlled and
if changing
3. The status table is updated and
4. The NSC is informed else
5. A new timeout period is initiated and
6. Control is given to message synchronization function.
Figure 4.2.6.2-1.2
Inter SCC Handshaking Subsystem
Block Diagram
Comments to block diagram Figure 4.2.6.2-1.3.
N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲S̲y̲n̲c̲h̲r̲o̲n̲i̲z̲a̲t̲i̲o̲n̲
1. A keep alive message is received for processing.
2. The messages queued as pending ACK are compared
with messages queued for processing if messages
match, then the messages are deleted (3-4).
5. The messages processed at the active SCC, given
in the keep alive message, match with the messages
queued for processing (6). Then the messages are
deleted else
7. The messages (msg. ID) are queued as pending ACK's.
8. The enqueuing time of the oldest message is checked
and if the time a message has been queued exceeds,
a predefined value then
9. The message (msg.-ID) is delivered to the supervisor.
Figure 4.2.6.2-1.3
Inter SCC Handshaking Subsystem
Block Diagram
Comments to block diagram Figure 4.2.6.2-1.4.
S̲t̲a̲t̲u̲s̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲
1. The ISH status reporting function gains control
after an AMOS timeout:
2. Generate a keep alive message containing the status
and if active then
3. Include the msg.-ID of processed messages and
4. Write the control message to the TSF.
5. The message is enqueued to the NSS.
6. The NSS transports the keep alive message to the
remote SCC.
Figure 4.2.6.2-1.4
Inter SCC Handshaking Subsystem
Block Diagram
Comments to block diagram 4.2.6.2-1.5.
I̲n̲t̲e̲r̲n̲a̲l̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
1. The ISH creates a control message to the SCC interface
function, i.e. give status of remote SCC.
2. The NSS transports request to collocated N/M where
3. The ISH receives the request.
4. The status is returned and if not stand-by then
5. Messages queued at the collocated N/M are moved
to the SCC processor
5a. The status of the remote SCC is stand-by. This
causes the SCC processor to terminate with an error
code displayed on the operator console.
Figure 4.2.6.2-1.5
Inter SCC Handshaking Subsystem
Block Diagram
4.2.6.3 D̲e̲s̲i̲g̲n̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
The ISH subsystem is designed to implement the protocol
between the SCC's. The protocls hereby include the:
- SCC to SCC protocol.
This includes the protocol necessary for the remote
SCC monitoring as well as the protocol for message
synchronization.
- Internal protocol.
This protocol is used between the SCC and the collocated
NODE/MEDE. The protocol is only used by SCC processor
initialization.
The SCC to SCC protocol may hereby be executed from
an active SCC to a stand-by or off-line SCC. To support
this protocol, the ISH is implemented at the collocated
N/M and the SCC. The implementation at the collocated
NODE/MEDE is hereby called SIP (SCC Interface Process)
and at the SCC called CIP (Collocated NODE/MEDE I/F
Process).
The external function of the SIP and CIP is seen from
the network to look like the SCC. The CIP will look
like the SCC when the SCC processor is on-line and
the SIP will look like the SCC when the SCC processor
is off-line.
Messages destinated to NICS-TARE or the SCC will, depending
on the status of the SCC processor, be enqueued to
the CIP or the SIP. The latter is fully controlled
by the NSS.
The SCC protocol is illustrated in Figure 4.2.6.3-1.
Figure 4.2.6.3-1
SCC Protocols
the ISH implements following modules. Modules implemented
at the collocated N/M are flagged.
M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲M̲o̲d̲u̲l̲e̲
The module supports distribution of messages which
are received at the SCC via the NSS interface. The
message may hereby be either a control or a narrative
message. Messages destined for the SCC or NICS-TARE
are enqueued in the ISH input queue by the NSS. The
MTCB will hereby reference the file containing the
message on the IMF. The DISH will dequeue this message
from the input queue and depending on if it is a control
message or a narrative message queue it for the NSC
subsystem or MSS subsystem.
If the message is a narrative message, the processing
might be devided into the cases where
- The queue size is less than predefined value.
In this case a pseudo MTCB is created and a link to
the real MTCB is written into the pseudo MTCB and it
is queued to the N/M queue.
Further, the MSG-ID, extracted from the IMF file, is
written to the pseudo MTCB, ill. overleaf.
- The queue size is greater than a predefined value.
In this case the MTCB monitor is requested to create
a file on the temporary storage file (TSF) and the
message is moved to this file from the IMF. Hereby
the messge is extracted and written into the MTCB,
ill. overleaf.
- A congestion situation has occured.
Hereby the message is directly queued for interception.
When it is a control message, the ISH determines if
it is a keep alive message or not. If is is a keep
alive message, from the remote SCC, the control is
passed to the ISH, SCC monitoring module in all other
cases, the message is just delivered to the NLSC subsystem.
This module is implemented at the SCC processor and
at the collocated N/M.
S̲C̲C̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
This module received the keep alive messages from the
remote SCC's. Based upon these, the remote SCC status
is maintained. If a status change takes place, the
status change is reported to the NSC by enqueueing
of a control message, (the keep alive message is forwarded
to NSC).
The status change may be reported directly from the
remote SCC, information enclosed in the keep alive
message, or it is indirectly detected, i.e. based on
a timeout at the receiving SCC.
If the keep alive message contains message processed
by the active SCC, acknowledgement, the control is
passed to the ISH message synchronization module.
This module is implemented at the SCC and at the collocated
NODE/MEDEs.
M̲e̲s̲s̲a̲g̲e̲ ̲S̲y̲n̲c̲h̲r̲o̲n̲i̲z̲a̲t̲i̲o̲n̲ ̲M̲o̲d̲u̲l̲e̲
This module receives the keep alive messages from the
active SCC containing messages (msg-ID) processed and
transmitted by the active SCC.
These acknowledgements are queued in the pending acknowledgement
queue subsequently followed by a comparison of this
pending acknowledgement queue and the conversion queue.
When by this comparison, messages are found in both
queues; these are deleted
It is further by this examination checked that the
first message queued, i.e. the oldest, has not been
queued for more than a specified time and if this is
the case, then the message is delivered to the supervisor
for interception.
This module is implemented at the SCC and at the collocated
N/M.
S̲t̲a̲t̲u̲s̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
This module reports the SCC status to the remote SCC
on a periodically basis. If the SCC procesor, where
the module is implemented, is in active mode, the messages,
identified by their msg-ID, are included in the keep
alive message.
This module is only implemented at the SCC's
I̲n̲t̲e̲r̲n̲a̲l̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
This module supports the protocol which is necessary
between the ISH part implemented at the SCC and the
ISH part implemented at the collocated NODE/MEDE.
The task of the module includes that a SCC processor
by initialization may request the status of the remote
SCC from the ISH part implemented at the collocated
NODE/MEDE and may further request the messages which
are queued, for the SCC or NICS-TARE, at the collocated
NODE/MEDE to be moved, transported to the SCC.
The module is divided into two submodules, i.e. the
SCC interface submodule implemented at the collocated
NODE/MEDE and the collocated N/M interface submodule
implemented at the SCC.
4.2.6.3.1 F̲i̲l̲e̲s̲
The following files are used by the ISH:
- I̲M̲F̲,̲ ̲I̲n̲b̲o̲u̲n̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲i̲l̲e̲
This file contains all messages entering a NODE/MEDE
or the SCC.
- T̲S̲F̲,̲ ̲T̲e̲m̲p̲o̲r̲a̲r̲y̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲F̲i̲l̲e̲
This file is used for the purpose of unloading
the IMF file, i.e. the TSF contains message files
in compressed form. Further, the file is used by
generation and release of a control message.
4.2.6.3.2 Q̲u̲e̲u̲e̲s̲
Following queues are accessed of the ISH subsystem:
- T̲Q̲,̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲Q̲u̲e̲u̲e̲
This queue which in fact is the NSS's input queue
is used by sending a control message from the SCC
to the collocated N/M or the remote SCC.
- C̲Q̲,̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲Q̲u̲e̲u̲e̲
Contains the narrative message which is queued
for conversion.
- N̲/̲M̲,̲ ̲N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲Q̲u̲e̲u̲e̲
is similar to the CQ implemented at the collocated
N/M for the purpose of buffering messages destinated
for the off-line SCC.
- C̲M̲,̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲Q̲u̲e̲u̲e̲
This queue contains control messages queued for
the NSC subsystem.
- P̲A̲,̲ ̲P̲e̲n̲d̲i̲n̲g̲ ̲A̲c̲k̲n̲o̲w̲l̲e̲d̲g̲e̲m̲e̲n̲t̲ ̲Q̲u̲e̲u̲e̲
The queue contains messages, MSG, ID's, processed
at the active SCC i.e. acknowledgements.
- C̲I̲P̲/̲S̲I̲P̲,̲ ̲I̲n̲p̲u̲t̲ ̲Q̲u̲e̲u̲e̲
This queue(s) contains messages destinated for
the SCC or NICS-TARE.
4.2.6.4 V̲i̲s̲u̲a̲l̲ ̲T̲a̲b̲l̲e̲ ̲o̲f̲ ̲C̲o̲n̲t̲e̲n̲t̲s̲
Figure 4.2.6.4-1 gives an overview of the main modules
which constitute the ISH.
Figure 4.2.6.4-1
ISH Visual Table of Contents
4.2.6.5 S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲ ̲H̲I̲P̲O̲ ̲D̲i̲a̲g̲r̲a̲m̲
Figure 4.2.6.5-1 provides n overview of the function
that occur in support of the ISH processes.
Figure 4.2.6.5-1a
Figure 4.2.6.5-1b
Figure 4.2.6.5-1c
