This document explains why the checkpoint process may not honor the 'Save active wait time' parameter when there are multiple save operations occurring on the system for the same objects.

The Save-While-Active (SWA) backup starts to save objects immediately after the backup starts even though the process encounters locked objects and has not waited the indicated amount of time specified on the 'Save active wait time' parameter (SAVACTWAIT).

One of the following messages are posted in the joblog immediately after the start of the backup:

CPI3724 - The save-while-active operation has now locked the objects in 0 libraries.
CPF3761 - Cannot use &2 &1 in &3.
CPI3710 - Save-while-active checkpoint processing for library &1 complete.

This scenario will occur if there is another job that is performing a backup on the same objects.

This is working as designed. The object locks obtained by save operations do not conflict with each other, so multiple save operations can each obtain object locks. The additional check for concurrent save operations is immediate so the immediate time-out on the objects is what would be expected if those objects were being saved or restored in another job.

Here are some suggested alternatives to obtain a successful backup: Note: The parameter 'Save active wait time' specifies the amount of time to wait for an object that is in use or to wait for transactions with pending changes to reach a commit boundary before continuing the save operation.

This issue can be encountered when running save-while-active backups with BRMS or with native commands.