top - download
⟦5983d8d37⟧ Wang Wps File
Length: 57036 (0xdecc)
Types: Wang Wps File
Notes: CPS/SDS/001
Names: »1354A «
Derivation
└─⟦e53c2fc59⟧ Bits:30006055 8" Wang WCS floppy, CR 0087A
└─ ⟦this⟧ »1354A «
WangText
7…0e…7 7…06…7…07…6…08…6…0f…6 6…05…6…06…5…0d…5…05…5…06…4…0d…4
3…09…3…00…3…86…1
…02…
…02… …02…
…02…CPS/SDS/001
…02…811020…02……02…
CAMPS
SYSTEM
DESIGN
SPECIFICATION
…02…ISSUE
1.1…02…CAMPS
4.2 FUNCTIONAL FLOW ..........................
107
4.2.1 Introduction .........................
107
4.2.2 Package Inter-Relationship ...........
107
4.2.2.1 Basic Relationship ...............
107
4.2.2.2 Processes and Transactions .......
111
4.2.3 Message Transactions .................
114
4.2.3.1 Incoming ACP127 Message ..........
114
4.2.3.2 Outgoing ACP127 Message -
Originated by CAMPS ..............
114
4.2.3.3 Outgoing ACP127 Message -
Prepared Externally ..............
114
4.2.3.4 Comments .........................
114
4.2.3.5 VDU Pages ........................
115
4.2.4 Functional Flow for an In-Message ....
115
4.2.4.1 Reception Process (IOC and THP) ..
115
4.2.4.2 Analysis Process (THP) ...........
117
4.2.4.3 Use of Tables in Analysis ........
118
4.2.4.4 Reasons for Rejection ............
119
4.2.4.5 Completion of Analysis ...........
120
4.2.4.6 Special Actions for All Messages .
120
4.2.4.7 Message Types ....................
123
4.2.4.8 Message Service Assistance (TEP) .
124
4.2.4.9 Other Incoming Information .......
126
4.2.4.10 Distribution (MDP) ...............
129
4.2.4.11 Relationship Between Analysis,
Distribution, and MDCO ...........
129
4.2.4.12 MDCO Actions .....................
132
4.2.4.13 Final Situation ..................
132
4.2.5 Functional Flow for an Out-Message ...
133
4.2.5.1 Introduction .....................
133
4.2.5.2 Message Preparation/Input ........
138
4.2.5.3 Co-ordination (TEP, MDP) .........
141
4.2.5.4 Release (TEP) ....................
142
4.2.5.5 ACP127 Synthesis (THP) ...........
142
4.2.5.6 Route Assignment .................
148
4.2.5.7 Output ...........................
149
4.2.5.8 Distribution .....................
151
4.2.5.9 Final Situation ..................
151
4.2.6 Views of a Message ...................
151
4.2.6.1 In-Message .......................
151
4.2.6.2 Out-Message ......................
153
4.2.6.3 Re-transmitted Message ...........
154
4.2.6.4 Service and Encrypted Messages ...
154
4.2.6.5 Channel Checks ...................
154
4.2.6.6 Automatically Generated Service
Messages .........................
154
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-2
shows the hardware responsibilities of the System Software
sub-system. In summary:
a) All data and file accessing is controlled by the
CSF, SFM, SAR, 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, except for user sign-on,
sign-off and security interrogation.
d) Security is controlled by the SSC package in conjunction
with 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 or a function key;
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 than 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 successfully 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 and 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 division 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 and security
parameters. The message is filed and locally distributed.
See 4.2.4 for the detailed flow of an in-message.
4.2.3.2 O̲u̲t̲g̲o̲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 and locally distributed.
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 (CCIS only)
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.
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 command
and quoting the appropriate identifier. A user can
also prepare a VDU-page.
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 for longer
than a given period).
Fig 4.2.4-1
b) It is necessary to detect the SOTF of ACP127 format
line 1 of a message so that the reception process
will compare the CSN of the appropriate channel
table and; if incremented by one number, update
the table. If incremented by more than one number
or not incremented or reverting in numerical sequence,
the table should be updated, a service message
automatically transmitted and the supervisor notified.
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, 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 (transmission
instructions, Z operating signals, erroneous and
premature 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 unknown local PLAs in
lines 7 and 8 and in detecting possible mis-routed
messages. 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 (xmt 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. 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 is left to be done by the
distribution package (MDP).
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 correction
at a message service position in the COMMCEN by
a supervisor assistant. These conditions will be
of 4 types:
1) Those relating to the message in general. For
example, channel errors, many oversize lines,
oversize message, premature and erroneous 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.
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.
4) Those relating to inconsistencies between lines.
Mismatch between security warning in FL1 or
FL4 and security classification in FL12a; between
RIs in FL2 and FL7 and 8; or FL2 and FL4 when
"T" instructions are used".
b) Details of the conditions found by analysis that
require the message to be presented for service
assistance will be attached to the message for
use when the message is presented and for possible
statistical uses.
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 a complete analysis is accomplished, 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.
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. The action could be the procedure as fo
re-transmission.
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. The
processing of this message type is as for a normal
plaindress message (text contains printable characters
always).
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) or via
the distribution function. This type includes messages
with encrypted texts but non-encrypted addressees.
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
form 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 (TRC, Point to point). 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. The message
will be re-transmitted over the outgoing channel
related to the incoming channel over which
the message was received. 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. CAMPS will 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 point out the reasons and which lines
involved. The analysis function then places a reference
to the message in the appropriate queue of the
TEP. 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.
b) C̲o̲r̲r̲e̲c̲t̲i̲o̲n̲
The MSO edits the message to correct it, and submits
it for re-analysis. The TEP passes the message
back to the analysis function. If the message still
contains errors it is now returned as a response
to the same terminal.
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 and the MCB of the message is updated
and removed from the queue.
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 transaction 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.
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 release and comments are now handled
as for their locally-generated equivalents (see
below). VDU pages are eventually passed to TMP
for filing. Released messages are transferred within
THP to be processed as an outgoing message.
figure 4.2.4-3
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
COMPLETE RELEASED FOR FOR COMMENT VDU
PAGE
RELEASE CO-ORDI-
NATION
SOURCE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
CCIS X X X
X
X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SCARS X
X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
PTR/OCR X X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
NOTE: 1) A complete message 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.
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.
Figure 4.2.4-4
4.2.4.10 D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲(̲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 five 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.
4) To deliver the message (via TEP) to appropriate
terminals and devices.
5) To control queues in respect to terminal sign-on/sign-off
procedures.
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 with respect
to incoming messages.
a) The distribution function is supplied with queue
elements referring to messages supplied by analysis
of messages 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
PLAs and SICs of the message as qualified by
operational and exercise SDLs. 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. 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
always completely displayable and printable.
Such a message will be queued for the MDCO
if address information is missing, otherwise
this message type will be distributed as a
normal plaindress message.
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.
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. 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 from the MCB.
4.2.5 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲F̲l̲o̲w̲ ̲f̲o̲r̲ ̲a̲n̲ ̲O̲u̲t̲-̲M̲e̲s̲s̲a̲g̲e̲
4.2.5.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
This section describes the CAMPS processes required
for handling outgoing information.
a) A̲C̲P̲1̲2̲7̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Figure 4.2.5-1 shows the main processing steps
involved in the processing of a normal plaindress
out-message, together with the use made of system
tables and message storage facilities. Other types
of out-message require variations on these processing
steps as is shown in simplified form in figure
4.2.5-2. Further details about these variations
are given under the corresponding process descriptions.
A summary matrix showing significant process actions
applicable to different outgoing message types
is given in figure 4.2.5-3.
b) N̲o̲n̲-̲A̲C̲P̲1̲2̲7̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
CAMPS must also be able to send distributed messages
and comments to CCIS and SCARS as appropriate.
The handling of this information differs from that
of ACP127 messages and is described further under
the Output process (4.2.5.7).
c) F̲l̲o̲w̲ ̲o̲f̲ ̲C̲o̲n̲t̲r̲o̲l̲
Many processes are involved in handling an out-going
ACP127 message from initial preparation through
output on the required telegraph channels and internal
distribution. Most of the processes occur sequentially,
but the output to telegraph channels and the internal
distribution will occur in parallel and asynchronously.
As with incoming messages, the message control
block (MCB), which is created when a message is
prepared, is where the current status of a message
is recorded and is the prime means of passing information
about a message to processes. The other means is
via process queue elements.
Figure 4.2.5-1
Figure 4.2.5-2
Figure 4.2.5-3
4.2.5.2 M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲/̲I̲n̲p̲u̲t̲ (See Figures 4.2.5-2, 4.2.5-3)
Before an outgoing message can be processed, CAMPS
must be given the text of the message, its addresses
or RIs, security classification, precedence etc. Message
preparation is a general name for all the processes
involved in collecting this information. The actual
processes vary according to the type and source of
a message, but the end result will be a stored message
with an MCB. In cases where an outgoing message is
prepared from a previous message (for example, re-route,
retransmission) detailed design will state how the
new message will relate to the previous version and
how the MCB will be created.
a) N̲o̲r̲m̲a̲l̲ ̲P̲l̲a̲i̲n̲d̲r̲e̲s̲s̲/̲V̲D̲U̲ ̲I̲n̲p̲u̲t̲ ̲(̲T̲E̲P̲)̲
This interactive preparation process is controlled
by the Terminal Package (TEP). The process involves:
1) various methods of text preparation (VDU input;
appending texts of other messages; use of predefined
messages with validation of formatted data)
2) validation of information to be used in the
header of the message (addresses, precedence,
security classifications) and therefore access
to the appropriate address tables
3) validation of message subject and distribution
information (SICs, exercise data, and local
distribution information) and therefore access
to the appropriate tables
4) acceptance of instructions concerning the further
processing of the message (for example, coordination,
release and special handling). Provided the
message has not been queued for release, it
may be edited and changed and is held by the
system pending the release verdict.
b) N̲o̲r̲m̲a̲l̲ ̲P̲l̲a̲i̲n̲d̲r̲e̲s̲s̲/̲N̲o̲n̲-̲V̲D̲U̲ ̲I̲n̲p̲u̲t̲ ̲(̲T̲H̲P̲)̲
Outgoing messages may be received from OCR, PTR,
CCIS and SCARS. In these cases the messages will
have been prepared externally and are received
by the Traffic Handling Package (THP), see 4.2.4.9,
which will check that the message is acceptable
to CAMPS (in terms of size, classification etc.)
and validate the message according to its status.
Messages that are unacceptable to CAMPS are presented
to MSO. Messages that are acceptable to CAMPS are
then processed as follows:
1) Messages for coordination are delivered to
the appropriate users/terminals by the distribution
package (MDP).
2) Messages for release are delivered by the MDP.
3) Released messages are handled by THP (see 4.2.5.4).
c) P̲l̲a̲i̲n̲d̲r̲e̲s̲s̲ ̲(̲D̲a̲t̲a̲)̲
The text of a data message is always displayable
and printable. Validation of information is confined
to addresses, classification and precedence.
d) E̲n̲c̲r̲y̲p̲t̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲
An encrypted message is prepared externally to
CAMPS. Because the encryption could include the
addresses (CODRESS message), such a message can
only be routed to appropriate outgoing circuits
according to explicitly-provided RIs. In this respect,
its handling is as for a complete message.
e) S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲(̲T̲E̲P̲)̲
1) N̲o̲r̲m̲a̲l̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲
This is prepared interactively in much the
same way as a normal message.
2) A̲b̲b̲r̲e̲v̲i̲a̲t̲e̲d̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲
This is prepared interactively in a simplified
way, giving the drafter greater freedom to
specify the content of the ACP127 header of
the message. The message is routed according
to RIs explicitly supplied by the drafter;
no addressee validation and examination is
performed. The system only validates classification,
precedence and RIs.
3) S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲f̲o̲r̲ ̲D̲e̲s̲i̲g̲n̲a̲t̲e̲d̲ ̲C̲h̲a̲n̲n̲e̲l̲
There is an implied requirement for a version
of an abbreviated service message that will
be output on a specific channel of a circuit
(see 4.2.5.7). This would be used for certain
accounting messages and test messages.
f) C̲h̲a̲n̲n̲e̲l̲ ̲C̲h̲e̲c̲k̲s̲ ̲(̲T̲H̲P̲)̲
A channel check is either generated automatically
by THP or is received as an in-message from an
external station and is self-addressed to that
station. (This requires the selection of a specific
channel of a circuit (see 4.2.5.7)).
g) A̲u̲t̲o̲m̲a̲t̲i̲c̲ ̲F̲l̲a̲s̲h̲ ̲A̲c̲k̲n̲o̲w̲l̲e̲d̲g̲e̲m̲e̲n̲t̲ ̲(̲T̲H̲P̲)̲
This is an abbreviated service message that is
automatically generated by THP (if required) upon
receipt of a FLASH-precedence message.
h) I̲d̲e̲n̲t̲i̲c̲a̲l̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲(̲T̲H̲P̲)̲
This is an abbreviated service message that is
automatically generated by THP under certain circumstances
(see figure 4.2.4-2).
i) R̲e̲l̲a̲y̲ ̲(̲T̲H̲P̲)̲
This is an in-message received by the CAMPS that
contains instructions in ACP127 format line 4 requiring
that CAMPS transmits the message according to named
RI(s). For design convenience it may be desirable
to treat this type of message as a new message
separate from its incoming version.
j) C̲o̲m̲p̲l̲e̲t̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲(̲T̲H̲P̲)̲
A complete message requires CAMPS to transmit the
message according to its RIs. Such a message is
prepared externally and then input to CAMPS (for
example via a PTR, see figure 4.2.4-4). After validation
it is handled in a similar way to an abbreviated
service message.
k) R̲e̲-̲t̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲(̲T̲E̲P̲)̲
The re-transmission of a message may be initiated
after the retrieval of the appropriate version
of the required message. A mis-routed message may
be returned into the system by using the same facilities
as available for retransmission.
m) R̲e̲-̲a̲d̲d̲r̲e̲s̲s̲a̲l̲
Refer CPS/230/ICD/0003.
4.2.5.3 C̲o̲o̲r̲d̲i̲n̲a̲t̲i̲o̲n̲ ̲(̲T̲E̲P̲,̲ ̲M̲D̲P̲)̲
Plaindress messages prepared by a CAMPS for which he
has taken responsibility may optionally be presented
to designated users/terminals for coordination.
a) In the case of a message prepared by a CAMPS user,
TEP passes the message to MDP for delivery.
b) In the case of a message received from CCIS for
coordination, THP passes the message to MDP for
delivery. The designated CAMPS-user now takes over
the responsibility for the message, i.e. coordinates
it with other CAMPS-users, updates it if necessary
and queues it for release as a normal outgoing
message.
4.2.5.4 R̲e̲l̲e̲a̲s̲e̲ ̲(̲T̲E̲P̲
a) A plaindress message prepared by a CAMPS user (who
is neither a Supervisor or a supervisor-assistant)
has to be presented to an appropriate user/terminal
for release; a message received from CCIS may,
optionally, require release by a CAMPS user. Release
does not alter a message; it allocates a release
date-time group (file time) and a station serial
number to the message (see 4.2.5.5). Release is
an interactive transaction controlled by TEP which
has one of the following results:
1) M̲e̲s̲s̲a̲g̲e̲ ̲r̲e̲l̲e̲a̲s̲e̲d̲
The message is queued for the ACP127 synthesis
process of THP (see 4.2.5.5, figures 4.2.5-1,
4.2.5-2).
2) R̲e̲l̲e̲a̲s̲e̲ ̲r̲e̲f̲u̲s̲e̲d̲
TEP sends an appropriate comment to the user/terminal
associated with the drafting of the message.
3) R̲e̲l̲e̲a̲s̲e̲ ̲D̲e̲f̲e̲r̲r̲e̲d̲
TEP sends an appropriate comment to the user/terminal
associated with the drafting of the message.
4.2.5.5 A̲C̲P̲1̲2̲7̲ ̲S̲y̲n̲t̲h̲e̲s̲i̲s̲ ̲(̲T̲H̲P̲)̲
This function is used for plaindress messages that
originate from CAMPS users, CCIS and SCARS where CAMPS
is responsible for allocating the appropriate routing
(see figure 4.2.5.2). Much of the information needed
for the ACP127 header of a message is supplied during
the various message preparation functions. The ACP127
synthesis function continues the build-up of this
information.
a) O̲b̲j̲e̲c̲t̲i̲v̲e̲s̲
The objectives of this function are:
1) To allocate station serial number (SSN), and
time of release (file time) for pre-released
messages received from SCARS or CCIS.
2) To derive the routing indicators (RIs) associated
with the addressees of the message.
3) To add appropriate operating signals to the
message according to system parameters and
operator-supplied information.
4) To arrange for a message requiring routing
assistance to be presented to the MSO.
b) M̲e̲s̲s̲a̲g̲e̲ ̲F̲o̲r̲m̲a̲t̲
At this stage in the handling of a message, the
header information is pointed out via the MCB.
Detailed design will decide on the most convenient
form in which to hold this information (for example,
as parameters or as formatted lines ready for transmission).
Thus in the following description, references to
ACP127 format lines mean their logical content,
not their physical layout.
c) A̲l̲l̲o̲c̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲S̲S̲N̲,̲ ̲F̲i̲l̲e̲ ̲t̲i̲m̲e̲,̲ ̲a̲n̲d̲ ̲T̲i̲m̲e̲ ̲o̲f̲ ̲R̲e̲l̲e̲a̲s̲e̲
̲(̲T̲E̲P̲)̲
The SSN is obtained from the system parameters
via TMP which will also update the current value.
The SSN and file-time are placed in ACP127 format
line 3; the date-time of release is placed in ACP127
format line 5. There is no distinction between
time of release and file time for messages created
under the control of CAMPS. The SSN and release
date-time are supplied to SAR as retrieval parameters.
1) M̲e̲s̲s̲a̲g̲e̲ ̲R̲e̲l̲e̲a̲s̲e̲ ̲b̲y̲ ̲C̲A̲M̲P̲S̲
An SSN and date-time of release are allocated
to the message and also incorporated in a release
notification and log entry. The release note
is sent to the user/terminal associated with
the drafting of the message.
2) P̲r̲e̲-̲r̲e̲l̲e̲a̲s̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲
No release notification is generated. The SSN
allocation of release date-time and file date-time
is also allocated by this function.
d) A̲l̲l̲o̲c̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲R̲o̲u̲t̲i̲n̲g̲ ̲I̲n̲d̲i̲c̲a̲t̲o̲r̲s̲ ̲(̲R̲I̲s̲)̲
This description assumes an uncomplicated situation;
special cases are discussed in sub-para. e).
1) The RIs of a message are obtained from the
PLA table. This table is accessed directly
using the PLAs of the message from ACP127 format
lines 7, 8. It is accessed indirectly via AIGs
in these format lines after any exempt addressees
in format line 9 have been subtracted from
the AIGs. For each PLA thus obtained, the RI
appropriate to the security classification
of the message selected.
2) For each PLA directly listed in the prepared
ACP127 format lines 7, 8, the selected RI is
logically associated with it in the MCB so
that the RI/PLA combination will appear in
the transmitted versions of the message.
3) All the RIs selected are now sorted according
to the requirements and duplicates eliminated.
They now form a composite ACP127 format line
2 to be stored in the Routing List and handled
by the Route Assignment process (4.2.5.6).
e) S̲p̲e̲c̲i̲a̲l̲ ̲C̲a̲s̲e̲s̲
In allocating RIs to a message the following special
cases have to be taken into account:
1) A̲d̲d̲r̲e̲s̲s̲e̲e̲ ̲U̲n̲k̲n̲o̲w̲n̲
A message is allocated addressees during the
preparation process and these are then checked
for existence against the PLA and AIG tables.
Addressees that are not held in these tables
may still be contained in the message at the
specific request of the drafter. In this case
the message has to be presented to MSO for
manual routing assistance.
2) T̲a̲b̲l̲e̲s̲ ̲C̲h̲a̲n̲g̲e̲d̲
The functional flow described here, assumes
that RIs are not allocated during message preparation
but are allocated after coordination and release.
(The final decision depends on detailed design).
In this manner, the most up-to-date RI allocation
may be used. However, it is possible that a
PLA or an AIG of the message may have been
removed from the tables. In this case the message
requires manual routing assistance.
3) C̲C̲I̲S̲,̲ ̲S̲C̲A̲R̲S̲
Messages originated by CCIS and SCARS may contain
addressees that are not in the CAMPS tables.
Such addressees will require manual routing
assistance for a message.
4) R̲I̲/̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲C̲l̲a̲s̲s̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲M̲i̲s̲m̲a̲t̲c̲h̲
If for a given PLA there is no RI with a suitable
security classification, it will be queued
to MSO for manual RI assignment.
5) Z̲E̲N̲
For a given PLA the associated record in the
PLA file may indicate ZEN instead of an RI.
This situation is handled by the Route Assignment
function (4.2.5.6).
6) O̲v̲e̲r̲s̲i̲z̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲
There is a design limit on the size of messages
that CAMPS can handle. It is assumed that this
limit applies to all versions of a message
so that, for example, a message that exceeds
the limit would be unacceptable even if it
could subsequently be split into separate transmitted
sections each of which individually would not
exceed limit. However, the limit may be reached
at various stages of processing. For example,
during message preparation; during ACP127 synthesis
when RIs are added to ACP127 format lines 7
and 8.
f) R̲o̲u̲t̲i̲n̲g̲ ̲A̲s̲s̲i̲s̲t̲a̲n̲c̲e̲ ̲(̲T̲E̲P̲)̲
The reason for presenting an outgoing message to
a service operator for routing assistance is primarily
to permit RIs to be assigned manually in respect
of addressees that are unknown to the system. The
following are some of the factors to be taken into
account:
1) 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
and will indicate which addressees or other
components of the message are involved. The
ACP127 synthesis function then places a reference
to the message in the appropriate queue of
the terminal handler (TEP). When the message
is eventually presented at a service terminal,
the function performing this task will format
and present the information appropriately.
It is possible that the service operator may
need to view the proposed ACP127 header and
text as well as any addressees (PLA or AIG)
that are causing problems in order to decide
on the appropriate routing. The text of DATA
messages would not be displayed. In addition,
the operator may need to know who prepared
the messages in case of problems; so the CAMPS
input source should be identified.
2) O̲p̲e̲r̲a̲t̲o̲r̲ ̲A̲c̲t̲i̲o̲n̲
The operator may supply the RI or RIs required.
For a PLA this may be associated directly.
For an unknown AIG, it may be necessary to
supply a series of RIs. In some cases ZEN may
need to be specified.
3) S̲u̲b̲s̲e̲q̲u̲e̲n̲t̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
The re-processing of the message may require
a check that all addressees have now been allocated
RIs or ZEN, though an AIG may have to be exempted
from this check. The RIs supplied can be validated
for format. Any problems should cause the message
to be presented to the same operator as a response.
If the message is now acceptable, it is returned
to the ACP127 synthesis function.
4) R̲e̲l̲a̲t̲i̲o̲n̲s̲h̲i̲p̲ ̲w̲i̲t̲h̲ ̲I̲n̲-̲m̲e̲s̲s̲a̲g̲e̲ ̲C̲o̲r̲r̲e̲c̲t̲i̲o̲n̲ (4.2.4.8)
The MSO is responsible for both the correction
of in-coming messages and routing assistance
for out-going messages. TEP will distinguish
between these classes of message so as to control
the actions permitted.
g) C̲o̲n̲c̲l̲u̲s̲i̲o̲n̲ ̲o̲f̲ ̲A̲C̲P̲1̲2̲7̲ ̲S̲y̲n̲t̲h̲e̲s̲i̲s̲
Provided that the processing of a message does
not terminate at the MSO, this function will conclude
by queuing a message for the Route Assignment function
of THP and for the internal distribution function
of MDP.
4.2.5.6 R̲o̲u̲t̲e̲ ̲A̲s̲s̲i̲g̲n̲m̲e̲n̲t̲ ̲(̲T̲H̲P̲)̲
This process is used for all outgoing messages where
the system has to route the messages to external telegraph
circuits on the basis of RIs. (Thus it is not used
for messages that are allocated to specific channels
during preparation; for example, channel checks and
channel accounting messages).
a) I̲n̲p̲u̲t̲
The process will be fed by an input queue of messages
of all types. The MCB of each message, regardless
of its type or source, would provide the process
with the RIs and other parameters.
b) O̲u̲t̲p̲u̲t̲
For each message, the process will group the RIs
within the MCB into the ACP127 format lines 2 required
for each separate transmission of the message and
will queue the message for the output process (4.2.5.7).
Messages which require local output could be queued
for the appropriate device by this process or by
the output process (depending on the final design).
c) P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
1) For each RI of a message, the process will access
the CAMPS Routing Table to identify the corresponding
outgoing circuit. As a result, the RIs can now
be grouped by outgoing circuit.
2) There is a limit on the number of RIs per transmission
on a given circuit. If necessary, a group will
be subdivided to avoid exceeding the circuit RI
limit.
3) If the length of the text of a normal (i.e. non-data)
message is greater than the limit laid down in
ACP127, the message text is to be sub-divided into
sections and sent as separate messages (the ACP127
header will be the same). Thus each transmission
identified in steps 1 to 2 above, will be applied
to each section of a long message. In principle,
the output process only needs to know the section
boundaries of the message text in order to sub-divide
it for transmission.
4.2.5.7 O̲u̲t̲p̲u̲t̲ ̲(̲T̲H̲P̲ ̲&̲ ̲I̲O̲C̲)̲
The output process or processes of THP together with
IOC provide facilities for the transmission of out-messages
over telegraph circuits of various types (maximum speed
NICS-TARE, low speed TRCs etc.) and transmission of
information to SCARS and CCIS. This section briefly
describes the requirements for handling the telegraph
circuits.
a) C̲i̲r̲c̲u̲i̲t̲/̲C̲h̲a̲n̲n̲e̲l̲
If CAMPS is connected to another station (for example,
a NICS-TARE) by more than 1 channel, this group
of channels form a circuit. In general, the channels
will have identical channel characteristics and
are only distinguishable by name. Only messages
that are testing or otherwise concerned with a
Specific channel (for example channel check messages)
will be queued directly for the channel. All other
messages will be queued by the Route Assignment
process for a circuit. The first free channel of
a circuit outputs the next message.
b) P̲r̲e̲c̲e̲d̲e̲n̲c̲e̲
Messages are output in order of queuing within
precedence. Flash precedence messages may pre-empt
other messages under certain conditions.
c) C̲l̲a̲s̲s̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲a̲ ̲C̲i̲r̲c̲u̲i̲t̲
It is assumed that all the channels of a given
circuit will have the same security classification.
The relationship between RIs and circuits is unlikely
to change frequently. On this basis, if an RI is
selected to suit the classification of a message,
the corresponding circuit should also suit the
classification of the message. If not, the RI allocation
according to the PLA table is incorrect. The output
process will produce a report and take special
action if there is a classification mismatch between
a message and a circuit.
d) C̲i̲r̲c̲u̲i̲t̲ ̲U̲n̲a̲v̲a̲i̲l̲a̲b̲l̲e̲
A circuit will be unavailable if all of its channels
are closed. This situation will require an adjustment
to the routing table to provide an alternative
circuit of equal or higher classification.
e) S̲t̲r̲u̲c̲t̲u̲r̲e̲ ̲o̲f̲ ̲a̲ ̲M̲e̲s̲s̲a̲g̲e̲
Upon transmission all the components of the ACP127
header of a message and its text need to be assembled
in the correct order with the appropriate ACP127
format line 2. This can be achieved dynamically
as the message is output, or in advance by storing
the message in the appropriate form. Additionally,
ACP127 page headers need to be inserted for certain
message types (see figure 4.2.5-3) and long messages
need to be split into separately transmitted sections.
f) F̲L̲A̲S̲H̲ ̲A̲c̲k̲n̲o̲w̲l̲e̲d̲g̲e̲m̲e̲n̲t̲
Under certain conditions, the system will expect
eventually to receive an acknowledgement for each
successful transmission and appropriate details
of the transmission.
g) C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲o̲f̲ ̲I̲T̲A̲ ̲5̲ ̲t̲o̲ ̲I̲T̲A̲ ̲2̲
CAMPS handles all messages in ITA5 code. On transmission
of a message on a channel that requires ITA2, an
appropriate conversion is performed.
h) A̲l̲l̲o̲c̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲I̲d̲e̲n̲t̲i̲f̲i̲e̲r̲s̲ ̲(̲T̲I̲)̲
The TI for a given transmission of a message can
only be allocated when the message is about to
be output on a channel. The TI is therefore allocated
by the output process, the appropriate channel
sequence number updated, and the TI supplied to
SAR as a retrieval parameter.
4.2.5.8 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̲)̲
The internal distribution of out-messages is performed
by MDP. The facilities needed are outlined in 4.2.4.10,
and the message types that may require it are shown
in fig. 4.2.5-3. Out-message distribution is to staff
cells named by the drafter of a message.
4.2.5.9 F̲i̲n̲a̲l̲ ̲S̲i̲t̲u̲a̲t̲i̲o̲n̲
As described in 4.2.4.13, in addition to the processing
outlined in this section, an outgoing message is stored
in short-term storage in CAMPS internal format together
with the MCB. The message will be moved to intermediate
store (or deleted) as for an in-message. Appropriate
retrieval parameters are derived and stored, and statistics
generated.
4.2.6 V̲i̲e̲w̲s̲ ̲o̲f̲ ̲a̲ ̲M̲e̲s̲s̲a̲g̲e̲
An ACP127 message is a complex structure of variable
length components. Different views of this structure
are needed depending upon the use being made of the
message. This section describes the views of a message
required by CAMPS with reference to fig. 4.2.6-1. In
all cases the SOTF and EOTF sequences are never stored.
4.2.6.1 I̲n̲-̲M̲e̲s̲s̲a̲g̲e̲
a) D̲u̲r̲i̲n̲g̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲ ̲a̲n̲d̲ ̲G̲a̲r̲b̲l̲e̲ ̲C̲o̲r̲r̲e̲c̲t̲i̲o̲n̲
The message has a start and an end and analysis
is attempting to define the structure in between.
b) A̲f̲t̲e̲r̲ ̲S̲u̲c̲c̲e̲s̲s̲f̲u̲l̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
For a message in general ACP127 format lines 1
through 11 are identified though some are optional
and some are not present in certain types of messages.
ACP127 page headings may be present within format
lines 7 onwards and in the text.
Fig. 4.2.6-1
c) D̲i̲s̲t̲r̲i̲b̲u̲t̲e̲d̲ ̲F̲o̲r̲m̲ ̲
This consists of format lines 5 onwards but with
RIs removed from address format lines 7 and 8.
A distribution list is added (this may be at the
top or bottom of the message depending on the eventual
requirement).
d) R̲e̲t̲r̲i̲e̲v̲a̲l̲
The possible retrieval presentation forms are
1) As received (or if the message has been corrected
by MSO, only the corrected form is available).
2) Distributed form (only for message types that
are distributed).
3) Data Message (without display of the message
text).
4.2.6.2 O̲u̲t̲-̲M̲e̲s̲s̲a̲g̲e̲
a) D̲u̲r̲i̲n̲g̲ ̲P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲,̲ ̲C̲o̲o̲r̲d̲i̲n̲a̲t̲i̲o̲n̲,̲ ̲R̲e̲l̲e̲a̲s̲e̲
This consists of text, addressees, and other parameters
in the VDU format.
b) R̲o̲u̲t̲i̲n̲g̲ ̲A̲s̲s̲i̲s̲t̲a̲n̲c̲e̲
This form is TBD, but could consist of the composite
ACP127 format line 2, header format lines 5 to
11 and the text, unpaged and not split for separate
transmissions.
c) D̲i̲s̲t̲r̲i̲b̲u̲t̲e̲d̲ ̲F̲o̲r̲m̲
As for In-Message.
d) T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲
ACP127 format lines 1 and 2 for the transmission
and the rest of the header lines 3 to 11, ACP127
paging, and the text. If the text is long, the
transmission will contain the appropriate text
section and the page headings will also show the
section number.
e) S̲t̲o̲r̲e̲d̲ ̲F̲o̲r̲m̲
To permit the various versions of an out-message
to be retrieved sufficient information must be
held to supply:
1) Format lines 1 and 2 for any transmission together
with the appropriate text section and page
headings (if applicable).
2) The composite format line 2 in case of a re-transmission
to all addressees, together with any or all
of the separate transmitted sections.
4.2.6.3 R̲e̲-̲t̲r̲a̲n̲s̲m̲i̲t̲t̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲
In addition to the original structure of the message,
this contains pilot lines A,B,C (equivalent to format
lines 1 to 3) in place of line 1.
4.2.6.4 S̲e̲r̲v̲i̲c̲e̲ ̲a̲n̲d̲ ̲E̲n̲c̲r̲y̲p̲t̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
These are held in their as-received/corrected or as-transmitted
forms.
4.2.6.5 C̲h̲a̲n̲n̲e̲l̲ ̲C̲h̲e̲c̲k̲s̲
These are stored and may be retrieved.
4.2.6.6 A̲u̲t̲o̲m̲a̲t̲i̲c̲a̲l̲l̲y̲ ̲G̲e̲n̲e̲r̲a̲t̲e̲d̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
These are stored and may be retrieved.
