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

At certain points in your program, you code CHECKPOINT statements, which instruct the operating
environment to copy a specific list of one or more of your data elements into the backup process’s
data space. If the primary process fails, the operating environment activates the backup process.
The backup process starts executing at the code location following the last CHECKPOINT statement
executed. At this point, the backup process’s data space contains a copy of the part of the primary
process’s data space that was checkpointed at the time of the last CHECKPOINT statement.
Determining the proper sites and data-element lists for CHECKPOINT statements can be a painstaking
operation. One recommendation is that you checkpoint everything involved in writing a record
just before executing the WRITE statement.
Introduction to TMF
The HP NonStop™ Transaction Management Facility (TMF) relies on the principle of archiving and
backing out transactions. Every transaction has a beginning and an end. If the entire transaction
cannot be completed (due to some single point of failure), any changes made to the database
must be backed out. This means that other processes must be kept from using any of the records
that a transaction has modified until the transaction has been completed.
If you are writing a Pathway server in HP COBOL, and the Pathway application will use TMF, your
design is much simpler than it would be if you used the fault-tolerant facility. All an HP COBOL
server needs to do to be fault tolerant under these conditions is to lock every record it is going to
change before changing the record, and lock any record it reads that affects the course of the
transaction. All other coding for fault tolerance is at the requester level—the SCREEN COBOL
program includes BEGIN TRANSACTION, END TRANSACTION, and ABORT TRANSACTION
statements.
If you want an HP COBOL program that is not a Pathway server to run under TMF, you must include
ENTER statements to call the routines BEGINTRANSACTION, ENDTRANSACTION, and so on.
Choosing the Fault-Tolerant Facility or TMF
If your program is updating unaudited files and you want it to be fault tolerant, you must code it
to use the fault-tolerant facility; otherwise, whether to use the fault-tolerant facility or TMF is primarily
a question of efficiency versus maintenance.
TMF is implemented with process pairs, so when you use TMF you are using the fault-tolerant facility
indirectly. Using the fault-tolerant facility directly makes the program run more efficiently; however,
maintenance is easier with TMF, because the programming and debugging of the process pairs
has already been done for you.
It is easier to configure the system for TMF and to design, implement, and maintain servers that
use TMF than it is to design, implement, and maintain process pairs. The auditing operation takes
processing time. The audit trails take disk space and require tape operations. But just as Pathway/TS
frees the application programmers from having to produce and support multithreaded requesters,
TMF frees them from having to produce and maintain process pairs.
Fault-Tolerant Facility
The fault-tolerant facility is software that HP provides but that you must explicitly call to cause a
loadfile to be executed as a process pair.
You must include a NONSTOP directive in your compilation before the PROCEDURE DIVISION
header. You must include one STARTBACKUP statement to create the backup process, and a
number of CHECKPOINT statements to transmit restart information to the backup process. Finally,
you must run the program as a named process (to learn how, see Process Names (page 920)).
After you have done these things, the fault-tolerant facility does the remainder of the work to assure
fault-tolerant operation.
Fault-Tolerant Facility 945