Originally, database files were the only object eligible for journal protection and the matching Start Journal Physical File (STRJRNPF) command was sufficient. As the years progressed, keyed logical files (also known as Access Paths) were welcomed into the fold and a matching Start Journal Access Path (STRJRNAP) command showed up. More time passed, IBM's journal developers recognized that critical information was no longer stored exclusively within the database, and so additional objects such as data areas, data queues, and even IFS files became journal eligible. However, in order to grant journal protection to such objects, you had to name them one-by-one and you had to take overt action to identify each such object and grant it journal protection.

If you were lazy or sloppy, you could easily overlook an object and suffer the consequence.

In the latest release (IBM i 6.1) a substantial new approach was initiated along with a new command.

Do you know what it is?

Answer: The new attribute is known as "Library Inheritance" and the matching command is Start Journal Library (STRJRNLIB). Why would you want to journal a library? Answer: Because doing so has an impact which may help assure that you don't overlook objects which need journal protection. Does the practice of issuing STRJRNLIB cause all underlying objects housed within the library to become journal protected? No, that's not it.

Rather, the library itself takes on the role of a mother hen. It watches for the arrival of new objects added to the brood and insures that they newly arriving objects are journaled at birth - that's the "inheritance" part. Hence, it's not an effect on the objects already resident in the library when the STRJRNLIB command is issued but rather an impact on the new arrivals.

Say, for example that you create a new physical file, PF1, within library Lib1. Provided that Lib1 has taken on this new role, PF1 will have no choice. It will be journaled. In fact, not only with the equivalent of a STRJRNPF operation be performed against PF1 but even the fact that PF1 was created will itself become a new entry within the journal. In a sense, you can think of this as a birth certificate.

Who cares?

Answer: Since the STRJRNPF behavior will ensue at birth, that is: before any application has had an opportunity to add any new rows to the PF; you can rest assured that all actions taken against this new PF have indeed been captured in the journal associated with the library. That's an especially attractive behavior if you have applications which tend to create new PFs on the fly. It assures that you're well prepared should you experience a site loss and then have to try to recover your database at a hot site. Provided that you bring your latest journal receivers with you, you know that there will be no missing PFs.

Are there any downsides to granting "Journal inheritance" as an attribute to your libraries?

Answer: Just be sure you truly understand what you've asked the underlying operating system to do. You've instructed it to be diligent and issue a STRJRNPF to every file which arrives hereafter. That includes not only simply PFs but also any type of object which is built on an underlying PF. Hence, if you tend to store outfiles or work files within the library, they too will be journaled at birth.

Also be sure you look into the defaults associated with this command. Since data areas and data queues can also reside within libraries and since both object types are journal eligible, newly created data areas and data queues will also be granted journal protection. There are options on the STRJRNLIB command to customize which kinds of objects to include or exclude and also options to customize whether the STRJRNPF behavior ensues only for CRTPF operations or also when objects join a library because you've restored them or moved them.

Net: Think of the new STRJRNLIB command as a safety net. It's an easy way to assure that you grant journal protection to all newly created files, data areas, and data queues.