top - download
⟦524c28c3d⟧ Wang Wps File
Length: 61549 (0xf06d)
Types: Wang Wps File
Notes: CPS/SDS/038
Names: »1653A «
Derivation
└─⟦fa8144eef⟧ Bits:30006080 8" Wang WCS floppy, CR 0123A
└─ ⟦this⟧ »1653A «
WangText
…0a……00……00……00……00……14……02……00……00……14…
…13……09……13……0e……13……02……12……08……12……0a……12……0b……12……0c……12……0f……12……00……12……06……12……07……11……0e……11…
…11… …10……08……10……09……10……00……10……06……0f……0c……0f……02……0f……07……0e……0d……0e……02……0e……05……0d……08……0d……0a……0d……02……0d……06……0d……07……0c……0e……0c……0f……0c…
…0c… …0c……07……0b……08……0b……0e……0b…
…0b… …0b……06……0b……07……86…1 …02… …02… …02…
…02…CPS/SDS/038
…02…JHH/820514…02……02…
MSO VDU
DETAILED DESIGN SPECIFICATION…02……02…CAMPS
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 MSO Package Specification for the CAMPS
Project/4040 is written to fulfil the following
objectives:
1) To provide a detailed definition of the VDU
MSO package function and software architecture.
2) To provide MSO operational and development
personnel with details of the ongoing analysis.
3) To define in detail the interaction with other
packages and to describe their facilities.
b) The VDU MSO package specification defines the functions
and software architecture of the package to a level
sufficient for a programmer to start programming
with a minimum of design effort of the architecture.
The VDU MSO package constitutes one of the building
stones of the TEP package.
For an overall description of the TEP package refer
CPS/SDS/012.
All VDU MSO package internal data and interfaces
are defined within this document in detail. For
a detailed data description of data external to
the VDU MSO 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
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
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
Detailed Design Specification CPS/SDS/024
Message Management
Detailed Design Specification CPS/SDS/025
System Status and Control
Detailed Design Specification CPS/SDS/029
Table Managment
Detailed Design Specification CPS/SDS/026
Input/Output Control
Detailed Design Specification CPS/SDS/028
Storage and Retrieval
Detailed Design Specification CPS/SDS/030
Statistics
Detailed Design Specification CPS/SDS/031
Logging
Detailed Design Specification CPS/SDS/032
Traffic Handling
Detailed Design Specification CPS/SDS/033
Message Distribution Package
Detailed Design Specification CPS/SDS/034
VDU Supervisor Package
Detailed Design Specification CPS/SDS/035
Supervisor Printer Package
Detailed Design Specification CPS/SDS/036
VDU MDCO Package
Detailed Design Specification CPS/SDS/037
USER VDU
Detailed Design Specification CPS/SDS/039
OCR Package
Detailed Design Specification CPS/SDS/040
Printer Package
Detailed Design Specification CPS/SDS/041
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̲
MSO Message Service Operator
THP Traffic Handling
MSOP Message Service Operator Package
MSOS Message Service Operator Subprocess
IMAS Incoming Message Service Assistance
OMAS Outgoing Message Service Assistance
SEVCO Message Service VDU Control
SEFCO Message Service Function Control
SEDIA Message Service VDU Dialogue
SETR Message Service Retrieval
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 VDU M̲S̲O̲ P̲ackage (MSOP) constitutes the only means
by which CAMPS Personnel may gain access to the services
of the CAMPS MSO function.
a) The CAMPS MSO function is made up of six subfunctions,
Service message Preparation, Retrieval for Readdressal,
Retrieval for Rerun, Incoming message service assistance,
Outgoing message service assistance and Display
of retrieved messages. A VDU or MSO may have access
rights to one or more of the subfunction services
as specified by the Supervisor. In figure 2.1-1
and figure 2.1-2 overleaf the services of the CAMPS
MSO function and the sub-functions are depicted.
b) The VDU MSO package (MSOP) implements all the services
of the CAMPS MSO function, which implies the following
responsibilities:
1) Interface the MSO to the CAMPS system, i.e.
Man/Machine I/F Support and monitoring
2) Direct all MSO requests/commands to the relevant
package within CAMPS
3) Present to the MSO information sent to his
VDU
4) Supervise/allow the MSO to prepare service
messages and annotation.
5) Allow the MSO to service on outgoing/incoming
messages e.g. Garble correction, Relay assistance,
Outgoing routing indicator assignment.
c) The packages to which MSOP 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) Table Management
8) Storage and Retrieval
9) Log and Accountability
Figure 2.1-1
Figure 2.1-2
In figure 2.1-3 an overview of the interfaces of MSOP
is depicted.
In figure 2.1-4 the message flow between MSOP and the
rest of the CAMPS system as well as the MSOP internal
flow are depicted, highlighting the most important
functional interfaces.
Information flow between MSOP and other CAMPS packages
is depicted in figure 2.1-5. It should be noted that
UMAM is used for control of Service Messages under
preparation and shared with all VDU User Subprocess.
Figures 2.1-3 to -5
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
MSOP are outlined. As stated in section 2.1 the
main task of MSOP is to implement the CAMPS MSO
function. The CAMPS MSO function and the related
requirement will be treated as a whole.
b) As a short introduction to the description of the
MSOP main functions and functional responsibilites
the environment of MSOP as they may be experienced
by the MSO together with an overview of the services
of MSOP are outlined below. Refer figure 2.2-1.
The MSO may acces the preparation database, where
all messages under preparation are kept. The user
may insert/delete/edit item in the database.
The MSO may access the incoming and outgoing queues,
which are queues of the precedence type, into which
CAMPS inserts all messages/comments destined to
the MSO terminals. The MSO may inspect/ edit/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 e.g.
retrieval for rerun and readdressal. The MSO may
edit/inspect/ remove/get a printed copy of the
queued elements.
The MSO may issue requests/commands to the system,
e.g. retrieve a message, delete a service 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 MSOP are:
1) Continuous display of queue status information
2) Continuous display information concerning the transaction
in progress
3) The means for display of queued information
4) The means for service message preparation
5) The means for directing requests to CAMPS and deliver
responses to the MSO
6) Maintain and update message status files
In figure 2.2-2 an overview of all transaction, which
may be initiated by the MSO are 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 four queues;
response queue (RESP), incoming message queue (INCQ),
outgoing message queue (OUTQ), and user queue (USER)
the total amount of messages queued for presentation
shall be displayed.
When the MSO takes action on items in one of the two
queues of precedence type (i.e. incoming mesage queue
and outgoing message queue), the precedence of the
messages queue in the accessed queue will be displayed
in the fields marked: ZZ (FLASH), OO (IMMEDIATE), PP
(PRIORITY), RR (ROUTINE).
Messages without recognizable precedence level will
be queued with immediate precedence.
…01…QUEUED INFORMATION
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
TRANSACTION DATA ENTRY INCOMING OUTGOING RESPONSE
REQUEST MESSAGE MESSAGE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Prepare new Plaindress X
Messages (PRPF)
Prepare new abbreviated X
plaindress message (PRAP)
Prepare new abbreviated X
service message (PRAS)
Continue plaindress X
message preparation (CPFP)
Continue plaindress mes- X
sage preparation (CAPP)
Continue abbreviated X
service message prepara-
tion (CASP)
Delete service message X
(DESM)
Outgoing service messsage X
status (OSMS)
Incoming message service X X
assistance (IMAS)
Outgoing message service X
X
assistance (OMAS)
Retrieval for rerun X
X
(RERN)
Retrieval for readdressal X
X
(READ)
Response message display X
X
(RESP)
FIGURE 2.2-2
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 (CLASSIFICATION).
Whenever the classification is unknown or no transaction
is in progress the maximum classification to which
the MSO may gain access through this VDU shall be displayed.
Whenever the classification of a message is garbled
the maximum classification of channel from which it
was received, will 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
Service Mode of operation together with the transaction
control capabilities in the mode of operation is given
in figure 2.2-4. For the sake of completeness the Interactive
mode of operation is reflected as well.
figure 2.2-4
2.2.1.3.1 T̲h̲e̲ ̲I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲Q̲u̲e̲u̲e̲
When the MSO enters the command IMAS, he will be able
to inspect the items in the INCQ queue one by one,
make service on the messages in accordance with the
contents of Terminal Function field, (i.e. Garble Correction,
Message Inspection), 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, Next, Delete and Present Next, Print, Cancel.
The first message to be presented to the MSO will be
the item with the highest precedence level. If two
or more have the same precedence the oldest item will
be displayed first.
When the MSO activates the F/C key Return to current
menu it will cause the system to send to the VDU the
MSO menu and return the item currently displayed on
the VDU to the queue.
2.2.1.3.2 T̲h̲e̲ ̲O̲u̲t̲g̲o̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲Q̲u̲e̲u̲e̲
When the MSO enters the command OMAS he will be able
to inspect the item in the OUTQ queue one by one, make
service on the messges in accordance with the content
of Terminal Function fied, i.e. Outgoing Routing Indicator
Assignment, 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
Next, Delete and Present Next, Print, Cancel.
The first message to be presented to the MSO will be
the item with the highest precedence level and if two
or more have the same precedence then the oldest will
be displayed.
When the MSO activates the F/C key Return to current
Menu it will cause the system to send to the VDU the
MSO menu and the item currently displayed on the VDU
in returned to the queue.
2.2.1.3.3 T̲h̲e̲ ̲R̲e̲s̲p̲o̲n̲s̲e̲ ̲Q̲u̲e̲u̲e̲
When the MSO enter the command RESP, he will be able
to inspect the items in the RESP queue one by one,
make service on the messages in accordance with the
content of Terminal Function field, i.e. Retrieval
for Rerun, Retrieval for Readdressal, 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 Next, Delete and Present Next, Print, Cancel.
The first message to be presented to the MSO will be
the first in the queue.
When the MSO activates the function key Return to Current
Menu. It will have the effect that the item is returned
to the queue and causes the system to send the MSO
menu to the VDU.
2.2.1.3.4 T̲h̲e̲ ̲U̲s̲e̲r̲ ̲Q̲u̲e̲u̲e̲
The user queue is used to inform the MSO about the
number of items awaiting user transactions and is only
available through entering User Mode of operation.
The queue reflects the total number of messages queued
for this terminal i.e. the number of messages in receive,
release and response queue.
If the terminal profile is set to be without user capability
the User Queue is empty.
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̲
The MSO may issue requests to CAMPS system by means
of either a command or by use of F/C Keys.
The MSO may request:
1. Outgoing Service Message Status
2. Message Retrieval
3. Message treatment
4. Message print
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 for messages sent or deleted.
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̲
1. Initialization: The initialization of the MSOP
subprocess is performed by the VUS INITIALIZATION
SUBPACKAGE which is described in document CPS/SDS/039.
The initialization of MSOP data areas and the Format
Handler of the IOC Software is done by MSOP.
2. Close Down: This is termination of the current
processing in an ordered manner setting MSOS 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 (i.e. Internal error and Queue error)
will be reported to SSC software.
2.2.2.4 I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
MSOP shall contain credibility checks 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 MSOP to the LOG-Package
are final log information upon completion of a
transaction.
The data are:
a) Transaction ID
b) Item reference identity
c) Format Identification
d) Month and day, only applicable for retrieval
e) A code indicating the reason for diversion
f) Log time
g) Exit cause
h) Start time of transaction
2 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
N/A.
3 R̲e̲p̲o̲r̲t̲s̲
N/A.
2.2.2.6 S̲e̲c̲u̲r̲i̲t̲y̲
MSOP maintains a list of all MSO commands. This list
is used during validation of any command issued to
the system by the MSO VDUs.
For each command entered by the MSO there exists a
function key mask. This will prevent illegal transaction
being initiated.
Access to queues are checked by System Software.
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 MSOP.
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 MSOP:
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 ensures 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̲
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̲
MSOP's system software environment consists of the
following components:
- DAMOS
- CAMPS System Function
- Message Management System
- Storage and File Management
- I/O Control Software
- SSC 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̲
Supervisor Commands and Procedures ref. doc. no. 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̲
START UP
CLOSE DOWN
START USER
STOP USER
BLOCK TERMINAL
3.3.2.2 T̲M̲P̲ ̲I̲/̲F̲
COMMAND TABLE
ERROR TABLE
SEQUENCE TABLE
VALIDATION TABLES
ADDRESSING TABLES
3.3.2.3 L̲O̲G̲ ̲I̲/̲F̲
SEND LOG RECORD
3.3.2.4 S̲A̲R̲ ̲I̲/̲F̲
STORE
RETRIEVE
3.3.2.5 T̲H̲P̲ ̲I̲/̲F̲
READDRESSAL
RERUN
SERVICE MESSAGES
INCOMING/OUTGOING MESSAGE SERVICE
SC ̲VDU ̲PAGE
SC ̲COMMENT
3.3.2.6 U̲M̲A̲M̲ ̲I̲/̲F̲
SERVICE MESSAGES UNDER PREPARATION
OUTGOING SERVICE MESSAGE STATUS
3.3.2.7 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 MSO capability
Security Warning
Sign-off procedure
Security interrogation
on behalf of MSOP.
Initialization of coroutine, Semaphores, and Operations
are performed by VUS INITIALIZATION SUBPACKAGE within
VUP.
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 M̲essage S̲ervice O̲perator P̲ackage (MSOP) 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 M̲essage S̲ervice O̲perator S̲ubprocess
(MSOS) is shown on fig. 4.1-1. It consists of 4 sub-packages
(or coroutines) as specified in sec. 4.1.2):
a) SEVCO (Message S̲e̲rvice 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) SEFCO (Message S̲e̲rvice F̲unction C̲o̲ntrol) which
reacts upon commands from SEVCO, F/C Keys (Function
Keys) from Keyboard and input from the Answer Queue,
Incoming Message Queue, Outgoing Message Queue
and Response Queue. It also receives input from
the Retrieve Coroutine (SETR) and controls the
Dialogue Coroutine (SEDIA).
It contains all the functions for control of the
M̲an M̲achine I̲nterface (MMI) and interfacing to
other packages as well as command execution.
c) SEDIA (Message S̲e̲rvice VDU D̲i̲a̲loque) which performs
input and output to and from the VDU format area
and validation of input data on command from SEFCO.
d) SETR (Message S̲e̲rvice Ret̲r̲ieval) which receives
answers (messages or error-codes) from SAR on requests
sent to SAR from SEFCO. It communicates on-line
retrieval results to SEFCO and off-line retrieval
results to the Response Queue.
Communication with other packages (apart from Monitor
Calls) is done via queues. The MSOP has 7 input
queues:
Common Command
Queue: Flash notification from Traffic
Handling Pakcage. The queue is
shared between up to four MSO
positions (ref. figure 4.1-1a))
Command Queue: Commands from TEMCO and timer
events from Timer Monitor
Answer Queue: Answers to requests to other packages.
Common Incoming
Message Service
Queue: Messages queued for service assistance
by THP. The queue is shared between
up to four MSOs.
Common Outgoing
Message Service
Queue: Messages queued for service assistance
by THP. The queue is shared between
up to four MSOs.
Response Queue: Off-line Retrieval Results (placed
in the queue by SETR).
Retrieve Queue: Retrieval results (off-line and
on-line) from SAR.
The detailed analysis leading to the breakdown
of MSOP into these 4 sub-packages is similar to
the one presented in CPS/SDS/039 (VUP) and thus
shall not be repeated in this document (ref section
4.1.3.2).
Figure 4.1-1
1. Flash notifications from THP (ref. figure 4.4-1a)
2. Antiflash notifiction from other MSOs (ref. figure
4.4-1a). Flash notifications from other MSOs. Commands
from SSC (e.g. start, stop) and timer events.
3. Timer initiated update of VDU header (queues, time)
4. Control information from SEVCO to SEFCO
5. Commands/parameters and function keys
6. Transaction ID, classification, error messages
7. Messages and requests
8. Validated/unvalidated messages
9. Retrieved messages
10. Off-line retrieval results are sent to the Response
queue for MSO attention and access.
11. Retrieve finished signal to SEFCO and on-line retrieval
results.
12. Answers to requests and retrieved messages and
Messages for service assistance
In figure 4.1-1 is outline that two types of command
queues exist, a common command queue and a separate
command queue.
In figure 4.1-1 a) is outlined a situation in the interplay
between the two queue types.
The MSO who first receives a flash notification, distributes
it to the other MSOs command queues. The MSO who first
request the message of precedence flash to be displayed,
will at the same time send an antiflash notification
to the other MSO's command queues in order to delete
the flash notification. If the mesage is returned to
the queue, from which it was received, the MSOs will
at the same time send a flash notification to the other
MSOs.
The situation outlined in figure 4.1-1 a) in MSO1 receiving
a flash notification and distributing it to MSO2, MSO3,
and MSO4.
Figure 4.1-1 a)
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 MSOP.
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 MSOP-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.
MSO TRANSACTION CONTROL:
These are the bulk of the package functions controlling
the MMI and performing the MSO 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.
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.
BLOCK TERMINAL is performed on command from TEMCO when
the Supervisor has specified the terminal to be blocked.
Figure 4.1.1.-1
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̲
The headline Queue Status Maintenance covers the requirements
listed below:
- The periodic update of the VDU header queue status
line with a periodicity of one minute.
- The immediate update of FLASH (and superflash)
precedence queues each time an item is placed in
such a queue.
In figure 4.1.1.2-1 a functional breakdown of the QUEUE
STATUS MAINTENANCE function is depicted.
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 Functions (i.e. Release-,
Response-, Receive Queue) if the MSO has user capabilities.
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.
UPDATE INCOMING MESSAGE SERVICE ASSISTANCE QUEUE:
This field contains the total number of elements queued
in the INCQ queue. It is updated to reflect current
state of the queue. The queue is shared between up
to four MSO positions.
UPDATE OUTGOING MESSAGE SERVICE ASSISTANCE QUEUE:
This field contains the total number of elements queued
in the OUTQ queue. It is updated to reflect current
state of the queue. The queue is shared between up
to four MSO position.
DISPLAY QUEUE STATUS INFORMATION:
This function performs the actual display of the VDU
Header Queue Status Line.
The INVERT INCQ/OUTQ FIELD functions are introduced
to satisfy the requirements for a unique indication
of which of the FLASH precedence queues contains elements.
As the number in the FLASH queue (ZZ-field) in the
queue status line is the total amount of items of FLASH
precedence queued in the INCQ queue and the OUTQ queue,
the relevan queue (s) is displayed in inverse video.
The INTERPRET ANTIFLASH NOTIFICATION function identifies
the antiflash notification.
The INTERPRET FLASH NOTIFICATION function is a consequence
of System Design, where the following requirement was
introduced:
- When a package places an item in a FLASH (or Superflash)
precedence level queue, it shall place a FLASH
NOTIFICATON (indicating the relevant queue) in
the command queue as well.
The real time nature of the QUEUE STATUS MAINTENANCE,
together with the requirements for concurrency with
the MSO TRANSACTION CONTROL, implies that the QUEUE
STATUS MAINTENANCE functions shall have higher priority
than the MSO TRANSACTION CONROL functions.
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 on
figure 4.1.1.3-1.
ASSIGN TRANSACTION DESIGNATOR:
This function assigns a Transaction Designator to the
transaction started.
COLLECT LOG DATA:
This function collects final log information.
FINAL LOG REPORTING:
This function sends log information to the LOG-package
upon completion of the current transaction.
figure 4.1.1.3-1
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.1.4-1. 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.1.4-1
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.1.5-1. 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 Supervisory Command and acceptable in the
current context.
COMMAND PARAMETER VALIDATION is performed on parameters
entered with the command (if any).
DISPLAY ERROR MESSAGE is performed if CMD or parameter
is not acceptable.
Figure 4.1.1.5-1
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.1.6-1.
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.1.6-1
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.1.7-1.
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
and RETURN TO CURRENT MENU.
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.
Fig. 4.1.1.7-1
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.1.8-1.
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.1.8-1
4.1.1.9 P̲r̲e̲s̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲Q̲u̲e̲u̲e̲d̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
Functional breakdown of these functions is shown in
figure 4.1.1.9-1.
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 OF MESSAGE initiates display of the message
requested from the queues.
FETCH SAR ERROR CODES is performed if the off-line
Retrieval request was unsuccessful.
FETCH THP ERROR CODES is performed if the message is
queued for message service by THP
INPUT MESSAGE is performed in order to take the appropriate
action on the displayed item.
In figure 4.1.1.9-2 and figure 4.1.1.9-3 the types
of service assistance the MSO may perform on messages
from the outgoing and the incoming queues are outlined.
ERROR CODE DISPLAY is performed to give details of
reason for failure.
Figure 4.1.1.9-1 to -3
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.1.10-1
RETRIEVAL REQUESTS are the requests made available
via the RETV COMMAND (i.e. for rerun and readdressal)
(ref CPS/230/ICD/0002) and a further breakdown is shown
in figure 4.1.1.10-2.
MESSAGE TREATMENT REQUESTS are the operations that
can be performed upon a prepared Service Message and
a retrieved message. A further breakdown is shown in
figure 4.1.1.10-3.
OUTGOING MESSAGE STATUS REQUEST is the request 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.
Figures 4.1.1.10-1 to -3
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.1.11-1. 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/028.
Figure 4.1.1.11-1
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.1.12-1.
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 is performed when errors are found
during validation.
Figure 4.1.1.12-1
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̲
The functions are a subset of the functions defined
in CPS/SDS/039 (VUP) for UMAM (USER MESSAGE ACCESS
MONITORING) and as this process is shared with VUS
details of the functional breakdown can be found in
that document.
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.
The MSO Subprocess is a part of the VDU USER Package,
which is composed of VUS, MSOS, MDOS Subprocesses.
Refer figure 4.1.2-1A.
Figure 4.1.2-1 shows the mapping of functions onto
processes and coroutines.
MSOS contains the coroutines:
SEVCO Message S̲e̲rvice V̲DU C̲o̲ntrol
SEFCO Message S̲e̲rvice F̲unction C̲o̲ntrol
SEDIA Message S̲e̲rvice V̲DU D̲i̲a̲logue
SETR Message S̲e̲rvice Ret̲r̲ieval
The detailed analysis leading to the software structure
of MSOP is very similar to the one described for VUP
(CPS/SDS/039) and as UMAM (ref. CPS/SDS/039) 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 functonal breakdown
are presented in highlighted boxes in this section).…86…1
…02… …02… …02… …02… …02…
Figure 4.1.2-1a
Figure 4.1.2-1
4.1.2.1 S̲E̲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
SEFCO via commands and processes completion reports
from SEFCO corresponding to the commands.
It also maintains the VDU Queue Status Line every minute
activated by a timer event.
Figures 4.1.2.1-1 to 4.1.2.1-8 show the software structure.
Figures 4.1.2.1-1 to -8
4.1.2.2 S̲E̲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 SEVCO and controls SEDIA via
commands and processes completion reports from SEDIA
corresponding to the commands.
It communicates with SEVCO by sending completion reports
corresponding to commands received from SEVCO.
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 SEDIA.
Figures 4.1.2.2-1 to 4.1.2.2-10 show the software structure.
Figure 4.1.2.2-1 to -10
4.1.2.3 S̲E̲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 SEFCO 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 Formats via the Message Monitor of the CSF
Package.
Figures 4.1.2.3 to 4.1.2.3-7 show the software structure.
Figure 4.1.2.3-1 to -8
4.1.2.4 S̲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 SEFCO.
This communication is done by SETR sending On-line
Retrieval Results directly to SEFCO and Off-line Retrieval
Results indirectly via the Response Queue.
Figure 4.1.2.4-1 shows the Software Structure.
Figure 4.1.2.4-1
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 MSOP
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̲
MSOS 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.3.1-1 shows the communication between MSOS
and UMAM.
Figure 4.1.3.1-1
1 Current Access State of Service Message
Temporary Outgoing Message Status Entry
Access Key (Q-Elem) to CIF (Service Message)
Permanent Entry in Outgoing Message Status
2 Access Key (Q-Elem) to CIF (Service Message)
Outgoing Service Message Status.
4.1.3.2 M̲S̲O̲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 MSOS synchronize
as shown on figure 4.1.3.2-1.
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.
SEVCO waits for the S1 Semaphore. S1 is associated
with the Command Queue and thus as soon as an element
is sent to this SEVCO is ready to run. Elements sent
to this queue are TEMCO commands and Timer events.
SEVCO has highest priority as it controls the process.
SEVCO signals the S2 Semaphore in order to start SEFCO.
SEFCO 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 MSOS is
via F/C Keys SEFCO controls the operation of the VDU
(MMI).
SEFCO is also activated by SEVCO signalling S2 and
will then process commands passed from SEVCO.
When SETR signals S2 SEFCO will get a Retrieval Result
passed to it from SETR.
The access to the Response Queue is direct in the way
that SEFCO does not wait for input to the queue, but
on request from the MSO (RESP-cmd) accesses the queue.
SEFCO signals the S3 semaphore in order to start SEDIA.
SEDIA waits for S3. When S3 is signalled SVDIA receives
commands from SEFCO. SEDIA performs input/output to
and from the VDU format area on request by SEFCO and
informs SEFCO of completion by signalling S2 and passing
a Command Completion Report to SEFCO.
SETR waits for input in the Retrieve Queue. When a
retrieval request is sent to SAR by SEFCO SAR answers
back by sending a Retrieval Result to the Retrieve
Queue. If the retrieved item is on-line SETR passes
the item directly to SEFCO (by signalling S2).
If the retrieved item is off-line SETR will send the
item to the Response Queue. SAR error codes will be
treated the same way in the two cases.
SEFCO will have lower priority than SEVCO but higher
than SEDIA and SETR to ensure proper control, and SEDIA
and SETR will have equal priority.
Figure 4.1.3.2-1
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 MSO capability
3. Garble correction
4. Sign OFF
The following HIPO diagrams illustrates the flow.
15 HIPOer
4.1.4 C̲o̲m̲m̲o̲n̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
COROUTINE ̲SEMAPHORE refer CPS/DBD/00l
COROUTINE ̲OPERATION refer CPS/DBD/00l
IFCB ̲INDEX ̲TYPE refer CPS/DBD/00l
TIME ̲TYPE refer CPS/DBD/00l
QEL ̲REFERENCE refer CPS/DBD/00l
CLASSIFICATION ̲TYPE refer CPS/DBD/00l
QUEUE ̲REFERENCE refer CPS/DBD/00l
PRECEDENCE-TYPE refer CPS/DBD/00l
QERROR ̲INFO ̲TYPE refer COS/DBD/00l
SEND ̲PARAMS refer CPS/DBD/00l
IOC-FIELD ̲DESCRIPTOR ̲TYPE refer CPS/DBD/00l
SAR ̲RETRIEVAL ̲KEY ̲TYPE refer CPS/DBD/00l
PARAMETER ̲INFO ̲TYPE refer CPS/DBD/00l
DESIGNATOR ̲TYPE refer PS/DBD/00l
OFFER ̲ID refer CPS/DBD/00l
LOGICAL ̲TERMINAL ̲NO ̲TYPE refer CPS/DBD/00l
TERMINAL ̲DEGSIGNATOR ̲TYPE refer CPS/DBD/00l
FCT ̲CAPABILITY ̲TYPE refer CPS/DBD/00l
QELEMENT ̲MAIN ̲TYPE refer CPS/DBD/001
MESSAGE ̲SUBTYPE refer CPS/DBD/001
MSOS ̲SUBPROCESS ̲SINGE ̲CAP refer CPS/DBD/001
ACCESS ̲PROFILE refer CPS/DBD/001
SPECIAL ̲HANDLING ̲DESIGNATOR refer CPS/DBD/001
b) C̲o̲m̲m̲o̲n̲ ̲T̲y̲p̲e̲s̲
TYPE MSOS ̲CO ̲OP ̲TYPE = RECORD
COROUTINE ̲OP : COROUTINE
̲OPERATION
CMD: CO ̲CMD ̲TYPE
OP ̲ID: ID ̲TYPE
PARA1: INTEGER
PARA2: INTEGER
PARA3: INTEGER
END
TYPE IDENT ̲TYPE = (SEVCO ̲IDENT,SEFCO ̲IDENT,SEDIA
̲IDENT,
SETR ̲IDENT, CMDQ ̲IDENT,CCMDQ ̲IDENT,
FC ̲KEY ̲IDENT, ANQ ̲IDENT,VDU ̲IDENT,
TYPE ID ̲TYPE = ARRAY (1 2) OF BYTE
CMD
NO IDENT OP ̲ID.NO:COUNTER
̲TYPE
PARA1 OP ̲ID.IDENT:IDENT
̲TYPE
PARA2
PARA3…86…1 …02… …02… …02… …02……02… …02…
…02… …02… …02…
CO ̲CMD ̲TYPE = (INIT ̲SEFCO ̲CMD,RESTART ̲SEFCO ̲CMD,
START ̲SEFCO ̲CMD,STOP ̲SEFCO ̲CMD,
BLOCK ̲SEFCO ̲CMD,CLOSE ̲DOWN ̲SEFCO ̲CMD,
INIT ̲SEFCO ̲CC,RESTART ̲SEFCO ̲CC,START
̲SEFCO ̲CC,
STOP ̲SEFCO ̲CC,BLOCK ̲SEFCO ̲CC,CLOSE ̲DOWN
SEFCO ̲CC,MSO ̲MODE ̲CHANGE,SEND ̲NOTIFICATION,
SEND ̲ANTINOTIFICATION,CLOSE,CANCEL ̲I
̲O,
CLEAR ̲VDU,INPUT ̲DATA,OUTPUT ̲DATA,DISPLAY
MENU,OUTPUT ̲FORMAT,L ̲INSERT,L ̲DELETE,
GARBLE ̲IN,ONLINE ̲NOTIFICATION,OFF ̲LINE ̲NOTIFICATION,RERUN
̲
NOTIFICATION,READDRESS NOTIFICATION,RETRIEVAL ̲ERROR)
SEVCO ̲CMD ̲TYPE = INIT ̲SEFCO ̲CMD CLOSE ̲DOWN ̲SEFCO ̲CMD
SEFCO ̲CC ̲TYPE = INIT ̲SEFCO ̲CC SEND ̲ANTINOTIFICATION
SEFCO ̲SEDIA ̲CMD ̲TYPE = CLOSE GARBLE ̲IN
SETR ̲SEFCO ̲RESPONCE ̲TYPE = ONLINE ̲NOTIFICATION RETRIEVAL
̲ERROR
TYPE MSO ̲RECV ̲QUEUE ̲TYPE = (OUTGOING ̲Q,INCOMING ̲Q,
ANSWER ̲Q)
TYPE CURRENT ̲MODE = (OUTQ ̲MODE, INCO ̲MODE,
RESP ̲MODE,
INTERACTIVE ̲MODE)
TYPE Q ̲POINTER = (NO ̲Q,OUTQ,INCQ,RESPQ,USER
̲RESP ̲Q, USER ̲RELS ̲Q,USER
̲RECV ̲Q)
TYPE QUEUE ̲ERROR = QERROR ̲INFO ̲TYPE
TYPE INTERNAL ̲ERROR = RECORD
USER ̲CC : INTEGER
USER ̲INF: ARRAY(l..4)OF
INTEGER
END
TYPE CO ̲CMD ̲CC = (OK ̲CC,ERROR ̲CC,SPLIT ̲FAILED ̲CC)
c) M̲S̲O̲ ̲C̲o̲m̲m̲o̲n̲ ̲D̲a̲t̲e̲
VAR SEVCO ̲OP,MSOS ̲OP, SETR ̲OP,CMD ̲OP,
CCMD ̲OP,ANQ ̲OP,FC ̲KEY ̲OP, VDU ̲OP: MSOS ̲CO ̲OP
̲TYPE
INIT SETR ̲OP.IDENT= SETR ̲IDENT
INIT CMD ̲OP.IDENT = CMDQ ̲IDENT
INIT CCMD ̲OP.IDENT = CCMDQ ̲IDENT
INIT FC ̲KEY ̲OP.IDENT= FC ̲KEY ̲IDENT
INIT ANQ ̲OP.IDENT = ANQ ̲IDENT
INIT VDU ̲OP.IDENT = VDU ̲IDENT
VAR MSOS ̲Sl,MSOS ̲S2,MSOS ̲S3 : COROUTINE ̲SEMAPHORE
VAR FORMAT ̲IFCB,
HEADER ̲IFCB: IFCB ̲INDEX ̲TYPE
VAR TRANSACTION ̲ID = RECORD
TERMINAL ̲DESIGNATOR:DESIGNATOR
̲TYPE
SERIAL ̲NO :INTEGER
TIME :TIME
̲TYPE
END RECORD
VAR INPUT ̲CIF,
OUTPUT ̲CIF: VIEW ̲REFERENCE
VAR CURRENT ̲MODE: CURRENT ̲MODE ̲TYPE
VAR Q ̲REFERENCE: QUEUE ̲REFERENCE
VAR CURRENT ̲CLASS: CLASSIFICATION ̲TYPE
VAR CURRENT ̲SUBQ: PRECEDENCE ̲TYPE
VAR QERROR ̲INF: QUEUE ̲ERROR ̲TYPE
VAR INT ̲ERROR ̲INF: INTERNAL ̲ERROR ̲TYPE
VAR MSOS ̲SEND ̲PARAMS: SEND ̲PARAMS
VAR PREC ̲POINTER: PRECEDENCE ̲TYPE
VAR SEFCO ̲SETR ̲ATTR,
SETR ̲QEL ̲ATTR,
MSO ̲RECV ̲ATTR: QEL ̲ATTRIBUTES
VAR VDU ̲SPLIT ̲FLAG: BOOLEAN
VAR USER ̲ACTIVE ̲FLAG: BOOLEAN
VAR FIELD ̲DESCRIP: IOC ̲FIELD ̲DESCRIPTOR ̲TYPE
VAR CIF ̲BUFFER = ARRAY(l..MAX ̲SAR ̲RETRIEVAL ̲KEY
̲SIZE)OF
INTEGERS
VAR SEDIA ̲PARAMETER ̲INFOR ̲TYPE = PARAMETER ̲INFO
̲TYPE
VAR Q ̲POINTER: Q ̲POINTER ̲TYPE…86…1 …02… …02… …02… …02… …02…
…02… …02… …02…
TYPE EDIT ̲PARAMETERS = RECORD
ITEM ̲REF : INTEGER
LTD: LOGICAL ̲TERMINAL ̲NO ̲TYPE
ACCESS ̲PROFILE: LONG
EDIT ̲REC: EDIT ̲REQUEST ̲TYPE
END
VAR ITREF: ITEM ̲REFERENCE ̲IDENTIFY
VAR START ̲UP: INTEGER
VAR EDIT ̲PARAM: EDIT ̲PARAMETERS
VAR VDU ̲HEADER ̲AREA = RECORD
TIME:ARRAY(1 TIME ̲LENGTH)OF
TWO ̲CHAR
CLASS:ARRAY(1 CLASSI ̲LENGTH)
OF TWO ̲CHAR
PREC1:TWO ̲CHAR
PREC2:TWO ̲CHAR
PREC3:TWO ̲CHAR
PREC4:TWO ̲CHAR
PREC5:TWO ̲CHAR
PREC6:TWO ̲CHAR
IN:TWO ̲CHAR
OUT:TWO ̲CHAR
RESP:TWO ̲CHAR
USER:TWO ̲CHAR
END
CONST TIME ̲LENGTH = 7
CONST CLASSI ̲LENGTH = 10
CONST KEY ̲BUF ̲START = 0
CONST KEY ̲BUF ̲SIZE =
CONST MSOS ̲ARRQ = MSOS ̲MSOS ̲ARRQ
CONST MSOS ̲IMQ = MSOS ̲MSOS ̲IMQ
CONST MSOS ̲OMQ = MSOS ̲MOSO ̲OMQ
CONST MSOS ̲CMDQ = MSOS ̲MSOS ̲CMDQ
CONST MSOS ̲CCMDQ = MSOS ̲MOSO ̲CCMDQ
VAR INIT ̲AREA = RECORD
CMD ̲SPLIT ̲COUNT ̲ID:OFFER ̲ID
CMD ̲SPLIT ̲DATA ̲ID:OFFER ̲ID
FORMAT ̲SPLIT ̲COUNT ̲ID:OFFER ̲ID
FORMAT ̲SPLIT ̲TERMINAL ID:OFFER ̲ID
LOGICAL ̲TERMINAL ̲NO:LOGICAL ̲TERMINAL
̲NO ̲TYPE
TERMINAL ̲DESIGNATOR:TERMINAL ̲DESIGNATOR
̲TYPE
USER ̲CAP:USER ̲FCT ̲CAPABILITY ̲TYPE
FCT ̲CAPABILITY:FCT ̲CAPABILITY ̲TYPE
ACC:ACCESS ̲PROFILE
MAX ̲CLASS:CLASSIFICATION ̲TYPE
SPECIAL ̲HANDLING ̲INSTRUCTION: SPECIAL
̲HANDLING ̲
DESIGNATOR
END
4.1.5 C̲o̲m̲m̲o̲n̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
4.1.5.1 M̲S̲O̲S̲ ̲Q̲U̲E̲U̲E̲ ̲E̲R̲R̲O̲R̲
4.1.5.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The purpose of this procedure is to report queue errors
to the SSC.
4.1.5.1.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) MSOS ̲QUEUE ̲ERROR(USER ̲ACTION: USER ̲ACTION ̲TYPE,
QEL: QEL ̲REFERENCE,
VUS ̲QERROR: QERROR ̲INF)
b) MSOS ̲QUEUE ̲ERROR(R1, R3, R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R1 USER ̲ACTION DESTROYED
R3 POINTER TO QEL DESTROYED
R4 pointer to MSOS ̲QERROR DESTROYED
R6 LINK DESTROYED
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None
R0-R7 DESTROYED
4.1.5.1.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
USER ̲ACTION ̲TYPE refer CPS/DBD/001
GAQ ̲INFO ̲TYPE refer CPS/DBD/001
QEL ̲REFERENCE refer CPS/DBD/001
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
MSOS ̲QERROR refer 4.1.4
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
None
4.1.5.1.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
This procedure reports queue errors to the SSC by calling
the SEND ̲GARBLE-procedure.
4.1.5.2 V̲U̲S̲ ̲I̲N̲T̲E̲R̲N̲A̲L̲ ̲E̲R̲R̲O̲R̲
4.1.5.2.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The purpose of this procedure is to report internal
errors to the SSC.
4.1.5.2.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) MSOS ̲INTERNAL ̲ERROR (USER ̲ACTION ̲ USER ̲ACTION ̲TYPE,
MSOS ̲INT ̲ERROR: INTERNAL ̲ERROR
̲INF)
b) MSOS ̲INTERNAL ̲ERROR (R1, R4, R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R1 USER ̲ACTION DESTROYED
R4 pointer to VUS ̲INT ̲ERROR DESTROYED
R6 LINK DESTROYED
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None
R0-R7 DESTROYED
4.1.5.2.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
USER ̲ACTION ̲TYPE refer CPS/DBD/001
GAQ ̲INFO ̲TYPE refer CPS/DBD/001
QEL ̲REFERENCE refer CPS/DBD/001
INTERNAL ̲ERROR ̲INF ̲TYPE refer CPS/DBD/001
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
MSOS ̲INTE ̲ERROR refer 4.1.4
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
TYPE MSOS ̲INTERNAL ̲ERROR: INTERNAL ̲ERROR ̲INF ̲TYPE
4.1.5.2.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
This procedure reports internal errors to the SSC by
calling the SEND ̲GARBLE-procedure.
4.1.5.3 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The purpose of this procedure is to dismantle an object
referenced by a a QEL.
The referenced view will be checkpointed if the Checkpoint
Status is true.
The referenced view will be closed if the close boolean
is true.
4.1.5.3.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) DISM(QEL: QEL ̲REFERENCE ̲TYPE
CP ̲STATUS: BOOLEAN
OBJECT: OBJECT ̲TYPE)
CLOSE: BOOLEAN
b) DISM(R2, R4, R5, R6)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R2 QEL (DEST)
R4 CP ̲STATUS (DEST)
R5 OBJECT (DEST)
R6 LINK (DEST)
R7 CLOSE (DEST)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
None (DEST)
R0-R7 (DEST)
4.1.5.3.3 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
OBJECT ̲TYPE refer CPS/DBD/001
QEL ̲REFERENCE ̲TYPE refer CPS/DBD/001
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
None
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
CONST REC ̲LEVEL = DISK ̲CP
4.1.5.3.4 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲i̲g̲n̲
DISM
QEL EQ NIL?
CASE OBJECT ̲TYPE OF OBJECT ̲TYPE
TIMER,
QEL? DISMANTLE(QEL)(CC): OK
BUFFER? CASE DISMANTLE ̲BUFFER(QEL)(CC): ERROR
̲OK
ERROR? ANALYSE ̲ERROR(CC, 0)
OK?
END CASE
VIEW? ̲CLOSE EQ TRUE?
CASE CLOSE ̲VIEW(QEL)(CC): ERROR ̲OK
ERROR? ANALYZE ̲ERROR(CC,O)
OK?
END CASE
CP ̲STATUS EQ FALSE?-M̲S̲O̲ ̲C̲I̲F̲ ̲D̲I̲S̲M̲A̲N̲T̲L̲E̲ ̲(̲4̲.̲2̲.̲5̲.̲6̲.̲1̲-̲2̲)̲
CASE SAVE ̲VIEW(DISMANTLE, REC ̲LEVEL,QEL)
(CC): ERROR ̲OK
ERROR? ANALYSE ̲ERROR(CC, 0)
OK?
END CASE
OTHERWISE?- M̲S̲O̲ ̲I̲N̲T̲E̲R̲N̲A̲L̲ ̲E̲R̲R̲O̲R̲ ̲(̲4̲.̲2̲.̲5̲.̲6̲.̲3̲1̲)̲
END CASE
4.1.5.3.-1
MSO CIF DISMANTLE
CASE DISMANTLE ̲VIEW(QEL)(CC): ERROR ̲OK
ERROR? ANALYSE ̲ERROR(CC, 0)
OK?
END CASE
Fig. 4.1.5.3-2
4.1.6 G̲l̲o̲b̲a̲l̲ ̲D̲a̲t̲a̲
Refer CPS/DBD/001
4.1.7 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
4.1.7.1 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
MSO Procedures ref. doc. no. CPS/230/ICD/0002.
All MSOP subpackages interfaces, this document.
4.1.7.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
4.1.7.2.1 T̲r̲a̲f̲f̲i̲c̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲(̲T̲H̲P̲)̲ ̲I̲/̲F̲
This interface is implemented by the MSOS coroutine
SEFCO.
For details refer section 4.2 and doc. no. CPS/ICD/009.
4.1.7.2.2 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 MSOS coroutines
SEFCO (requests queued to SAR) and SETR (reception
of SAR responses).
For details, refer section 4.2 and doc. no. CPS/ICD/009.
4.1.7.2.3 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 MSOS coroutine
SEFCO. For details refer section 4.2 and doc. no. CPS/ICD/009.
4.1.7.2.4 S̲S̲C̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲I̲/̲F̲
This interface is implemented by the MSOS coroutines
SEVCO (start / stop function ) and SEFCO (security
interrogation request).
For details, refer sections 4.2 and doc. no. CPS/ICD/009.
4.1.7.2.5 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 MDOS coroutines
UFCO (GLOBAL no. series) and VDIA (table access).
For details refer section 4.2 and doc. no. CPS/ICD/009.
4.1.7.3 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
4.1.7.3.1 P̲r̲o̲c̲e̲s̲s̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
These are the interfaces between UMAM and MSOS:
F̲r̲o̲m̲ ̲M̲S̲O̲S̲ ̲t̲o̲ ̲U̲M̲A̲M̲:
1. Status Requests
2. Edit Requests
3. Delete Requests
4. Access State Changes
5. Status Records.
F̲r̲o̲m̲ ̲U̲M̲A̲M̲ ̲t̲o̲ ̲M̲S̲O̲S̲:̲
1. Access Key to CIF (QEL ref)
2. Delete Notification
3. Outgoing Service Message Status
4.1.7.3.2 C̲o̲r̲o̲u̲t̲i̲n̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
1̲.̲ ̲F̲r̲o̲m̲ ̲S̲E̲V̲C̲O̲ ̲t̲o̲ ̲S̲E̲F̲C̲O̲
1. INIT ̲SEFCO ̲CMD
2. Restart ̲SEFCO CMD
3. Start ̲SEFCO ̲CMD
4. Stop ̲SEFCO ̲CMD
5. Close ̲Down ̲CMD
6. Block ̲SEFCO ̲CMD
2̲.̲ ̲F̲r̲o̲m̲ ̲S̲E̲F̲C̲O̲ ̲t̲o̲ ̲S̲E̲V̲C̲O̲
1. STOP SEFCO CC
2. CLOSE ̲DOWN ̲CC
3. BLOCK SEFCO ̲CC
4. START ̲SEFCO ̲CC
5. RESTART ̲SEFCO ̲CC
6. INIT ̲SEFCO ̲CC
7. MSO ̲MODE ̲CHANGE
8. DISTRIBUTE ̲FLASH ̲NOTIFICATION
9. DISTRIBUTE ̲ANTIFLASH ̲NOTIFICATION
3̲.̲ ̲F̲r̲o̲m̲ ̲S̲E̲F̲C̲O̲ ̲t̲o̲ ̲S̲E̲D̲I̲A̲
1. OUTPUT ̲DATA
2. OUTPUT ̲FORMAT
3. CLOSE
4. CANCEL ̲I ̲O
5. CLEAR ̲VDU
6. INPUT ̲DATA
7. DISPLAY ̲MENU
8. L ̲INSERT
9. L ̲DELETE
10. GARBLE ̲IN
4̲.̲ ̲F̲R̲O̲M̲ ̲S̲I̲D̲I̲A̲ ̲T̲O̲ ̲S̲E̲F̲C̲O̲
The commands which applies to the interface from SEFCO
to SEDIA are also used here.
Further the returned operation carries information
about the execution, of the command i.e.
Command executed, VDU ̲SPLIT ̲FAILED and format validation
results.
5̲.̲ ̲F̲R̲O̲M̲ ̲S̲E̲F̲C̲O̲ ̲T̲O̲ ̲S̲E̲T̲R̲
NONE
6̲.̲ ̲F̲R̲O̲M̲ ̲S̲E̲T̲R̲ ̲T̲O̲ ̲S̲E̲F̲C̲O̲
1. ONLINE ̲NOTIFICATION
2. OFFLINE ̲NOTIFICATION
3. READDRESS ̲NOTIFICATION
4. RERUN ̲NOTIFICATION
5. RETRIEVAL ̲ERROR
