top - download
⟦681f195bf⟧ Wang Wps File
Length: 51297 (0xc861)
Types: Wang Wps File
Notes: CPS/SDS/039
Names: »1553A «
Derivation
└─⟦7f5d2b450⟧ Bits:30006107 8" Wang WCS floppy, CR 0170A
└─⟦this⟧ »1553A «
WangText
…1f……00……00……00……00……15……0a……00……00……15……0b……15……0c……15……0f……15……00……15……01……15……07……14……0d……14……02……13……09……13……0a……13……0e……13……0f……13……00……13……01……13… …13……05……12……09……12……0a……12……0c……12……0d……12……0e……12……0f……12……05……12……06……11……0a……11……0b……11……0e……11……0f……11……86…1 …02… …02… …02…
…02…CPS/SDS/039
…02…841101…02……02…
USER VDU
DETAILED DESIGN SPECIFICATION…02…ISSUE 1…02…CAMPS
Fig. 4.1.1.4-2
4.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
In this section the software structure of VUP will
be described. The allocation of functions onto processes
and coroutines will be explained, based on the analysis
performed in section 4.1.1.
Figure 4.1.2-1 shows the mapping of functions onto
processes and coroutines
4.1.2.1. V̲U̲S̲ ̲P̲r̲o̲c̲e̲s̲s̲
The VDU USER PROCESS controls the interaction with
the user VDU, under supervision of TEMCO (SSC software).
It thus has the following responsibilities:
- TEMCO command execution
- Control and execution of user transactions
- User transaction accounting
- Maintaining the VDU Header queue status
- Monitoring of FLASH queues.
Fig. 4.1.2-1
Fig. 4.1.2.1-1 VUS Structure
4.1.2.1.1 V̲U̲S̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲s̲
The VDU USER PROCESS consists of four coroutines:
- the VDU Control Coroutine
- the User Function Control Coroutine
- the VDU Dialogue Coroutine
- the Retrieve Coroutine.
In figure 4.1.2.1-1 an overview of VUS is depicted.
4.1.2.1.1.1 V̲D̲U̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲
The VDU Control (VCO) Coroutine is the controlling
coroutine, controlling the start / stop of the processing
of all the other coroutines.
VCO is responsible for the execution of commands received
from TEMCO, e.g initialize, close down, restart, start/stop,
for VDU Header queue status update and that no message
is kept longer in a Flash precedence queue than allowed
by the supervisor.
During the analysis it was found that TEMCO Control
Functions and Queue Status Maintenance functions were
to be executed with higher priority than User Transaction
Control Functions. Thus these two functions have been
allocated their own coroutine named V̲DU C̲O̲NTROL COROUTINE
(VCO).
The VCO coroutine shall be asssigned the highest priority
among the coroutines of VUS, meaning that whenever
VCO and other VUS coroutines are ready to run, VCO
shall be allowed to run first.
4.1.2.1.1.2 U̲s̲e̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲
The User Function Control (UFCO) Coroutine performs
the direct control of the VDU Dialogue Coroutine.
UFCO performs the user transaction control, which consists
of:
- user transaction execution
- user requested transaction interruption
- user transaction accounting.
The functions of UFCO and VDIA have been assigned separate
coroutines to decrease the complexity of the software.
When a user transaction is in progress, UFCO software
shall only take care of transaction interruption while
all formatting and I/O transfer initiation / awaiting
is performed by VDIA. UFCO is assigned a higher priority
than VDIA.
4.1.2.1.1.3 V̲D̲U̲ ̲D̲i̲a̲l̲o̲g̲u̲e̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲
The VDU dialogue (VDIA) coroutine is responsible for
the VDU format transformation of input and output and
for validation of user input.
4.1.2.1.1.4 R̲e̲t̲r̲i̲e̲v̲e̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲
The Retrieve (RETR) Coroutine is responsible for reception
and treatment of retrieval answers from SAR.
The functions of RETR have been assigned to a separate
coroutine, due to the fact that the function may be
performed even when the other coroutines have been
stopped after user sign-off. Furthermore, the function
of the RETR may be considered as low priority tasks,
having in mind that during on-line retrieval all the
other coroutines associated with user transaction processing
(UFCO, VDIA) will await input from RETR, thereby allowing
RETR to be processing. RETR is assigned the lowest
priority within VUS.
4.1.2.1.2 U̲s̲e̲r̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲ ̲U̲S̲P̲R̲
The USPR subpackage is a set of procedures, which is
able to convert specific types of data from external
(shown on the VDU) to internal (stored in CIF's or
memory records) representation and vise versa.
The USPR is divided into three different parts, namely:
D̲i̲s̲p̲l̲a̲y̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
Converts from internal representation to a string which
can be displayed in a field on the VDU. This kind of
procedures works on single fields.
S̲y̲n̲t̲a̲x̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
Validates the content of a single field on the VDU
and converts it to the internal representative.
S̲e̲m̲a̲n̲t̲i̲c̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
Validates that the contents of different fields in
a format not interfere with each other. Each procedure
validates a whole format.
Because each of the Function COntrol (UFCO, MAFCO,
SVCO) subpackages has its own formats, and because
a procedure is connected to a specific field in a format,
or a specific format the USPR subpackage is rather
related to the FCO than to the VDIA subpackage.
4.1.2.2 U̲M̲A̲M̲ ̲P̲r̲o̲c̲e̲s̲s̲
The UMAM process controls the access to the preparation
database and maintains the Outgoing Message Status,
the Release Status, the Delivery Status and the Service
Message Status for each VDU and printer.
In figure 4.1.2.1-2 an overview of the UMAM process
is shown.
The functions of UMAM have been allocated their own
process for the following reasons:
a) To keep security access control as simple and tight
as possible.
b) To minimize the damage caused by system malfunction.
With reference to the analysis in 4.1.1.4.1 this
means that the solution where the releaser process
queues a request for removing or changing items
is not chosen. Note that due to security, it is
our aim that a user process should not be trusted,
meaning that access rights possessed by an unassigned
user process (no user has signed on) shall be kept
at a minimum.
c) The close relationship between Preparation Database
Access Control and Message / Comment Status Maintenance
has caused both functions to be allocated to the
same process.
d) The allocation of one process to Status Maintenance
gives the designer the freedom to optimize disk-accesses
and to utilize the fact that identical entries
in different status types exist.
e) The centralization of status maintenance and PDB
access control for all VDU processes in one process,
increases the flexibility of the system.
4.1.2.3 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
In the preceding subsections of section 4.1.2, the
processes and coroutines of VUP have been isolated,
and the functions to be performed by these software
components identified.
F̲I̲G̲U̲R̲E̲ ̲4̲.̲1̲.̲2̲.̲1̲-̲2̲…86…1 …02… …02… …02… …02…
The software structure for each component (i.e. coroutine)
will be outlined in the following subsections. The
description of the software structure will mainly be
in the form of software structure charts.
In figure 4.1.2.3-1 an overview of the VUP processes
is shown.
4.1.2.3.1 V̲U̲S̲ ̲I̲N̲I̲T̲I̲A̲L̲I̲Z̲A̲T̲I̲O̲N̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
This subpackage contains the software which initializes
the coroutines and semaphores of the VUS subprocess.
The software structure is shown in figure 4.1.2.3-2.
4.1.2.3.2 V̲C̲O̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
This coroutine receives commands from TEMCO and starts/stops
UFCO accordingly.
Furthermore the periodic updating of the VDU-header
is performed by VCO.
The software structure of the VDU Control Coroutine
(VCO) is outlined in the structure chart in fig. 4.1.2.3-3.
Fig. 4.1.2.3-1 Software Structure Process Overview.
Fig. 4.1.2.3-2 VUS INITIALIZATION - SOFTWARE STRUCTURE
Fig. 4.1.2.3-3 VCO COROUTINE - SOFTWARE STRUCTURE
4.1.2.3.3 U̲F̲C̲O̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
This coroutine controls input/output to and from the
VDU and the communication with other packages.
It accepts commands from VCO and control VDIA via commands
and process completion reports from VDIA corresponding
to the commands.
It communicates with VCO by sending completion report
corresponding to commands received by VCO.
The control of the MMI is exercised via function key
interrupts received from the VDU, via execution of
commands entered from the VDU and via input / output
commands sent to VDIA.
Fig. 4.1.2.3-4 shows the software structure.
Fig. 4.1.2.3-4 UFCO COROUTINE - SOFTWARE STRUCTURE
4.1.2.3.4 V̲D̲I̲A̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
This coroutine transfers and converts data between
the format area of the VDU and storage in CIF or memory.
The function of VDIA is controlled by operation buffers
send to the activation semaphore, as a response VDIA
returns a completion report by a operation buffer send
to the answer semaphore.
It communicates with the VDU via the Format Handler
of the IOC Package and accesses data in the I̲nternal
M̲essage F̲ormat (IMF) via the Message Monitor of the
CSF Package.
The reading and writing of a format is controlled by
Format Control Program (FCP) which is interpreted by
VDIA.
Fig. 4.1.2.3-5 shows the software structure.
F̲I̲G̲U̲R̲E̲ ̲4̲.̲1̲.̲2̲.̲3̲-̲5̲ ̲V̲D̲I̲A̲ ̲C̲O̲R̲O̲U̲T̲I̲N̲E̲ ̲-̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲S̲T̲R̲U̲C̲T̲U̲R̲E̲
4.1.2.3.5 RE̲T̲R̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
This coroutine receives input from SAR via the Retrieve
Queue and communicates with UFCO.
This communication is done either by RETR sending Online
Retrieval Results direct to UFCO or Off-line Retrieval
Results indirectly via the Response Queue.
The coroutine is implemented in one module.
Fig. 4.1.2.3-6 RETR COROUTINE - SOFTWARE STRUCTURE
4.1.2.3.6 U̲M̲A̲M̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
This processs receives input from other packages in
the Collect and Command Queues.
Figure 4.1.2.3-7 shows the software structure.
Fig. 4.1.2.3-7 UMAM Software Structure
4.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̲
In this section, the data flow between the VUS processes
and coroutines will be described together with the
control logic used to synchronize their execution of
the VUP functions allocated to them.
4.1.3.1 P̲r̲o̲c̲e̲s̲s̲ ̲D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲P̲r̲o̲c̲e̲s̲s̲ ̲S̲y̲n̲c̲h̲r̲o̲n̲i̲z̲a̲t̲i̲o̲n̲
The data flow and process synchronization of the UMAM
process and the VUS incarnations will be described
for the UMAM process and one VUS process, as the flow
and synchronization for all VUS incarnations are identical.
In fig. 4.1.3.1-1 the data flow between UMAM and VUS
is depicted. The flow is shown for the VUS process
possessing full access rights to the CAMPS USER FUNCTIONS.
However, the dataflow for a VUS process possessing
access right to a subset of the CAMPS USER FUNCTIONS
only (i.e. one or more of the subfunctions PREPARATION,
RECEPTION or RELEASE) is indicated as well by means
of the capital letters enclosed in parentheses, which
denote the subfunction to which the flow is associated.
VUS acts as the master(controlling) process and UMAM
is the slave process, i.e. UMAM does not execute any
function before requested by VUS, and while UMAM executes
the requested function, VUS stops its own processing
and awaits the result to be delivered by UMAM in its
answer queue.
Figure 4.1.3.1-1
The different incarnations of VUS do not communicate
with each other in a way requiring synchronization
of their operations. However, they do exchange information
directly (i.e. messages for release and release notifications).
In the following subsections, the data flow and control
logic internal to UMAM and VUS, i.e. between their
coroutines, are described.
4.1.3.2 V̲U̲S̲ ̲I̲n̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲ ̲S̲y̲n̲c̲h̲r̲o̲n̲i̲z̲a̲t̲i̲o̲n̲
The data flow internal to VUS is depicted in fig. 4.1.3.2-1.
The command parameters listed with the arrows 3 and
6 are identical, but those associated with arrow 3
are unformatted while those associated with arrow 6
are input via a format, refer section 4.1.1.3.4.
In fig. 4.1.3.2-2, an overview of the VUS coroutines
and the operation-semaphores (S1, S2, S3) used for
synchronization is depicted.
Fig. 4.1.3.2-1 Dataflow between VUS Coroutines
L̲e̲g̲e̲n̲d̲ ̲f̲o̲r̲ ̲f̲i̲g̲.̲ ̲4̲.̲1̲.̲3̲.̲2̲-̲1̲ ̲o̲n̲ ̲P̲r̲e̲v̲i̲o̲u̲s̲ ̲P̲a̲g̲e̲
1. Commands from SSC (e.g. start, stop) and time events.
2. Timer initiated update of VDU header (queues, time).
3. Control information from VCO to UFCO.
4. Commands / parameters and function keys.
5. Transaction ID, classification, error messages.
6. Messages and system update requests.
7. Validated / unvalidated messages and system information.
8. Retrieved messages.
9. Off-line retrieval results are sent to the response
queue.
10. Retrieve finished signal to UFCO and on-line retrieval
results.
11. Answers to requests and retrieved messages.
Fig. 4.1.3.2-2 VUS Coroutine Synchronization Overview
VCO receives its input from S1. VCO is the coroutine
which controls the activities of all the others through
its control of UFCO. VCO starts and stops UFCO by executing
a send operation on S2 with the proper command. When
UFCO has executed a command sent by VCO, UFCO notifies
VCO by performing a send operation on S1 with the relevant
Command Completion code.
UFCO receives its input from S2. UFCO controls the
activities of VDIA through S3. The control logic is
analogous to that described above for VCO control of
UFCO.
On the basis of the UFCO Software Structure (ref. section
4.1.2.3.2) the control logic for UFCO can be constructed
in the same way as done for VCO.
VDIA receives its input from S3. As the main work load
due to I/O transfers and validation of messages / comments
of the VUS process is actually performed by VDIA, a
way to interrupt VDIA function execution within a reasonable
time has to be considered. This means that VDIA shall
return to its waiting point frequently enough to fulfil
the requirements for being controlable by UFCO.
RETR receives input from the retrieve queue only, thus
its control structure will be to await items to be
inserted and process the occurred events.
Further, two pure synchronization semaphores exist
(not depicted):
- a split semaphore to ensure that VCO & UFCO do
not perform I/O on the header split simultaneously
- a retrieval semaphore to ensure that UFCO - in
some off-line situations - gets running before
RETR.
4.1.3.3 U̲M̲A̲M̲ ̲I̲n̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲
UMAM receives input in the Command and Collect queues,
thus the control structure will be to await item to
be inserted and process the occured events.
In figure 4.1.3.3-1 an overview of the UMAM process
is depicted.
As UMAM is a process without coroutines, then no internal
synchronization is required.
4.1.3.4 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲E̲x̲a̲m̲p̲l̲e̲
Below is given a typical example of a complete transaction,
as seen from UFCO's point of view. The considered example
is continued comment preparation (CTCP).
The inital conditions are as follows:
- user-menu displayed at VDU
- UFCO waits at semaphore S2 in module UFCO ̲MAIN
- VDIA waits at semaphore S3.
1. Operator keys function-key F1 (command), causing..
2. UFCO leaves S2 and enters module FC ̲KEY ̲PROC, noting
that a fc-key now is pending (i.e. return).
3. After exit from module FC ̲KEY ̲PROC, UFCO waits
at S2.
4. Operator keys CTCP,1, followed by fc-key enter,
causing ...
5. UFCO exits S2 and enters module FC ̲KEY ̲PROC. A
fc-key was pending, meaning that module FC ̲KEY
̲PROC*VUS ̲CMD ̲PEND is entered.
The latter validates the entered command - succesfully
in this case - causing module FC ̲KEY ̲PROC*VUS ̲CMD
̲PEND*VUS ̲SEQUENCE to be entered.
Table-entry (keys)=(format, code)=(CTCP, input
̲ok) is executed, i.e. request to UMAN is issued.
When done ...
6. UFCO waits at S2, while UNAM searches the preparation-database.
Eventually, the reply from UMAM arrives. This event
causes ...
7. UFCO enters module ANQ ̲PROC. If reply is acceptable,
module ANQ ̲PROC*VUS ̲SEQUENCE is entered and table-entry
(CTCP, ANQ ̲CONT) is executed, i.e. a new CIF-version
(named OUTPUT ̲CIF), of cif received from umam (named
INPUT ̲CIF), is created.
Initial log-report is generated.Transaction-number
is drawn. Further, an output-data command is issued
to VDIA. Note that next table-entry will have (format,
code) = (G3, ?).
8. UFCO waits at S2 in UFCO ̲MAIN. When completion-code
from arrives from VDIA ...
9. UFCO enters module VDIA ̲CC ̲PROC, i.e. enables vdu-keyboard
and sets cursor in format-split.
10. Header format of the comment is now displayed and
operator may enter corrections. Both UFCO and VDIA
waits at their main waiting-points (S2 and S3,
respectively).
11. Operator keys fc-key enter.
12. UFCO enters module FC ̲KEY ̲PROC. As no fc-keys are
pending, module FC ̲KEY ̲PROC*VUS ̲SEQUENCE is entered.
Table-entry (G3, enter) is executed, i.e. an input-data
command is issued to VDIA. Input-target is OUTPUT
̲CIF.
13. UFCO waits at S2 for completion from VDIA. Assuming
VDIA validates the input'd data as ok ...
14. UFCO enters module VDIA ̲CC ̲PROC*VUS ̲SEQUENCE. Table-entry
(G3, input ̲ok) is executed, i.e. the text of INPUT
̲CIF is copied to OUTPUT ̲CIF (new header, old text).
OUTPUT ̲CIF is renamed to INPUT ̲CIF. A new view
of OUTPUT ̲CIF (also named OUTPUT ̲CIF) is created.
Status quo: INPUT ̲CIF (new header, old text) is
saved, OUTPUT ̲CIF (empty header, empty
text) is input-target.
Finally and output-date command is issued to VDIA.
Next table-entry will be (G3 ̲2, ?).
15. UFCO waits at S2. When VDIA has displayed text
(of INPUT ̲CIF) and replied...
16. UFCO enters module VDIA ̲CC ̲PROC, enabling vdu-keyboard
and setting cursor in format-split.
17. Text is displayed. UFCO and VDIA waits at S2 and
S3, respectively.
Operator may alter text. Eventually fc-key enter
is depressed, causing ...
18. UFCO enters module FC ̲KEY ̲PROC*VUS ̲SEQUENCE. Table-entry
(G3 ̲2, enter) is executed, i.e. and input-data
command is issued to VDIA.
Provided that validation is ok, VDIA now inputs
new-header (kept in memory-buffer) and new text
(from vdu) to empty OUTPUT ̲CIF.
19. UFCO waits at S2. When reply from vdia arrives
...
20. UFCO enters VDIA ̲CC ̲PROC*VUS ̲SEQUENCE. Table-entry
is (G3 ̲2, input ̲ok), i.e. OUTPUT ̲CIF is saved,
INPUT ̲CIF dismantled. An output ̲format command
is issued to VDIA. Next table-entry will be (G3
̲3, ?).
21. UFCO waits at S2, when VDIA has output'd decision-format
and signalled reply to S2...
22. UFCO enters module VDIA ̲CC ̲PROC, enabling keyboard
and setting cursor in format-split. UFCO waits
at S2 until ...
23. Operator enters decision defer then fc-key enter
.
24. UFCO enters module FC ̲KEY ̲PROC*VUS ̲SEUENCE. Table-entry
(G3 ̲3, enter) leads to vdia ̲command input ̲data.
25. UFCO waits at S2. When VDIA signals reply ...
26. UFCO enters VDIA ̲CC ̲PROC*VUS ̲SEQUENCE. Table-entry
(G3 ̲3, defer) is executed, i.e. final log-report
is generated, OUTPUT ̲CIF is send to UMAN (for storage
in preparation database) then dismantled. VDIA
command is display ̲menu.
27. UFCO waits at S2. Transaction is ended.
F̲I̲G̲U̲R̲E̲ ̲4̲.̲1̲.̲3̲.̲3̲-̲1̲
4.1.4 C̲o̲m̲m̲o̲n̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
4.1.4.1 V̲U̲S̲ ̲C̲O̲M̲M̲O̲N̲ ̲D̲A̲T̲A̲
a) D̲A̲T̲A̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲ Refer sourcelisting for
prefixes used.
b) V̲U̲S̲ ̲C̲O̲M̲M̲O̲N̲ ̲T̲Y̲P̲E̲S̲ Refer sourcelistings.
c) V̲U̲S̲ ̲C̲O̲M̲M̲O̲N̲ ̲C̲O̲N̲S̲T̲A̲N̲T̲S̲
Q̲U̲E̲U̲E̲ ̲N̲A̲M̲E̲S̲
Refer source listings
d) V̲U̲S̲ ̲C̲O̲M̲M̲O̲N̲ ̲V̲A̲R̲I̲A̲B̲L̲E̲S̲
Refer source listings
4.1.5 C̲o̲m̲m̲o̲n̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
4.1.5.1 T̲E̲P̲ ̲Q̲U̲E̲U̲E̲ ̲E̲R̲R̲O̲R̲
4.1.5.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 purpose of this procedure is to report queue errors
to the SSC. The referenced CIF will be set to NIL.
4.1.5.1.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) TEP ̲QUEUE ̲ERR(USER ̲ACTION: USER ̲ACTION ̲TYPE,
QEL: QEL ̲REFERENCE)
b) TEP ̲QUEUE ̲ERR(R1, R3, R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R1 USER ̲ACTION DEST
R3 pointer to QEL DEST
R6 LINK DEST
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None
R0-R7 DEST
4.1.5.1.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
Refer source listing for prefixes used.
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
TEP ̲ERROR (m) refer 4.1.4
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
Refer source listing.
4.1.5.1.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
This procedure reports queue errors to the SSC by calling
the SEND ̲GARBLE-procedure. The QEL will be set to NIL.
4.1.5.2 T̲E̲P̲ ̲I̲N̲T̲E̲R̲N̲A̲L̲ ̲E̲R̲R̲O̲R̲
4.1.5.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 purpose of this procedure is to report internal
errors to the SSC.
4.1.5.2.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) TEP ̲INT ̲ERR (USER ̲ACTION ̲ USER ̲ACTION ̲TYPE,
IDENTIFICATION: 4 INTEGERS)
b) TEP ̲INT ̲ERR (R1, R2, R3, R4, R5, R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R1 USER ̲ACTION DEST
R2 SUBPACKAGE ID DEST
R3 MODULE ID DEST
R4 PROCEDURE ID DEST
R5 Call ID DEST
R6 LINK DEST
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None
R0-R7 DEST
4.1.5.2.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
Refer source listing for prefixes used.
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
TEP ̲ERROR (m) refer 4.1.4
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
Refer source listing.
4.1.5.2.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
This procedure reports internal errors to the SSC by
calling the SEND ̲GARBLE-procedure.
4.1.5.3 T̲E̲P̲ ̲D̲I̲S̲M̲A̲N̲T̲L̲E̲
4.1.5.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 purpose of this procedure is to dismantle an object
referenced by a QEL.
If the object is of type view, it will be checkpointed
and/or closed as specified.
4.1.5.3.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) TEP ̲DISMANTLE (QEL: QEL ̲REFERENCE
CP ̲STATUS: BOOLEAN,
OBJECT: OBJECT ̲TYPE,
CLOSE: NO ̲YES)
b) TEP ̲DISMANTLE (R2, R3, R4, R5, R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R2 pointer to QEL (Dest.)
R3 CP ̲STATUS (Dest.)
R4 OBJECT (Dest.)
R5 CLOSE (Dest.)
R6 LINK (Dest.)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None
R0 - R7 (Dest.)
4.1.5.3.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
Refer source listing for prefixes used.
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
None
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
Refer source listing.
4.1.5.3.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
Refer figure 4.1.5.3-1
Note: This procedure is called from several coroutines
and contains external waiting-points, hence it must
be re-entrant.
TEP ̲DISMANTLE
QEL EQ NIL?
CASE OBJECT OF OBJECT ̲TYPE
SINGLE,
TIMEOUT DISMANTLE (QEL) (CC): OK
BUFFER? CASE DISMANTLE ̲BUFFER (QEL) (CC):ERROR
OK
ERROR? ANALYZE ̲ERROR (CC,O)
OK ?
END CASE
VIEW? CLOSE EQ TRUE? CASE CLOSE ̲VIEW (QEL) (CC):
ERROR ̲OK
ERROR? ANALYZE
̲ERROR (CC,1
ALREADY
̲CLOSED)
OK?
END CASE
CP EQ FALSE? CASE DISMANTLE ̲VIEW(QEL) (CC):ERROR
̲OK
ERROR? ANALYZE ̲ERROR (CC,0)
OK?
END CASE
CASE SAVE ̲VIEW (DISMANTLE,QEL) (CC,0):ERROR
̲OK
ERROR? ANALYZE ̲ERROR (CC,0)
OK?
END CASE
OTHERWISE? T̲E̲P̲ ̲I̲N̲T̲E̲R̲N̲A̲L̲ ̲E̲R̲R̲O̲R̲ ̲(̲G̲I̲V̲E̲ ̲U̲P̲)̲ ̲(̲4̲.̲1̲.̲5̲.̲2̲)̲
END CASE
Figure 4.1.5.3-1
4.1.5.4 S̲E̲T̲ ̲H̲E̲A̲D̲E̲R̲ ̲T̲X̲T̲
4.1.5.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 purpose of this procedure is to update the VDU
̲HEADER ̲AREA (Terminal txt part) with the HEADER ̲TXT
which is specified by the caller. No I/O is performed.
4.1.5.4.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) SET ̲HEADER ̲TEXT (HEADER ̲TEXT: HEADER ̲TEXT ̲TYPE)
b) SET ̲HEADER ̲TEXT (R0, R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲
R0 HEADER ̲TEXT DEST
R6 LINK DEST
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲
None
R0-R7 DEST
4.1.5.4.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
HEADER ̲TEXT ̲TYPE refer 4.1.4
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
VDU ̲HD ̲AREA (m) refer 4.1.4
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
None
4.1.5.4.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
A text is setup in VDU ̲HD ̲AREA (terminal ̲text ̲field)
in accordance with specified HEADER ̲TEXT ̲TYPE.
4.1.5.5 S̲E̲T̲ ̲H̲E̲A̲D̲E̲R̲ ̲C̲L̲A̲S̲S̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
4.1.5.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 VDU ̲HEADER ̲AREA is updated with the required classification
which can be either CURRENT ̲CLASS or MAX ̲CLASS. No
I/O performed.
4.1.5.5.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) SET ̲HEADER ̲CLASS (REQUIRED ̲CLASS: REQ ̲CLASS ̲TYPE;
CURRENT ̲CLASS: CLASSIFICATION
̲TYPE)
b) SET ̲HEADER ̲CLASS (R0, R1, R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R0 REQUIRED ̲CLASS DEST
R1 CURRENT ̲CLASS DEST
R6 LINK DEST
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None
R0-R7 DEST
4.1.5.5.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲
Refer sourcelisting for prefixes used.
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
VDU ̲HD ̲AREA (m) refer 4.1.4
INIT ̲AREA refer 4.1.4
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
None
4.1.5.6.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
A clarification (in plain language) is setup in output
buffer VDU ̲HD ̲AREA (classification-field).
If MAX ̲CLASS is specified to classification will be
fetched from INIT ̲AREA, otherwise the classification
specified will be used.
4.1.5.6 V̲U̲P̲ ̲C̲O̲N̲V̲E̲R̲T̲I̲O̲N̲
4.1.5.6.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module contains two auxilliary functions
1) INTEGER ̲TO ̲ASCII
Converts integer to the corresponding ASCII-format.
2) ASCII ̲TO ̲INTEGER
Converts an numeric ASCII-string to the corresponding
integer value.
4.1.5.6.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲S̲p̲e̲c̲.̲
a1) INT ̲TO ̲ASCII (2-CHAR ̲STRING)(5-CHAR ̲STRING)
a2) ASCII ̲TO ̲INT (5-CHAR ̲STRING)(2-CHAR ̲STRING)
b1) INT ̲TO ̲ASCII (R1, R2, R3, R4, R5, R6)
b2) ASCII ̲TO ̲INT (R1, R2, R3, R4, R5, R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲r̲t̲i̲o̲n̲s̲
Call registers
1) R1 pointer to input (dest)
R2 byte ̲offset, input
(any value) (dest)
R4 pointer to output (dest)
R5 byte ̲offset, output
(any value) (dest)
R6 link
2) R1 pointer to input (dest)
R2 byte ̲offset, input
(any value (dest)
R4 pointer to output (kept)
R5 byte ̲offset, output
(0 or 1) (dest)
R6 link
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
1) R3 no of bytes outputted
others destroyed
2) R3 no of bytes outputted (2)
others except R4 destroyed.
4.1.5.6.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲s̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
Refer source listing for prefixes used.
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
None
c) Local Data
Refer source listing.
4.1.5.6.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
1) INT ̲TO ̲ASCII
The number is extracted from the source-array and
converted to an internal variable. The needed numbers
of characters (1 or up to 5) are these moved to
the specified destination.
2) The characters, from last to first, are extracted
converted to digits and summed according to weight.
If non-numeric characters are encounted or the
number exceeds 65535 (unsigned), an internal error
is reported.
3) Common feautures:
The caller should have SWELLS layout of byte-arrays
in mind. Both in- & output-pointers are superposed
byte-array with minimum index null.
4.1.5.7 S̲e̲m̲a̲p̲h̲o̲r̲e̲-̲O̲p̲e̲r̲a̲t̲i̲o̲n̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
4.1.5.7.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module manages a pool of semaphore operation.
Two functions are implemented:
1) FETCH ̲SEMAPHORE ̲OERATION
A coroutine-operation is fetched from free set.
Sender ̲id is inserted into returned operation.
2) FREE ̲SEMAPHORE ̲OPERATION
A previously fetched coroutine-operation is returned
to the free set of the pool.
4.1.5.7.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲S̲p̲e̲c̲.̲
a1) FETCH ̲SEMOP (SENDER ̲ID: TEP ̲SENDER ̲ID)
(OPERATION:TEP ̲COROUTINE ̲OP)
a2) FREE ̲SEMOP (OPERATION: TEP ̲COROUTINE ̲OP)
b1) FETCH ̲SEMOP (SENDER ̲ID, R5, R6)
b2) FREE ̲SEMOP (R5, R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲r̲t̲i̲o̲n̲
Call registers
1) R6 link
2) R5 pointer to operation (kept)
R6 link
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
1) R5 pointer to operation
others destroyed
2) all except R5 destroyed.
4.1.5.7.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
Refer source listing for prefixes used.
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
SEMOP refer 4.1.4
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
SEMOP ̲STATE: ARRAY (SEMOP ̲RANGE) of (FREE, OCCUPIED)
The array is initial FREE.
4.1.5.7.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
1) FETCH ̲SEMOP
The state-description of the operation-pool is
scanned. If an FREE operation is found, the state
is changed to OCCUPIED and a pointer to the operation
is returned. If a FREE operation could not be found
an internal error is reported.
2) FREE ̲SEMOP
The pool of operation and the state description
is scanned. If the specified operation is in pool
and marked as OCCUPIED, the state is changed to
FREE. Otherwise an internal error is reported.
4.1.6 G̲l̲o̲b̲a̲l̲ ̲D̲a̲t̲a̲
Global data used by VUP are defined in CPS/DBD/OO1
4.1.7 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
4.1.7.1 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
User Procedures ref. doc. no. CPS/230/ICD/0001.
All VUP subpackages interfaces, this document.
4.1.7.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
4.1.7.2.1 T̲r̲a̲f̲f̲i̲c̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲(̲T̲H̲P̲)̲ ̲I̲/̲F̲
This interface is implemented by the VUS coroutine
UFCO.
For details refer CPS/ICD/009.
4.1.7.2.2 D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲(̲M̲D̲P̲)̲ ̲I̲/̲F̲
This interface is implemented by the VUS coroutine
UFCO.
For details refer CPS/ICD/009.
4.1.7.2.3 S̲t̲o̲r̲a̲g̲e̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲(̲S̲A̲R̲)̲ ̲I̲/̲F̲
This interface is implemented by the VUS coroutines
UFCO (requests queued to SAR) and RETR (reception of
SAR responses).
For details refer CPS/ICD/009.
4.1.7.2.4 L̲o̲g̲ ̲a̲n̲d̲ ̲A̲c̲c̲o̲u̲n̲t̲a̲b̲i̲l̲i̲t̲y̲ ̲(̲L̲O̲G̲)̲ ̲I̲/̲F̲
This interface is implemented by the VUS coroutine
UFCO.
For details refer CPS/ICD/009.
4.1.7.2.5 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲(̲S̲T̲P̲)̲ ̲I̲/̲F̲
This interface is implemented by the VUS coroutine
UFCO.
For details refer CPS/ICD/009.
4.1.7.2.6 S̲S̲C̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲I̲/̲F̲
This interface is implemented by the VUS coroutines
VCO (start / stop function ) and UFCO (security interrogation
request).
For details refer CPS/ICD/009.
4.1.7.2.7 T̲a̲b̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲(̲T̲M̲P̲)̲ ̲I̲/̲F̲
This interface is implemented by the VUS coroutines
UFCO and VDIA.
For details refer CPS/ICD/009.
4.1.7.3 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
4.1.7.3.1 P̲r̲o̲c̲e̲s̲s̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
These are the interfaces between UMAM and VUS:
F̲r̲o̲m̲ ̲V̲U̲S̲ ̲t̲o̲ ̲U̲M̲A̲M̲:
1. Status Requests
2. Edit Requests
3. Delete Requests
4. Access State Changes
5. VDU-PAGE Retrieval
6. Status Records
7. Storage of VDU-PAGES
8. Messages retrieved for append
F̲r̲o̲m̲ ̲U̲M̲A̲M̲ ̲t̲o̲ ̲V̲U̲S̲:
1. Access Key to CIF (QEL ref)
2. Append Notification
3. Message Release Status
4. Outgoing Message Status
5. Delivery Status.
4.1.7.3.2 C̲o̲r̲o̲u̲t̲i̲n̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
1̲.̲ ̲F̲r̲o̲m̲ ̲V̲C̲O̲ ̲t̲o̲ ̲U̲F̲C̲O̲
1. Start UFCO Command
2. Stop UFCO Command
3. Close UFCO Command
4. Block UFCO Command
2̲.̲ ̲F̲r̲o̲m̲ ̲U̲F̲C̲O̲ ̲t̲o̲ ̲V̲C̲O̲
1. Start UFCO CC 2. Stop
UFCO
CC
3. Close UDCO CC
4. Block-UFCO ̲CC
3̲.̲ ̲F̲r̲o̲m̲ ̲U̲F̲C̲O̲ ̲t̲o̲ ̲V̲D̲I̲A̲
1. Display Format CMD
2. Input CMD
3. Output CMD
4. Insert Lines/Group CMD
5. Delete Lines/Group CMD
6. Clear VDU CMD
7. Close Down CMD.
8. Start VDIA CMD
9. Append CMD
10. COPY ̲CIF CMD
11. Suspend
12. Cancel
4̲.̲ ̲F̲r̲o̲m̲ ̲V̲D̲I̲A̲ ̲t̲o̲ ̲U̲F̲C̲O̲
All CMD's mentioned above (UFCO to VDIA) is acknowledged.
5̲.̲ ̲F̲r̲o̲m̲ ̲R̲E̲T̲R̲ ̲t̲o̲ ̲U̲F̲C̲O̲
1. SAR on-line retrieval notification
2. SAR off-line retrieval notification
3. On-line retrieval result
4. On-line append result
5. On-line retrieval error
6. Queue error
4.2 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
4.2.1 V̲D̲U̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲(̲V̲C̲O̲)̲
This subpackage is the controlling subpackage within
the package. The control is exercised by issue of commands
and reception of responses.
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 subpackage contains the following functions:
- Initialization
- TEMCO Command Processing
- Flash Item Control
- Timer Event Processing
- VDU Header Control
- UFCO Control
- Error Reporting
Figure 4.2.1.1-1 presents the functional breakdown.
F̲I̲G̲U̲R̲E̲ ̲4̲.̲2̲.̲1̲.̲1̲-̲1̲
4.2.1.1.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲ ̲(̲1̲.̲0̲)̲
a) Initialize VUS Data (1.1)
Performs initialization of data for VUS and VCO.
Handler for FORMAT- and FCP-file are looked up.
b) Initialize splits and FORMAT-handler (1.2)
Performs initialization for the format-handler
and defines the VDU-splits.
4.2.1.1.2 T̲E̲M̲C̲O̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲(̲2̲.̲0̲)̲
a) Process START USER CMD (2.1)
This command is received after a successful SIGN
ON procedure has taken place and VCO takes action
and starts UFCO.
b) Process STOP USER CMD (2.2)
This command is received after SIGN OFF and VCO
takes action and stops UFCO.
c) Process BLOCK TERMINAL CMD (2.3)
This command is received when the terminal has
been blocked (by supervisor or as a result of a
failed SIGN ON procedure or security interrogation)
and VCO informs UFCO.
d) Process CLOSE DOWN CMD (2.4)
This command informs VUS that a system close down
procedure is to take place and VCO informs UFCO.
e) Send Response to TEMCO (2.5)
For each TEMCO command a corresponding command
to UFCO exists and to each UFCO command a corresponding
completion response exists. When VCO has received
the expected completion response from UFCO an acknowledge
to the TEMCO command is sent to TEMCO.
4.2.1.1.3 F̲l̲a̲s̲h̲ ̲I̲t̲e̲m̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲3̲.̲0̲)̲
a) Interpret flash notification (3.1)
Analyses the flash notification to determine the
precedence (superflash or flash) and which queue
the flash item is in (Release - or Receive queue).
b) Request/Cancel Timeout (3.2)
Calls upon the timer monitor functions.
c) Search Flash Queues (3.3)
Searches for flash items in the flashqueues.
d) Send Flash Items to MDCO (3.4)
Sends old flash items to MDCO.
4.2.1.1.4 T̲i̲m̲e̲r̲s̲ ̲E̲v̲e̲n̲t̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲(̲4̲.̲0̲)̲
a) Interpret Timeout (4.1)
Analyses timeout to determine whether it is a flash
timeout request or a periodic timeout.
b) Request Timeout (4.2)
Requests a flash timeout.
4.2.1.1.5 V̲D̲U̲ ̲H̲e̲a̲d̲e̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲5̲.̲0̲)̲
a) Update Date/Time Field (5.1)
Maintains the Date/Time Field in the VDU-header
when a periodic timeout occurs.
b) Update Q-Status Fields (5.2)
Maintains the queue length fields in the VDU-header.
c) Display VDU-Header (5.3)
Updates the VDU-header display.
4.2.1.1.6 U̲F̲C̲O̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲6̲.̲0̲)̲
a) Send CMD to UFCO (6.1)
Controls UFCO by sending commands.
b) Process Command Completion from UFCO (6.2)
Interprets and reacts upon acknowledge from UFCO.
c) Process User Mode Change (6.3)
Monitors information from UFCO about current user
mode (i.e. release, preparation, reception) has
changed.
d) Process Precedence Change (6.4)
Monitors information from UFCO about current precedence.
4.2.1.1.7 E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲ ̲(̲7̲.̲0̲)̲
a) Queue Error Reporting (7.1)
Reports to SSC that an unexpected Queue element
has been received.
b) Internal Error Handling (7.2)
Reports to SSC that an unexpected response has
been received from UFCO or from monitor procedures
called.
4.2.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The software structure is shown on figure 4.2.1.2-1.
VCO consists of one coroutine (refer section 4.2.1.3
for details regarding modules.
F̲I̲G̲U̲R̲E̲ ̲4̲.̲2̲.̲1̲.̲2̲-̲1̲
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̲ ̲w̲i̲t̲h̲i̲n̲ ̲V̲C̲O̲
An overview of the dataflow through VCO is shown on
diagrams 4.2.1.3-1 to 4.
F̲I̲G̲U̲R̲E̲ ̲4̲.̲2̲.̲1̲.̲3̲-̲1̲ ̲-̲ ̲F̲I̲G̲U̲R̲E̲ ̲4̲.̲2̲.̲1̲.̲3̲-̲4
4.2.1.4 V̲C̲O̲ ̲M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
M̲o̲d̲u̲l̲e̲s̲
VCO ̲CONTR Initialization Main Loop
VCO ̲VDU Update Header Display other VDU Access
VCO ̲CMDS Execution of Commands from SSC
VCO ̲FLASH Handling of Flash Item
VCO ̲COM Service Subroutine for Queue Scannity
VCO ̲DATA Data for VCO Subpackage
VCO ̲PREFIX Type Definitions
4.2.1..4.1 V̲C̲O̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.1.4.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̲
Entry Point for VCO. Performs the following Initialization:
- Find FORMATS Directory
- Find FDCB for FCP File
- Set FF ̲HANDLE.FCP ̲FDCB
- Call VCO ̲INIT ̲FH (in VCO ̲VDU)
Afterwards the VCO Main Loop is entered.
The Main Loop receives SSC Commands or FCO Operations
by use of procedure NEXT ̲VCO ̲OPERATION.
4.2.1.4.1.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Export Procedure V̲C̲O̲ ̲C̲O̲N̲T̲R̲O̲L̲
(R5 - - NOT USED
R6) - - NOT USED
4.2.1.4.1.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Procedure N̲E̲X̲T̲ ̲V̲C̲O̲ ̲O̲P̲E̲R̲A̲T̲I̲O̲N̲
(R0 - R result from RECEIVE ̲FIRST ̲QEL
R1 - R MAINTYPE
R2 - R SUBTYPE
R3 - R FLAGS
R4 - R PM ̲TIME.LEAST
R5 - R PM ̲TIME.MOST
R6) C K LINK
QEL R Reference to queue element received
OBJECT R Objecttype for queue element received
CHECK ̲STATUS R CHECK ̲STATUS for queue element received
Receives next element from COMMAND queue and handles
UFCO operations. The UFCO operations sent to semaphore
VUS ̲S1 are handled without returning from the procedure.
4.2.1.4.2 V̲C̲O̲ ̲V̲D̲U̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.1.4.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̲
Export procedure V̲C̲O̲ ̲I̲N̲I̲T̲ ̲F̲H̲
(R4 C K FDCB Index for directory containing
FORMAT file
R6) C K LINK
FORMAT ̲
IFCB - R Updated to found value
HEADER ̲
IFCB - R Updated to found value
FF ̲HANDLE - R FF ̲HANDLER.FORMAT ̲IFCB updated to
found value
Initializes format handler by a call of FH ̲INIT ̲FORMAT
and , for each VDU split, a call of FH ̲DEFINE ̲FORMAT
̲AREA.
Export procedure V̲C̲O̲ ̲I̲N̲I̲T̲ ̲T̲E̲R̲M̲I̲N̲A̲L̲
(R5 C K % USER ̲START ̲ID
R6) C K LINK
Initializes both VDU splits by calls of FH ̲INIT ̲TERMINAL
Export Procedure V̲C̲O̲ ̲S̲T̲A̲R̲T̲ ̲V̲D̲U̲
(R6) C K LINK
VDU ̲STATE - R VDU ̲READY if no FH ̲ERRORS,else VDU
̲FAIL
INVERT ̲
MASK - r Set to 0000
Gets and outputs the header split format by calls of
FH ̲GET ̲FORMAT and FH ̲OUTPUT ̲FORMAT.
Writes terminal text and classification fields with
blank and highest classification.
Gets system time and counter and writes them on the
VDU.
Export procedure V̲C̲O̲ ̲S̲T̲O̲P̲ ̲V̲D̲U̲
(R6) C K LINK
VDU ̲STATE - R Set to VDU ̲REMOVED
Deactivates the VDU by calling FH ̲REMOVED ̲TERMINAL
for both VDU splits. Sets VDU ̲STATE to VDU ̲REMVED.
Export procedure V̲C̲O̲ ̲U̲P̲D̲A̲T̲E̲ ̲V̲D̲U̲ ̲H̲D̲
(R6) C K LINK
VDU ̲
STATE C R Set to VDU ̲FAIL if FH ̲ERROR
Computes values of system time and VCO ̲COUNTERS: If
VDU ̲READY the fields with changed value are output
to the VDU. In case of FH ̲ERROR the variable VDU ̲STATE
is set to VDU ̲FAIL.
Displays RELS or REW counter in inverse video of flash.
Item are in the corresponding queue.
Export procedure V̲C̲O̲ ̲B̲E̲E̲P̲
(R6) C K LINK
VDU ̲
STATE C R Set to VDU ̲ERROR if FH ̲ERROR
Rings the BELL on the VDU if VDL ̲STATE is VDU ̲READY.
VDU ̲STATE is set to VDU ̲ERROR by FH ̲ERROR.
4.2.1.4.2.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Procedure U̲P̲D̲A̲T̲E̲ ̲C̲O̲U̲N̲T̲E̲R̲S̲
(R0 - R CHANGED MASK
R6) C K LINK
COUNTERS C R UPDATED TO NEW VALUES
Computes and stores values for TIME and COUNTERS. If
time or a counter value has changed, the corresponding
bit is set in CHANGED MASK.
Procedure D̲I̲S̲P̲L̲A̲Y̲ ̲C̲O̲U̲N̲T̲E̲R̲S̲
(R0 C K DIAPLAY MASK
R6) C K LINK
VDU ̲
STATE C R Set to VDU ̲FAIL if FH ̲ERROR
INVERT ̲
MASK C R Set as fileds are displayed
If VDU ̲STATE = VDU ̲READY then REVERSE/NORMAL VIDEO
for RELEASE and DISPLAY counters are updated according
to the values of the FLASH priority counters for the
queues. The INVERT MASK is given the present state
of reverse/normal for the fields.
Afterwards the fields specified in DISPLAY MASK are
output to the VDU. In case of FH ̲ERROR the variable
VDU ̲STATE is set to VDU ̲FAIL.
Procedure G̲E̲T̲ ̲F̲I̲E̲L̲D̲ ̲L̲I̲S̲T̲
(R3 C K Header field no. (0, 1, ...)
R5 C K % Memory area to receive field list
R6 C K LINK
R7) R Set = VCO ̲STACK.CUR ̲PTR
Moves field list for specified header field to memory
location %R5.
4.2.1.4.3 V̲C̲O̲ ̲C̲M̲D̲S̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
4.2.1.4.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̲
Export procedure V̲C̲O̲ ̲S̲T̲A̲R̲T̲
(R6) C K LINK
VCO ̲CONTR ̲VAR.QEL Used to find SSC command
-. VCO ̲STATE Updated to VCO ̲STARTED
-. VDU ̲STATE Updated by call of VCO ̲START ̲VDU
USER ̲ACTIVE Set to true
start the user as follows:
Calls USE ̲SSC ̲DATA with makes some initialization
(see above)
Sends answer to SSC
Starts the VDU's by a call of VCO ̲START ̲VDU
Empties ANSWER QUEUE (by call of EMPTY ̲ANSWER ̲QUEUE)
Starts UFCO by a Start command to semaphore VUS
̲s2
Sets VCO ̲STATE to VCO ̲started
Export procedure V̲C̲O̲ ̲S̲T̲O̲P̲
(R2 C K SSC command code (subtype from qel)
R6) C K LINK
VCO ̲STATE VCO ̲STOPPED
VDU ̲STATE Updated by VCO ̲STOP ̲VDU
USER ̲ACTIVE Set to false
Cancels periodic timeout.
Sends command to UFCO (depending of call R2).
Remove terminals by call of VCO ̲STOP ̲VDU
Sends reply to SSC
If command = CLOSE an infinite wait-loop is entered
- otherwise: Flash queues are emptied, and procedure
returns.
4.2.1.4.3.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Procedure S̲S̲C̲ ̲R̲E̲P̲L̲Y̲
(R6) C K LINK
VCO ̲CONTR ̲VAR.QEL used to identify request queue element
Returns the command reply to SSC.
Procedure U̲S̲E̲ ̲S̲S̲C̲ ̲D̲A̲T̲A̲
(R6) C K LINK
VCO ̲CONTR ̲VAR.QEL used to find SSC command
Reads the buffer from SSC command and uses the contents
for:
Initialize INIT ̲AREA
Initialize Terminal ̲designator in ACCOUNT
Initialize Terminals by calling
VCO ̲INIT ̲TERMINALS:
Procedure E̲M̲P̲T̲Y̲ ̲A̲N̲S̲W̲E̲R̲ ̲Q̲U̲E̲U̲E̲
(R6) C K LINK
Takes care of all elements in answer queue as follows
depending on maintype:
INITIAL ̲MAINTYPE:
QUEUE ̲ELEMENT is send to UMAN with maintype =
TEP ̲INTERNAL and SUBTYPE = UNKNOWN ̲SATUS ̲CHANGE
Other Maintype:
QUEUE ̲ELEMENT is just dismantled (thrown away !!!)
Procedure R̲E̲Q̲ ̲P̲E̲R̲I̲O̲D̲I̲C̲ ̲T̲I̲M̲E̲O̲U̲T̲
(R6) C K LINK
Starts the periodic timer (which gives timeout at every
change of minute).
Procedure C̲A̲N̲C̲ ̲P̲E̲R̲I̲O̲D̲I̲C̲ ̲T̲I̲M̲E̲O̲U̲T̲
(R6) C K LINK
Cancels the request for periodic timeouts.
4.2.1.4.4 V̲C̲O̲ ̲F̲L̲A̲S̲H̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
4.2.1.4.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̲s̲
Export procedure V̲C̲O̲ ̲F̲L̲A̲S̲H̲ ̲N̲O̲T̲I̲F̲
(R2 C K SUBTYPE, e.g. code for priority
R3 C K FLAGS, e.g code for queue
R4 C K CURRENT ̲PM ̲TIME.LEAST
R5 C K CURRENT ̲PM ̲TIME.MOST
R6) C K LINK
CUR ̲PREC C K Used to determine SEND ̲ACTION (in
call of HANDLE ̲FLASH ̲QUEUE);
FLASH.
STATE C R Updated if a FLASH ̲TIMEOUT is requested
VCO ̲STATE C K Used to determine SAEND ̲ACTION
If received item is FOR ̲RELEASE a BEEP is made and
VDU header is updated.
Otherwise the priority SUB QUEUE specified is handled
with ation depending on VCO ̲STATE:
VCO ̲STOPPED: SEND ̲ALL
VCO ̲STARTED: SEND ̲PROFILE
If no elemets are removed a BEEP and VDU Header update
is made. If elements remains in queue and if there
is no outstanding FLASH timeout, a FLASH TIMEOUT REQUEST
is made.
Export procedure V̲C̲O̲ ̲F̲L̲A̲S̲H̲ ̲T̲I̲M̲E̲O̲U̲T̲
(R4 C K Current PM ̲TIME.LEAST
R5 C K Current PM ̲TIME.MOST
R6) C K LINK
FLASH.
STATE C R Updated if precedence FLASH or if
FLASH TIMEOUT is requested
VCO ̲STATE C K
CURRENT ̲
PREC C K
If VCO ̲STATE = VCO ̲STOPPED then nothing is done - otherwise:
If current precedence is higher or equal to flash then
an extra flash timeout (with period = sample interval)
is requested. Otherwise the FLASH queues are emtied
for OLD elements. If any elements remains a new FLASH
timeout is requested - with period = MIN (LIFETIME,
SAMPLE ̲INTERVAL).
Export procedure V̲C̲O̲ ̲E̲M̲P̲T̲Y̲ ̲F̲L̲A̲S̲H̲ ̲C̲
(R6) C K LINK
Sends all elements of precedence FLASH or SUPER ̲FLASH
in RECEIVE QUEUE which are NOR FOR ̲COORDINATION to
the MDCO.
4.2.1.4.4.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Procedure R̲E̲C̲ ̲F̲L̲A̲S̲H̲ ̲T̲I̲M̲E̲O̲U̲T̲
(R3 C K Period in seconds
R6) C K LINK
Requests a FLASH TIMEOUT to be returned after the number
of SECONDS specified in call.
Procedure G̲E̲T̲ ̲F̲Q̲T̲
(R2 - R Flash queue timeout (in seconds)
R6) C K LINK
Gets the actual value of FLASH QUEUE TIMEOUT by calling
the TMP ̲REQUEST TMP ̲GET ̲SYSTEM ̲PARAM, FLASH ̲QUEUE ̲
TIMEOUT.
Procedure H̲A̲N̲D̲L̲E̲ ̲F̲L̲A̲S̲H̲ ̲Q̲U̲E̲U̲E̲
(R0 C K SEND ̲ACTION (FLASH ̲SEND ̲TYPE)
R1 C K Priority (FLASH or SUPER ̲FLASH)
R2 C K Flash queue timeout in sec's (only
used by SEND ̲OLD)
R3 - R Remaining lifetime in sec's for oldest
element (only SEND ̲OLD)
R4 C PM ̲TIME.LEAST (only SEND ̲OLD)
R No. of elements send to MDCO
R5 C PM ̲TIME.MOST (only SEND ̲OLD)
R No. of elements left (=updated FLASH
̲
CNT value)
R6) C K LINK
FLASH ̲
CNT(R1) Updated to elements left at return
from procedure.
Scars the PRIORITY subqueue of RECEIVE queue and handles
elements found which are not for coordination as follows,
depending on SEND ̲ACTION (R0).
SEND ̲ALL: All queue elements (not for coordination)
are send to MDCO.
SEND ̲PROFILE: All queue elements (not for coordination)
which gives profile check error are send
to MDCO.
SEND ̲OLD: All queue elements (not for coordination)
which give profile check error or with
an age greater than Flash Queue Timeout
(R2) are send to MDCO. Remaining lifetime
for oldest left element (if any) is returned
in R3. Age is computed by use of PM ̲TIME
in queue element and call PM ̲TIME (considered
to be current time).
4.2.1.4.5 V̲C̲O̲ ̲C̲O̲M̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
4.2.1.4.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̲
Export procedure V̲C̲O̲ ̲S̲T̲A̲C̲K̲ ̲E̲R̲R̲O̲R̲
Export procedure V̲C̲O̲ ̲Q̲ ̲P̲A̲R̲ ̲C̲O̲P̲Y̲
(R4 C K % SEND ̲PARAMS
R5 C K % QEL ̲ATTRIBUTES
R6) C K LINK
Copies selected parts of QEL ̲ATTRIBUTES (%R5) to SEND
̲PARAMS (%R4) so that the SEND ̲PARAMS can afterwards
be used for SEND ̲REPLY.
Export procedure V̲C̲O̲ ̲Q̲ ̲I̲N̲I̲T̲
(R0 - R VCO ̲Q ̲RESULT
R1 C K MAIN QUEUE
R2 C R SUBQUEUE
R3 - R Qel ref, if qel received
R4 C K % VCO ̲Q ̲DESCR
R5 C K % QEL ̲ATTRIBUTES for receive
R6) C K LINK
Initializes the VCO ̲Q ̲DESCR (%R4) for scan of QUEUE
and receives the first QUEUE ̲ELEMENT (if any) in QEL
̲ATTRIBUTES (%R5).
Export procedure V̲C̲O̲ ̲Q̲ ̲N̲E̲X̲T̲
(R0 - R VCO ̲Q ̲RESULT
R3 - R Qel ref (if qel received)
R4 C K % VCO ̲Q ̲DESCR
R5 C K % QEL ̲ATTRIBUTES for receive
R6) C K LINK
Receives the next QUEUE ̲ELEMENT (if any) from SUB QUEUE.
The present element is returned to QUEUE or dismantled
(by a call of TEP ̲DISMANTLE). Dismantle is performed
if the procedure VCO ̲Q ̲DISM has been called after the
previous call of VCO ̲Q ̲NEXT (or VCO ̲Q ̲INIT).
Export procedure V̲C̲O̲ ̲Q̲ ̲D̲I̲S̲M̲
(R3 C K Check status: BOOLEAN
R4 C K % VCO ̲Q ̲DESCR
R6) C K LINK
Marks the current queue element to be dismantled or
saved with dismantle = true by the next call of VCO
̲Q ̲NEXT or VCO ̲Q ̲TERM.
Export procedure V̲C̲O̲ ̲Q̲ ̲T̲E̲R̲M̲
(R4 C K % VCO ̲Q ̲DESCR
R6) C K LINK
Procedure R̲E̲T̲U̲R̲N̲ ̲Q̲ ̲E̲L̲
(R4 C D % VCO ̲Q ̲DESCR
R6) C K LINK
R7 R Set to VCO ̲STACK.CUR ̲PTR
Other reg's Destroyed !!!
Returns or dismantles the queue element references
by VCO ̲Q ̲DESCR according to VCO ̲Q ̲DESCR.STATE as follows:
QU ̲EMPTY: Nothing is done
QU ̲RETURN: Queue element is RETURN'ed to QUEUE
QU ̲DISMANTLE: Queue is TEP ̲DISMANTLE's with CHECKPOINT
= FALSE
QU ̲SAVE: Queue is TEP ̲DISMANTLE'd with CHECKPOINT
= TRUE
Afterwards STATE IN VCO ̲Q ̲DESCR is set to QU ̲EMPTY.
4.2.1.7 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
4.2.1.7.1 V̲C̲O̲ ̲U̲F̲C̲O̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The following commands are sent from VCO to UFCO via
operation semaphore VUS ̲S2:
START ̲UFCO
STOP ̲UFCO
BLOCK ̲UFCO
CLOSE ̲UFCO
4.2.1.7.2 U̲F̲C̲O̲ ̲V̲C̲O̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Completion codes are sent from UFCO to VCO for the
following commands:
START ̲UFCO
STOP ̲UFCO
BLOCK ̲UFCO
CLOSE ̲UFCO
The following completion codes exist:
OK ̲CC
ERROR ̲CC
SPLIT ̲FAILED ̲CC
