COBOL Manual for TNS and TNS/R Programs

Fault-Tolerant Processes
HP COBOL Manual for TNS and TNS/R Programs522555-006
32-7
Checkpointing
Topics:
Data Items
Sync Blocks
General Rules
Rules for Servers to Follow With Fault-Tolerant Requesters
Data Items
These are usually file record areas but can be any desired data items in the File
Section or the Working-Storage Section of the Data Division. You can only checkpoint
data items in the Extended-Storage Section if your program runs in the CRE or is a
native process. You must checkpoint any data items that are part of the program’s
state—specifically the disk record that is about to be written, the terminal or tape
record that was just read, and any data that is necessary to resume processing at the
site of the checkpoint statement.
The reason for checkpointing data items is to give the backup process all the
information it needs to reexecute an I-O request if the primary process fails. Usually,
you checkpoint a data item just before writing the data to disk. You can also use data-
item checkpointing to eliminate the need for the backup process to reexecute an I-O
request. An example of this is an entry received from a terminal. You checkpoint the
data item received from a terminal by a READ statement immediately after executing
the READ statement to minimize the possibility that the operator has to reenter data.
Sync Blocks
A sync block contains control information about the current state of a disk file (such as
the current value of the file pointers).
The purpose of checkpointing the sync block is twofold:
To ensure that a write operation is not duplicated when a backup process takes
over from its primary process
To pass the current file pointers’ values to the file system of the backup processor
When a process executes a checkpoint of a sync block, the operating environment
passes the information in the sync block to the file system of the backup processor.
The reason for preventing duplicate operations is illustrated in Figure 32-3. In
Figure 32-3, a primary process completes a sequential write operation (that is, append
to end of file) successfully, but fails before a subsequent checkpoint to its backup
process. On the takeover from the primary process, the backup process reexecutes
the operations just completed by the primary process. If the write operation was
performed as requested, it duplicates the record, but at the new end-of-file location.