Journaling at Object Creation with i5/OS V6R1M0

A new method to automatically journal objects within a library.

For many users, the objects within a library are not static. New objects are created and deleted over the course of a day. To allow for more complete recovery and replication there is a desire to have objects automatically start journaling when they are added to a production library. With V6R1M0 of the i5/OS operating system there is a new method to accomplish this task.

In V6R1M0 there is a new Start Journal Library (STRJRNLIB) command that allows the library to become a journaled object. This means that any objects eligible to be journaled that are added to the library can be automatically journaled.

Like the previous release support with the QDFTJRN data area, when journaling a library the user can specify what object types and what operations should cause automatic journaling. This information is specified via the Inherit Rules (INHRULES) parameter of the command. With the INHRULES parameter unique journal attributes can be specified for each object type. This allows the default values for the Images and Omit journal entries to be overridden.


How about an example:

The following is the prompt screen for the new command. The library specified to start journaling is PRODLIB. The journal that it is to be journaled to is @JRNLIB/JRNL. By default, all eligible objects (objects of type *FILE, *DTAARA and *DTAQ) that are added to the library (created in the library, moved to the library, or restored to the library) will start journaling. The appropriate default Images and Omit journal entry values are used for each object type.

The Inherit rules parameter allows for flexibility in what objects will automatically start journaling and what journal attributes will be used when journaling is started.




                        Start Journal Library (STRJRNLIB)                      
                                                                               
 Type choices, press Enter.                                                    
                                                                               
 Library  . . . . . . . . . . . .   PRODLIB       Name, generic*                
                + for more values                                              
 Journal  . . . . . . . . . . . .   JRNL          Name                          
   Library  . . . . . . . . . . .     @JRNLIB     Name, *LIBL, *CURLIB          
 Inherit rules:                                                                
   Object type  . . . . . . . . .   *ALL          *ALL, *FILE, *DTAARA, *DTAQ  
   Operation  . . . . . . . . . .   *ALLOPR       *ALLOPR, *CREATE, *MOVE...    
   Rule action  . . . . . . . . .   *INCLUDE      *INCLUDE, *OMIT              
   Images . . . . . . . . . . . .   *OBJDFT       *OBJDFT, *AFTER, *BOTH        
   Omit journal entry . . . . . .   *OBJDFT       *OBJDFT, *NONE, *OPNCLO      
                + for more values                                              
 Logging level  . . . . . . . . .   *ERRORS       *ERRORS, *ALL                
                                                                               
                                                                               
                                                                               
                                                                               
                                                                         Bottom
 F3=Exit   F4=Prompt   F5=Refresh   F12=Cancel   F13=How to use this display    
 F24=More keys                                                                  




The following example shows the command to automatically journal all files added to the library, but only automatically journal data areas when they are created into the library. In this example data queues would not automatically start journaling. Additionally, for files the Images value of *AFTER and the Omit journal entry value of *NONE will be used. The Images and Omit journal entry values for data areas will be the system default values because no other value is specified.

STRJRNLIB LIB(PRODLIB) JRN(@JRNLIB/JRNL)
INHRULES((*FILE *ALLOPR *INCLUDE *AFTER *NONE)
(*DTAARA *CREATE))


The following example shows the command to automatically journal eligible objects created or restored into the library but to omit objects moved into the library.

STRJRNLIB LIB(PRODLIB) JRN(@JRNLIB/JRNL)
INHRULES((*ALL *ALLOPR *INCLUDE) (*ALL *MOVE *OMIT))


What about SQL tables?

SQL tables have automatically been journaled since the introduction of SQL. Starting in V6R1M0, SQL schemas will be created with the library being journaled and the inherit rules set to (*FILE *CREATE *INCLUDE *BOTH *OPNCLO). So any files (or tables) created into the schema will be automatically journaled, but other object types will not. Also, files moved or restored into the schema will not automatically start journaling. This results in the same behavior that schemas had in prior releases.


Changing automatic journaling settings

