top - download
⟦72294fcb8⟧ Wang Wps File
Length: 49277 (0xc07d)
Types: Wang Wps File
Notes: CPS/SDS/037
Names: »1651A «
Derivation
└─⟦fa8144eef⟧ Bits:30006080 8" Wang WCS floppy, CR 0123A
└─ ⟦this⟧ »1651A «
WangText
…00……00……00……00……00…#…02……00……00…#
"…08…"…0d…"…02…!…09…!…0a…!…0c…!…0d…!…05…!…06… …0d… …0e…
…1f……0a……1f……01……1f……07……1e……0d……1e……0f……1e……05……1d……08……1d……0b……1d……0d……1d……00……1d……07……1c……0b……1c……0c……1c……01……1c……06……1c……07……1b……0b……1b……0c……1b……0f……1b……00……1b… …1b……07……1a……08……1a……0a……1a……0b……86…1 …02… …02… …02…
…02…CPS/SDS/037
…02…CGN/820514…02……02…
MDCO VDU
DETAILED DESIGN SPECIFICATION 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 MDCO VDU Package Specification for the CAMPS
Project/4040 is written to fulfil the following
objectives:
1) To provide a detailed definition of the MDCO
VDU package function and software architecture.
2) To provide MDCO operational and development
personnel with details of the ongoing analysis.
3) To specify in details the interfaces with other
packages and to describe their facilities.
b) The MDCO VDU package specification defines the
functions and software architecture of the package
to a level sufficient for a programmer to start
coding with a minimum of design effort on the architecture.
The MDCO VDU package constitutes one of the building
stones of the TEP package.
For an overall description of the TEP package refer
CPS/SDS/012.
All MDCO VDU package internal data and interfaces
are defined within this document in detail. For
a detailed data description of data external to
the VDU MDCO 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 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/024
Message Management CPS/SDS/025
System Status and Control CPS/SDS/029
Table Managment CPS/SDS/026
Input/Output Control CPS/SDS/028
Storage and Retrieval CPS/SDS/030
Statistics CPS/SDS/031
Logging CPS/SDS/032
Traffic Handling CPS/SDS/033
Message Distribution Package CPS/SDS/034
VDU Supervisor Package CPS/SDS/035
Supervisor Printer Package CPS/SDS/036
VDU MSO Package CPS/SDS/038
USER CPS/SDS/039
OCR Package CPS/SDS/040
Printer Package 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̲
N/A
1.3.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
MDCO Message Distribution Control Operator
MDOP MDCO VDU Package
MDOS MDOS VDU Process
DIVCO Delivery VDU Control
DIFCO Delivery Function Control
DIDIA Delivery VDU Dialogue
DIRT Delivery Retrieval
UMAM User Message Access Monitoring Process
IOC I/O Control Software
CSF Camps System Functions
TMP Traffic Handling Package
MDP Message Distribution Package
TMP Table Managenemt Package
SAR Storage and Retrieval
LOG Log and Accountability Package
TEP Terminal Package
SSC System Status and Control
VUS VDU-User Subprocess
TEMCO Terminal - Monitoring and Control
Command: Abbreviations:
SMPR Service message Preparation
MDAS Message Distribution Assistance
REDS Retrieval For Redistribution
RESP Responce Message
PRPF Prepare New Plaindress Message
PRAP Prepare New Abbreviated Plaindress Service
PRAS Prepare New Abbreviated Service Message
CRPF Continue Plaindress Message
CRAD Continue New Abbreviated Plaindress Message
CRAS Continue Abbreviated Service Message
DESM Delete Service Message
OSMS Outgoing Service Message Status…86…1
…02… …02… …02… …02…
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 M̲essage D̲istribution Control O̲perator VDU P̲ackage
(MDOP) constitutes the only means by which CAMPS Personnel
may gain access to the services of the CAMPS MDCO function.
a) The CAMPS MDCO function is made up of three
subfunctions, Service message Preparation,
Message Distribution assistance and Redistribution.
The MDCO can only get access to messages
or prepare message with the same classification
or lower than his own classification. In
figure 2.1-1 overleaf the services of the
CAMPS MDCO function are depicted.In figure
2.1-2 the facilities of the Service message
function are depicted.
b) The MDCO VDU package (MDOP) implements all
the services of the CAMPS MDCO function,
which implies the following responsibilities:
1) Interface
the
MDCO
to
the
CAMPS
system,
i.e.
Man/Machine
I/F
Support
and
monitoring
2) Direct
all
MDCO
requests/commands
to
the
relevant
package
within
CAMPS
3) Present
to
the
MDCO
messages
sent
to
his
VDU
4) Make
it
possible
for
the
MDCO
to
prepare
Service
Messages
and
change
addressees
of
incoming
messages
or
retrieved
messages.
c) The packages to which MDOP 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
Figure 2.1-1
In figure 2.1-3 an overview of the interfaces of MDOP
is depicted.
In figure 2.1-4 the message flow between MDOP and the
rest of the CAMPS system as well as the MDOP internal
flow are depicted, highlighting the most important
functional interfaces.
Information flow between MDOP and other CAMPS packages
is depicted in figure 2.1-5.
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
MDOP are outlined. As stated in section 2.1 the
main task of MDOP is to implement the CAMPS MDCO
function. The CAMPS MDCO function and the related
requirement will be treated as a whole, ie. the
three subfunctions, Service Message, Preparation,
Message Distribution Assistance and Redistribution
constituting the CAMPS MDCO function and will
be treated together in most sub-sections.
b) As a short introduction to the description of the
MDOP main functions and functional responsibilites
the environment of MDOP as they may be experienced
by the MDCO together with an overview of the services
of MDOP are outlined below. Refer figure 2.2-1.
The MDCO may access the preparation database, where
all service messages under preparation are kept.
The MDCO may insert/delete/edit Service Message
in the database.
The MDCO 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 MDCO may access the Distribution queue, which
is a queue of the precedence type and is common
for the four MDCO terminals. Here CAMPS inserts
the incoming and outgoing mesages for the purpose
of getting new addresses to the messages, in the
case where the addresses have been garbled or the
flash-time-out has happened. The MDCO may inspect/remove/get
a printed copy/change addresses of the queued items.
The MDCO may access the response queue, which is
a queue of the non-precedence type, into which
CAMPS inserts messages that were offline when a
retrieval request was issued by the MDCO. The MDCO
may inspect/remove/get a printed copy/change addresses
of the queued items.
The MDCO 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 MDOP are:
1) Continuously display queue status information
2) Continuously 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 Message Distribution Assistance
6) The means for directing requests to CAMPS and deliver
responses to the MDCO
7) Maintain and update message status files
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.1.1-1
The second line of the VDU header area is used for
queue status display. For each of the three queues;
Distribution queue (DISQ), response queue (RESP) and
USER queue (USER) the total amount of messages queued
for presentation shall be displayed.
The distribution queue is displaying the total amount
of items, the number of items will also be displayed
according to their precedence levels in the fields
marked: ZZ (FLASH), OO (IMMEDIATE), PP (PRIORITY),
RR (ROUTINE).
The response queue is only displaying the number of
items which have been stored off-line in CAMPS system
and for which the MDCO has issued a redistribution
request.
The user queue field contains the total number of messages/comments
destined to the MDCO in user mode if he has this capability.
The user queue field reflect the user ̲VDU's receive-,
release- and response queues.
FIGURE 2.2.1.1
2.2.1.2 I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲c̲e̲r̲n̲i̲n̲g̲ ̲t̲h̲e̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲i̲n̲ ̲P̲r̲o̲g̲r̲e̲s̲s̲
The first line of the VDU Header Area is used to identify
the Transaction in progress, for example Service message
preparation, Incoming Assistance or Redistribution
after which mode the MDCO has called upon. At the same
time the classificaton of the item currently accessed
will be displayed.
Whenever the classification is unknown or no transaction
is in progress the maximum classification to which
the MDCO may gain access through this VDU is displayed.
2.2.1.3 D̲i̲s̲p̲l̲a̲y̲ ̲o̲f̲ ̲Q̲u̲e̲u̲e̲d̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
An overview of transactions to be performed in the
Distribution mode and Response mode together with the
transaction control capabilities in each mode of operation
is given in figure 2.2.1.3-1. For the sake of completeness
the Interactive mode of operation is reflected as well.
The MDCO may inspect elements in the queue one by one,
remove them and/or request a printed copy. This is
done by means of the F/C Keys Keep and Present next,
Delete and Present next, Print, Cancel.
The queue is accessed in FIFO manner. To exit the Mode
of operation the MDCO activates the Return to current
menu F/C key.
Fig. 2.2.1.3
2.2.1.4 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 Service
Message Preparation Menu (Ref. CPS/230/ICD/0002.
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.5 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 sent or deleted Messages
2.2.1.6 R̲e̲d̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
The items for redistribution is presented via the REDS
command. In case where the retrieved item is off-line
when the command is given the item can be optained
from the Response queue by the RESP command, when delivered
by SAR.
Redistributions are processed in 5 phases:
1. Display retrieval format for entry of retrieval
keys
2. Validation of input information
3. Display of requested message
4. Display of format to enter addresses to the previous
message if the Enter F/C has been entered or display
of format for entry of new retrieval keys will
be displayed if the cancel F/C key has been entered.
5. Validation of input information.
2.2.1.7 M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲A̲s̲s̲i̲s̲t̲a̲n̲c̲e̲
These are the functions covered by the Message Distribution
Assistance Service (MDAS) command.
When some items can't be delivered by the Message distribution
package they are sent to the MDCO message distribution
assistance queue. The items in question are items with
missing or garbled addresses, items with flash precedence
that have not been delivered within time limit or items
with precedence that did not match on its way to its
distinating addresses.
The assistance is performed in two phases.
1. Different formats can be displayed depending on
which kind of distribution assistance is needed.
Here the new Staff Cell Designator's can be specified.
2. Then the item will be validated and sent for further
processing.
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̲
MDCO VDU Package performs the above functions.
1. Initialization: It includes initialization of the
Format Handler of the IOC-Software. The common
package procedure in VUP takes care of the initialization
of the MDOS process making the controlling units
(coroutines) ready to run, it also initialize the
Coroutine Monitor.
2. Close Down: This is termination of the current
processing in an ordered manner setting MDOS into
a state ready for restart.
3. Restart: This is performed after Close Down, Switchover
and Total System Failure and contains the elements
described for Initialization with the addition
of processing queue elements marked as "recovered".
2.2.2.2 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
Checkpointing is performed by calling the SAVE-function
(CSF-function) at appropriate points, that is when
a message is created, updated, and sent to queues in
the system.
Recovery is performed during restart and is processing
of queue elements returned by CSF and marked "recovered".
(E.g messages marked "recovered" found in the Answer
Queue are sent to the UMAM process).
2.2.2.3 E̲r̲r̲o̲r̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Errors detected by MDOP are some times solved by the
package itself, but when the error is fatal a report
is sent to SSC.
2.2.2.4 I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
MDOP contain credibility check to contain the effects
of corrupt or inaccurate data to the extent this does
not introduce redundant processing which will decrease
the system throughput.
It is a design aim that wherever possible the consequence
of a single software fault incident does not affect
more than one transactions. The detection of an inconsistency
indicating a fault does 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 major recovery or operator intervention action
is 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 MDCO VDU Package 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̲
The MDCO Package does not deliver statistics data.
3. R̲E̲P̲O̲R̲T̲S̲
The MDCO Package does not deliver Reports
2.2.2.6 S̲e̲c̲u̲r̲i̲t̲y̲
The MDCO VDU Package implements the security functions
listed below:
a) For each command entered by the MDCO the MDOP shall
compare the command against the MDCO's subfunctions
(Service Message Preparation, Message Distribution
Assistance, Redistribution) and prevent illegal
transactions to be 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 MDOP.
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 MDOP:
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 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̲
MDOP'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 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
BLOCK TERMINAL
STOP USER
3.3.2.2 T̲M̲P̲ ̲I̲/̲F̲
TMP provides access to tables, global number series
and system parameters. The tables accessed by MDOP
include:
AG
AIG
PLA
SCD
SIC
Validation tables
Sequence tables
Error tables
Command tables
Global no. series:
Transaction serial no.
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̲
SERVICE MESSAGES
3.3.2.6 M̲D̲P̲ ̲I̲/̲F̲
INCOMING ITEMS FOR DISTRIBUTION ASSISTANCE
REDISTRIBUTION
3.3.2.7 U̲M̲A̲M̲ ̲I̲/̲F̲
SERVICE MESSAGES UNDER PREPARATION
OUTGOING SERVICE MESSAGE STATUS
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 MDCO capability
Security Warning
Sign-off procedure
Security interrogation
on behalf of MDOP.
Initialization of Coroutines, semaphores, 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̲D̲CO̲ VDU-P̲ackage (MDOP) 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̲D̲CO̲ VDU Process̲ (MDOS) is shown
on fig. 4.1-1. It consists of 4 sub-packages (or coroutines)
as specified in sec. 4.1.2):
a) DIVCO (D̲eli̲very V̲DU C̲ontrol) which reacts upon
commands from TEMCO and controls the other coroutines
as well as maintaining the VDU Header Status Area.
b) DIFCO (D̲eli̲very F̲unction C̲o̲ntrol) which reacts
upon commands from DIVCO, F/C Keys (Function Keys)
from Keyboard and input from the Answer Queue Message
Distribution Queue and Response Queue. It also
receives input from the Delivery Retrieve Coroutine
(DIRT) and controls the Delivery Dialogue Coroutine
(DIDIA).
It contains all the functions for c̲o̲n̲t̲r̲o̲l̲ of the
M̲an M̲achine I̲nterface (MMI) and interfacing to
other packages as well as command execution.
c) DIDIA (D̲eli̲very 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 DIFCO.
d) DIRT (D̲eli̲very R̲et̲rieval) which receives answers
(messages or error-codes) from SAR on requests
sent to SAR from DIFCO. It communicates on-line
retrieval results to DIFCO and off-line retrieval
results to the Response Queue.
Communication with other packages (apart from Monitor
Calls) is done via queues. The MDOS has 6 input
queues:
Command Queue: Commands from TEMCO and timer
events from Timer Monitor, flash
and antiflash notification.
Common Command
Queue: Flash notifications for the four
MDCO terminals.
Answer Queue: Answers to requests to other packages.
Message Distri-
bution Queue: Incoming Message Distribution
assistance and Alternative Message
Distribution Assistance from Message
Distribution Package, also common
for the four MDCO terminals.
Response Queue: Off-line Retrieval Results (placed
in the queue by DIRT).
Retrieve Queue: Retrieval results (off-line and
on-line) from SAR.
The detailed analysis leading to the breakdown
of MDOP 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. Commands from SSC (e.g. start, stop), timer events,
and antiflash notification from the MDOP that got
the item with flash precedence (fig. 4.1-2).
2. Flash notification to the four MDCO's from the
common command queue.
3. Timer on flash initiated update of VDU header (queues,
time)
4. Control information from DIVCO to DIFCO
5. Commands/parameters and function keys
6. Transaction ID, classification, error messages
7. Messages and requests
8. Validated/unvalidated messages and system information
9. Retrieved messages
10. Off-line retrieval results are sent to the Response
queue for MDCO attention and access.
11. Retrieve finished signal to DIFCO and on-line retrieval
results.
12. Requested Message from UMAM, objected message from
THP and MDP and log acknowledge.
13. Items from MDP for Message Distribution Assistance.
14. Retrieved items that were off-lined stored when
the item was requested.
Fig. 4.1-2 shows that two types of command queues exist,
a common command queue and a separate command queue.
Fig. 4.1-2 outlines the interplay between the two queue
types.
When an item with flash precedence arrives for MDCO
assistance, a flash notification is sent to the common
command queue.
The MDOS who first receives the flash notification
sends a copy to the other MDOS's command queues in
order to update the queue information displayed and
thus notify all MDCO's of the arival of the flash item.
When a MDCO requests the flash item to be displayed
the corresponding MDOS sends an antiflash notification
to the other MDOS's command queues in order to update
the queue displays.
In the case where the MDCO returns the flash item to
the queue the corresponding MDOS sends a flash notification
to the other MDOS's command queues for renewed update
of displayed queue status.
The situation outlined in fig. 4.1-2 is a situation
where MDCO-1 receives a flash notification from the
common command queue and sends a flash notification
to MDCO-2, MDCO-3 and MDCO-4's command queues.
Figure 4.1-2
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 MDOP.
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 MDOP-functions is
shown on figure 4.1.1-1. The following main functions
are identified and broken down in this section.
TEMCO CONTROL FUNCTIONS:
These implement the TEMCO Commands (start, stop, close-down,
etc.).
QUEUE STATUS MAINTENANCE:
These maintain the VDU Header Status Area.
MDCO TRANSACTION CONTROL:
These are the bulk of the package functions controlling
the MMI and performing the MDCO transactions.
SERVICE MESSAGE DATABASE MAINTENANCE:
These functions perform access control and Status Maintenance
for Service Messages under preparation.
Fig. 4.1.1-1…01…MDOP Main functions
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.1.1-1
START SESSION is performed on command from TEMCO following
a successful SIGN-ON procedure.
STOP SESSION is performed on command from TEMCO following
a SIGN-OFF procedure.
CLOSE-DOWN is performed on command from TEMCO during
Ordered System Close Down.
BLOCK TERMINAL is performed on command from TEMCO when
the Supervisor has specified the terminal to be blocked.
Figure 4.1.1.1-1…01…TEMCO Control functions
4.1.1.2 Q̲u̲e̲u̲e̲ ̲S̲t̲a̲t̲u̲s̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
Functional breakdown of these functions is shown in
figure 4.1.1.2.1.
- The periodic update of the VDU header queue status
line with a periodicity of one minute.
- The immediate update of Flash (and superflash)
presedence queues each time an item is placed in
such a queue.
The breakdown of the Queue Status Maintenance should
be self evident, except for a few functions explained
below.
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 queued
for the MDCO User Function (i.e. the Receive-, Release.
and Response Queue).
UPDATE DISTRIBUTION QUEUE LENGHT FIELD:
This field contains the total number of elements queued
for all the MDCOs in the Distribution Queue.…86…1
…02… …02… …02… …02… …02…
UPDATE RESPONSE QUEUE LENGTH FIELD:
This field contains the total number of elements queued
for MDCO in the Response Queue. It is updated to reflect
current state of the queue.
DISPLAY QUEUE STATUS INFORMATION:
This function performs the actual display of the VDU
Header Queue Status Line.
The INTERPRET FLASH NOTIFICATION function implements
the following requirements.
- When a package places an item in a Flash precedence
level queue, it shall place a Flash notification
in the common command queue as well.
The INTERPRET ANTI-FLASH NOTIFICATION function identifies
the antiflash notification.
Figure 4.1.1.2-1
4.1.1.3 T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲A̲c̲c̲o̲u̲n̲t̲i̲n̲g̲
Functional break-down of these functions is shown in
figure 4.1.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…01…Transaction Accounting
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…01…Transaction Interruption
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̲
A functional breakdown of these functions is shown
on fig. 4.1.1.5-1. The functions are performed when
a command is entered in the Command Line of the VDU
Header.
Command Validation is performed to check that the command
is a valid MDCO 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 the command or
parameters are not acceptable.
Fig. 4.1.1.5-1…01…COMMAND Interpretation
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…01…Command Execution
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.
REQUEST ACCESS TO CIF is performed via request to UMAM
when a Preparation or Presentation Transaction shall
start.
GIVE UP ACCESS TO CIF is performed via request to UMAM
when a Preparation or Presentation Transaction shall
stop.
CLEAR USED WORK SPACE is performed when a Preparation
or Presentation Transaction has stopped.
Fig. 4.1.1.7-1…01…START/STOP TRANSACTION EXECUTION
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…01…Preparation of Service Message
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.
OUTPUT DISTRIBUTION DECISION INPUT FORMAT is displaying
the appropriate format for the following action.
DISPLAY QUEUE ITEM initiates display of the item from
the Distribution queue or retrieved item.
OUTPUT REDISTRIBUTION DECISION INPUT FORMAT is displaying
the format for entry of addresses.
FETCH SAR ERROR CODES are performed if the off-line
Retrieval request was unsuccessful.
ERROR CODE FORMAT DISPLAY is performed to give details
of reason for failure of off-line retrieval.
Figure 4.1.1.9-1…01…Presentation of Queued Information
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
figures 4.1.1.10-1 to 4.1.1.10-3.
RETRIEVAL REQUESTS are the requests made available
via the RETV Menu (ref CPS/230/ICD/0002) and a further
breakdown is shown in figure 4.1-22.
MESSAGE TREATMENT REQUESTS are the operations that
can be performed upon a prepared Service Message. A
further breakdown is shown in figure 4.1-23.
OUTGOING MESSAGE STATUS REQUEST is the requests made
available via the OSMS command.
PRINT REQUESTS are the requests for print of messages/service
messages signalled by activation of the PRINT F/C Key.
Figure 4.1.1.10 - 1
Fig. 4.1.1.10-2…86…1 …02… …02… …02… …02… …02…
Fig. 4.1.1.10-3…86…1 …02… …02… …02… …02… …02…
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/006.
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 FORMAT is performed when errors
are found during validation.
Figure 4.1.1.12-1…01…FORMAT VALIDATION
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
this 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 into software components.
Figure 4.1.2-1 shows the Initialization procedure of
the Tep packages. VUS, MSOS and MDOS are all packages
which Coroutines and semaphores are initialized by
VUS Initialized SUBPACKAGE.
Figure 4.1.2.-2 shows the mapping of functions into
processes and coroutines.
MDOS contains the coroutines:
DIVCO D̲eli̲very V̲DU Control
DIFCO D̲eli̲very F̲unction Control
DIDIA D̲eli̲very VDU D̲i̲a̲logue
DIRT D̲eli̲very R̲et̲rieval
The detailed analysis leading to the software structure
of MDOS 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 functional breakdown
are presented in highlighted boxes in this section).…86…1
…02… …02… …02… …02… …02…
Fig. 4.1.2-1
Fig. 4.1.2-2…86…1 …02… …02… …02… …02… …02…
4.1.2.1 D̲I̲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
DIFCO via commands and processes completion reports
from DIFCO 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
and take care of the signalling when a flash notification
arrives to the terminal.
Fig. 4.1.2.1-1…01…MDOP Coroutine Software Structure
Fig. 4.1.2.1-2…01…DIFCO-STRUCTURE-PROCESS START-UP
Fig. 4.1.2.1-3…01…DIFCO STRUCTURE-PROCESS DIFCO CONTROL
Fig. 4.1.2.1.1-4…01…DIFCO STRUCTURE-PROCESS
Fig. 4.1.2.1.1-5
Fig. 4.1.2.1.1-6
Fig. 4.1.2.1.1-7
Fig. 4.1.2.1.1-8
4.1.2.2 D̲I̲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 DIVCO and controls DIDIA via
commands and processes completion reports from DIDIA
corresponding to the commands.
It communicates with DIVCO by sending completion reports
corresponding to commands received from DIVCO.
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 DIDIA.
Figures 4.1.2.2-1 to 4.1.2.2-9 show the software structure.
Fig. 4.1.2.2-1…01…DIFCO Structure
Fig. 4.1.2.2-2…01…DIFCO STRUCTURE-EXECUTE INITIALIZATION COMMAND
Fig. 4.1.2.2-3…01…DIFCO STRUCTURE-EXECUTE RESTART…01…DIFCO COMMAND
Fig. 4.1.2.2-4…01…DIFCO STRUCTURE-EXECUTE START…01…DIFCO COMMAND
Fig. 4.1.2.2-5…01…DIFCO STRUCTURE-EXECUTE STOP DIFCO COMMAND
Fig. 4.1.2.2-6…01…DIFCO STRUCTURE-EXECUTE STOP DIFCO COMMAND
Fig. 4.1.2.2-7…01…DIFCO STRUCTURE-EXECUTE BLOCK DIFCO COMMAND
Fig. 4.1.2.2-8…01…DIFCO STRUCTURE-PROCESS INVALID…01…F/C KEY INTERRUPT
Fig. 4.1.2.2-9…01… …86…1 …02… …02… …02… …02… …02…
4.1.2.3 D̲I̲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 or sends requests to the DIFCO sub-process.
It accepts commands from DIFCO and sends completion
reports corresponding to these commands.
It communicates with the VDU via the Format Handler
of the IOC Package and accesses data in the Internal
Message Format (IMF) via the Message Monitor of the
CSF Package.
Figures 4.1.2.3-1 shows the software structure.
Fig. 4.1.2.3-1
4.1.2.4 D̲I̲R̲T̲ ̲S̲u̲b̲-̲P̲a̲c̲k̲a̲g̲e̲
This coroutine receives input from SAR via the Retrieve
Queue and communicates with DIFCO.
This communication is done by DIRT sending On-line
Retrieval Results directly to DIFCO and Off-line Retrieval
Results indirectly via the Response Queue.
Figure 4.1.2.4-1 shows the Software Structure.
Fig. 4.1.2.4-1…01…DIRT STRUCTURE
4.1.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
This section describes the Data Flow between the MDOP
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̲
MDOS 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 MDOS
and UMAM.
Fig. 4.1.3.1-1…01…MDOP PROCESS SYNCHRONIZATION
COLLECT QUEUE: 1) Current Access State of Service
Message
Temporary Outgoing Message Status
Entry
Access Key (Q-Elem) to CIF (Service
Message)
2) Permanent Entry in Outgoing Message
Status
ANSWER QUEUE: 1) Access Key (Q-Elem) to CIF (Service
Message)
Outgoing Service Message Status.
4.1.3.2 M̲D̲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 MDOS 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.
DIVCO waits for the S1 Semaphore. S1 is associated
with the Command Queue and thus as soon as an element
is sent to this DIVCO is ready to run. Elements sent
to this queue are TEMCO commands and Timer events.
DIVCO has highest priority as it controls the process.
DIVCO Signals the S2 Semaphore in order to start DIFCO.
DIFCO 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 MDOP is
via F/C Keys DIFCO controls the operation of the VDU
(MMI).
DIFCO is also activated by DIVCO signalling S2 and
will then process commands passed from DIVCO.
When DIRT signals S2 DIFCO will get a Retrieval Result
passed to it from DIRT.
The access to the Response Queue is direct in the way
that DIFCO does not wait for input to the queue, but
on request from the Supervisor (RESP-cmd) accesses
the queue.
DIDIA waits for S3. When S3 is signalled DIDIA receives
commands from DIFCO. DIDIA performs input/output to
and from the VDU format area on request by DIFCO and
informs DIFCO of completion by signalling S2 and passing
a Command Completion Report to DIFCO.
DIRT waits for input in the Retrieve Queue. When a
retrieval request is sent to SAR by DIFCO SAR answers
back by sending a Retrieval Result to the Retrieve
Queue. If the retrieved item is on-line DIRT passes
the item directly to DIFCO (by signalling S2).
If the retrieved item is off-line DIRT will send the
item to the Response Queue. SAR error codes will be
treated the same way in the two cases.
DIFCO will have lower priority than DIVCO but higher
than DIDIA and DIRT to ensure proper control, and DIDIA
and DIRT will have equal priority.
Fig. 4.1.3.2-1…01…MDOP STRUCTURE
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 MDCO CAPABILITY
3. SELECT MESSAGE DISTRIBUTION ASSISTANCE MODE
(MDAS-CMD)
4. SIGN OFF
The Following HIPO diagrams illustrates the flow.
15 HIPO DIAGRAMMER
