IBM i 7.1 Journal and Remote Journal Enhancements

High Availability / Disaster Recovery
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Filtering capabilities, automatic restart, and more!


IBM i 7.1, officially released last April 23, provides enhancements that help ensure System i will be a robust and reliable platform for many years to come. One of the greatest features of IBM i 7.1 is its capability of journaling and remote journaling, the cornerstones of many high availability (HA) solutions currently available on the market. This article examines the IBM i 7.1 enhancements to journal and remote journal and includes practical examples.

Journal Enhancement: Object Name Filtering for Automatic Journaling

On this new release, when you're journaling libraries using the Start Journal Library (STRJRNLIB) command, you can now select or omit objects to automatically start journaling based on the name of the object (name filter). This allows you to automatically start journaling new production files in the library (but not journal temporary work files if they are named uniquely).


The name filter support is available via the INHRULES parameter for the STRJRNLIB and Change Journaled Object (CHGJRNOBJ) commands. You may specify both include and omit filters. The order in which the filters are implemented matters: the last filter defined for the object is the one applied. The name filter rules apply to objects that are created, moved, or restored to the specified library. Renaming an existing object after the filter rule is implemented will cause journaling to not start for this object.


The following code will start journaling for all objects added to the library except files whose names start with WRK or TMP.






Remote Journal Enhancement: Automatic Restart Capability with Remote Journaling

Remote journaling is dependent on communication networks, which occasionally have problems. When communication problems are encountered, remote journaling ends. New on IBM i 7.1 is the capability to have remote journaling automatically restart when it ends because of a recoverable error (CPF70D5 or CPF70C5 messages).


On this new release, the operating system will attempt to restart the remote journal after a recoverable error. You can specify the number of attempts to be made and the time delay between them (in seconds) using the Change Remote Journal (CHGRMTJRN) command or the Change Journal State (QjoChangeJournalState) API. The restarts will happen in the QSYSWRK subsystem under jobs named QJORESTART. If restarts happen, message CPI7027 will be sent to the journal message queue for each attempt; if all restart attempts fail, message CPI7028 will be sent to the journal message queue.


The following code will attempt a restart 20 times, every 60 seconds.





You can verify the maximum restart attempts associated with a remote journal by entering the following command and selecting PF16 and then option 5=Display remote journal details.





Figure 1: Verify restart attempts. (Click images to enlarge.)


Another important addition in this release is the capability to verify the total retransmissions associated with a particular remote journal. None of the previous operating system releases had an easy way to do this.


From the above screen, page down twice to the following screen:



Figure 2: Verify total retransmissions.

Remote Journal Enhancement: Filtering Capabilities

Historically, a remote journal receiver has been a duplicate of the journal receiver associated with the local journal. New on IBM i 7.1 is the ability to filter entries for a remote journal connection. Filtering out journal entries that are not absolutely needed on the target system can decrease the amount of data sent across the communication line.


Important notes about remote journal filtering:

  • A journal may have different remote journal connections with different filtering criteria.
  • You can have a new journal receiver generated when new remote journaling criteria is added.
  • You can have a different journal receiver's library on the remote system for each remote journal filter criteria created.
  • Remote journaling filtering is valid only for asynchronous remote journals.
  • Remote journaling filtering requires the licensed, chargeable option HA Journal Performance (5770SS1 option 42, feature 5117) to be installed.


Remote Journaling Filtering Criteria


  • Before images—for files and data areas, even before images in R/DL (Record deleted in the physical file member) and R/DR (Record deleted for rollback operation) entries
  • Individual objects—files, data areas, data queues
  • Program names—with qjoChangeJournalState API only

Before Images


This remote journaling filtering criteria will allow before image journal entries to not be sent to the remote journal. This is especially useful when the local journal has applications using commitment control, which require before images to exist on the source system for rollback operations. On the target system, the before image journal entries may not be of any application, so implementing this filtering option should enhance the throughput between source and target systems.





Note: You cannot use a before image filtered receiver for the RMVJRNCHG command because it needs the before images to roll back the changes. 


The remote journaling filtering rules can be verified by using the following command and selecting PF18.





Figure 3: Verify remote journaling filtering rules (no filtering by object, filter before images).


Individual Objects   


This remote journaling filtering criteria indicates which journal entries associated with a given object are not to be sent to the remote journal. The default is off (i.e., by default, all entries associated with a journaled object will be sent to the remote journal). The object attribute indicates that journal entries for it should be filtered with remote journaling. The object filtering criteria can be implemented via CHGJRNOBJ or the INHRULES on STRJRNLIB commands.







The remote journaling filtering rules can be verified by using the following command and then PF18.





Figure 4: Verify remote journaling filtering rules (filtering by object, no filter images).


Program Names


This remote journaling filtering criteria indicates which journal entries deposited on behalf of any program(s) should not be sent to the remote journal. It is implemented via the qjoChangeJournalState API using the format CJST0500 (find information about the qjoChangeJournalState API in the Infocenter).


You cannot use a filtered receiver for APYJRNCHG when journal receiver entries were filtered by object or program, but before-image filtering is allowed.


Remote Journaling Latency


Replicating a journal entry asynchronously means that the journal entry is replicated to the target system after control is returned to the application depositing the journal entry on the source system.


Journal entry latency might occur when remote journals are asynchronously maintained (Remote Journal Delivery Mode = *ASYNC). Journal entry latency is the difference between journal entries existing in the remote journal on the target system and those residing in the journal on the source system. From a recovery standpoint, the source system might be some number of journal entries ahead of the journal entries on the target system.


In this new release, active asynchronous remote journaling on the target system will now report an estimate of how many hundredths of a second it is behind, the maximum time behind since the connection was started, and when that maximum time behind occurred.


Use the following command:





Figure 5: Determine how far behind the target system is.


Easier and Faster!

As you can see, the IBM i 7.1 journal enhancements will allow better use of the System i resources—communications and storage—and will also make journal management much easier and quicker.