top - download
⟦cb3d5b5b4⟧ Wang Wps File
Length: 15468 (0x3c6c)
Types: Wang Wps File
Notes: FIX/1000/PSP/038
Names: »5293A «
Derivation
└─⟦c5670ecfe⟧ Bits:30006140 8" Wang WCS floppy, CR 0516A
└─ ⟦this⟧ »5293A «
WangText
…0e……0e… 5293A/aml…02…FIX/1000/PSP/0038
…02…OK/850529…02……02…
FIKS SYSTEM
SPECIFICATION
…02……02…FK 7809…0f…
4 F̲I̲K̲S̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲S̲Y̲S̲T̲E̲M̲
The functions summarized in section 3, that support
the operation of the network, are designed to be implemented
as collections of software subsystems. Each subsystem
consists of one or more modules of program code and
associated data.
This section deals with the subsystem, their functions
and their place in the FIKS System.
4.1 N̲O̲D̲E̲/̲M̲E̲D̲E̲ ̲A̲P̲P̲L̲I̲C̲A̲T̲I̲O̲N̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
4.1.1 O̲v̲e̲r̲v̲i̲e̲w̲
Care has been taken to ensure that the subsystems comprising
the Node/MEDE are separable into subsystems that provide
Node functions and those that provide MEDE functions.
The visual table of contents is shown in Figure 4.1.1-1.
4.1.1.1 S̲y̲s̲t̲e̲m̲ ̲B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲
The block diagram shown in Figure 4.1.1-2 illustrates
the sequence of operations that occur as messages are
inbound to the Node, and as messages are originated
by the MEDE for outbound transmission from the Node.
The diagram shows the logical relationship of the Nodal
Switch Subsystem (NSS), the three MEDE subsystems Message
Distribution (MDS), Storage and Retrieval (SRS) and
Message Entry (MES), and the Supervisory Functions
Subsystem (SFS).
Although all executive subsystems may be involved in
the processes depicted, only the three data management
subsystems are shown to emphasize the flow of data
as well as control.
Figure 4.1.1-1…01…FIKS Software System
Figure 4.1.1-1 (cont'd)…01…FIKS Software System
Figure 4.1.1-1 (cont'd)…01…FIKS Software System
Figure 4.1.1-2…01…FIKS NODE/MEDE System…01…Narrative Message Flow
4.1.1.2.2 I̲n̲b̲o̲u̲n̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
The MDS calls QACCESS to fetch from its input queues
the entry which is of highest precedence. This occurs
whenever the MDS receives an interprocess signal or
whenever it completes delivery of an inbound message.
The input queue entry contains the MTCB index of the
message, and the time of day at which the entry was
made. The MDS uses the MTCB index in a request to
the MTCB Monitor for the logical description of the
file of the message. The MDS provides this file description
to the Input/Output System in a request to read the
Address List of the message from the file (8). The
List together with the "classification" field of the
MTCB indicate that the message is one of the following
types:
a. A narrative message to be delivered to MEDE terminal;
or
b. A narrative message the security classification
of which calls for Special Handling prior to delivery
to a MEDE terminal(s);
or
c. A control message to be delivered to the Supervisory
Functions Subsystem;
or
d. An erroneously orbiting message to be delivered
to the SFS.
If the Address List of the message, when compared to
the distribution directory of the MDS, reveals erroneous
addressee data, an entry is made in the SFS Distribution
Queue (DT) which references the MTCB for this u̲n̲k̲n̲o̲w̲n̲
̲A̲N̲O̲ error condition (8a).
If the classification of the message is higher than
that of the operator, an entry is made in the SFS Distribution
queue (DT).
4.1.1.2.2.1 S̲p̲e̲c̲i̲a̲l̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
If the MTCB indicates that delivery requires Special
Handling, the control block of each of the addressed
terminals is checked for existence of a Special
Handling password which is associated with the
current terminal operator (9). QACCESS is then
called to update the SH queue of the terminal with
an entry which references the MTCB (10). Subsequently,
the terminal operator will initiate the security
interrogation procedure which authorizes his access
to the message (section 4.1.1.2.5.1 describes this
action).
If an addressed terminal is in use by an operator
whose User Security Profile does not specify a
Special Handling password, the MTCB reference of
the message is entered, via QACCESS, into the DT
queue (9a) of the supervisory terminal.
This action is accompanied by a request to QACCES
to update the Alarm Queue of the supervisor with
a pseudo MTCB reference which provides a notice
of this u̲n̲s̲u̲c̲c̲e̲s̲s̲f̲u̲l̲ ̲S̲p̲e̲c̲i̲a̲l̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲d̲e̲l̲i̲v̲e̲r̲y̲
(9b).
4.1.1.2.2.2 D̲e̲l̲i̲v̲e̲r̲y̲ ̲o̲f̲ ̲N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲ ̲t̲o̲ ̲t̲h̲e̲ ̲M̲E̲D̲E̲
If the MTCB indicates that Special Handling is
not required for the narrative message, the message
is entered into the Historical Data Base (11).
This is initiated by the MDS through an enqueue
request to QACCESS. The queue entry contains the
input file descriptor of the message and the time
of day the entry was made. The MTCB of the message
is updated prior to the enqueue request, by the
MDS, with the time of day the enqueue request was
made.
The time which is recorded in the MTCB becomes
the retrieval date time group (DTG) for the message.
QACCESS is then called to enter the MTCB reference
into the terminal queues of the Printer Interface
Process (12). The monitor call specifies each
terminal number of the queue and a count of the
number of message copies to be printed at each
adressed terminal.
This action concludes delivery of the message.
4.1.1.2.2.3 D̲e̲l̲i̲v̲e̲r̲y̲ ̲o̲f̲ ̲I̲n̲t̲e̲r̲c̲e̲p̲t̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
If the MTCB indicates that the message was intercepted
by the NSS (orbit error), QACCESS is called to
enqueue the message to the Supervisory Functions
Subsystem input queue (12a). The request specifies
that the DT queue receives the MTCB reference.
QACCESS is then requested to enqueue the message
to the input queue of the Storage and Retrieval
Subsystem for entry into the HDB (13).
This concludes delivery of intercepted messages.
4.1.1.2.2.4 C̲o̲n̲t̲r̲o̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
The MTCB indicates if the inbound message is a
control message.
Control messages are directed by the MDS to the
Supervisor Functions Subsystem.
Control messages are treated similar to Special
Handling messages, to the extent that they are
not entered into the Historical Data Base.
If the SFS is referenced as the logical terminal
recipient, QACCESS is called to enqueue the message
into the SF queue (14).
If the colocated SCC is the recipient, QACCESS
enters the message into the SCC input queue.
These actions conclude delivery of the control
message.
4.1.1.2.3 M̲e̲s̲s̲a̲g̲e̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲i̲n̲ ̲t̲h̲e̲ ̲H̲i̲s̲t̲o̲r̲i̲c̲a̲l̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲
The Storage and Retrieval Subsystem calls QACCESS
to dequeue from its storage input queue the entry
that has waited the longest. This occurs whenever
the SRS receives an interprocess signal from QACCESS
or whenever it completes a previous update request.
The SRS first determines if there is sufficient
space on the HDB to store the message.
It begins by requesting from the MTCB Monitor the
size and location (file descriptor) of the message.
If space is available to store the message on the
Message Text File of the HDB, the SRS initiates
the data base update. It uses the file description
to request that the IOS read the message into main
memory (15) for subsequent copy to the Message
Text File. The copying of the message is copied
in blocks.
While the message is in memory essential information
for the Message Retrieval File is extracted for
subsequent MRF update. This is accomplished by
writing to the in-memory subset of the MRF, the
ID of the message, its SIC references, its security
class, and its length.
The DTG of the message, to be used later in retrieval
requests, is obtained from the MTCB reference of
the storage input queue. It is added to the Message
Retrieval File at this point.
Each message is stored on the MTF beginning at
a new disk sector (16). The MTF itself is created
at starting time as a contiguous, sequential file.
The SRS manages this space by updating the Message
Retrieval File with sector addresses and extents.
After the first message block is written to the
MTF, subsequent blocks are read from the input
file of the message and written to the next sequential
disk sectors of the MTF.
The last input block contains the Address List
of the message. The Message Retrieval File is
updated with these data to record the terminal
ID's which will be authorized to retrieve the message.
The DTG File is then updated if it is necessary.
This action occurs if the message is the first
one, during a recorded minute of the day, which
is entered into the storage input queue. DTGF
records contain offset values of record addresses
in the Message Retrieval File which correspond
to each recorded minute.
The SRS then calls the MTCB Monitor to update the
MTCB of the message. The use count of the input
file is decremented, and if it is zero, the file
space is released by the Monitor (16a). The beginning
sector address of the message on the MTF is added
to the MTCB.
The DTGF and MRF access files are updated with
new records (17).
4.1.1.2.4 M̲e̲s̲s̲a̲g̲e̲ ̲D̲e̲l̲e̲t̲i̲o̲n̲ ̲f̲r̲o̲m̲ ̲t̲h̲e̲ ̲H̲i̲s̲t̲o̲r̲i̲c̲a̲l̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲
The Storage and Retrieval Subsystem guarantees
that update requests will never be refused. It
accomplishes this, whenever the HDB is full, by
deleting enough of the oldest messages to free
a percentage of disk space, as specified by a system
parameter.
The design assumes that it is possible that any
of the three HDB files could be full when a storage
request is received.
If the Message Text File is full, the SRS removes
the oldest messages from the File. It does this
by deleting references to these messages in the
DTG and Message Retrieval Files (18).
The deletion procedure terminates when three conditions
are satisfied. First, the MTF must have available
a "threshold" number of free disk sectors for new
message storage.
Second, the Message Retrieval File must not describe
more than 44.500 messages.
Finally the Date Time Group File must not reference
more than 720 hours of elapsed time.
4.1.1.2.5 D̲e̲l̲i̲v̲e̲r̲y̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲ ̲t̲o̲ ̲M̲E̲D̲E̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲s̲
The Printer Interface Process (PIP) calls QACCESS
to dequeue from its terminal print queues the entry
which has waited the longest and is of highest
precedence. A MEDE terminal is served by PIP when
output to the terminal has completed and its queue
has waiting print requests.
The MTCB Monitor is called to obtain the type of
data to be printed and its file location.
Output data types which are recognized include:
N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲m̲e̲s̲s̲a̲g̲e̲s̲, including those which require
Special Handling and those which are being delivered
to an interactive teleprinter or receive only printer.
C̲o̲o̲r̲d̲i̲n̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲r̲e̲l̲e̲a̲s̲e̲ ̲r̲e̲m̲a̲r̲k̲s̲ which originate
from other, local terminals.
M̲e̲s̲s̲a̲g̲e̲ ̲L̲o̲g̲ ̲r̲e̲p̲o̲r̲t̲s̲ which require formatting before
printing.
Requests to print data on interactive teleprinters
are not entered in terminal queues. To minimize
response time to the the terminal operator's display
request, PIP acts on interprocess messages which
bypass the input queue interface. After data has
been printed, the Message Entry Subsystem is notified
so that interactions may continue.
Print queues are ordered by priority. Message
precedence indicators are used to select queue
entries in the following order:
1. Special Handling
2. Message precedence "Z"
3. " " "Y"
4. " " "O"
5. Local print requests ("LP")
6. Message precedence "P"
7. " " "M"
8. " " "R"
4.1.1.2.5.1 P̲r̲i̲n̲t̲i̲n̲g̲ ̲N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
In this case the PIP is furnished with the retrieval
DTG of the message, by the MTCB monitor. This
value, together with that of the acceptance DTG
(time of release by the originator), will be output
after the text of the message is printed.
If the message requires Special Handling, PIP verifies
that the terminal operator has informed the Message
Entry Subsystem of his current password. If the
operator has not completed this action, QACCESS
is called to select an entry from the next available
input queues of the terminal.
If the queue delay before printing a Special Handling
message, after successful password verification,
is more than 10 minutes the message is diverted
to the Supervisor's Distribution Queue (19).
If the buffer which is dedicated in the PIP's data
space to the terminal, is free the first block
of the message is read from its input file (20).
The time of release of the message from the originating
MEDE is removed from the binary header (which is
itself discarded) and saved for printing after
the end of the message.
Prior to printing a Special Handling message the
Message Entry Subsystem is notified that printing
has commenced (21a). The interprocess message
awakens the idle MES process and allows the terminal
operator to initiate new procedures.
When the terminal is ready the header and text
contained in the buffer of the message is transmitted
to the terminal (21). No formatting by the PIP
is necessary, because each output line contains
its own standard line control character by printing
a message PIP supply the output with page number
and class marking on each page. Incompatible control
character resolution and necessary conversions
from ASCII to Baudot are performed by the micro-programmed
LTUX which drives the terminal.
Printing continues with the message buffer being
replenished from the disk as necessary.
The Address List remaining after the end of the
text is discarded. It is replaced by the release
time and retrieval time of the message.
After Special Handling messages are printed, the
Message Entry Subsystem is notified so that it
can query the associated terminal operator for
his SH password (21b).
4.1.1.2.5.2 P̲r̲i̲n̲t̲i̲n̲g̲ ̲C̲o̲o̲r̲d̲i̲n̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲R̲e̲l̲e̲a̲s̲e̲ ̲R̲e̲m̲a̲r̲k̲s̲
Remarks are read from the file the address of which
is specified in the MTCB. Only one disk sector
is required to store the contents of remarks data.
The file is read into the buffer dedicated to the
terminal. It is transmitted to the terminal without
additional formatting.
4.1.1.2.5.3 P̲r̲i̲n̲t̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲L̲o̲g̲ ̲E̲n̲t̲r̲i̲e̲s̲
Message Log entries are stored not on disk files,
but are recorded in-memory as the associated event
occurs. The contents of the entry is obtained
by calling the MTCB Monitor, who maintains a "pseudo
MTCB" which contains the recorded log entry.
PIP uses these data to format a single print line,
as exemplified by:
LOG DTG MSG REL msg ̲id
After the line is printed, the MTCB Monitor is
notified, so that the pseudo MTCB can be released
for reallocation.
