top - download
⟦8c295aa62⟧ Wang Wps File
Length: 53263 (0xd00f)
Types: Wang Wps File
Notes: CPS/SDS/023
Names: »1124A «
Derivation
└─⟦af7ebed0d⟧ Bits:30006042 8" Wang WCS floppy, CR 0067A
└─ ⟦this⟧ »1124A «
WangText
…00……00……00……00……1f……0a……00……00……1f……0b……1f… …1e……0e……1e……05……1d……0a……1d……0f……1d……01……1d……05……1d……06……1c……0d……1c……02……1c…
…1c……06……1b……08……1b……0c……1b……0d……1b……0e……1b… …1b……06……1b……07……1a……0c……1a……0d……1a…
…19……09……19……00……19… …18……0a……18……0e……18……00……18…
…18……06……17……0d……17……00……17……01……17… …86…1 …02… …02… …02…
…02…CPS/SDS/023
…02…BBC/810801…02……02…
TEP SUPERVISOR VDU PACKAGE
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 GENERAL .......................................
6
1.1 PURPOSE AND SCOPE .........................
6
1.2 APPLICABLE DOCUMENTS AND PROJECT REFERENCES
7
1.2.1 Applicable Documents ..................
7
1.2.2 Reference Documents ...................
7
1.3 TERMS AND ABBREVIATIONS ...................
8
1.3.1 Terms .................................
8
1.3.2 Abbreviations .........................
8
2 SUMMARY OF REQUIREMENTS .......................
9
2.1 PACKAGE DESCRIPTION .......................
9
2.2 PACKAGE FUNCTIONS .........................
16
2.2.1 Main Functions (Normal Operation) .....
19
2.2.1.1 Queue Status Display ..............
19
2.2.1.2 Information Concerning the Trans-
actions in Progress ...............
22
2.2.1.3 Display of Queued Information .....
22
2.2.1.4 Requests to CAMPS System ..........
24
2.2.1.5 Service Message Preparation .......
25
2.2.1.6 Maintenance and Update of Message
Status Files ......................
25
2.2.1.7 Supervisor Engineering Functions ..
25
2.2.2 Functional Responsibilities ...........
25
2.2.2.1 Initialization, Close-Down and
Restart ...........................
25
2.2.2.2 Checkpointing and Recovery ........
26
2.2.2.3 Error Detection and Error Handling
26
2.2.2.4 Integrity of Operation ............
26
2.2.2.5 Data Collection (Log, Statistics
and Reports) ......................
27
2.2.2.6 Security ..........................
27
2.3 CHARACTERISTICS ...........................
28
2.3.1 Timing ................................
28
2.3.2 Throughput ............................
28
2.3.3 Flexibility ...........................
29
2.3.4 Accuracy ..............................
29
3 ENVIRONMENT ...................................
30
3.1 EQUIPMENT .................................
30
3.2 SOFTWARE ..................................
30
3.2.1 System Software .......................
30
3.2.2 Development Support Software ..........
30
3.3 INTERFACES ................................
30
3.3.1 External Interfaces ...................
30
3.3.2 Package Interfaces ....................
30
3.3.2.1 SSC I/F ...........................
30
3.3.2.2 TMP I/F ...........................
31
3.3.2.3 CSF I/F ...........................
31
3.3.2.4 LOG I/F ...........................
31
3.3.2.5 SAR I/F ...........................
31
3.3.2.6 THP I/F ...........................
31
3.3.2.7 MDP I/F ...........................
31
3.3.2.8 SPRI I/F ..........................
32
3.3.2.9 UMAM I/F ..........................
32
3.3.2.10 VUS I/F ...........................
32
3.4 FUNCTIONS MAINTAINED BY OTHER PACKAGES ....
32
4 PACKAGE DESIGN ................................
33
4.1 PACKAGE OVERVIEW ..........................
33
4.1.1 Functional Specification ..............
37
4.1.1.1 TEMCO Control Functions ...........
39
4.1.1.2 Queue Status Maintenance ..........
41
4.1.1.3 Transaction Accounting ............
44
4.1.1.4 Transaction Interruption ..........
46
4.1.1.5 Command Interpretation ............
48
4.1.1.6 Command Execution .................
50
4.1.1.7 Start/Stop Transaction Execution ..
52
4.1.1.8 Preparation of Service Message ....
54
4.1.1.9 Presentation of Retrieved Message .
56
4.1.1.10 Requests to CAMPS System ..........
58
4.1.1.11 Dialogue Formatting ...............
71
4.1.1.12 Format Validation .................
73
4.1.1.13 Service Message Database
Maintenance .......................
75
4.1.2 Software Specification ................
79
4.1.2.1 SVCO Sub-Package ..................
81
4.1.2.2 SFCO Sub-Package ..................
86
4.1.2.3 SVDIA Sub-Package .................
95
4.1.2.4 SRETR Sub-Package .................
107
4.1.3 Dataflow and Control Logic ............
109
4.1.3.1 Process Dataflow and Process
Synchronization ...................
109
4.1.3.2 SVUP Internal Dataflow and
Coroutine Synchronization .........
112
4.1.3.2.1 Normal Functional Flow
(Major Transaction) ...........
115
4.1.3.2.2 Functional Flow (Initialization,
Close-Down, and Restart) ......
132
4.1.3.2.3 Functional Flow (Checkpointing
and Recovery) .................
132
4.1.3.2.4 Functional Flow (Error Detec-
tion, and Error Handling) .....
132
4.1.3.2.5 Functional Flow (Integrity
of Operation) .................
132
4.1.3.2.6 Functional Flow (Data
Collection) ...................
132
4.1.3.2.7 Functional Flow (Security) ....
132
4.1.4 Package Data ..........................
132
4.1.5 Common Data ...........................
132
4.1.6 Interfaces ............................
133
4.1.6.1 External Interfaces ...............
133
4.1.6.2 Package Interfaces ................
133
4.1.6.3 Sub-Package Interfaces ............
133
4.1.6.3.1 Process Interfaces ............
133
4.1.6.3.2 Coroutine Interfaces ..........
134
4.2.x Sub-Package Specifications ............
135
4.3 MEMORY LAYOUT .............................
135
1̲ ̲ ̲G̲E̲N̲E̲R̲A̲L̲
1.1 P̲U̲R̲P̲O̲S̲E̲ ̲A̲N̲D̲ ̲S̲C̲O̲P̲E̲
a) The Supervisor VDU Package Specification for the
CAMPS project/4040 is written to fulfil the following
objectives:
1) To provide a detailed definition of the Supervisor
VDU Package function and Software architecture.
2) To provide user operational and development
personnel with details of the ongoing analysis.
3) To define in detail the interfaces with other
packages and to describe their facilities.
b) The Supervisor VDU Package Specification defines
the functions and software architecture of the
package to a level sufficient for a programmer
to start detailed design with a minimum of design
effort.
The Supervisor VDU Package constitutes one of the
building blocks of the TEP package.
For an overall description of the TEP package refer
CPS/SDS/012.
All Supervisor VDU Package internal data and interfaces
are defined within this document in detail. For
a detailed data description of data external to
the Supervisor VDU package and interfaces to other
packages refer the Database Design document and
the relevant interface documents.
1.2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲ ̲A̲N̲D̲ ̲P̲R̲O̲J̲E̲C̲T̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
1.2.1 A̲p̲p̲l̲i̲c̲a̲b̲l̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
CAMPS System Requirement Specification
CPS/210/SYS/0001
Supervisor Commands and Procedures
CPS/230/ICD/0002
CAMPS System Design Specification
CPS/SDS/001
Database Design Document
CPS/DBD/001
CAMPS Software Interface Control Document
CPS/ICD/009
Terminal Package Design Specification
CPS/SDS/012
1.2.2 R̲e̲f̲e̲r̲e̲n̲c̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
DOCUMENT NAME DOCUMENT NUMBER
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
CAMPS System Functions CPS/SDS/002
Message Management CPS/SDS/003
System Status and Control CPS/SDS/004
Table Managment CPS/SDS/005
Input/Output Control CPS/SDS/006
Storage and Retrieval CPS/SDS/007
Statistics CPS/SDS/008
Logging CPS/SDS/009
Traffic Handling CPS/SDS/010
Message Distribution Package CPS/SDS/011
Supervisor Printer Package CPS/SDS/024
VDU MDCO Package CPS/SDS/025
VDU MSO Package CPS/SDS/026
VDU User Package CPS/SDS/027
OCR Package CPS/SDS/028
Printer Package CPS/SDS/029
1.3 T̲E̲R̲M̲S̲ ̲A̲N̲D̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
1.3.1 T̲e̲r̲m̲s̲
N/A.
1.3.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
SFCO Supervisor Function Control Coroutine
SRETR Supervisor Retrieval Coroutine
SUP Supervisor VDU Package
SVCO Supervisor VDU Control Coroutine
SVDIA Supervisor VDU Dialogue Coroutine
SVUP Supervisor VDU Process
2̲ ̲ ̲S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
2.1 P̲A̲C̲K̲A̲G̲E̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
The S̲upervisor VDU P̲ackage (SUP) contains the software
to support the three main supervisor functions as shown
on figure 2.1-1
S̲y̲s̲tem C̲ontrol (SYSC)
M̲es̲sag̲e H̲andling (MSGH)
S̲upervisor E̲n̲gineering F̲unctions (SENF)
The remaining s̲u̲p̲e̲r̲v̲i̲s̲o̲r̲y̲ ̲f̲u̲n̲c̲t̲i̲o̲n̲s̲ MDCO- and MSO functions
are defined in CPS/SDS/025 and CPS/SDS/026 respectively
and the Supervisor Print Functions in CPS/SDS/024.
The System Control Functions are the functions for:
Device Control
Addressing Scheme Control
User Profile Update
Queue Control
Report Control
Supervisor Printout Control
Security Control
Global No. Series Control
System Parameter Control
System Information Extract
Table Print
as defined in CPS/230/ICD/0002.
These functions allow the supervisor to control the
operational and functional aspects of the system.
Figure 2.1-1
The Message Handling Functions are the functions for:
a) S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Prepare New Plaindress Service Message
Prepare New Abbreviated Plaindress Service Message
Prepare New Abbreviated Service Message
Continue Plaindress Preparation
Continue Abbreviated Plaindress Preparation
Continue Abbreviated Service Message Preparation
Delete Service Message
Outgoing Service Message Status
b) R̲e̲t̲r̲i̲e̲v̲a̲l̲
Retrieval for Re-addressal
Retrieval for Rerun
Retrieval for Re-distribution
Retrieval for Local use
as defined in CPS/230/ICD/0002.
These functions allow the supervisor to prepare and
edit Service Messages, to send Service messages, to
delete Service Messages and to obtain status regarding
Service Messages under preparation or sent for transmission.
The retrieval functions allow the supervisor to retrieve
any message in a suitable format and dependent of this
format (ACP127, E1, E2) to specify re-addressal, rerun,
redistribution or local use.
The Supervisor Engineering Functions will allow the
supervisor to perform engineering/operator type functions
upon the system. Due to the nature of these functions
they will be defined during detailed design.
The Supervisor VDU Package interfaces with other parts
of the Terminal Package (TEP) as well as other packages
of the CAMPS System.
Fig. 2.1-2 shows the interface between the S̲upervisor
V̲DU P̲rocess (SVU̲P) and the other TEP processes:
Supervisor Print Process (SPRI)
VDU User Subprocess (VUS)
User Message Access Monitoring Process (UMAM)
UMAM is used for control of Service Messages under
preparation and shared with all VDU User Subprocesses.
VUS is the VDU User Subprocess giving the Supervisor
access to User Functions when he has User Capability,
MDCO Capability, or MSO Capability.
The Supervisor Functions are contained in a separate
process to ensure that access to these functions due
to application software malfunction cannot be obtained
by a person without Supervisor Capability.
Further to ensure that Supervisor Control over the
system can be maintained after failure of the Supervisor
VDU a second VDU can be connected to SVUP (by issuing
the Assign Supervisor command). Only one of these VDUs
can access VUS as a u̲s̲e̲r̲ only has access to o̲n̲e̲ VDU.
Further fig. 2.1-2 shows the interfaces to the other
CAMPS packages:
System Status and Control (SSC)
Table Management (TMP)
CAMPS System Functions (CSF)
LOG Package (LOG)
Storage and Retrieval (SAR)
Traffic Handling (THP)
Message Distribution (MDP)
Figure 2.1-2
1 GIVE QUEUE LENGTH FOR PRINT QUEUES
2 REQUEST QUEUE LENGTH FOR PRINT QUEUES
ACTIVATE: PASSWORD LIST, PROFILE PRINT, COMMAND
PRINT, TABLE PRINT, SYSTEM PARAMETER PRINT
SUPERVISOR PRINT CONTROL
3 PROFILE CHANGES
BLOCK/UNBLOCK
CONNECT/DISCONNECT
OPEN/CLOSE
MOUNT/DISMOUNT
4 PROFILE UPDATE
TABLE UPDATE
REORGANIZE/ABANDON REORGANIZATION
COPY SYSTEM PARAMETER FILE
COMMAND CONTROL
SECURITY CONTROL
GLOBAL NO SERIES CONTROL
SYSTEM PARAMETER CONTROL
5 QUEUE BLOCK/UNBLOCK
DELETE MESSAGE
6 SEND LOG RECORD
LOGTRACE
7 DISKCONTROL
8 STORE
RETRIEVE
9 READDRESSAL
RERUN
SERVICE MESSAGES
OPEN/CLOSE FOR INCOMING TRAFFIC
10 REDISTRIBUTION
11 12 SERVICE MESSAGES UNDER PREPARATION
OUTGOING SERVICE MESSAGE STATUS
13 REQUEST QUEUE LENGTH FOR ALL QUEUES
14 GIVE QUEUE LENGTH FOR ALL QUEUES
2.2 P̲A̲C̲K̲A̲G̲E̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
This section outlines the functions to be performed
by SUP.
The functions are called from one of the Supervisor
VDUs and SUP communicates with the Supervisor by displaying
Queue Status Information, Information on Current Transaction
and via commands from the Supervisor display of formats
for input of requests and Service Messages retrieved
from the HDB.
The functions available are grouped with respect to
relationship and guidance for selection is given by
SUP via Menus specifying the functions within the groups.
See fig. 2.2-1 and fig. 2.2-2.
Function keys (F/C Keys) on the Keyboard give the Supervisor
control over the format displayed and editing facilities
as well as entry of commands to the system.
Security related functions such as sign-on/sign-off
are performed by SSC (TEMCO) and signalled by use of
a special F/C key SYSTEM ̲BREAK from the keyboard.
fig. 2.2-1
fig. 2.2-2
2.2.1 M̲a̲i̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲(̲N̲o̲r̲m̲a̲l̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲)̲
The main functions implemented by SUP are:
1. Continuous display of queue status information
2. Continuous display of information concerning the
transaction in progress
3. The means for display of queued information
4. The means for directing requests to CAMPS and deliver
responses.
5. The means for Service Message preparation
6. Maintain and Update Message Status Files
7. Supervisor Engineering Functions
2.2.1.1 Q̲u̲e̲u̲e̲ ̲S̲t̲a̲t̲u̲s̲ ̲D̲i̲s̲p̲l̲a̲y̲
The upper 5 lines of the VDU screen is named VDU Header
Area ref. fig. 2.2-3.
The second line of the VDU Header Area is used for
Queue Status Display and updated regularly (every minute).
The queues in question are:
1. User Queue: this contains the total number of elements
queued for the Supervisor VDU User Subprocess.
2. Supervisor Print Queue: this contains the total
number of elements queued for the Supervisor Print
Process (SPRI) in the Supervisor Print Queue.
3. Report Print Queue: this contains the total number
of elements queued for SPRI in the Report Print
Queue.
4. Log Print Queue: this contains the total number
of elements queued for SPRI in the Log Print Queue.
5. Statistics Print Queue: this contains the total
number of elements queued for SPRI in the Statistics
Print Queue.
6. Response Queue: this contains the total number
of elements queued for SVUP in the Response Queue.
Together with update of the Queue Status Display the
date/time field on the first line is updated.
fig. 2.2-3
2.2.1.2 I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲c̲e̲r̲n̲i̲n̲g̲ ̲t̲h̲e̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲i̲n̲ ̲P̲r̲o̲g̲r̲e̲s̲s̲
The first line of the VDU Header Area is used to identify
the Transaction in progress (i.e. the Supervisor Function
called upon) and the classification of the information
currently accessed.
Whenever the classification is unknown or no transaction
is in progress the maximum classification to which
the supervisor may gain access through this VDU is
displayed.
2.2.1.3 D̲i̲s̲p̲l̲a̲y̲ ̲o̲f̲ ̲Q̲u̲e̲u̲e̲d̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
Information queued for display is queued in the Response
Queue. This will be Messages retrieved which were off-line
when the retrieval request was issued.
The Supervisor may gain access to the information by
giving the command RESP. SVUP then enters the Response
Mode of operation and the Supervisor may inspect element
in the queue one by one, remove them and/or request
a printed copy. This is done by means of the F/C Keys
Keep and Present next, Delete and Present next, Print,
Cancel.
The queue is accessed in FIFO manner. To exit the Response
Mode of operation the Supervisor activates the Return
to current menu F/C key. Ref. fig. 2.2-4.
Figure 2.2-4
2.2.1.4 R̲e̲q̲u̲e̲s̲t̲s̲ ̲t̲o̲ ̲C̲A̲M̲P̲S̲ ̲S̲y̲s̲t̲e̲m̲
These are all the requests covered by the SYSC Menu
(Ref. CPS/230/ICD/0002 and fig. 2.2-1)
These functions can be called either by going down
via the appropriate menus or by issuing the appropriate
commands directly.
Going up via menus is accomplished by (possibly repeated)
use of the Return to current Menu F/C Key or by giving
the name of the menu as a command.
Requests are processed in 4 phases:
1. Display of requested information (e.g. User Profile)
for inspection and update.
2. Validation of updated information.
3. Display of validated information together with
either error codes or an invitation to confirm
the update request.
4. Validation of Confirmation Code and performance
of the actual update or in case of Cancel F/C key
no updating.
2.2.1.5 S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲
These are all the functions covered by the SMPR Menu
(Ref. CPS/230/ICD/0002) and figure 2.2-2.
The functions can be called either directly or via
the appropriate menus.
The functions support creation of Service messages
and storage in the Preparation Database, recall and
editing of Service Messages, Deletion from the Preparation
Database and display of Outgoing Service Message Status.
The preparation is performed in 5 phases:
1. Display of empty format for entry of Service Message
Header.
2. Input and validation of header.
3. Display of header with error codes or when error
free header is entered display of empty format
for entry of text.
4. Input of text and validation.
5. Display of text with error codes or format for
entry of message treatment decision (defer or send).
2.2.1.6 M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲a̲n̲d̲ ̲U̲p̲d̲a̲t̲e̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲S̲t̲a̲t̲u̲s̲ ̲F̲i̲l̲e̲s̲
These functions maintain the Outgoing Service Message
Status for Service Messages under preparation.
The display of Outgoing Service Message status is available
via the OSMS-command (ref. CPS/230/ICD/0002).
At 24.00 hours the Outgoing Message Status is queued
for print at the Supervisor Printer and the Message
Status File is cleared.
2.2.1.7 S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲E̲n̲g̲i̲n̲e̲e̲r̲i̲n̲g̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
TBD.
2.2.2 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲R̲e̲s̲p̲o̲n̲s̲i̲b̲i̲l̲i̲t̲i̲e̲s̲
2.2.2.1 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲,̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲ ̲a̲n̲d̲ ̲R̲e̲s̲t̲a̲r̲t̲
SUP performs the above functions on command from TEMCO.
1. Initialization: This is initialization of the SVUP
process making the controling units (coroutines)
ready to run. It also includes initialization of
the Coroutine Monitor and the Format Handler of
the IOC Software. Upon completion a command completion
report is returned to SSC (TEMCO).
2. Close Down: This is termination of the current
processing in an ordered manner setting SVUP into
a state ready for restart.
3. Restart: This is performed after Close Down, Switchover
and Total System Failure and contains the elements
described for Initialization with the addition
of processing queue elements marked as "recovered".
2.2.2.2 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
Checkpointing is performed by calling the SAVE-function
(CSF-function) at appropriate points, that is when
a message is created, updated, and sent to queues in
the system.
Recovery is performed during restart and is processing
of queue elements returned by CSF and marked "recovered".
(E.g messages marked "recovered" found in the Answer
Queue are sent to the UMAM process).
2.2.2.3 E̲r̲r̲o̲r̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Errors detected by SUP are reported to SSC for decision
on what type of action shall be taken. (e.g. Ignore,
Terminate, Process, etc.).
2.2.2.4 I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
SUP shall contain credibility check to contain the
effects of corrupt or inaccurate data to the extent
this does not introduce redundant processing which
will decrease the system throughput.
It shall be a design aim that wherever possible the
consequence of a single software fault incident will
not affect more than one transaction. The detection
of an inconsistency indicating a fault shall initiate
a report and the re-processing from a validated checkpoint
in an attempt to recover with a minimum of discontinuity.
Only after further failures should major recovery or
operator intervention action be invoked.
2.2.2.5 D̲a̲t̲a̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲ ̲(̲L̲O̲G̲,̲ ̲S̲T̲A̲T̲I̲S̲T̲I̲C̲S̲,̲ ̲a̲n̲d̲ ̲R̲e̲p̲o̲r̲t̲s̲)̲
1. L̲o̲g̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
The log data delivered by SUP to the LOG-Package
are final log information upon completion of a
transaction.
The data are:
Terminal Designator
Transaction Serial Number
Format Identification
Log time
Item Reference ID
Exit Code
Start Time of Transaction
Month and Day
2 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
N/A.
3 R̲e̲p̲o̲r̲t̲s̲
The following reports are generated to the Supervisor
Print Package:
a) Security Report: Unsuccessful System Integrity
Check.
b) Command Completion Report: Termination of processing
of supervisor command.
2.2.2.6 S̲e̲c̲u̲r̲i̲t̲y̲
SUP maintains a list of all Supervisor commands together
with their (possibly) associated Permissive Entry Code
(PEC) and (possibly) Restrictive Warning Text.
This list is used during validation of any command
issued to the system from the Supervisor VDUs.
2.3 C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
2.3.1 T̲i̲m̲i̲n̲g̲
The following requirements extracted from CPS/210/SYS/0001
shall be fulfilled by SUP.
S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲y̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲R̲e̲s̲p̲o̲n̲s̲e̲ ̲(̲3̲.̲4̲.̲1̲.̲6̲.̲5̲)̲
Response time shall be measured as of 3.4.1.6.3 c.
The response time is time to acceptance of command
parameters (i.e. request for new input).
Response time for commands entered via the command
line or via a format display shall be less than 5 seconds
for 99% of all commands.
The above time shall never exceed 10 seconds.
U̲s̲e̲r̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲a̲c̲t̲i̲o̲n̲ ̲(̲3̲.̲4̲.̲1̲.̲6̲.̲3̲)̲
c) During interactive transactions at VDUs the response
time shall be measured as the time delay from transmission
of the last character of the input to the system
and the start of display of response/next format/menu.
1) Response times for entry in the command line
shall not exceed 1 second in 90% of all cases.
2) Response times for validation of a request
(e.g. retrieval, status) shall not exceed 5
seconds in 90% of all cases.
3) Response times for validation of information
(e.g. message, edited message) shall not exceed
10 seconds per VDU page in 90% of all cases.
2.3.2 T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲
The following characteristics extracted from CPS/210/SYS/0001
apply to SUP:
M̲e̲s̲s̲a̲g̲e̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲ ̲(̲3̲.̲4̲.̲1̲.̲1̲)̲
M̲e̲s̲s̲a̲g̲e̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲ ̲(̲3̲.̲4̲.̲1̲.̲1̲.̲1̲)̲
d) Service Messages have an average length of 400
characters.
e) Service Messages have a maximum length of 12000
characters.
f) Maximum 5% of Service Messages exceed 100 characters
in length.
2.3.3 F̲l̲e̲x̲i̲b̲i̲l̲i̲t̲y̲
The design shall ensure that changes to formats and
format tolerances can be implemented with ease to facilitate
improvement of the MMI useability.
Addition of new formats is straight forward, but software
to support the new functions will probably need to
be developed.
2.3.4 A̲c̲c̲u̲r̲a̲c̲y̲
Time shall be accurate within +/- 500 ms.
All other data be that input or output shall be exact.
3̲ ̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
3.1 E̲Q̲U̲I̲P̲M̲E̲N̲T̲
TBD.
3.2 S̲O̲F̲T̲W̲A̲R̲E̲
3.2.1 S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
TBD.
3.2.2 D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
TBD.
3.3 I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
3.3.1 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Ref. Supervisor Procedures (CPS/230/ICD/0002)
3.3.2 P̲a̲c̲k̲a̲g̲e̲-̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
3.3.2.1 S̲S̲C̲ ̲I̲/̲F̲
PROFILE CHANGES
BLOCK/UNBLOCK
CONNECT/DISCONNECT
OPEN/CLOSE
MOUNT/DISMOUNT
3.3.2.2 T̲M̲P̲ ̲I̲/̲F̲
PROFILE UPDATE
TABLE UPDATE
REORGANIZE/ABANDON REORGANIZATION
COPY SYSTEM PARAMETER FILE
COMMAND CONTROL
SECURITY CONTROL
GLOBAL NO SERIES CONTROL
SYSTEM PARAMETER CONTROL
3.3.2.3 C̲S̲F̲ ̲I̲/̲F̲
QUEUE BLOCK/UNBLOCK
DELETE MESSAGE
3.3.2.4 L̲O̲G̲ ̲I̲/̲F̲
SEND LOG RECORD
LOGTRACE
3.3.2.5 S̲A̲R̲ ̲I̲/̲F̲
DISKCONTROL
STORE
RETRIEVE
3.3.2.6 T̲H̲P̲ ̲I̲/̲F̲
READDRESSAL
RERUN
SERVICE MESSAGES
OPEN/CLOSE INCOMING CHANNEL TRAFFIC
3.3.2.7 M̲D̲P̲ ̲I̲/̲F̲
REDISTRIBUTION
3.3.2.8 S̲P̲R̲I̲ ̲I̲/̲F̲
GIVE QUEUE LENGTH FOR PRINT QUEUES
REQUEST QUEUE LENGTH FOR PRINT QUEUES
ACTIVATE: PASSWORDLIST, PROFILE PRINT, COMMAND PRINT,
TABLE PRINT, SYSTEM PARAMETER PRINT
SUPERVISOR PRINT CONTROL
REPORT CONTROL
3.3.2.9 U̲M̲A̲M̲ ̲I̲/̲F̲
SERVICE MESSAGES UNDER PREPARATION
OUTGOING SERVICE MESSAGE STATUS
3.3.2.10 V̲U̲S̲ ̲I̲/̲F̲
QUEUE LENGTH FOR ALL QUEUES
3.4 F̲U̲N̲C̲T̲I̲O̲N̲S̲ ̲M̲A̲I̲N̲T̲A̲I̲N̲E̲D̲ ̲B̲Y̲ ̲O̲T̲H̲E̲R̲ ̲P̲A̲C̲K̲A̲G̲E̲S̲
The following functions are performed by TEMCO (SSC):
Sign-on Procedure
Select SUPV capability
Security Warning
Sign-off procedure
on behalf of SUP.
4̲ ̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲D̲E̲S̲I̲G̲N̲
4.1 P̲A̲C̲K̲A̲G̲E̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
The S̲upervisor VDU-P̲ackage (SUP) consists of 2 processes.
One process containing the software required to support
the VDU handling and one containing software to control
the Preparation Database. The latter UMAM is shared
with the V̲DU U̲ser P̲ackage (VUP) (as will be specified
later) and is only used in connection with preparation
of Service Messages.
An overview of the S̲upervisor V̲DU̲ P̲rocess (SVUP) is
shown on fig. 4.1-1. It consists of 4 sub-packages
(or coroutines) as specified in sec. 4.1.2):
a) SVCO (S̲upervisor V̲DU C̲o̲ntrol) which reacts upon
commands from TEMCO and controls the other coroutines
as well as maintaining the VDU Header Status Area.
b) SFCO (S̲upervisor F̲unction C̲o̲ntrol) which reacts
upon commands from SVCO, F/C Keys (Function Keys)
from Keyboard and input from the Answer Queue and
Response Queue. It also receives input from the
Retrieve Coroutine (SRETR) and controls the Dialogue
Coroutine (SVDIA).
It contains all the functions for c̲o̲n̲t̲r̲o̲l̲ of the
M̲an M̲achine I̲nterface (MMI) and interfacing to
other packages as well as command execution.
c) SVDIA (S̲upervisor V̲DU D̲i̲a̲loque) which performs
input and output to and from the VDU format area
and validation of input data on command from SFCO.
d) SRETR (S̲upervisor R̲e̲t̲r̲i̲eval) which receives answers
(messages or error-codes) from SAR on requests
sent to SAR from SFCO. It communicates on-line
retrieval results to SFCO and off-line retrieval
results to the Response Queue.
Communication with other packages (apart from Monitor
Calls) is done via queues. The SVUP has 4 input
queues:
Command Queue: Commands from TEMCO and timer
events from Timer Monitor
Answer Queue: Answers to requests to other packages.
Response Queue: Off-line Retrieval Results (placed
in the queue by SRETR).
Retrieve Queue: Retrieval results (off-line and
on-line) from SAR.
The detailed analysis leading to the breakdown
of SVUP into these 4 sub-packages is similar to
the one presented in CPS/SDS/027 (VUP) and thus
shall not be repeated in this document (ref section
4.1.3.2).
Figure 4.1-1
1. Commands from SSC (e.g. start, stop) and timer
events.
2. Timer initiated update of VDU header (queues, time)
3. Control information from SVCO to SFCO
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 for supervisor attention and access.
10. Retrieve finished signal to SFCO and on-line retrieval
results.
11. Answers to requests and retrieved messages.
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̲
This section contains an analysis of the main functions
to be performed by SUP.
The analysis is carried out to a level where self-contained
sub-functions can be identified. Further the analysis
identifies concurrency and priority of the sub-functions
identified.
The first level break-down of the SUP-functions is
shown on figure 4.1-2. The following main functions
are identified and broken down in this section.
TEMCO CONTROL FUNCTIONS:
These implement the TEMCO Commands (Init, start, stop,
close-down, etc.).
QUEUE STATUS MAINTENANCE:
These maintain the VDU Header Status Area.
SUPERVISOR TRANSACTION CONTROL:
These are the bulk of the package functions controlling
the MMI and performing the Supervisor transactions.
SERVICE MESSAGE DATABASE MAINTENANCE:
These functions perform access control and Status Maintenance
for Service Messages under preparation.
Figure 4.1-2
4.1.1.1 T̲E̲M̲C̲O̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Functional breakdown of these functions is shown in
figure 4.1-3.
INITIALIZATION is performed on command from TEMCO during
start of the CAMPS System.
RESTART is performed on command from TEMCO during recovery
from a system failure (switchover or total system failure).
CLOSE-DOWN is performed on command from TEMCO during
Ordered System Close Down.
START SESSION is performed on command from TEMCO following
a successful SIGN-ON procedure.
STOP SESSION is performed on command from TEMCO following
a SIGN-OFF procedure.
CLOSE TEMPORARILY is performed on command from TEMCO
when a security interrogation is to be performed.
RESUME is performed subsequent to CLOSE TEMPORARILY
on command from TEMCO following a successful security
interrogation.
Figure 4.1-3
4.1.1.2 Q̲u̲e̲u̲e̲ ̲S̲t̲a̲t̲u̲s̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
Functional breakdown of these functions is shown in
figure 4.1-4. The functions are all performed on timer
request (every minute).
UPDATE DTG FIELD:
The date-time-group is updated to reflect current time.
UPDATE USER ̲QUEUE LENGTH FIELD:
This field contains the total number of elements in
all queues to the VDU User Process controlling the
VDU from which the supervisor can exercise his USER/MDCO/MSO-
CAPABILITIES (if any). This does not have to be the
same VDU as the one controlled by SVUP as the system
has 2 Supervisor VDUs and a USER (Supervisor exercising
USER functions) can only sign-on at o̲n̲e̲ VDU). The field
is updated to reflect current state of the VUS-Queues.
UPDATE SUPERVISOR PRINT-QUEUE LENGTH FIELD:
This field contains the total number of elements queued
for the S̲upervisor P̲r̲i̲nt Process (SPRI) for the Supervisor
Printer. It is updated to reflect current state of
the Supervisor Print Queue.
UPDATE LOG PRINT - QUEUE LENGTH FIELD:
This field contains the total number of elements queued
for SPRI in the Log Print Queue. It is updated to reflect
current state of the queue.
UPDATE REPORT PRINT - QUEUE LENGTH FIELD:
This field contains the total number of elements queued
for SPRI in the Report Print Queue. It is updated to
reflect current state of the queue.
UPDATE STATISTICS PRINT-QUEUE LENGTH FIELD:
This field contains the total number of elements queued
for SPRI in the Statistics Print Queue. It is updated
to reflect current state of the queue.
UPDATE RESPONSE QUEUE LENGTH FIELD:
This field contains the total number of elements queued
for SVUP in the Response Queue. It is updated to reflect
current state of the queue.
DISPLAY QUEUE STATUS INFORMATION:
This function performs the actual display of the VDU
Header Queue Status Line.
Figure 4.1-4
4.1.1.3 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲A̲c̲c̲o̲u̲n̲t̲i̲n̲g̲
Functional break-down of these functions is shown in
figure 4.1-5.
ASSIGN TRANSACTION DESIGNATOR:
This function assigns a Transaction Designator to the
transaction started.
COLLECT LOG DATA:
This function collects initial and final log information.
FINAL LOG REPORTING:
This function sends log information to the LOG-package
upon completion of the current transaction.
figure 4.1-5
4.1.1.4 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲I̲n̲t̲e̲r̲r̲u̲p̲t̲i̲o̲n̲
Functional breakdown of these functions is shown in
figure 4.1-6. The functions are performed when an F/C
Key Interrupt occurs.
FETCH FUNCTION KEY:
This function analyses the F/C Key Interrupt to identify
the F/C Key.
CHECK RECEIVED F/C KEY ALLOWED:
This function checks that the F/C key is valid in the
current context (at this stage in the transaction).
DISPLAY ERROR MESSAGE:
This function performs display of the appropriate error
message in the case where the F/C key is invalid.
EXECUTE F/C KEY FUNCTIONS:
This function performs the function corresponding to
the F/C Key.
Figure 4.1-6
4.1.1.5 C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲a̲t̲i̲o̲n̲
Functional breakdown of these functions is shown in
figure 4.1-7. The functions are performed when a command
is entered on the Command line of the VDU header.
COMMAND VALIDATION is performed to check that the command
is a valid Supervisor Command and acceptable in the
current context.
PERMISSIVE ENTRY CODE VALIDATION is performed if a
PEC is specified for the command entered.
COMMAND PARAMETER VALIDATION is performed on parameters
entered with the command (if any).
DISPLAY RESTRICTIVE WARNING TEXT is performed if such
a text exists for the command entered.
DISPLAY ERROR MESSAGE is performed if CMD, parameter
or PEC is not acceptable.
Figure 4.1-7
4.1.1.6 C̲o̲m̲m̲a̲n̲d̲ ̲E̲x̲e̲c̲u̲t̲i̲o̲n̲
Functional breakdown for these functions is shown in
figure 4.1-8.
CREATE NEW CIF is done via call to Message Monitor
when preparation of a Service Message shall be performed.
FETCH REFERENCED CIF is done via request to UMAM when
editing of a Service Message shall be performed.
DISPLAY ERROR MESSAGE is performed when referenced
CIF cannot be accessed.
OPEN FOR QUEUE ACCESS is performed when a reception
CMD is received.
REQUEST COMMAND EXECUTION initiates the REQUEST to
CAMPS SYSTEM - functions.
OUTPUT REQUESTED NO OF LINES is performed when an INSERT
LINES CMD is entered.
DELETE REQUESTED NO OF LINES is performed when a DELETE
LINES CMD is entered.
RETURN CURSOR returns the cursor to the position where
it was when the CMD-key was activated (prior to INSERT/DELETE
LINES CMDs).
DEFINE VALID COMMANDS defines the commands valid in
the context of the current transaction.
Figure 4.1-8
4.1.1.7 S̲t̲a̲r̲t̲/̲S̲t̲o̲p̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲E̲x̲e̲c̲u̲t̲i̲o̲n̲
Functional break-down of these functions is shown in
figure 4.1-9.
CREATE NEW CIF VERSION is performed when an editing
transaction is started.
GET NEXT QUEUED CIF is performed when a message (or
service message) from the Response Queue is requested.
RETURN CIF TO PDB is performed when a Service Message
Preparation Transaction is terminated with a DEFER
request.
REQUEST UPDATE OF OUTGOING MESSAGE STATUS is performed
when a Service Message Preparation Transaction is terminated
with a SEND-request.
DELETE CIF VERSION is performed when a Service Message
Preparation Transaction is terminated by F/C Key CANCEL.
REMOVE CIF FROM QUEUE is performed when a Presentation
Transaction is terminated by F/C Key DELETE AND PRESENT.
RETURN CIF TO QUEUE is performed when a Presentation
Transaction is terminated by F/C Key KEEP AND PRESENT.
REQUEST ACCESS TO CIF is performed via request to UMAM
when a Preparation or Presentation Transaction shall
start.
GIVE UP ACCESS TO CIF is performed via request to UMAM
when a Preparation or Presentation Transaction shall
stop.
CLEAR USED WORK SPACE is performed when a Preparation
or Presentation Transaction has stopped.
Fig. 4.1-9
4.1.1.8 P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲
Functional breakdown of these functions is shown on
figure 4.1-10.
OUTPUT TRANSACTION INFORMATION IN HEADERLINE is performed
when a Preparation Transaction is started.
DEFINE ALLOWED F/C KEY INTERRUPTS defines the F/C Keys
allowed in the context of the current transaction.
OUTPUT MESSAGES HEADER initiates display of the Header
Format with empty fields for preparation of a new Service
Message and with field contents for editing of a Service
Message.
INPUT MESSAGE HEADER initiates input of the header
part of the message when the ENTER F/C Key is activated.
OUTPUT MESSAGES TEXT initiates display of the Text
Format with or without contents when the previously
entered header is accepted.
INPUT MESSAGES TEXT initiates input of the text part
of the message when the ENTER F/C Key is activated.
OUTPUT MESSAGE TREATMENT FORMAT initiates display of
the format for entry of SEND or DEFER decision.
Figure 4.1-10
4.1.1.9 P̲r̲e̲s̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲R̲e̲t̲r̲i̲e̲v̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲
Functional breakdown of these functions is shown in
figure 4.1-11.
OUTPUT TRANSACTION INFORMATION IN HEADER LINE is performed
when a Presentation Transaction is started.
DEFINE ALLOWED F/C KEY INTERRUPTS defines the F/C Keys
allowed in the context of the current transaction.
DISPLAY RETRIEVED SERVICE MESSAGE initiates display
of the message requested from the response queue.
FETCH SAR ERROR CODES is performed if the off-line
Retrieval request was unsuccessful.
ERROR CODE FORMAT DISPLAY is performed to give details
of reason for failure of off-line retrieval.
Figure 4.1-11
4.1.1.10 R̲e̲q̲u̲e̲s̲t̲s̲ ̲t̲o̲ ̲C̲A̲M̲P̲S̲ ̲S̲y̲s̲t̲e̲m̲
Functional breakdown of these functions is shown in
figure 4.1-12.
SYSTEM CONTROL REQUESTS are the requests made available
via the SYSC MENU (ref CPS/230/ICD/0002) and a further
breakdown is shown in figure 4.1-13 to figure 4.1-21.
RETRIEVAL REQUESTS are the requests made available
via the RETV Menu (ref CPS/230/ICD/0002) and a further
breakdown is shown in figure 4.1-22.
MESSAGE TREATMENT REQUESTS are the operations that
can be performed upon a prepared Service Message. A
further breakdown is shown in figure 4.1-23.
OUTGOING MESSAGE STATUS REQUEST is the requests made
available via the OSMS command.
PRINT REQUESTS are the requests for print of messages/service
messages signalled by activation of the PRINT F/C Key.
SUPERVISOR ENGINEERING REQUESTS: Details are TBD.
Figures 4.1-12 to 4.1-23
4.1.1.11 D̲i̲a̲l̲o̲g̲u̲e̲ ̲F̲o̲r̲m̲a̲t̲t̲i̲n̲g̲
Functional breakdown of these functions is shown in
figure 4.1-24. The functions are all calls on the Monitor
Procedures of the FORMAT HANDLER in the IOC Package.
Via these procedures the actual communication with
the VDU Format Area is performed. For details ref.
CPS/SDS/006.
Figure 4.1-24
4.1.1.12 F̲o̲r̲m̲a̲t̲ ̲V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲
Functional breakdown of these functions is shown in
figure 4.1-25.
HEADER FORMAT VALIDATION is performed after entry of
message header during Service Message Preparation.
TEXT FORMAT VALIDATION is performed after entry of
message text during Service Message Preparation.
REQUEST FORMAT VALIDATION is performed after entry
of a request. (This also covers msg treatment requests).
DISPLAY ERROR CODE FORMAT is performed when errors
are found during validation.
Figure 4.1-25
4.1.1.13 S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲D̲a̲t̲a̲b̲a̲s̲e̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
Functional breakdown of these functions is shown in
figure 4.1-26 to 4.1-28. The functions are a subset
of the functions defined in CPS/SDS/027 (VUP) for UMAM
(USER MESSAGE ACCESS MONITORING) and as this process
is shared with VUS details of the functional breakdown
can be found in this document.
Figure 4.1-26 to -28
4.1.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This section describes the mapping of the functions
specified in section 4.1.1 onto software components.
Figure 4.1-29 shows the mapping of functions onto processes
and coroutines. As can be seen SUP consists of the
two processes mentioned in section 4.1.
SVUP contains the coroutines:
SVCO S̲upervisor V̲DU C̲o̲ntrol
SFCO S̲upervisor F̲unction C̲o̲ntrol
SVDIA S̲upervisor V̲DU D̲i̲a̲logue
SRETR S̲upervisor R̲e̲t̲r̲ieval
and UMAM contains the coroutines:
PAC P̲reparation Database A̲ccess C̲ontrol
USFM U̲ser S̲tatus F̲ile M̲aintenance
The detailed analysis leading to the software structure
of SVUP is very similar to the one described for VUP
(CPS/SDS/027) and as UMAM (ref. CPS/SDS/027) covers
the facilities required by SERVICE DATABASE MAINTENANCE
FUNCTIONS this process is shared with VUP and thus
not described in this section.
The rest of this section describes the functions allocated
to the sub-packages (coroutines). The functions can
be divided into two types:
1) Functions mapped from functional breakdown
2) Functions related to communication between software
components (coroutines and processes).
As the former functions are described in section 4.1.1
only the latter functions will be described in this
section. (The functions mapped from functional breakdown
are presented in highlighted boxes in this section).
Figure 4.1-29
4.1.2.1 S̲V̲C̲O̲ ̲S̲u̲b̲-̲P̲a̲c̲k̲a̲g̲e̲
This coroutine is the controlling coroutine within
the process. It accepts commands from TEMCO and controls
SFCO via commands and processes completion reports
from SFCO corresponding to the commands.
It also maintains the VDU Queue Status Line every minute
activated by a timer event.
Figures 4.1-30 to 4.1-33 show the software structure.
Figures 4.1-30 to -33
4.1.2.2 S̲F̲C̲O̲ ̲S̲u̲b̲-̲P̲a̲c̲k̲a̲g̲e̲
This coroutine controls input/output to and from the
VDU and the communication with other packages.
It accepts commands from SVCO and controls SVDIA via
commands and processes completion reports from SVDIA
corresponding to the commands.
It communicates with SVCO by sending completion reports
corresponding to commands received from SVCO.
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 SVDIA.
Figures 4.1-34 to 4.1-41 show the software structure.
Figure 4.1-34 to -41
4.1.2.3 S̲V̲D̲I̲A̲ ̲S̲u̲b̲-̲P̲a̲c̲k̲a̲g̲e̲
This coroutine performs input/output to and from the
format area of the VDU and validation and storing of
input.
It accepts commands from SFCO and sends completion
reports corresponding to these commands.
It communicates with the VDU via the Format Handler
of the IOC Package and accesses data in the Internal
Message Format (IMF) via the Message Monitor of the
CSF Package.
Figures 4.1-42 to 4.1-52 show the software structure.
Figure 4.1-42 to -52
4.1.2.4 S̲R̲E̲T̲R̲ ̲S̲u̲b̲-̲P̲a̲c̲k̲a̲g̲e̲
This coroutine receives input from SAR via the Retrieve
Queue and communicates with SFCO.
This communication is done by SRETR sending On-line
Retrieval Results directly to SFCO and Off-line Retrieval
Results indirectly via the Response Queue.
Figure 4.1-53 shows the Software Structure.
Figure 4.1-53
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̲
This section describes the Data Flow between the SUP
processes and coroutines and the Control Logic used
to synchronize the execution of the 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̲
SVUP communicates with UMAM during preparation and
editing of Service Messages. When Service Messages
are sent to THP status changes temporarily and when
Transmitted (accepted by THP) permanently.
Outgoing Message Status Requests (OSMS cmd) are also
handled by communication with UMAM.
Figure 4.1-54 shows the communication between SVUP
and UMAM.
Figure 4.1-54
1 Current Access State of Service Message
Temporary Outgoing Message Status Entry
Access Key (Q-Elem) to CIF (Service Message)
2 Permanent Entry in Outgoing Message Status
3 Access Key (Q-Elem) to CIF (Service Message)
Outgoing Service Message Status.
4.1.3.2 S̲V̲U̲P̲ ̲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 4 coroutines contained within SVUP synchronize
as shown on figure 4.1-55.
The general principle is that a running coroutine is
allowed to run until it issues a wait operation. Then
the coroutine with highest priority ready to run is
started. A coroutine is ready to run when an event
for which it has issued a wait instruction takes place.
SVCO waits for the S1 Semaphore. S1 is associated with
the Command Queue and thus as soon as an element is
sent to this SVCO is ready to run. Elements sent to
this queue are TEMCO commands and Timer events. SVCO
has highest priority as it controls the process. SVCO
Signals the S2 Semaphore in order to start SFCO.
SFCO waits for S2. S2 is associated with F/C Key interrupts
from the VDU via IOC and with the Answer Queue.
As the only way a VDU can communicate with SVUP is
via F/C Keys SFCO controls the operation of the VDU
(MMI).
SFCO is also activated by SVCO signalling S2 and will
then process commands passed from SVCO.
When SRETR signals S2 SFCO will get a Retrieval Result
passed to it from SRETR.
The access to the Response Queue is direct in the way
that SFCO does not wait for input to the queue, but
on request from the Supervisor (RESP-cmd) accesses
the queue.
SFCO signals the S3 semaphore in order to start SVDIA.
SVDIA waits for S3. When S3 is signalled SVDIA receives
commands from SFCO. SVDIA performs input/output to
and from the VDU format area on request by SFCO and
informs SFCO of completion by signalling S2 and passing
a Command Completion Report to SFCO.
SRETR waits for input in the Retrieve Queue. When a
retrieval request is sent to SAR by SFCO SAR answers
back by sending a Retrieval Result to the Retrieve
Queue. If the retrieved item is on-line SRETR passes
the item directly to SFCO (by signalling S2).
If the retrieved item is off-line SRETR will send the
item to the Response Queue. SAR error codes will be
treated the same way in the two cases.
SFCO will have lower priority than SVCO but higher
than SVDIA and SRETR to ensure proper control, and
SVDIA and SRETR will have equal priority.
Figure 4.1-55
4.1.3.2.1 N̲o̲r̲m̲a̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲F̲l̲o̲w̲ ̲(̲M̲a̲j̲o̲r̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲s̲)̲
This section contains a functional flow for a major
(typical) transaction:
1. SIGN ON
2. SELECT SUPERVISOR CAPABILITY
3. USER PROFILE UPDATE (UPUP-CMD)
4. SIGN OFF
The Following HIPO diagrams illustrates the flow.
16 L@KRE HIPO DIAGRAMMER
4.1.3.2.2 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲F̲l̲o̲w̲ ̲(̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲,̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲,̲ ̲R̲e̲s̲t̲a̲r̲t̲)̲
TBD
4.1.3.2.3 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲F̲l̲o̲w̲ ̲(̲C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲)̲
TBD
4.1.3.2.4 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲F̲l̲o̲w̲ ̲(̲E̲r̲r̲o̲r̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲)̲
TBD
4.1.3.2.5 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲F̲l̲o̲w̲ ̲(̲I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲)̲
TBD
4.1.3.2.6 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲F̲l̲o̲w̲ ̲(̲D̲a̲t̲a̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲)̲
TBD
4.1.3.2.7 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲F̲l̲o̲w̲ ̲(̲S̲e̲c̲u̲r̲i̲t̲y̲)̲
TBD
4.1.4 P̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
TBD
4.1.5 C̲o̲m̲m̲o̲n̲ ̲D̲a̲t̲a̲
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̲
All SUP external interfaces are described in CPS/230/ICD/0002.
4.1.6.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
All interfaces between SUP and other packages are described
in CPS/ICD/009.
4.1.6.3 S̲u̲b̲-̲P̲a̲c̲k̲a̲g̲e̲s̲ ̲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 SVUP.
F̲r̲o̲m̲ ̲S̲V̲U̲P̲ ̲t̲o̲ ̲U̲M̲A̲M̲:̲
1. ACCESS STATE OF SERVICE MESSAGE = DEFERRED
2. TEMPORARY ACCESS STATE OF SERVICE MESSAGE = SENT
3. ACCESS KEY TO CIF (Q-ELEM.)
4. PERMANENT ACCESS STATE OF SERVICE MESSAGE = SENT
F̲r̲o̲m̲ ̲U̲M̲A̲M̲ ̲t̲o̲ ̲S̲V̲U̲P̲:̲
1. ACCESS KEY TO CIF (Q-ELEM.)
2. OUTGOING MESSAGE 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̲ ̲S̲V̲C̲O̲ ̲t̲o̲ ̲S̲F̲C̲O̲:̲
1. INITIALIZE CMD
2. RESTART ̲SFCO CMD
3. START ̲SFCO CMD
4. STOP ̲SFCO CMD
5. CLOSE ̲DOWN CMD
2̲.̲ ̲ ̲F̲r̲o̲m̲ ̲S̲F̲C̲O̲ ̲t̲o̲ ̲S̲V̲C̲O̲:̲
1. INITIALIZE CC REPORT
2. RESTART ̲SFCO CC REPORT
3. STOP ̲SFCO CC REPORT
4. CLOSE ̲DOWN CC REPORT
3̲.̲ ̲ ̲F̲r̲o̲m̲ ̲S̲F̲C̲O̲ ̲t̲o̲ ̲S̲V̲D̲I̲A̲
1. INITIALIZE CMD
2. START ̲SVDIA CMD
3. DISPLAY ̲FORMAT CMD
4. INPUT ̲FORMAT CMD
5. OUTPUT ̲MSG CMD
6. OUTPUT ̲REQ CMD
7. INSERT ̲LINES CMD
8. DELETE ̲LINES CMD
9. CLEAN ̲UP CMD
10. CLOSE ̲DOWN CMD
4̲.̲ ̲ ̲F̲r̲o̲m̲ ̲S̲V̲D̲I̲A̲ ̲t̲o̲ ̲S̲F̲C̲O̲
1. INITIALIZE CC REPORT
2. START ̲SVDIA CC REPORT
3 CLEAN ̲UP CC REPORT
4 CLOSE ̲DOWN CC REPORT
5 VALIDATION RESULT
5̲.̲ ̲ ̲F̲r̲o̲m̲ ̲S̲F̲C̲O̲ ̲t̲o̲ ̲S̲R̲E̲T̲R̲
NONE
6̲.̲ ̲ ̲F̲r̲o̲m̲ ̲S̲R̲E̲T̲R̲ ̲t̲o̲ ̲S̲F̲C̲O̲
1. SAR ON/OFF-LINE RETRIEVAL RESULT
4.2.X S̲u̲b̲-̲P̲a̲c̲k̲a̲g̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
TBD
4.3 M̲E̲M̲O̲R̲Y̲ ̲L̲A̲Y̲O̲U̲T̲
TBD
