IBM Power System i Journaling: To cache or not to cache

Home/HADR Solutions for business/IBM Power System i Journaling: To cache or not to cache

IBM Power System i Journaling: To cache or not to cache

The use of journaling is a common denominator for most High Availability solutions.  It seems many people are a bit intimidated by this. Frankly, if a journal/journal receiver is not set up and managed correctly, it can and will bring your system to a halt. For this reason, most HA solutions offer a built-in journal management function. However, it is still important to have at least a basic understanding of the journaling function.

CPU overhead associated with journaling

Figure 1 shows performance on a client system during our HA implementation.  Prior to ITSG starting journaling, the nightly process ran 50 Minutes.  The impact on a batch job after starting journaling brought that same job run time to 210 minutes. My phone starting ringing.   We installed Opt. 42 HA Journal Performance and changed the journal caching to *YES.  Job run time went back to 50 minutes.

Figure 1.


57xxSS1 Opt. 42 HA Journal Performance, gives us the ability to cache your updates before writing to disk.  Journaling allows “Journal caching”, but by default caching is set to *NO.

Opt. 42 HA Journal performance is a fee based licensed program option for IBM Power i.  Once installed and set to active,  Journal Caching starts the usual 70 day ‘trial’ clock so you have time to test the benefit of Journal caching. Consult with your IBM Business Partner or ITSG for pricing

 The ability to change Journal caching can be done ‘on the fly’ using the command: CHGJRN  JRN(jrn lib/JRN)  JRNRCV(*GEN)  JRNCACHE(*YES)”.  If  Opt. 42 HA Journal Performance is not installed, you will get  “Message ID. .:   CPD70E4  “Changing the journal cache not allowed”

As with any caching option that uses system memory, journal caching does come with an element of risk.  This IBM Redbook explains it in more detail.

Journal Caching: Understanding the Risk of Data Loss



Although journaling is not hard to maintain, it is NOT a ‘set it and forget it’ process. IBM is always enhancing journaling functions. Not only is it updated by a new release of the OS, but with PTFs and Technology refresh levels as well.  Of the 9 TR releases at V7R1, 6 of those had Journal related updates.

Current PTFs for Journaling for all supported releases

Not all Journal PTF’s make it on a Group or cumulative PTF package.  If a cumulative PTF Package number is not shown to the right of the PTF number, that PTF will need to be ordered separately.
For example, PTF MF59454 “LIC-DB-JRN EVI refresh inhibits force, impacts journal sync” will be a manual install.

R710 MF59454
R710 SI52882 on C4283710

One more performance item to discuss.  Async vs. Synch   

Remote journaling

The remote journal function has two modes of operation:

  • Sync mode attempts to refrain from caching, thereby assuring that newly arriving journal entries are sent to the target side as rapidly as possible. In doing so, it sacrifices some performance. This is the default.
  • Async mode welcomes caching and even has a “super-bundling” mode that is aimed at attempting to improve performance by bunching together larger quantities of journal entries that are headed to a remote target machine.

Changing between modes is done with the CHGRMTJRN command.  The remote journaling state must be *Inactive to do this.

To inactivate remote journaling

To activate Asynchronously

To Activate Synchronously

To re-activate remote journaling

Reference links:

High Availability on the AS/400 System: A System Manager’s Guide

 IBM I Journal Management 7.1

IBM I Journal Management 7.2

 AS/400 Remote Journal Function for High Availability and Data Replication

HA Journal Performance

Journal Standby Mode on IBM i5/OS: When It Makes Sense to Use

2016-10-23T16:46:16+00:00 By |