top - download
⟦21961f254⟧ Wang Wps File
Length: 13214 (0x339e)
Types: Wang Wps File
Notes: FIX/1200/PSP/0098
Names: »4898A «
Derivation
└─⟦c7fef4850⟧ Bits:30006144 8" Wang WCS floppy, CR 0418A
└─ ⟦this⟧ »4898A «
WangText
4898A/ir…02…FIX/1200/PSP/0098
…02…OK/840510…02……02…#
FIKS SYSCHP
PROCEDURE
PSP
…02……02… FIKS
FIKS SYSCHP PROCEDURE PSP
FIX/1200/PSP/0098
Ove Kaastrup
Ole Eskedal
AMC (6), LOL, APE, REV, LU
…0e… FIKS S/W Mgr. 840510
1
ILS Conf. Mgr. 840510…0f…
840510
4898A/ir…02… FIX/1200/PSP/0098
…02… OK/840510…02……02…ii
FIKS SYSCHP PROCEDURE PSP
…02……02… FIKS
840510 All Issue one of Document
…0f…4898A/ir…02… FIX/1200/PSP/0098
…02… OK/840510…02… iii
FIKS RECOVM PROCEDURE PSP
…02……02… FIKS…0e…
…01…T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 SCOPE ........................................
1
1.1 INTRODUCTION ..............................
1
1.2 ABBREVIATIONS .............................
1
2 APPLICABLE DOCUMENTS .........................
2
2.1 SYSTEM SOFTWARE ...........................
2
2.2 FIKS DOCUMENTATION ........................
2
3 MODULE SPECIFICATION .........................
3
3.1 FUNCTIONAL CAPABILITIES ...................
3
3.2 INTERFACE DESCRIPTION .....................
4
3.3 PROCESSING ................................
6
3.3.1 Clean Start ............................
6
3.3.2 Restart ................................
7
3.3.3 The CHECKPOINT Procedure ...............
9
3.4 DATA ORGANIZATION .........................
10
3.5 STORAGE ALLOCATION ........................
10
3.6 LIMITATIONS ...............................
10
3.7 ERROR LOCATIONS ...........................
10
4 QUALITY ASSURANCE ............................
11
5 PREPARATION FOR DELIVERY .....................
11
1 S̲C̲O̲P̲E̲
This document contains an as-built product specification
of the initialization programme SYSCHP (System Checkpoint
Module).
1.1 I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
This document is mainly ment as an aid to persons who
are going to maintain the SYSCHP programme, or to persons
who wants a detailed insight in it. The document gives
an overview of all functions performed by SYSCHP. Further,
it explains the impact of this programme to other parts
of the FIKS system.
SYSCHP exists in a SCC-version and a N/M-version. Both
versions are described in this document. All the functionalities
described in chapter 3.3. apply to the N/M-version,
while only a subset of these apply to the SCC-version.
Chapter 3.3. points out the differences.
1.2 A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
Refer to ref. 3, chapter 1.2
2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲
2.1 S̲Y̲S̲T̲E̲M̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
1) CR80 AMOS KERNEL
Product Specification
CSS/302/PSP/0008
2.2 F̲I̲K̲S̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
2) FIKS SYSTEM PSP
FIX/1000/PSP/0038
3) FIKS DATA INTERFACE REFERENCE MANUAL
FIX/0100/MAN/0004
4) CHECKPOINT SUBSYSTEM PSP
FIX/1100/PSP/0041
5) MES SUBMODULE PSP
FIX/1351/PSP/0060
6) FIKS FILE GENERATORS PSP
FIX/1200/PSP/0042
7) RDF ̲INIT PROCEDURE PSP
FIX/1200/PSP/0082
3 M̲O̲D̲U̲L̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
SYSCHP is a programme which only runs in the initialization
phase of a N/M or SCC. When it has finished its processing,
it is removed and not used again. The programme is
run in both cold-starts (without use of checkpoint)
and restarts (with use of checkpoints) of a system.
However, the functions performed in the two cases are
very different:
The functions performed in a cold-start are not performed
in a restart (and vise versa). In the SCC version,
which only contains a subset of the N/M version functions,
no processing is done in case of a restart. (The process
terminates itself immediately, when it discovers that
it is a restart). It should therefore be ommited in
the command files on the SCC concerning restarts.
3.1 F̲U̲N̲C̲T̲I̲O̲N̲A̲L̲ ̲C̲A̲P̲A̲B̲I̲L̲I̲T̲I̲E̲S̲
The main functions of this programme can be divided
in 2 parts, depending on the status of the system:
CLEAN START: All checkpointed MTCB's and queue
elements are deleted.
All checkpointed RDF - and TCB updates
performed on the local N/M are deleted.
(Not applicable to the SCC-version).
PDBTAB checkpoints are retrieved
(Message checkpoints for the terminal
processes) and all Message ID's
are inserted in critical region
PDBTAB. (This is done so that the
sequential numbering of message
ID's can continue - also after a
coldstart). (Not applicable to the
SCC-version.
RESTART: (Not applicable to the SCC-version)
- RDF checkpoints are retrieved.
(The Incore RDF area is replaced
by the checkpointed RDF-data,
meaning that updates performed
on the local N/M before the closedown
of the system, are reestablished.
- TCB (Terminal control blocks)
checkpoints are retrieved. (Checkpointed
TCB's are inserted in the critical
region XTCBCR). This means, that
the status of all terminals (logged
in, logged off, blocked, etc.)
are as before, the system was
closed down.
- PDBTAB checkpoints (made by terminal
processes and concerning messages
in preparation) are retrieved.
(Checkpointed PDBTAB records are
inserted in the critical region
PDBTAB). This means that the status
of not yet released messages are
the same as before the closedown.
3.2 I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
Figure 3.2 shows the interfaces of the SYSCHP module.
- Communication with the CHECKP process (ref. 4)
is performed by means of AMOS system messages and
answers. (ref. 1).
- The critical regions CONFIG and PDBTAB are accessed
by means of the critical region monitor procedure
in the KERNEL (ref. 1).
- The CHECKP ̲FILE is accessed by means of communication
with CHECKP process. (see above).
Figure 3.2
Interface Description of SYSCHP
3.3 P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲
The main processing in SYSCHP takes place in the main
module. Communication with the CHECKP process takes
place in the procedure CHECKPOINT (ref. chapt 3.3.3).
When the process is started, the critical region CONFIG
is accessed and the flag, indicating whether the system
has the status CLEANSTART or RESTART, is read. Further
the parameter describing the number of MTCB's in the
system is read from CONFIG. The remaining functions
performed by SYSCHP are different for the two kinds
of status: The functions performed in the CLEANSTART
situation are described in 3.3.1 and the functions
performed in the RESTART situation in 3.3.2.
3.3.1 C̲l̲e̲a̲n̲s̲t̲a̲r̲t̲
a) C̲l̲e̲a̲r̲ ̲M̲T̲C̲B̲ ̲c̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲
All MTCB-checkpoints performed before the system
was closed down are deleted. All the MTCB checkpoint
records in the CHECKP ̲FILE (ref. 4, chapter 3.3.3.2
are reset by making subsequent calls of the CHECKPOINT
procedure, which tells the CHECKP process to write
an empty buffer into the area.
When finished, all MTCB checkpoint records in CHECKP
̲FILE will be empty. This also tells the CHECKP
process, that these records are not occupied, and
can be used for future MTCB checkpoints.
b) S̲t̲o̲r̲e̲ ̲R̲D̲F̲-̲c̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲ (only available in
N/M-version)
An empty buffer is checkpointed by call of CHECKPOINT,
meaning, that the entire checkpointed RDF - area
is reset. All updates performed on the N/M before
the closedown are lost.
c) S̲t̲o̲r̲e̲ ̲T̲C̲B̲-̲c̲h̲e̲c̲k̲p̲o̲i̲n̲t̲. (Only available in
N/M-version)
An empty buffer is checkpointed by call of CHECKPOINT,
meaning, that the entire TCB-checkpoint area is
reset. All updates performed on the N/M before
the closedown are lost, meaning that all terminals
will have the status logged off, regardless of
which status they had before closedown.
d) R̲e̲t̲r̲i̲e̲v̲e̲ ̲P̲D̲B̲T̲A̲B̲ ̲c̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲ (Only available
in
N/M-version)
These checkpoints are used by the terminal processes,
for narrative messages, which have not yet been
released. (ref. 5). The purpose of this section
is not to reestablish this situation, but only
to retrieve the message ID's for each terminal,
so that the numbering of prepared messages from
each terminal can continue. (If the last message
released from terminal KMA before system closedown
was KMA 340, then the first message prepared on
this terminal after a cleanstart will be KMA 341,
etc.).
The whole PDBTAB area is retrieved from the CHECKP
̲
FILE, the message ID's are extracted from each
terminal record and inserted in an empty buffer
at the same offset. The buffer is then stored in
the CHECKP ̲FILE.
3.3.2 R̲E̲S̲T̲A̲R̲T̲ (only available in the N/M-version)
a) R̲e̲t̲r̲i̲e̲v̲e̲ ̲R̲D̲F̲-̲c̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲
The RDF checkpoint area is retrieved and copied
into the incore RDF-area. Before this process is
run, another initialization programme - RDF ̲INIT
- is run. This programme copied a part of the RDF
file (containing data local to this N/M) into the
memory. This memory area is now overwritten by
this checkpoint retrieval. All updates performed
on the local RDF data (local to the N/M) before
the closedown are now still valid.
b) R̲e̲t̲r̲i̲e̲v̲e̲ ̲T̲C̲B̲ ̲c̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲
Each time a status of one of the terminals is changed,
a checkpoint containing the new status is performed.
All these checkpoints are read from CHECKP ̲FILE
to the critical region XTCBCR by call of the procedure
CHECKPOINT. The status of all terminals will now
be the same as before closedown.
c) R̲e̲t̲r̲i̲e̲v̲e̲ ̲P̲D̲B̲T̲A̲B̲ ̲c̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲
Information about messages which are not released
are kept in the critical region PDBTAB. One record
exists for each terminal, which can have up to
10 messages in preparation at a time. Each time
a new message is created or the status of an existing
message is changed, a checkpoint is made by the
terminal process. All these checkpoints are by
SYSCHP retrieved from the CHECKP ̲FILE and copied
into the XTCBCR critical region by call of the
CHECKPOINT procedure.
The status of all messages in preparation are now
the same as before closedown.
Information about how much of the contents of a
message in preparation is available after a closedown,
may be found in ref. 5.
3.3.3 T̲h̲e̲ ̲C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲p̲r̲o̲c̲e̲d̲u̲r̲e̲
The purpose of this procedure is to communicate with
the CHECKP process.
An AMOS system message (ref. 1) is sent to the CHECKP
process. The contents of the message buffer (which
holds checkpoint information) are set up before CHECKPOINT
is called.
An AMOS system ANSWER is awaited. (The CHECKP process
is supposed to send this answer when the checkpoint
has been made). When the answer is received (the procedure
will wait for it until it arrives), the last word in
the message buffer is inspected. This word holds the
completion code, and if it differs from OK, the process
is terminated by call of MON (TERMINATE).
Otherwise the procedure is exited.
3.4 D̲A̲T̲A̲ ̲O̲R̲G̲A̲N̲I̲Z̲A̲T̲I̲O̲N̲
The following external data structures, defined outside
this document must be known:
Critical region CONFIG (ref. 6)
Critical region PDBTAB (ref. 6 and 5)
Critical region XTCBCR (ref. 6 and 5)
Incore RDF area (ref. 6 and 7)
CHECKP ̲FILE (ref. 6 and 4
I̲n̲t̲e̲r̲n̲a̲l̲ ̲d̲a̲t̲a̲ ̲s̲t̲r̲u̲c̲t̲u̲r̲e̲s̲:
Please refer to source listings.
3.5 S̲T̲O̲R̲A̲G̲E̲ ̲A̲L̲L̲O̲C̲A̲T̲I̲O̲N̲S̲
Please refer to linker printout listings.
3.6 L̲I̲M̲I̲T̲A̲T̲I̲O̲N̲S̲
- Before SYSCHP is run, the critical regions CONFIG,
XTCBCR and PDBTAB must be loaded.
- Before SYSCHP is run, the initialization programme
RDF ̲INIT must have been run.
- The CHECKP process must be running, when SYSCHP
is loaded.
3.7 E̲R̲R̲O̲R̲ ̲L̲O̲C̲A̲T̲I̲O̲N̲S̲
L̲a̲b̲e̲l̲: R̲a̲i̲s̲e̲d̲ ̲b̲y̲ ̲c̲a̲l̲l̲ ̲o̲f̲:
1 MON (REGION, RCOPYN) (CONFIG)
2 MON (REGION, RCOPYN) (CONFIG)
7 Procedure CHECKPOINT in case of a timeout or
illegal answer from the CHECKP process
11 MON (REGION, RENTER) (PDBTAB)
12 MON (REGION, RPUT) (PDBTAB)
13 MON (REGION, RLEAVE) (PDBTAB)
111 Orderly termination (RESTART)
0 Orderly termination (Cleanstart)
4 Q̲U̲A̲L̲I̲T̲Y̲ ̲A̲S̲S̲U̲R̲A̲N̲C̲E̲
N/A
5 P̲R̲E̲P̲A̲R̲A̲T̲I̲O̲N̲ ̲F̲O̲R̲ ̲D̲E̲L̲I̲V̲E̲R̲Y̲
A constant in the file NM.SCC.SWITCH determines, whether
a N/M-version or a SCC version shall be generated.
Edit this constant to the correct value
(SCC = TRUE OR FALSE), and then follow the instructions
given in the file INFORMATION.
