For many industries, 24-hour, 7-day system availability is a must. They can’t afford to have downtime or system failure of any kind. In this environment, it is difficult to have a secondary system that can assume the load should something happen to the primary system. In addition, if there is a primary system failure and a secondary system does take over, it is increasingly difficult to switch back to the primary system when necessary. With V4R2, IBM has introduced an effective and efficient way to implement a hot-backup

environment that will meet the critical demands of your shop. Come find out what it is and how it works.

Remember when backup and recovery meant restoring last night’s data from reel- to-reel tape or a magazine of 8 1/2-inch diskettes and asking the department whose data was lost to re-key everything for that day? The term hot backup was used back then, but it described the temperament of the manager and the direction of productivity, not data replication.

Later, the ability to journal data was introduced. A journal entry was written to a journal receiver for every database change made. This feature allowed data to be locally replicated. If a database file required restoring, it could be restored, and journal entries applied from the time of the last backup to the last journal entry for that database file. This method cut down on the re-keying, but what happened when the system went down?

It didn’t matter that the data was journalized; it couldn’t be accessed. This situation is one in which the more appropriate, and less emotional, meaning for hot backup would apply. Journal entries could be asynchronously applied to a remote AS/400 by receiving them on the primary system, sending them to a secondary system, and then applying them to a database file on the secondary system. In that way, if the primary system went down, the data would reside on a secondary system. Although this method decreased the risk of losing data, it didn’t completely remove it. Today, with the introduction of the remote journal function, the risk of losing data approaches zero.

The remote journal function, available withV4R2, allows you to add journals and journal receivers on a remote AS/400 that are associated with specific journals and journal

receivers on a local AS/400. This function enables you to automatically replicate data from the local system to the remote system. Those familiar with Distributed Data Management (DDM) might recognize the basic concepts behind the remote journal function. When a DDM file or data queue is created on a remote system and the local file or data queue denoted in the DDM version is modified, the modification is also represented on the remote system. This is accomplished by the operating system. No user intervention is necessary once the relationship has been established. The remote journal function does not work exactly as DDM does, but, in general, the underlying concepts are the same.

Once remote journal and journal receivers have been associated to journal and journal receivers on the local system, they are kept in sync by the operating system. Prior to V4R2, you could have implemented a hot-backup site by using the Receive Journal Entry (RCVJRNE) command (see Figure 1). In that example, the RCVJRNE program receives journal entries from the local journal and then sends the journal entries to the remote system. All of this processing occurs asynchronously to the initial operation that is causing the journal entry. If the primary system goes down before all of the journal entries are received by the remote system, the entries not received are lost.

Replacing this method with the remote journal function solves this problem by allowing replication to occur synchronously to the initial operation causing the journal entry (see Figure 2). In other words, while the database file is being updated, the journal entries are simultaneously posted locally and remotely. If that isn’t enough, the work done by the remote journal function takes place at the licensed internal code layer as opposed to the application code layer, as is the case in Figure 1. Doing the work at this lower layer improves overall system performance and journal entry replication performance.

Most of the features and benefits of remote journals are not visible in the form of new application software or new user commands; rather, they are located inside the operating system. However, to use the remote journal function, there are some new concepts, terms, and API calls with which to become acquainted.

The terms asynchronously maintained and synchronously maintained have already have been introduced but not explained. They describe the mode of journal delivery for the remote journal function. If a journal is asynchronously (*ASYNC) maintained, it passes control back to the application that initiated the journal entry on the source system without waiting for replication to take place on the remote system. An asynchronously maintained remote journal may contain several fewer journal entries than the journal on the source system, which, in turn, could cause database changes to be lost in the case of a system failure. If a journal is synchronously (*SYNC) maintained, it continues with the replication process on the remote system before returning control back to the application. This method increases the likelihood that the two journals are in sync by not buffering the journal entries before transferring them.

Journals themselves have matured with the release of V4R2. They can now be created as local (*LOCAL) or remote (*REMOTE). Local journals are the types that existed prior to the release of V4R2. The remote journal is new in town and is always associated with a journal on another system—similar to a DDM file. However, whereas a DDM object never contains actual data (it merely points to the data on another system), a remote journal contains actual journal entries received from its associated journal on another system. V4R2 introduced three new APIs that allow you to take advantage of the remote journal function:

• QjoAddRemoteJournal This API associates a remote journal on the target system with a local journal on the source system. The journal on the source system may be either a local journal or another remote journal.

A maximum of 255 remote journals may be associated with a single journal on the source system.

• QjoRemoveRemoteJournal This API removes the relationship between a journal on the source system and a journal on the target system. The journal and journal receivers on the target system are not deleted, their association with the source system is simply eliminated.

• QjoChangeJournalState This API changes the state of a local or remote journal on the source system. The state can be changed from *ACTIVE to *INACTIVE or visa versa. *ACTIVE journals allow for the deposit of journal entries into their attached receivers; *INACTIVE journals do not.

IBM figured they would give you a little taste of API calling before providing commands to perform the same functions. So, with the release of V4R3, the Add Remote Journal (ADDRMTJRN), Remove Remote Journal (RMVRMTJRN), and Change Remote Journal (CHGRMTJRN) commands were added to perform the same functions as their respective API counterparts.

