top - download
⟦d3b3f7f1e⟧ Wang Wps File
Length: 57542 (0xe0c6)
Types: Wang Wps File
Notes: CPS/ICD/009
Names: »1151A «
Derivation
└─⟦0a9635741⟧ Bits:30006044 8" Wang WCS floppy, CR 0070A
└─ ⟦this⟧ »1151A «
WangText
…00……00……00……00……00…D…0a……00……00…D…0b…D…00…D…05…C…0a…C…0f…C…01…C…05…B…09…B…0b…B…0e…B…02…B B…07…A…0a…A…0d…A…00…A
A…05…@…09…@…0f…@ @…06…?…08…?…0d…?…01…?…06…>…09…>…0c…>…86…1 …02… …02… …02…
…02…CPS/ICD/009
…02…850401…02……02…
CAMPS SOFTWARE INTERFACE CONTROL DOCUMENT
…02…Issue 2.1…02…CAMPS
6̲ ̲ ̲S̲Y̲S̲T̲E̲M̲ ̲E̲V̲E̲N̲T̲S̲ ̲A̲N̲D̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
6.1 A̲U̲D̲I̲T̲ ̲D̲A̲T̲A̲ ̲C̲O̲L̲L̲E̲C̲T̲I̲O̲N̲
6.1.1 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲D̲a̲t̲a̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
STP data collection is invoked by calling a monitor
procedure STP COLL. The call parameters are used in
updating the data area containing the collected statistics
information. This area is stored on disk every 6 minutes
and prepared for receiving statistics data during the
next 6 minutes interval.
6.1.1.1 S̲p̲e̲c̲i̲f̲i̲c̲ ̲I̲n̲p̲u̲t̲ ̲D̲a̲t̲a̲ ̲f̲o̲r̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
Packages contributing with statistics information delivered
to STP collection sub-package are:
- Traffic Handling, THP
- CAMPS System Function, CSF
- Message Distribution, MDP
- Terminal Package, TEP
- System Status and Control, SSC
6.1.1.1.1 T̲H̲P̲ ̲C̲o̲n̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
THP delivers a statistics record related to each of
the following groups:
- incoming messages per channel
- outgoing messages per channel
- incoming channel availability
- outgoing channel availability
6.1.1.1.2 C̲S̲F̲ ̲C̲o̲n̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
CSF delivers a statistics record related to the following
group:
- storage occupancy
6.1.1.1.3 M̲D̲P̲ ̲C̲o̲n̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
MDP delivers a statistics record related to each of
the following groups:
- incoming message distribution per terminal
- outgoing message distribution per terminal
- incoming message distribution per distribution
- outgoing message distribution per distribution
6.1.1.1.4 T̲E̲P̲ ̲C̲o̲n̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
TEP delivers a statistics record related to each of
the following groups:
- use of message formats, type 1
- use of message formats, type 2
6.1.1.1.5 S̲S̲C̲ ̲C̲o̲n̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
SSC delivers a statistics record related to the following
group:
- use of message formats, type 2, format I1 and format
I2.
6.1.1.2 W̲h̲e̲n̲ ̲T̲o̲ ̲C̲o̲l̲l̲e̲c̲t̲
The time at which the statistics data record is delivered
or collected by the previously mentioned packages is
specified according to events.
Group 1, incoming message data record is collected
after analysis.
Group 2, outgoing message data record is collected
after transmission.
Group 3, storage occupancy is collected every 6 minutes.
Group 4, channel availability and occupancy data record
is collected each time a channel either opens or closes.
Group 5, incoming message distribution data record
is collected after the message is queued to the terminals
by MDP.
Group 6, outgoing message distribution data record
is collected after the message is queued to the terminals
by MDP.
Group 7, use of format 1 data record is collected after
completion of format use.
Group 8, use of format 2 data record is collected after
completion of format use.
6.1.1.3 W̲h̲a̲t̲ ̲t̲o̲ ̲C̲o̲l̲l̲e̲c̲t̲
The information to be collected, delivered by the previously
mentioned packages, is listed below. Data are delivered
in form of a record consisting of a header and a variable
number of parameters.
6.1.1.3.1 R̲e̲c̲o̲r̲d̲ ̲H̲e̲a̲d̲e̲r̲
Identifies the event and involved equipment. The header
parameters are:
a) Group Number
Group number identifies which of the following
groups the parameters are related to:
Group Category
1 Incoming messages per channel
2 Outgoing messages per channel
3 Incoming channel availability
4 Outgoing channel availability
5 Incoming message distribution per terminal
6 Incoming message distribution per distribution
7 Outgoing message distribution per terminal
8 Outgoing message distribution per distribution
9 Use of message formats, type 1
10 Use of message formats, type 2
Type definition is defined in the CPS/DBD/001 section
4.8.5
b) S̲u̲b̲-̲g̲r̲o̲u̲p̲ ̲N̲u̲m̲b̲e̲r̲
Sub-group number identifies which of the formats
from group 9 or 10 (use of formats) the parameters
are related to. For group 9, the formats are:
format A
format C1
format G1
format M
format O
For group 10, the formats are:
format B
format D
format F
format G2
format H
format I1
format I2
format N
format P1
format P2
format Q
format R
Type definitions are defined in the CPS/DBD/001
section 4.8.5.
For group 6 and 8 the subgroups are: VDUs
PRINTERs
c) R̲e̲c̲o̲r̲d̲ ̲N̲u̲m̲b̲e̲r̲
The record number identifies which part of the
equipment i.e. channel or terminal, that the parameters
are related to.
Type definition is defined in the CPS/DBD/001 section
4.8.5
6.1.1.3.2 R̲e̲c̲o̲r̲d̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲s̲
The following groups and contents are present.
For Record definitions refer CPS/DBD/001 section 4.8.5.
6.1.1.3.2.1 G̲r̲o̲u̲p̲ ̲1̲ ̲D̲e̲l̲i̲v̲e̲r̲e̲d̲ ̲b̲y̲ ̲T̲H̲P̲
Incoming messages per channel
Parameters delivered are as follows:
INC ̲MSG ̲PER ̲CHN
MSG ̲LENGTH
PREC ̲LEV
CLASS ̲CAT
SPEC ̲HAND
REJ ̲IND
6.1.1.3.2.2 G̲r̲o̲u̲p̲ ̲2̲
Outgoing messages per channel
Parameters delivered are as follows:
OUTG ̲MSG ̲PER ̲CHN
MSG ̲LENGTH
PREC ̲LEV
CLASS ̲CAT
SPEC ̲HAND
6.1.1.3.2.3 G̲r̲o̲u̲p̲ ̲3̲
Incoming channel availability
Parameters delivered are as follows:
INC ̲CHN ̲AVAIL
…02……02……02……02…OPEN ̲CLOSE ̲INDIC
OPEN ̲CLOSE ̲TIME
BAUDRATE
6.1.1.3.2.4 G̲r̲o̲u̲p̲ ̲4̲
Channel availability and occupancy
Parameters delivered are as follows:
OUTG ̲CHN ̲AVAIL
OPEN ̲CLOSE ̲INDIC
OPEN ̲CLOSE ̲TIME
BAUDRATE
6.1.1.3.2.5 G̲r̲o̲u̲p̲ ̲5̲
Incoming messages distribution per terminal
Parameters delivered are as follows:
INC ̲MSG ̲DIST ̲PER ̲TERM
MSG ̲LENGTH
INF ̲PREC ̲LEV
ACT ̲PREC ̲LEV
CLASS ̲CAT
SPEC ̲HANDL
TERM ̲IN ̲DIST
ASS ̲REQ ̲INDIC
6.1.1.3.2.6 G̲r̲o̲u̲p̲ ̲6̲
Incoming message distribution per distribution.
…02…Parameters delivered are as follows:
…02…INC ̲MSG ̲DIST ̲PER ̲DIST
…02……02……02……02… MSG ̲LENGTH
INF ̲PREC ̲LEV
ACT ̲PREC ̲LEV
CLASS ̲CAT
SPEC ̲HAND
TERM ̲IN ̲DIST
ASS ̲REQ ̲INDIC
6.1.1.3.2.7 G̲r̲o̲u̲p̲ ̲7̲
Outgoing message distribution per terminal:
…02…Parameters delivered are as follows:
…02……02…OUTG ̲MSG ̲DIST ̲PER ̲TERM
MSG ̲LENGTH:
INF ̲PREC ̲LEV:
ACT ̲PREC ̲LEV:
CLASSIFIC ̲CAT:
SPEC ̲HAND:
TERM ̲IN ̲DIST:
ASS ̲REQ ̲INDIC:
6.1.1.3.2.8 G̲r̲o̲u̲p̲ ̲8̲
Outgoing messages distribution per distribution
Parameters delivered are as follows:
OUTG ̲MSG ̲DIST ̲PER ̲TER = MSG ̲LENGTH
PREC ̲LEV
CLASS ̲CAT
SPEC ̲HAND
TERM ̲IN ̲DIST
ASS ̲REQ ̲INDIC
6.1.1.3.2.9 G̲r̲o̲u̲p̲ ̲9̲
Use of formats 1
Parameter delivered are as follows:
FORMAT ̲TYPE ̲1 DURATION ̲TIME
PREC ̲LEV
CLASS ̲CAT
6.1.1.3.2.10 G̲r̲o̲u̲p̲ ̲1̲0̲
Use of format 2
- no parameters delivered.
6.1.2 L̲o̲g̲ ̲D̲a̲t̲a̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
The collected Log information is queued to the Incoming
Log queue by the packages that have created the log
record.
6.1.2.1 S̲p̲e̲c̲i̲f̲i̲c̲ ̲I̲n̲p̲u̲t̲ ̲D̲a̲t̲a̲ ̲f̲o̲r̲ ̲L̲o̲g̲g̲i̲n̲g̲
Packages contributing with logging information delivered
to Incoming Log Queue are:
- Traffic Handling, THP
- Terminal package, TEP
- CAMPS System Functions, CSF
- System, Status and Control, SSC
6.1.2.1.1 T̲H̲P̲ ̲C̲o̲n̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
THP delivers a Log record for the following transactions:
- Valid incoming message log
- Invalid incoming message log
- Outgoing message log
- Channel discontinuity log
- PTP log
Ref. fig. 6.1.2-2
6.1.2.1.2 T̲E̲P̲ ̲C̲o̲n̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
TEP delivers a log record for the following transactions.
- Log of supervisor transactions
- Log of MDCO transactions
- Log of MSO transactions
- Log of output to printer
- Log of input from OCR
- Log of user procedures
ref. fig. 6.1.2-3, 6.1.2-4, 6.1.2-5.
6.1.2.1.3 C̲S̲F̲ ̲C̲o̲n̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
- Log of CTS and ATOMAL MSG deletion
- Log of Encrypted MSG deletion
ref. fig. 6.1.2-6
6.1.2.1.4 S̲S̲C̲ ̲C̲o̲n̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
- Log of security procedures
6.1.2.2 W̲h̲a̲t̲ ̲T̲o̲ ̲C̲o̲l̲l̲e̲c̲t̲
The information delivered by the previously mentioned
packages is described in this section. Data is delivered
in the form of a record, and consists of a variable
number of parameters.
TRAFFIC ̲LOG = RECORD
DESIGNATOR: DESIGNATOR ̲TYPE;
SERIAL ̲NO: STATION ̲SERIAL ̲NO ̲TYPE;
MESSAGE ̲TYPE: MESSAGE ̲TYPE ̲TYPE
ITEM ̲1 ̲REF ̲ID: ITEM ̲REF ̲ID ̲TYPE;
PRECEDENCE: PRECEDENCE ̲TYPE;
CALLING ̲STATION: STATION ̲ID ̲TYPE;
STATION ̲SERIAL ̲NO: STATION ̲SERIAL ̲NO ̲TYPE;
FILING ̲TIME: TIME ̲TYPE;
CLASSIFICATION: CLASSIFICATION ̲TYPE;
SPEC ̲HAND ̲CAT: SPEC ̲HAND ̲TYPE;
SIC: SIC ̲GROUP ̲TYPE;
PROBLEM ̲CODE: PROBLEM ̲CODE ̲TYPE;
EXP ̲CHANNEL ̲SERIAL ̲NO: CHANNEL ̲SERIAL ̲NO ̲TYPE
END;
Fig. 6.1.2-2…01…TRAFFIC LOG
VDU ̲SUPV ̲LOG = RECORD
TERMINAL ̲DESIGNATOR: TERMINAL ̲DESIGNATOR ̲TYPE;
TRANSACTION ̲SERIAL ̲NO: TRANSACTION ̲SERIAL ̲NO ̲TYPE;
FORMAT ̲ID: TEP ̲FORMAT ̲ID ̲TYPE;
ITEM ̲1 ̲REF ̲ID: ITEM ̲REF ̲ID ̲TYPE;
EXIT ̲CAUSE: EXIT ̲CAUSE ̲TYPE;
TRANSACTION ̲START ̲TIME: TIME ̲TYPE;
MONTH ̲DAY: TIME ̲TYPE;
PROBLEM ̲CODE: REJECTION ̲CODE ̲TYPE
ITEM ̲2 ̲REF ̲ID: ITEM ̲REF ̲ID ̲TYPE
END;
Fig. 6.1.2-3…01…SUPERVISOR, MDCO, MSO LOG
PRINTER ̲OCR ̲LOG = RECORD
DEVICE ̲DESIGNATOR: DEVICE ̲DESIGNATOR ̲TYPE;
TRANSACTION ̲SERIAL ̲NO: TRANSACTION ̲SERIAL ̲NO ̲TYPE;
FORMAT ̲ID: TEP ̲FORMAT ̲ID ̲TYPE;
ITEM ̲1 ̲REF ̲ID: ITEM ̲REF ̲ID ̲TYPE;
EXIT ̲CAUSE: EXIT ̲CAUSE ̲TYPE;
CLASSIFICATION: CLASSIFICATION ̲TYPE;
SPEC ̲HAND ̲CAT: SPEC ̲HAND ̲TYPE;
TRANSACTION ̲START ̲TIME: TIME ̲TYPE;
SYSTEM ̲PRINT ̲CONT ̲NO: SYSTEM ̲PRINT ̲CONT ̲NO ̲TYPE
SPECIAL ̲HAND ̲PRINT ̲CONT ̲NO: ARRAY(0..4) OF CHAR;
END;
Fig. 6.1.2-4…01…PRINTER, OCR LOG
VDU ̲USER ̲LOG = RECORD
TERMINAL ̲DESIGNATOR: TERMINAL ̲DESIGNATOR ̲TYPE;
TRANSACTION ̲SERIAL ̲NO: TRANSACTION ̲SERIAL ̲NO ̲TYPE;
FORMAT ̲ID: TEP ̲FORMAT ̲ID ̲TYPE;
ITEM ̲1 ̲REF ̲ID: ITEM ̲REF ̲ID ̲TYPE;
EXIT ̲CAUSE: EXIT ̲CAUSE ̲TYPE;
CLASSIFICATION: CLASSIFICATION ̲TYPE;
SPEC ̲HAND ̲CAT: SPEC ̲HAND ̲TYPE;
TRANSACTION ̲START ̲TIME: TIME ̲TYPE;
ITEM ̲2 ̲REF ̲ID: ITEM ̲REF ̲ID ̲TYPE;
MONTH ̲DAY: TIME ̲TYPE;
DECISION ̲CODE: DECISION ̲CODE ̲TYPE
END;
Fig. 6.1.2-5…01…USER LOG
CTS ̲ATOMAL ̲DELETION ̲LOG = RECORD
CHANNEL ̲DESIGNATOR: CHANNEL ̲DESIGNATOR ̲TYPE;
CHANNEL ̲SERIAL ̲NO: CHANNEL ̲SERIAL ̲NO ̲TYPE;
MESSAGE ̲TYPE: MESSAGE ̲TYPE ̲TYPE
ITEM ̲1 ̲REF ̲ID: ITEM ̲REF ̲ID ̲TYPE;
CALLING ̲STATION: STATION ̲ID ̲TYPE
STATION ̲SERIAL ̲NO: STATION ̲SERIAL ̲NO ̲TYPE;
FILING ̲TIME: TIME ̲TYPE;
TERMINAL ̲DESIGNATOR: TERMINAL ̲DESIGNATOR ̲TYPE;
TIME ̲STAMP ̲SEND: TIME ̲TYPE
END;
Fig. 6.1.2-6…01…DELETION LOG
VDU ̲SECURITY ̲LOG = RECORD
TERMINAL ̲DESIGNATOR: TERMINAL ̲DESIGNATOR ̲TYPE;
TRANSACTION ̲SERIAL ̲NO: TRANSACTION ̲SERIAL ̲NO ̲TYPE;
FORMAT ̲ID: TEP ̲FORMAT ̲ID ̲TYPE;
EXIT ̲CAUSE: EXIT ̲CAUSE ̲TYPE;
TRANSACTION ̲START ̲TIME: TIME ̲TYPE;
USER ̲ID: USER ̲ID ̲TYPE
END;
Fig. 6.1.2-7…01…SECURITY LOG
6.1.3 R̲e̲p̲o̲r̲t̲s̲
The following types of reports are attempted by the
system:
- Security Reports
- Warning Reports
- Command Completion Report
- Queue Prints
- Channel Reports
- Deletion Request Report
The reports are specified in this section and for each
report is specified the package that creates it.
6.1.3.1 S̲e̲c̲u̲r̲i̲t̲y̲ ̲R̲e̲p̲o̲r̲t̲s̲
Security reports are those reports specified below.
a) Unsuccessful system integrity check (SSC).
b) Unsuccessful sign-on attempt (SSC).
c) Unsuccessful security interrogation and whether
it was due to time-out or faulty password (SSC).
d) Security warning timed out or invalid entry code
(SSC).
e) Unsuccessful password entry by release officer
during release procedure (TEP).
f) Attempt by the equipment to transmit messages of
classification/special handling category not permitted
on channel (THP).
6.1.3.2 W̲a̲r̲n̲i̲n̲g̲ ̲R̲e̲p̲o̲r̲t̲s̲
Warning reports are those reports specified below.
a) Table, queue, or file capacity exceeds a preset
threshold which may result in loss of information
for
1) message storage file (SFM)
2) log (LOG)
3) outstanding report file (TEP)
4) channel queues (CSF)
b) Preemption on external channels, which requires
supervisory action for retransmission of preempted
messages from external channel (THP).
c) Report when 100 characters have been received on
channel after EOM but without VZCZC detected (THP).
d) Halted messages when transmission to CAMPS of a
message is interrupted for more than 5/30 seconds
on highspeed/lowspeed channels (THP).
e) More than 50 identical consecutive characters received
over a channel except for data messages identified
by format line 4 (THP).
f) Report that a service message has been sent indicating
50 identical characters (THP).
g) Report that no receipt message has been received
within required time (Flash acknowledge) (THP).
h) No channel found available for transmission (THP).
i) Report that mounting of off-line storage media
is required for retrieval (SAR).
j) Report that limit of retransmission is exceeded
(THP).
6.1.3.3…02…C̲o̲m̲m̲a̲n̲d̲ ̲C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲ ̲R̲e̲p̲o̲r̲t̲
a) Command completion reports are those reports specified
below.
1) Termination of processing of supervisor command
(TEP).
6.1.3.4…02…Q̲u̲e̲u̲e̲ ̲P̲r̲i̲n̲t̲s̲
A Queue Print shall be generated on supervisor request.
The report shall contain the following information:
- for each internal delivery channel (including release
position and supervisor and supervisor assistant
positions): Total queue length of incoming messages/transactions.
- for each external outgoing channel: Total queue
length for outgoing messages.
6.1.3.5…02…C̲h̲a̲n̲n̲e̲l̲ ̲R̲e̲p̲o̲r̲t̲s̲
Channel reports are those reports specified below.
a) Discontinuity of incoming message traffic as detected
from the improper serial number sequence (THP).
b) Missing transmission serial number of incoming
traffic from external stations (THP).
c) No service messages received within the period
starting at 23,45 and ending 00,15 hours on channels
as specified by the supervisor (THP).
d) A message has been prematurely terminated. This
report is generated for messages, where the supervisor
is responsible for requesting retransmission (THP).
e) On incoming channels a report when incoming messages
exceed a length of 12000 characters, i.e. before
a valid EOTF sequence is detected (THP).
6.1.3.6 D̲e̲l̲e̲t̲i̲o̲n̲ ̲R̲e̲q̲u̲e̲s̲t̲ ̲R̲e̲p̲o̲r̲t̲
Report that a preparation position has made attempt
to delete a message already released (TEP).
6.2 S̲T̲O̲R̲A̲G̲E̲ ̲O̲F̲ ̲M̲E̲S̲S̲A̲G̲E̲S̲/̲C̲O̲M̲M̲E̲N̲T̲S̲,̲ ̲V̲D̲U̲ ̲P̲A̲G̲E̲S̲,̲ ̲E̲T̲C̲.̲
SAR will request MMS for storage when it receives a
set of retrieval keys. Collection of retrieval keys
are described in this section.
6.2.1 R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲K̲e̲y̲s̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
Retrieval Keys collection is performed by the Storage
and Retrieval Package. The packages which are performing
the message processing will send a storage request
to SAR when it is appropriate. The message request
will be sent to the Incoming Storage Queue. SAR will
then, based on the SAR ̲STORAGE ̲TYPE in the QEL attributes,
identify the format and the Retrieval keys in the format.
6.2.1.1 P̲a̲c̲k̲a̲g̲e̲s̲ ̲C̲o̲n̲t̲r̲i̲b̲u̲t̲i̲n̲g̲ ̲w̲i̲t̲h̲ ̲R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲K̲e̲y̲s̲
Packages contributing with retrieval key information
for SAR are:
Traffic Handling, THP
Message Distribution, MDP
Terminal Package, TEP
Log Package, LOG
6.2.1.1.1 T̲H̲P̲ ̲C̲o̲n̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
THP delivers a message view related to each of the
following types:
Type 1: Incoming message after analysis.
Type 6: Released message
Type 7: Released message after assignment of transmission
type.
6.2.1.1.2 M̲D̲P̲ ̲C̲o̲n̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
MDP delivers a message view related to each of the
following types:
Type 2: Incoming message after selection of nominal
distribution list.
Type 9: Released Local distributed messages.
6.2.1.1.3 T̲E̲P̲ ̲C̲o̲n̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
TEP delivers a message view related to each of the
following types:
Type 3: First draft.
Type 4: Comments.
Type 5: Release nofification.
6.2.1.1.4 L̲o̲g̲ ̲C̲o̲n̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
Log delivers a record upon completion of 10 minutes
log records.
Type 8: Log CIFs.
6.2.1.2 W̲h̲e̲n̲ ̲T̲o̲ ̲C̲o̲l̲l̲e̲c̲t̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲K̲e̲y̲s̲
This paragraph includes a description of when storage
keys are collected for each of the previously mentioned
storage subjects. Fig. 6.2.1.2-1, 6.2.1.2-2, 6.2.1.2-3
show which Message types are to be stored by which
packages.
6.2.1.2.1 I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲ ̲A̲f̲t̲e̲r̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
This is performed by THP after a possible correction
by message service. Stored upon successful pass of
analysis. The view stored is the incoming message
retrievable by the supervisor.
6.2.1.2.2 I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲A̲f̲t̲e̲r̲ ̲S̲e̲l̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲N̲o̲m̲i̲n̲a̲l̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
̲L̲i̲s̲t̲
This is performed by MDP. Stored when distribution
has taken place during the MDP finish distribution
procedure.
6.2.1.2.3 F̲i̲r̲s̲t̲ ̲D̲r̲a̲f̲t̲
Storage of first draft is performed by TEP. Storage
takes place when draft is dispatched for coordination
or sent for release. Deferring of message for later
preparation or appending of a message section from
another message will not cause any storage. These
last two transactions are stored when either of the
first two decisions, coordination or release, are taken.
6.2.1.2.4 C̲o̲m̲m̲e̲n̲t̲
This is performed by TEP when creator sends the comment
for distribution by using the send field on the VDU.
6.2.1.2.5 R̲e̲l̲e̲a̲s̲e̲ ̲N̲o̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Performed by TEP when operator of the release position
presses the ENTER key. Previously, the release decision
has been taken and a possible comment assignment has
been made.
6.2.1.2.6 R̲e̲l̲e̲a̲s̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Stored by THP when a positive release decision has
been given. The message stored is retrievable by supervisor
and user.
6.2.1.2.7 R̲e̲l̲e̲a̲s̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲A̲f̲t̲e̲r̲ ̲A̲s̲s̲i̲g̲n̲m̲e̲n̲t̲ ̲o̲f̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲
̲S̲t̲o̲r̲a̲g̲e̲ ̲K̲e̲y̲s̲
This is performed by THP after transmission and assignment
of transmission storage keys. The stored view is retrievable
by supervisor.
6.2.1.2.8 L̲o̲g̲ ̲C̲I̲F̲
Log performs storage of log CIFs every 10 minutes,
or when log CIF gets full. Only retrievable by Log
itself.
6.2.1.3 W̲h̲a̲t̲ ̲T̲o̲ ̲C̲o̲l̲l̲e̲c̲t̲
The information to be collected, delivered by the previously
mentioned packages, is listed below. Data are delivered
in the form of a message view in which the Retrieval
parameters exist.
6.2.1.3.1 I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲A̲f̲t̲e̲r̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
Refer 5.3.1.1 for parameter information.
6.2.1.3.2 I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲A̲f̲t̲e̲r̲ ̲S̲e̲l̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲N̲o̲m̲i̲n̲a̲l̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
̲L̲i̲s̲t̲
Refer 5.3.2.1 for parameter information.
6.2.1.3.3 F̲i̲r̲s̲t̲ ̲D̲r̲a̲f̲t̲
Refer 5.3.4.10 USER
5.3.4.16 MDCO
5.3.4.17 MSO
5.3.4.18 Supervisor
for parameter information.
6.2.1.3.4 C̲o̲m̲m̲e̲n̲t̲s̲
Refer 5.3.4.9 for parameter information.
6.2.1.3.5 R̲e̲l̲e̲a̲s̲e̲ ̲N̲o̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Refer 5.3.4.11 for parameter information.
6.2.1.3.6 R̲e̲l̲e̲a̲s̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Refer 5.3.1.3 for parameter information.
6.2.1.3.7 R̲e̲l̲e̲a̲s̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲ ̲A̲f̲t̲e̲r̲ ̲A̲s̲s̲i̲g̲n̲m̲e̲n̲t̲ ̲o̲f̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲
̲K̲e̲y̲s̲
Refer 5.3.1.2 for parameter information.
6.2.1.3.8 L̲O̲G̲ ̲I̲t̲e̲m̲s̲
Refer 5.4.7.1 for parameter information.
6.3 C̲O̲M̲M̲O̲N̲ ̲T̲E̲C̲H̲N̲I̲C̲A̲L̲ ̲E̲R̲R̲O̲R̲ ̲H̲A̲N̲D̲L̲I̲N̲G̲
This section covers the following topics:
- error detection
- error types
- error reporting and error actions by
- service system
- user
- COPSY
Two monitor procedures:
- ANALYZE ̲ERROR and
- SEND ̲GARBLE
are identified as the application I/F to handling of
any type of error.
Also, specific commands to be used by the operator/supervisor
during start-up prior to user sign-on are described.
6.3.1 E̲r̲r̲o̲r̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲
Technical errors are detected during:
- System calls
- Instruction execution
- Validity checks
- WDP monitoring
6.3.1.1 S̲y̲s̲t̲e̲m̲ ̲C̲a̲l̲l̲
6.3.1.1.1 E̲r̲r̲o̲r̲ ̲T̲y̲p̲e̲s̲
Errors detected during system calls have one of the
following types:
- SW errors:
- resource error
- security violation
- illegal parameter error
- informative completion code
- HW errors:
- TMS connection error
- FMS connection error (Handling is TBD)
6.3.1.1.2 R̲e̲p̲o̲r̲t̲i̲n̲g̲
The following reporting mechanisms exist:
- return of completion code
- sending of synchronization element to parent synchronization
element (PSE)
- return of completion code and sending of synchronization
element to device status synchronization element
(DSSE).
6.3.1.1.3 E̲r̲r̲o̲r̲ ̲R̲e̲a̲c̲t̲i̲o̲n̲ ̲B̲y̲ ̲T̲h̲e̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲S̲y̲s̲t̲e̲m̲
Three error actions exist:
- return to user
- retire of user
- PU shut down
6.3.1.1.4 E̲r̲r̲o̲r̲ ̲A̲c̲t̲i̲o̲n̲ ̲B̲y̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲S̲y̲s̲t̲e̲m̲ ̲a̲n̲d̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲ ̲i̲n̲
̲R̲e̲l̲a̲t̲i̲o̲n̲ ̲t̲o̲ ̲E̲r̲r̲o̲r̲ ̲T̲y̲p̲e̲
For:
- DAMOS security violation errors and
- CSF/TMP
- resource errors
- security violations
- illegal parameter errors
the calling process is automatically retired and a
report is sent to the PSE.
For:
- DAMOS
- resource errors
- illegal parameter errors
- information CCS
and
- CSF/TMP
- informative parameter errors
a CC is returned to the caller.
For some illegal parameter errors (e.g. addressing)
DAMOS retires a user and a report is sent to PSE.
For TMS connection errors, a report is sent to a DSSE
a̲n̲d̲ a completion code is returned to the caller.
6.3.1.1.5 E̲r̲r̲o̲r̲ ̲A̲c̲t̲i̲o̲n̲ ̲b̲y̲ ̲t̲h̲e̲ ̲U̲s̲e̲r̲
Users have to handle the CCs, which are returned during
a system call.
An ANALYZE ̲ERROR procedure (refer section 6.3.6) shall
be invoked if a CC is not zero.
As input parameters to ANALYZE ̲ERROR, the user specifies
a list of CCs, which he wants to react upon.
It is only possible to specify CCs of the following
types:
- informative completion code
- TMS/FMS connection error
i.e. resource and illegal parameter errors are handled
as security violation errors.
A list of the CCs, which a user is allowed to react
upon is defined in CPS/DBD/001, section 4.3. The ANALYZE
̲ERROR will retire a user and report to PSE, if a CC
appears, which a user has not specified in the CC list.
The error handling related to system calls is independent
of the CAMPS mode = AT-RISK OR NORMAL.
6.3.1.1.6 S̲p̲e̲c̲i̲f̲i̲c̲ ̲U̲s̲e̲r̲ ̲R̲e̲a̲c̲t̲i̲o̲n̲s̲
6.3.1.1.6.1 T̲M̲S̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲E̲r̲r̲o̲r̲s̲
U̲s̲e̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
When receiving a TMS connection error except for "paper
low", a subprocess will cancel its current transaction
and await a TEMCO, DEMCO or CEMCO start-user, start-SAD
or start-EXC command.
However, for the TMS connection error "paper low",
a printer subprocess will await a DEMCO restart-print
command.
6.3.1.1.6.2 C̲O̲P̲S̲Y̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲
Refer section 6.3.1.3.
6.3.1.1.6.3 I̲n̲f̲o̲r̲m̲a̲t̲i̲v̲e̲ ̲C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲ ̲C̲o̲d̲e̲ ̲U̲s̲e̲r̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The error reactions to informative completion codes
are user specific and will not be described further.
TYPE
GARBLE ̲PARAMS =
RECORD
ERROR ̲TYPE : GAQ ̲INFO ̲TYPE,
USER ̲ACTION : USER ̲ACTION ̲TYPE,
ERROR ̲INFO : QUEUE ̲ERROR ̲INFO/
INTERNAL ̲ERROR ̲INFO/
TIMEOUT ̲ERROR ̲INFO
END
QUEUE ̲ERROR ̲INFO = EMPTY
TIMEOUT ̲ERROR ̲INFO = QUEUE ̲REFERENCE
Destination Queue
INTERNAL ̲ERROR ̲INFO = RECORD
LOC : INTEGER
Error Location
INFO : ARRAY (1..4) OF
INTEGER
Additional Information
END
TYPE
STANDARD ̲GARBLE ̲OUTPUT =
RECORD
ERROR ̲TYPE : GAQ ̲INFO ̲TYPE
USER ̲ACTION : USER ̲ACTION ̲TYPE
USER ̲CC : COMPLETION ̲CODE
ID : GARBLE ̲ID
END
QUEUE ̲GARBLE ̲OUTPUT =
RECORD
STANDARD ̲PART : STANDARD ̲GARBLE ̲OUTPUT
QUEUE,
ANS ̲QUEUE : SUBQUEUE ̲REFERENCE
x)
ORIG ̲INFO ̲TYPE : BOOLEAN
xx)
END
INTERNAL ̲GARBLE ̲OUTPUT =
RECORD
STANDARD ̲PART : STANDARD ̲GARBLE ̲OUTPUT
LOC : INTEGER
END
x) Specifies answer queue, if the QEL has a function
request.
xx) The original info type of QEL.
TIMEOUT ̲GARBLE ̲OUTPUT =
RECORD
STANDARD ̲PART : STANDARD ̲GARBLE ̲OUTPUT
DEST ̲QUEUE : SUBQUEUE ̲REFERENCE
END
GAQ ̲INFO ̲TYPE = (Q ERROR, INTERNAL, TIMEOUT)
USER ̲ACTION ̲TYPE = (GIVE ̲UP, DUMMY ̲ACTION, CONTINUE)
6.3.1.2 I̲n̲s̲t̲r̲u̲c̲t̲i̲o̲n̲ ̲E̲x̲e̲c̲u̲t̲i̲o̲n̲
Errors resulting from instruction execution imply an
error interrupt.
The error types, error reporting and error reactions
are defined below:
- PU error
A report is inserted in a Kernel data area and
the PU is shut down.
- PU error in non-system software
A report is sent to the parent in PSE and the process
in question is retired.
The actions are performed by DAMOS and give no user
I/F.
6.3.1.3 V̲a̲l̲i̲d̲i̲t̲y̲ ̲C̲h̲e̲c̲k̲s̲
6.3.1.3.1 E̲r̲r̲o̲r̲ ̲T̲y̲p̲e̲s̲
Errors due to validity checks refer to:
1) illegal contents of:
- Q ̲INFO
- Q ̲BUFFER - VIEW
2) internal program logic error
- "otherwise" in case statements
- array limit error
3) process communication error
- timeout for a reply
Type 1 and 3 are external errors.
6.3.1.3.2 E̲r̲r̲o̲r̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲
Validity checks are executed by users.
6.3.1.3.3 R̲e̲p̲o̲r̲t̲i̲n̲g̲
Validity check errors are reported to the garble queue
GAQ and is performed by users via the Queue Monitor
procedure SEND-GARBLE:
Also, garble information is sent to the GAQ via the
SEND ̲GARBLE (refer section 6.3.7).
6.3.1.3.4 E̲r̲r̲o̲r̲ ̲A̲c̲t̲i̲o̲n̲s̲ ̲b̲y̲ ̲S̲E̲N̲D̲ ̲G̲A̲R̲B̲L̲E̲
The SEND ̲GARBLE procedure performs one action depending
on:
- CAMPS mode of operation (refer 6.3.3)
- NORMAL
- AT ̲RISK
- Process type (refer 6.3.4)
- VITAL
- DUMMY
- RETIRABLE
- User specified action (refer 6.3.5)
- GIVE-UP
- DUMMY-ACTION
- CONTINUE
In NORMAL mode SEND ̲GARBLE:
- reports to GAQ
- retires the process (hereby a PSE report is sent
to COPSY)
In AT ̲Risk mode SEND ̲GARBLE
- reports to GAQ
- performs an action as specified overleaf
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Process
Type
User VITAL DUMMY RETIRABLE
Actions
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
GIVE ̲UP RETIRE RETIRE RETIRE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
DUMMY ̲ACTIONS N/A RETURN N/A
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
CONTINUE RETURN RETURN RETURN
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
6.3.1.4 W̲a̲t̲c̲h̲d̲o̲g̲ ̲(̲W̲D̲P̲)̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲
The WDP monitoring gives no user I/F.
6.3.2 C̲O̲P̲S̲Y̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲s̲
This section contains the COPSY handling of:
- PSE report
- GAQ reports
- DSSE reports
- FMS SE reports
- Emergency closedown/switchover
6.3.2.1 P̲S̲E̲ ̲R̲e̲p̲o̲r̲t̲s̲
When receiving a retire report COPSY dumps the retired
process queue environment to a garble spool area on
disk via a queue monitor procedure DUMP ̲PROCESS ̲Q ̲ENVIRONMENT.
Further actions depend on the CAMPS mode of operation.
In NORMAL MODE COPSY sends an error report to the WDP-ROP
and executes an emergency switchover. However prior
to this, the GAQ is emptied.
In AT ̲RISK mode, COPSY reacts as above for VITAL and
DUMMY processes. For RETIRABLE processes, COPSY:
- reports the error
- continues execution
6.3.2.2 C̲O̲P̲S̲Y̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲V̲a̲l̲i̲d̲i̲t̲y̲ ̲C̲h̲e̲c̲k̲ ̲E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲s̲ ̲i̲n̲ ̲G̲A̲Q̲
The GAQ serving process COPSY copies garbled data to
a garble spool area and prints an appropriate error
report.
For error reports containing the USER ̲ACTION = CONTINUE
COPSY updates an error counter, which defines number
of errors related to the process.
The counters are periodically cleared.
When a threshold is exceeded, the process is retired.
CAMPS either continues (AT ̲RISK mode and process type
= RETIRABLE) or performs an emergency closedown/switchover.
The retired process queue environment is dumped as
described in section 6.3.2.1.
6.3.2.3 D̲S̲S̲E̲ ̲R̲e̲p̲o̲r̲t̲s̲
When receiving a TMS DSSE error report (except for
"paper low") COPSY will:
- dismantle the TMS connections
- if terminal: block terminal in terminal profile
- if device: disconnect device in device profile
- if channel: disconnect channel in channel profile
- update the error status in the port table
- print an error report as the WDP ̲ROP
When receiving a paper low DSSE report COPSY will do
nothing but await a paper high DSSE report or a start-SAD
command.
When receiving a paper high DSSE report COPSY will:
- Send a restart-print command to a printer subprocess.
6.3.2.4 F̲M̲S̲ ̲S̲E̲ ̲R̲e̲p̲o̲r̲t̲s̲
For the online mirrored disks any CC will imply an
emergency closedown or switchover. For the offline
disk, COPSY will print an error report and deassign
the disk (if disk error).
6.3.2.5 E̲m̲e̲r̲g̲e̲n̲c̲y̲ ̲C̲l̲o̲s̲e̲d̲o̲w̲n̲/̲S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲
COPSY executes an emergency close-down by:
- sending a WDP ̲ROP error message
- stopping all child processes
- dumping the retired process queue environment
- notifying the WDP
- calling a DAMOS procedure PU ̲SHUT ̲DOWN, which
- generates an error message in the Kernel
- issues a programmed master clear.
6.3.3 C̲A̲M̲P̲S̲ ̲M̲o̲d̲e̲s̲
The system is able to execute in two modes:
- NORMAL
- AT ̲RISK
In normal mode any SW error will imply an emergency
switchover.
In AT ̲RISK mode, the SW action depends on the error
type and the process type.
The process-type is a start-up parameter. The AT RISK/NORMAL
mode setting is performed by the operator.
The operator may determine to set AT ̲RISK mode:
- During load of new software (e.g. patches)
- During a WARM1/3 start-up, when the SB PU has failed
subsequent to a switchover.
For users, the actual setting is available through
QMON.
6.3.4 P̲r̲o̲c̲e̲s̲s̲ ̲T̲y̲p̲e̲s̲
Processes are divided into three types:
1) Vital
2) Dummy
3) Retirable
V̲i̲t̲a̲l̲ ̲P̲r̲o̲c̲e̲s̲s̲
Vital processes cannot be retired or executed in dummy
mode without inhibiting normal processing.
D̲u̲m̲m̲y̲ ̲P̲r̲o̲c̲e̲s̲s̲
Dummy type processes are processes (e.g. log, statistics),
which:
- do not influence message processing
- cannot be retired without changing the behaviour
of other processes.
- can execute in a mode, where no other processing
is performed, but answering requests as if they
are successfully executed (i.e. transparent for
a user).
R̲e̲t̲i̲r̲a̲b̲l̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲
Retirable processes can be retired, without changing
the behaviour of other processes (e.g. processes serving
VDUs or channels).
P̲r̲o̲c̲e̲s̲s̲ ̲T̲y̲p̲e̲s̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
PACKAGE PROCESS VITAL DUMMY RETIRABLE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SSC COPSY X
CMI X
CSF X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
LOG LOG X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
STP STP X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SAR SAR X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
THP ANALYSIS X
CONVERSION X
TRANSPORT(M) X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
TEP SPIP(M) X
MSO ̲MDCO(M) X
VUP (M) X
SUPV (2) X
OAS (1) X
UMAM X
ROP X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
MDP MDP X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
TMP TMP X
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
6.3.5 U̲s̲e̲r̲ ̲S̲p̲e̲c̲i̲f̲i̲e̲d̲ ̲A̲c̲t̲i̲o̲n̲s̲
The GIVE ̲UP action is specified, when the error is
considered vital for the operation of the user e.g.
most internal programming logic errors.
The DUMMY ̲ACTION is specified, when the error is:
- internal, but not in dummy mode code or
- external and not related to execution of the dummy
operation.
The CONTINUE action is specified for most external
errors. For DUMMY type processes refer also above.
6.3.6 A̲n̲a̲l̲y̲z̲e̲ ̲E̲r̲r̲o̲r̲
F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The procedure is used by application processes to analyse
completion codes returned from system calls.
A list of "expected completion codes" is delivered
as a call parameter. The expected codes are those
which can be handled by the application process.
Unexpected completion codes will cause a retire of
the calling process.
The procedure has as many exit points as there are
completion codes in the list of expected codes. The
exit point will be chosen as the relative position
in the list of the actual completion code.
I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
C̲a̲l̲l̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
a) ANALYZE ̲ERROR (CC,N,E1,....,EN): (L1,...,LN)
b) MON(ANALYZE ̲ERROR,N,E1,....,EN, R6, R7): (L1,...,LN)
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R6 CC (kept)
R7 LINK (destr.)
R0, R1, R7, R3, R4, R5 kept
6.3.7 S̲E̲N̲D̲ ̲G̲A̲R̲B̲L̲E̲ ̲P̲R̲O̲C̲E̲D̲U̲R̲E̲S̲
6.3.7.1 S̲e̲n̲d̲ ̲G̲a̲r̲b̲l̲e̲
F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Sends to the Garble Queue. If Error Type is Queue error,
the referred QEL is removed from its present queue
and inserted into Garble Queue. If Error Type is Internal
or Timeout, a QEL is made and sent to Garble Queue.
A unique Garble Id is generated and inserted into QEL
together with Garble Param.
The calling process is retired with the following parameter
codes, refer DAMOS System Specification 4.1.3.6:
- Primary : SEND ̲GARBLE ̲CAUSE
- Secondary : SUBPROCESS
- Tertiary : GARBLE ̲ID
- Resume Allowed: TRUE
If the process is resumed, a normal return is made.
The QEL can not be referenced by caller after Send
Garble. The function has no effect on a possible checkpoint
for a referenced view.
…02…C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) SEND ̲GARBLE ( QEL : QEL ̲REFERENCE,
…02……02……02…PARAMS : GARBLE ̲PARAMS )
…02……02… ( CC : COMPLETION ̲CODE) : ERROR ̲OK
b) MON (CSF,QMON ̲SEND ̲GARBLE, R1, R2, R7) = ERROR
̲OK
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲
R1 pointer to PARAMS…08… (kept)
R2 QEL (destr)
…02…R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲
…02…R7 CC
R0, R3, R4, R5, R6 Destroyed
F̲a̲t̲a̲l̲ ̲E̲r̲r̲o̲r̲s̲
QEL Reference Error
These type definitions are only stated here for readability.
They are defined in CPS/DBD/001 section "CPS.PREFIX.D".
CPS ̲ERROR ̲HAND.
TYPE
GARBLE ̲PARAMS =
…02……02…RECORD
…02……02……02…ERROR ̲TYPE : GAQ ̲INFO ̲TYPE;…02……02……02… USER
̲ACTION
:
USER
̲ACTION
̲TYPE;
ERROR INFO : QUEUE ̲ERROR ̲INFO/
INTERNAL ̲ERROR ̲INFO/
TIMEOUT ̲ERROR ̲INFO
END;
QUEUE ̲ERROR ̲INFO = EMPTY
TIMEOUT ̲ERROR ̲INFO = QUEUE ̲REFERENCE
Destination Queue
INTERNAL ̲ERROR ̲INFO = RECORD
…02……02……02… LOC : INTEGER
Error Location
INFO: ARRAY (1..4) OF INTEGER
Additional Information
END;
TYPE
STANDARD ̲GARBLE ̲OUTPUT =
RECORD
ERROR ̲TYPE : GAQ ̲INFO ̲TYPE
USER ̲ACTION: USER ̲ACTION ̲TYPE
USER ̲CC : COMPLETION ̲CODE
ID : GARBLE ̲ID
END;
QUEUE ̲GARBLE ̲OUTPUT ̲=
RECORD
STANDARD ̲PART : STANDARD ̲GARBLE ̲OUTPUT
QUEUE,
ANS ̲QUEUE : SUBQUEUE ̲REFERENCE
x)
ORIG ̲INFO ̲TYPE : BOOLEAN
xx)
…02……02…END;
INTERNAL ̲GARBLE ̲OUTPUT =
RECORD
STANDARD ̲PART : STANDARD ̲GARBLE ̲OUTPUT
LOC : INTEGER
…02……02…END;
x) Specifies answer queue, if the QEL has a function
request.
xx) The original info type of QEL
TIMEOUT ̲GARBLE ̲OUTPUT =
RECORD
STANDARD ̲PART : STANDARD ̲GARBLE ̲OUTPUT
DEST ̲QUEUE : SUBQUEUE ̲REFERENCE
…02……02…END;
GAQ ̲INFO ̲TYPE = (Q ERROR, INTERNAL, TIMEOUT)
USER ̲ACTION ̲TYPE = (GIVE ̲UP, DUMMY ̲ACTION, COROUTINE)
6.3.7.2 G̲e̲t̲ ̲G̲a̲r̲b̲l̲e̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Requests the Garble Information Contents of a QEL which
has been received from Gable Queue.
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
GET ̲GARBLE ̲INFORMATION (QEL: QEL ̲REFERENCE)
(OUTPUT: QUEUE ̲GARBLE ̲OUTPUT/
INTERNAL ̲GARBLE ̲OUTPUT/
TIMEOUT ̲GARBLE ̲OUTPUT;
CC : COMPLETION CODE)
:
ERROR ̲OK
MON (CSF, QMON ̲GET ̲GARBLE ̲INFORMATION, R1,R2,R7,):ERROR
̲OK
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲
R1 pointer to Garble Output (kept)
R2 QEL (destr)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲
R7 CC
R0, R3, R4, R5, R6 destroyed
F̲a̲t̲a̲l̲ ̲E̲r̲r̲o̲r̲s̲
QEL Reference Error
6.3.7.3 R̲e̲c̲e̲i̲v̲e̲ ̲f̲r̲o̲m̲ ̲G̲a̲r̲b̲l̲e̲ ̲Q̲u̲e̲u̲e̲
This is done using normal Receive calls. The receiving
subprocess must have receive capability to Garble Queue.
QEL Attributes will contain the following, depending
upon error type:
- Queue Error:
The original content of QEL Attribute
- Internal Error:
Information will contain INFO field of INTERNAL
ERROR INFO. The rest of attribute is undefined.
- Timeout Error:
Undefined
The rest of the garble information is obtained by Get
Garble Information.
6.3.7.4 D̲e̲f̲i̲n̲e̲ ̲G̲a̲r̲b̲l̲e̲ ̲Q̲u̲e̲u̲e̲
The Garble Queue is defined as an additional field
in INST ̲QUEUES ̲DATA. It can not be changed.
6.3.7.5 G̲e̲t̲ ̲S̲u̲b̲p̲r̲o̲c̲e̲s̲s̲ ̲Q̲u̲e̲u̲e̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲ (during clean-up)
F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Inspects all QELS and checks, if the specified subprocess
is owner of any of them. If such a QEL is found the
following is done:
-̲ ̲ ̲C̲a̲l̲l̲i̲n̲g̲ ̲s̲u̲b̲p̲r̲o̲c̲e̲s̲s̲ ̲i̲s̲ ̲i̲n̲s̲e̲r̲t̲e̲d̲ ̲a̲s̲ ̲o̲w̲n̲e̲r̲ ̲o̲f̲ ̲t̲h̲e̲ ̲Q̲E̲L̲
- The QEL reference and QEL attributes are delivered.
- The absolute queue reference of the queue containing
the QEL is delivered.
The QEL must then be treated as if calling subprocess
had received it from the queue.
Error return, if specified subprocess is not owner
of any QELS.
T̲h̲e̲ ̲f̲u̲n̲c̲t̲i̲o̲n̲ ̲m̲u̲s̲t̲ ̲b̲e̲ ̲u̲s̲e̲d̲ ̲t̲o̲ ̲c̲l̲e̲a̲n̲ ̲t̲h̲e̲ ̲q̲u̲e̲u̲e̲ ̲e̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
̲o̲f̲ ̲a̲ ̲f̲a̲i̲l̲e̲d̲ ̲p̲r̲o̲c̲e̲s̲s̲.̲
The function is privileged
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
GET ̲SUBPROC ̲QEL (SUBPROCESS : SUBPROCESS ̲INDEX)
(QEL : QEL ̲REFERENCE,
ATTRIBUTES : QEL ̲ATTRIBUTES,
QUEUE : SUBQUEUE ̲REFERENCE)
(CC : COMPLETION ̲CODE)
: ERROR OK;
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R0 SUBPROCESS (desk)
R1 point to ATTRIBUTES (kept)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R2 QEL
R3 QUEUE
R7 CC
C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲ ̲C̲o̲d̲e̲s̲
NO ̲QEL ̲FOUND
F̲a̲t̲a̲l̲ ̲E̲r̲r̲o̲r̲
PRIVILIGE ̲ERROR
SUBPROCESS ̲REFERENCE ̲ERROR
PARAM ̲ADDRESS ̲ERROR
6.3.7.6 C̲O̲P̲S̲Y̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲a̲ ̲F̲a̲i̲l̲e̲d̲ ̲P̲r̲o̲c̲e̲s̲s̲
For a process which:
- has retired itself, or
- must be stopped because other process have discovered
that the process has failed,
the following actions must take place:
1. The DAMOS PMD function Clean Up Process must be
called. This will cause CSF to finish all outstanding
requests.
2. For each subprocess of the process, COPSY must
call Get Subprocess Queue Elements repeatedly until
there are no more QELs owned by the subprocess.
Each received QEL must be disposed of, e.g. by
copying contents of referenced view to garble spool
area.
6.3.7.7 G̲e̲t̲ ̲C̲I̲F̲
F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Inspects all QELs and checks, if the QEL references
a view of CIF with CIFNAME. If such a QEL is found,
the following is done:
- The QEL is claimed for the calling subprocess.
- The View Reference and QEL Attribute are delivered.
- The attribute queue reference of the queue containing
the QEL is delivered.
The QEL must be treated as if calling subprocess had
received it from the queue.
Error return, if no QELs are found.
The function is used to dispose of CIFs after system
start, but before application process are started.
In order to remove a CIF, the function must be called
repeatedly, and each view dismantled, until the completion
code NO ̲QEL ̲FOUND is obtained. Note that only active
CIFs can be removed in this way.
The function is privileged.
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
GET ̲CIF (CIFNAME : CIF ̲ID)
(CIFREF : VIEW ̲REFERENCE,
ATTRIBUTES: QEL ̲ATTRIBUTES,
QUEUE : SUBQUEUE ̲REFERENCE,
CC : COMPLETION ̲CODE) ERROR ̲OK;
R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲v̲e̲n̲t̲i̲o̲n̲s̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R1 points to ATTRIBUTES (kept)
R2 points to CIFNAME
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲
R2 CIFREF
R3 QUEUE
R7 CC
R0, R4, R5, R6 Destroyed
C̲o̲m̲p̲l̲e̲t̲i̲o̲n̲ ̲C̲o̲d̲e̲s̲
NO ̲QEL ̲FOUND
F̲a̲t̲a̲l̲ ̲E̲r̲r̲o̲r̲s̲
PRIVILEGE ̲ERROR
PARAM ̲ADDRESS ̲ERROR
Table specified by SSC by TMP start.
Subproc TMP SYNCEL TMP SEGMENT
SP1 SEn2 SEGn2
SP2 SEn1 SEGn1
SP3 SEn8 SEGn8
SP4 SEn1 SEGn3
SP5 SEn8 SEGn8
SP6 SEn8 SEGn9
SP7 SEn9 SEGn5
. . .
. . .
. . .
. . .
. . .
. . .
. . .
SYNCELS and SEGMENTs are created by SSC before TMP
start.
They are catalogued by DAMOS under the here specified
names.
6.4 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲
Checkpoints are generated for individual CIFs. There
is no relation between checkpoints for two different
CIFs. Only CIFs in Short Term Storage are checkpointed.
A checkpoint for a CIF is a collection of information
fulfilling the following objectives:
a) It shall make it possible to restore all information
about the CIF, its fields and views, which is not
disk resident. This includes disk addressing information
for the CIF fields.
b) It shall contain an "application process data"
section where Message Monitor data about queues
etc. shall be kept.
A checkpoint will not contain data of the CIF, as all
data reside in fields on disk.
The recovery model for MMS is based on the following
assumptions:
1) The processing flow for a CIF consists of a well
defined set of successive steps, where output from
one step serves as input for one or more succeeding
steps.
2) It is possible to record in a checkpoint the CIF
state resulting from a step in such a way that
the CIF may after a system failure be "rolled back"
to the beginning of latest step initiated before
the failure.
A sufficient but not necessary condition for this to
be true is:
3) A processing step will only modify a CIF by appending
to one or more of its fields. In that case the
state prior to the beginning of the step may be
restored by simply resetting field lengths to their
values at the beginning of the step.
A relaxed condition is that updates of any field do
not overwrite any information which is used as input
to a processing step after the point to which the CIF
can be rolled back.
It is the responsibility of application module designers
to identify processing steps and to request MMS checkpointing
of appropriate CIFs at appropriate points in processing
flow.
A checkpoint is requested by a Message Monitor call.
6.4.1 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲M̲e̲c̲h̲a̲n̲i̲s̲m̲
The referencing structure of a CIF is as explained
on figure 6.4.1-1.
A checkpoint for a CIF is essentially a saved picture
of the referencing structure as it was at the time
the checkpoint was generated, together with disk address
information for the CIF.
During each active period for a CIF a sequence of checkpoints
is generated. Each checkpoint replaces the previous
one in the sequence, and at each point in time, the
current checkpoint thus reflects the referencing structure
as it was at the most recent checkpoint generation
time.
A Passive CIF has no Active Handle, and no checkpoints
exist for a Passive CIF.
A checkpoint is generated at the following occasions:
- Save View
A call of this function will unconditionally generate
a checkpoint.
- Dismantle View
If the dismantled QEL is the last one referencing
the Handle and the Handle has been included in
a previous checkpoint, the Handle is deleted and
a checkpoint is generated.
- Lock View
Updates the current checkpoint for the CIF with
the new Handle count of the referenced View.
- Unlock View
If the specified CIF is Active, the current checkpoint
is updated with the new Handle Count.
Each Handle has a Checkpoint Status, which is set to
False when the Handle is created. It is set to True
when a Save View command is issued for a QEL referencing
the Handle.
A checkpoint for a CIF includes all Handles with checkpoint
Status = True, and all views referenced by at least
one of those Handles. This feature makes it possible
for an application to create a view, fill data into
it in a sequence of Write commands, and then save it
by issuing a Save View command. The intermediate states
of the View will thus not be recovered.
Fig. 6.4.1-1…01…CIF AND VIEW REFERENCING
6.4.2 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲ ̲P̲e̲r̲f̲o̲r̲m̲e̲d̲ ̲b̲y̲ ̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲P̲a̲c̲k̲a̲g̲e̲s̲
Fig. 6.2.1 shows the application interfaces with checkpoint
responsibility. The subpackage which has sent an object,
is responsible for the creation of the checkpoint is
created. All the checkpoints shown are disk checkpoints
(level 0 checkpoints).
Checkpoint number 4 is used after presentation of all
messages, comments and release notifications. The
checkpointing is performed on a "presented per terminal"
basis. This checkpoint is created when the transaction
"Delete and present next message" is performed.
Checkpoint number 6. After print of a message on a
printer checkpoint number 6 will be performed.
Checkpoint number 8. Messages from CCIS sent for Release,
rejected or deferred by the releasing officer are checkpointed
as finished.
Checkpoint number 12. When messages are transmitted
a checkpoint meaning "message finish" is sent. Messages
for which an acknowledgement is expected are not checkpointed
until after the reception of the acknowledgement.
In case of a channel failure preventing the message
to be sent, it will be returned to COQ and checkpointed.
Checkpoint number 15. Messages that MDCO decides shall
be stopped are finally checkpointed.
Checkpoint number 16. Messages that MSO decides shall
be stopped are finally checkpointed.
Checkpoint number 18 and 20. After print of a CIF
on the statistics or on the supervisor printer, the
CIF will finally be checkpointed.
Checkpoint number 22. When SAR has finished processing,
a retrieval key request, the associated CIF will finally
be checkpointed.
Checkpoint number 25 is used when a new CIF is created.
The QEL referencing the CIF will be inserted by CSF
in the answer queue where TEP will checkpoint it.
6.4.3 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲ ̲P̲e̲r̲f̲o̲r̲m̲e̲d̲ ̲b̲y̲ ̲t̲h̲e̲ ̲S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲P̲a̲c̲k̲a̲g̲e̲s̲
C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲ ̲p̲e̲r̲f̲o̲r̲m̲e̲d̲ ̲b̲y̲ ̲S̲S̲C̲
The SSC is responsible for checkpointing the time of
day. Periodically, the time of day is transferred
to disk (via TMP).
C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲ ̲p̲e̲r̲f̲o̲r̲m̲e̲d̲ ̲b̲y̲ ̲C̲S̲F̲
CSF makes a disk checkpoint when an application process
calls a DISMANTLE VIEW and it turns out that the view
is about to be deleted because the last referencing
QEL is dismantled.
6.5 S̲T̲A̲R̲T̲-̲U̲P̲ ̲A̲N̲D̲ ̲I̲N̲I̲T̲I̲A̲L̲I̲Z̲A̲T̲I̲O̲N̲
6.5.1 R̲e̲g̲i̲s̲t̲e̲r̲ ̲C̲o̲n̲t̲e̲n̲t̲s̲ ̲f̲o̲r̲ ̲p̲r̲o̲c̲e̲s̲s̲
When a process starts execution the registers have
following contents.
R0-R4 contains start-up information for a child
(refer overleaf).
R7 contains information for the PRE ̲INITIALIZATION
procedure in all processes.
PROCESS R0 R1 R2 R3 R4
T̲Y̲P̲E̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SUPV ̲S START ̲UP ̲ PROCESS ̲ FIRST ̲NO 1 0
ACTIVE ̲ TYPE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲T̲Y̲P̲E̲ ̲D̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
USER ̲S - - USER ̲NO MSO ̲NO MDCO
̲NO
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
ROP ̲S - - FIRST ̲NO NO 0
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
OCR ̲S - - - - -
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
PTR ̲S - - - -
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
PTP ̲S - - - - -
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
̲
NICS ̲
T̲A̲R̲E̲ ̲S̲ ̲ ̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
SCARS ̲
C̲C̲I̲S̲ ̲S̲ ̲ ̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
TRC ̲
P̲T̲O̲P̲ ̲S̲ ̲ ̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
TMP,
C̲M̲I̲,̲ ̲A̲A̲S̲ ̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲-̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲n̲i̲l̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲n̲i̲l̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲n̲i̲l̲ ̲ ̲ ̲ ̲
FIRST ̲NO : first subprocess no. within process
NO : no. of subprocesses within process
USER ̲NO : subprocess no. of a user subprocess
MSO ̲NO : subprocess no. of a MSD subprocess
MDCO ̲NO : subprocess no. of a MDCD subprocess
The MSO subprocesses are placed in USER ̲S processes:
FIRST ̲USER ̲P ̲NO .. FIRST ̲USER ̲P ̲NO + NO ̲OF ̲MSOS-1
The MDCO subprocesses are placed in USER ̲S processes:
FIRST ̲USER ̲R ̲NO .. FIRST ̲USER ̲R ̲NO + NO ̲OF ̲MDCOs
6.5.2 P̲r̲e̲ ̲i̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
Prior to letting a childprocess begin its own execution
a preinitialization module has to be executed. The
PRE ̲INITIALIZATION module shall be called in every
childprocess.
6.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 procedure first maps in the COMON ̲segment. If the
system executes in trace mode (TRACE ̲MODE equal to
TRUE) a trace file for the process is opened.
6.5.2.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) PRE ̲INITIALIZATION
b) PRE ̲INITIALIZATION (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̲
R6
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R0 - R5, R7 kept
6.5.2.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
The module consists of the procedure:
- PRE ̲INITIALIZATION
The module calls the DAMOS procedures:
- MAP ̲IN ̲SEGMENT
- GET ̲ROOT
- LOOK ̲UP
and the CSF procedure:
- INIT ̲TRACE
6.5.2.4 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̲
C̲o̲n̲s̲t̲a̲n̲t̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
COMON ̲SEGM
FMS ̲MOVING
MIR ̲MOVING
TRACE ̲DIR
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
VAR PAGE : LPN
SEGM ̲SIZE : LPN
used as return parameter in the DAMOS call MAP ̲IN ̲SEGMENT
VAR, TRACE ̲FILE ̲NAME : ARRAY (1..b) of BYTE
used to keep the file name of the trace file of the
process
VAR ROOT ̲DIR : FDCB ̲INDEX refer DAMOS
used as printer to the ROOT-directory
VAR TRACE ̲DIR ̲INDEX : FDCB ̲INDEX refer DAMOS
used as printer to the TRACE-directory
VAR CC : INTEGER
used as completion code
VAR PROC ̲ : PROCESS ̲TYPE refer sec.
used to keep the information about the type of process
VAR T ̲FILE : FDCB ̲INDEX
used as printer to trace-file for the process
VAR PROC ̲NO : INTEGER
indicates the number of process within a process type
VAR TRACE ̲FILE ̲NAME ̲TABLE =
ARRAY ( COPSY ̲S..TRC ̲PTOP.S) OF TRACE ̲FILE ̲NAME TYPE
TYPE
TRACE ̲FILE ̲NAME ̲TYPE = ARRAY (1..b) OF BYTE (CHAR)
INIT
TRACE ̲FILE ̲NAME ̲TABLE (COPSY ̲S) = …08…COP (:0:)…08…
- " - (TMP ̲S) = …08…TMP (:0:)…08…
- " - (CMI ̲S) = …08…CMI (:0:)…08…
- " - (CSF ̲S) = …08…CSF (:0:)…08…
- " - (OAS ̲S) = …08…OAS (:0:)…08…
- " - (LOG ̲S) = …08…LOG (:0:)…08…
- " - (STP ̲S) = …08…STP (:0:)…08…
- " - (SAR ̲S) = …08…SAR (:0:)…08…
- " - (MDP ̲S) = …08…MDP (:0:)…08…
- " - (UMAM ̲S) = …08…UMA (:0:)…08…
- " - (SPIP ̲S) = …08…SPI (:0:)…08…
- " - (ACS ̲S) = …08…ACS (:0:)…08…
- " - (AAS ̲S) = …08…AAS (:0:)…08…
- " - (SUPV ̲S) = …08…SUP (:0:)…08…
- " - (USER ̲S) = …08…VUS (:0:)…08…
- " - (MSA ̲S) = …08…MAS (:0:)…08…
- " - (ROP ̲S) = …08…ROP (:0:)…08…
- " - (OCR ̲S) = …08…OCR (:0:)…08…
- " - (PTR ̲S) = …08…PTR (:0:)…08…
- " - (PTP ̲S) = …08…PTP (:0:)…08…
- " - (NICS ̲TARE ̲S) = …08…NIC (:0:)…08…
- " - (SCARS ̲CCIS ̲S) = …08…S ̲C (:0:)…08…
- " - (TRC ̲PTOP ̲S) = …08…TPT (:0:)…08…
- " - (STI ̲S) = …08…STI (:0:)
6.5.2.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
N̲a̲r̲r̲a̲t̲i̲v̲e̲
The COMON-segment is maped in three steps a handle
to the tracefile is found, and the tracefile is initialized.
F̲l̲o̲w̲g̲r̲a̲m̲
See fig. 6.5.25-1
PROCEDURE
PRE ̲INITIALIZATION
BEGIN
SAVE ̲REGISTERS
PROC = R1
PROC ̲NO = R7
CASE MAP ̲IN ̲SEGMENT (COMON ̲SEGM, NIL, READ ̲WRITE
̲ACCESS)
ERROR ? ANALYZE ̲ERROR (CC, 0)
END CASE MAP ̲IN ̲SEGMENT
TRACE ̲MODE EQ FALSE ?
CASE GET ̲ROOT (FMS ̲MOVING, MIR ̲MOVING) (ROOT
̲DIR, CC)
ERROR ? ANALYZE ERROR (CC, 0)
END CASE GET ̲ROOT
CASE LOOK ̲UP (ROOT ̲DIR, TRACE ̲DIR) (TRACE ̲DIR
̲INDEX, CC)
ERROR ? ANALYZE ̲ERROR (CC, 0)
END CASE LOOK ̲UP
TRACE ̲FILE ̲NAME ̲TABLE (PROC) (4..5) = + PROC
̲NO
T ̲FILE = -TRACE ̲FILE ̲NAME (PROC)
CASE LOOK ̲UP (TRACE ̲DIR ̲INDEX, TRACE ̲FILE, T
̲FILE, CC)
ERROR ? ANALYZE ̲ERROR (CC, 0)
END CASE LOOK ̲UP
CASE INIT ̲TRACE CT ̲FILE) (CC, 0)
ERROR ? ANALYZE ̲ERROR (CC, 0)
END CASE INIT ̲TRACE
RESTORE ̲REGISTERS
END PROCEDURE PRE ̲INITIALIZATION
fig. 6.5.2.5-2
6.6 T̲A̲B̲L̲E̲ ̲A̲C̲C̲E̲S̲S̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
This section describes the use of TMP objects. The
figures on the following pages specify whether a subprocess
reads, writes or/and initializes a specific system
parameter or table. Based on these specifications access
rights to the TMP objects are given too.
For system parameters and profiles each entry in a
parameter record is specified, whereas for tables are
specified only the table name.
