Example: Saving objects with partial transactions

This example shows a typical use of the save-while-active function to eliminate save-outage time by not waiting for commitment boundaries. Your exact use of the function may differ, based on your specific application requirements.

This example uses a checking and savings account. Both libraries contain journaled objects and the journals for those objects. The changes may or may not be made under commitment control.

This example demonstrates a save without waiting for commitment boundaries and does not end the applications that are making changes to the objects that are in these libraries. Not ending the applications introduces additional restore considerations for the recovery operation after you restore the objects from the media.

Use the following steps to eliminate save-outage time without waiting for commitment boundaries:

Submit the following command before the transaction is ended:
```
SAVLIB LIB(CHK SAV)  DEV(TAP01) SAVACT(*SYNCLIB) +
	SAVACTWAIT(30 *NOCMTBDY 30) +
	SAVACTMSGQ(QSYSOPR) +
	ACCPTH(*YES)
```
Note: You can also use the SAVOBJ or SAVCHGOBJ commands, depending on your specific needs.

The server waits 30 seconds, as specified by the SAVACTWAIT parameter to resolve each lock conflict during checkpoint processing. The objects will not be saved if lock conflicts are not resolved within the specified time.

By specifying ACCPTH(*YES), you are also saving access paths for the logical files. Access paths, in most cases, will not be built after restoring the files from this save media.

The recovery procedures needed when restoring objects from this media are dependent upon each of the database members in the CHK and SAV being updated with the time stamp of this save operation.
When checkpoint processing is complete, QSYSOPR receives message CPI3712 as specified by SAVACTMSGQ parameter. Until the QSYSOPR message queue receives the CPI3712 message, monitor lock conflicts that the save-while-active job may encounter.
Wait for the save job to complete.
After the batch job has completed, verify that all of the required objects were saved. If any objects were saved in a partial state, the files must be either rolled forward or backward to a consistent state before they can be used.
Save the appropriate receivers of each journal being used to journal the objects in libraries CHK and SAV. You must include the receivers to be saved starting with the receiver containing the start of commit entry for any transactions which were open when the save checkpoint processing took place through the attached receiver. The save OUTFILE will indicate the name of the earliest receiver for each object which will need to be available to use the APYJRNCHG command during the recovery process. You must issue a separate save request to save these receivers if these receivers do not exist in library CHK or SAV
Note: It is highly recommended that you save all of the attached receivers with the following command.
Multiple save commands may be necessary for this step. Note that it is not necessary to use the save-while-active function when saving journal receivers. The following command defaults to SAVACT(*NO).
```
SAVOBJ OBJ (attached-receiver)+
LIB (attached-receiver-library)+
OBJTYPE(*JRNRCV)+
DEV(TAP01)
```