Recommended recovery procedures after eliminating save-outage time

If you perform save-while-active operations to eliminate save outage time and you specified *NOCMTBDY for the SAVACTWAIT pending record changes value, you can be left with objects that are saved with partial transactions. It is recommended that you use Backup, Recovery, and Media Services (BRMS) to automate your backup and recovery operations. BRMS automatically applies changes to objects with partial transactions and restores them to a usable state.

The following provides some recommended recovery procedures after restoring from the save-while-active media. The following procedure is a recommendation only. Your recovery procedures may need to be somewhat different depending upon your applications and your particular application dependencies.

The recovery for journaled objects may include Apply Journaled Changes (APYJRNCHG) and Remove Journaled Changes (RMVJRNCHG) operations. The following recommendation uses the APYJRNCHG command exclusively. The APYJRNCHG command is the most common recovery operation that brings journaled objects to application boundaries. However, you can use the RMVJRNCHG command instead of the APYJRNCHG to bring the journaled objects to an application boundary. Use the RMVJRNCHG command if you are removing changes from the journaled object. You can use the RMVJRNCHG command if you are journaling before images for the journaled object.

If you need to use the APYJRNCHG command for the recovery, you must specify a known application boundary for either the ending sequence number (TOENT) parameter or the ending large sequence number (TOENTLRG) parameter but not both. Specify the FROMENTLRG parameter regardless of whether all objects reached a checkpoint together. You must run multiple APYJRNCHG commands if the objects are journaled to different journals.

The following steps give a general recommendation to follow for recovery procedures:

If some of the objects you are restoring are journaled objects, make sure that the necessary journals are on the server.
If all necessary journals are not on the server, restore the journals first. The server automatically restores the journals first if both items below are true:
- The journals are in the same library as the objects you are restoring.
- You used the same save request to save the journals and the objects.
Restore objects from the save-while-active media.
If some of the objects restored are journaled objects, restore any required journal receivers that do not already exist on the server.
1. Start by restoring receivers that contain the start of save journal entries for the journaled objects.
2. Continue restoring receivers until you restore the receiver that contains the journal entry that is the desired application boundary. These receivers need to be online for each of the journals used to journal the restored objects.
If all of the application-dependent objects are journaled, skip to step 9. If only some or none of the application-dependent objects are journaled, go to step 6.
If some application-dependent objects are not journaled objects, and one of the following scenarios is true, go to step 7. Otherwise, go to step, 8.
1. All of the objects are in the same library and are saved using SAVACT(*LIB).
2. All objects in all of the libraries are saved using SAVACT(*SYNCLIB).
You can perform the recovery procedures in Example: Restore libraries after reducing save-outage time. All of the objects reached a checkpoint together and the restored objects are in a consistent state in relationship to each other. However, if you need to bring the objects forward to some defined application boundary, you can only use the APYJRNCHG command for the journaled objects. For objects that are not journaled, you must perform user-defined recovery procedures.
If neither of the scenarios in 6 are true, then the objects are not saved in a consistent state in relationship to each other. Use the APYJRNCHG command to bring the journaled objects forward to some common application boundary. For objects that are not journaled, you must perform user-defined recovery procedures.
If all of the application-dependent objects are journaled, and all of the application-dependent objects are under commitment control, skip to step 11. Otherwise, go to step 10.
If all application-dependent objects are journaled objects but all of the changes made to the objects are not made under commitment control, then you must use APYJRNCHG command to bring all of the objects to an application boundary.
If all of the application-dependent objects are under commitment control and the objects exist in different libraries go to step 12. Otherwise, go to step 13.
If the objects exist in different libraries, then the objects restored are at commitment boundaries. However, not all of the objects will be at the same common commitment boundary. Bring the objects to the same common commitment boundary with the APYJRNCHG command. Specify the CMTBDY(*YES) parameter to bring the objects forward to some common application boundary.
By specifying CMTBDY(*YES), you ensure that the apply operation starts on a commitment boundary. You also ensure that the server applies complete transactions up through the sequence number that you specified to correspond with your application boundary.
If all application-dependent objects are journaled objects that exist in the same library, and the files are only updated under commitment control, the server restores the files as they existed at some common commitment boundary when you saved the data.
Use the APYJRNCHG command specifying the CMTBDY(*YES) parameter to bring the files forward to some defined application boundary if one of the following is true:
- The common commitment transaction boundary is not an application boundary.
- Additional transactions exist in the journal that you want to apply to the objects.
By specifying CMTBDY(*YES), you can ensure that the apply operation starts on a commitment boundary. You also ensure that the server applies complete transactions up through the specified sequence number that corresponds to your application boundary.

If the commitment boundary is an application boundary, then no additional recovery procedures are necessary.