top - metrics - download
⟦9a7014c11⟧ Wang Wps File
Length: 68493 (0x10b8d)
Types: Wang Wps File
Notes: IDCN - EL-BIT Vol. II
Names: »4320A «
Derivation
└─⟦2d59e51b9⟧ Bits:30006026 8" Wang WCS floppy, CR 0397A
└─⟦this⟧ »4320A «
WangText
…14……08……14……01……13……08……13……0e……13……0f……13……00……13……01……13……06……13……07……12……0b……12……0c……12……0f……12……00……12… …11……0a……11……01……11……06……10……09……10……0c……10……01……10……05……10……06……86…1
…02…
…02…
…02…
…02…
IDCN -
VOLUME
II
SYS/83-11-18
TECHNICAL
PROPOSAL
Page
3.5 S̲O̲F̲T̲W̲A̲R̲E̲
The following S/W packages are included in this proposal
for the IDCN:
O̲n̲ ̲l̲i̲n̲e̲ ̲e̲x̲e̲c̲u̲t̲i̲v̲e̲ ̲s̲y̲s̲t̲e̲m̲
Applied in Total no.
Node/Mede SCC of copies
o XAMOS operating
system x x 5
o Extensions x x 5
o On line diagnostics x x 5
O̲n̲ ̲l̲i̲n̲e̲ ̲a̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲s̲
o Node/Mede application x 4
o SCC application x 1
O̲f̲f̲ ̲l̲i̲n̲e̲ ̲s̲u̲p̲p̲o̲r̲t̲
o H/W Maintenance and
diagnostics x x 5
o S/W Development x 1
Each package is further described in the sections below.
3.5.1 X̲A̲M̲O̲S̲ ̲O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲
The XAMOS operating system comprises the following
subsystems:
o XAMOS Kernel
o File Management System (FMS)
o Input/output system (I/O System)
o Critical Region Monitor
The function of the XAMOS Kernel is to allocate CPU
time to processes as a function not only of their priority,
but also of their application characteristics.
The Kernel further performs event synchronization,
interprocess communication and fault detection.
The I/O Systems supports the application programs in
accessing I/O devices by a uniform set of commands.
The I/O System contains drivers for external devices
such as TDX Driver, DISC Driver dualized disc system,
and drivers for the different terminal types: VDUs
teleprinters, graphics colour display etc.
The file management function exhibits also a departure
from the traditional approach found in recent communication
network implementations. It recognizes that a primary
design goal is to minimize the elapsed time for disk
file operations, while supporting dynamic file creation,
extension and deletion for multiple interactive terminal
users and for real-time network traffic. It meets
these objectives in part by isolating, in a separate
computer system, disk file operations from execution
of IDCN application processes.
The File Management Supervisor treats the disk unit
as two logical devices. This allows data transfer
from the fixed-head portion of the disk to occur simultaneously
with moving-head seek operations.
Disk operations are dualized on two separate disk units.
This is accomplished by duplicating the logical file
structure and control on each of two configured disk
units. Disk dualization is supported by the Input/Output
System and the File Management System in a way that
is transparent to application programs, except for
reporting of disk operation status. Error status returns
are reported by application software to the Error Switchover
Processor.
The file management function further reduces the potential
for bottlenecks to throughput by providing multiple,
logical data channels between the File Processor (FP)
and the IDCN application, or User Processor (UPs).
These channels, referred to as "DMA ports", transfer
commands and data concurrently between the FP and UP.
The FP services each transfer in a sequence whose
priority is specified for each port. The number of
ports in concurrent use is a system parameter.
The fault detection and error recovery function provides
on line test and diagnostics concurrently with the
real time functions performed by applications processes.
It attempts also to recover from CPU and other processors'
execution faults. If the fault is unrecoverable the
Error Switchover Processor (ESP) is notified of the
condition. The ESP is otherwise notified periodically
that the processors of the system are executing normally.
Finally, this function provides for recovery from
system failure by recording the occurrence of significant
events that indicate message and terminal status.
These checkpoint records are available to the standby
processor during its restart and recovery procedure.
3.5.2 E̲x̲t̲e̲n̲s̲i̲o̲n̲s̲
The standard XAMOS operating system has been extenden
to support the concurrent flow of messages and reports
through a Node/Mede and SCC system and to provide facilities
for dualized operation.
These extensions are categorized as:
o Memory Management
o Message transition control (MTCB Monitor)
o Queue Access Management (QACCESS)
o Shared Memory Access (Critical Regions)
o Switchover and Recovery
o On line diagnostics
The queue and memory management monitors are designed
to interact as necessary to manage the shared use of
primary and secondary disk memory. They recognize
that subsystems are designed to execute as queue driven,
independent groups of software processes.
3.5.2.1 M̲e̲m̲o̲r̲y̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Each program is allocated, at system start up time,
a contiguous data space large enough to contain its
I/O buffers and file descriptions, and other data local
to execution of the program. This results in identifying,
to the ESP, the program and its data space as a "process",
as illustrated in Figure 3.5.2.1-1. Processes in IDCN
may execute the same program reentrantly, but may not
share the same process data space.
3.5.2.2 M̲e̲s̲s̲a̲g̲e̲ ̲T̲r̲a̲n̲s̲i̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
Memory data space that is not dedicated to local processes,
or for global reference to subsystem queues or system
data, is avialable for allocation during system operation.
This space is designed to be used to record the status
of messages and reports as they flow through subsystem
interfaces.
Figure 3.5.2.2-1 illustrates use of Message Transition
Control Blocks (MTCBs) to maintain system-wide awareness
of the status of messages and reports. Awareness of
message status is maintained by recording in the MTCB
the indicators listed below.
a. The message is now being served by one (or
more) specific subsystem processes.
b. The message is located on an inbound file or
preparation file, or it is stored in the Historical
Data Base at a specific address.
Figure 3.5.2.1-1…01…Overview Of Process Concept
Figure 3.5.2.2-1…01…MTCB Use, Real MTCB
Figure 3.5.2.2-2…01…MTCB Use, Pseudo MTCB
c. The message requires optional special security
handling.
d. The message's precedence and length, in number
of bytes, is recorded.
e. The message's security classification is recorded,
if it is being delivered to a local MEDE terminal.
In addition to these common status indicators, the
MTCB is designed to record information needed for specific
subsystem use. This includes, for example, routing
information for message switching and distribution,
and the time of day the message was queued for entry
into the Historical Data Base.
To control the use of Message Transition Control Blocks,
an MTCB Monitor is used as shown in Figure 3.5.2.2-3.
It allocates fixed-length blocks from a memory pool,
assigning each block a number ("MTCB index") that is
used in queue references to messages and reports.
It provides also as an option the creation, and subsequent
deletion, of disk files for use by multiple processes.
It ensures that a file is not deleted until the last
process that references the file's MTCB completes processing.
Figure 3.5.2.2-3…01…Use Of MTCB Monitor
3.5.2.3 Q̲u̲e̲u̲e̲ ̲A̲c̲c̲e̲s̲s̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Processes that require a message or report to be delivered
to a subsysten or terminal interface request the QACCESS
monitor to perform the service. Figure 3.5.2.3-1 provides
an overview of the general queue structure, and its
memory management.
An entry in a queue is an index number that references
an MTCB.
Queue server processes call QACCESS to read or remove
queue entries, by FIFO precedence, or by position in
the queue.
Some interfaces are configures with one queue for each
level of message precedence. QACCESS can be requested
to enter and retrieve entries from a single logical
queue that represents the group of precedence queues
assigned to an interface.
Other queue management services are provided by QACCESS,
including the numbering and reorganizing of queues,
as well as returning data to the requestor about the
lengths of queues.
Figure 3.5.2.3-1
General Queue Structure
3.5.2.4 S̲h̲a̲r̲e̲d̲ ̲M̲e̲m̲o̲r̲y̲ ̲A̲c̲c̲e̲s̲s̲
The executive software has been extended to control
multiple processes that access concurrently shared,
"critical" regions. Processes that require such access
are considered to be in one of the states shown in
Figure 3.5.2.4-1.
Critical regions are addressed by symbolic name. Memory
locations within a critical region also are addressed
symbolically, the result being an offset value relative
to the origin of the region. The memory area contained
within a region is referred to as the "variable space",
or VS.
Figure 3.5.2.4-1…01…Critical Region Control
Note that the states shown in the Figure apply only
to the relation between a single region and a process.
The process may interact with several other regions
at the same time.
The meaning of the states are:
R̲e̲g̲i̲o̲n̲ ̲l̲e̲f̲t̲:
In this state the process has no access to the
VS of the region. A process will initially be
in this state.
R̲e̲g̲i̲o̲n̲ ̲e̲n̲t̲e̲r̲e̲d̲:
In this state the process has access to all the
variables of the VS. Only a single process can
be in this state (in relation to a specific region)
at any one time.
W̲a̲i̲t̲i̲n̲g̲ ̲t̲o̲ ̲e̲n̲t̲e̲r̲ ̲r̲e̲g̲i̲o̲n̲
The process is suspended until no other process
is in the "region entered" state.
W̲a̲i̲t̲i̲n̲g̲ ̲t̲o̲ ̲r̲e̲-̲e̲n̲t̲e̲r̲ ̲r̲e̲g̲i̲o̲n̲
The process is suspended until a process leaves
the region.
The purpose of this state is to be able to wait
until the variables of the VS fulfils a wanted
condition.
The transitions between the states occur at the following
events:
1: The current process calls ENTER-REGION and
the region already contains a process in the
"region entered" state.
2: The current process calls ENTER-REGION and
no process is in the "region entered" state.
3: Another process (which was in the "region entered"
state) calls LEAVE-REGION or WAIT-REGION, and
the current process is at the head of the queue
of processes waiting to enter the region and
no processes w̲e̲r̲e̲ in the state "waiting to
re-enter region".
4: The process calls LEAVE-REGION.
5: The current process calls WAIT-REGION.
6: Another process calls LEAVE-REGION or WAIT-REGION
and the current process is at the head of the
queue of processes waiting to re-enter the
region.
The normal use of critical regions is:
o to enter a region
o modify and/or inspect the variables in VS
o if the varibales inspected must fulfil a certain
condition (which they do not) before processing
can continue, the process may call WAIT-REGION.
This causes the process to be delayed until
at least one other process has been in the
"region entered" state.
o and finally to leave the region.
A region does not need to control a VS. If it does
not, the criticl region serves as a simple synchronization
element.
3.5.2.5 S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
Switchover and recovery is performed by the ESP - Error
and Switchover Process. The functions performed by
the ESP are as follows:
o Start
o Restart/Recovery
o Checkpointing
o Watchdog communication
S̲t̲a̲r̲t̲
The very first initialization of a N/M is called
the start. The subsystems are loaded, initialized,
and started with the common RESTART ̲FLAG set to
FALSE.
There are no messages within the subsystems for
which they are responsible.
R̲e̲s̲t̲a̲r̲t̲/̲R̲e̲c̲o̲v̲e̲r̲y̲
The system restart function executes after a switchover
from an active to standby Node/MEDE configuration
branch. During a restart the former cold stand-by
N/M computer is started, i.e. the subsystems are
initialized with the common RESTART ̲FLAG set to
TRUE.
In case of a fatal error in the active branch,
i.e. an error which makes it impossible for the
branch to continue operations a switchover from
active to stand by branch shall be performed.
The stand by branch has to be RECOVER'ed. This
means that it must be brought into a position from
where the former active failed. The standby branch
has in advance been loaded with all necessary software
modules ready to start executing of instructions.
The Disk system and TDX-system can immediately
be used. The vital thing missing to start operations
is the data placed in the CR80-memory of the former
active branch. These data are recovered by use
of CHECKPOINTs stored outside the CR80 memory.
Checkpoints are data records that defines the
state and substate of a system e.g.
- state of message being processed
- state of trunk
- state of terminal
etc.
These records are in the IDCN system stored in
the disk system, where they can be retrieved by
the standby branch. After the processes are started
in the standby branch these checkpoints are processed
in the RESTART procedure to reestablish the data
structures in the CR80-memory as close as possible
to the original contents former active:
o All queues and MTCB's are regenerated.
o The Nodal Data File is loaded as left by
the failed branch. In this way neither
routing information nor trunk status are
lost.
o All trunks, which were open during the
crash, are re-opened.
o The outbound Message file is scanned, emptied
and each message is put into the transport
queue for rerouting and retransmission.
o After recovery normal processing continues
and no messages are lost.
C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲
By means of checkpoints the book-keeping of messages
for which the Node/Mede is responsible are currently
updated.
Locally generated messages put into the Transport
Queue are p̲o̲s̲i̲t̲i̲v̲e̲l̲y̲ checkpointed by the supplier.
remote generated messages are p̲o̲s̲i̲t̲i̲v̲e̲l̲y̲ checkpointed
when written on disc before the ACK is returned.
Whenever a message for which the Node is responsible
is put into an output queue a positive checkpoint
is made. For the transport queue, however, this
is done by saving the Outbound Message Buffer onto
the Outbound Message File or the Checkpoint File.
When a message is deleted from a queue a n̲e̲g̲a̲t̲i̲v̲e̲
checkpoint is made. For the transport queue, however,
this is done by saving the Outbound Message Buffer
onto the Outbound Message File.
Figure 3.5.2.5-1 shows some typical checkpoint
events.
S̲U̲B̲S̲Y̲S̲T̲E̲M̲ A̲C̲T̲I̲O̲N̲ R̲E̲S̲P̲O̲N̲S̲I̲B̲L̲E̲
B: ACCESS MSG. IN QUEUE AB
B
B: PROCESS MSG
B: PUT MSG: INTO QUEUE BC
B: MAKE A POSITIVE CHECKPOINT FOR C
B: MAKE A NEGATIVE CHECKPOINT FOR B
B: REMOVE MSG. FROM QUEUE AB
C
C: PROCESS MSG.
C: PUT MSG. INTO QUEUE CD
C: MAKE A POSITIVE CHECKPOINT FOR D
C: MAKE A NEGATIVE CHECKPOINT FOR C
C: REMOVE MSG. FROM QUEUE BC
D
Figure 3.5.2.5-1…01…Positive And Negative Checkpoints
W̲a̲t̲c̲h̲d̲o̲g̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
The ESP resides in both the active and the standby
branch of the dualized CR80 Node/Mede computer.
Both ESP will with regular intervals send Keep
alive messages to the Watchdog. If Keep alive
messages from the active branch are missing, the
watchdog will initiate switchover. The ESP will
receive error messages from the on line diagnostics
and in case of fatal errors request for a switchover.
Also fatal S/W errors will be cause notification
of the ESP, which will initiate switchover and
restart.
3.5.3 O̲n̲ ̲L̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲
On line diagnostic programs will be provided to perform
fault detection on the following CR80 Modules:
o CPUs
o RAMs
o PROMs
The on line diagnostic programs will be executed in
lowest priority, and will operate as part of the operational
software in both the active and the standby processor
system.
The diagnostic results will be available for automatic
transmission to the SCC, upon request from the SCC
Supervisor.
3.5.4 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̲
The Node/Mede Application Software consits of the following
subsystems:
. M̲e̲s̲s̲a̲g̲e̲ ̲E̲n̲t̲r̲y̲ (MES) Handling of interactive procedures
for entering and editing messages from VDUs and
teleprinters.
. M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ (MDS) Local distribution,
formatting and printing of messages.
. S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ (SRS) Storing and Retrieval
of Messages on the log term storage.
. N̲o̲d̲a̲l̲ ̲S̲w̲i̲t̲c̲h̲(NSS) Network message switching, routing
and internodal message transmission.
. S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲y̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ (SFS): Node/Mede Supervision
and Control, Supervisor Procedures and Communication
with the SCC Supervision and Control.
. S̲C̲C̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲ (SIP):
Exchange of messages with the collocated SCC. Only
included in the Node/Mede connected to an SCC.
The figure 3.5.4-1 below shows the an overview of the
interfaces between subsystems.
Figure 3.5.4-1
Node/Mede Software
3.5.4.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 3.5.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 logicl 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 3.5.4.1-1
Node/Mede System
Narrative Message Flow
Figure 3.5.4.1-2
NODE/MEDE System
Narrative Message Flow
I̲n̲b̲o̲u̲n̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
Narrative and control messages arrive at the TDX Interface
simultaneously from up to 7 internodal trunk lines.
On a given trunk, as illustrated in Figure 3.5.4.1-3,
messages are intermixed, arriving in packets by precedence
level.
Message packets are variable in length up to a maximum
size, whose value is a system parameter. The message
data portion of the packet currently is set at a maximum
of 512 bytes.
Figure 3.5.4.1-3
Nodal Switch Queues
N̲o̲d̲a̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲S̲w̲i̲t̲c̲h̲i̲n̲g̲
Employing X25 Level 3 protocol, the NSS buffers the
packets of an incoming message (1). Buffers may be
temporarily unavailable. If so, acknowledgement of
packet receipt to the sending Node is withheld. This
action inhibits further input of message packets.
The first packet of a message indicates a new transmission
serial number. If this number is not greater in value
than the serial number of a previous messae received
from the internodal trunk, then the message is assumed
to be a duplicate and is discarded, but acknowledged,
as its packets are received. If the serial number is
greater by 2 or more than the previous value, then
a negative acknowledgement is sent to the sending Node
reporting a message transmission serial number error
(1a).
The binary header that is contained in the message's
first packet is referenced to obtain the routing information.
These data provide identifiers of the appropriate MEDE
or SCC that will receive a copy of the message.
This information is entered into a Message Transition
Control Block (MTCB) that is requested from the MTCB
Monitor.
Acknowledgement to the sending Node, of receipt of
the first packet, is withheld pending the reservation
of the MTCB and its associated file (3).
The header of each incoming packet then is referenced
to determine its sequence number and if it is the last
packet comprising the message.
As packets are written to the IMF (4), their headers
are removed. If packet sequence numbers indicate transmission
errors, then the sending Node is requested to retransmit
the message (4a). Otherwise, each packet is acknowledged
by the NSS by trnsmitting the appropriate X.25 control
message response.
If the NSS receives from the I/O System a status indication
of trunk failure, it reports the failure to the Supervisory
Function Subsystem (4b).
After the last packet has been written to the message's
IMF, the Nodal Switch acknowledges, to the sending
Node, its receipt of the message (5).
If the message is intended for rely to another Node,
then its orbit control count is decremented. If the
count becomes zero, then the message's MTCB is updated
to indicate that an orbit error has occurred.
This overrides the binary header's internodal relay
indicator, as specified by the routing mask, to direct
the message to the MEDE for disposal (6a).
The QACCESS Monitor then is invoked to make an entry
in the Nodal Switch's trunk queue for outbound transmission
of the message to be relayed (6).
The entry is time-stamped by QACCESS and entered in
the queue that is designated for outbound messages
of the requested precedence level. QACCESS updates
also the message's MTCB to indicate that further use
of the message's file is pending (the Inbound Message
File then becomes also an "outbound message file",
avoiding unnecessary interface to the File Processor).
The message may be intended for delivery to the SCC
that is collocated with the Node/MEDE. In this case,
QACCESS is requested to enter the message's MTCB index
number in the input queue servied by the SCC Interface
Process (SIP).
If the message is intended for delivery to the MEDE,
then QAACCESS is requested to enter the message's MTCB
reference into the appropriate precedence-level input
queue of the Message Distribution Subsystem (7).
QACCESS notifies the MDS that a message awaits distribution
if the MDS's input queue is empty when the enqueue
request was made. A logical "signal" is sent to the
MDS interface through the XAMOS' interprocess communication
facility.
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 that 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 message's MTCB index,
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 message's file.
The MDS provides this file descripton to the Input/Output
System in a request to read the message's Address List
from the file (8). The List together with the MTCB's
"classification" field, 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 whose security classification
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 message's Address List, when compared to the
MDS's distribution directory, reveals erroneous addresse
data, then an entry is made in the SFS Distribution
Queue (DT) that references the MTCB for this unknown
ANO error condition (8a).
If the classification of the message is higher than
that of the operator then an entry is made in the SFS
Distribution queue (DT).
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, then the message
is entered into the Historical Data Base (11). This
is initiated by the MDS through a queue request to
QACCESS. The queue entry contains the message's input
file descriptor and the time of day the entry was made.
The message's MTCB is updated prior to the queue request,
by the MDS, with the time of day the queue request
was made.
The time that is recorded in the MTCB becomes the retrieval
data time group (DTG) for the message.
QACCESS then is called to enter the MTCB reference
into the Printer Interface Process'es terminal queues
(12).
The monitor call specifies each queue's terminal number
and a count of the number of message copies to be printed
at each addressed terminal.
This action concludes delivery of the message.
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), then QACCESS is called to
queue the message to the Supervisory Functions Subsystem
input queue (12a). The request specifies that the DT
queue receives the MTCB reference.
QACCESS then is requested to enqueue the message to
the Storage and Retrieval Subsystem's input queue for
entry into the HDB (13).
This concludes delivery of intercepted messages.
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. In this special case, the MTCB indicates also
the message's subsystem destination (logical terminal
number maintained by QACCESS):
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,
then QACCESS is called to enqueue the message into
the SF queue (14).
If the collocated SCC is the recipient, then QACCESS
enters the message into the SCC input queue.
These actions conclude delivery of the control message.
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 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 to store the message on the HDB's Message
Text File is available, then 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 message's ID, its
SIC references, its security class and its length.
The message's DTG, to be used later in retrieval requests,
is obtained from the storage input queue's MTCB reference.
It is added to the Message Retrieval File at this point.
Each message is stored on the MTF beginning at a new
disc 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 message's input
file and written to the next sequential disc sectors
of the MTF.
The last input block contains the message's Address
List. The Message Retrieval File is updated with these
data to record the terminal ID's that 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, that is entered
into the storage input queue. DTGF records contain
offset values of record addresses in the Message Retrieval
File that correspond to each recorded minute.
The SRS then calls the MTCB Monitor to update the message's
MTCB. 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).
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 disc
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, then the SRS removes
the oldest messages from the Files. 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 disc sectors for new message
storage.
Secondly, the Message Retrieval File must not describe
more than 44.500 messages.
Finally, the Date Time Group File must not reference
more than 72 hours of elapsed time.
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 that
has waited lonest and that 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 that are recognized include:
Narrative Messages, including those that require
Special Handling and those that are being delivered
to an interactive teleprinter or receive only printer;
Coordination and release remarks that originate
from other, local terminals;
Message Log reports, which require formatting before
printing.
Requests to print data on interactive teleprinters
are not entered in terminal queues. To minimize response
time to the terminal operator's display request, PIP
acts on interprocess messages that 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 (optional feature)
2. Message precedence "Z"
3. "Y"
4. "O"
5. Local print requests ("LP")
6. Message precedence "P"
7. "M"
8. "R"
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 message's
retrieval DTG, by the MTCB monitor. This value, together
with that of the acceptance DTG (time of release by
the originator), will be output after the message's
text is printed.
If the message requires Special Handling, then PIP
verifies that the terminal operator has informed the
Message Entry Subsystem of his current password. If
the operator has not completed this action, then QACCESS
is called to select an entry from the next available
terminals's input queues.
If the queue delay before printing a Special Handling
message, after successful password verification, is
greater than 10 minutes then the message is diverted
to the Supervisor's Distribution Queue (19).
If the buffer, that is dedicated in the PIP's data
space to the terminal, is free, then the first block
of the message is read from its input file (20).
The message's time of release 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 message's header and
text contained in the buffer 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
and 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 that drives the terminal.
Printing continues, with the message buffer being replenished
from the disc as necessary.
The Address List remaining after the end of the text
is discarded. It is replaced by the message's release
time and retrieval time.
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).
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 whose address 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
fomatting.
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 content of the entry is obtained by calling the
MTCB Monitor, who maintains a "pseudo MTCB" that 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.
M̲e̲s̲s̲a̲g̲e̲ ̲O̲r̲i̲g̲i̲n̲a̲t̲i̲o̲n̲
Narrative messages enter the IDCN Network from interactive
terminals connected to MEDEs. Control messages enter
the Network from software subsystems that 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.
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 password (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 entrering the
operator's security clearance, in the terminal's TCB.
The ITM concludes the logon sequence by requesting
the XAMOS Kernel to start the process that communicates
with the terminal operator.
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.
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 be allocated to store
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 maximun of 9000 characters. Also, no more than 10
messages can be under preparation, stored in the PDB,
at a terminal.
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 that
stores comments directed to and from the message coordinator
terminal (28).
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 that 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).
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 one of the
10 possible messages in the PDB, associated with his
terminal, be deleted (31).
In this case, the Message Entry Subsystem calls the
MTCB Monitor and requests that the MTCB be released
that describes the message to be deleted from the TDB.
The MTCB Monitor releases the MTCB to delete the message's
file (32).
M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲l̲e̲a̲s̲e̲
Any one of the 10 possible messages that are stored
in a terminal's preparation files can be released by
an operator for distribution to its addressees. When
a command is received to release a message (33), the
MES first verifies that the terminal is one that is
authorized to initiate such a request.
If the terminal is not authorized to release message,
then the MES updates the message's MTCB with an indication
that the message is being sent to another terminal
for release. The identity of the terminal that is authorized
to release messages is recorded in the requesting terminal's
control block (TCB) that 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 originating terminal's LP queue
that subsequently will print the releas-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 authorized
release, then the MES updates the message's binary
header with the time of day. It then requests the QACCESS
Monitor to queue 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.
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 that 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 that 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 queued 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 resulting interaction between QACCESS and
the MTCB Monitor deletes the message itself, when its
use count reaches zero.
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 that 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 location of messages that meet the input search
criteria (36).
Retrieval criteria are specified as one of the input
keys:
(l) 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, that satisfies the search criteria, the SRS determines
if the terminal is qualified to retrieve it.
A message user terminal is considered qualified to
retrieve a given message if it representing an ANO
that 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 current, active
security clearance level is not lower than that of
the message. Supervisors 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 is
allocated that records the message's address, its character
length, its security classification, its original precedence
and its retrieval time.
The search of the MRF terminates successfully when
from one to 10 messages are located with the requested
retrieval time range. In this case, the SRS calls QACCESS
and requests that the MTCB index references be queued
into the appropriate queue for the message that was
located. The specific queue is that, which is requested
by the subsystem that 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 then is 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 that 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 assumed to operate in a low priority, background
fashion with data base updates taking precedence. Secondly,
separation of the message location procedure from the
message-transfer procedure ensures that access security
is controlled at both access points.
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 terminal operator's requested queue. 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).
M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲a̲d̲d̲r̲e̲s̲s̲i̲n̲g̲
The user also can employ the message retrieval interface
implicitly (41) by requesting readdressing of a message
that he originated or received. In this case, the only
retrieval key is the message's ID and retrieval DTG.
The Message Entry Subsystem executes this request by
preparing a message that has the original message's
header and text appendiced to the new message's text
(42). The SRS functions in the same manner as for the
general retrieval request.
O̲u̲t̲b̲o̲u̲n̲d̲ ̲N̲o̲d̲a̲l̲ ̲S̲w̲i̲t̲c̲h̲i̲n̲g̲
The MDS makes an entry in the Nodal Switch Subsystem's
input queue that requests route selection and transmission
of the message to the network (43). The MTCB index
number that references the message is entered in the
NSS's "transport queue" that serves the precedence
level requested when the message was prepared.
The enqueued MTCB contains the message's file address
and length. If the Storage and Retrieval Subsystem
enters the message into the HDB before the NSS accesses
the MTCB, the message's new address is recorded in
the appropriate field of the MTCB. The MTCB contains
also the identifiers of th MEDEs that serve the terminals
that are addressees. NICS addresses and messages directed
to the active and standby SCCs are assigned appropriate
routine identifiers.
3.5.5 S̲C̲C̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The SCC functions are allocated to 3 application subsystems,
shown in Figure 3.5.5-1.
SCC Appli-
cation Sub-
systems
Inter-SCC Network Network
Handshaking Supervision Statistics
Subsystem Control
65 (ISH) 61 (NSC) 62 (NES)
Figure 3.5.5-1
SCC Application Subsystem
Figure 3.5.5-2 shows the logical interfaces between
the rest of the IDCN network and the SCC subsystems
and the interrelationship between the SCC subsystem.
The following serves as an explanation to Figure 3.5.5-2.
a. The Network Supervision and Control Subsystem (NSC)
receives and processes control messages from Node/MEDEs
and the standby SCC. Control messages are printed
on the log printer. Control messages containing
status change information are stored on disc.
The NSC will analyse control message header and,
based on the type, display an alarm, alert or notice
to the SCC supervisor. The NSC will handle commands
for display of status table information, routing
calculations and creation of network commands.
Outgoing network commands are logged on log printer.
b. Network Statistics Subsystem (NES)
The NES collects and stores statistical reports
from the Node/MEDE on-line. A 24 hour MEDE statistic
(i.e. message flow statistic) is generated for
each MEDE on supervisor's request and send to the
appropriate MEDE. Statistical data collected on-line
not belonging to the message flow statistic may
be dumped (on-line) to floppy disc.
Figure 3.5.5-2
SCC Software Overview
c. Inter-SCC Handshaking Subsystem (ISH)
This subsystem handles the SCC-SCC monitoring and
synchronization,when the network is configured
with two SCCs.
d. Collocated Node/Mede Interface (CIP)
This subsystem handles the exchange of control
messages between the SCC and the connected Node/Mede.
As shown in figure 3.5.5-3 a version of the Nodal
Switch Subsystem (NSS) resides in both the SCC
and the Node/Mede.
Figure 3.5.5-3
Logical Connection SCC - Collocated Node/MEDE
3.5.6 O̲f̲f̲-̲L̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲s̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
Off-Line diagnostics are disc resident programs which
may be loaded on a processor system, which is already
declared off-line because of noticeable error.
The off-line diagnostics programs must be able to operate
in the failed half part of the system simultaneously
with continued operation of the other half part.
Off-Line diagnostics detect faults by direct checking
of equipment modules and by analysis of test results,
which isolate faults to replaceable hardware modules.
The off-line Maintenance and Diagnostics (M+D) program
contains the following submodules; Central Processing
Unit Test (CPU), Random Access Memory Test (RAM), Prgrammable
Read Only Memory Test (PROM), and a simple functional
test of TDX bus communication.
The Central Processing Unit Test tests proper operation
of a CPU by verification of all possible instruction
in the instruction set except for Monitor call and
I/O instruction.
The Random Access Memory Test verifies proper operation
of RAM memory module. The following elements are tested:
Main Bus interface, RAM internal addressing circuit`ry
and storage circuitry.
The Programmable Read Only Memory Test verifies proper
operation and proper contents of the PROM.
The following elements are tested; mainbus interface,
internal addressing circuitry and contents of PROM
chips.
The off-line diagnostics programs are control from
a KSR ACII terminal connected to the Watchdog.
T̲D̲X̲ ̲O̲f̲f̲-̲L̲i̲n̲e̲ ̲T̲e̲s̲t̲
TDX off-line test software is PROM-resident programs
in the TDX-devices.
The off-line test are done by the active controllers
connected to the TDX-buses.
The TDX-controller is able to check all connected TDX-devices
(LTUX-S, LTUX-M and TDX Host I/F), and by an analysis
of their answers it is able to determine, whether the
device is working properly.
The TDX-controller runs a status table, which for every
TDX-device shows if it is working properly.
It is possible to request a dump of this status table.
This is done from the console connected to the Watchdog.
By a hardware switch on the Watchdog it is possible
to switch the console to the TDX-controller before
requesting a dump of the status table.
It is also be possible to connect a console directly
to a TDX-controller.
3.6 E̲X̲P̲A̲N̲D̲A̲B̲I̲L̲I̲T̲Y̲
Flexible variation in the size and structure of the
CR80 systems is permitted by the unusual degree of
hardware and software modularity. The hardware essentially
consists of fast transfer buses joined to each other
by adapters which allow units on one bus to access
those on another. Dualization at the internal level
and multiple redundancy at the system level provide
a CR80 hardware architecture which is fully exploited
by the DAMOS software operating system and programs
to provide survival after operational failure of individual
components.
These standard configurations encompass a broad range
of physical characteristics to meet the requirements
of the smaller stand-alone user and those of the largest
multi-installation network applications. The four models
offer a huge range of growth:
- A 50:1 range in instruction execution rate, varying
from 0.6 mips to 30 mips.
- A 1000:1 range in memory capacity, from 512 K bytes
to 512 megabytes.
- A 80:1 range in processing power, utilizing one
CPU or up to 16 interconnected multiprocessors
with a maximum of 5 CPU's each.
- A 400:1 range in connectivity, through Peripheral
controllers accommodating a variety of terminations
with as many as 960 peripherals or up to 4096 communication
lines.
The MX configuration proposed in this configuration
has initially been equipped with 512 KW of memory.
The memory can be expanded to 4 MW within the same
crate provided physical space is available.
The initial network topology contains 4 Node/Medes
and 1 SCC. This can be expanded to 32 Node/MEDEs and
2 SCCs.
3.7 S̲O̲F̲T̲W̲A̲R̲E̲ ̲M̲O̲D̲I̲F̲I̲C̲A̲T̲I̲O̲N̲S̲
3.7.1 S̲o̲f̲t̲w̲a̲r̲e̲ ̲M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
An overview of the software modifications to be done
on the existing baseline is given on table 3.7.1-1.
The table summarizes the itemized software subsystems
which are required for the message swithcing network.
The software is almost totally based on existing software.
Only the concentrator interface software is a new item.
The table summarizes per subsystem the estimated update
effort. Estimates are made in manmonths and based on
the current knowledge of the system. The estimates
cover software development activities such as: Design,
Code & Component Test, subsystem integration tests.
Excluded from the estimates are activities such as:
Requirements specification, system design, system integration
tests, and acceptance tests.
The table summarizes software modifications needed
for the software components residing in the principal
Nodes and the System Control Center.
Est. Dev.
̲ ̲ ̲ ̲ ̲ ̲N̲o̲.̲ ̲ ̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲E̲f̲f̲o̲r̲t̲ ̲(̲m̲/̲m̲)̲ ̲ ̲ ̲ ̲ ̲ ̲
̲C̲o̲m̲m̲e̲n̲t̲.̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲R̲e̲f̲.̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲ ̲
1. Operating System, Device AMOS
Drivers and Extensions 12 to
MXAMOS
upd. 3.7.2
2. Nodal Supervisory Software 14 updates 3.7.3
3. Message Distribution/
Output Software 8 updates 3.7.4
4. Storage and Retrieval S/W 4 updates 3.7.5
5. Message Journal and
Statistics Software 8 updates
3.7.6
6. Message Service Software 12 updates 3.7.7
7. System Control Center S/W 24 updates 3.7.8
8. Nodal Switch Software 2 updates
3.7.9
9. Concentrator Interface S/W 6 New
Item
…0e…x)…0f… 3.7.10
10. End-to-End Control Monitor 24 New
Item
…0e…xx) 3.7.11
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲T̲o̲t̲a̲l̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲1̲4̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
x) Standard X.25 I/F Software to be used
xx) Standard transport station to be amended
Table 3.7.1-1
Software Modifications Summary
3.7.2 Modifications to Operating System,
D̲e̲v̲i̲c̲e̲ ̲D̲r̲i̲v̲e̲r̲s̲ ̲a̲n̲d̲ ̲E̲x̲t̲e̲n̲s̲i̲o̲n̲s̲ ̲ ̲ ̲ ̲ ̲
The Operating System, Device Drivers and Extensions
are itemized in table 3.7.2-1.
̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲I̲t̲e̲m̲ ̲ ̲ ̲ ̲ ̲ ̲C̲o̲r̲r̲e̲s̲p̲.̲ ̲F̲I̲K̲S̲ ̲I̲t̲e̲m̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲C̲o̲m̲m̲e̲n̲t̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1. MXAMOS Kernel AMOS Kernel Kernel of the
system
2. STI Driver TDX Driver Device Driver
to the
TDX system
3. DSC Driver DISC Driver Device Driver
(disc)
4. TTY Driver TTY Driver Device Driver
(TTY)
5. Tape I/F Driver Tape I/F Driver Device Driver
(Tape)
6. Error Switchover - Same Module - Highlevel operating
Process (ESP) (FIKS DEV.) System (incl.
watch-
dog control
7. Checkpoint Process - Same Module - Checkpoint
Service
(FIKS DEV.) Extension
8. Recovery Process - Same Module - Recovery Service
(FIKS DEV.) Extension
9. Message Transition - Same Module - Control Block
Service
Control Block (FIKS DEV.) Extension
Monitor
10. Queue Access - Same Module
- Queue
Service
Extension
Monitor (FIKS DEV.)
11. Timer Process - Same Module
- Real
Time
Service
(FIKS DEV.) Extension
12. Interactive - Same Module
- Terminal
Interface
Terminal Monitor (FIKS DEV.) Service Extension
13. Address Table - Same Module
- Access
Service
Access Monitors (FIKS DEV.) Extension
14. User Profile - Same Module
- Access
Service
Access Monitors (FIKS DEV.) Extension
15. File Management File Management Standard
FMS
System (FMS) System
(AMOS based)
Table 3.7.2-1
Operating System, Device Drivers and Extensions Overview
Estimated
M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ E̲f̲f̲o̲r̲t̲ ̲(̲m̲/̲m̲)̲
a. General update of all software from AMOS
to MXAMOS which imply the following:
- Change of address room from 256K to
4
16 Mbyte (Mapped CPU)
- Privileged instructions added
- Boundary checks added
- Change from TDX driver to STI driver
b. Changes to the checkpoint events to be
included in the checkpoint process 1
c. Recovery Process to account for changed
checkpoints and additional software modules 1
d. Interactive Terminal Monitor to reflect
changes in profiles terminal types 2
e. Changes in addressing table address room and
format addresses to be reflected in the
address access monitors 2
f. Changes in user profile handling to be
reflected in user profile access monitors
̲ ̲2̲ ̲ ̲
̲
Total update effort
12 mm
3.7.3 M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲t̲o̲ ̲t̲h̲e̲ ̲N̲o̲d̲a̲l̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲y̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The Nodal Supervisory Software covers modifications
of the following items:
1. Supervisor Terminal Functions (STF) which provides
the interactive terminal support for a nodal supervisor,
i.e. for the functions of control and monitoring
the nodal environment.
2. Supervisory Automatic Functions (SAF) which provides
the services of automatic reaction to events and
downline loaded control from the system control
center including the event based and periodic reporting
locally on the node and to the system control center.
The following modifications are needed as summarized
below:
Estimated
M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ E̲f̲f̲o̲r̲t̲ ̲(̲m̲/̲m̲)̲
a. SAF modification for dynamic reroute in
case of satellite concentrator line switch 3
b. Service Message Handling (SAF update) 3
c. Supervisor interface procedures update
including the handling of subscriber
profiles (STF update) 3
d. Traffic Supervisor. SAF update, i.e.
update with respect to changed node
attachments. 3
e. Adaption to new reports (existing software
covers raw data collection, but not
presentation)
̲ ̲2̲ ̲ ̲ ̲
Total update effort
14 mm
3.7.4 Modifications to Message Distribution
a̲n̲d̲ ̲O̲u̲t̲p̲u̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
This section deals with the modifications to the following
modules:
1. The Message Distribution Subsystem (MDS) which
routes the messages according to resolved addresses.
2. The Printer Interface Process (PIP) which provides
the output service.
The following modifications are needed as summarized
below:
Estimated
M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ E̲f̲f̲o̲r̲t̲ ̲(̲m̲/̲m̲)̲
a. No formatting of an output (PIP update) 1
b. Reflect encoding of output characters
(PIP update) 1
c. Dynamic rerouting on satellite concentrator
line switch (MDS modification) 2
d. Address distribution and other distribution
criterias (no of copies etc.) to be reflected
in PIP and MDS 1
e. Preemption and sequence numbering scheme to
be adapted on PIP 2
f. Traffic summary statistics for MDS + PIP
̲ ̲1̲ ̲ ̲ ̲
Total update effort
8 mm
3.7.5 M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲t̲o̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
This section deals with the modifications to the following
Modules:
1. The Storage Module (SRS) which provides the services
of storage and catalogueing on long
term storage.
2. The Retrieval Module (SRR) which provides the services
of retrieval from long term storage
according to the following keys:
- Message identification
- Date time group
- Subject indicator code
The modifications needed are summarized below:
Estimated
M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ E̲f̲f̲o̲r̲t̲ ̲(̲m̲/̲m̲)̲
a. Change in format (and content) of
retrieval keys (SRS + SRR) 4
b. Support for multiple storage volumes,
i.e. tapes or discs. Note that mirrored Not
quoted
disc handling is covered by the software ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Total update effort
4 m/m
3.7.6 Modifications to Message Journal
a̲n̲d̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
This section deals with the modifications to the following
Modules:
1. The Journal Software (JOUR) providing the services
of journalization of significant message events,
e.g.: release for distribution, enqueued for output,
output completed etc.
2. The Network Statistics Module (NES) which provides
the services of
- storing raw statistical date
- generating statistical reports.
The modifications needed are summarized below:
Estimated
M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ E̲f̲f̲o̲r̲t̲ ̲(̲m̲/̲m̲)̲
a. New types of raw data to be stored
(NES and JOUR) 3
b. New types of reports to generated (NES)
̲ ̲5̲ ̲ ̲ ̲ ̲ ̲
Total update effort
8 m/m
3.7.7 M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲t̲o̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
This section deals with the modifications to the following
modules:
1. The Message Conversion Modules (MAS/MSA). These
modules provide the services of analysing incoming
messages, resolve addresses priority indicator,
classification, date time group etc., and convert
the pieces of information to binary pieces of information.
Furthermore above information is correctly synthesized
upon output in case of incorrect input format.
2. The Message Intercept Module (INT). This module
provides the interactive supervisor support for
repairing faulty messages.
The modifications needed are summarized below:
Estimated
M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ E̲f̲f̲o̲r̲t̲ ̲(̲m̲/̲m̲)̲
a. Syntax checking, address decoding
(MAS/MSA modules) 4
b. Recognition and analysis of service
messages (MAS/MSA modules) 6
c. Changes to the supervisor procedures for
editing faulty messages and giving this
capability also to normal users
̲ ̲2̲ ̲ ̲ ̲ ̲
Total update effort
12 m/m
3.7.8 M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲t̲o̲ ̲S̲y̲s̲t̲e̲m̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲C̲e̲n̲t̲e̲r̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
This section deals with the modifications to the following
modules:
1. The Network Supervisory and Control Module (NSC),
providing the services of automatic and interactive
control and monitoring of the network.
The modifications needed are summarized below:
Estimated
M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ E̲f̲f̲o̲r̲t̲ ̲(̲m̲/̲m̲)̲
a. Handling of Service Messages 5
b. Dynamic rerouting in case of concentrator
line switch 5
c. Network wide configuration support 8
- Topology reconfiguration
- Subscriber profiles
d. Network Status accountability due to
change in network topology ̲
̲ ̲6̲ ̲ ̲ ̲ ̲
Total update effort
24 m/m
3.7.9 M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲t̲o̲ ̲t̲h̲e̲ ̲N̲o̲d̲a̲l̲ ̲S̲w̲i̲t̲c̲h̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
This section deals with the modifications to the following
modules:
1. The Nodal Switch Subsystem (NSS), which provides
the services of network message switching.
The modifications needed are summarized below:
Estimated
M̲o̲d̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ E̲f̲f̲o̲r̲t̲ ̲(̲m̲/̲m̲)̲
a. Change in no. of nodes, network topology
and addressing room
̲ ̲2̲ ̲ ̲ ̲ ̲
Total update effort
2 m/m
3.7.10 C̲o̲n̲c̲e̲n̲t̲r̲a̲t̲o̲r̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
This is a new item which covers the services of handling
the messages exchanged via concentrator interface.
The quote given in table 3.7.1-1 for this subsystem
assumes the standard X.25 package can be used without
modifications.
3.7.11 E̲n̲d̲-̲t̲o̲-̲E̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲M̲o̲n̲i̲t̲o̲r̲
This is a new item which covers the services of end-to-end
control for the message traffic.
The quote given in table 3.7.1-1 is under the assumption
that a standard transport station can be modified for
this purpose. The services to be provided will include
handling of service messages and support for traffic
summaries and traffic reports.
