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

Fault-Tolerant Processes
HP COBOL Manual for TNS/E Programs—520347-003
32-20
The TMF Subsystem for Batch Jobs
You recover from a failure during the series by adopting a strategy to protect records
by allocating a field to mark the record “in use.” Then other transactions can read the
record but agree not to attempt to change it. This mechanism puts more responsibility
on the designer and the maintenance staff. The “in-use” field identifies the terminal that
is using the record so that, in the event of major failure and recovery, the restored
system can resume properly.
You can also collect information from the database without locking records and pass
the information back to the requester. Then, when the requester makes its final request
to update the database, it can send the server the before and after versions of the
data, and the server can read and lock the records. Then the server can verify that the
records have not been changed and can rewrite the new records, or the server can
respond to the requester with the new information and have the requester ask the
terminal operator what to do with the record in its revised form. This strategy increases
the context that is carried by the requester, which affects performance.
The TMF Subsystem for Batch Jobs
The TMF subsystem is appropriate for any batch job where you cannot afford the time
to rerun it if it fails near its completion. Suppose your system must be available to
process interactive transactions daily from 6 AM to 9 PM, and overnight a 5-hour batch
job updates the database. There are only 9 hours between the suspension and
resumption of interactive work. In that 9 hours, you must dump the database to tape
and then update it. If the update fails, you must reload from the tape and repeat the
update. There is not enough time to do this if the failure occurs a few hours into the
batch update.
In such a batch update, the update cannot be one big transaction. Not only must the
audit trail for each transaction remain on disk until the transaction is complete, but
backing out the incomplete transaction takes about as long as the transaction had
been running at the time of the failure; however, the I-O overhead of making each
batch transaction a TMF transaction might be burdensome. It is best to cluster about
20 to 100 batch transactions as one TMF transaction.
Debugging Programs That Use the TMF Subsystem
There are no debugging tools specific to TMF application debugging. You can use a
symbolic debugger, to set breakpoints in both SCREEN COBOL terminal programs
and in server programs. If the symbolic debugger that you use can accept its
commands from an OBEY command file, you can create a script that interrupts
transactions at various points in the requester and the server and tests the recovery
mechanisms.