The inheritance rules of a journaled library can be changed with the Change Journaled Object (CHGJRNOBJ) command. Specify the library to change on the OBJ (Object) parameter, *INHRULES on the Attribute (ATR) parameter, and the new set of inheritance rules on the Inherit rules (INHRULES) parameter. It is worth noting that inherit rules specified on this command will replace all rules currently defined for the library.

As an example, consider a library journaled with the default inheritance rules. To change this to only journal physical files (with the default Images and Omit journal entry values) the following would be specified:

CHGJRNOBJ OBJ((PRODLIB *LIB)) ATR(*INHRULES)
INHRULES((*FILE *ALLOPR *INCLUDE))


Impacts on disaster recovery procedures

Journal users have long known to use the Apply Journaled Changes (APYJRNCHG) command at their backup site to recover from disasters. The recovery performed by this command can be maximized by journaling libraries. By applying the changes recorded on behalf of the library object, files, data areas and data queues can be created during the apply operation. These types of changes would be applied with either of the following command examples.

APYJRNCHG JRN(@JRNLIB/JRNL)
OBJ((PRODLIB *LIB) (PRODLIB/*ALL *ALL))

Or

APYJRNCHG JRN(@JRNLIB/JRNL) OBJ((PRODLIB/*ALL *ALL))


Both examples will apply changes for library PRODLIB and all objects found in it. This includes applying entries for logical files (APYLF(*YES) is the default). The apply operation will start from the last save of each object and end where the objects are restored (also command defaults).

One note about applying entries for logical files, in prior releases the APYJRNCHG command would not apply entries for logical files. This function was only available with the Apply Journaled Changes Extended (APYJRNCHGX) command. A new parameter is now available on the APYJRNCHG command to indicate that entries for logical files built over the physical files specified on the command are also to be applied. This new parameter is Apply changes to logical files (APYLF). As noted earlier, the default for this new parameter is *YES. So by default, actions performed against logical files will also be applied.


Any differences between journaling libraries and the QDFTJRN data area support?

One of the differences between the V6R1M0 library journaling support and the automatic journaling provided in V5R4M0 via the QDFTJRN data area has to do with the authority that is required to automatically start journaling. With the V6R1M0 support the only user required to have authority to the journal is the user that starts journaling the library. Users that create objects that become automatically journaled require no authority to the journal. With the QDFTJRN data area support in V6R1M0 the user no longer needs authority to the journal either, but they do need authority to read the QDFTJRN data area. In V5R4, every user creating an object that was to be automatically journaled needed authority to the journal.

Another addition with the V6R1M0 library journaling support is that since the library is journaled, there will be new journal entries to record changes made to the library. This includes actions like changing the authorities related to the library and changing the text of the library. Also, when the library is journaled, the journal cannot be deleted. With the QDFTJRN data area support there is nothing to prevent the journal specified within the data area from being deleted.

Additionally, with the INHRULES parameter the values used when starting journaling objects for Images and Omit journal entry can be tailored. With the QDFTJRN data area support, default Images and Omit journal entry values were always used. The current inherit rules for a library can be seen via the Display Library Description (DSPLIBD) command.


How does library journaling interact with the QDFTJRN data area support?

Since there are now two methods for automatically journaling objects, it is important to know how these two methods work together. If there is a QDFTJRN data area in the library to which an object is being added, then the information in the QDFTJRN data area will be used to decide if the object should be automatically journaled. This decision was made so that existing users of the QDFTJRN data area would not be surprised when they moved up to the new V6R1M0 release.

If journaling is started on a library that contains a QDFTJRN data area, an informational message is sent to remind the user that the data in the QDFTJRN data area will override any INHRULES. Additionally, every time the system is considering automatically journaling an object and finds a QDFTJRN data area within a journaled library, an informational message is issued to remind the user that the data in the QDFTJRN data area is overriding any inherit rules that were specified for the library. It is up to the end user to decide when to delete the QDFTJRN data area and let the library inherit rules take over automatic journaling.


Benefits of journaling libraries

By journaling libraries, objects can be automatically journaled as they are added to the library which allows for more robust auditing, replication, and disaster recovery. The library will be reported as a journaled object when viewing all objects journaled to a given journal. Additionally, changes made to the library will be recorded in the journal and can then be recovered.