Catch-up phase for remote journals

Catch-up refers to the process of replicating journal entries that existed in the journal receivers of the source journal before the remote journal was activated.

The catch-up phase is the most efficient method of replicating journal entries to a remote journal. Control does not return to the requester of the activation of the remote journal until this catch-up processing has completed. You will want to consider this when deciding the starting point for journal entry replication.

Catch-up phase is initiated after the following actions occur:

A request has been issued on the source system to activate a remote journal.
The system has determined which journal receivers and journal entries to replicate to the target system.

There is a difference between the catch-up phase processing and the run-time synchronous or asynchronous processing. Catch-up processing replicates the following to the target system:

Those journal entries that already exist in the journal on the source system.
Those journal entries that are deposited or replicated to the source journal during the catch-up processing.

Run-time synchronous or asynchronous processing occurs as part of the actual deposit or replication of journal entries into the currently attached receiver on the source system. While in the catch-up phase, the journal delivery mode will be either asynchronous pending (*ASYNCPEND) or synchronous pending (*SYNCPEND), depending on the delivery mode that was specified.

The catch-up phase is the most efficient method of transporting journal entries to a remote journal in bulk.

The following is a high-level overview of the catch-up phase and related processing:

The starting point in the journal receiver on the source system is determined.
If necessary, the system creates a receiver on the target system and attaches it to the remote journal.
The system replicates or completes replication for all of the journal entries that are contained in the receiver on the source system to the corresponding receiver on the target system.
If the receiver on the source system is the currently attached receiver, the system completes the catch-up processing by transitioning into synchronous or asynchronous remote journal delivery mode. Catch-up phase is complete, and control returns to the requester of the remote journal activation.
The remote journal will now be maintained synchronously or asynchronously as additional journal entries are deposited, or replicated, into the attached receiver on the source system.
If the receiver on the source system is not the currently attached receiver for the journal on the source system, one of the following steps are performed:
- If there is a next receiver within the source journal's chain of receivers, go back to step 2. The system replicates journal entries by starting with the first entry in the next receiver.
  For more information about receiver directory chains, see Keep track of journal receiver chains.
- If there is no next receiver, (which indicates that a receiver chain break exists), the catch-up phase is complete. Processing does not transition into synchronous or asynchronous mode and the change journal state processing ends. A final escape message is sent indicating that processing has ended.

After the system transitions a given remote journal to either the synchronous or asynchronous remote journal delivery mode, the system continues to maintain that mode. This continues until the remote journal function is inactivated for that remote journal by using the Change Journal State (QjoChangeJournalState) API or Change Remote Journal (CHGRMTJRN) command, or a failure occurs.

The replication of journal entries to an individual remote journal is performed independently from the replication of journal entries to any other defined remote journal. This is important if a given target system fails or if communications to a target system fails from a particular source system. If either one occurs, the remote journal function will end to those affected remote journals that reside on that target system and are maintained from the source system. All other remote journals that are being maintained from the source system will continue to function normally. For example, a source journal could have two remote journals on two different systems. In this situation, if the replication of entries from the source journal to the second remote journal ended, the replication of entries from the source journal to the first remote journal would not necessarily end. If a given remote journal has any type of failure, the system ends the remote journal function. Appropriate messages are signaled to either system or both systems involved, but the remote journal function for other remote journals would not be affected. Likewise, the communications line speed for a given asynchronously maintained remote journal will not affect the speed for another asynchronously maintained remote journal using a different physical transport.

See the following links for more information about inactivating remote journals possible failure conditions.