When it comes to journaling experts, IBM's Larry Youngren is among the best. Recently this award-winning speaker
teamed with Adam Stallman, a member of IBM's iSeries Journal design team, for a Search400.com webcast on The benefits and uses of remote journaling. A few people had questions for Youngren and Stallman following the broadcast; below are their responses.
What happens to the HA BP now with the remote journaling available? Can their product work with remote journaling?
Youngren/Stallman: Yes, indeed the traditional HA BP vendors still have a very important role to play. The arrival of Remote Journal support does NOT replace them. It merely makes their products better. The presence of Remote Journal is an attempt on our part to provide them with more options and improved efficiency. The HA BP vendor products do an essential step that Remote Journal alone does NOT provide: They replay the resulting journal entries on the target machine. Remote Journal is only a transport mechanism, not a replay mechanism.
Recent versions of all the major HA vendor suites have incorporated Remote Journal as a transport option. Some of the most recent HA vendors have so much confidence in the Remote Journal approach that they've elected to make Remote Journal the ONLY transport option. We believe their confidence is well placed. That doesn't mean that older versions of some HA BP products are equipped to work with Remote Journal, rather you'll want to assure that you check with your preferred HA vendor to insure you're using a version of their product that is modern enough to embrace Remote Journal.
On V5R1 what does the chgjrn jrnstate(*inactive) do ?
Youngren/Stallman: This option on the CHGJRN command allows you to flag the journal as "closed for business - - not accepting any more journal entries".
At this point it's an increasingly ancient and aging option that we'll probably be withdrawing in a future release, hence I'd be inclined to suggest that you begin to wean yourself away from using it.
There are better alternatives.
On the target machine, for example, use of the newer *STANDBY mode is often a wiser choice.
Also use of the CHGRMTJRN command rather than the CHGJRN command on the source side is often a better choice for managing the relationship between the source (so-called "local") and target (so-called "remote) journals. This is especially true for Sync-flavored Remote Journal mode.
Maybe a little background will help...
A Sync-connected remote journal on the target can be in one of three states for the purpose of this discussion:
- *ACTIVE -- This is the normal "I'm alive and well and feeling fine, send me journal entries" state.
- *InActPend -- This is the "I used to be *ACTIVE but lost contact with the source side and I'm not yet sure whether the most recent journal entries entrusted to me also made it out to the disk on the source side, I wonder what you'd like me to do with them?" state. (Note: These in-doubt journal entries are called "unconfirmed" because the source side hasn't yet confirmed to the target that they reached the disk surface on the source.) Depending on what action you take next, the Remote Journal on the target will either let you read these unconfirmed entries (and most HA vendor products would probably want to do just that) or... will toss them away. Thus you've got to make sure your HA vendor knows which policy he wants to adopt before leaving this state.
- *InActive -- This is the "I've jettisoned any unconfirmed journal entries and am ready to shake hands anew with my twin on the source side as soon as he is alive and well, just let me know when you're ready to proceed" state. It's the state you need to reach on the target before the source side attempts to re-establish contact.
With that as a background...
Issuing CHGJRN . . . jrnstate(*inactive) on the source against the local journal merely makes him reject subsequent journal deposit attempts. This does not alter the connection between the local and the remote journal.
Issuing CHGJRN . . . jrnstate(*inactive) on the target against the remote journal moves him from *InActPend to *Inactive and also tosses (erases from the remote journal) any unconfirmed entries thereby priming the remote journal for reconnection to the source side. This step is not necessary for async-connected remote journals, as they have no unconfirmed entries.
More details can be found in the Redbook "As/400 Remote Journal Function for High Availability and Data Replication" at http://www.redbooks.ibm.com.