Considerations and restrictions for commitment control

The topic talks about miscellaneous considerations and restrictions for commitment control.

Database file considerations

If you specify that a shared file be opened under commitment control, all subsequent uses of that file must be opened under commitment control.
If SEQONLY(*YES) is specified for the file opened for read-only with LCKLVL(*ALL) (either implicitly or by a high-level language program, or explicitly by the Override with Database File (OVRDBF) command), then SEQONLY(*YES) is ignored and SEQONLY(*NO) is used.
Record-level changes made under commitment control are recorded in a journal. These changes can be applied to or removed from the database with the Apply Journaled Changes (APYJRNCHG) command or the Remove Journaled Changes (RMVJRNCHG) command.
Both before-images and after-images of the files are journaled under commitment control. If you specify only to journal the after-images of the files, the system also automatically journals the before-image of the file changes that occurred under commitment control. However, because the before-images are not captured for all changes made to the files, you cannot use the RMVJRNCHG command for these files.

Considerations for object and record-level changes

Object-level and record-level changes made under commitment control using SQL will use the commitment definition that is currently active for the activation group that the requesting program is running in. If neither the job-level nor the activation-group-level commitment definition is active, SQL will start an activation-group-level commitment definition.

One-phase and two-phase commit considerations

While a one-phase remote conversation or connection is established, remote conversations or connections to other locations are not allowed. If a commitment boundary is established and all resources are removed, the location can be changed.
If you are using two-phase commit, you do not need to use the Submit Remote Command (SBMRMTCMD) command to start commitment control or perform any other commitment control operations at the remote locations. The system performs these functions for you.
For a one-phase remote location, the COMMIT and ROLLBACK CL commands will fail if SQL is in the call stack and the remote relational database is not on a system. If SQL is not on the call stack, the COMMIT and ROLLBACK commands will not fail.
For a one-phase remote location, commitment control must be started on the source system before making committable changes to remote resources. The system automatically starts commitment control for distributed database SQL on the source system at connection time if the SQL program is running with the commitment control option other than *NONE. When the first remote resource is placed under commitment control, the system starts commitment control on the target system.

Save consideration

A save operation is prevented if the job performing the save has one or more active commitment definitions with any of the following types of committable changes:

A record change to a file that resides in the library being saved. For logical files, all the related physical files are checked.
Any object-level changes within a library that is being saved.
Any API resource that was added using the Add Commitment Resource (QTNADDCR) API and with the Allow normal save processing field set to the default value of N.

This prevents the save operations from saving to the save media changes that are due to a partial transaction.

Note: If you use the new save with partial transactions feature the object can be saved without ending a commitment definition.

Object locks and record locks prevent pending changes from commitment definitions in other jobs from being saved to the save media. This is true only for API commitment resources if locks are acquired when changes are made to the object or objects associated with the API commitment resource.

Miscellaneous considerations and restrictions

Before upgrading your system to a new release, all pending resynchronizations must either be completed or canceled.
The COMMIT and ROLLBACK values are shown on the WRKACTJOB Function field during a commit or rollback. If the Function remains COMMIT or ROLLBACK for a long time, one of the following events might have occurred:
- A resource failure during the commit or rollback requires resynchronization. Control will not return to the application until the resynchronization completes or is canceled.
- This system voted read-only during the commit. Control will not return to the application until the system that initiated the commit sends data to this system.
- This system voted OK to leave out during the commit. Control will not return to the application until the system that initiated the commit sends data to this system.