ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzaki_5.4.0.1/rzakicatchup.htm

139 lines
9.7 KiB
HTML
Raw Normal View History

2024-04-02 14:02:31 +00:00
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en-us" xml:lang="en-us">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="security" content="public" />
<meta name="Robots" content="index,follow" />
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
<meta name="DC.Type" content="task" />
<meta name="DC.Title" content="Catch-up phase for remote journals" />
<meta name="abstract" content="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." />
<meta name="description" content="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." />
<meta name="DC.Relation" scheme="URI" content="rzakiactiverep.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakisrcjrnrcv.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakijrnrcvchn.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakiinactivate.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakirerrmessage.htm" />
<meta name="copyright" content="(C) Copyright IBM Corporation 2004, 2006" />
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2004, 2006" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="rzakicatchup" />
<meta name="DC.Language" content="en-us" />
<!-- All rights reserved. Licensed Materials Property of IBM -->
<!-- US Government Users Restricted Rights -->
<!-- Use, duplication or disclosure restricted by -->
<!-- GSA ADP Schedule Contract with IBM Corp. -->
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
<link rel="stylesheet" type="text/css" href="./ic.css" />
<title>Catch-up phase for remote journals</title>
</head>
<body id="rzakicatchup"><a name="rzakicatchup"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Catch-up phase for remote journals</h1>
<div><p><span class="uicontrol">Catch-up</span> refers to the process of replicating
journal entries that existed in the journal receivers of the source journal
before the remote journal was activated.</p>
<div class="section"><p>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.</p>
<p>Catch-up phase is initiated after the
following actions occur:</p>
<ul><li>A request has been issued on the source system to activate a remote journal.</li>
<li>The system has determined which journal receivers and journal entries
to replicate to the target system.</li>
</ul>
<p>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:</p>
<ul><li>Those journal entries that already exist in the journal on the source
system.</li>
<li>Those journal entries that are deposited or replicated to the source journal
during the catch-up processing.</li>
</ul>
<p>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.</p>
<p>The
catch-up phase is the most efficient method of transporting journal entries
to a remote journal in bulk.</p>
<p>The following is a high-level overview
of the catch-up phase and related processing:</p>
</div>
<ol><li class="stepexpand"><span>The starting point in the journal receiver on the source system
is determined.</span></li>
<li class="stepexpand" id="rzakicatchup__steprec"><a name="rzakicatchup__steprec"><!-- --></a><span>If necessary, the system creates a receiver on the
target system and attaches it to the remote journal.</span></li>
<li class="stepexpand"><span>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.</span></li>
<li class="stepexpand"><span>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.</span> <p>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.</p>
</li>
<li class="stepexpand"><span>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:</span> <ul><li>If there is a next receiver within the source journal's chain of receivers,
go back to step <a href="#rzakicatchup__steprec">2</a>. The
system replicates journal entries by starting with the first entry in the
next receiver. <p>For more information about receiver directory chains, see
Keep track of journal receiver chains.</p>
</li>
<li>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.</li>
</ul>
</li>
</ol>
<div class="section"><p>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. </p>
<p>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.</p>
<p>See the following links for more information about
inactivating remote journals possible failure conditions.</p>
</div>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakiactiverep.htm" title="In order to activate the replication of journal entries to a given remote journal, the following must be true:">Activate the replication of journal entries to a remote journal</a></div>
</div>
<div class="relconcepts"><strong>Related concepts</strong><br />
<div><a href="rzakisrcjrnrcv.htm" title="When you specify a journal receiver for remote journaling, you are specifying where the replication of journal entries will start.">Where the replication of journal entries start</a></div>
<div><a href="rzakijrnrcvchn.htm" title="Journal receivers that are associated with a journal (that is presently or previously attached to the journal) are linked in one or more receiver chains. Each journal receiver, except the first one, has a previous receiver that was detached when the current receiver was attached. Each journal receiver, except the one that is currently attached, also has a next receiver.">Keep track of journal receiver chains</a></div>
<div><a href="rzakirerrmessage.htm" title="Several different error conditions can occur when the remote journal function is active.">Work with remote journal error messages</a></div>
</div>
<div class="reltasks"><strong>Related tasks</strong><br />
<div><a href="rzakiinactivate.htm" title="When you end replication of journal entries to a remote journal, it is recommended that the replication of entries be ended from the source system whenever possible, rather than from the target system. Usually, ending replication from the target system for a remote journal is only necessary when the source system has failed, and the system has not ended the remote journal function.">Inactivate the replication of journal entries to a remote journal</a></div>
</div>
</div>
</body>
</html>