top - download
⟦c3392354a⟧ Wang Wps File
Length: 54815 (0xd61f)
Types: Wang Wps File
Notes: TEP VDU User Package
Names: »1127A «
Derivation
└─⟦fad1c67d1⟧ Bits:30006043 8" Wang WCS floppy, CR 0069A
└─ ⟦this⟧ »1127A «
WangText
%…07…$…08…$…0c…$…0d…$…02…$
$…07…#…08…#…0d…#…0e…# "…09…"…0d…"…0e…"…02…"
"…07…!…08…!…0b…!…0f…!
…08…
…0b…
…0f…
…1f……08……1f……0b……1f……0f……1f……02……1f……05……1f……06……1e……0a……1e……0b……1e……0c……1e……0d……1e……02……1e……06……1e……07……1d……08……1d……09……86…1
…02…
…02…
…02…
…02…CPS/SDS/027
…02…MSN/810801…02……02…
TEP VDU
USER PACKAGE
…02……02…CAMPS
4.2.1 U̲s̲e̲r̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲A̲c̲c̲e̲s̲s̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲
The U̲ser M̲essage A̲ccess M̲onitoring (UMAM) process has
the responsibility for the status collecting and status
generating. Furthermore, UMAM performs the access control
to the preparation database.
4.2.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The following functions are included in this subpackage
(refer figure 4.2.1.1-1):
- collect status
- generate status
- message access control.
4.2.1.1.1 C̲o̲l̲l̲e̲c̲t̲ ̲S̲t̲a̲t̲u̲s̲
The functional breakdown is shown in figure 4.2.1.1-2.
Status update requests are received from VUP in the
Request Queue. The QEL will identify the type of status.
They are:
- delivery message status
- release status
- outgoing message status.
The release status will be a part of the outgoing message
status.
Fig. 4.2.1.1-1 Functional Specification
If the received information is a part of the release
message status, then the relevant PREP Queue is updated
and the information is stored on the O̲utgoing M̲essage
S̲tatus F̲ile (OMSF) and the file directory (OMFD) is
updated.
If the received information is a part of the outgoing
message status, then the PREP queue is updated.
When the received status is a part of the delivery
status, then the information is stored in the D̲elivery
S̲tatus F̲ile (DSF) and the file director (DFD) is updated.
4.2.1.1.2 G̲e̲n̲e̲r̲a̲t̲e̲ ̲S̲t̲a̲t̲u̲s̲
Two types of status are generated. They are:
- user requested status
- periodic generated status.
The functional breakdown is shown in figure 4.2.1.1-3.
4.2.1.1.2.1 U̲s̲e̲r̲ ̲R̲e̲q̲u̲e̲s̲t̲e̲d̲ ̲S̲t̲a̲t̲u̲s̲
Upon request from a user, a status is generated. There
are three types of status which can be requested:
- outgoing message status
- message release status
- delivery status.
Figure 4.2.1.1-2 Functional Breakdown of Collect Status
a) Outgoing Message Status
Information about the terminal is looked up in
the OMFD. The relevant records are then transferred
from the status file to a temporary CIF. The contents
of the PREP queue associated with the requesting
terminal, are transferred to the CIF too. The CIF
is then sent to the requestor.
b) Message Release Status
Information about the terminal positions which
are associated with this release position are looked
up in the release table and in the OMFD. The relevant
records are then transferred from the status file
and sorted. The remaining records are then sent
to the requestor in a temporary CIF.
c) Delivery Status
Information about the terminal is looked up in
the DFD. The records are then transferred from
the status file to a temporary CIF which is sent
to the requestor.
4.2.1.1.2.2 P̲e̲r̲i̲o̲d̲i̲c̲ ̲G̲e̲n̲e̲r̲a̲t̲e̲d̲ ̲S̲t̲a̲t̲u̲s̲
A summary status is generated each day at 00.00 hours
and sent to the supervisor.
Fig. 4.2.1.1-3 Function Breakdown of Generate Status
The status is generated per terminal as described in
4.2.1.1.2.2 a-b.
When the generated CIF is sent, then the status files
will be cleared and the file directories will be reset.
4.2.1.1.3 M̲e̲s̲s̲a̲g̲e̲ ̲A̲c̲c̲e̲s̲s̲-̲C̲o̲n̲t̲r̲o̲l̲
Deletion commands and edit commands inserted by a user
are received in the Request Queue. The functional breakdown
is shown in figure 4.2.1.1-4.
a) Deletion
Depending on the message status, the deletion request
is either sent to the supervisor or the referenced
item is deleted from the PREP queue.
b) Edit
If the reference message is in a state where it
is available for editing, then the message is sent
to the requesting terminal. If the SEND command
is rejected by QMON due to profile fault, then
the message is deleted and a response message is
returned. If the user does not have access to the
message, then a response message is returned to
the requestor.
Fig. 4.2.1.1-4 Functional Breakdown of Message Access Control
4.2.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The UMAM process consists of two coroutines, the P̲reparation
A̲ccess C̲ontrol (PAC) coroutine and the U̲ser S̲tatus
F̲ile M̲aintenance (USFM) coroutine. PAC is the controlling
coroutine, analysing the requests in the request queue
and delegating the work to be done between USFM and
itself. PAC performs the access control to the PREP
queues and extracts the part of the outgoing message
status derivable from a PREP queue when requested.
USFM extracts/updates the OMSF and OSF when commanded
to do so by PAC.
UMAM has been designed with the two coroutines PAC
and USFM because of the disk transfers to be performed.
This design allows the USFM part of UMAM to wait for
disk transfers without stopping the processing of the
PAC part.
4.2.1.2.1 P̲A̲C̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The software structure of coroutine PAC is shown in
figure 4.2.1.2-1.
PAC will wait for reception of a command either in
the Request Queue or in a semaphore S2. Each command
will constitute a main function and is implemented
as a procedure. A brief description of each procedure
is given below.
Fig. 4.2.1.2-1 PAC Software Structure
a) Update Delivery Status
The received parameters are checked and a completion
code is returned to caller. The received buffer
is sent to USFM.
b) Update Release, Deleted, Comment Sent
The received parameters are checked and a completion
code is returned to caller. If the referenced item
is found in the specified PREP queue, then the
queue element is dismantled. The received buffer
is sent to USFM. If the received buffer reflects
a deletion, then a notification is sent to the
user.
c) Update Append Notification
The received parameters are checked and a completion
code is returned to caller. The referenced messages
are looked up in the PREP queue and the state of
the message is changed to "Append Complete".
d) Update Not Released, Deferred
The received parameters are checked and a completion
code is returned to caller. The referenced message
is looked up in the PREP queue and the message
state is changed.
e) Status Report
A temporary CIF is created and sent to USFM.
f) Delete Request
If the referenced message is available for deletion,
then the queue element placed in the PREP queue
is dismantled. Otherwise a deletion request is
sent to supervisor. The requestor is told about
the action taken.
g) Edit Request
If the referenced message/comment is available
for editing, then the message is sent to the requesting
terminal. If the message is not found or is not
available for editing, then the requestor is notified.
h) Close-Down
The command is sent to USFM.
i) Start-Up
The state of the messages which are awaiting append
is changed to "Append Abandon".
j) Delivery Status Closing
The CIF which contains the extracted status is
sent to requestor.
k) Outgoing Status Closing
This extracts the status information from the PREP
queue. The information is sent to requestor in
a temporary CIF together with the records extracted
from OMSF.
l) Release Status Closing
The CIF which contains the extracted status is
sent to requestor.
m) Time Request Outgoing Status Closing
This extracts the status information from the PREP
queues. The information is sent to supervisor in
a temporary CIF together with the records extracted
from OMSF.
n) Time Request Release Status Closing
The CIF which contains the extracted status is
sent to supervisor.
o) SSC Completion
Sends a completion code to the SSC package.
4.2.1.2.2 U̲S̲F̲M̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The software structure of coroutine USFM is shown in
figure 4.2.1.2-2.
USFM will wait for reception of a command either in
semaphore S0 or in semaphore S1, where S0 has the highest
priority. Each command will constitute a main function
and is implemented as a procedure. A brief description
of each procedure is given below:
a) Update Delivery Status
The received buffer is stored in DSF and the file
directory is updated.
b) Update Rel/Out Status
The received buffer is stored in OMSF and the file
directory is updated.
c) Delivery Status Request
The relevant records are transferred from DSF to
a temporary CIF which is sent to PAC.
d) Outgoing Status Request
The relevant records are transferred from OMSF
to a temporary CIF which is sent to PAC.
Fig. 4.2.1.2-2 USFM Software Structure
e) Release Status Request
The relevant data are transferred from OMSF to
memory. The records are sorted and sent to PAC
in a temporary CIF.
f) Release Status Time Request
A release status is generated for all release terminals.
The result is sent to PAC in a temporary CIF.
g) Outgoing Message Status Time Request
An outgoing status is generated for all terminals.
The result is sent to PAC in a temporary CIF.
h) Close-Down
File directories are updated and stored safely
on disk.
i) Start-Up
File directories are fetched from disk and updated.
4.2.1.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
The HIPO diagrams overleaf show the data flow and control
logic of UMAM. Diagram 1 and diagram 2 depict the main
flow for coroutine PAC and coroutine USFM. The boxes
marked 14i, 15i and 24i are further described through
the subsequent diagrams.
HIPO DIAGRAMS
(36 pages)
4.2.1.4 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
The data used by this subpackage consists of the D̲elivery
S̲tatus F̲ile (DSF) and the O̲utgoing M̲essage S̲tatus F̲ile
(OMSF). An overview of the memory resident data is
shown in figure 4.2.1.4-1.
4.2.1.4.1 D̲S̲F̲
The DSF contains an area for each of the 32 VDUs and
two identical file directories (ref. figure 4.2.1.4-2).
The reason for having two identical file directories
on disk is to ensure that there will always be a directory
which is easy to update in case of recovery.
The contents of the file directory are shown in figure
4.2.1.4-3.
The terminal data area consists of two types of record.
The contents of these records are shown in figure 4.2.1.4-4.
Fig. 4.2.1.4-1 UMAM Data Overview
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
File Directory no. 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 K File Directory no. 2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
20 K Terminal no. 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
20 K Terminal no. 2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
20 K Terminal no. 31
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
20 K Terminal no. 32
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Figure 4.2.1.4-2 Contents of the Delivery Status File
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 byte File directory identification
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
6 byte Time for last storage of directory
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
6 byte Time for last clear of DSF
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte Count
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte No. of records terminal no. 1
2 byte No. of records terminal no. 2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte No. of records terminal no. 31
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte No. of records terminal no. 32
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Fig. 4.2.1.4-3 Contents of File Directory for the DSF
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 byte Type
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte Time stamp (minutes since 00.00)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte Item reference identity
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte From PLA (reference number)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
3 byte DTG (minutes since 1st January)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Record Layout Type I,L (ref. CPS/230/ICD/0001
section 3.13)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 byte Type
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte Time stamp
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte Item reference identity
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
3 byte SCD
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Record Layout Type C,A (ref. CPS/230/ICD/0001
section 3.13)
Figure 4.2.1.4-4 Record Layout for DSF
4.2.1.4.2 O̲M̲S̲F̲
The OMSF consists of an area for each of the 32 VDUs,
two identical file directories, a release table and
an overflow area (ref. figure 4.2.1.4-5).
The reason for having two identical file directories
on disk is to ensure that there will always be a directory
which is easy to update in case of recovery.
The contents of the file directory are shown in figure
4.2.1.4-6.
The release table is used when a release message status
shall be extracted from the outgoing message status.
The release table contains information about the terminals
which are/have been associated with a given release
terminal. The contents of the release table are shown
in figure 4.2.1.4-7.
The data area consists of two types of records. The
contents of these records are shown in figure 4.2.1.4-7.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
File directory no. 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 K File directory no. 2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 K Terminal no. 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 K Terminal no. 2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 K Terminal no. 31
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 K Terminal no. 32
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
X K Free Area
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Figure 4.2.1.4-5 Contents of the Outgoing Message Status File
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte File directory identification
1 byte Count
6 byte Time for last storage of directory
6 byte Time for last periodic status
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte Pointer to free area
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte No. of records
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 byte No. of release records in this area Terminal
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ no.
1
1 byte No. of other records in this area
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte Pointer to free area
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
4 byte Release table
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Terminal
no.
32
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Figure 4.2.1.4-6 Contents of File Directory for the OMSF
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 byte Type
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte Time stamp (minutes since 00.00)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte Item reference identify
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
3 byte SCD
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
(1) byte SSN
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte Item reference identify
(release notification)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte Identification of release terminal
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Record layout types release, not released and deferred
for release.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 byte Type
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 byte Item reference identify
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
3 byte SCD
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Record layout type comment, deleted
Figure 4.2.1.4-7 Record Layout for OMSF
4.2.1.5 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The UMAM subpackage interfaces with the RETR and the
UFCO subpackages. UFCO will send QELs to the PREP queue
and QEL buffers to the REQUEST queue. RETR will send
QEL buffer to the answer queue.
4.2.1.5.1 P̲R̲E̲P̲ ̲Q̲u̲e̲u̲e̲ ̲U̲p̲d̲a̲t̲i̲n̲g̲
UFCO will insert status direct into the PREP queue
by sending a QEL to the queue.
The contents of the QEL information field are:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
S
A STATUS
R CODE SCD 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SCD 2 SCD 3
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SCD: The SCD of the originator.
SAR: Storage flag.
STATUS CODE:
Code indicating the message state:
1. sent for coordination
2. message deferred
3. append completed
4. message suspending
5. message awaiting append
6. sent for release
7. comment suspended
8. comment deferred
9. retrieved for append.
4.2.1.5.2 I̲n̲p̲u̲t̲ ̲t̲o̲ ̲R̲e̲q̲u̲e̲s̲t̲ ̲Q̲u̲e̲u̲e̲
Requests are inserted by UFCO in the request queue
in a buffer. The contents of the buffer are:
a) Delivery Status Updating
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
S STATUS
U CODE SCD 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
PLA ref #
SCD 2 SCD 3
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
TD 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
item ref. id 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
TIME
STAMP
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
DTG
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SU = "1": status updating flag
SCD: the originating SCD
PLA #: the FROM PLA
TD 1: the terminal to which the message was delivered
ITEM REF ID:
the item reference identity of the message
TIME STAMP: the time of presentation
DTG: the DTG of the message.
b) Outgoing / Release Status
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
S STATUS SCD 1
U CODE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SCD 2 SCD 3
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
TD 1 TD 2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
item ref id 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
time stamp
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
item ref id 2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SSN
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
TD 2: release terminal identification
item ref id 2:
the item reference identity of the release
notification.
c) Requests
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
S REQUEST SCD 1
U CODE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SCD 2 SCD 3
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
item ref id
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
time stamp
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SU, = "0"
request code:
1. edit request
2. delete request
3. DIOM
4. DIDS
5. DIRS
d) RETR Subpackage Interfaces
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
S STATUS
U CODE TD 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
item ref id 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SU = "1"
status code: append notification
4.2.2 R̲e̲t̲r̲i̲e̲v̲e̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲
The R̲e̲t̲r̲ieve Subpackage (RETR) is responsible for reception
and treatment of retrieval answer from SAR.
4.2.2.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The functions included in this subpackage are the following:
- reception of off-line/on-line notification
- reception of retrieved items
The functional breakdown is shown in figure 4.2.2.1-1.
Retrieved items and off-line/on-line notifications
are received from SAR in the retrieve queue. After
analysis, the received item is sent to the destination.
Figure 4.2.2.1-1
4.2.2.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The retrieve subpackage consists of one coroutine.
The software structure of RETR is shown in figure 4.2.2.2-1.
RETR will wait on reception of a QEL in the Retrieve
Queue. The QEL will identify one of the following events:
- on-line/off-line notification
- on-line retrieval
- on-line append
- off-line retrieval
- off-line append.
Each of the events will constitute a main function
and is implemented as a procedure. A brief description
of each procedure is given below:
a) On-line/Off-line Append:
The received buffer is sent to UFCO.
b) On-line Retrieval:
The received item is sent to UFCO.
c) On-line Append:
The received item is sent to UFCO.
d) Off-line Retrieval:
The received item is sent to the Response Queue.
e) Off-line Append:
The received item is sent to the PREP queue and
an append notification is sent to UMAM.
Figure 4.2.2.2-1 RETR Software Structure
4.2.2.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
The HIPO diagrams overleaf show the data flow and control
logic of RETR.
HIPO Diagrams (3 pages)
4.2.2.4 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
The data used by RETR consists of a small buffer area
in which data is received from SAR and signalled to
semaphore S2.
4.2.2.5 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
No data are received by the RETR subpackage.
4.2.3 D̲i̲a̲l̲o̲g̲u̲e̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲
The V̲DU D̲i̲a̲logue (VDIA) subpackage has the responsibility
for input of formats from the VDU and output of formats
to the VDU. Furthermore, VDIA performs the validation
of data entered in the VDU format area.
4.2.3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The following functions are included in this subpackage
(ref. figures 4.2.3.1-1 to 5):
- input of data
- validation of data
- display of error codes
- output of data
- insert/delete lines.
4.2.3.1.1 I̲n̲p̲u̲t̲ ̲o̲f̲ ̲D̲a̲t̲a̲
When commanded by UFCO, VDIA will input data from the
VDU via the format handler. A command telling which
format to be input from and a reference to the CIF
where the data shall be stored are received via semaphore
S3.
VDIA will then ask the format handler to transfer data
from the VDU to main memory.
Upon completion, VDIA will go through the field list
and buffer list and store the received data in the
referenced CIF. The data will be stored in the internal
message format (IMF). If input data are from a request
format, then the data will be put into a buffer. The
procedure will be repeated until all data are transferred
from the VDU.
If before a completion code is received from the format
handler, a stop input command is received from UFCO
via semaphore S3, then the system call monitor function
CANCEL will be called. Upon reception of a completion
code, VDIA will clear local memory and send a clear
VDU command to the format handler. Thereafter, VDIA
will return the referenced CIF, if any, and a completion
code to UFCO via semaphore S2
Fig. 4.2.3.1-1
Fig. 4.2.3.1-2
Fig. 4.2.3.1-3
Fig. 4.2.3.1-4
Fig. 4.2.3.1-5
Fig. 4.2.3.1-6
Fig. 4.2.3.1-7
4.2.3.1.2 V̲a̲l̲i̲d̲a̲t̲e̲ ̲D̲a̲t̲a̲
The validation performed by VDIA can be grouped in
the following events:
- validation of messages/comments
- validation of requests
- display of error codes.
4.2.3.1.2.1 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Validation of input will only be performed when commanded
by UFCO, i.e. a user can use the suspend key under
preparation of a message header.
a) Syntax of Messages
In figure 4.2.3.1-8, the message format fields
are listed. The fields which are validated by VDIA
are marked with an "X". The fields whicha are marked
with an "M" are mandatory and the check that they
are present will be performed by I/O control Software.
Furthermore, the syntax of the format fields when
validated is shown in figure 4.2.3.1-8.
Fig. 4.2.3.1-8
Fields Validated in format A, C1, M and their syntax
b) Semantic Validation
The semantic and logical validation on each message
input field performed by VDIA are described below:
Classification: Classification Active terminal
profile. classification.
Special Handling 1) Special handling i̲n̲ Active
terminal profile special
handling.
2) If (classification = UU
a̲n̲d̲ special handling) then
special handling = national
eyes.
For national: If special handling - EE then
nation identification is present.
Message handling: Z-code or Q-code is checked
for existence through table
look up.
Precedence action: None.
Precedence info: If present, then precedence
(info) precedence (action).
Coordination: 1) Redundant SCDs are deleted.
2) If special handling i̲n̲
(crypto security, national
eyes, exclusive) then no
coordination SCDs.
3) SCDs are checked for existence
through table look up.
Originator Id: None.
Originator SCD: SCD i̲n̲ Active terminal profile.
Local distribution: 1) Redundant SCDs are deleted.
2) If special handling i̲n̲
(crypto security, national
eyes, exclusive) then no
local distribution SCDs.
3) If local distribution required
(i.e. at least one SCD
present) then precedence
info is present.
4) SCDs are checked for existence
through table look up.
From PLA: PLA is checked for existence
through table look up.
To action / info: 1) Redundant AIGs and AGs
are deleted.
2) AIGs and AGs are checked
for existence through table
look up.
3) Redundant PLAs are deleted.
4) PLAs are checked for existence
through table look up.
5) PLAs included in specified
AIGs are deleted.
6) At least one address is
present.
7) If info addresses then
info precedence is present.
8) X-PLAs are not validated.
Exempt 1) Redundant PLAs are deleted.
2) PLAs are included in action
or info AIGs/AGs.
3) The number of PLAs and
PLAs extracted from AIGs/AGs
and exempt PLAs are less
than 250.
SIC: 1) Redundant SICs are deleted.
2) SICs are checked for existence
through table look up.
3) SIC = SVC.
EXER/OPER/ If OPER/ then check if the
user has OPER/ capability.
Internal handling: None.
Subject: None.
Text: None.
For mandatory fields on which no semantic validations
are performed, the following rule applies:
- At least one character = "space" must be entered.
When the user has entered the message header and text,
one of the comments below must be entered:
- COORDINATE: Coordination SCDs must be specified.
- RELEASE: None.
- DEFER: None.
- APPEND: Refer 4.2.3.1.2.3.
4.2.3.1.2.2 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲C̲o̲m̲m̲e̲n̲t̲s̲
Validation of input will only be performed when commanded
by UFCO, i.e. a user can use the suspend key under
preparation of a message header.
Fig. 4.2.3.1-9
Fields Validated in Formats G1, G3 and their Syntax
a) Syntax of Comments
In figure 4.2.3.1-9, the comment format fields
are listed. The fields which are validated by VDIA
are marked with an "X". The fields which are marked
with an "M" are mandatory and the check of presence
will be performed by I/O Control Software. Furthermore,
the syntax of the format fields when validated
is shown in figure 4.2.3.1-9.
b) Semantic Validation
The semantic and logical validations on each command
input field performed by VDIA are described below:
Classification: Classification Active terminal
profile. classification.
Special handling: 1) Special handling n̲o̲t̲
̲i̲n̲ (crypto security,
exclusive, national eyes).
2) Special handling i̲n̲ Active
terminal profile. special
handling.
Precedence action: None.
Originator id: None.
Originator SCD: SCD i̲n̲ Active terminal profile.
Local distribution: 1) Redundant SCDs are deleted.
2) SCDs are checked for
existence through table
look up.
Text: None.
For mandatory fields in which no semantic validations
are performed, the following rule applies:
- At least one character = "space" must be entered.
When the user has entered the message header and text,
one of the commands below must be entered:
SEND: None.
OFFER: None.
4.2.3.1.2.3 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲R̲e̲q̲u̲e̲s̲t̲s̲
Below is described the validation of requests inserted
in the format area:
a) Retrieval/Append
The logical validation of the input fields in the
retrieval formats will ensure that the retrieval
keys sent to SAR will be one of those depicted
in figure 4.2.3.1-10.
The semantic and syntax validation in each format
input field performed by VDIA are listed below:
TOC : Year: 00-99
Month: First three letters of month
Zone suffix: Z
Day: 1) If month i̲n̲ (apr, jun, sep,
nov) then day max. 30.
2) If month i̲n̲ (jan, mar, may,
jul, aug, oct, dec) then
day max. 31.
3) If (month = feb a̲n̲d̲ leap
year) then day max. 29.
4) If (month = feb a̲n̲d̲ ̲n̲o̲t̲ leap
year) then day max. 28.
Hour: 00-24
Minute: 1) 00-59
2) If hour = 24, then minute
= 00.
TOC Real Time.
Figure 4.2.3.2.1-10
TOC Window: 1) max. 6 hours
2) (TOC + TOC window) Real
time
Then reference id: 00000 - 65535
DTG: Zone suffix: Z
Month: First 3 letters of month
Day: Ref. TOC
PLA: PLA checked for existence through table
look up and converted to PLA reference
number.
SCD: SCD i̲n̲ Active terminal profile.
b) Deletion
The deletion format consists of the following input
fields:
- Item reference id
- TOC
- SCD
The validation of these fields are as described
in ref. 4.2.3.1.2.3.a.
c) Release
The release format consists of the following input
fields:
- release code
- SCD
The validation performed on each of these input
fields is:
Release code: REL, NO, DEF
SCD: SCD i̲n̲ active terminal profile.
d) Continue Preparation
The continue preparation formats (CTMP, CTCP) consist
of one entry field:
- item reference id.
It is checked that the item reference id is in
the range 00000 - 65535.
e) Predefined Messages
The prepare predefined message format (PRPM) consists
of one entry field:
- message type.
It is checked that the message type is in the range
M001 - M200.
4.2.3.1.2.3.4 D̲i̲s̲p̲l̲a̲y̲ ̲o̲f̲ ̲E̲r̲r̲o̲r̲ ̲C̲o̲d̲e̲s̲
If, during validation of a format, errors are found,
then an error code is stored in an error list together
with an identification of the field in which the error
was found. After validation, the error list is sent
to the VDU via the format handler. These error codes
will be displayed in the left hand margin. Furthermore,
the fields in error will be highlighted.
4.2.3.1.3 O̲u̲t̲p̲u̲t̲ ̲o̲f̲ ̲D̲a̲t̲a̲
When demanded by UFCO, VDIA will output data to the
VDU via the format handler. A command is received via
semaphore S3 telling which format is to be displayed.
If an empty format shall be displayed, then VDIA will
demand that the format handler outputs the requested
format.
If a message shall be displayed, then VDIA will demand
the format handler to output the requested format.
VDIA will then transfer the referenced message from
disk to memory and build up a field list and a buffer
list. Then the format handler will be asked to transfer
the data to the VDU. This procedure will be repeated
until all data are transferred to the VDU.
If, before a completion code is received from the format
handler, a stop output command is received from UFCO
via semaphore S3, then the System Call Monitor function
CANCEL will be called. Upon receipt of the completion
code, VDIA will clear local memory and send a clear
VDU command to the format handler. Thereby VDIA will
return the referenced CIF and a completion code to
UFCO via semaphore S2.
4.2.3.1.4 I̲n̲s̲e̲r̲t̲/̲D̲e̲l̲e̲t̲e̲ ̲L̲i̲n̲e̲s̲
The specified number of lines is inserted/deleted from
the format.
4.2.3.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The dialogue subpackage consists of one coroutine with
semaphore S3 as the main waiting point. The software
structure of VDIA is shown in figure 4.2.3.2-1.
The input from S3 will either be a command from UFCO
or a completion code from the format handler.
Each command will constitute a main function and is
implemented as a procedure. The commands are:
- input messages
- input requests
- output formats
- output data
- insert/delete lines.
Furthermore, there are some procedures in existence
which are called by the main functions. These procedures
are:
- validate messages
- validate requests
- display error codes
- stop input/output.
A brief description of each procedure is given below:
Figure 4.2.3.2-1 VDIA Software Structure
a) Input Messages
The format fields are read from the VDU and stored
in a CIF.
b) Input Requests
The format fields are read from the VDU and placed
in a buffer.
c) Output Formats
Outputs an empty format to the VDU.
d) Output Data
Outputs a message to the VDU.
e) Insert/Delete Lines
A specified number of lines are deleted/inserted
in a format.
f) Validate Messages
Performs syntax and semantic validation of messages.
g) Validate Requests
Performs syntax and semantic validation of requests.
h) Display Error Codes
Outputs error codes and highlights fields in error.
i) Stop Input/Output
Stop input/output, clear VDU and clear local memory.
4.2.3.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
The HIPO diagrams overleaf show the data flow and control
logic of VDIA. Diagram 1 depicts the main flow for
coroutine VDIA. The box marked 13i is further described
through the following diagrams.
HIPO Diagrams (17 pages)
4.2.3.4 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
The data used by VDIA are shown in figure 4.2.3.4-1.
The format file directory contains pointers to the
format descriptors.
The format descriptor area contains a description of
the current format.
The validation data area contains a validation table.
The buffer area is used as internal working area.
Figure 4.2.3.4-1 VDIA Data Overview
4.2.3.5 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The VDIA subpackage interfaces with UFCO via semaphore
S3.
The data received are:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
V FORMAT FORMAT
COMMAND F TYPE COMMAND …0e…0…0f… TYPE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
QEL REFERENCE NO. OF LINES
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SERIAL NUMBER
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ CURSOR
POSITION
TIME STAMP ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
COMMAND: INPUT MESSAGE INSERT LINES
INPUT REQUEST DELETE LINES
OUTPUT FORMAT
OUTPUT DATA
CANCEL S/O
VF = 1: VALIDATION
QEL REF: CIF REFERENCE
4.2.4 V̲D̲U̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲
The V̲DU C̲o̲ntrol (VCO) subpackage is the controlling
subpackage, controlling the start/stop of the processing
of all the other subpackages.
4.2.4.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The following functions are included in this subpackage:
- TEMCO command execution
- Flash queue monitoring
- Periodic timer events
- Time out events.
Figure 4.2.4.1 presents the functional breakdown.
Figure 4.2.4.1-1
Figure 4.2.4.1-2
Figure 4.2.4.1-3
Figure 4.2.4.1-4
Figure 4.2.4.1-5
4.2.4.1.1 T̲E̲M̲C̲O̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲E̲x̲e̲c̲u̲t̲i̲o̲n̲ ̲(̲1̲.̲0̲
The TEMCO command execution functions are those which
directly involve the SSC PACKAGE.
a) Initialization (1.1)
Executes the functions to be performed after load
of software and which must be executed before normal
operation can be initiated.
An initiation command is sent to UFCO.
b) Start User (1.2)
Executes the functions to be performed after a
Sign-on.
c) Stop User (1.3)
Executes the functions to be performed after a
Sign-off.
d) Block Terminal (1.4)
Executes the functions to be performed after a
block terminal command is received.
e) Close Terminal (1.5)
These functions provide VCO with the capability
to perform an ordered close-down.
f) Resume (1.6)
Executes the function to be performed after a successful
security interrogation.
g) Close Temporarily (1.7)
Executes the functions to be performed during a
security interrogation/warning.
4.2.4.1.2 F̲l̲a̲s̲h̲ ̲Q̲u̲e̲u̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲(̲2̲.̲0̲)̲
These are the functions which must be performed after
reception of a message with flash precedence.
a) Update Flash Queue Length (2.1)
These functions display the length of the flash
queue in the VDU header field.
b) Ring the Bells (2.2)
This function will demand the VDU to ring the bells.
c) Change Field Attributes (2.3)
This function will identify the queue to which
the flash message is sent. The relevant queue field
will be displayed in inverse video.
d) Start Timer (2.4)
This function will send a time out request to the
Timer Monitor.
4.2.4.1.3 P̲e̲r̲i̲o̲d̲i̲c̲ ̲T̲i̲m̲e̲r̲ ̲E̲v̲e̲n̲t̲s̲ ̲(̲3̲.̲0̲)̲
These are the functions which must must be performed
every minute.
a) Get Queue Length (3.1)
The lengths of the VDU queues are counted via the
Queue Monitor.
b) Update VDU Header Queue Length Fields (3.2)
These functions display the lengths of the VDU
queues in the VDU header fields.
c) Update VDU Time Field (3.3)
The time field of the VDU will be updated.
4.2.4.1.4 T̲i̲m̲e̲ ̲O̲u̲t̲ ̲E̲v̲e̲n̲t̲s̲ ̲(̲4̲.̲0̲)̲
Execute the functions to be performed in case of time
out in a flash queue or time out of an ordered close
down.
a) Receive First Message in a Flash Queue (4.1)
The first CIF in a given flash queue is received.
b) Determine Queue Time (4.2)
The period in which the message has been in the
queue is calculated.
c) Send CIF to MDCO (4.3)
This function will send the CIF to MDCO in case
of time out.
d) Close Down (4.4)
This function will send a close down command to
UFCO in case of time out.
4.2.4.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The software structure of subpackage VCO is shown in
figure 4.2.4.2-1.
The VCO subpackage consists of one coroutine with semaphore
S1 as the main waiting point. The input from S1 will
be a command received via the command queue or a completion
code received from UFCO.
Each type of command will constitute a main function
and is implemented as a procedure.
A brief description of each procedure is given below.
Figure 4.2.4.2-1 VCO Software Structure
a) Initialization (1.3.1)
The VCO memory is initalized and an initialization
command is sent to UFCO.
b) Start User (1.3.2)
The VDU header is updated and a start command is
sent to the UFCO. A periodic time request is sent
to Timer Monitor.
c) Stop User / Block Terminal (1.3.3)
Outstanding timer request is cancelled and a stop
command is sent to UFCO.
d) Close-Down (1.3.4)
A time out request is sent to Timer Monitor.
e) Close Temporary (1.3.5)
The close temporary flag is set. Errors concerning
the format handler are neglected.
f) Resume (1.3.6)
The close temporary flag is reset. A resume command
is sent to UFCO.
g) Flash Notification Reception (1.3.7)
A timer out request is sent to Timer Monitor. The
VDU is demanded to ring the bells.
h) Periodic Timer Events (1.3.8)
The VDU header is updated with queue length and
time date group.
i) Flash Queue Time Out (1.3.9)
If a message has been in a flash queue longer than
the allowed period, then the message is sent to
the MDCO.
j) Close Down Time Out (1.4.0)
A stop user command is sent to UFCO.
k) Error Reporting (1.4.1)
An error report is sent to SSC.
4.2.4.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
The flowgrams in table 4.2.4.3 show the control logic
of VCO.
The numbers in parentheses refer to the HIPO diagrams
overleaf.
INIT LOOP
WAIT S1
INITIALIZING COMMAND ? - I̲N̲I̲T̲I̲A̲L̲I̲Z̲A̲T̲I̲O̲N̲ ̲(̲1̲.̲3̲.̲1̲)̲
END INIT
INIT RECEIVE COMMAND QUEUE
ASSOCIATE S1
FOREVER LOOP
WAIT S1
CASE ENTRY OF:
TEMCO COMMAND - TEMCO COMMAND 4.2.4.3-2
FLASH NOTIFICATION - F̲L̲A̲S̲H̲ ̲N̲O̲T̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
̲(̲1̲3̲7̲)̲
PERIODIC TIMER EVENT - P̲E̲R̲I̲O̲D̲I̲C̲ ̲T̲I̲M̲E̲R̲ ̲E̲V̲E̲N̲T̲
̲(̲1̲3̲8̲)̲
TIME OUT FOR FLASH - F̲L̲A̲S̲H̲ ̲Q̲U̲E̲U̲E̲ ̲T̲I̲M̲E̲
̲O̲U̲T̲ ̲(̲1̲3̲9̲)̲
TIME OUT FOR CLOSE DOWN - C̲L̲O̲S̲E̲ ̲D̲O̲W̲N̲ ̲T̲I̲M̲E̲
̲O̲U̲T̲ ̲(̲1̲4̲0̲)̲
ERROR REPORTS - E̲R̲R̲O̲R̲ ̲R̲E̲P̲O̲R̲T̲I̲N̲G̲
̲(̲1̲4̲1̲)̲
END CASE
END FOREVER
Table 4.2.4.3-1 VCO Control Logic
ANALYSE COMMAND
CASE COMMAND OF:
START USER - S̲T̲A̲R̲T̲ ̲U̲S̲E̲R̲ ̲(̲1̲3̲2̲)̲
STOP USER
BLOCK TERMINAL - S̲T̲O̲P̲ ̲U̲S̲E̲R̲ ̲(̲1̲3̲3̲)̲
CLOSE TERMINAL - C̲L̲O̲S̲E̲ ̲D̲O̲W̲N̲ ̲(̲1̲3̲4̲)̲
CLOSE TEMPORARY - C̲L̲O̲S̲E̲ ̲T̲E̲M̲P̲O̲R̲A̲R̲Y̲ ̲(̲1̲3̲5̲)̲
RESUME - R̲E̲S̲U̲M̲E̲ ̲(̲1̲3̲6̲)̲
END CASE
Table 4.2.4.3-2 TEMCO Command Execution
HIPO Diagrams (11 pages)
4.2.4.4 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
An overview of the data area used by VCO is shown in
figure 4.2.4.4-1.
The queue length area contains a 2 byte counter for
each queue (subqueue).
The time area is a buffer which contains a time stamp.
The field list area is used to the format handler interface.
The buffer area is used as internal working area.
Figure 4.2.4.4-3 VDU Data Overview
4.2.4.5 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The VCO subpackage interfaces with UFCO via semaphore
S1.
The data received are:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
F code
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
7 6 0
F: interface type
0: completion code
1: error code
code: error/completion code number.
4.2.5 U̲s̲e̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲
The U̲ser F̲unction C̲ontrol (UFCO) subpackage peforms
the control of all user transactions. Furthermore,
UFCO performs the direct control of the VDU dialogue.
4.2.5.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The following functions are included in this subpackage:
- System control
- Transaction accounting
- Transaction creation
- Format sequence functions.
Figure 4.2.5.1 presents the functional breakdown.
Figure 4.2.5.1-1
Figure 4.2.5.1-2
Figure 4.2.5.1-3
Figure 4.2.5.1-4
Figure 4.2.5.1-5
Figure 4.2.5.1-6
Figure 4.2.5.1-7
Figure 4.2.5.1-8
Figurer 4.2.5.1-9
4.2.5.1.1 S̲y̲s̲t̲e̲m̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲1̲.̲0̲)̲
The system control functions are those which indirectly
involve the SSC package. The commands are received
from VCO.
a) Initialization (1.1)
Executes the function to be performed after load
of software and which must be executed before normal
operation can be initiated. Depending on the type
of initialization, different actions are taken.
An initialization command is sent to VDIA.
b) Start-Up (1.2)
Executes the function to be performed after sign-on.
The command validation table reflecting the user
capability is defined.
c) Close-Down (1.3)
This function provides the UFCO with the capability
of performing the following functions:
- Sign-off
- Block terminal
- Order close-down.
d) Security Interrogation (1.4)
Requests a security interrogation to be performed
in case of release.
Executes the functions to be performed after a
security interrogation (e.g. receive function keys).
e) Error Handling (1.5)
These functions control the error handling, report
errors to VCO and determine whether the processing
shall be stopped or not.
4.2.5.1.2 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲A̲c̲c̲o̲u̲n̲t̲i̲n̲g̲ ̲(̲2̲.̲0̲)̲
The transaction accounting functions are those concerning
log and statistics.
a) Collect Data (2.1)
The data which are used for log, statistics and
other purposes are collected in an accounting area.
There exists no special collecting procedures but
all data which are pertinent for UFCO will be placed
in this area.
b) Log Reporting (2.2)
The log reporting functions are those required
to report final and initial log records. The data
which are required in a log record are extracted
from the accounting area.
c) Statistics Reporting (2.3)
The statistics reporting functions are those required
to report statistics.
The data which are required in the statistics are
extracted from the accounting area.
d) Assign Transaction Designator (2.4) Allocates next
transaction no. for this terminal.
4.2.5.1.3 Transaction Creation (3.0)
The transaction creation group includes all the functions
to be performed before a transaction may be started.
a) Receive and Validate Function Key (3.1)
Function keys entered by a user are received from
the VDU. The received function key is validated
against a function key bit mask.
There are two bit masks.
Bit mask (1) reflects the function keys which are
allowed at the moment.
Bit mask (2) reflects the function keys which will
change the format sequence.
b) Define Next Function Key (3.2)
If a function key must be followed by another,
this is defined (i.e. RETURN shall follow COMMAND).
c) Receive Command Line (3.3)
The contents of the VDU command line are received
via the format handler.
d) Validate Command Line (3.4)
The contents of the command line are validated.
A command is validated against the command validation
table.
Parameters are checked to be within the correct
range.
e) Display Error Code (3.5)
These functions display a response message in the
VDU response line.
f) Execute Function Key
The functions associated with the received function
key are performed and the format sequence is changed.
g) Execute Command (3.7)
The sequence table key is looked up in the command
validation table and the format sequence is started.
4.2.5.1.4 F̲o̲r̲m̲a̲t̲ ̲S̲e̲q̲u̲e̲n̲c̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲ ̲(̲4̲.̲0̲)̲
The format sequence functions are those functions which
are called from the format sequence table.
This table makes it possible to drive the MMI in an
automatic and flexible manner.
It defines for each screen format:
- Allowed commands and function keys
- Functions to be called corresponding to commands/F/C
Keys
- LOG, STATISTICS, SAR reporting required
- Cursor position
- Command to VDIA
4.2.5.1.4.1 S̲t̲a̲r̲t̲ ̲E̲x̲e̲c̲u̲t̲i̲o̲n̲ ̲(̲4̲.̲1̲)̲
The start execution functions are those which must
be performed before a format is presented for a user.
a) Create CIF /Buffer (4.1.1)
These functions are those used to interface to
the message management system.
b) Request CIF (4.1.2)
If a continue preparation command is received,
then the referenced CIF is fetched from the preparation
database.
If a receive command is received, then the first
CIF in the corresponding queue is fetched.
c) Update VDU Header (4.1.3)
These functions update the VDU header fields, classification
and terminal function.
d) Complete Append (4.1.4)
These functions add a section of another message
to a message under preparation.
It shall be noticed that an off-line append can
result in two security interrogations.
e) Display Error Code (4.1.5)
These functions display a response message in the
VDU response line.
f) Determine Message Type (4.1.6)
These functions determine the format which shall
be used for a message.
g) Clear Accounting Area (4.1.7)
These functions will clear the memory area used
for accounting data.
4.2.5.1.4.2 S̲t̲o̲p̲ ̲E̲x̲e̲c̲u̲t̲i̲o̲n̲ ̲(̲4̲.̲2̲)̲
The stop execution functions are those which must be
performed when a user gives up access to a CIF.
a) Dismantle CIF / Buffer (4.2.1)
These functions are those used to interface to
the message management system.
b) Update Status (4.2.2)
The outgoing message status, release message status
and the delivery message status are updated. The
message / comment under preparation is returned
to the preparation database.
c) Clear Working Area (4.2.3)
The memory area which has been used for this transaction
is cleared.
d) Update VDU Header (4.2.4)
These functions update the VDU header fields, classification
and terminal function.
e) Clear Accounting Area (4.2.5)
These functions will clear the memory area used
for accounting data.
4.2.5.1.4.3 Q̲u̲e̲u̲e̲ ̲R̲e̲q̲u̲e̲s̲t̲s̲ ̲(̲4̲.̲3̲)̲
The queue request functions are those concerning the
reception of messages.
a) Receive (4.3.1)
The first CIF to which the requestor has access
is received from a given queue.
b) Delete (4.3.2)
This function removes a CIF from a queue.
c) Keep (4.3.3)
This function returns a CIF to a queue.
d) Keep and Present next (4.3.4)
This function returns a CIF to the queue from which
it was received. The next CIF to which the requestor
has access is returned.
e) Delete and Present next (4.3.5)
This function removes a CIF from the queue from
which it was received. The next CIF to which the
requestor has access is returned.
4.2.5.1.4.4 R̲e̲q̲u̲e̲s̲t̲s̲ ̲t̲o̲ ̲C̲A̲M̲P̲S̲ ̲S̲y̲s̲t̲e̲m̲ ̲(̲4̲.̲4̲)̲
The request functions are those concerning the treatment
of messages (CIFs) and requests (buffers).
a) Send for Coordination (4.4.1)
The message is sent for coordination and the delivery
notification created by MDP is displayed.
b) Send for Release (4.4.2)
The message is sent to the associated release terminal.
c) Release (4.4.3)
The message is sent for local distribution and
transmission. A release notification is returned
to the drafter.
d) Retrieve / Append (4.4.4)
A retrieve request is sent to SAR and the retrieved
CIF and/or a response message is displayed.
e) Print (4.4.5)
The CIF currently displayed on the VDU is sent
to the associated printer.
f) Defer (4.4.6)
The preparation is terminated and the CIF is sent
to the preparation database.
g) Status Request (4.4.7)
A status request is sent to UMAM and the received
CIF is displayed.
h) Send for Distribution (4.4.8)
A comment is sent for locad distribution.
i) Edit / Delete Requests (4.4.9)
A request is sent to UMAM and the referenced CIF
or a response message is displayed.
