top - download
⟦340bc7c4d⟧ Wang Wps File
Length: 12708 (0x31a4)
Types: Wang Wps File
Notes: FIX/1000/PSP/038
Names: »5202A «
Derivation
└─⟦e48583e73⟧ Bits:30006141 8" Wang WCS floppy, CR 0514A
└─ ⟦this⟧ »5202A «
WangText
…0f…
5202A/bna…02…FIX/1000/PSP/0038
…02…MLA/850529…02……02…
FIKS SYSTEM SPECIFICATION
…02……02…FK7809…0e…
4.1.1.3 M̲e̲s̲s̲a̲g̲e̲ ̲O̲r̲i̲g̲i̲n̲a̲t̲i̲o̲n̲
Narrative messages enter the FIKS Network from interactive
terminals connected to MEDEs. Control messages enter
the Network from software subsystems which react to
operating conditions (status) or to operating history
(statistics).
The discussion of this section summarizes the events
that occur, as narrative messages are created and then
transmitted to Network terminals.
4.1.1.3.1 M̲e̲s̲s̲a̲g̲e̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲L̲o̲g̲o̲n̲
Before a terminal user is granted access to the MEDE,
he performs the logon procedure. In response to prompts
from the Interactive Terminal Monitor, he supplies
a userid and logon pasasword (22).
The ITM retrieves the User Security Profile (USP) entry
from the USP file that corresponds to the logon userid
(23).
If the logon password does not match that of the USP
entry then an invalid logon has been attempted. The
ITM makes an entry in the Supervisory functions Subsystem's
AL queue to notify the N/M supervision with an invalid
logon alarm.
If the operator performs the logon sequence correctly
then the ITM retrieves his security clearance from
the USP entry. The terminal's active security clearance
then is recorded in the associated Terminal Control
Block. This clearance is established by entering the
operator's security clearence, in the terminal's TCB.
The ITM concludes the logon sequence by marking the
TCB as logged on which will allow other commands than
LOGON.
Immediately upon gaining control, the terminal's process
requests the ITM to issue to the terminal a prompt
that requests input of a procedure name.
The response from the operator to the prompt
directs the process to execute a module of the Message
Entry Subsystem. Each module supports the performance
of one of the eight message user functions, which are
illustrated in the bottom right half of the block diagram.
In either cases the ITM queue a log report to be printed
on the log printer.
4.1.1.3.2 M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲
When a new message originates from the MEDE, an interactive
terminal is used to communicate with the Message Entry
Subsystem (MES) (24). The terminal operates in a line-at-a-time
mode for entry of the message header in Simplified
Message Format (SMF).
Before the first line of the SMF is entered, the MES
requests that a permanent file will be allocated for
storing of the message in the Preparation Data Base
(PDB) (25).
A new message is entered into the PDB in two stages.
First, the validated lines of the SMF header are stored
on a sector by sector basis in the PDB after reference
is made to the Routing Directory File to obtain the
correct routing indications (26). Then, after the header
is completely stored, the text of the message is entered
and written to the PDB (27). The user optionally is
assisted in entering text by displays of fill-in-the-blanks
text masks that he can call up from the Text Mask File
(27a).
Message header and text is restricted in length to
a maximum of 9000 characters. Also, no more than 10
messages can be under preparation, stored in the PDB,
at a terminal.
4.1.1.3.3. M̲e̲s̲s̲a̲g̲e̲ ̲C̲o̲o̲r̲d̲i̲n̲a̲t̲i̲o̲n̲
If the new message must be coordinated prior to its
release, a temporary Remarks File is allocated which
stores comments directed to and from the message coordinator
terminal (28).
4.1.1.3.4 M̲e̲s̲s̲a̲g̲e̲ ̲E̲d̲i̲t̲i̲n̲g̲
If the message must be modified before its release,
a temporary Edit File is allocated which stores the
edited version of the original message in the PDB (29).
If the user decides to replace the original message
with its edited version, the temporary Edit File is
entered into the PDB as a replacement of the original
file (30).
4.1.1.3.5 D̲e̲l̲e̲t̲i̲o̲n̲ ̲o̲f̲ ̲P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲F̲i̲l̲e̲s̲
The terminal operator can request that any of the 10
possible messages in the PDB associated with his terminal
should be deleted (31).
In this case the Message Entry Subsystem calls the
MTCB Monitor and requests that the MTCB, which describes
the message in the PDB, to be deleted. The MTCB of
the message is unknown to other subsystems. The MTCB
Monitor releases the MTCB and requests the File Management
System to delete the file of the message (32).
4.1.1.3.6 M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲l̲e̲a̲s̲e̲
Any of the 10 possible messages which are stored in
the preparation files of a terminal can be released
by an operator for distribution to its addressees.
When a command is received to release a message (33)
the MES at first verifies that the terminal is one
which is authorized to initiate such a request.
If the terminal is not authorized to release messages,
then the MES updates the MTCB of the message with an
indication that the message is being sent to another
terminal for release. The identity of the terminal
which is authorized to release messages is recorded
in the control block (TCB) of the requesting terminal
which is maintained by the Interactive Terminal Monitor.
The MES makes an entry in the RL queue of the authorized
release-position's terminal (33a).
When the authorized release-position operator requests
the next entry from his terminal's Release Queue, the
message is read from the PDB file and displayed on
the terminal (33b). If the operator authorizes release,
then the originating terminal operator is notified
of the time of day his message was released (33c) and
the release action begins.
If the release-position operator declines to release
the originator's message, then the MES accepts from
the release operator a partial text line of remarks
(33d). These remarks are written to a Remarks File,
created temporarily for that purpose (33e). The MES
makes an entry in the LP queue of the originating terminal
which subsequently will print the release-position
operator's remarks about his refusal to release the
message (33f).
If the originating terminal is authorized to release
messages, or if the release-position operator authorizes
release, then the MES updates the message's binary
header with the time of day. It then requests the QACCESS
Monitor to enqueue the message's MTCB index into the
appropriate precedence queue of the Message Distribution
Subsystem (34). It also requests the MTCB Monitor to
release its use (MES) of the message's MTCB.
4.1.1.3.7 S̲t̲o̲r̲a̲g̲e̲ ̲o̲f̲ ̲R̲e̲l̲e̲a̲s̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Messages which do not require Special Handling are
entered into the Historical Data Base. The MDS initiates
this action through its interface to the SRS (35),
in the same manner as described earlier for inbound
message delivery (15,16,17,18).
Messages which require Special Handling remain on the
Preparation Data Base until the completion of outbound
transmission by the Nodal Switch Subsystem and local
delivery by the MDS, if required. The message subsequently
is deleted from the PDB.
Deletion of messages from the PDB after their release
occurs indirectly through process interaction with
the QACCESS Monitor. MDS reads MTCB index references
from its input queues but does not d̲e̲q̲u̲e̲u̲e̲ them, until
after they are enqueued into the input queues served
by the Nodal Switch Subsystem. Likewise, the NSS first
reads and then dequeues MTCB indexes from its input
queues. The resultant interaction between QACCESS and
the MTCB Monitor deletes the message itself, when its
use count reaches zero.
4.1.1.3.8 R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲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̲
A message which has been entered into the HDB may be
retrieved at any time from qualified terminals. When
an operator requests that the Message Entry Subsystem
initiate a retrieval from the HDB, the Storage and
Retrieval Subsystem is requested by the MES to initiate
the locating of messages which meet the input search
criteria (36).
Retrieval criteria are specified as one of the input
keys:
(1) message ID and retrieval DTG; or
(2) retrieval DTG range; or
(3) retrieval DTG range and Subject Indicator Code.
When a message is found in the HDB's Message Retrieval
File which satisfies the search criteria, the SRS determines
whether the terminal is qualified to retrieve it.
A message user terminal is considered qualified to
retrieve a given message if it represented an ANO which
was a "TO" or "INFO" addressee of the message at distribution
time or if the terminal was used originally to prepare
the message. Further, the terminal is qualified to
retrieve a messae, if the current, active security
clearance level is not lower than that of the message.
Supervisory are restricted only by their security clearances.
The simplest retrieval case is initiated when the MES
receives a request for a single message to be located
by the SRS from the message's ID and retrieval time.
The design approach assumes that this case also is
by far the most frequent retrieval request likely to
be received. In this case the DTG File is accessed
directly by the SRS to obtain the index to the HDB's
Message Retrieval File record that describes the message
(37). The retrieval request is considered successful
if the terminal is fully qualified to retrieve the
message. If the terminal is not qualified or if the
message cannot be found, then the request is considered
to have failed.
The last two retrieval cases require the SRS to search
the Message Retrieval File for all messages whose retrieval
times and SIC references satisfy the input criteria
(38). When a message is found, the SRS compares its
security classification to the terminal's current active
clearance. If the message's clearance is higher, then
it is eliminated from the set of retrievable messages.
If the message is included in the retrievable set,
then the SRS calls the MTCB Monitor. A free MTCB which
records the address of the message, its character length,
its security claasification, its original precedence,
and its retrieval time, is allocated.
The search of the MRF terminates successfully when
from one to ten messages are located with the requested
retrieval time range. In this case, the SRS calls QACCESS
and requests that the MTCB index references may be
enqueued into the appropriate queue for the messages
which were located. The specific queue is that requested
by the subsystem which initiated the retrieval.
If the search is unsuccessful the SRS returns an error
notice to the requestor. It performs this using the
request MTCB of the retrieval request. The Monitor
is requested to write the error notice into the MTCB.
QACCESS is then requested to enter the MTCB's index
into the requestor's retrieval queue.
Successful interactive requests for retrieval from
the HDB result in the SRS's identifying the disk address
of messages which satisfy the retrieval criteria. The
physical transfer of the located messages occurs later
under control of the Message Entry Subsystem or the
Printer Interface Process.
This "locate-now-transfer-later"-approach is taken
for two reasons. First, the retrieval function itself
is aasumed to operate in a low priority, back ground
fashion with data base updates taken precedence. Secondly,
separation of the message location procedure from the
message-transfer procedure ensures that access security
is controlled at both access points.
4.1.1.3.9 D̲i̲s̲p̲l̲a̲y̲ ̲o̲f̲ ̲R̲e̲t̲r̲i̲e̲v̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Messages retrieved interactively from the HDB are entered
into the requested queue of the terminal operator.
Two queue types are supported. The LP queue is specified
if the operator wants a hard copy printed in a batch-oriented
background manner, without further interaction with
the Message Entry Subsystem (39).
The RT queue is specified if the terminal operator
intends to request the MES to display the message directly
on the interactive terminal (40).
4.1.1.3.10 M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲a̲d̲d̲r̲e̲s̲s̲a̲l̲
The user can also employ the message retrieval interface
implicitly (41) by requesting readdressal of a message
which he originated or received. In this case, the
only retrieval key is the ID and retrieval DTG of the
message. The Message Entry Subsystem executes this
request by preparing a message which has the header
and text of the original message appended to the text
of the new message (42). The SRS functions in the same
manner as the general retrieval request does.
