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

On NonStop systems, under DP2 (Disk Process 2), all disks permit TMF auditing. To instruct TMF
to audit a file, use the attribute AUDITED, which you set with the FUP command SET or ALTER. The
AUDITED attribute is an attribute of the disk file itself; an HP COBOL program is unaware of and
cannot affect this attribute.
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).
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.
TMF 955