top - download
⟦6e17cfc1f⟧ Wang Wps File
Length: 38544 (0x9690)
Types: Wang Wps File
Notes: Spelunked
Names: »~ORPHAN58.00«
Derivation
└─⟦fa4d101ea⟧ Bits:30005807 8" Wang WCS floppy, CR 0112A
└─ ⟦this⟧ »~ORPHAN58.00«
WangText
…00……00……00……00……00…:…02……00……00…:
: :…07…9…08…9…09…9…0f…9…05…8…0c…8…0d…8…02…8
8 8…05…8…06…8…07…7…0c…7…0d…7…0e…7…0f…7…02…7
7…05…7…06…7…07…6…08…6…0e…6…0f…6
6 6…07…5…08…5…0f…5…00…5
5…07…4…0b…4…0f…4
4…06…3…09…3…0d…3…01……86…1 …02… …02… …02…
…02…CPS/SDS/039
…02…820104…02……02…
USER VDU
DETAILED DESIGN SPECIFICATION…02……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 o 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 softwre).
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
- he 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 corouines.
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 suprvisor.
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 oroutine 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..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.…86…1
…02… …02… …02… …02…
UFCO performs the user transaction control, which consists
of:
- user transaction execution
- user requested transaction interruption
- user transaction accounting.
The fnctions 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 transferinitiation / 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̲s̲
The VDU dialogue (VDIA) coroutine is responsible for
the VDU format transfromation of input and output and
for validaion 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 thatthe 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 coroutinesassociated 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.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 Srvice
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 ad 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 tat 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 Dataase
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 disigner the freedom to optimize disk-accesses
and to utilze 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̲
n 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̲-̲…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 sftware structure charts and references
should be made to the functional specification given
in section 4.1.1. The denotation used in section 4.1.1
has as far as possible been used in the software structure
charts, with the purpose of highlighting te close relationship.
Thus the identification of programme tasks is given
in narrative English and not as programme or procedure
names.
4.1.2.3.1 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̲
The software structure of the VDU Control Coroutine
(VCO) is outined in the structure charts in fig. 4.1.2.3-1
through fig. 4.1.2.3-5 and is related to fig. 4.1-7
and fig. 4.1-8 of the functional specifications.
In fig. 4.1.2.3-1, the box PROCESS TEMCO COMMAND EXECUTION
reflects that VCO controls the activitis of UFCO. Control
logic will be described in section 4.1.3.
Fig. 4.1.2.3-1 VCO Coroutine Software Structure
Fig. 4.1.2.3-2 VCO Structure TEMCO CMD Processing
Fig. 4.1.2.3-3 UVCO Structure ̲ Update of Queue Status Line
Fig. 4.1.2.3-4 VCO Structure - Flash Queue Monitoring
Fig. 4.1.2.3-5
VCO Structure - Process CMD Completion Report from UFCO.
In fig. 4.1.2.3-2 the Temco Command Processing is depicted.
For those commands representing the key commands with
respect to the execution of the VUP main functions,
the software tructure is slightly more detailed than
for the others, as this is the most important to grasp
when getting to understand the general structure.
4.1.2.3.2 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
theVDU 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
correspondin 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-6 to fig. 4.1.2.3-8 sow the software structure.
Fig. 4.1.2.3-6 UFCO Structure
Fig. 4.1.2.3-7 UFCO Structure - Process Invalid F/C Key Interrupt
Fig. 4.1.2.3-8 UFCO Structure - Execute F/C Key Function
4.1.2.3.3 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 performs input / output to and from
the format area of the VDU and validation and storage
of input.
It accepts commads from UFCO and sends completion report
corresponding to these commands.
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.
ig. 4.1.2.3-9 shows the software structure.
F̲I̲G̲U̲R̲E̲ ̲4̲.̲1̲.̲2̲.̲3̲-̲9̲ ̲V̲D̲I̲A̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲ ̲
4.1.2.3.4 R̲E̲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 ending Online
Retrieval Results direct to UFCO or Off-line Retrieval
Results indirectly via the Response Queue.
Fig. 4.1.2.3-10 shows the software structure.
fig. 4.1.2.3-10 RETR Structure
4.1.2.3.5 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-11 shows the software structure.…86…1
…02… …02… …02… …02…
Fig. 4.1.2.3-11 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 thir 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 VU 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.
owever, 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 paentheses, 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 requesed function, VUS stops its own processing
and awaits the result to be delivered by UMAM in its
answer queue.
Figure 4.1.3-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. mssages 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-2.
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 sction 4.1.1.3.4.
In fig. 4.1.3.2-2, an overview of the VUS coroutines
and the primitives (S1, S2, S3) used for synchronization
is depicted.
Fig. 4.1.3-2 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 informtion from UVCO 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 messags.
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 opeation 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 DIA 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.
DIA 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 consideed. 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
insered and process the occurred events.
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 a overview of the UMAM process
is depicted.
As UMAM is a process without coroutines, then no internal
synchronization is required.
F̲I̲G̲U̲R̲E̲ ̲4̲.̲1̲.̲3̲.̲3̲-̲1̲…86…1 …02… …02… …02… …02… …02…
4.1.4 C̲o̲m̲m̲o̲n̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
a) D̲A̲T̲A̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
COROUTINE ̲SEMAPHORE ̲TYPE refer
CPS/DBD/001
COROUTINE ̲OPERATION ̲TYPE refer
CPS/DBD/001
IFCB ̲INDEX ̲TYPE refer
CPS/DBD/001
FELD ̲DESCRIPTOR ̲TYPE refer
CPS/DBD/001
DESIGNATOR ̲TYPE refer
CPS/DBD/001
TIME ̲TYPE refer
CPS/DBD/001
QEL ̲REFERENCE ̲TYPE refer
CPS/DBD/001
CLASSIFICATION ̲TYPE refer
CPS/DBD/001
PRECEDENCE ̲TYPE refer
CPS/DBD/001
USER ̲CAPABILITY ̲TYPE efer
CPS/DBD/001
QERROR ̲INF ̲TYPE refer
CPS/DBD/001
TMP ̲PARAM ̲TYPE refer
CPS/DBD/001
b) V̲U̲S̲ ̲C̲O̲M̲M̲O̲N̲ ̲T̲Y̲P̲E̲S̲…86…1…02… …02… …02… …02… …02… …02… …02…
…02… …02…
TYPE VUS ̲COROUTINE ̲OP = RECORD
COROUTINE
OP: COROUTINE
̲OP
̲TYPE
IDENT: IDENT
̲TYPE
CMD: CO
̲CMD's
̲TYPE
PARA: INTEGER
END
TYPE IDENT = (VCO ̲IENT, UFCO ̲IDENT, UFCO ̲VDIA ̲IDENT,VDIA
̲IDENT,
RETR ̲IDENT, CMDQ ̲IDENT,F/C ̲KEY ̲IDENT,
ANQ ̲IDENT, VDU ̲IDENT)
TYPE CO-̲CMD = CASE
IDENT
OF
VCO ̲IDENT: VCO ̲CMD ̲TYPE
UFCO ̲IDENT: UFCO ̲CC ̲TYPE
UFCO ̲VDIA ̲IDENT: UFCO ̲VDIA ̲CMD ̲TYPE
VDIAIDENT: VDIA ̲UFCO ̲CC ̲TYPE
RETR ̲IDENT: RETR ̲NOT ̲TYPE
VDU ̲IDENT: VDU ̲CMD ̲TYPE
END CASE
TYPE VCO ̲CMD = (INIT
̲UFCO
̲CMD,
RESTART
̲UFCO
̲CMD,
START ̲UFCO ̲CMD, STOP ̲UFCO ̲CMD,
BLOCK ̲UFCO ̲CMD, CLOSE ̲DOWN ̲UFCO ̲CMD)
TYPE UFCO ̲CC = (INIT
̲FCO
̲CC,
RESTART
̲UFCO
̲CC)
START ̲UFCO ̲CC, STOP ̲UFCO ̲CC,
BLOCK ̲UFCO ̲CC, CLOSE ̲DOWN ̲UFCO ̲CC,
USER ̲MODE ̲CHANGE, PRECEDENCE ̲CHANGE)
TYPE UFCO ̲VDIA ̲CMD= (VDIA ̲CLOSE ̲DOWN, VDIA
̲CANCEL,
VDIA ̲CLEAR ̲VDU, VDIA ̲SUSPEND,
VDIA ̲INPUT ̲FORMAT, VDIA ̲INPUT
̲MSG,
VDIA ̲INPUT ̲REQ, VDIA ̲OUTPUT
̲FORMAT,
VDIA ̲OUPUT ̲MSG, VDIA ̲APPEND,
VDIA ̲INSERT, VDIA ̲DELETE)
TYPE VDIA ̲UFCO ̲CC = (SPLIT ̲FAILED ̲CC, VDIA
̲CLOSE ̲DOWN ̲CC,
VDIA ̲CANCEL ̲CC, VDIA ̲CLEAR
̲VDU ̲CC,
INSERT ̲NOT ̲ALLOWED ̲CC, LINES
̲INSERTED ̲CC,
DELETE ̲NOT ̲ALLOWED ̲CC, LINES
̲DELETED ̲CC,
OUTPUT ̲MSG ̲CC, OUTPUT ̲FORMAT ̲CC,
INPUT ̲REQ ̲CC, INPUT ̲MSG ̲CC,
EXCEEDED ̲CC, VAL ̲ERROR ̲CC,
VDIA ̲SUSPEND ̲CC, APPEND ̲VALID
̲CC,
DEFER ̲VALID, RELEASE ̲VALID,
COORDINATION ̲VALID)
TYPE RETR ̲NOT = (ONLINE ̲NOTIFICATION,
OFFLINE ̲NOIFICATION,
RETRIEVAL ̲NOTIFICATION, APPEND
̲NOTIFICATION)
TYPE VDU ̲CMD = (FORMAT ̲TO ̲VDU, FIELDS
̲TO ̲VDU,
FIELDS ̲FROM ̲VDU, LINES ̲INSERTED,
LINES ̲DELETED)
TYPE SEQUENCE ̲CODE = (SEQ
̲ENTER,
SEQ
̲FK1,
SEQ
̲FK2,
SEQ
̲FK3...SEQ
̲FK36,
SEQ
̲START,
SEQ
̲CLOSE
̲DOWN,
SEQ
̲STOP
̲USER,
SEQ
̲BLOCK
̲TERMINAL,
SEQ
̲FAILURE,
SEQ
̲CLOSE
̲DOWN
̲CC,
SEQ ̲CANCEL ̲CC, SEQ ̲CLEAR
̲VDU ̲CC,
SEQ
̲OUTPUT
̲MSG
̲CC,
SEQ
̲OUTPUT
̲FORMAT
̲CC,
SEQ
̲INPUT
̲REQ
̲CC,
SEQ
̲INPUT
̲MSG
̲CC,
SEQ
̲INPUT
̲FORMAT
̲CC,
SEQ
̲EXCEEDED
̲CC,
SEQ
̲VAL
̲ERROR
̲CC,
SEQ
̲SUSPEND
̲CC,
SEQ
̲APPEND
̲VALID
̲CC,
SEQ
̲DEFER
̲VALID
̲CC,
SEQ
̲RELEASE
̲ALID
̲CC,
SEQ
̲COORDINATION
̲VALID
̲CC,
SEQ
̲CONT,
SEQ
̲DISP,
CONT
̲DISP,
SUS/DEF
̲DISP,
UMAM
̲ERROR
̲RESP,
CONT
̲COMMENT,
SUS/DEF
̲COMMENT,
DISP
̲COOR,
ACK
̲THP,
SEQ
̲DELI,
SEQ
̲OUTG,
SEQ
̲RELS,
REL
̲OK,
REL
̲NOT,
SEQ
̲OFF
̲NOT)
c) V̲U̲S̲ ̲C̲O̲M̲M̲O̲N̲ ̲D̲A̲T̲A̲…86…1…02… …02… …02… …02… …02… …02… …02… …02… …02… …02…
…02…
VAR VCO ̲OP, UFCO ̲OP, VDIA ̲CC ̲OP, RETR ̲OP,
CMD ̲OP, ANQ ̲OP, F/C ̲KEY ̲OP, VDU ̲OP: VUS
̲COROUTINE
̲OP
̲TYPE
INIT UFCO ̲OP. IDENT =
UFCO
̲VDIA
̲IDENT
INIT VDIA ̲CC ̲OP. IDENT =
VDIA
̲IDET
INIT RETR ̲OP. IDENT =
RETR
̲IDENT
INIT CMD ̲OP. IDENT =
CMDQ
̲IDENT
INIT ANQ ̲OP. IDENT =
ANQ
̲IDENT
INIT F/C ̲KEY ̲OP. IDENT =
F/C
̲KEY
̲IDENT
INIT VDU ̲OP. IDENT =
VDU
̲IDENT
VAR VUS ̲S1, VUS ̲S2, VUS ̲S3: COROUTINE ̲SEMAPHORE
̲TYPE
VAR FORMAT ̲FCB,
HEADER ̲IFCB: IFCB
̲INDEX
̲TYPE
VAR FIRST ̲FIELD ̲RECORD: FIELD ̲DESCRIPTOR ̲TYPE
VAR CURSOR ̲RECORD ̲1,
CURSOR ̲TO ̲CMD ̲RECORD,
CURSOR ̲RECORD =
RECORD
SPLIT
̲DIGIT
:
INTEGER
FIELD
: FIELD
̲DESCRIPTOR
̲TYPE
INES
̲ABOVE
: INTEGER
END;
VAR TRANSACTION ̲ID =
RECORD
TERMINAL
̲DESIGNATOR:
DESIGNATOR
̲TYPE
SERIAL
̲NO :
INTEGER
TIME :
TIME
̲TYPE
END;
…86…1…02… …02… …02… …02… …02… …02… …02… …02… …02…
VAR CIF ̲REF ̲QEL,
APPEND ̲QEL: QEL
̲REFERENCE
̲TYPE
VAR CURRENT ̲CLASSIFIC: CLASSIFICATION
̲TYPE
VAR CURRENT ̲PRECEDENCE: PRECEDENCE
̲TYPE
VAR CAB
: USER
̲CAPABILITY
̲TYPE
ONST LOG ̲BUFFER ̲SIZE =
CONST STATUS ̲BUFFER ̲SIZE =
VAR TMP ̲RECORD: TMP
̲PARAM
̲TYPE
VAR VUS ̲QERROR: QERROR
̲INF
̲TYPE
VAR VUS ̲INT ERROR = RECORD
USER
̲CC: INTEGER
USER
̲INF: ARRAY(1..4)
of
INTEGER
END;
VAR ERROR ̲TEXT : ARRAY(1..36)
OF
CHAR
VAR VUS ̲SEND ̲PARAMS : SEND
PARAMS
TYPE…86…1
…02…
…02…
…02…
…02…
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 V̲U̲S̲ ̲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.
4.1.5.1.2 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) VUS ̲QUEUE ̲ERROR(USER ̲ACTION: USER ̲ACTION ̲TYPE,
QEL: QEL ̲REFERENCE,
VUS ̲QERROR: QERROR ̲INF)
b) VUS ̲QUEUE ̲ERROR(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 QEL DEST
R4 pointer to VUS ̲QERROR DEST
R6 LINK DEST
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None
R0-R7 DEST…86…1
…02… …02… …02… …02…
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̲
USER ̲ACTION ̲TYPE refer CPS/DBD/001
GAQ ̲INFO ̲TYPE refer CPS/DBD/001
QEL ̲REFERENCE refer CP/DBD/001
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
VUS ̲QERROR refer 4.1.4
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
None
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.
4.1.5.2 V̲U̲S̲ ̲I̲N̲T̲E̲R̲N̲A̲L̲ ̲E̲R̲R̲O̲R̲
4.1..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) VUS ̲INTERNA ̲ERROR (USER ̲ACTION ̲ USER ̲ACTION ̲TYPE,
VUS ̲INT ̲ERROR: INTERNAL ̲ERROR
̲INF)
b) VUS ̲INTERNAL ̲ERROR (R1, R4, 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
R4 pointer to VUS ̲INT ̲ERROR 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̲
USER ̲ACTION ̲TYPE refer CPS/DBD/001
GAQ ̲INFO ̲TYPE refer CPS/DBD/001
QEL ̲REFERENCE refer CPS/DBD/001
INTERNAL ̲ERROR ̲INFTYPE refer CPS/DBD/001
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
VUS ̲INTE ̲ERROR refer 4.1.4
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
TYPE VUS ̲INTERNAL ̲ERROR: INTERNAL ̲ERROR ̲INF ̲TYPE
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 SS by
calling the SEND ̲GARBLE-procedure.
4.1.6 G̲l̲o̲b̲a̲l̲ ̲D̲a̲t̲a̲
TBD
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̲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.3S̲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 interfae 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 implemnted 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 (Global n. series) and VDIA (table access).
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. Deete Requests
4. Access State Changes
5. VDU-PAGE Retrieval
6. Status Records.
7. Storage of VDU-PAGES
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̲a̲c̲e̲s̲
1̲.̲ ̲F̲r̲o̲m̲ ̲V̲C̲O̲ ̲t̲o̲ ̲U̲F̲C̲O̲
1. Initialize Command
2. Restart UFCO Command
3. Start UFCO Command
4. Stop UFCO Command
5. Close Down Command.
2̲.̲ ̲F̲r̲o̲m̲ ̲U̲F̲C̲O̲ ̲t̲o̲ ̲V̲C̲O̲
1. Initalize CC
2. Restart UFCO CC
3. Start UFCO CC 4. Stop
UFCO
CC
5.Close Down CC
3̲.̲ ̲F̲r̲o̲m̲ ̲U̲F̲C̲O̲ ̲t̲o̲ ̲V̲D̲I̲A̲
1. Initialize CMD
2. Start VDIA CMD
3. Display Format CMD
4. Input Format CMD
5. Output Message CMD
6. Insert Lines CMD
7. Delete Lines CMD
8. Clean Up CMD
9. Close Down CMD.
4̲.̲ ̲F̲r̲o̲m̲ ̲V̲D̲I̲A̲ ̲t̲o̲ ̲U̲F̲C̲O̲
1. Initialize CC
2. Start VDIA CC
3. Clean Up CC
4. Close Down CC
5. Validation Result.
6. Output format CC
7. Input format CC
5̲.̲ ̲F̲r̲o̲m̲ ̲U̲F̲C̲O̲ ̲t̲o̲ ̲E̲T̲R̲
None.
6̲.̲ ̲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
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 command
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 common data for the
subpackages within VUS.
b) Initialize VCO Data (1.2)
Performs iniialization of common data for the modules
within the VCO subpackage.
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̲
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 strts 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 reslt 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.)
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 TMCO.
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 fash 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 fash 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..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 filds in the VDU-header.
c) Display VDUHeader (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)
Reacts upon information from UFCO that the urrent
user mode (i.e. release, preparation, reception)
has changed.
d) Process Precedence Change (6.4)
Reacts upon information from UFCO that the current
precedence has changed.
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 (71)
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̲
Te software structure is shown on figure 4.2.1.2-1.
VCO consists of one coroutine containing 4 modules
and 14 common procedures.
4.2.1.2.1 V̲C̲O̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲1̲.̲0̲)̲
This is the module containing the mainloop of VCO.
The module contains the VUS initialiation functions,
receives and processes items arriving in the VUS ̲CMDQ,
receives and reacts upon UFCO responses, sends acknowledge
of TEMCO commands to TEMCO and reports queue errors
and internal errors to SSC.
The following component procedures re contained in
this module:
a) VUS Init (1.1)
Initializes the VUS common data and VCO data.…86…1
…02… …02… …02… …02…
b) Set Receive CMD QEL (1.2)
Initiates a receive function for the VUS ̲CMDQ and
associates the event to the VUS ̲S1 semaphore.
c) Init UFCO cc Processing (1.3)
Reacts upon comletion of the INIT UFCO CMD.
d) Restart UFCO cc Processing (1.4)
Reacts upon completion of the RESTART UFCO CMD.
e) Start UFCO cc Processing (1.5)
Reacts upon completion of the START UFCO CMD.
f) Stop UFCO cc Processing (1.6)
Reacts upo completion of the STOP UFCO CMD.
g) Block UFCO cc Processing (1.7)
Reacts upon completion of the BLOCK UFCO CMD.
h) Close Down UFCO cc Processing (1.8)
Reacts upon completion of the CLOSE DOWN UFCO CMD.
4.2.1.2.2 T̲E̲M̲C̲O̲ ̲C̲M̲D̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲(̲2̲0̲)̲
This module analyses TEMCO commands, performs start
user actions (after sign on), sends commands to UFCO
and reports reception of unexpected queue elements
to SSC.
The following component procedures are contained in
this module:
a) Get Terinal Profile (2.1)
Reads the terminal profile by call upon TMP.
b) Set Session Attributes (2.2)
Transfers data from the terminal profile to VUS
Common data areas.
c) Set User Connection (2.3)
Transfers the user connection (received from EMCO
together with START USER CMD) to VUS common data
areas.
d) Init Header Split (2.4)
Initializes the contents of the fields to be displayed
as VDU header and displays the fields.
e) Request Periodic Timeout (2.5)
Requests the perioic timeout (every minute) for
the duration of this session.
4.2.1.2.3 F̲l̲a̲s̲h̲ ̲Q̲u̲e̲u̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲(̲3̲.̲0̲)̲
This module interprets the flash notification to determine
which queue the flash item has arrived at and the precedence
of the item (superflash nd flash), determines whether
the classification allows the item to be displayed
(if not it will be sent to MDCO immediately), determines
whether the current precedence is flash or above (in
which case timeout request is not required), checks
if a imeout is already outstanding (in which case timeout
request is not required), reads the system parameter
FQT (Flash Queue Timeout), checks if it is changed
since last used, requests/cancels timeout accordingly,
updates VDU header queue fields, invrts appropriate
flash queue fields, rings the bell displays the VDU
header and reports reception of unexpected queue element
in the VUS ̲CMDQ.
The following component procedure is contained in the
module:
a) Get Flash QEL Attributes (3.1)
Obtans flash queue element attributes by call upon
the Queue Monitor function.
4.2.1.2.4 T̲i̲m̲e̲r̲ ̲E̲v̲e̲n̲t̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲(̲4̲.̲0̲)̲
This module interprets the timeout to determine whether
it is a periodic- or flash timeout request. For periodic
timeouts the date/time fied and queue length fields
in the VDU header are updated and the VDU header displayed.
For a flash timeout it is checked if current precedence
is flash or above (in which case no action is taken),
otherwise the flash item timed out is sent.
MDCO, te flash queues are searched for further flash
items (if such items are found renewed timeout is requested),
the VDU queue length fields are updated and displayed.
If unexpected queue elements are found this is reported
to SSC.
4.2.1.2.5 C̲o̲m̲m̲o̲n̲ ̲P̲o̲c̲e̲d̲u̲r̲e̲s̲
For description of the 14 common procedures refer section
4.2.1.6.
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.
The call structure within VCO is shown on figure 4.2..3-5
identifying all calls between modules and common procedures.
F̲I̲G̲U̲R̲E̲ ̲4̲.̲2̲.̲1̲.̲3̲-̲1̲ ̲-̲ ̲F̲I̲G̲U̲R̲E̲ ̲4̲.̲2̲.̲1̲.̲3̲-̲5̲
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̲
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̲c̲a̲t̲i̲o̲n̲
This module is the controlling module within the subpackage.
It inerprets the startup parameters delivered in the
registers when the subprocess is started and activates
initialization or restart accordingly. It initializes
the VUS dataareas, sends a command to UFCO, signals
UFCO and initiates reception from the VS ̲CMDQ. It associates
the reception from this queue with the semaphore VUS
̲S1 and waits for this semaphore. It analyses the input
to the semaphore (when signalled) to identify:
- SSC commands
- Flash Notifications
- Timeouts
- UFCO Responses
and calls appropriate modules.
4.2.1.4.1.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) VCO ̲CONTROL
b) VCO ̲CONTROL (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̲
R̲6̲ ̲L̲I̲N̲K̲ DESTROYED
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
RO-R7 DESROYED
F̲a̲t̲a̲l̲ ̲E̲r̲r̲o̲r̲s̲
None…86…1 …02… …02… …02… …02…
4.2.1.4.1.3 ̲M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
4.2.1.4.1.3.1 V̲U̲S̲ ̲I̲N̲I̲T̲
Initializes the VUS-data areas and VCO-dataareas.
4.2.1.4.1.3.2 S̲E̲T̲ ̲R̲E̲C̲E̲I̲V̲E̲ ̲C̲M̲D̲ ̲Q̲E̲L̲
Initiates reception from VUS ̲CMDQand associates to
VUS ̲S1. Refer figure 4.2.1.4.1.3.2-1.
4.2.1.4.1.3.3 I̲N̲I̲T̲ ̲U̲F̲C̲O̲ ̲C̲C̲ ̲P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲
Responds to completion of UFCO cmd.
4.2.1.4.1.3.4 R̲E̲S̲T̲A̲R̲T̲ ̲U̲F̲C̲O̲ ̲C̲C̲ ̲P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲
Responds to completion of UFCO cmd.
4.2.1.4.1.3.5 S̲T̲A̲R̲T̲ ̲U̲F̲C̲O̲ ̲C̲ ̲P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲
Responds to completion of UFCO cmd and sends acknowledge
of START ̲USER cmd to TEMCO.
4.2.1.4.1.3.6 S̲T̲O̲P̲ ̲U̲F̲C̲O̲ ̲C̲C̲ ̲P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲
Responds to completion of UFCO cmd and sends acknowledge
of STOP ̲USER cmd to TEMCO.
4.2.1.4.1.3.7 B̲L̲O̲C̲K̲U̲F̲C̲O̲ ̲C̲C̲ ̲P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲
Responds to completion of UFCO cmd and sends acknowledge
of BLOCK ̲TERMINAL cmd to TEMCO.
4.2.1.4.1.3.8 C̲L̲O̲S̲E̲ ̲D̲O̲W̲N̲ ̲U̲F̲C̲O̲ ̲C̲C̲ ̲P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲
Responds to completion of UFCO cmd, clears VDU Header
Split, closes Format Handler interface and sends acknowledge
of CLOSE ̲DOWN cmd t TEMCO.
S̲E̲T̲ ̲R̲E̲C̲E̲I̲V̲E̲ ̲C̲M̲D̲ ̲Q̲E̲L̲
CASE INIT ̲RECEIVE ̲FIRST ̲QEL(WAIT, VUS ̲CMDQ, VUS ̲CMDQ
̲ATTR,
CMD ̲OP)(CC): ERROR ̲OK
ERROR? ANALYSE ̲ERROR(CC,0)
OK? ASSOCIATE(VUS ̲S1, CMD ̲OP): OK
END CASE INIT
END
…01…F̲I̲G̲U̲R̲E̲ ̲4̲.̲2̲.̲1̲.̲4̲.̲1̲.̲3̲.̲2̲-̲1̲
4.2.1.4.1.4 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̲
VCO ̲OP refer 4.1.4
VUS ̲S1 refer 4.1.4
INIT ̲UFCO ̲CMD refer 4.1.4
RESTART ̲UFCO ̲CMD refer 4.1.4
START ̲UFCO ̲CMD refer 4.1.4 STOP
̲UFCO
̲CMD refer
4.1.4
BLOCK ̲UFCO ̲CMD refer 4.1.4
CLOSE ̲DOWN ̲UFCO ̲CMD refer 4.1.4
INIT ̲UFCO ̲CC refer 4.1.4
RESTART ̲UFCO ̲CC refer 4.1.4
START ̲UFCO ̲CC refer 4.1.4
STOP ̲UFCO ̲CC refer 4.1.4
BLOCK ̲UFCO ̲CC refer 4.1.4
CLOSE ̲DOWN ̲UFCOCC refer 4.1.4
USER ̲MODE ̲CHANGE refer 4.1.4
PRECEDENCE ̲CHANGE refer 4.1.4
QERROR ̲INF refer 4.1.4
INTERNAL ̲ERROR ̲INF refer 4.1.4
CMD ̲QEL refer 4.2.1.5
CMD ̲QEL ̲MAINTYPE refer 4.2.1.5
CMD ̲QEL ̲SUBTYPE refer 4.2.1.5
CMD ̲QEL ̲FLAGS refer 42.1.5
ACK ̲PARAMS refer 4.2.1.5
CURRENT ̲MODE ̲QUEUE refer 4.2.1.5
FLASH ̲ITEM ̲FOUND refer 4.2.1.5
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
START ̲UP: START ̲UP ̲ACTIVE ̲TYPE
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
RESTART: BOOLEAN
UFCO ̲CC ̲RECEIVED: BOOLEAN
OP ̲POINTER: INTEGER
OP ̲IDET: INTEGER
4.2.1.4.1.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The module performs the following tasks:
- Interprets the START ̲UP ̲ACTIVE ̲TYPE and sends a
INIT ̲UFCO cmd or RESTART ̲UFCO cmd accordingly.
- Initializes VUS data- and VCO dataareas.
- Sets up RECEIVE ̲FIRST ̲QEL callto VUS ̲CMDQ, associates
the call to VUS ̲S1, signals UFCO and waits for VUS
̲S1.
- Analyses input to VUS ̲CMDQ and calls the modules:
TEMCO ̲CMD ̲PROCESSING
FLASH ̲QUEUE ̲MONITORING
TIMER ̲EVENT ̲PROCESSING
accordingly.
- Analyses UFCO responsesand updates and displays
VDU header.
- Sends acknowledge to TEMCO.…86…1 …02… …02… …02…
V̲C̲O̲ ̲C̲O̲N̲T̲R̲O̲L̲
CASE START ̲UP OF
DEAD1? RESTART: = FALSE
DEAD2? RESTART: = FALSE
COLD ? RESTART: = FALSE
WARM1? RESTART: = TRUE
WARM2? RESTART: = TRUE
OTHERWSE? V̲U̲S̲ ̲Q̲U̲E̲U̲E̲ ̲E̲R̲R̲O̲R̲(̲C̲O̲N̲T̲I̲N̲U̲E̲)̲ ̲(̲4̲.̲1̲.̲5̲.̲1̲)̲
END CASE STARTUP
V̲U̲S̲ ̲I̲N̲I̲T̲(̲4̲.̲2̲.̲1̲.̲4̲.̲1̲.̲3̲.̲1̲)̲
RESTART? VCO ̲OP.CMD: = RESTART ̲UFCO ̲CMD
VCO ̲OP.CMD: = INIT ̲UFCO ̲CMD
S̲I̲G̲N̲A̲L̲ ̲U̲F̲C̲O̲(̲4̲.̲2̲.̲1̲.̲6̲.̲1̲)̲
S̲E̲T̲ ̲R̲E̲C̲E̲I̲V̲E̲ ̲C̲M̲D̲ ̲Q̲E̲L̲(̲4̲.̲2̲.̲1̲.̲4̲.̲1̲.̲3̲.̲2̲)̲
LOOP FOREVER
WAIT ̲OPSEM(US ̲S1)(VUS ̲OP): OK
CASE VUS ̲OP.IDENT OF
CMD ̲IDENT? V̲U̲S̲ ̲C̲M̲D̲ ̲Q̲E̲L̲ ̲P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲(̲-̲2̲)̲
UFCO ̲IDENT? U̲F̲C̲O̲ ̲R̲E̲S̲P̲O̲N̲S̲E̲ ̲P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲(̲-̲3̲)̲
OTHERWISE? V̲U̲S̲ ̲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 IDENT
END FOREVER LOOP
END
F̲I̲G̲R̲E̲ ̲4̲.̲2̲.̲1̲.̲4̲.̲1̲.̲5̲-̲1̲
