Commitment Control

Q1: Where can I find information on commitment control?

A1: A good resource on how commitment control works is the Commitment Control manual, which is located at the following Web site:

https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_75/rzakj/rzakjprintme.htm

Q2: Should called programs and calling programs that are updating or writing to the same file both have commit in the file section for the file?

A2: When a record is written or updated, it is locked for a short period of time. Even if cmtctl is not used, jobA will not be able to update a record that jobB is currently updating. It is not necessary to use cmtctl.

As far as whether a commit should be done by both programs, one program must determine where it is appropriate to commit
the changes based on the logic of the application. As long as both programs are running in the same application group, a commit by one program will commit any pending changes made by the other program. Further details can be found in the Commitment Control manual referenced in A1.

Q3: If a program accesses a file that has been updated in a called program with commit on file but changes have not been committed, will the changes be visible to the calling program?

A3: The answer to this depends upon the level specified in Start Commitment Control (STRCMTCTL). If the calling program is compiled with cmtctl *CHG, it will be able to see uncommitted changes in other jobs. Any other higher level (*CS, *RS, *ALL, *RR) will not be able to see uncommitted changes from other job.

Note: For RPG (and any other native I/O method, for example, non-SQL), there are only three lock levels: *CHG, *CS, and *ALL.

Q4: Are there any concerns with using DBU to change a file within an online environment that has been started with STRCMTCTL? Do I have to do a commit in a CL to apply the changes?

A4: DBU is a third-party product. STRCMTCTL by itself is not enough to put files under commitment control. Commit must also be specified when the file is opened. In RPG, this is done via the file description. In CL, this is done via the OPNDBF COMMIT keyword. So the answer depends on what mechanism DBU uses to open files. If DBU does not open files under commit, then neither COMMIT nor ROLLBACK will have any effect on the changes made by DBU.

Q5: Can commit be done on objects other than files, such as data areas?

A5: We can do commitment control on files, SQL tables, and SQL Collections.

The Integrated File System uses commit to provide robustness for things like moving a file to a different directory and other object level changes. This is done implicitly. Users have no control over this. Changes to the data within an Integrated File System object is not subject to commitment control. You cannot rollback changes to the data within an Integrated File System object.

Data areas are not committable.

Q6: Are files that are defined with commit in the file section locked by the SETLL/SETGT operation code?

A6: SETLL sets the cursor position, which does not lock the record. The read of the record causes a lock if you use a commitment control level of *CS or *ALL. For further information on locking levels, refer to the Commitment Control manual.

Q7: Can multiple writes be done to a file under commitment control before the changes are committed, and will all the writes be reflected in the file?

A7: Yes, the commit block can commit several changes at a time. However, do not let the commit blocks get too big in case of a rollback. Also, during a COMMIT or a ROLLBACK, there are locks that are held, and those locks must be unlocked.

Through the use of the QAQQINI file, you can adjust the number of locks that can be held at one time by using the COMMITMENT_CONTROL_LOCK_LIMIT parameter. You must make the call as to whether you would like to limit the number of locks that can be held at one time. The INI file is a convenient way to prevent a large transaction that results from bad program logic, which is especially useful during development. To use the QAQQINI file option, do the following:

1.	On the operating system command line type the following: CRTDUPOBJ OBJ(QAQQINI) FROMLIB(QSYS) TOLIB(qusrsys) DATA(*YES) Press the Enter key.
2.	Update QUSRSYS/QAQQINI and set QQVAL = 32000, where QQPARM = "COMMITMENT_CONTROL_LOCK_LIMIT".

Note: Jobs hitting the limit will receive message CPF5079.

Q8: Under commitment control, is journaling done at the time of the addition or change to a file or when these changes are committed?

A8: Commitment control cannot be used for an object that is not journaled. We do not implicitly journal an object just because it is opened under commitment control. The OPEN request should fail if commitment control is specified but the file is not journaled. The journal entry is deposited prior to the record change. We ensure that the journal entry makes it to disk before allowing the record change to make it to disk, although we do not guarantee that the journal entry is written to disk until the Commit or Rollback entry is deposited. It is done this way to enhance performance.

A rollback will not remove journal entries. Entries are never removed from journals under any circumstances. For further information on how journaling works, refer to the Journal Management manual at the following Web site:

https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_75/rzaki/rzakiprintthis.htm

Q9: Do many runs of the operation code commit in a program affect performance? What do we need to watch for in programming that can degrade performance within commitment control?

A9: Commitment Control can actually improve performance over plain old journaling, depending on the width of the transaction and the number of active transactions, because record entries are not immediately written to disk. Thus, these record entries can be bundled together, which results in fewer trips to disk. However, the Commit verb causes all the entries deposited thus far to be written to disk and that can thwart the attempts of journal caching, if that option is enabled.

If it is common for your application to update the same records in different transactions, then it is in your best interest to keep the transactions as short and small as possible. Commit is considered a very performance-critical operation by development, so you should not be afraid of issuing many commits.

For further details on performance considerations, refer to the Commitment Control manual.