COBOL Manual for TNS and TNS/R Programs

Fault-Tolerant Processes
HP COBOL Manual for TNS and TNS/R Programs—522555-006
32-19
The TMF Subsystem and Requester Screen
Transactions
The TMF Subsystem and Requester Screen Transactions
Because the server’s TMF protection is governed by the requester, you need to
coordinate the designs of the two. If the terminal user needs to traverse more than one
screen for each transaction, you must consider how to package the transaction.
Transactions that consist of several screens are easy and straightforward to program
but can be expensive. If a transaction spans several screens, it can keep records
locked for long periods; however, if you design for single-screen transactions, you
might have some problems when a series of screens makes up a single conceptual
transaction.
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.