Commitment control is a way to ensure that a single transaction, which consists of more than one database update, is executed in its entirety or not at all. For example, suppose your Customer Service clerk is entering new sales orders into your Order Entry and Billing software. Each "transaction" is a sales order, which is usually comprised of a header and line items.
If you do not use commitment control, the system may have an inconsistent database if the clerk's job were to end abnormally after starting one order, but before completing the data entry. For example, the clerk may have just completed the header portion. Immediately after your program writes the header to the database, power fails and the system shuts down. Now you have a sales order header in your database that has no line items associated with it. Depending on how the software was designed, your software may not allow you to resume entry or even delete the order.
Under commitment control, on the other hand, all database updates that make up a single transaction are performed at once. Your programs still perform the same write, update, or delete operations on the database files, but they are only queued. When the program encounters a commit operation, however, all queued database operations are carried out at once. Therefore, if power fails somewhere in the middle, no database updates would have taken place because the operations were only in the queue.
You cannot choose to use commitment control, arbitrarily, on any file or group of files. The system requires you to do the following:
The files that are going to be operated upon with commitment control must be journaled, and such journaling must be performed in the same journal. Refer to the previous section about journaling, and note in particular the material about the STRJRNPF command.
You must run the Start Commitment Control (STRCMTCTL) command before you attempt to use commitment control. Your HLL program can then run using commitment control. Files must be identified as committable. In RPG IV, identify the files in the F-specs with a COMMIT keyword.
After your HLL program ends, you must run the End Commitment Control (ENDCMTCTL) command.
Although the actual process is much more complicated, the following description is enough for our purposes. Any program that is running under commitment control queues all database change operations (write, update, delete) for all committable files, and locks the changed records. When the program reaches a COMMIT operation, all queued operations are carried out at once, which releases all changed records.
Each time a program executes the COMMIT operation, the system writes all the database operations that were in the queue, and a boundary entry that marks the COMMIT operation into the journal receiver. As the program continues executing, it runs more database operations which, again, are queued instead of carried out. The next time the program reaches the COMMIT operation, all database operations are carried out at once, recorded in the journal receiver, and the loop continues.
The ROLLBACK operation performs the inverse operation. ROLLBACK (which is spelled ROLBK in RPG IV) clears the queue of database operations that are accumulating before COMMIT is executed, which releases all affected records.
In the sales order example at the beginning of this section, the data entry clerk might be about to finish entering a new sales order when the clerk realizes that an incorrect customer number was entered on the very first display. By this time, the HLL program the clerk is running has queued quite a few write and update operations, but it has not reached the COMMIT operation yet. You can provide a function key to abort the sales order. The HLL program then executes a ROLLBACK, the queue is cleared, and the database is as it was before the sales order entry began.