How Save-While-Active on IFS (SAV) Works

Resolving The Problem

When using Save-While-Active (SWA) on a System i to save the IFS data, there are differences compared to the SWA saves of libraries and objects.

There are two options of SWA on the SAV command:

1. SAVACT(*YES)

SAVACT(*YES) will not checkpoint all the objects at the same time. With SAVACT(*YES), the operating system will checkpoint groups of objects and the groups start out at 2000 objects, going up to 10,000 objects per group. However, the checkpoint complete message (CPI3712) will not be sent until after the very last group has reached checkpoint. This will look as though the SWA is taking longer than expected.
As there is no wait time parameter on the SAV command, there is no waiting on files which are locked. If a file is encountered that is locked, it is immediately skipped and the save moves onto the next file.

When the checkpoint is reached for groups during SAVACT(*YES), the locks on those files are lowered from 'share with readers only' to 'share with readers and writers'. This allows the objects to be updated after the checkpoint.

2. SAVACT(*SYNC)

SAVACT(*SYNC) checkpoints all files in the IFS save at the same time.

As there is no wait time parameter on the SAV command, there is no waiting on files which are locked. If a file is encountered that is locked, it is immediately skipped and the save moves onto the next file.

If there is a large number of IFS objects being saved, this can take longer than the SAVACT(*YES) option.

Note: If a media definition is specified for the device parameter (such as with BRMS parallel saves) and SAVACT(*YES) was specified, the SAVACT parameter will be changed to SAVACT(*SYNC) and message CPI3823 will be posted in the joblog indicating the change. This may significantly impact the performance of the IFS/*LINK save.
Message CPI3823 may indicate that SAVACT(*SYNCLIB) was used, however SAVACT(*SYNC) is what was actually used.