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

Fault-Tolerant Processes
HP COBOL Manual for TNS/E Programs—520347-003
32-19
Designing Programs for the TMF Subsystem
If the process executes an UNLOCK operation on a record that was locked and
modified in an audited file, TMF prevents the record from actually being unlocked until
the transaction is completed or aborted. The TMF subsystem automatically unlocks
these locked records at the end of a transaction, whether the process explicitly unlocks
them or not. If there is any chance that the same logic will be run on audited files at
some times and on non-audited files at other times, it is best to specify explicit
unlocking operations.
If you unlock a record in a nonaudited file in TMF or unlock a record that you locked
but did not modify, the unlock operation occurs immediately.
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.