The Four Hundred

Editor's Note: A Tech Insight column authored by Chris Hird and published on August 5 mistakenly left some people with the impression that the relatively new remote journaling feature in OS/400, being used in a number of high availability software solutions for the OS/400 market, does not support remote journaling of data queues, data areas, or the Integrated File System. This is untrue, as Larry Youngren, an OS/400 microcode designer intimately involved with journaling, explains. We wanted to make sure you see his comments, which were originally published in the Reader Feedback and Insights column on August 12.

In the article "Tech Insight: OS/400 Remote Journaling Issues," Chris Hird stated his belief that data areas, data queues, and Integrated File System journaling were not eligible to flow across the communication wire from a local production journal to a remote journal.

Actually, the remote journal is merely a replication on a target machine of everything that flows into a local production journal receiver on the source machine. It's just that straightforward.

Hence, data areas, data queues, and Integrated File System object journaling is no different from database journaling, from a remote journal point of view. To the remote journal facility, they're just additional strings of bytes representing journal entries that need to be transported efficiently, through better plumbing, to the target system.

The remote journaling facility doesn't interrogate the kinds and flavors of such journal entries and weed out the data area- or data queue- or Integrated File System-flavored journal entries and elect to refrain from sending them. Nor does it insist that such objects place their entries in some separate journal distinct from the remote journal and journal receiver being used for traditional database objects. They can (and often are) intermixed within the same journal.

The resulting journal entries, which are replicated to the remote instance of the journal, are intact in every respect. Every descriptive field residing within a journal entry, identifying the action that originated the change, which was visible on the source machine, is present and visible on the target machine, including things like program name, job name, and user profile.

A shop can even elect to put its own so-called "user" entries into the journal. Say, for example, that you want to signify the time when a particular critical job ends. Merely use the SNDJRNE command or the Send Journal Entry (QJOSJRNE) API, and whatever journal entry you write to the production journal shows up in the same spot on the remote copy.

Beginning with V5R1, you can even see the so-called DDL type of database operations (Grants, Removes, ALTER TABLE) on your ordinary data journal. These are database object-level operations, which, beginning with V5R1, are now recorded on the local production data journal, interspersed with the DML type of operations (Put, Update, Delete); hence, they, too, flow through the remote journal plumbing to the target system.

Thus, all high availability vendors can now elect to harvest such object-level database actions from the remote instance of the journal receiver rather than having to try to watch two journals at the same time (the audit journal and the data journal on the source machine). The same is true for Integrated File System objects; that is, all object-level actions such as attribute changes and authority changes are placed in the data journal associated with these objects. And all of this can be transported, in real time, from the production machine to the target machine via better plumbing: remote journal.

In fact, if there is an interest or need to monitor the audit journal so as to detect changes to other object types, such as user profiles, even the audit journal itself can be replicated in real time to the remote system. In short, the remote journal technology takes on all comers and replicates all journal content that shows up on the production system.

Sure, you still need to write or acquire high availability software to then replay the changes represented by the replicated remote journal entries to the associated database files, Integrated File System objects, data areas, or data queues, but harvesting such journal entries with the precious and limited CPU cycles of your production machine can become a thing of the past. Instead, such overhead can be shifted to the target machine, thereby freeing up CPU cycles on the production machine.

In addition, the remote journal plumbing has the capability to behave in either broadcast or cascade mode (or even a combination of the two). Thus you can employ the remote journal technology either to broadcast multiple replicas of such a journal receiver to multiple sites or to cascade such replicas.

Say you have a production system at your headquarters that needs to send delta information about a mixture of certain updated Integrated File System objects and matching database records to multiple regional locations--price updates, for example. Rather than sending the whole object each time you modify your prices, and rather than write special code to extract the updated prices and have this code execute on your production machine, you could merely set up a broadcast remote journal connection from your production system to as many as 255 remote locations.

They'd each receive, via remote journal, copies of the newest entries deposited into the journal receiver, reflecting the updated prices in real time. If you choose to, the data could then be read from the remote instance of the journal receiver and used to update selected prices on the target system.

Some shops may want to use the remote journal technology to both broadcast and cascade. Imagine a production system that wants to achieve high availability by sending journal entries in real time to a second iSeries backup machine across the street, which, in turn, sends this same set of journal entries to a data warehouse machine across the country. The production system (A) would broadcast to the high availability system (B), which would then cascade to the data warehouse machine (C). Both your high availability site and your data warehouse site would remain cognizant of your latest Integrated File System, data area, data queue, or database changes. The remote journal plumbing makes such topologies easy to set up.

Examples of such broadcast and cascade topologies were investigated in November 2001, during production of the Redbook Striving for Optimal Journal Performance.

For a list of all possible system-generated entries, and thus all entries that participate in local and remote journaling, see the Backup and Recovery Guide's Appendix "Journal Entry Information." If you find a journal entry flavor documented in this list, remote journal handles it!

Larry Youngren is an OS/400 microcode designer for IBM in Rochester, Minnesota. His current assignment involves future performance and recovery improvements affecting journaling. Larry can be reached at youngren@us.ibm.com.