Monitor your save-while-active operation

Do the following procedures as they apply if you are using the save-while-active function to eliminate your save-outage time.

Parent topic: Eliminate your save-outage time
Related concepts
The wait time (SAVACTWAIT) parameter

Checking for lock conflicts

  1. During checkpoint processing, look for possible lock conflicts by monitoring the save-while-active job.

    A status of LCKW on the Work Active Jobs (WRKACTJOB) display identifies a lock conflict.

  2. If a lock conflict exists for a particular object, identify the job that holds the conflicting lock with the Work with Object Locks (WRKOBJLCK) command.
  3. Take appropriate steps to have the job release the lock so that the save-while-active job can continue and perform the save for that particular object.
  4. If a save-while-active request does not save a particular objects due to lock conflicts, resolve all lock conflicts.
  5. Issue the entire save-while-active request again. You should not just re-save the objects that had a lock conflict. Otherwise objects you saved in the two save-while-active requests will not be in a consistent state each other. This situation can lead to a complex recovery procedure.

Monitoring save-while-active operations for objects under commitment control

  1. During checkpoint processing, if changes to the objects you are saving are made under commitment control and *NOCMTBDY is not used for the SAVACTWAIT pending record changes value, monitor the QSYSOPR message queue for CPI8365 messages.
    CPI8365 messages indicate that the jobs have commitment definitions that are preventing the save-while-active job from proceeding. The QSYSOPR message queue only receives CPI8365 informational messages if you specify the SAVACTWAIT time to be at least 30 seconds.
    Note: See or information on controlling the amount of time that elapses while waiting for commitment definitions to reach a commitment boundary.
  2. Take the appropriate steps, as outlined in the recovery portion of the CPI8365 message, to bring all commitment definitions for a job to a commitment boundary.
  3. The save-while-active request ends if you cannot reach a commitment boundary for a particular commitment definition.
  4. Depending upon the type of uncommitted changes one of the following happens:
    • The job log receives CPF836C messages.
    • The QSYSOPR message queue receives CPI8367 messages.
    In either case, the messages contain the job names that had commitment definitions that prevented the save-while-active request for the library.