Why save objects after you start journaling

 

After you start journaling, it is essential that you save objects that you are journaling.

It is critical to save the journaled object after journaling is started to be able to apply journaled changes. When you start journaling an object, the system assigns a unique journal identifier (JID) to that object. If the object is a physical database file, each member is also assigned a unique JID. If you start journaling on a distributed file, the piece on each server has its own unique JID. The JID is part of every journal entry added to the journal receiver for a given object. The system uses the JID to associate the journal entry with the corresponding journaled object. The copy of the object on the save media that was saved before it was journaled does not have the journal identifier saved with it. Therefore, if this copy of the object is restored to the server, the journal entries cannot be associated with the object and cannot be applied.

After you start journaling an object, do the following:

• Save the object immediately after you have started journaling it, before any changes have occurred.

• Save a physical file or a logical file after you start journaling access paths for the file. This ensures that when you restore the file, journaling access paths is started automatically.

• If you are using distributed files, save the file separately on the systems in the node group after starting journaling for the distributed file.

Saving these objects ensures that you can completely recover all the objects by using your saved copy and your journal receivers.

 

Updating the history

If you are not using the save-while-active function, update the history for the object when you save it so that processing for applying and removing journaled changes will have the best information for verification. If you save the object using the SAV command, change the UPDHST value to something other than *NO. The default value for the SAV command is to not preserve the update history. For the other Save related commands, the default value is to preserve the update history. When you use the save-while-active function, you do not need to update the history for the object for verification when you apply and remove journaled changes. When you use the save-while-active function, information is saved on the media with the object and restored when the object is restored. This extra information provides the last save information for applying and removing journaled changes.

 

Saving queue contents

• To save the contents of the queue as well, one must specify QDTA((*DTAQ) on the save commands.

 

The JID and other journaling operations

Not only do you need the JID to apply journaled changes, other journaling operations use the JID. All formats, except the *TYPE1, *TYPE2, and *TYPE3 formats, for the Display Journal (DSPJRN), Receive Journal Entry (RCVJRNE), or Retrieve Journal Entry (RTVJRNE) command include the JID for the object. The JID is also included with the *TYPEPTR and *JRNENTFMT format for the RCVJRNE command, as well as the Retrieve Journal Entries (QjoRetrieveJournalEntries) API. You can use the Retrieve JID Information (QJORJIDI) API to retrieve an object's name (for an object not in the integrated file system) or the file identifier (for an object in the integrated file system), if you know its JID.

 

Commands for saving objects

You can use one of the following commands to save journaled objects:

Physical database files, data areas, and data queues

• Save Changed Objects (SAVCHGOBJ) and specify OBJTYPE(*object-type) OBJJRN(*YES)

• Save Object (SAVOBJ)

• Save Library (SAVLIB)

• Save (SAV)

Integrated file system objects

• SAV

See the Manually saving parts of your server topic for more information about saving journaled objects.

 

Parent topic:

Starting and ending journaling and changing journaling attributes

Related concepts
Journal entries Recovery of journaled objects

Related tasks
Manually saving parts of your server