The DB2 RDBMS is a transaction-based system. All of the work that you perform while using DB2 must occur within a transaction, whether that work is being done through the Acu4GL for DB2 or another application. When you use Acu4GL for DB2, a transaction is implicitly started for you by the database engine itself with the first file I/O operation performed on a file associated with DB2. Because all operations with Acu4GL for DB2 occur within a transaction, any record locked during processing remains locked until either a COMMIT WORK or ROLLBACK WORK is issued by Acu4GL. This action results in behavior similar to the LOCK ON MULTIPLE RECORDS clause in COBOL.
The benefits of this transaction management system are best illustrated by an example. A COBOL application that handles order entry might perform these steps to accept an order:
This series of four file operations is a logical unit. If the program were interrupted and had completed only some of the four file operations, the files would be in an inconsistent state. For example, if the program terminated unexpectedly after it updated the customer record, but before it updated the inventory record, a subsequent run might access non-existent inventory.
The solution to this problem is to provide a method for the programmer to define a set of operations that should either all occur or all not occur. Then, if the program encounters an error or terminates, the files are left in a consistent state.
All file operations that are part of a transaction are logged. Once logged, they can be either committed or rolled back (undone) by the program.
If a program dies, or the system fails, the log file can be used to reconstruct complete transactions, returning all files to a consistent state. Transaction logging gives the ability to: