COBOL Manual for TNS/E Programs (H06.08+, J06.03+)

of performing the operation, the file system returns the recorded completion status of the operation
to the backup process. If, however, the requested operation has not been performed, it is performed
and the completion status is returned to the backup process. The course of action taken by the file
system is completely invisible to the backup process.
The file system can save the completion status of the latest 15 disk-file operations and relate those
completions with up to 15 operations requested by a backup process upon takeover from a failed
primary process. (For $RECEIVE or other processes handled as files, the number of saved completion
status values is 255.) Use the SYNCDEPTH parameter to specify the maximum number of completion
status values that the file system is to save. The SYNCDEPTH value is typically the same as the
maximum number of operations that write to a file without an intervening checkpoint of the file’s
sync block. The default SYNCDEPTH value is 1. In a Pathway application, the SYNCDEPTH value
must be 1.
General Rules
You can checkpoint the entire data area of the program and checkpoint each file after the execution
of each statement in your program, but this places a tremendous burden on the interprocess message
system and degrades the performance of your process and all processes executing on the same
processors as your process pair.
Minimize the number of checkpoints in a processing loop and the amount of data checkpointed
for each CHECKPOINT statement. One approach is to checkpoint only the items necessary to
establish a restart point. Verify that you have captured all necessary data items (you might want
to group them in the Data Division). Also, if you checkpoint the contents of a record area, verify
that the remainder of the data storage is still valid in case of a takeover by the backup process.
When your program performs a series of updates to one or more disk files, you can combine
checkpoints to reduce system overhead. Structure your program so that the series of write operations
necessary to update a file are performed in a group. For each file to be checkpointed in this
manner, the sync depth must equal the maximum number of write operations that occur between
checkpoint operations (CHECKPOINT, OPEN, or CLOSE statements). Then, when a file is about
to be updated by performing that collection of write operations, the file’s sync block and its record
areas must be checkpointed. In any case, ensure the integrity of all data by checkpointing.
Rules for Servers to Follow With Fault-Tolerant Requesters
If a server is handling requests from a requester that is running as a process pair, there is an
important rule for the server to follow for checkpointing between a $RECEIVE READ-WRITE pair
for a nonretryable request. A nonretryable request is a task that must not be automatically reexecuted
if the requester’s backup process takes over. For example, if a failure occurs after a request to
deduct taxes from a paycheck is executed, reexecution would cause double deduction. This
operation must be done only once for each calculation of the taxes; thus, it is a nonretryable
request.
The rule for this case is: Have at least one of the CHECKPOINT statements include the file-name
(from name of the file description entry) of the output file assigned to $RECEIVE—the file-name
with which the write operation is associated.
Using the Fault-Tolerant Facility
To use the fault-tolerant facility, your source program must include a NONSTOP directive and
STARTBACKUP and CHECKPOINT statements and its process must have a name.
NONSTOP Directive
To enable the fault-tolerant facility, you must specify the NONSTOP directive before the Procedure
Division of the first program unit in the source text.
Fault-Tolerant Facility 949