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

Designing Programs for the TMF Subsystem
Like any other programming task, the most important part of designing for TMF is planning. Someone
must plan the training, hardware, development, installation, testing, and operation.
Before development can proceed, the designers must be trained in TMF. Eventually, some training
is necessary for everyone involved.
When the designers understand TMF, the project must be planned. Identify the transactions in the
system. Do all transactions need to be protected by TMF? Are the transactions of appropriate size
(number of SEND operations and number of screens involved)?
The entire installation must be scheduled, whether you are converting to TMF, adding a TMF project
on a system that is already using TMF, or creating a new system.
Testing must be planned. Application code should be tested first without TMF, then with TMF.
Operations and development groups must practice recovery procedures.
Daily operation must be planned. Determine the frequency of online dumps and whether the dump
is to tape or disk. Determine how the archival tapes or disks are transported to storage and how
they are retrieved. Have a disaster recovery script. Practice disaster recovery occasionally.
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.
956 Fault-Tolerant Processes