Two new journal configuration methods were also introduced with V4R2: broadcast and cascade. A broadcast configuration consists of a journal that replicates entries to one or more remote journals. A journal on the source system can broadcast journal entries to up to 255 remote target systems. A cascade configuration allows a remote journal to replicate its journal entries to another remote journal. This cascading can continue to include an unlimited number of additional remote journals. IBM recommends that, if you choose to broadcast journal entries, you should do so from a target system, after the first level of cascading, so as to not impact performance on the primary system.

Once you have determined that your environment qualifies for the implementation of remote journals, you can use the three aforementioned commands or API calls to start the remote journal process. To associate a connection between a source and a target journal, use the ADDRMTJRN command or call the QjoAddRemoteJournal API. Once the relationship is established, use the CHGRMTJRN command, the previously existing CHGJRN command, or call the QjoChangeJournalState API to start the transfer of journal entries from the source system to the target system or systems.

Figures 1 and 2 show the differences between data replication prior to V4R2 and the current data replication environment. A hot-backup environment using the remote journal function is not much different than the illustration in Figure 2.

In a hot-backup environment, a remote journal is also established on the local system and associated with the local journal on the remote system (see Figure 3). If the local system fails, the remote system can assume the role of primary system and journal entries can be written to the local journal on the remote system. When the local system regains control, the remote journal on the local system becomes active and receives all of the journal entries since the failure. During normal processing (that is, when the local system is the primary system), the remote journal that is defined on the local system is not active. When it is not active, it is not receiving journal entries from the local journal on the remote system. That way, you don’t have journal entries transferring from the local system to the remote system and back again.

Any environment requiring high system availability is a prime candidate for the remote journal function. For example, in Las Vegas, many hotels and casinos use the AS/400 to run all aspects of their businesses. They cannot afford to have downtime or system failure of any kind. For this reason, they implement complex backup, recovery, and disaster plans to ensure that they are up and running all the time.

With the remote journal function used to create a hot-backup site, some of the complexity of data replication and system interchangeability goes away. The synchronous transfer of journal entries greatly diminishes the chance of losing data. Moving the receiving of journal entries to the remote systems decreases some of the workload on the primary system, while transferring the rest of the load from the application layer to the licensed internal code layer reduces the CPU cycles used for the journal process even more. In addition, the ability to create remote journals on the primary system and create local journals on the remote systems allows the ability to easily swap back to the primary system once it’s ready to assume its duties again.

You now can see how the improvements to the journal process provided by the remote journal function can increase the performance and reliability of your hot-backup site while reducing CPU cycles on the primary system. If these benefits sound appealing, you

may want to investigate your environment to see if it is ready for the remote journal function.

References AS/400 System API Reference V4R2 (SC41-5801-01, QB3AMA01) OS/400 Backup and Recovery V4R2 (SC41-5304-01, QB3ALE01) OS/400 CL Reference V4R3 (SC41-5722-02, QBAUP02) OS/400 Journal and Commit APIs V4R3 (SC41-5882-02, QB3APE02)

Journal Monitor Job

RCVJRNE exit program receives entries and sends to backup system Journal Receivers

Local AS/400 (Primary) Remote AS/400 (Backup)

Figure 1: Example of data replication to a remote system prior to V4R2

Data Comm

Machine Interface (MI)

Application Programs

Add, update, and delete operations

Database Files

Target job

Receives entries from primary system and stores them temporarily

Entries stored

Storage object

(File, data queue, data space, etc.)

Apply job

Retrieves entries and applies them to database files

Database add, update, and delete operations

Database Files

RCVJRNE requests Entries retrieved

Journal entries returned

Journaling

Local AS/400 (Primary) Remote AS/400 (Backup)

Figure 2: Example of data replication to a remote system using the remote journal function

Receiver

RCVLIB1/RCV1 File 1 File 2 File 3

Remote Journal

JRNLIB2/JRN

Application Programs

Machine Interface (MI)

Add, update, and delete operations Entries retrieved

Journaling Data

Comm

Application Programs

Receive and Apply Job

RCVJRNE exit program receives entries and applies them to database files

Receive and Apply Job

RCVJRNE exit program receives entries and applies them to database files

Database add, update, and delete operations

Files Database Files

Database Files

Journal Receivers Journal Receivers

Journal Receivers

Database

Local AS/400 (Primary)

1) Files are journaled on the primary system
4) In the event of a primary system failure, the backup system takes over as primary. This remote journal will be used to replay the changes back to the original database.

Remote AS/400 (Backup)

Figure 3: Example of complete hot-backup environment using the remote journal function

Transport Transport

Receiver

RCVLIB2/RCV2 File 1 File 2 File 3

Local Journal

JRNLIB1/JRN

Receiver

RCVLIB2/RCV2

Local Journal

JRNLIB1/JRN Receiver

RCVLIB2/RCV2 Remote Journal

JRNLIB2/JRN Receiver

RCVLIB1/RCV2

Local Journal

JRNLIB1/JRN

2) Journal entries from the remote journal are applied to the replica database on the backup system
3) Replica database files are journaled on the backup system

This path is only active after a primary system failure during which the backup system took over as primary, and the primary system is back up again.