top - download
⟦19a7230bf⟧ Wang Wps File
Length: 11648 (0x2d80)
Types: Wang Wps File
Notes: OPERATIONAL REQUIREMENT
Names: »5937A «
Derivation
└─⟦b3c9a9699⟧ Bits:30006142 8" Wang WCS floppy, CR 0015A
└─ ⟦this⟧ »5937A «
WangText
…00……00……00……00……1f……86…1 …02… …02… …02… …02…
FIKS SYSTEM EXTENSION SPD/85-05-21
OPERATIONAL REQUIREMENT Page #
OPERATIONAL REQUIREMENT
FOR
FIKS SYSTEM EXTENSION
CONCERNING
SCC CONVERSION LOG
AND
RETRANSMISSION PROCEDURE
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
Page
1 DOCUMENTATION REFERENCES .......................
3
2 UPDATE CONCEPT .................................
4
3 OPERATIONAL REQUIREMENT ........................
5
3.1 SCC CONVERSION LOG .........................
5
3.2 RETRANSMISSION OF MESSAGES .................
8
4 HARDWARE SPECIFICATION .........................
8
5 SOFTWARE SPECIFICATION .........................
12
1̲ ̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲A̲T̲I̲O̲N̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
The following documents are required to establish a
firm base line for the update.
1) FIKS SYSTEM SPECIFICATION
FIX/1000/PSP/0038
2) FIKS DATA I/F REFERENCE
FIX/0100/MAN/0004
3) FIKS ISH PROCESSES PSP
FIX/1160/PSP/0091
4) AMC letter AHK.601.728-1090
dated 23 November, 1984
2̲ ̲ ̲U̲P̲D̲A̲T̲E̲ ̲C̲O̲N̲C̲E̲P̲T̲
The update will be implemented with as few changes
as possible in the existing FIKS S/W and H/W to reduce
the amount of effort involved.
To overcome the problem concerning the limited amount
of spare CR80 - program memory, implementation using
"background processing" will be used. In case the CR80-computers
at a later point in time will be equipped with the
XAMOS System, the background processing can be transferred
to ordinary processing and thereby improve the performance.
The update is concerned with two objects:
1. SCC Conversion Log
- All messages passing the conversion procedure
(SMF to ACP127, ACP127 to SMF) shall be logged.
The logging is performed when a message enters/leaves
the ISH Subsystem. A new kind of terminal "LOG PRINTER"
will be introduced in the FIKS System. This will
be a "Receive Only Printer", that uses the same
hardware printer as those connected to the existing
VDU-terminals. No input operations will be supported.
To implement this, a new kind of LTUX is introduced
(LTUX-log). This will be a modification of the existing
LTUX-tele. The solution shall be used as a model
for future extension/modification of log-functions
used in the FIKS-system.
2. Retransmission of Messages:
- One message or messages in a DTG-range can be
object for retransmission. The modification shall
especially enable retransmission of messages from
FIKS to NATO.
A retransmitted message shall, for the receiver,
look just like if it was received as an intended
original. It shall be possible to specify a subset
of the original message addressees which then will
receive the message. No other than those specified
addressees, must receive the message. To implement
this a new kind of message has been introduced.
"Retransmission Message", which will have its own
identity. The existing FIKS Software must learn
to handle this.
The update shall cover all S/W and H/W (except additional
terminal equipment) needed to perform the implementation.
3̲ ̲ ̲O̲P̲E̲R̲A̲T̲I̲O̲N̲A̲L̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲
3.1 S̲C̲C̲ ̲C̲O̲N̲V̲E̲R̲S̲I̲O̲N̲ ̲L̲O̲G̲
An outline is shown in figure 3.1.
The information concerning which message that enter/
leave the ISH Subsystem (ref.3), i.e for which conversion
is started/completed, is contained in the CIP-SIP-
and SIP-SIP keep alive control messages. They are at
the SCC-colocated Node/MEDE delivered to the SWD-process
(SIP-watchdog), which then places them in the critical
region SMAILB, where they can be inspected by other
processes. The input to the "SCC Conversion Log" will
be based upon the mentioned control messages.
The existing keep alive traffic shall be expanded to
contain information enough to format a log-record with
content as described in ref. 4.I.6. The number of fields
has to be increased. The control messages must also
contain information about the incoming NICS-FIKS-messages
as "Start of ACP127-SMF-conversion" and "Conversion
Completed". This implies that:
- the layout of the critical regions SMAILB, CMAILB
and the keep alive control messages must be modified.
- the processes that access SMAILB and CMAILB must
be modified, so that they can perform the required
extended updating. This concerns the processes
CWD, CPM, MAS at the SCC's and SWD, SPM at the
colocated Node/MEDE's.
- "flow control" of the SIP-SIP keep alive traffic
must be introduced. No later oncoming antimessages
(used at event: leave ISH-system) must overwrite
the preceeding ones. This is to ensure the same
logging on both ACTIVE and STANDBY SCC.
A new process CVLOG (Conversion Log Printer Process)
is implemented. This shall, when notified by the SWD-process,
format the log-records based upon the SMAILB-content.
The records are written into the CVF-disk file. The
CVF-file has a structure and size like the existing
MJF-file (Message Journal File).
…86…1 …02… …02… …02… …02… …02…
FIGURE 3.1
SCC CONVERSION LOG OUTLINE
After the records have been stored, they are printed
on the particular allocated Conversion Log Printer,
in case the logging is of the type "leave of ISH-system",
i.e. conversion completed. Later on, all the records
(or part of them) can be printed at request of the
supervisor (ref. 4.I.4). By keying in an appropriate
supervisor command, he will initiate the printout.
The printout is performed using a "LOG PRINTER". This
will be a new kind of FIKS-terminal, using a minimum
of resources, and with the special purpose of performing
log printout. The hardware printer to be used shall
be of the same type as the one used together with VDU-terminals,
i.e 300 band printers with the full ASCII-character
set available. It is necessary to introduce a new kind
of corresponding LTUX-device into the red TDX-system.
This will be a modification of the existing LTUX-tele,
i.e. an LTUX-S with the possibilitiy of connecting
up to four log printers. This can be exploited in future
extension/improvement of the FIKS system.
A SCC Conversion Log Printer shall be allocated to
both of the collocated Node/MEDE's. Restart of the
LTUX's will be possible in the same manner as restart
of the other LTUX's serving the terminals. Facilities
and procedures to enable replacement of paper/ribbon
of the log printers without corrupting the printout,
will be worked out.
3.2 R̲E̲T̲R̲A̲N̲S̲M̲I̲S̲S̲I̲O̲N̲ ̲O̲F̲ ̲M̲E̲S̲S̲A̲G̲E̲S̲
An outline is shown in figure 3.2.
A retransmitted message shall after retransmission,
for the receiver, look like it never was retransmitted,
i.e. Message id, release DTG, from/to addresses, address-marking,
etc must not be changed caused by the retransmission.
This indicates that at least a complete copy of the
original message has to be transmitted (incl. the ANO-.list).
Anyway the message might possibly be routed in a different
way (only to a subset of the original addressees).
This indicates a different ANO-list to be used. The
following will be implemented:
A retransmitted message contains both the original
ANO-list (the old) and the one used at retransmission
(the new). The new ANO-list is added to the end of
the old message. The items, message length and ANO-list
offset, in the binary header is updated to confirm
with the new ANO-list. The new ANO-list will contain
the old ANO-list offset, so that the old ANO-list still
can be accessed as an ANO-list. The message will be
marked as a "retransmitted message" by using a spare
bit position in the binary header. This will ensure
that the message always can be processed in the correct
way.
The network- and distribution routines in the FIKS
network will in this way not be affected. The retransmitted
messages will be stored as such in the HDB. The processes
that access the signal text will have to distinguish
between retransmitted/not retransmitted messages. This
concerns the following:
- the PIP-, MAS-, MSA-, TERM-processes has to be
updated so that they skip the old ANO-list as signal
text.
- the PIP-process shall use the old ANO-list for
address-marking.
- the MSA shall use the new ANO-list when the routing
indicators are set up. (building format line 2).
A new procedure as described in ref. 4-II.4 to be used
in preparation of retransmitted messages will be implemented.
The steps 1-4 will be like preparation of a readdressed
message, except no new message id, no FM ̲ -prompt.
The ordinary message header preparation will be used
(AIG's, XMT's, etc.) If the ANO does not exist in the
old ANO-list, the operator is notified and the keying
is refused. The message will be automatically released
for transmission in the network, when the preparation
is finished. I.e. no editing and listing of the message
is possible.
When the DTG-range option is used a different approach
is applied. The SRR-process (the Storage Retrieve Process)
will receive the request. When SRR in the affected
DTG-range finds a message that has an ANO pointing
on a NATO-address, it will insert all such ANO's in
the new ANO-list and release the message to the network.
In this way only NATO-addressees will receive a retransmitted
message. The DTG-option shall only be possible from
a supervisor terminal.
Retransmitted messages will be object for checkpointing,
Message Journal logging, statistics, etc. in the usual
standard FIKS manner. Only original (not retransmitted)
messages are objects for retransmission.
FIGURE 3.2
"RETRANSMISSION OF MESSAGE" - OUTLINE
4̲ ̲ ̲H̲A̲R̲D̲W̲A̲R̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
To implement "SCC Conversion Log" an extra LTUX-S shall
be added to the existing H/W-configuration at each
of the two SCC colocated Node/MEDE's. It is assumed
that vacant resources in the form of crates, fans,
power suppliers, etc are available.
5̲ ̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
The update is implemented by adding/updating of the
following S/W and H/W of the FIKS system baseline.
R̲e̲.̲ ̲S̲C̲C̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲L̲o̲g̲
- LTUX-tele firmware update
- New CVLOG-process is added
- ISH subsystem update, expansion of keep alive traffic,
- TERM-process update, New supervisor procedure:
"PCL", Print of Conversion Log, ref. 4-I.
- Miscellaneous FIKS module update, new queue structure,
LCFH-files update, etc.
R̲e̲.̲ ̲R̲e̲t̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
- New procedure: "RTM", ref. 4-II
(TERM-process + SRR-process update)
- Adaption of the process PIP, MAS and MSA to handle
"Old ANO-list is not signal text".
- PIP-process updating: "Marking of Addresses".
- MSA-process updating: "Use new ANO-list to build
format line 2".
