top - download
⟦ae1b1e1e5⟧ Wang Wps File
Length: 43434 (0xa9aa)
Types: Wang Wps File
Notes: CPS/SDS/027
Names: »1141A «
Derivation
└─⟦fad1c67d1⟧ Bits:30006043 8" Wang WCS floppy, CR 0069A
└─ ⟦this⟧ »1141A «
WangText
%…00……00……00……00…9…0a……00……00…9…0b…9 8…0e…8…07…7…01…6…0b…6…0d…6
6…07…5…0a…5…00…5…01…5
5…86…1 …02… …02… …02…
…02…CPS/SDS/027
…02…MSN/810801…02……02…
TEP VDU USER PACKAGE
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 GENERAL .......................................
9
1.1 PURPOSE AND SCOPE .........................
9
1.2 APPLICABLE DOCUMENTS AND PROJECT REFERENCES
9
1.2.1 Applicable Documents ..................
9
1.2.2 Reference Documents ...................
10
1.3 TERMS AND ABBREVIATIONS ...................
11
1.3.1 Terms .................................
11
1.3.2 Abbreviations .........................
11
2 SUMMARY OF REQUIREMENTS .......................
12
2.1 PACKAGE DESCRIPTION .......................
12
2.2 PACKAGE FUNCTIONS .........................
18
2.2.1 Main Functions ........................
20
2.2.1.1 Queue Status Display ..............
20
2.2.1.2 Information Concerning the Trans-
action in Progress ................
23
2.2.1.3 Display of Queued Information .....
23
2.2.1.3.1 The Receive Queue .............
23
2.2.1.3.2 The Response Queue ............
24
2.2.1.3.3 The Release Queue .............
24
2.2.1.4 Message/Comment Preparation .......
25
2.2.1.5 Treatment of User Request .........
29
2.2.1.6 Maintenance of Message Status Files
29
2.2.1.6.1 Outgoing Message Status .......
29
2.2.1.6.2 Delivery Status ...............
29
2.2.1.6.3 Release Status ................
31
2.2.2 Functional Responsibilities ...........
31
2.2.2.1 Initialization, Close Down and
Restart ...........................
31
2.2.2.1.1 Initialization ................
31
2.2.2.1.2 Close Down ....................
31
2.2.2.1.3 Restart .......................
32
2.2.2.2 Checkpointing and Recovery ........
32
2.2.2.3 Error Detecting and Error Handling
32
2.2.2.4 Integrity of Operation ............
33
2.2.2.5 Data Collection ...................
33
2.2.2.5.1 Log Collection ................
33
2.2.2.5.2 Statistics Information ........
34
2.2.2.5.3 Reports .......................
34
2.2.2.6 Security ..........................
37
2.3 CHARACTERISTICS ...........................
39
2.3.1 Timing ................................
39
2.3.2 Throughput ............................
40
2.3.3 Flexibility ...........................
41
2.3.4 Accuracy ..............................
42
3 ENVIRONMENT ...................................
43
3.1 EQUIPMENT .................................
43
3.2 SOFTWARE ..................................
43
3.2.1 System Software .......................
43
3.2.2 Development Support Software ..........
43
3.3 INTERFACES ................................
43
3.3.1 External Interfaces ...................
43
3.3.2 Package Interfaces ....................
43
3.3.2.1 Traffic Handling (THP) I/F ........
44
3.3.2.2 Distribution (MDP) I/F ............
44
3.3.2.3 Storage and Retrieval (SAR) I/F ...
44
3.3.2.4 Log and Accountability (LOG) I/F ..
44
3.3.2.5 Statistics (STP) I/F ..............
45
3.3.2.6 SSC Software I/F ..................
45
3.3.2.7 Table Management Package (TMP) I/F
45
3.4 FUNCTIONS MAINTAINED BY OTHER PACKAGES ....
46
4 PACKAGE DESIGN ................................
47
4.1 PACKAGE OVERVIEW ..........................
47
4.1.1 Functional Specification ..............
53
4.1.1.1 TEMCO Control Functions ...........
55
4.1.1.2 Queue Status Maintenance ..........
57
4.1.1.3 User Transaction Control ..........
60
4.1.1.3.1 Transaction Assounting ........
61
4.1.1.3.2 Transaction Interruption ......
66
4.1.1.3.3 Command Interpretation ........
68
4.1.1.3.4 Command Execution .............
70
4.1.1.3.5 Start/Stop Transaction
Execution .....................
72
4.1.1.3.6 Preparation of Messages/
Comments ......................
74
4.1.1.3.7 Presentation of Queued Infor-
mation ........................
76
4.1.1.3.8 Requests to CAMPS System ......
78
4.1.1.3.9 Dialogue Formatting ...........
87
4.1.1.3.10 Format Validation .............
89
4.1.1.4 User Message Access Monitoring ....
91
4.1.1.4.1 Preparation Database Access
Control .......................
93
4.1.1.4.2 Message/Comment Status
Maintenance ...................
96
4.1.2 Software Specification ................
100
4.1.2.1 VUP Processes .....................
100
4.1.2.1.1 VUS Process ...................
100
4.1.2.1.2 UMAM Process ..................
104
4.1.2.2 VUP Coroutines ....................
107
4.1.2.2.1 VUS Coroutines ................
108
4.1.2.2.1.1 VDU Control Coroutine .....
108
4.1.2.2.1.2 User Function Control
Coroutine .................
109
4.1.2.2.1.3 VDU Dialogue Coroutine ....
110
4.1.2.2.1.4 Retrieve Coroutine ........
110
4.1.2.2.2 UMAM Coroutines ...............
111
4.1.2.2.2.1 Preparation Access Control
Coroutine .................
111
4.1.2.2.2.2 User Status File Mainte-
nance Coroutine ...........
111
4.1.2.3 Software Structure ................
112
4.1.2.3.1 VCO Coroutine Software
Structure .....................
118
4.1.2.3.2 UFCO Coroutine Software
Structure .....................
126
4.1.2.3.3 VDIA Coroutine Software
Structure .....................
137
4.1.2.3.4 RETR Coroutine Software
Structure .....................
139
4.1.2.3.5 PAC Coroutine Software
Structure .....................
139
4.1.2.3.6 USFM Coroutine Software
Structure .....................
139
4.1.3 Data Flow and Control Logic ...........
142
4.1.3.1 Process Data Flow and Process
Synchronization ...................
142
4.1.3.2 VUS Internal Data Flow and
Coroutine Synchronization .........
144
4.1.3.3 UMAM Internal Data Flow and
Coroutine Synchronization .........
150
4.1.4 Common Data Elements ..................
153
4.1.5 External Data Elements ................
153
4.1.6 Interfaces ............................
153
4.1.6.1 External Interfaces ...............
153
4.1.6.2 Package Interfaces ................
153
4.1.6.2.1 Traffic Handling (THP) I/F ....
153
4.1.6.2.2 Distribution (MDP) I/F ........
153
4.1.6.2.3 Storage and Retrieval (SAR) I/F
154
4.1.6.2.4 LOG and Accountability (LOG)
I/F ...........................
154
4.1.6.2.5 Statistics (STP) I/F ..........
154
4.1.6.2.6 SSC Software I/F ..............
154
4.1.6.2.7 Table Management Package I/F ..
154
4.1.6.3 Sub-Package Interfaces ............
155
4.1.6.3.1 Process Interfaces ............
155
4.1.6.3.2 Coroutine Interfaces ..........
155
4.2 SUBPACKAGE SPECIFICATIONS .................
158
4.2.1 User Message Access Monitoring
Subpackage ............................
158
4.2.1.1 Functional Specification ..........
158
4.2.1.1.1 Collect Status ................
158
4.2.1.1.2 Generate Status ...............
160
4.2.1.1.2.1 User Requested Status .....
160
4.2.1.1.2.2 Periodic Generated Status .
162
4.2.1.1.3 Message Access Control ........
164
4.2.1.2 Software Structure ................
166
4.2.1.2.1 PAC Software Structure ........
166
4.2.1.2.2 USFM Software Structure .......
170
4.2.1.3 Data Flow and Control Logic .......
172
4.2.1.4 Subpackage Data ...................
209
4.2.1.4.1 DSF ...........................
209
4.2.1.4.2 OMSF ..........................
214
4.2.1.5 Interfaces ........................
218
4.2.1.5.1 PREP Queue Updating ...........
218
4.2.1.5.2 Input to Request Queue ........
219
4.2.2 Retrieve Subpackage ...................
222
4.2.2.1 Functional Specification ..........
222
4.2.2.2 Software Structure ................
224
4.2.2.3 Data Flow and Control Logic .......
226
4.2.2.4 Subpackage Data ...................
230
4.2.2.5 Interfaces ........................
230
4.2.3 Dialogue Subpackage ...................
230
4.2.3.1 Functional Specification ..........
230
4.2.3.1.1 Input of Data .................
230
4.2.3.1.2 Validate Data .................
239
4.2.3.1.2.1 Validation of Messages ....
239
4.2.3.1.2.2 Validation of Comments ....
243
4.2.3.1.2.3 Validation of Requests ....
246
4.2.3.1.2.4 Display of Error Codes ....
249
4.2.3.1.3 Output of Data ................
249
4.2.3.1.4 Insert/Delete Lines ...........
250
4.2.3.2 Software Structure ................
250
4.2.3.3 Data Flow and Control Logic .......
253
4.2.3.4 Subpackage Data ...................
271
4.2.3.5 Interfaces ........................
273
4.2.4 VDU Control Subpackage ................
274
4.2.4.1 Functional Specification ..........
274
4.2.4.1.1 TEMCO Command Execution .......
280
4.2.4.1.2 Flash Queue Monitoring ........
281
4.2.4.1.3 Periodic Timer Events .........
281
4.2.4.1.4 Time Out Events ...............
282
4.2.4.2 Software Structure ................
282
4.2.4.3 Data Flow and Control Logic .......
285
4.2.4.4 Subpackage Data ...................
299
4.2.4.5 Interfaces ........................
301
4.2.5 User Function Control Subpackage ......
301
4.2.5.1 Functional Specification ..........
301
4.2.5.1.1 System Control ................
311
4.2.5.1.2 Transaction Accounting ........
312
4.2.5.1.3 Transaction Creation ..........
312
4.2.5.1.4 Format Sequencing .............
313
4.2.5.1.4.1 Start Execution ...........
314
4.2.5.1.4.2 Stop Execution ............
315
4.2.5.1.4.3 Queue Requests ............
315
4.2.5.1.4.4 Requests to CAMPS System ..
316
4.2.5.2 Software Structure ................
318
4.2.5.2.1 VCO Commands ..................
320
4.2.5.2.2 Function Keys .................
320
4.2.5.2.3 VDIA Commands .................
321
4.2.5.2.4 RETR Commands .................
321
4.2.5.2.5 Answer Queue Commands .........
321
4.2.5.2.6 Common Procedure ..............
322
4.2.5.3 Data Flow and Control Logic .......
322
4.2.5.4 Subpackage Data ...................
371
4.2.5.5 Interfaces ........................
376
4.3 MEMORY LAYOUT .............................
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 VDU User Package Specification for the CAMPS
Project/4040 is written to fulfil the following
objectives:
1) To provide a detailed definition of the VDU
user package function and software architecture.
2) To provide user operational and development
personnels with details of the ongoing analysis.
3) To define in details the interfaces with other
packages and to describe their facilities.
b) The VDU user 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
of the architecture.
The VDU user package constitutes one of the building
stores of the TEP package.
For an overall description of the TEP package refer
CPS/SDS/012.
All VDU user package internal data and interfaces
are defined within this document in detail. For
a detailed data description of data external to
the VDU user package and interfaces to other packages
refer the data definition 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 Requirements
CPS/210/SYS/0001
User Procedures and Associated Formats
CPS/230/ICD/0001
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
VDU Supervisor Package CPS/SDS/023
Supervisor Printer Package CPS/SDS/024
VDU MDCO Package CPS/SDS/025
VDU MSO Package CPS/SDS/026
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̲
1.3.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
PAC Preparation Access Control
PDB Preparation Data Base
RETR Retrieve Coroutine
UFCO User Function Control Coroutine
UMAM User Message Access Monitoring
USFM User Status File Maintenance
VCO VDU Control Coroutine
VDIA VDU Dialogue Coroutine
VUP VDU User Package
VUS VDU User Sub-Process
HDB Historical Data Base
OMSF Outgoing Message Status File
OMFD Outgoing Message File Directory
DSF Delivery Status File
DFD Delivery File Directory
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 V̲DU U̲ser P̲ackage (VUP) constitutes the only means
by which CAMPS Personnel may gain access to the services
of the CAMPS user function.
a) The CAMPS user function is made up of three subfunctions,
Preparation, Reception, and Release. A VDU or user
may have access rights to one or more of the subfunction
services as specified by the Supervisor. In figure
2.1-1 overleaf the services of the CAMPS user function
and the sub-functions are depicted.
b) The VDU user package (VUP) implements all the services
of the CAMPS user function, which implies the following
responsibilities:
1) Interface the user to the CAMPS system, i.e.
Man/Machine I/F Support and monitoring
2) Direct all user requests/commands to the relevant
package within CAMPS
3) Present to the user information sent to his
VDU
4) Supervise/allow the user preparing messages
and comments.
c) The packages to which VUP interfaces are
1) Kernel
2) I/O Control Software
3) CAMPS systems Functions
4) Storage and File Management
5) SS&C Software
6) Traffic Handling
7) Distribution
8) Table Management
9) Storage and Retrieval
10) Log and Accountability
11) Statistics
Figure 2.1-1
In figure 2.1-2 an overview of the interfaces of VUP
is depicted.
In figure 2.1-3 the message flow between VUP and the
rest of the CAMPS system as well as the VUP internal
flow are depicted, highlighting the most important
functional interfaces.
Information flow between VUP and other CAMPS packages
is depicted in figure 2.1-4.
Figures 2.1-2 to -4
2.2 P̲A̲C̲K̲A̲G̲E̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
a) In this section the functions to be performed by
VUP are outlined. As stated in section 2.1 the
main task of VUP is to implement the CAMPS user
function. The CAMPS user function and the related
requirement will be treated as a whole, ie. the
three subfunctions Preparation, Reception, and
Release constituting the CAMPS user function and
to each of which access must be granted by the
supervisor will be treated together in most sub-sections.
For the limitations imposed if a user only possesses
access rights to one or two of the subfunctions
refer subsection 2.2.2.1 and 2.2.2.6.
b) As a short introduction to the description of the
VUP main functions and functional responsibilites
the environment of VUP as they may be experienced
by the user together with an overview of the services
of VUP are outlined below. Refer figure 2.2-1.
The user may acces the preparation database, where
all messages and comments under preparation are
kept. The user may insert/delete/edit item in the
database.
The user may access the receive queue, which is
a queue of the precedence type, into which CAMPS
inserts all messages/comments destined to the terminal.
The user may inspect/remove/get a printed copy
of the queued elements.
The user may access the response queue, which is
a queue of the non-precedence type, into which
CAMPS inserts responses to user issued requests
with long or unpredictable response times. The
user may inspect/remove/get a printed copy of the
queued elements.
The user may issue requests/commands to the system,
e.g. retrieve a message, delete a message.
Figure 2.2-1
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 to be implemented by VUP are:
1) Continuously display of queue status information
2) Continuously display information concerning the
transaction in progress
3) The means for display of queued information
4) The means for message/comment preparation
5) The means for directing requests to CAMPS and deliver
responses to the user
6) Maintain and update message status files
In figure 2.2-2 an overview of all transaction, which
may be initiated by the user is shown, together with
an indication of whether the transaction refers to
preparation/request or display of queued information.
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 the VDU
header area, refer figure 2.2-3.
The second line of the VDU header area is used for
queue status display. For each of the three queues;
receive queue (DISP), response queue (RESP) and release
queue (RELS) the total amount of messages queued for
presentation shall be displayed.
The total amount of messages for coordination queued
in the receive queue shall be displayed in the field
marked COOR.
The distribution of messages on precedence levels for
the two precedence queues receive and release shall
be displayed in the fields marked: ZZ (FLASH), OO (IMMEDIATE),
PP (PRIORITY), RR (ROUTINE).
…01…QUEUED INFORMATION
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
FORMAT TRANSACTION DATA ENTRY RECEIVE RESPONSE
RELEASE
ID REQUEST QUEUE QUEUE QUEUE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
A New msg. prep. X
B Msg coordination X
C1 Cont. msg prep X
D Msg release
X
E1 Incom. msg. pres. X
E2 Outg. msg. present X
F Release notificat. X
G1 New comment prep. X
G2 Comment present X
G3 Cont. Comment prep X
H Retrieval X X
M Prep. predef. msg X
N Outg. msg. status X
O Append msg. X X
P1 Deletion request X
P2 Deletion notificat. X
Q Msg release status X
R Delivery Status X
FIGURE 2.2-2…01…TRANSACTION RELATED TO THE USER FUNCTION
FIGURE 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 (refer fig. 2.2-3)
shall be used to identify to the user the transaction
in progress (TERMINAL FUNCTION) and the classification
of the information currently accessed (CLASSIFICATON).
Whenever the classification is unknown or no transaction
is in progress the maximum classification to which
the user may gain access through this VDU shall be
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̲
An overview of transactions to be performed in the
Response Mode, Receive Mode and Release Mode of operation
together with the transaction control capabilities
in each mode of operation is given in figure 2.2-4.
For the sake of completeness the Interactive mode of
operation is reflected as well.
2.2.1.3.1 T̲h̲e̲ ̲R̲e̲c̲e̲i̲v̲e̲ ̲Q̲u̲e̲u̲e̲
When the user enters the command RECV (precedence)
VUP shall enter the Receive Mode of operation. The
user shall now be able to inspect the items in the
receive queue one by one, remove an inspected item
from the queue, or request a printed copy of the item.
This may be done by means of the function keys: Keep
and Present, Delete and Present, Print, Cancel.
The first message to be presented to the user shall
be the first queued of the precedence specified by
the command parameter. If none is specified the first
item queued with highest precedence shall be displayed.
When the user activates the function key Suspend, VUP
shall exit the Receive Mode of operation.
2.2.1.3.2 T̲h̲e̲ ̲R̲e̲s̲p̲o̲n̲s̲e̲ ̲Q̲u̲e̲u̲e̲
When the user enters the command RESP, VUP shall enter
the Response Mode of operation.
The user shall now be able to inspect the items in
the response queue one by one, remove an inspected
item from the queue or request a printed copy of the
item. This may be done by means of the function keys;
Keep and Present, Delete and Present, Print, Cancel.
The first item to be presented to the user shall be
the first queued.
When the user activates the function key suspend VUP
shal exit the response mode of operation.
2.2.1.3.3 T̲h̲e̲ ̲R̲e̲l̲e̲a̲s̲e̲ ̲Q̲u̲e̲u̲e̲
The release queue contains messages for release.
When the releaser enters the command RELM (precedence)
VUP shall enter the Release Mode of operation. The
releaser shall now be able to inspect the items in
the release queue one by one, enter his release decision
and/or request a printed copy of the item.
To each item in the release queue is attached an input
format for the entry of the release decision. After
input of the decision the releaser notifies VUP that
a release decision has been entered by means of the
function key ENTER. VUP remove the item from the queue
and executes the decision.
Inspection and print requests are issued to VUP by
means of the function keys: Keep and Present, Print.
The first message to be presented to the releaser shall
be the first queued of the precedence specified by
the command parameter. If none is specified the first
item queued with highest precedence shall be displayed.
When the releaser activates the function key Suspend
VUP shall exit the Release Mode of operation.
2.2.1.4 M̲e̲s̲s̲a̲g̲e̲/̲C̲o̲m̲m̲e̲n̲t̲ ̲P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲
a) Message/comment preparation consists of two functions:
Preparation of New messages/comments, Editing of
existing Messages and Comments.
b) Messages may be edited until they are requested
released. If the release request is rejected or
deferred the messages become available for editing
again. After release the message is not available
for editing.
c) Comments may be edited until they are requested
sent (distributed internally).
d) It is the responsibility of VUP to send retrieval
key to SAR for the first draft of a message and
the released version.
e) It is the responsibility of VUP to send retrieval
keys for a comment at the time of the send request.
f) Message/Comment preparation is achieved through
one of the transactions listed below:
1) New Message Preparation (format A)
2) Continue Message Preparation (format C1)
3) Prepare Predefined Message (format M)
4) New Comment Preparation (format G1)
5) Continue Comment Preparation (format G3)
g) f1), f3), and f4) above requires that VUP inserts
the new item in the preparation database. Whereas
f2) and f5) above require VUP to retrieve the items
which the user wants to edit from the preparation
database (in this case a new CIF-version is created).
h) In figure 2.2-5 the different stages of a preparation
transaction (refer f) above) is shown. The user
access to control the transaction by means of function
keys is shown for each stage as well.
1) For messages the request for further treatment
may be:
- APPEND
- COORDINATE
- SEND FOR RELEASE
- DEFER (Return to preparation database)
2) For comments the request for further treatment
may be:
- SEND
- DEFER
Figure 2.2-4
Figure 2.2-5
2.2.1.5 T̲r̲e̲a̲t̲m̲e̲n̲t̲ ̲o̲f̲ ̲U̲s̲e̲r̲ ̲R̲e̲q̲u̲e̲s̲t̲s̲
Besides the user requests which may be entered as part
of a transaction as already described refer 2.2.1.3.3,
2.2.1.4. h1) and h2), the requests listed below may
be issued by the user:
- Retrieval (format H)
- Deletion Request (format P1)
- Outgoing Message Status (format N)
- Delivery Status (format R)
- Release Status (format Q)
In figure 2.2-6 the different stages of a request transaction
(refer a) above) is shown, together with the user access
to control the transaction by means of function keys
in each stage.
2.2.1.6 M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲S̲t̲a̲t̲u̲s̲ ̲F̲i̲l̲e̲s̲
It is the responsibility of VUP to maintain and update
the following status files for each VDU:
- Outgoing Message Status
- Delivery Status
- Release Status
2.2.1.6.1 O̲u̲t̲g̲o̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲S̲t̲a̲t̲u̲s̲
The Outgoing Message Status file shall contain the
status for each message prepared at a VDU.
Each day at 24.00 hour the Outgoing Message status
file shall be cleaned up. This means that all status
information concerning items which will no longer undergo
changes shall be deleted (e.g. messages released, deleted
etc.)
2.2.1.6.2 D̲e̲l̲i̲v̲e̲r̲y̲ ̲S̲t̲a̲t̲u̲s̲
The Delivery status shall contain a list of all items
removed from the receive queue, as well as these of
the relevant type retrieved. The Delivery Status shall
be cleared each day at 24.00 hour.
Figure 2.2-6
2.2.1.6.3 R̲e̲l̲e̲a̲s̲e̲ ̲S̲t̲a̲t̲u̲s̲
The release status shall contain a list of all items
to which a release decision has been taken and a list
of the associated release notifications for each VDU
with release capability. Each day at 24.00 hour a copy
of the status file shall be queued for print-out at
the supervisor's printer.
Each day at 24.00 hour the Release Status file shall
be cleared.
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̲
VUP is controlled by the SSC software and shall execute
the functions listed below on command from SSC.
- Initialization
- Close Down
- Restart
2.2.2.1.4 I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
On command from SSC VUP shall initialize the VUP software.
The initialization refers to the functions to be performed
after load or re-load of VUP and which it is necessary
to execute before VUP can initiate its normal operation.
2.2.2.1.2 C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲
On command from SSC VUP shall terminate its current
processing in an ordered manner and bring itself into
a state, where it can respond to a restart command.
2.2.2.1.3 R̲e̲s̲t̲a̲r̲t̲
On command from SSC VUP shall be able to execute a
restart function. Restart is commanded following close
down, switchover or total system failure. VUP shall
implement functions necessary to restart after each
situation listed above.
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̲
a) Checkpointing
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.
b) Recovery
When VUP is restarted by SSC software following
close down, switchover, or total system failure
"recovery required" is specified by SSC.
Relevant queues will then have contents according
to latest checkpoint and VUP shall inspect the
queues to reestablish the VUP state.
2.2.2.3 E̲r̲r̲o̲r̲ ̲D̲e̲t̲e̲c̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
a) Error Detecting
VUP has no explicit responsibilities for detection
of hardware errors.
VUP shall implement facilities for error detection
in accordance with general software engineering
practice.
b) Error Handling
Errors detected by VUP shall be reported to the
SSC software together with information on whether
VUP was able to handle the error itself or not.
(Refer also subsection 2.2.2.4). Detection of an
error which VUP cannot handle itself shall cause
VUP to stop its processing and transfer control
to SSC for further handling of the situation. Control
will be returned from SSC in cases where continued
operation is possible after SSC handling of error.
2.2.2.4 I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
VUP 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 troughput.
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 intitiate
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̲
2.2.2.5.1 L̲o̲g̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
Log information on user transactions shall be collected
by the VDU user package and reported to the log package.
Log information shall be reported at the time of start
of a transaction and completion of a transaction and
have the contents as specified in table 2.2-7.
2.2.2.5.2 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
Statistics information on user transactions shall be
collected by the VDU user package and reported to the
statistics package.
The statistics to be reported for each transaction
type is specified in table 2.2.1-8.
2.2.2.5.3 R̲e̲p̲o̲r̲t̲s̲
When the user issues a deletion request on an item,
which the user is not allowed to delete the VDU user
package shall generate a deletion request report and
queue it in the Supervisor's report queue.
FORMAT I A C1 M O H B E1 D F P1 P2 N Q R DUMMY
G1 G3 E2 G2
Log Re-
cord (type,
control)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
Initial X X X X
Final X X X X X X X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
Term design X X X X X X X X X X X
Trans.ser.no. X X X X X X X X X X X
Format id X X X X X X X X X X X
Log time X X X X X X X X X X X
Item ref id X X X X X X X X
Exit Cause X X X X X X X X
Classification X X X X X
Spec.hand.cat. X X X X X
Start time of
transaction X X X X…0e…1)…0f… X
Item ref id X X X
Month + day X
Decision code X
NOTE 1: Format P2 only
TABLE 2.2-7
LOG OF USER TRANSACTION
CONTENTS TYPE 1 TYPE 2
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Type and Contents Terminal Designator X X
of Statistics Format id X X
Duration of use X
Classification X
Precedence X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
A X
B X
C1 X
Transactions identi- D X
fied through Format E1 X
ID and the statistics E2 X
to be collected F X
G1 X
G2 X
H X
M X
N X
O X
P1 X
P2 X
Q X
R X
TABLE 2.2-8 …01…STATISTICS ON USER TRANSACTION
2.2.2.6 S̲e̲c̲u̲r̲i̲t̲y̲
The VDU user package shall implement the security related
functions listed below:
a) When a releaser requests a message to be released
the VDU user package shall request TEMCO to perform
a security interrogation. The VDU user package
shall await the answer from TEMCO and only release
the message if the Security interrrogation is reported
successful completed by TEMCO.
b) For each CAMPS user sub-function, i.e. Preparation,
Release, and Reception, the VDU user package shall
check each command entered by the user in interactive
mode of operation against the assigned sub-function,
and prevent illegal transactions to be initiated.
Refer table 2.2-9.
Access to queues are checked by System Software.
c) For each command entered by the user there exists
a function key mask. This will prevent illegal
transactions being initiated.
̲ ̲ ̲ ̲U̲S̲E̲R̲ ̲S̲U̲B̲F̲U̲N̲C̲T̲I̲O̲N̲ ̲ ̲
̲
VDU MODE OF FORMAT TRANSACTION PREP. RELS. RECV.
OPERATION ID
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
Interactive A New msg. prep. X
Mode
(Data entry C1 Cont. msg prep X
and requests
G1 New comment prep. X X
G3 Cont. Comment prep X X
H Retrieval X
M Prep. predef. msg X
N Outg. msg. status X
O Append msg. X
P1 Deletion request X
Q Msg release status X
R Delivery Status X X X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
B Msg. Coordination X X
Receive Mode
E1 Incom. Msg. Present X
E2 Outg. Msg. Present X
G2 Comment Present X X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
F Release Notificat. X
Response Mode
H Offl. Retr.Notific. X
O Offl. append notif. X
P2 Deletion Notificat. X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲
Release Mode D Msg. Release X
TAB. 2.2-9 TRANSACTIONS ALLOWED PER ASSIGNED CAMPS USER SUBFUNCTION
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̲
a) Transmission to terminals of a response or other
output shall be at cadence speed once commenced.
b) Non interactive transactions shall in 90% of all
cases commence not later than 5 seconds after the
event which gives rise to the transaction, assuming
the terminal facility required is available.
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.
d) Once an interactive transaction has been completed
or terminated/aborted the succeeding action(s)
by the system shall commence within 5 seconds in
90% of all cases.
e) Update of queue status in the VDU header area shall
take place each minute. If a message of precedence
FLASH (or above) arrives, the queue status shall
be updated immediately.
2.3.2 T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲
a) The busy second character flow from/to a CAMPS
of maximum equipment configuration employing formats
applicable to messages not yet released shall never
exceed:
To CAMPS ............... 200 Chars/sec
From CAMPS ............. 1400 Chars/sec
b) Messages will on average be sent for coordination
twice.
c) Messages will on average give rise to two comments.
d) A comment will on average be of 69 characters excluding
heading information.
e) Messages will on average be edited twice.
f) Maximum operator keying rate is assumed to be 10
IA5 character/s.
g) The channel capacity for transmission from VDU
to system and for system response output is 120
IA5 characters per second.
h) Release terminal positions release messages at
a rate of max. six per minute.
The throughput in this section is specified for
a CAMPS of maximum equipment configuration as defined
in CPS/210/SYS/0001 3.4.1.2.1.
i) Throughput requirements in this section shall for
a CAMPS of less than maximum configuration be reduced
as follows:
M̲a̲x̲.̲ ̲c̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲:̲
VDU (32) 32 x 120 chars/s
TPs (as TRC) 24 x 10 char/s
j) For a CAMPS with less than max. configuration the
theoretical flow shall be calculated as above and
the throughput requirements in this section be
reduced accordingly.
2.3.3 F̲l̲e̲x̲i̲b̲i̲l̲i̲t̲y̲
a) Precedences:
Four levels of precedences shall be distinguished
by the system. To accomodate a possible increase
in the number of precedence levels used, allowance
shall be made in the design for two other levels.
Defined Precedences Precedences Foreseen
highest
Superflash
Flash Flash
Immediate Immediate
Superpriority
Priority Priority
Routine Routine
lowest
b) Formats:
Changes in formats, new formats, changes in format
tolerances and improvements in Man/Machine I/F
shall be flexibility requirements during TEP design.
c) During detailed design more flexibility items will
be identified.
2.3.4 A̲c̲c̲u̲r̲a̲c̲y̲
a) Accuracy of input data:
Time shall be exact within 500 ms, i.e. a tolerance
of +/- 500 ms is acceptable.
All other input data shall be exact.
b) Accuracy of output data:
Output-data shall be exact, except for time where
the tolerance mentioned in (a) above applies.
3̲ ̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
3.1 E̲Q̲U̲I̲P̲M̲E̲N̲T̲
The equipment environment of this package is the CR80D
Computer.
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̲
VUP's system software environment consists of the following
components:
- DAMOS
- CAMPS System Function
- Message Management System
- Storage and File Management
- I/O Control Software
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̲
Development software is standard DAMOS and TOS (Terminal
Operating System) resident in a single CR80D configuration.
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̲
User Procedures ref. doc. no. CPS/230/ICD/0001.
3.3.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
3.3.2.1 T̲r̲a̲f̲f̲i̲c̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲(̲T̲H̲P̲)̲ ̲I̲/̲F̲
Message released by the releaser shall by VUP be queued
to THP for routing and ACP127-conversion.
3.3.2.2 D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲(̲M̲D̲P̲)̲ ̲I̲/̲F̲
Messages for coordination are by VUP queued to MDP
for distribution. MDP returns to VUP a list of the
coordinators which could not be reached.
Messages released by the releaser shall by VUP be queued
to MDP for local distribution.
Comments are by VUP queued to MDP for distribution.
MDP queues messages for coordination, comments, incoming
and outgoing messages in VUP's receive queue.
Whenever MDP queues a message of precedence FLASH or
above MDP shall explicit notify VUP.
If during Quiet Hours a message of precedence Flash
or Immediate is sent or attempted sent to a terminal
which is signed off it will be queued for the Quiet
Hour Terminal as specified by the supervisor.
3.3.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̲
VUP shall request SAR to store first drafts of messages
and messages as released. Together with the store request
VUP reports all the retrieval keys except for the TOC.
Upon reception of the store requests SAR returns the
associated TOC to VUP.
SAR shall retrieve items requested by VUP. VUP shall
queue the retrieve request to SAR. The first thing
SAR shall do is to inform VUP whether the requested
item resides on on-line or off-line database. After
retrieval SAR shall queue the retrieved item or an
error code to VUP.
3.3.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̲
LOG records collected by VUP shall be queued to LOG.
VUP then receives a receipt from LOG.
3.3.2.5 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲(̲S̲T̲P̲)̲ ̲I̲/̲F̲
Statistics information to be collected by VUP shall
be communicated to STP by invoking the appropriate
Monitor Procedure.
3.3.2.6 S̲S̲C̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲I̲/̲F̲
VUP shall be able to request TEMCO (SSC Software) to
perform a security interrogation. When TEMCO has performed
the security interrogation VUP shall be informed of
the result.
On command from SSC VUP shall execute the start function.
The start command is given VUP after a user has signed-on,
together with all information necessary (access rigths,
associated release terminal, etc.).
On command from SSC VUP shall stop its current processing.
The stop command is issued from SSC when the user signs-off
or in analogous situations. VUP shall upon reception
of the stop command perform all function necessary
to clean up work space used and be ready for a new
SSC command.
3.3.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̲
TMP provides access to tables, global number series
and system parameters. The tables accessed by VUP include:
AG
AIG
PLA
SCD
SIC
Global no. series:
Transaction serial no.
Release serial no.
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̲
Security interrogations and warnings are performed
by TEMCO (SSC) without the knowledge of VUP. SSC Software
is requested by the Message Management Software to8execute
the interrogation/warning when access to a message
is requested by VUP. Access by VUP will only be allowed
if granted by SSC software.
