In general, the server cannot preserve application boundaries because they are defined by the application. It is left up to you to provide for any of the appropriate recovery procedures when you use the save-while-active function to eliminate your save-outage time.
This topic discusses some of the considerations for save-while-active recovery procedures. Additional recovery procedures are needed to bring the objects to a consistent state in relationship to each other after the restore operation is completed. You must determine the exact steps that are required for these recovery procedures at the time the objects are being saved. The recovery procedures must be performed after the objects from the save-while-active media are restored, but before the objects are used by any application.
You need to consider these recovery procedures if you are using the save-while-active function to eliminate your save-outage time:
If you specify SAVACT(*SYNCLIB) for the save operation, then all the data is saved with one common checkpoint. If you use commitment control to define all of the application boundaries and wait for transaction boundaries during the save operation, the recovery procedure is a basic restore of your objects.
If you specify SAVACT(*SYSDFN) or SAVACT(*LIB) for the save operation, then the data is saved with multiple checkpoints. If you use commitment control to define all of the application boundaries and wait for transaction boundaries during the save operation, the recovery procedure requires you to apply or remove journaled changes to reach a common application boundary.
If you specify SAVACT(*SYNCLIB) for the save operation, then the data is saved with one common checkpoint. If you use commitment control and specify *NOCMTBDY on the SAVACTWAIT parameter for the save operation, the recovery procedure requires you to apply or remove journaled changes to complete or rollback your partial transactions and reach commit boundaries.
If you specify SAVACT(*SYSDFN) or SAVACT(*LIB) for the save operation, then the data is saved with multiple checkpoints. If you use commitment control and specify *NOCMTBDY on the SAVACTWAIT parameter for the save operation, the recovery procedure requires you to apply or remove journaled changes to complete partial transactions and bring them to a common application boundary.
If all application-dependent objects are journaled but commitment control is not used, then you can apply or remove journaled changes. These commands can bring all of the objects to an application boundary after restoring them from the save-while-active media. However, application boundaries are not recorded in the journal so you will need to determine where the boundaries are on an object by object basis. When the journaled object reaches a checkpoint, the journal receiver gets an additional journal entry in conjunction with the object saved journal entry. The journal entry notes that you used the save-while-active function to save the object and is used by the APYJRNCHG and RMVJRNCHG commands as the location to start the operation when the FROMENT(*LASTSAVE) parameter is used. It is critical that the currently attached journal receiver be saved along with the objects being journaled. If more than one journal is being used to journal the objects, then all attached receivers must be saved. Include the request to save the receiver in the same save request as that for the journaled objects. Or save the receiver in a separate save request after the save of the journaled objects. This save is necessary because the attached journal receiver will contain the entries that may be required by any apply or remove journaled changes operation that is part of the recovery when using the save-while-active media.
If you do not define your application boundaries you will have to do a restore and do a recovery from an abnormal end. If you do not know what procedures are required for recovering an abnormal end, then use the method to Example: Restore libraries after reducing save-outage time.