top - download
⟦9eaf41f43⟧ Wang Wps File
Length: 32404 (0x7e94)
Types: Wang Wps File
Notes: CPS/SDS/001
Names: »0478A «
Derivation
└─⟦6f17b967f⟧ Bits:30006000 8" Wang WCS floppy, CR 0035A
└─ ⟦this⟧ »0478A «
WangText
…00……00……00……00……00…&…02……00……00…&
%…0c…%…02…% %…05…%…06……0f……0d……86…1 …02… …02… …02…
…02…CPS/SDS/001
…02…810115…02……02…#
CAMPS SYSTEM DESIGN SPECIFICATION
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
4.2 FUNCTIONAL FLOW ..........................
4.2.1 Introduction .........................
4.2.2 Package Inter-Relationship ...........
4.2.2.1 Basic Relationship ...............
4.2.2.2 Processes and Transactions .......
4.2.3 Message Transactions .................
4.2.3.1 Incoming ACP127 Message ..........
4.2.3.2 Outgoing ACP127 Message -
Originated by CAMPS ..............
4.2.3.3 Outgoing ACP127 Message -
Prepared Externally ..............
4.2.3.4 Comments .........................
4.2.3.5 VDU Pages ........................
4.2.4 Functional Flow for an In-Message ....
4.2.4.1 Reception Process (IOC and THP) ..
4.2.4.2 Analysis Process (THP) ...........
4.2.4.3 Use of Tables in Analysis ........
4.2.4.4 Reasons for Rejection ............
4.2.4.5 Completion of Analysis ...........
4.2.4.6 Special Actions for All Messages .
4.2.4.7 Message Types ....................
4.2.4.8 Message Service Assistance (TEP) .
4.2.4.9 Other Incoming Information .......
4.2.4.10 Distribution and Delivery (MDP) ..
4.2.4.11 Relationship Between Analysis,
Distribution, and MDCO ...........
4.2.4.12 MDCO Actions .....................
4.2.4.13 Final Situation ..................
4.2.5 Functional Flow for an Out-Message ...
4.2.5.1 Introduction .....................
4.2.5.2 Message Preparation ..............
4.2.5.3 Co-ordination ....................
4.2.5.4 Release ..........................
4.2.5.5 ACP127 Synthesis .................
4.2.5.6 Route Assignment .................
4.2.5.7 Output ...........................
4.2.5.8 Distribution .....................
4.2.6 Views of a Message ...................
4.2 F̲U̲N̲C̲T̲I̲O̲N̲A̲L̲ ̲F̲L̲O̲W̲
4.2.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
This section describes in out-line how the software
configuration listed in section 4.1 fits together to
perform the CAMPS functions. The functional flow is
not specifically described in terms of the hardware
components since in most cases this can easily be deduced
from section 4.1 and would entail unnecessary repetition.
The functional flow is illustrated by examples of the
processing of incoming and outgoing messages. Further
illustrations of message flow are in system recovery
(section 4.7, figures 4.7.5.1 and 4.7.7.1).
4.2.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲-̲R̲e̲l̲a̲t̲i̲o̲n̲s̲h̲i̲p̲
4.2.2.1 B̲a̲s̲i̲c̲ ̲R̲e̲l̲a̲t̲i̲o̲n̲s̲h̲i̲p̲
To perform the CAMPS application functions, information
and control passes between the components of the system
identified in section 4.1. A view of all the software
package inter-relationships is given in figure 4.2.2-1
which shows the systems software and applications software
packages (see section 5 for full details). Figure 4.2.2-1
shows the hardware responsibilities of the System Software
sub-system. In summary:
a) All data and file accessing is controlled by the
CSF, SFM, and TMP packages.
b) All channels are accessed via THP/IOC packages.
c) All user terminals (VDUs and associated printers),
functions and special devices (OCR, PTR, PTP) are
controlled by the TEP/IOC packages, except for
user sign-on.
d) Security is controlled by the SSC package in conjunction
with KER, CSF, and SFM (see section 4.9).
e) Recovery is anticipated by checkpoints passed to
CSF which are placed on disc and/or passed to the
stand by processor. Actual recovery is performed
by SSC in association with each package (see section
4.7).
Figure 4.2.2-1
Figure 4.2.2-2
4.2.2.2 P̲r̲o̲c̲e̲s̲s̲e̲s̲ ̲a̲n̲d̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲s̲
Each software package will be implemented as a number
of software or firmware modules. In the CR80 DAMOS
environment, the software modules will operate, singly
or combined with other modules as processes. To perform
a CAMPS transaction, will generally require the use
and cooperation of a number of processes.
a) T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲
A transaction is initiated by a discrete event.
For example input of a command, function key or
a format; timer event (such as the non-arrival
of a FLASH acknowledgement or periodic output of
statistics); completion of an input from an external
device or channel (such as receipt of end of message
function on a low-speed telegraph line). Most transaction
can be categorized by the method of initiation
though a few can be initiated in more that one
way (for example, the processing of an in-message
can be re-started by MSO after correction; distribution
of a comment can be caused by CCIS/SCARS).
b) P̲r̲o̲c̲e̲s̲s̲
A process can be viewed in three ways which are
important for an understanding of how the system
will sucessfully perform all of its functions:
1) T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲
A process may be part of a number of transactions,
and will interface with other processes on
behalf of these transactions. A theoretical
example is given in figure 4.2.2-3, and practical
examples are in sections 4.2.3 an 4.2.4. Certain
processes run independently of transactions
and are kept in action by a polling or interrupt
mechanism (for example, the processes receiving
blocks and characters from devices and channels).
2) S̲y̲s̲t̲e̲m̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
A process operates in an environment that has
been specifically designed to suit the CAMPS
requirements. It may actually be part of this
environment. Figure 4.2.2-4 shows the facilities
available to a generalized process (see section
4.5 and 4.6 for detailed information).
3) D̲e̲s̲i̲g̲n̲ ̲a̲n̲d̲ ̲P̲e̲r̲f̲o̲r̲m̲a̲n̲c̲e̲
There is often a choice as to whether a function
is implemented as one or more processes. For
example, incoming channels can be serviced
by one composite process or by a separate process
for each channel. In the latter case, the separate
process would be functionally equivalent and
would use the same modules. The choice would
mainly be decided on design convenience. The
number of instances of a transaction that can
simultaneously be processed will be governed
by the number of instances permitted of the
processes which it uses. The choice would be
dictated by resource and performance considerations.
The detailed design will show:
The diversion of packages into processes
The mapping of transaction onto processes
The mapping of modules onto processes
Interfaces between processes
Interfaces between modules
Figure 4.2.2-3
Figure 4.2.2-4
4.2.3 M̲e̲s̲s̲a̲g̲e̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲s̲
CAMPS has to process various types of message and comment,
received or generated.
4.2.3.1 I̲n̲c̲o̲m̲i̲n̲g̲ ̲A̲C̲P̲1̲2̲7̲ ̲M̲e̲s̲s̲a̲g̲e̲
An incoming message requires analysis to decide its
type and attributes (all of which affect the way in
which it is subsequently handled), to derive its classification
and precedence to determine its distribution to CAMPS
users, and to extract and validate retrieval parameters.
The message is filed. See 4.2.4 for the detailed flow
of an in-message.
4.2.3.2 O̲u̲t̲go̲i̲n̲g̲ ̲A̲C̲P̲1̲2̲7̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲-̲ ̲O̲r̲i̲g̲i̲n̲a̲t̲e̲d̲ ̲b̲y̲ ̲C̲A̲M̲P̲S̲
This message originates at a user terminal or is automatically
generated or is derived directly from an incoming message.
CAMPS synthesizes an ACP127 envelope for the message
(if required), determines the routing of the message
into the telegraph networks and transmits the message.
Some types of messages are distributed locally on the
basis of information supplied with the message when
created. The message is filed. See 4.2.5 for the detailed
flow of an out-message.
4.2.3.3 O̲u̲t̲g̲o̲i̲n̲g̲ ̲A̲C̲P̲1̲2̲7̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲-̲ ̲P̲r̲e̲p̲a̲r̲e̲d̲ ̲E̲x̲t̲e̲r̲n̲a̲l̲l̲y̲
This message is received by CAMPS from CCIS, or SCARS
and may require coordination or release or it may already
have been released. In all cases it requires initial
checking to ensure that it is acceptable to CAMPS and
thereafter its processing is according to its status.
4.2.3.4 C̲o̲m̲m̲e̲n̲t̲s̲
A comment can originate at a CAMPS terminal or be received
from CCIS or SCARS. It requires distribution and filing.
Messages for coordination are distributed in the same
way as comments.
4.2.3.5 V̲D̲U̲ ̲P̲a̲g̲e̲s̲
CAMPS can receive items of information that are to
be filed in a reserved entry in a CAMPS table according
to an identifier that accompanies the information.
A user can select the information, which corresponds
to a page of data for a VDU Screen, by use of a commnad
and quoting the appropriate identifier.
4.2.4 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲F̲l̲o̲w̲ ̲f̲o̲r̲ ̲a̲n̲ ̲I̲n̲-̲M̲e̲s̲s̲a̲g̲e̲
This section describes how CAMPS processes information
received from external channels and devices by using
ACP127 messages as an example, see figure 4.2.4-1.
The system also receives other information which is
eventually to be processed as an out-message (released
message, message for release, message for coordination),
or a comment, or VDU page. Figure 4.2.4-4 summarises
these types of information according to source.
4.2.4.1 R̲e̲c̲e̲p̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲s̲s̲ ̲(̲I̲O̲C̲ ̲a̲n̲d̲ ̲T̲H̲P̲)̲
a) At any time CAMPS can expect to be receiving messages
over all telegraph channels that are open and information
over other types of channel. The messages will
be received as a stream of blocks from the NICS
TARE channels and a stream of characters from the
low-speed telegraph channels (which if received
in ITA2 code will be converted to ITA5). The reception
process handles the spooling of these streams and
turns them into discrete messages, and files each
message in its "as-received form" with an attached
message control block (MCB). This process will
detect certain channel and message error conditions
(such as incorrect CSN, "Stuck character" conditions,
EDC error reports) and will also prematurely terminate
a message if necessary (for example, if the message
is too long or no characters are received of longer
than a given period). Details of these actions
will be placed in the MCB.
Fig 4.2.4-1
b) Because it is necessary to detect the SOTF of ACP127
format line 1 of a message, the reception process
may compare and update the CSN of the appropriate
channel table, and may also insert the RI of the
message as a retrieval parameter via SAR.
c) Channel error conditions are reported to the supervisor
and logged (if necessary)
d) The filing of the complete message and its MCB
provides a checkpoint for recovery, and so the
data will also be transferred to the stand by processor
unit (if available).
e) It is probable that there will be a process-type
for each type of channel and device. Each open
channel will be handled by its own process of a
suitable type. Thus the reception process will
take account of the differing protocol and error
reporting requirements of CCIS/SCARS.
4.2.4.2 A̲n̲a̲l̲y̲s̲i̲s̲ ̲P̲r̲o̲c̲e̲s̲s̲ ̲(̲T̲H̲P̲)̲
This process examines complete messages assembled by
the reception process. (The analysis of information
from non-telegraph lines is described in 4.2.4.9).
The purpose of this process is to:
a) Determine the type of message (see below), because
this will affect the way in which the message is
subsequently handled.
b) Derive the precedence and security and special
handling classifications.
c) Check that the message is actually addressed (by
RI and, if appropriate, PLA) to the CAMPS site.
d) Identify the local CAMPS addressees.
e) Identify distribution parameters (SICs, exercise
indicator).
f) Detect any special communications instruction (relay
requirements, Z-codes, artificial termination).
g) Validate retrieval parameters (DTG, Originator,
SICs).
4.2.4.3 U̲s̲e̲ ̲o̲f̲ ̲T̲a̲b̲l̲e̲s̲ ̲i̲n̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
In order to perform the analysis of the ACP127 header
of an in-message use will be made of the following
tables:
a) L̲o̲c̲a̲l̲ ̲R̲o̲u̲t̲i̲n̲g̲ ̲I̲n̲d̲i̲c̲a̲t̲o̲r̲s̲
This will indicate which RIs may legitimately be
present in format line 2 of an in-message, so enabling
mis-sent messages to be detected, it will also
assist in the detection of possibly mis-spelled
local PLAs in lines 7 and 8 and in detecting possible
mis-routed messages. Certain suffixes may be attached
to routing indicators to indicate staff in the
COMMCEN such as the crypto positon, the supervisor,
the message correction position etc. (See ACP117).
One way of allowing for these may be by entries
in this table. The table is also used to check
format line 4 for relay instructions that imply
action by a CAMPS site.
b) P̲L̲A̲
The PLA table is used
- to identify addressees local to the CAMPS site
- to validate the originator as a retrieval parameter
(if required)
- to identify exempt local addressees (transmit
line, format line 9)
1) For efficiency in access, local addressees
could be held as a separate, small table depending
on overall use of the PLA table and method
of access used.
2) For analysis purposes the PLAs will be accessed
using the alphanumeric PLA identifier. To avoid
missing a local PLA and to keep rejection rates
down, the matching of PLAs to table keys should
be without any spaces. For example, CDC SONOR
would be treated as CDCSONOR.
c) A̲I̲G̲
The AIG table is used to detect AIGs that contain
addressees local to the CAMPS site (the AIG lists
could be arranged to permit this to be done efficiently).
Such addressees must be qualified by any local
addressees listed in format line 9 (XMT).
d) S̲I̲C̲
Analysis will need to locate the SIC line. The
validation of this line theoretically could be
left to be done by the distribution package (MDP).
However, for convenience in keeping all garble
correction at the message service terminal, it
is assumed that analysis will also need to validate
the SIC line and so will access the SIC table.
e) P̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
Analysis will need to access parameters to recognize
certain operating signals (Z-codes) and translate
them into plain language (to be appended to the
message, if required) and/or to indicate special
action to be taken.
4.2.4.4 R̲e̲a̲s̲o̲n̲s̲ ̲f̲o̲r̲ ̲R̲e̲j̲e̲c̲t̲i̲o̲n̲
a) As a result of the analysis, conditions will be
detected that require inspection or connection
at a message service position in the COMMCEN by
a supervisor assistant. These conditions will be
of 3 types:
1) Those relating to the message in general. For
example, channel errors, many oversize lines,
oversize message, premature and artificial
termination. These might not require correction,
but should be presented to the
COMMCEN so that an explanation could be added
to the message when it is distributed or additional
actions may be carried-out (for example, ending
a service message asking for a repeat).
2) Those relating to specific errors in lines.
For example unknown special handling designator,
invalid DTG, non-local RI in ACP127 format
line 2.
3) Those relating to lines missing from the ACP127
format which prevent proper analysis of the
header. For example, missing ACP127 format
line 5.
b) Details of the conditions found by analysis that
require the message to be presented for service
assistance will be stored in the MCB for use when
the message is presented and for possible statistical
uses.
c) For convenience in presentation of this information
and to avoid run-away error conditions, rules will
be stated during detailed design to define the
conditions under which analysis will be abandoned
for a given line (physical or logical) and for
the message as a whole. For example: 1 error per
line; 10 errors for the message.
4.2.4.5 C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲ ̲o̲f̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
If analysis completes successfully, then the MCB is
updated with further information such as message type,
classification, precedence, special handling, and data
to be used by the distribution package. The message
is converted to an internal form used by the rest of
the system. Most messages are now passed on to the
distribution function, but special actions are needed
in certain cases and the full situation is now described
with reference to figure 4.2.4-2.
4.2.4.6 S̲p̲e̲c̲i̲a̲l̲ ̲A̲c̲t̲i̲o̲n̲s̲ ̲f̲o̲r̲ ̲A̲l̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Certain conditions can occur with any message and these
trigger actions that are additional to the normal processing
of a message. For example:
a) F̲l̲a̲s̲h̲ ̲P̲r̲e̲c̲e̲d̲e̲n̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲c̲e̲i̲v̲e̲d̲
In certain cases the system is required automatically
to generate an acknowledgement and to send it to
the appropriate station. This action should only
take place after any corrections have been made.
b) A̲u̲t̲o̲m̲a̲t̲i̲c̲ ̲R̲e̲l̲a̲y̲
If, according to ACP127 format line 4, a CAMPS
system is also automatically to relay a message,
then in addition to any other processing, output
will be made in appropriate format to the required
destination.
c) R̲e̲-̲R̲o̲u̲t̲e̲
A message may be received that has been mis-sent
and/or mis-routed (it may, in addition, be correctly
addressed to the CAMPS site). These conditions
are detectable by analysis and the message service
operator will have been notified to take required
action.
Figure 4.2.4-2
4.2.4.7 M̲e̲s̲s̲a̲g̲e̲ ̲T̲y̲p̲e̲s̲
The further normal processing of a message depends
on its type.
a) P̲l̲a̲i̲n̲d̲r̲e̲s̲s̲ ̲(̲N̲o̲r̲m̲a̲l̲)̲
This is passed on to the distribution process,
and retrieval parameters are also passed to SAR.
b) P̲l̲a̲i̲n̲d̲r̲e̲s̲s̲ ̲(̲D̲a̲t̲a̲)̲
This is passed to the distribution process but
special actions are needed to handle the potentially
non-displayable and non-printable text of the message.
c) C̲o̲d̲r̲e̲s̲s̲ ̲M̲e̲s̲s̲a̲g̲e̲
This is to be queued and output at a specified
device (indicated by system parameters). Detailed
design will decide whether the analysis function
will do this directly (or via the distribution
function). This type includes messages with encrypted
texts but non-encrypted addressees. The handling
of a Codress message after it has been decrypted
is TBD.
d) S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲(̲A̲b̲b̲r̲e̲v̲i̲a̲t̲e̲d̲ ̲o̲r̲ ̲F̲u̲l̲l̲)̲
Except for the special cases below, this is queued
and output at a specified device (indicated by
system parameters). The distinction between abbreviated
and full is made during analysis to ensure correct
handling of abbreviated messages. Its only significance
subsequently is in producing the appropriate output
from of a message.
e) C̲h̲a̲n̲n̲e̲l̲-̲C̲h̲e̲c̲k̲
Channel-check messages sub-divide into three types:
1) S̲e̲l̲f̲-̲a̲d̲d̲r̲e̲s̲s̲e̲d̲/̲s̲e̲l̲f̲-̲o̲r̲i̲g̲i̲n̲a̲t̲e̲d̲
This is a self-addressed message that was originated
by this system and has been returned by a directly-connected
receiving station. The appropriate channel
data for the pair of channels involved is updated
to show correct receipt of the channel check.
2) S̲e̲l̲f̲-̲a̲d̲d̲r̲e̲s̲s̲e̲d̲/̲n̲o̲n̲-̲s̲e̲l̲f̲-̲o̲r̲i̲g̲i̲n̲a̲t̲e̲d̲
This is a channel-check originated by another
station and is addressed to itself. If CAMPS
is to handle this type of message, it will
need to re-transmit the message over the outgoing
channel related to the incoming channel over
which the message was received. The channel
data is updated as required.
3) N̲o̲n̲-̲s̲e̲l̲f̲-̲a̲d̲d̲r̲e̲s̲s̲e̲d̲ ̲(̲C̲o̲n̲t̲i̲n̲u̲i̲t̲y̲)̲
This is a simple channel check. The channel
data is updated as required.
There is no further processing of a channel check
except for statistics, logging, and eventual deletion
of the message from on-line storage.
f) A̲c̲c̲o̲u̲n̲t̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲
This is a service-message received around midnight
and is usually associated with the resetting of
channel sequence numbers. The appropriate channel
data is updated, a report and log produced as required,
and the processing of the message is terminated.
g) F̲l̲a̲s̲h̲ ̲A̲c̲k̲n̲o̲w̲l̲e̲d̲g̲e̲m̲e̲n̲t̲
This is a service-message received for acknowledge
receipt by another station of a flash precedence
message transmitted by CAMPS. Provided this service
message conform to an agreed format, CAMPS will
attempt to check the transmission to which it refers
against a list of transmission awaiting acknowledgement.
If no match is found, the service message together
with a report is queued for an appropriate position
in the COMMCEN.
4.2.4.8 M̲e̲s̲s̲a̲g̲e̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲A̲s̲s̲i̲s̲t̲a̲n̲c̲e̲ ̲(̲T̲E̲P̲)̲
The resources for presenting an incoming message to
a Service operator are given in para 4.2.4.4
a) F̲i̲r̲s̲t̲ ̲T̲i̲m̲e̲ ̲P̲r̲e̲s̲e̲n̲t̲a̲t̲i̲o̲n̲
If a message is to be presented to a service position,
the MCB will contain the reasons as well as indicating
which lines, if any, are involved. The analysis
function then places a reference to the message
in the appropriate queue of the terminal handler.
When the message is eventually presented at a service
terminal, the function performing this task will
format and present the message in its as-received
form with its captions (general errors) as well
as the line-specific errors. A distinction needs
to be made between rejection reasons that are presented
for information and those that must be corrected
before the message can be properly processed by
the system (see 4.2.5.3.2.3a 1). Either the system
must recognize that the first category only needs
to be presented once or the service positions require
a command to acknowledge the presence of such conditions.
b) C̲o̲r̲r̲e̲c̲t̲i̲o̲n̲
The operator edits the message to correct it, and
submits it for re-analysis. The terminal handler
passes the message back to the analysis function
of the terminal handler. If the message still contains
errors it is now returned as a response to the
same terminal, otherwise an OK response is sent.
c) G̲a̲r̲b̲l̲e̲ ̲S̲t̲o̲p̲
It is assumed that there will be cases where the
message correction operator will want to stop any
further processing of a message (for example, complete
garble, or not text). For this purpose, a "stop"
command is used, the MCB of the message is updated
and, ideally, a report produced for the supervisor.
d) L̲o̲c̲a̲l̲ ̲P̲r̲i̲n̲t̲
A message service operator may obtain a hard-copy
print of a message at the associated medium speed
printer. It is assumed that this action is independent
of any correction action.
e) C̲a̲n̲c̲e̲l̲
If the message is cancelled either directly by
the operator or because of a terminal failure etc.,
the message is returned to its position in the
queue. It may now be presented at any of the service
positions and will be shown in its originally-queued
form as a first-time presentation.
4.2.4.9 O̲t̲h̲e̲r̲ ̲I̲n̲c̲o̲m̲i̲n̲g̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
Besides ACP127 messages received from telegraph lines,
CAMPS will also receive information from non-telegraph
sources. These are CCIS and SCARS. Figure 4.2.4-4 shows
the various types of information and their sources
(as currently decided).
a) These types of information are received from a
variety of channels and devices. Their handlers
pass the information to THP where they are analyzed
according to the source. Each Source will supply
information in a different format, though SCARS
and CCIS share a common format.
b) The complexity of the analysis will depend on both
the source and the type of information.
c) The purpose of analysis is to determine the classification,
precedence, retrieval parameters etc. and to check
that all required information is present. This
analysis is in place of the checking that would
have occurred had the message or comment been prepared
at a CAMPS interactive terminal.
d) Problems associated with these items are handled
by queuing the item concerned (message or comment)
for attention and correction by the Message Service
Operators (MSO) in a similar way to ACP127 messages
received via telegraph channels.
e) Messages for coordination, messages for release,
and comments are now handled as for their locally-generated
equivalents (see below). VDU pages are eventually
passed to TMP package for filing. Released messages
are transferred within THP to be processed as an
outgoing message.
N̲O̲N̲-̲T̲E̲L̲E̲G̲R̲A̲P̲H̲ ̲S̲O̲U̲R̲C̲E̲S̲ ̲O̲F̲ ̲I̲N̲F̲O̲R̲M̲A̲T̲I̲O̲N̲
INFORMATION OUT-MESSAGES
TYPE
ROUTED RELEASED FOR FOR COMMENT VDU
PAGE
RELEASE CO-ORDI-
NATION
SOURCE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
CCIS X X X
X
X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SCARS X
X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
NOTE: 1) A routed message (for example, off-line
encrypted) requires the routing indicators
in ACP127 format line 2 to be analyzed
to obtain the required outgoing circuits.
The precedence and classification also
need to be deduced. Internal distribution
TBD.
2) A released message, after analysis, is
handled as for a message released at a
CAMPS VDU.
3) Message for release implies possible "refuse"
and "defer" responses.
4) Message for coordination implies comments
as responses. CAMPS does not update messages
for coordination received from CCIS. The
storage requirement is TBD.
Figure 4.2.4-4
4.2.4.10 D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲D̲e̲l̲i̲v̲e̲r̲y̲ ̲(̲M̲D̲P̲)̲
a) Messages that have satisfactorily passed the analysis
function and that require distribution are queued
(by reference) for the MDP package. This package
has four main functions:
1) To determine and create the distribution list
for an in-message
2) To form the distribution lists for other messages
and comments
3) To interface (via TEP) to the MDCO for the
handling of distribution problems and presenting
messages for inspection (as specified by system
parameters).
4) To deliver the message (via TEP) to appropriate
terminals.
4.2.4.11 R̲e̲l̲a̲t̲i̲o̲n̲s̲h̲i̲p̲ ̲B̲e̲t̲w̲e̲e̲n̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲,̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲,̲ ̲a̲n̲d̲ ̲M̲D̲C̲O̲
The functional relationship between Distribution, Analysis,
and the MDCO is shown in figure 4.2.4-5 in respect
of incoming messages.
a) The distribution function is supplied with queue
elements referring to messages supplied by analysis
or message returned for distribution by a process
serving an MDCO terminal. It is intended that this
queue be checkpointed to permit system recovery
to this stage of the processing of an in-message.
b) Use of the queue element content and MCB enables
the process to distinguish the different types
of queued element and the message type. Messages
returned from the MDCO can be delivered to the
appropriate device and terminal queues. Messages
received from the analysis process are dealt with
according to type:
1) P̲l̲a̲i̲n̲d̲r̲e̲s̲s̲ ̲(̲N̲o̲r̲m̲a̲l̲)̲ ̲M̲e̲s̲s̲a̲g̲e̲
The distribution is derived from the local
addresees and SICs of the message as qualified
by special and exercise SICs. This information
is readily obtained via the MCB. The SDLs that
are selected as a result are used to derive
a list of SCDs, which presumably should be
adjusted to remove duplicates. This distribution
list is stored in the MCB. A normal message
is either queued for the MDCO (because of problems
or because of supervisor rules) or is queued
for all the devices/ terminals selected according
to its derived distribution list.
2) C̲o̲d̲r̲e̲s̲s̲ ̲M̲e̲s̲s̲a̲g̲e̲
Codress messages are delivered to the appropriate
device queue as designated by the system parameters.
3) D̲a̲t̲a̲ ̲M̲e̲s̲s̲a̲g̲e̲
The text of a Data Message is in principle
neither completely displayable nor printable.
The exact handling of such messages is TBD.
For the moment it is assumed that such a message
will be queued for the MDCO (and presented
without text). Possible distribution destinations
for such a message could be SCARS/CCIS/PTP.
c) The queue for the MDCO will contain, in addition,
elements for each message/queue combination rejected
because of classification mis-match or terminal/user
status not suitable. This rejection may occur upon
queuing for a device or subsequently if the status
changes before the message is output or for a FLASH
time-out. In these cases the information that indicates
which terminal SCD is involved is stored in the
queue element rather than the MCB.
Figure 4.2.4-5
4.2.4.12 M̲D̲C̲O̲ ̲A̲c̲t̲i̲o̲n̲s̲
The TEP process (or processes) handling the queue of
elements for MDCO positions, present the corresponding
messages and expect responses according to the reason
for queuing.
a) Messages presented because of problems in defining
a distribution list or because of mandatory selection
are presented in a suitable format together with
a full, partial, or no distribution list (depending
on the circumstances). An indication of the reasons
for presentation and any errors is also shown.
The operator at the MDCO may optionally modify
the distribution list which the process checks
and, if acceptable, returns the message to the
incoming queue for the distribution process. (It
is assumed that mandatory selection does not apply
to service and codress messages nor to messages
already presented because of problems).
b) Only the header of a data message can be shown
and the operator is expected to supply the appropriate
designators (SCD or other) to cause the message
to be output to suitable destinations. This message
is then returned to the distribution process.
c) Messages rejected because of delivery problems
are presented in the appropriate delivery format,
with distribution list, and with the specific recipient
identified that is the cause of the rejection together
with an indication of the reason for rejection
(for example, security, special handling, terminal
status, flash precedence time-out). Because this
information relates only to 1 delivery of a message,
the information is expected to be held in the queue
element rather than the MCB. The operator has various
options to print the message, select alternative
recipient etc. Certain changes may require the
distribution list associated with the message to
be adjusted.
4.2.4.13 F̲i̲n̲a̲l̲ ̲S̲i̲t̲u̲a̲t̲i̲o̲n̲
As a result of the processing described in this section
the following effects will also have been achieved:
a) S̲t̲o̲r̲a̲g̲e̲
An incoming message stored in short-term storage
in the CAMPS internal format together with the
MCB. Eventually when the message no longer has
any current users it will be moved to intermediate
storage or deleted (if it meets certain security
criteria).
b) R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
Appropriate retrieval parameters are derived and
stored.
c) S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
Statistics information is made available by updates
to tables (for example, channel tables) by updating
specific counts, and form the MCB. The exact method
of producing statistics will be defined during
detailed system design.
