top - download
⟦5fd73e5b7⟧ Wang Wps File
Length: 30708 (0x77f4)
Types: Wang Wps File
Notes: TEP VDU User Package
Names: »1142A «
Derivation
└─⟦fad1c67d1⟧ Bits:30006043 8" Wang WCS floppy, CR 0069A
└─ ⟦this⟧ »1142A «
WangText
B B…05…B…06…A…0d…A…00…A…01…@…08…@…0f…@…06…?…0d…? ?…06…?…07…>…08…>…09…>…0a…>…0b…>…00…>…01……86…1
…02…
…02…
…02…
…02…CPS/SDS/027
…02…MSN/810801…02……02…
TEP
VDU
USER
PACKAGE
…02……02…CAMPS
Fig. 4.1.1.4-3
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̲P̲ ̲P̲r̲o̲c̲e̲s̲s̲e̲s̲
The VDU USER PACKAGE (VUP) consists of nine processes,
which are the U̲SER M̲ESSAGE A̲CCESS M̲ONITORING (UMAM)
process and eight VDU processes. (Refer fig. 4.1.2.1-1).
Each of the eight VDU processes serves four VDUs, and
therefore contains four VDU subprocesses. A subprocess
is a set of coroutines to which a common ACCESS PROFILE
can be associated. The ACCESS PROFILE contains information
on which objects (e.g. a queue) a process or subprocess
may gain access to.
In fig. 4.1.2.1-2 each VDU process is shown to contain
four User VDU subprocesses. Actually, each of the User
VDU subprocesses could be exchanged with a MDCO VDU
subprocess or an MSO VDU subprocess (refer CPS/SDS/012)
but for clarity, this aspect of the design is kept
out of this document.
4.1.2.1.1 V̲U̲S̲ ̲P̲r̲o̲c̲e̲s̲s̲
a) The VDU USER SUBPROCESS 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.
In fig. 4.1.2.1-2 an overview of VUS is depicted.
Fig. 4.1.2-1
Fig. 4.1.2.1-1 VDU USER Package Overview
Fig. 4.1.2.1-2 VUS Structure
b) The VDU user subprocess holds the following queues:
- The Command queue
- The Answer queue
- The Receive queue
- The Release queue
- The Response queue
- The Retrieve queue.
The command queue is the queue where commands from
TEMCO (SSC software), answers to timer requests
(CSF software) and FLASH notifications are placed
(by MDP and other VDU USER SUBPROCESSES).
The answer queue is used for reception of answers
to requests to MDP, LOG and UMAM:
The Receive, the Release and the Response queue
are described in section 2.2 of this PDS.
In the Retrieve queue, SAR places all its answers
/ retrieved items associated with a retrieval request.
4.1.2.1.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 and the Delivery Status for each
user VDU.
In fig. 4.1.2.1-3 an overview of the UMAM process is
shown. UMAM holds one preparation queue (PREP queue)
for each user VDU. The PREP queue contains the status
and access key to all messages under prepartion, (i.e.
not released), for the associated user VDU. UMAM holds
one queue, the REQUEST queue. In this queue, a user
VDU subprocess places its request for a status, a deletion
or a message / comment for editing.
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.
With reference to the analysis in 4.1.1.4.1, this
means that the solution, where the process executing
the release decision is allowed access to the preparation
queue for removing or changing items, is not chosen.
Note that the releaser process should have access
to an unpredictable number of the existing preparation
queues and that the ones to which access should
be allowed would change dynamically due to supervisor
specifications.
Fig. 4.1.2.1-3 UMAM Structure
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.2 V̲U̲P̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲s̲
Before describing the allocation of VUP functions to
coroutines, the most important characteristics of the
coroutine software component type will be summarized.
As the concept of coroutines is closely related to
the process concept, the characteristics of the coroutine
will be described by describing the differences between
the coroutine and the process.
a) A coroutine is always subordinated to a process.
Coroutines residing within the same process may
synchronize in the same way as processes do. Synchronization
between coroutines residing in different processes
may be achieved using the normal means for process
communication.
b) As CPU time is time-sliced between processes so
the execution of a process may be stopped at unpredictable
points, extremem care is required by the designer
when two processes share a data area. However,
shared data between coroutines require no considerations
as a coroutine is given the full CPU time assigned
to the process to which it belongs until it itself
gives it up, i.e. a coroutine is allowed to run
from waiting point to waiting point without any
other coroutine being executed in between.
c) Thus, while the process concept is a convenient
tool for simulating concurrency of tasks / functions
allocated to different processes, the coroutine
concept may be used equivalent for the functions
assigned to a process.
In the next two subsections, the allocation of
functions to coroutines for VUS respective UMAM
process will be described.
4.1.2.2.1 V̲U̲S̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲s̲
The VDU USER SUBPROCESS consists of four coroutines:
- the VDU Control Coroutine
- the User Function Control Coroutine
- the VDU Dialogue Coroutine
- the Retrieve Coroutine.
4.1.2.2.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 - refer subsections 4.1.1.1.f) and
4.1.1.2f). Thus these two functions have been allocated
their own coroutine named V̲DU C̲ONTROL 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.
In the analysis it was stated that TEMCO Control Functions
should have higher priority than all other functions.
However, taking into account the frequency with which
the functions of TEMCO Control Functions and Queue
Status Maintenance Functions shall be executed and
the CPU time they will consume, it has been considered
sufficient with one coroutine associated with one input
queue.
4.1.2.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.
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.2.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 validation of user input.
4.1.2.2.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. Off-line
retrieved items (or answers) are placed by RETR in
the response queue. Off-line retrieved items for append
(or answers) are placed in the REQUEST queue of UMAM.
On-line retrieved items and on-line retrieved items
for append are transferred to UFCO.
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 and VDIA are assigned identical
priorities.
4.1.2.2.2 U̲M̲A̲M̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲s̲
UMAM consists of two coroutines:
- the Preparation Access Conrol (PAC) Coroutine
- the User Status File Maintenance (USFM) coroutine.
UMAM has been designed with the two coroutines, PAC
and USFM, because of the disk file 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.1.2.2.2.1 P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲
PAC is the controlling coroutine, analyzing 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. When commanded by PAC, USFM extracts
/ updates the Outgoing Message Status file, the Release
Status file and the Delivery Status file.
4.1.2.2.2.2 U̲s̲e̲r̲ ̲S̲t̲a̲t̲u̲s̲ ̲F̲i̲l̲e̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲
The coroutine named USER STATUS FILE MAINTENANCE (USFM)
executes all the functions of the MESSAGE / COMMENT
STATUS MAINTENANCE except for the extract of outgoing
message status concerning changeable entries. Furthermore,
it executes the functions of PDB ACCESS CONTROL which
has to do with updates of outgoing Message Status,
turning the entries unchangeable .
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.
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 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 the 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 outlined 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 activities 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 UVCO 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 structure 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
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-6 to fig. 4.1.2.3-12 show the software
structure.
Fig. 4.1.2.3-6 UFCO Structure
Fig. 4.1.2.3-7 UFCO Structure - Execute Initialization Command
Fig. 4.1.2.3-8 UFCO Structure - Execute Restart UFCO Command
Fig. 4.1.2.3-9 UFCO Structure - Execute Start UFCO Command
Fig. 4.1.2.3-10 UFCO Structure - Execute Stop UFCO command
Fig. 4.1.2.3-11 UFCO Structure - Process Invalid F/C Key Interrupt
Fig. 4.1.2.3-12 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 commands 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.
Fig. 4.1.2.3-13 to fig. 4.1.2.3-22 show the software
structure.
Fig. 4.1.2.3-13 VDIA Structure
Fig. 4.1.2.3-14 VDIA Structure Execute Init Command
Fig. 4.1.2..3-15 VDIA Structure - Execute Start Command
Fig. 4.1.2.3-16 VDIA Structure Execute Display Format CMD
Fig. 4.1.2.3-16 VDIA Structure - Execute Input ̲Format Command
Fig. 4.1.2.3-18 VDIA Structure - Execute Output ̲MSG Command
Fig. 4.1.2.3-19 VDIA Structure - Execute Insert ̲Lines Command
Fig. 4.1.2.3-20 VDIA Structure - Execute Delete ̲Lines Command
Fig. 4.1.2..3-21 VDIA Structure - Execute Clean ̲Up Command
Fig. 4.1.2.3-22 VDIA Structure - Execute Close-Down Command
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 sending Online
Retrieval Results direct to UFCO or Off-line Retrieval
Results indirectly via the Response Queue.
Fig. 4.1.2.3-23 shows the software structure.
fig. 4.1.2.3-23 RETR Structure
4.1.2.3.5 P̲A̲C̲ ̲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 Preparation Access Control
Coroutine (PAC) is outlined in fig. 4.1.2.3-24. PAC
is the controlling coroutine of the two UMAM coroutines,
thus the boxes marked INIT XXX in the structure charts,
simply denote that PAC initiates a task to be performed
by USFM. The control logic will be further described
in section 4.1.3.
4.1.2.3.6 U̲S̲F̲M̲ ̲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 User Status File Maintenance
Coroutine (USFM) is outline in fig. 4.1.2.3-25.
Fig. 4.1.2...3-24 PAC Software Structure
Fig. 4.1.2.3-25 USFM 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.
Thus the addition of VUS incarnations to the description
only adds one preparation queue per incarnation and
otherwise analogous flow and synchronization.
In fig. 4.1.3-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.
As seen from the arrow marked 1, it is not the message
or comment itself under preparation which are kept
in the preparation queue, but the current status and
the access key to the CIF where the item is kept by
MMS in temporary storage.
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
Now, the above statement is not the full truth, as
may be seen by reference to fig. 4.1.3-1. UMAM delivers
data to the VUS response queue, and this is done on
request from the VDU supervisor process. However, insertion
of elements in the response queue does not affect the
VUS processing at all. The same is the case for the
UMAM processing when elements are inserted in the preparation
queue by VUS.
The logic for access control and preparation database
maintenance cannot be derived fully from the dataflow
depicted in fig. 4.1.3-1.
The main rules for the maintenance of a preparation
queue are:
- VUS has only acccess to insert items in the preparation
queue.
- UMAM has access to update status of items in the
preparation queue and to remove items from it.
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. It should, however, be noted
that the VUS-UMAM process synchronization described
in this subsection is actually a synchronization between
the VUS UFCO coroutine and the UMAM PAC coroutine.
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.
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-3, an overview of the VUS coroutines
and the primitives (S1, S2, S3) used for synchronization
is depicted.
If a synchronization primitive is said to belong to
a coroutine, when it receives its input from that primitive,
i.e. executes a wait operation on that primitive, then
S1 belongs to VCO, S2 belongs to UFCO and S3 belongs
to VDIA. A coroutine defined within one process cannot
deliver input to a coroutine defined within another
process, i.e. a coroutine cannot execute a send operation
on a primitive external to the process in which it
is defined.
In the CAMPS system interprocess communication between
application processes is achieved through the Queue
Monitor (QMON) by executing a send command on a queue.
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̲ ̲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 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 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-8 VUS Coroutine Synchronization Overview
However, it is possible for a coroutine to await both
external (send operation on a queue) and internal (send
operation on a coroutine primitive) events in a coroutine
semaphore. This is achieved via the coroutine monitor
by using the ASSOCIATE Command.
On fig. 4.1.3-3 the arrows from the queues to the primitives
indicate that this facility is used.
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.
This can either be achieved through coding logic or
by using the mechanism available through system software
(INIT SYSTEM CALL, ASSOCIATE, CANCEL SYSTEM CALL).
The solution to be chosen will be determined during
detailed design.
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.
4.1.3.3 U̲M̲A̲M̲ ̲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 UMAM is depicted in fig.
4.1.3-4. The arrows marked 1 and 2 which merge into
the arrow marked 3, illustrate that an outgoing message
status to be delivered is extracted partly from the
relevant preparation queue (by PAC) and partly from
disk files (by USFM).
In fig. 4.1.3-5 an overview of the UMAM coroutines
and the primities (S0, S1, S2) used for synchronization
is depicted.
Using the same terminology as is 4.1.3.2, S0 and S1
belong to USFM and S2 belongs to PAC.
USFM has been assigned two primitives, to allow TEMCO
commands to be processed by USFM out of sequence, i.e.
TEMCO commands are sent to S0 by PAC whereas other
commands / requests are sent to S1.
USFM processes all input items received in S0 before
all those received in S1.
Fig. 4.1.3-4 Dataflow between UMAM Coroutines
Fig. 4.1.3-9 UMAM Coroutine Synchronization Overview.
4.1.4 C̲o̲m̲m̲o̲n̲ ̲D̲a̲t̲a̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲ ̲(̲I̲n̲t̲e̲r̲n̲a̲l̲)̲
Common internal data elements, i.e. data elements shared
between supackages, are contained in the accounting
area. The contents of this area are described in section
4.2.5.4. The accounting area is shared between UFCO
and VDIA.
4.1.5 E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲
TBD
4.1.6 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
4.1.6.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.6.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
4.1.6.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 section 4.2 and doc. no. CPS/ICD/009.
4.1.6.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 section 4.2 and doc. no. CPS/ICD/009.
4.1.6.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 section 4.2 and doc. no. CPS/ICD/009.
4.1.6.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 section 4.2 and doc. no. CPS/ICD/009.
4.1.6.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 section 4.2 and doc. no. CPS/ICD/009.
4.1.6.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 sections 4.2 and doc. no. CPS/ICD/009.
4.1.6.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 no. series) and VDIA (table access).
For details refer section 4.2 and doc. no. CPS/ICD/009.
4.1.6.3 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
4.1.6.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. Append Notification
6. Status Records.
F̲r̲o̲m̲ ̲U̲M̲A̲M̲ ̲t̲o̲ ̲V̲U̲S̲:
1. Access Key to CIF (QEL ref)
2. Delete Notification
3. Message Release Status
4. Outgoing Message Status
5. Delivery Status.
4.1.6.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. 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 Report
2. Restart UFCO CC Report
3. Stop UFCO CC Report
4. Close Down CC Report.
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 Report
2. Start VDIA CC Report
3. Clean Up CC Report
4. Close Down CC Report
5. Validation Result.
5̲.̲ ̲F̲r̲o̲m̲ ̲U̲F̲C̲O̲ ̲t̲o̲ ̲R̲E̲T̲R̲
None.
6̲.̲ ̲F̲r̲o̲m̲ ̲R̲E̲T̲R̲ ̲t̲o̲ ̲U̲F̲C̲O̲
1. SAR On-line / Off-line Retrieval Notification
2. On-line Retrieval / Append Result.
7.̲ ̲F̲r̲o̲m̲ ̲P̲A̲C̲ ̲t̲o̲ ̲U̲S̲F̲M̲
1. Status Records
2. Status Requests
3. Initialize CMD
4. Close Down CMD.
8̲.̲ ̲F̲r̲o̲m̲ ̲U̲S̲F̲M̲ ̲t̲o̲ ̲P̲A̲C̲
1. Outgoing Message Status
2. Message Release Status
3. Delivery Status
4. Initialize CC Report
5. Close Down CC Report.
