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

• Online Dump and Roll-Forward Recovery
• Record Locking
Transactions in General
A transaction is a multistep operation that affects the consistency of a database by transforming
the database from one consistent state to a new consistent state. A transaction is also a unit of
recovery. During a transaction, the database can be inconsistent. But either the entire transaction
must happen, or none of it must happen.
Each transaction has a unique transaction identifier. The identifier includes information about the
starting time of the transaction.
If your transaction involves more than one file or if the single file it involves is available to other
transactions, you can introduce inconsistency into the database.
Multiple-File Transactions
Suppose your process is maintaining a corporate personnel system in which each department has
its own file of information. You want to move an employee’s record from one file to another. It
does not matter whether the process writes the record in the new file before deleting it from the
old file or the reverse. During the interval between the two events, the database is inconsistent.
The employee record is either absent from the database or present in two places.
Multiple Changes to a Single File
Suppose that the corporate personnel system does not use multiple files, but a single file. If you
want to move an employee’s record from one department’s portion of the file to another department’s
portion of the file, the same problem arises as that with multiple files. If the record is deleted from
one place in the file and written to another place in the file, there is an interval during which the
database is inconsistent.
Defining Transactions
Because you, as the application programmer, are in the best position to define what constitutes a
transaction, TMF gives you the authority to specify the beginning and the end of the transaction.
In a Pathway application, the SCREEN COBOL terminal program uses the BEGIN-TRANSACTION
and END-TRANSACTION statements for this purpose.
In pTAL and HP COBOL programs outside of the Pathway environment, you must call the operating
system routines BEGINTRANSACTION and ENDTRANSACTION explicitly.
If a terminal program determines that a transaction cannot or must not complete, it uses the SCREEN
COBOL ABORT-TRANSACTION statement to instruct TMF to back it out and not retry it. If a process
written in pTAL or HP COBOL needs to abort a transaction, it calls the ABORTTRANSACTION
routine.
If a terminal program determines that a transaction should be aborted and retried as a new
transaction (because of a locking contention problem, for example), it can use the SCREEN COBOL
RESTART-TRANSACTION statement to initiate the operation. The pTAL or HP COBOL process must
explicitly use the ABORTTRANSACTION routine and handle its own restarting.
After TMF is informed of the boundaries of a transaction, it can assure that either the entire
transaction is performed or none of it is performed. TMF does this by using audit trails.
Audit Trails
An audit trail is a set of disk files in which a record is kept of before-images and after-images of
all records changed by each transaction that occurs in a certain file. A file is described as audited
when it has an audit trail. In TMF, every disk file in which records are to be changed can be
audited. If a disk is involved in transactions whose failure could leave the database in an inconsistent
state, that disk file should be audited.
954 Fault-Tolerant Processes