ILE COBOL Programmer's Guide


Using Commitment Control

Commitment control is a function that allows:

In some applications, it is desirable to synchronize changes to database records. If the program determines the changes are valid, the changes are then permanently made to the database (a COMMIT statement is processed). If the changes are not valid, or if a problem occurs during processing, the changes can be canceled (a ROLLBACK statement is processed). (When a file is cleared after being opened for OUTPUT, processing of a ROLLBACK does not restore cleared records to the file.) Changes made to records in a file that is not under commitment control are always permanent. Such changes are never affected by subsequent COMMIT or ROLLBACK statements.

Each point where a COMMIT or ROLLBACK is successfully processed is a commitment boundary. (If no COMMIT or ROLLBACK has yet been issued in a program, a commitment boundary is created by the first open of any file under commitment control.) The committing or rolling back of changes only affects changes made since the previous commitment boundary.

The synchronizing of changes at commitment boundaries makes restart or recovery procedures after a failure easier. For more information, see Recovery After a Failure.

When commitment control is used for database files, records in those files are subject to one of the following lock levels:

A locked record can only be modified within the same job and through the same physical or logical file.

The lock level also governs whether locked records can be read. With a high lock level (*ALL), you cannot read locked records in a database file. With a low lock level (*CHG), you can read locked records in a database file, provided the file is opened as INPUT in your job, or opened as I-O and READ WITH NO LOCK is used.

Other jobs, where files are not under commitment control, can always read locked records, regardless of the lock level used, provided the files are opened as INPUT. Because it is possible in some cases for other jobs to read locked records, data can be accessed before it is permanently committed to a database. If a ROLLBACK statement is processed after another job has read locked records, the data accessed will not reflect the contents of the database.

Figure 99 shows record locking considerations for files with and without commitment control.

Figure 99. Record Locking Considerations with and without Commitment Control

illustration of record locking

Note:
Update operations include a START, READ, REWRITE, or DELETE operation for the
same file (regardless of whether it is successful or unsuccessful), and
closing the file. A WRITE operation is not considered an update
operation; therefore, no lock will be set or released as the result of a
WRITE operation.

A file under commitment control can be closed or opened without affecting the status of changes made since the last commitment boundary. A COMMIT must still be issued to make the changes permanent, or a ROLLBACK issued to cancel the changes. A COMMIT statement, when processed, leaves files in the same open or closed state as before processing.

If you have Version 2 Release 3 Modification 0 or earlier of the OS/400 licensed program, all files opened under the same commitment definition within a job must be journaled to the same journal. If you have Version 3 Release 1 or later, this restriction no longer applies in most situations. For more information about journal management and its related functions, and for more information about commitment control, refer to the Backup and Recovery manual.

Commitment control must also be specified outside ILE COBOL through the OS/400 control language (CL). The Start Commitment Control (STRCMTCTL) command establishes the capability for commitment control and sets the level of record locking at the high level (*ALL), the cursor stability level (*CS), or the low level (*CHG).

When commitment control is started by using the STRCMTCTL command, the system creates a commitment definition. Each commitment definition is known only to the job or the activation group within the job that issued the STRCMTCTL command, depending on the commitment control scoping. The commitment definition contains information pertaining to the resources being changed under commitment control within that job or activation group within the job. The commitment control information in the commitment definition is maintained by the system as the commitment resources change.

The STRCMTCTL command does not automatically initiate commitment control for a file. That file must also be specified in the COMMITMENT CONTROL clause of the I-O-CONTROL paragraph within the ILE COBOL program. The commitment control environment is normally ended by using the End Commitment Control (ENDCMTCTL) command. This causes any uncommitted changes for database files under commitment control to be canceled. (An implicit ROLLBACK is processed.) For more information on the STRCMTCTL and ENDCMTCTL commands, see the CL and APIs section of the Programming category in the iSeries 400 Information Center at this Web site -http://publib.boulder.ibm.com/pubs/html/as400/infocenter.htm.

For more information about commitment control, see the Backup and Recovery manual.

Note:
The ability to prevent reading of uncommitted data that has been changed is a function of commitment control and is only available if you are running under commitment control. Normal (noncommitted) database support is not changed by the commitment control extension, and allows reading of locked records when a file that is opened only for input is read. Try to use files consistently. Typically, files should always be run under commitment control or never be run under commitment control.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]