Save-while-active backups sometimes end with message CPF377F in the joblog and message CPI8365 or CPI8367 in the message queue.

CPF377F:  Save-while-active request prevented by pending record changes.
Cause . . . . . :   The save-while-active request ended on library &2 because there are commitment definitions on the system with pending record changes.

CPI8365:  Save-while-active request requires commit or rollback for job &6/&5/&4.

CPI8367:  Cannot perform commitment control operation.

Note: If CPF377F recognizes the library as QUSRDIRDB, it can most likely be circumvented by following the instructions in Messages CPF3742, CPF377F, and CPI8365 Received on QUSRDIRDB during Save-While-Active Backup. If CPF377F recognizes another library besides QUSRDIRDB, refer to the description below regarding why a commit may stop a save-while-active backup.

 

Commitment Control and Save-While-Active

Description:
The save-while-active checkpoint waits until all changes are COMPLETED or HELD before saving the objects so that there are no partial transactions.

CPF377F can be logged for the following reasons:

Commitment Control identifies all jobs that have pending changes and then allows all of those changes to complete. If it identifies jobs that have no pending changes, those jobs will be delayed until the save-while-active checkpoint is reached.

If there are API commit or rollback requests (changes), they are HELD because the system is unable to know which objects are being changed. Because the job is held during the request and because a request can be performed only for a single commitment definition at a time, jobs with more than one API commitment definition always prevent a save-while-active backup from completing.

If your save-while-active backups are failing due to pending record changes, then it is probably because there is more than one API commitment definition. Basically, end and prevent the jobs with commitment definitions before the save-while-active backup, or omit the objects and libraries from the save-while-active backup.

If any of the files being saved are journaled and are journaled to the same journal as files under commit control, the save-while-active will wait.

It is possible for a save-while-active request to be delayed if a commitment definition has committed changes even though the uncommitted changes are not for any database file being saved by the Save-While-Active request. This situation can occur if any of the database files are being journaled to the same journal as the commitment definition is using for unrelated, uncommitted changes.

For example, files in LIBA and LIBB are journaled to a journal in LIBC. A save-while-active of LIBA will fail if files in LIBB have open commit definitions.

To find the open commit definitions that are preventing the save-while-active to complete, you should refer to  CPF7024 RC2 - Determining the Open Commit Definition .

 

Detailed Description:
The save-while-active checkpoint processing waits until all committable resources in the save request are at a commitment boundary (with respect to all jobs making committable changes to the objects being saved) prior to actually saving the objects to the save media. This is done so that no partial transactions are saved to the save media by a save-while-active operation.  An open transaction in a user job may delay save-while-active from reaching a checkpoint, which in turn may put other jobs into a "journal save while active wait state."  there should be CPI8365 or CPI836B messages in QSYSOPR or QHST to identify jobs that are delaying a save-while-active checkpoint.

When commitment control is active for any job on the system, the system performs the following during the save-while-active checkpoint processing:

Any job not making committable changes to the objects being saved by the save-while-active operation is not delayed, except for the following cases:

Any job that attempts to add an API commitment resource and all other commitment definitions for the job do not have any pending changes for any objects being saved by the save-while-active operation. In addition, any job with an added API commitment resource is held during a commit or rollback request for the commitment definition with the API commitment resource added. This is because the system does not know which objects are being changed for an API commitment resource. Therefore, for a save-while-active request, the system delays all jobs during the checkpoint processing that have a commitment definition with an API commitment resource. Because the job is held during the commit or rollback request, and because a commit or rollback request can be performed only for a single commitment definition at a time, jobs with more than one commitment definition with API commitment resources added always prevent a save-while-active operation from completing.

Note: This does not apply to API resources that were added using the QTNADDCR API if the Allow normal save processing field has a value of Y.

For all the cases mentioned previously that delay a job due to a save-while-active operation, the job is delayed only if all other commitment definitions for the job do not have any pending changes for any objects being saved by the save-while-active operation. The job is delayed only until the checkpoint processing is completed for the save-while-active operation. The save active wait (SAVACTWAIT) parameter value on the save commands can be used to control the amount of time allowed for jobs to reach, and be delayed at, a commitment boundary.

In the save active wait time help text, it lists the following Elements:

Element 1: Object locks

For each object that is in use, specifies the amount of  
time to wait for the object to become available.  If an  
object remains in use for the specified time, the object  
is not saved.    

Note: Element 1 addresses object locks during save-while-active (not commitment definitions).

Element 2: Pending record changes

If a commit boundary is not reached in the specified    
time, the save operation is ended, unless the value      
*NOCMTBDY is specified.                                  
The system will save objects without requiring            
transactions with pending record changes to reach a      
commit boundary.  Therefore, objects may be saved with    
partial transactions.        

Note: Element 2 includes DML (Data manipulation language) which addresses the changing of the data in the objects. This can be circumvented with the *NOCMTBDY (available at V5R3M0 and above and commonly referred to as rugged save while active). However, if an object is exclusively locked and there is a DML, message CPF32B3 is posted in the joblog and the object will not be saved.

Note: If an object is saved with a partial transaction, message CPI3731 will be logged in the save and/or restore joblog informing that the object was saved with a partial transaction and providing recovery actions.

Element 3: Other pending changes

For each library, specifies the amount of time to wait  
for transactions with other pending changes to reach a    
commit boundary.  Other pending changes include the      
following:

o  Data Definition Language (DDL) object level changes
  for that library.                                    
o  Any API commitment resource that was added without the
  option to allow normal save processing. For more
   information, see the Add Commitment Resource
   (QTNADDCR) API in the APIs topic collection in the
   Programming category in the IBM i Information Center
   at http://www.ibm.com/systems/i/infocenter/ .
                                                                       
If a commit boundary is not reached for a library in the  
specified time, the library is not saved.

Note: Element 3 includes DDL (Data definition language) which addresses the changing of the object itself, such as the object header. If an object is locked and there is a DDL, message CPD8366 is posted in the joblog and the library will not be saved.