If you restore an object that was saved with a save-while-active operation that specified that the object can be saved before it reaches a commitment boundary, it can have partial transactions. To recover objects that are in a partial state you must perform an apply or a remove journaled changes operation.
Another reason that an object can have partial transactions is if a long-running rollback was forced to end. However, if an object has partial transactions because of a long-running rollback, you cannot recover it with an apply or remove journaled changes operation.
If you perform save-while-active operations that can result in objects that are saved with partial transaction, it is recommended that you use Backup, Recovery, and Media Services (BRMS). You can use BRMS to automate your backup and recovery operations. BRMS automatically applies changes to objects with partial transactions and restores them to a usable state. For more detailed information see the BRMS topic.
When you recover objects with partial transactions, all of the journal receivers that are required for the recovery operation must be on the system. The recovery operation might require more journal receivers than just the last one you detached. The system looks for the last journal receiver with an journal entry for the object that indicates one of the following:
The following illustration demonstrates these requirements.
As the previous figure shows, even if you are performing an apply journaled changes operation, it is still possible that the transaction can be rolled back and you will need previous journal receivers.
All of the objects in the following examples are database files. The following are examples of recovering objects in a partial state from three possible scenarios:
In this example, an object, OBJ1 in library LIB1 was saved with a save-while-active operation while it had pending transactions. The save-while-active operation is the object's most recent save. Journaled changes start from the last save and end at the last sequence number in the journal receiver.
The following is an example of the APYJRNCHG command. The default value for FROMENT is *LASTSAVE. The TOENT parameter uses the *LASTRST value to apply journaled changes up to the journal entry when the object was last restored.
APYJRNCHG JRN(JRN1) FILE(LIB1/OBJ1) FROMENT(*LASTSAVE) TOENT(*LASTRST) RCVRNG(*LASTSAVE)
The following is an example of the RMVJRNCHG command. The following command removes the changes in journal JRN1 from the all the members of OBJ1:
RMVJRNCHG JRN(JRNA1) FILE(LIB1/OBJ1) FROMENT(*LASTSAVE) TOENT(*COMMITSTART) RCVRNG(*LASTSAVE)
Starting with the last save journal entry, only changes for journal entries for any partial transactions are removed, back to the start of the commit transaction.
This example uses the Change Journal Object (CHGJRNOBJ) command because the journal receivers are not available to perform an apply or remove journaled changes operation. The Partial Transactions (PTLTNS) parameter allows the object to be used, but does not complete the transactions. The object, BRKNOBJ, still has changes caused by the partial transactions, but you are able to open the file.
CHGJRNOBJ OBJECT(LIB1/BRKNOBJ *FILE) PTLTNS(*ALWUSE)