top - download
⟦6ac0e1c1f⟧ Wang Wps File
Length: 23677 (0x5c7d)
Types: Wang Wps File
Notes: FIX/1100/PSP/0041
Names: »3311A «
Derivation
└─⟦7680f6628⟧ Bits:30006133 8" Wang WCS floppy, CR 0288A
└─ ⟦this⟧ »3311A «
WangText
…00……00……00……00……00…F…02……00……00…F
F…05……0e……0f……0e……06……0d……08……0d……0d……0d……01……0d… …0d……07……86…1 …02… …02… …02…
…02…FIX/1100/PSP/0041
…02…APE/890607…02……02…#
CHECKPOINT SUBSYSTEM PSP
…02…APE/830127…02…FK 7809
…06…1 …02… …02… …02… …02… …02…
CHECKPOINT SUBSYSTEM PSP
FIX/1100/PSP/0041
AK
FMK
…0e…FMK (5), AK (4)
FIKS Prgrm.Mgr.
…0e…1.1…0f…
890607
REVISION RECORD
REVISION RECORD
REVISION RECORD
REVISION RECORD
REVISION RECORD
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…06…1 …02… …02… …02…
ISSUE DATE PAGES BRIEF
DESCRIPTION
OF
CHANGE
ISSUE DATE PAGES BRIEF
DESCRIPTION
OF
CHANGE
ISSUE DATE PAGES BRIEF
DESCRIPTION
OF
CHANGE
ISSUE DATE PAGES BRIEF
DESCRIPTION
OF
CHANGE
ISSUE DATE PAGES BRIEF
DESCRIPTION
OF
CHANGE
AFFECTED
AFFECTED
AFFECTED
AFFECTED
AFFECTED
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ^ ^
^
1 ^830127 ^ All ^
Original
issue
of
document.
^ ^ ^
1.1 ^890607 ^ DCN 1 ^
Changed
in
accordance
with
Order
no:
12/87
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
^ ^ ^
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 SCOPE .......................................... 0001
1.1 INTRODUCTION ............................... 0001
1.2 ABBREVIATIONS .............................. 0001
2 APPLICABLE DOCUMENTS ........................... 0002
2.1 SYSTEM SOFTWARE ............................ 0002
2.2 FIKS DOCUMENTATION ......................... 0003
3 MODULE SPECIFICATION ........................... 0004
3.1 Functional Capabilities .................... 0004
3.2 Interface Description ...................... 0005
3.3 PROCESSING ................................. 0007
3.3.1 CHECKP Main Flow ....................... 0007
3.3.2 CHECKP Initializing .................... 0010
3.3.3 Processing of Checkpoint ............... 0011
3.3.3.1 General Subtypes ................... 0014
3.3.3.2 MTCB- Checkpoints .................. 0015
3.3.3.3 RDF-Checkpoints .................... 0018
3.3.3.4 TCB and PDBTAB checkpoints ......... 0018
3.3.4 Error Handling ......................... 0019
3.4 Data Organization .......................... 0020
3.5 Storage Allocation ......................... 0021
3.6 Performance Characteristics ................ 0022
3.7 Limitations ................................ 0022
3.8 Error Locations ............................ 0023
3.9 Listings Reference ......................... 0024
4 QUALITY ASSURANCE .............................. 0025
4.1 Qualifications Tests ....................... 0025
4.2 Other Quality Assurance Provisions ......... 0025
5 PREPARATION FOR DELIVERY ....................... 0026
6 NOTES .......................................... 0027
6.1 Module Generation .......................... 0027
6.2 Node/MEDE & SCC - Version .................. 0028
7 APPENDICES ..................................... 0029
1 S̲C̲O̲P̲E̲
This document is the Product Specification for the Checkpoint Process (CHECKP) in the FIKS-System.
1.1 I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
The document is made out after the implementation of CHECKP was completed. The document
is primary meant to be used by those who are going to maintain CHECKP. Therefore the intention
with this document is to describe the function and procedures in the CHECKP-Process in a
general view and to explain the reasons why they are implemented as described. Some procedures,
that are rather simple and can easily be understood by inspection of source listings, are
not described in every detail. Capital letters have been used to emphasize keywords, used
in other documents or in the source listing.
1.2 A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
Refer to FIKS Data Interface Reference, FIX/0100/MAN/0004, sec. 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) CR80 AMOS I/O SYSTEM
Product Specification, CSS/006/PSP/0006
3) CR80 DMA Link Driver,
Product Specification,. CSS/006/PSP/0003
4) CR80 AMOS, FILE MANAGEMENT SYSTEM,
System Product Specification, CSS/920/SPS/0001
5) CR80 AMOS, FMS, Command Controller,
Product Specification, CSS/910/PSP/0046
6) CR80 AMOS, FMS, Disk Cache Manager,
Product Specification, CSS/920/PSP/0047
7) CR80 AMOS FMS, File Manager,
Product Specification, CSS/920/PSP/0048
8) CR80 Disk Driver,
Product Specification, CSS/006/PSP/0005
9) CR80 TDX Driver
Product Specification, CSS//314/PSP/0013
2.2 F̲I̲K̲S̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
10) FIKS System PSP
FIX/1000/PSP/0038
11) FIKS Data Interface Reference
FIX/0100/MAN/0004
12) GET ̲DTG Monitor
FIX/1256/PSP/0049
13) MES Submodule PSP
FIX/1351/PSP/0060
14) MTCB ̲INIT Procedure PSP
FIX/1200/PSP/0067
15) RDF ̲INIT Procedure PSP
FIX/1200/SPS/0082
16) CR80 Minicomputer Handbook
C80/HDBK/0001
17) HSP Subsystem
FIX/1161/PSP/0051
18) FIKS Node/MEDE Performance Analysis
FIX/0000/EWP/0064
19) RECOVM Procedure PSP
FIX/1200/PSP/0084
3 M̲O̲D̲U̲L̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
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 purpose of the CHECKP-Process is on request from FIKS Applications to store/retrieve
checkpoints in/from the CHECKP ̲FILE. Refer to (11) sec. 8.1 + sec. 11.12.
Besides these CHECKP updates the volumes used in the FIKS disk system, Ref (4), to maintain
the consistence of the volumes.
The REAL ̲TIME is checkpointed by CHECKP. This checkpoint is to be used of the FIKS Operational
System, when the FIKS System is RECOVERED or INITIALIZED. Ref. (16).
3.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Interface data: Ref (10)
Refer to Fig. 3.2 - Gerneral View.
S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
1. FMS-System via the IO-System. Ref. (2+4).
2. KERNEL, use of AMOS-message functions and critical region operations. Ref. (1).
F̲I̲K̲S̲ ̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
1. U̲s̲e̲ ̲o̲f̲ ̲F̲I̲K̲S̲-̲M̲o̲n̲i̲t̲o̲r̲s̲
1. GET ̲DTG. Ref (12).
2. U̲s̲e̲ ̲o̲f̲ ̲F̲I̲K̲S̲-̲C̲r̲i̲t̲i̲c̲a̲l̲ ̲R̲e̲g̲i̲o̲n̲s̲
1. CONFIG, Configuration Table Ref. (11), sec. 5.1.
2. XTCBCR, Terminal Control Blocks. Ref. (11), sec 7.2.
3. PDBTAB, PDB-File Table. Ref. (13), -
3. F̲I̲K̲S̲-̲M̲o̲d̲u̲l̲e̲s̲
Every FIKS-Process that performs checkpointing.
4. F̲i̲l̲e̲s̲
1. CHECKP ̲FILE Ref. (11), sec. 11.12.
5. F̲I̲K̲S̲ ̲A̲r̲e̲a̲s̲
1. MTCB-Area Ref. (14)
2. RDF-Area Ref. (15)
FIG. 3.2
CHECKP-INTERFACE DESCRIPTION, GENERAL VIEW…86…W …02… …02… …02… …02…
3.3 P̲R̲O̲C̲E̲S̲S̲I̲N̲G̲
3.3.1 C̲H̲E̲C̲K̲P̲ ̲M̲a̲i̲n̲ ̲F̲l̲o̲w̲
The Main Processing of CHECKP is shown on overview Figure 3.3.1.
CHECKP passes through an initializing phase (Ref. 3.3.2) before the ordinary processing loop
is entered. At a general waiting point, events to initialize processing, is awaited from
AMOS. These are:
D̲E̲L̲A̲Y̲: This indicates that the volumes in the FIKS-Disk-System must be updated.
M̲E̲S̲S̲A̲G̲E̲: This means that some process has requested a checkpoint to be performed. The
processing of this is started. A counter, COUNTER ̲UP DATE is decremented. This
is used later on to determine if 'Update of Volumes' takes place. The parameters,
which confirms the checkpoint, are fetched from the delivered message buffer.
These are interpreted in accordance to the specifications given in Ref (10),
sec. 8.1. If this interface description is not obeyed, then completion code
(PARAMETER ̲ERROR) concerned is inserted in AMOS-answer, which is returned later.
If, as a result of further processsing, it is discovered that data outside the
CR80-memory is referred to, then completion MEMORY ̲ERROR is returned in the answer.
UPDATE ̲OF ̲VOLUMES
…0e……0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f……0f…
This is performed in two cases
1. Runout of delay (MAD ̲DELAY ̲COUNT = 5 seconds).
2. After a certain number (MAX ̲COUNT ̲UPDATE = #10) of checkpoints has been completed.
This will ensure that, when the system either is not busy (runout of delay) or busy (often
checkpointing), then updating of volumes are performed with suitable intervals.
CHECKPOINT ̲OF ̲DTG
…0e……0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f……0f…
In connection with 'Updating of Volumes' the Real Time in binary and ASCII-format is fetched
via the monitor procedure GET ̲DTG, Ref. (12). The binary DTG delivered in seconds is converted
to minutes. If this is one minute greater than the last one read, then the whole DTG-Area
(Ref, (10), sec. 11.12, System Checkpoints) is checkpointed.
Fig. 3.3.1
CHECKP MAIN FLOW - GENERAL VIEW
3.3.2 C̲H̲E̲C̲K̲P̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲i̲n̲g̲
After CHECKP has been started by the ESP-Process, the initializing phase is executed.
1. Parameter to be used when accessing the CR80 - memory is settled - PSW ̲DISABLED, LOCAL
̲ACTION - return, Ref (16).
2. From the critical region CONFIG Parameters to be used when accessing the RDF, MTCB-Areas
is fetched.
3. CHECKP ̲FILE is opened to CHECKP.
3.3.3 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲o̲f̲ ̲C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲
The processing of a checkpoint, i.e. storing or retrieval of data from the CHECKP ̲FILE, depends
upon the type of checkpoint. However a general scheme is used in all cases. This scheme
is illustrated in Fig. 3.3.3.
On the basis of COMMAND in the checkpoint message, FUNCTION, TYPE, SUBTYPE and INDICATOR
is determined. Refer to Ref (11), sec. 8.1 for explanation of these items.
When TYPE is settled, then the AREA in CHECKP ̲FILE to be accessed is also settled and hereafter
the items FILE ̲OFFSET, AREA ̲LENGTH and RECORD ̲LENGTH. The items missing to complete the
determination of the CHECKPOINT are given by the remaining input parameters in the checkpoint
message.
Fig. 3.3.3
ACCESSING OF CHECKP - FILE - SCHEME
When a checkpoint is stored, then a checkpoint record is formed in BUFFER in the CHECKP-Process
by retrieving data item from the data structures in the CR80-memory. The checkpoint-record
is then written into the CHECKP ̲FILE. When a checkpoint is retrieved, then the reverse processing
is done. A checkpoint record is read from CHECKP ̲FILE into BUFFER. From here the data is
distributed to the data structures in the CR80-memory. The detailed processing will depend
upon the individual checkpoints.
3.3.3.1 G̲e̲n̲e̲r̲a̲l̲ ̲S̲u̲b̲t̲y̲p̲e̲s̲
The interpretation of SUBTYPE depends upon TYPE. Some SUBTYPE's are however common for all
types and these are:
CHECKPOINT ̲SINGLE ̲WORD:
…0e……0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f……0f…
One word contained in the message buffer has to be checkpointed. The transfer of this to/from
BUFFER and determination of the parameters needed for read/write in the CHECKP ̲FILE is very
simple.
CHECKPOINT ̲MULTIPLE ̲WORDS:
…0e……0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f……0f…
If this case data has to be transferred from SENDER's process area. The SENDER ̲LOCATION
(i.e. BASE and PAGE) is fetched from the pool of PCB's refer to Ref (1), sec. 3.3.1. These
are accessed directly by using 'Memory Access' - protection i.e. CPU, IO, and Real Time interrupt
disabled in the PSW. Ref. (16). Hereafter the words specified is transferred to/from the
senders data-area under 'Memory Access' - protections and read/write- operation is then executed.
For some TYPE's of checkpointing, only general SUBTYPE's are available for performing checkpoints.
These are:
PAGE ̲NUMBER-checkpoints and
SYSTEM-checkpoints.
3.3.3.2 M̲T̲C̲B̲-̲ ̲C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲
These are the most complex TYPE of checkpoints. Due to this and the 'nature' of MTCB- checkpoints
only storing of these is possible (except when using general SUBTYPE's). A special module
'RECOVM-Process' has been implemented to handle the task of retrieving/recovering the MTCB-checkpoints
Ref (19).
The MTCB-checkpoint record consists of two parts:
MTCB ̲IMAGE
…0e……0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f……0f… - This is an exact copy of the MTCB in memory at the moment of checkpointing.
This is transferred to CHECKP-BUFFER from MTCB ̲DATA-Area using direct memory access routines
. 'Memory Access' - protection.
QUEUE ̲MAP
…0e……0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f……0f… - This information is about which queues the MTCB is placed. It is formed by CHECKP
itself. One of the guidelines when implementing CHECKP has been to minimize the numbers
of file accesses.
Therefore in certain cases it is an advantage to retrieve the last stored QUEUE ̲MAP as a
part in the process of forming a new updated QUEUE ̲MAP.
An overview of the transfer operations involved in the MTCB-checkpoints are given in - Figure
3.3.3.2.
The difference in the MTCB-checkpoints (SUBTYPE,INDICATOR) describes how the checkpoint record
in CHECKP is formed and how much is written into the CHECKP ̲FILE. In table 3.3.3.2 is given
an overview of these records.
TRANSFERENCE AT MTCB - CHECKPOINTING
FIG. 3.3.3.2
TABLE 3.3.3.2
FORMING OF MTCB ̲CHECHPOINT RECORDS
(OVERVIEW)
3.3.3.3 R̲D̲F̲-̲C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲
The whole RDF - area is either stored in or retrieved from the CHECKP ̲FILE. The RDF-area
is transferred to/from the CHECKP ̲BUFFER using direct memory access routines. The parameters
needed to perform this is fetched from the critical region CONFIG in the initializing phase.
3.3.3.4 T̲C̲B̲ ̲a̲n̲d̲ ̲P̲D̲B̲T̲A̲B̲ ̲c̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲
The critical regions XTCBCR and PDBTAB are checkpointed in the same way. The following SUBTYPE's
may be used:
SINGLE ̲RECORD - checkpointing or
WHOLE ̲AREA - checkpointing
The difference between these types concerned is by which part of the critical region is to
be checkpointed.
The checkpoint data is transferred to/from CHECKP ̲BUFFER using critical region procedures,
Ref (1).
3.3.4 E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
No special processing in connection error condition is executed.
A list of all error locations used in the CHECKP-process are given in sec. 3.8.
…02…THIS PAGE IS INTENTIONALLY LEFT BLANK
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 by the
maintainer of CHECKP.
1. System software structures:
-AMOS events, IO-user-data structures, critical regions. Ref (1) + Ref (2).
2. CR80, Architecture
- BASE, PSW, LOCAL ̲ACTION
Ref (16).
3. MTCB Data Structurs.
Ref (14)
4. RDF, Incore Part
Ref (15)
5. TCB, Terminal Control Blocks.
Ref (11), sec. 7.1.
6. PDBTAB, PDB-File Table
Ref (13).
7. CHECKP ̲FILE.
Ref (11), sec 11.12.
3.5 S̲t̲o̲r̲a̲g̲e̲ ̲A̲l̲l̲o̲c̲a̲t̲i̲o̲n̲
The size of the CHECKPOINT - Application is approximately given by (memory claim).
PROGRAM SIZE: 700 words
PROCESS SIZE: 1000 words
The two versions of CHECKP (Node/MEDE,SCC) varies a little in size.
3.6 P̲e̲r̲f̲o̲r̲m̲a̲n̲c̲e̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
The performance of CHECKP-process is mainly concerned with its use of the FMS-system.
On the basis of 'Busy Hour Load' - definition given in Ref (18) the number of checkpointing
to be done in the busy hour has been calculated to:
17000 - 20000 checkpoints/hour
This will on average correspond to a similar number of disk-accesses.
It depends upon the 'Disk Cache' - size Ref (6) and the distribution of checkpoints. An
average disk operation in the volume FIXHEAD where CHECKP ̲FILE is placed, takes 20 ms. Then
the total load originating from CHECKP will be less than:
20000 x 20 ms/hour = 11%
Note that this load is only concerned with the FIXHEAD-volume.
3.7 L̲i̲m̲i̲t̲a̲t̲i̲o̲n̲s̲
There are no vital limitations in the CHECKP-process. The possible limitations must be placed
in the size of CHECKP-BUFFER - not being able to handle one large checkpoint in one operation.
This is not of current interest with the FIKS-System as it is implemented today
3.8 E̲r̲r̲o̲r̲ ̲L̲o̲c̲a̲t̲i̲o̲n̲s̲
LABEL Raised by (call off) Comments
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 MON(IO,GETROOT) FIXHEAD
2 MON(IO,DESCENT) to CHECKP ̲FILE
3 MON(IO,MODIFYBYTES) write checkpoint
4 MON(IO,READBYTES) read checkpoint
5 MON(IO,READBYTES) read old MTCB - checkpoint
6 MON(IO,UPDATE) Update of volumes
7 MON(IO,MODIFYBYTES) checkpoint of DTG
8 MON(IO,MODIFYBYTES) at MTCB - checkpoints
11 MON(REGION,RCOPYN)
12 MON(REGION,RENTER)
13 MON(REGION,RPUTN)
14 MON(REGION,RLEAVE)
21 MON(IDENTIFYSENDER) of checkpoint message
3.9 L̲i̲s̲t̲i̲n̲g̲s̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲
Source listing and linker lists may be obtained from FIXLIB. Ref. to SCCLDD.
4 Q̲U̲A̲L̲I̲T̲Y̲ ̲A̲S̲S̲U̲R̲A̲N̲C̲E̲
4.1 Q̲u̲a̲l̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲ ̲T̲e̲s̲t̲s̲
No specific module test of CHECKP-Process has been performed.
During the test 'Dual N/M Integration' the ability of CHECKP has been tested intensively.
Refer to Test Report for I150 Dual N/M Integration, FIX/1000/TRP/0006.
4.2 O̲t̲h̲e̲r̲ ̲Q̲u̲a̲l̲i̲t̲y̲ ̲A̲s̲s̲u̲r̲a̲n̲c̲e̲ ̲P̲r̲o̲v̲i̲s̲i̲o̲n̲s̲
Correct function of CHECKP is a condition for being able to SWITCHOVER in a Node/MEDE. In
the system test 'SO80 Dual Operation N/M', FIX/0000/TRP/0037, is shown that it is possible.
This proves that CHECKP fulfils its functions.
5 P̲R̲E̲P̲A̲R̲A̲T̲I̲O̲N̲ ̲F̲O̲R̲ ̲D̲E̲L̲I̲V̲E̲R̲Y̲
Perform as stated in file 'INFORMATION' in the last delivery of the CHECKP-directory to FIXLIB.
6 N̲O̲T̲E̲S̲
6.1 M̲o̲d̲u̲l̲e̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲
The CHECKP-Process is compiled as one main module by means of SWELL Compiler and linked by
means of the AMOS Linker. Refer to:
SWELL 80, Reference Manual,
CSS/415/RFM/0002
CR80 AMOS,SWELL Compiler, Users Manual,
CSS/415/USM/0047
CR80 AMOS, Linker, Reference Manual,
CSS/416/RFM/0003
CR80 AMOS, Linker, Users Manual,
CSS/416/USM/0048
To perform the compiliation and linking of the CHECKP do as stated in the INFORMATION-file
in the last, FIXLIB-delivery of CHECKP.
6.2 N̲o̲d̲e̲/̲M̲E̲D̲E̲ ̲&̲ ̲S̲C̲C̲ ̲-̲ ̲V̲e̲r̲s̲i̲o̲n̲
The source code for both CHECKP-versions is contained in the same source - i.e. source updating
must only be done at one place independent of version. The version compliled depends on
the content of the file NM.SCC.SWITCH. This contains only a compiler switch stating the
type of version. In this way one or both versions can be generated automatically.
7 A̲P̲P̲E̲N̲D̲I̲C̲E̲S̲
None
