Commitment control with save-while-active

This information applies if you are using commitment control and save-while-active to eliminate your save-outage time. This information applies only if you are not specifiying *NOCMTBDY for handling pending record changes on the SAVACTWAIT parameter.

If an object receives updates under commitment control during the checkpoint processing phase of a save-while-active operation, the server saves the object at a commitment boundary. The server saves all objects that reach a checkpoint together at the same common commitment boundary.

During the save preprocessing phase of a save-while-active request, the server ensures that it saves the objects commitment boundary as follows:

• If the job performing the save-while-active request is not currently at a commitment boundary, the save request ends without saving any objects. This processing is the same for any save request.
• If updates are in progress for any objects in a group that are reaching a checkpoint together, the server delays the checkpoint. The checkpoint resumes when all of the transactions reach a commitment boundary. The server waits the amount of time specified on the second element of SAVACTWAIT parameter for these transactions to reach a commitment boundary. If uncommitted transactions still exist when the specified time expires, the save request ends.
• The server identifies which jobs have commitment definitions that are not currently at a commitment boundary and are delaying the checkpoint processing. The server waits until uncommitted transactions delay checkpoint processing for a group of objects for approximately 30 seconds. The server then sends a CPI8365 message to the QSYSOPR message queue for each job that is delaying the save-while-active request. After you receive these messages, you can then take the appropriate actions to bring all commitment definitions for those jobs to a commitment boundary.
• When no more commitment definitions are delaying the save-while-active job, the save-while-active job completes the checkpoint processing for the objects. After the checkpoint processing ends, the server allows changes for those objects under commitment control.
• If a commitment definition has uncommitted changes, it could possibly delay a save-while-active request. The uncommitted changes could delay the save-while-active request even though the changes are not for any database files. This situation can occur if you are journaling any of the database files to the same journal as the commitment definition is using for unrelated, uncommitted changes and if you specify a value greater than 0 for the second element of the SAVACTWAIT parameter.
• If an application is performing a read-for-update operation but no changes have been made, the application is considered to have started a commit cycle. The server allows a checkpoint to be established in the middle of a commit cycle as long as no changes have been made. Checkpoint processing does not stop if the application is performing only a read-for-update operation.
• The server temporarily delays a job that has all commitment definitions at a commitment boundary when both of the following are true:
  • When it is likely that an application will change an object that is under commitment control
  • When that object is reaching a checkpoint
  The server holds that job until the objects reach a checkpoint, or the checkpoint processing for the object exceeds the time specified on the SAVACTWAIT parameter. During the time the server delays a job at a commitment boundary, the Work Active Job (WRKACTJOB) command displays CMTW as the job status.