top - download
⟦b2573cafd⟧ Wang Wps File
Length: 31121 (0x7991)
Types: Wang Wps File
Notes: CPS/SDS/001
Names: »0501A «
Derivation
└─⟦7c0ec4e20⟧ Bits:30006001 8" Wang WCS floppy, CR 0036A
└─ ⟦this⟧ »0501A «
WangText
.…0a….…0c….…0d….…86…1
…02…
…02… …02…
…02…CPS/SDS/001
…02…RG/810115…02……02…
CAMPS
SYSTEM
DESIGN
SPECIFICATION
…02……02…CAMPS
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 (including Release acceptance, reject,
and defer responses) 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.
However, to avoid conflicts it may be necessary
to prevent internal distribution occuring until
the completion of ACP127 synthesis and any associated
routing assistance by MSO (4.2.5.5). 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. Information about the message
may also be recorded in the MCB for later, statistical
use.
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̲ (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;
merging with texts of other messages; use of
predefined text formats 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 sent 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, CCIS,
SCARS. In these cases the messages will have been
prepared externally and are received by the Traffic
Handler 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
(the logging and storage requirements in this case
are TBD). 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 either
MDP or TEP (TBD).
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, by definition, neither
displayable nor printable. Though CAMPS has to
be able to output such messages, their origin and
preparation is TBD. The meaning of coordination,
release, and internal distribution for such messages
is also TBD. Validation of information would be
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 routed message (see below).
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) A̲u̲t̲o̲m̲a̲t̲i̲c̲ ̲M̲u̲l̲t̲i̲p̲l̲e̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲R̲e̲p̲o̲r̲t̲ ̲(̲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) R̲o̲u̲t̲e̲d̲ ̲(̲T̲H̲P̲)̲
A routed 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̲-̲r̲o̲u̲t̲e̲
This is an in-message which the MSO wishes to return
to the telegraph network (see 4.2.4.6). It is handled
in a similar way to an abbreviated service message.
The preparation process is TBD.
l) 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. The details of the preparation
of such a message are TBD.
m) R̲e̲-̲a̲d̲d̲r̲e̲s̲s̲a̲l̲
TBD
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 user or received
from CCIS may optionally be presented to designated
users/terminals for coordination. This process does
not alter the message, though the drafter of the message
may edit it (this could occur whilst the message is
queued for coordination and whilst being viewed by
a coordinator).
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. A subsequent message (released or pre-released,
or for coordination again) may or may not be received.
The storage and status of the message for coordination
in these situations is TBD since it is not clear
how the messages are related to each other.
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. (The
situation where a user who is empowered to release
a message is also the drafter of the message is
TDB). Release does not alter a message; it allocates
a release date-time group 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.
In the case of a CCIS-originated message, the
action is TBD. The handling of highly-classified
messages (which are to be deleted when processing
is completed) is TBD for this situation.
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. In the case of a CCIS-originated
message, both this action and the subsequent
handling of the same message are TBD.
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, SCARS, and OCR 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), filing
time, and time of release.
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 contained in 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̲i̲n̲g̲ ̲t̲i̲m̲e̲,̲ ̲a̲n̲d̲ ̲T̲i̲m̲e̲ ̲o̲f̲ ̲R̲e̲l̲e̲a̲s̲e̲
The SSN is obtained from the system parameters
via TMP which will also update the current value.
The SSN and filing date-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 filing 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
note 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 note is generated. The SSN is allocated
by this function but allocation of release
date-time and filing date-time is TBD. The
use of this information as retrieval parameters
is also TBD.
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
(and potentially other collective addressees)
in these format lines after any exempt addressees
in format line 9 have been subtracted from
the collective addressees. 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. This
explicit coupling of RI and PLA is neither
possible nor required for collective addressees.
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 MCB 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 necessary
to off-line encrypt the message in respect
of that addressee. For a given message this
condition could apply to all or a subset of
the addressees. The handling of a message in
this situation is TBD.
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) L̲o̲c̲a̲l̲ ̲P̲L̲A̲ ̲
A message may be addressed to an addressee
local to the originating CAMPS site (this might
apply to some or all of the message s addressees).
Such a message obviously does not need to be
transmitted into the telegraph network in respect
of the addressees. This situation would be
handled by the distribution function of MDP;
the distribution criteria are TBD. If all the
addressees of a message are local to the CAMPS
site, no external transmissions will be needed
and no RIs allocated.
7) 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; and during Route Assignment when format
line 2 is created. The action to be taken in
these situations is TBD.
8) O̲t̲h̲e̲r̲ ̲P̲r̲o̲b̲l̲e̲m̲s̲
A given PLA may have additional routing requirements
for example, the need for passing instructions
to be added to ACP127 format line 4. The method
by which the system recognizes this situation
is TBD.
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. Other
reasons (such as the need for passing instructions;
message oversize etc.) are TBD. The presentation
and handling of the message are TBD. 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
user should be identified, or CCIS, or OCR,
or CCIS, or SCARS.
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. It should be assumed
that there will be cases where the operator
will want to stop further processing of the
message pending reference back to the drafter
of the message.
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 are 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 to the operators. The
queuing method is TBD (a composite queue or
separate queue for each class of message).
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. By waiting until routing assistance, if
any, has concluded before permitting internal distribution,
it will be possible to avoid conflicts that might
occur if a message were to be simultaneously presented
to MDCO and MSO, and to avoid distributing a message
that might be rejected by the MSO. It is possible
that:
1) There may be no need for route assignment
if an out-message is addressed only to
addressees local to the CAMPS site.
2) There may be no internal distribution (for
example, if no distribution has been specified,
or for a DATA message).
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̲s̲
The process would 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̲s̲
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 (because of
ZEN or other reasons) 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̲
1) For each RI of a message, the process will access
the CAMPS Routing Table to identify the corresponding
outgoing circuit. (Because any CAMPS site will
have very few outgoing circuits but will handle
a large number of RIs, use can probably be made
of the hierarchical structure of RIs to produce
a very compact Routing table; see detailed design).
As a result, the RIs can now be grouped by outgoing
circuit.
2) A dual precedence message where the higher (action)
precedence is FLASH, may in certain circumstances
require separate transmissions to be made in respect
of the Action and Info addressees respectively.
To be able to fulfil this requirement means that
the RIs associated with the action addressees need
to be separately grouped. (It is also possible
that 1 RI could apply to both an action and an
info addressee).
3) Because there is a limit on the number of RIs per
transmission on a given circuit, the process checks
the corresponding circuit table for each group
of RIs. If necessary, a group will be subdivided
to avoid exceeding the circuit RI limit.
4) 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 3 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. This transmission can be stored
in the MCB by whichever process is the most convenient.
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̲c̲i̲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 would normally 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. The situation in respect of
relay and re-routed messages is TBD.
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. The effect
of such a conversion on a data message is TBD.
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 MSP. 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 normally
to staff cells named by the drafter of a message. The
basis for distribution of the message is addressed
to an addressee local to the originating CAMPS site
is TBD.
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 message.
ACP127 page headings may be present within format
lines 7 onwards and in the test. If the message
has been re-addressed format lines 5 to 11 may
re-occur.
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.
In the case of a re-addressed message the RIs are
only removed from the first set of address lines.
A distribution list is added (this may be at the
top or bottom of the message depending on the eventual
requirement). Removal of ACP127 page headers is
TBD.
d) R̲e̲t̲r̲i̲e̲v̲a̲l̲
The possible retrieval 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 handlings 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 (TBD).
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 not stored, though there may be retrieval
parameters (TBD).
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̲
TBD.
