COBOL Manual for TNS and TNS/R Programs

Fault-Tolerant Processes
HP COBOL Manual for TNS and TNS/R Programs—522555-006
32-14
Debugging Programs That Use the Fault-Tolerant
Facility
If your SYNCDEPTH exceeds one, and you open or close a file during checkpoint-
protected operation, you must checkpoint the sync blocks and record areas of all other
files before the next nonretryable operation.
If you need to checkpoint data that is in the Extended-Storage Section, you must
compile your program to run in the CRE.
Debugging Programs That Use the Fault-Tolerant Facility
Debugging a program that uses the fault-tolerant facility requires at least as careful an
analysis as designing the program. This list of suggestions is not exhaustive.
•
Test the program thoroughly as a simple batch job. You might create files of
transactions that the job must successfully process before you try testing the fault-
tolerance mechanisms. You can have the program read the files instead of having
the program read from $RECEIVE.
•
You can compile your program with STARTBACKUP and CHECKPOINT
statements in place, but disable them for batch testing by running the program with
the run-time parameter NONSTOP OFF. With NONSTOP OFF, the program does
not attempt to execute the STARTBACKUP and CHECKPOINT statements. To
establish the run-time parameter, use the TACL command PARAM (or the SMU
routine PUTPARAMTEXT or SMU_Param_PutText_ if you use a COBOL process
to start your batch test programs).
•
When you are convinced that the program works without being fault tolerant, start
testing the fault tolerance. Execute the program as a process pair, and use a
symbolic debugger to set breakpoints at which you stop the primary process. You
can set different breakpoints in the primary and backup processes to determine
whether the backup process takes over properly.
•
When all controlled testing is complete, obtain the use of a dedicated system and
try full integrated testing in which you run the application as a process pair and
stop one of the two processors on which the application is running.
TMF
TMF simplifies the task of maintaining data consistency for distributed databases that
are being updated by several independent processes.
TMF was developed to help solve two problems faced by designers of database
processing applications:
•
What happens if a transaction starts to change a database and fails to complete all
of its changes?
•
How can a database be recovered after a catastrophic, multicomponent system
failure?