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

Fault-Tolerant Processes
HP COBOL Manual for TNS/E Programs—520347-003
32-18
Concepts
Every disk operation that changes the contents of a database protected by TMF is
recorded in an audit trail. The before and after values of the information are both
recorded, and the database is changed. If the transaction does not complete, TMF
backs out the transaction—replaces the changed value with the previous value.
You can specify that some files in a transaction are audited and some are not audited;
however, this practice is risky. If a server updates an unaudited file having alternate
keys, a single-component failure can interrupt a transaction between the updating of
the prime key and alternate keys. In this case, the prime and alternate keys are
inconsistent. If you do not protect such a file with auditing, you must code the server as
a process pair to protect the consistency of the keys.
The TMF subsystem requires audit trails for both transaction backout and roll-forward
recovery. Eventually, the space required for audit trails can exceed available resources.
For this reason, the audit trails must periodically be dumped to tape and their disk
space thereby reclaimed. The system manager can configure TMF to automatically
dump the audit trails.
Even after a transaction is committed and its audit trail is no longer needed for
backout, you might need the audit trail for a roll-forward recovery; therefore, tapes
containing the dumped audit trails should be stored until you are certain that they are
no longer needed.
Online Dump and Roll-Forward Recovery
The TMF subsystem can perform an online dump of the database periodically. The
system manager is responsible for configuring TMF to do this at appropriate intervals.
In the event of a total system failure, the operator directs TMF to restore the database
from dump files. Then the operator directs TMF to conduct a roll-forward recovery to
repeat the transactions that have occurred since the last online dump. A roll-forward
recovery is the action of repeating each transaction that occurred to the database
between the time of the last online dump and the time of the system failure.
Record Locking
As a transaction progresses in TMF, these types of resources must be locked:
•
Records that are changed or inserted into the database
•
Records whose values affect the course of the transaction
•
Keys of deleted records
If you are going to rewrite a record in an audited file, you must first lock it when you
read it. The TMF subsystem automatically locks records that are inserted and keys of
records that are deleted.
If a process attempts to rewrite a record in an audited file without that record being
locked, the operation terminates with a file system error 80 (invalid operation attempted
on audited file or non-audited disk volume) and file status code “30” (permanent error).