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

87 lines
8.6 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="concept" />
<meta name="DC.Title" content="Synchronous and asynchronous delivery mode for remote journals" />
<meta name="abstract" content="The terms asynchronously maintained and synchronously maintained both describe a remote journal function delivery mode for journal entry replication." />
<meta name="description" content="The terms asynchronously maintained and synchronously maintained both describe a remote journal function delivery mode for journal entry replication." />
<meta name="DC.Relation" scheme="URI" content="rzakiplanrjrn.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakiaddprocess.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakiretrrievecommit.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakiactiverep.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakiconfirm.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="rzakisynch" />
<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>Synchronous and asynchronous delivery mode for remote journals</title>
</head>
<body id="rzakisynch"><a name="rzakisynch"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Synchronous and asynchronous delivery mode for remote journals</h1>
<div><p>The terms <strong>asynchronously maintained</strong> and <strong>synchronously maintained</strong> both describe a remote journal function delivery mode for journal entry replication.</p>
<p>If a journal is asynchronously maintained, control is returned to the application generating the journal entry on the source system without waiting for the journal entry to be replicated to the remote
journal. An asynchronously maintained remote journal might lag several journal entries behind the total number of journal entries in the journal on the source system. If a journal is synchronously maintained,
control is not returned to the application generating the journal entry on the local system until the journal entry is replicated to the remote journal.</p>
<div class="section"><h4 class="sectiontitle">Synchronous delivery mode</h4><p><strong>Synchronous</strong> delivery means that the journal entry is replicated to the target system concurrently with the entry being written to the local receiver
on the source system. The entry is known on the target system, in main storage, prior to returning control to the user application that deposited the journal entry on the source system. Therefore, the target
system knows of all journal entries as they are being made in real-time on the source system. Using this mode allows for recovery without losing journal entries on the target system if the source system
fails. Providing journal entries synchronously to a target system will have some affect to the journaling throughput on the local system.</p>
<p>Synchronous delivery mode is only supported when a remote
journal is associated with a local journal.</p>
<p>There are certain circumstances, when using synchronous mode, when some journal entries are not immediately sent to the target system. These entries are
either not necessary for recovery or the user did not specify that they be forced to disk. Journal entries are sent to the remote journal at the same time that they are forced to disk for the source journal.
Since these entries are not forced to disk at deposit time, they are not sent to the remote system.</p>
<ul><li>Some entries that are not required for data recovery might not be immediately sent to the target system. For example, journal entries for a file close (journal code 'F', entry type 'CL') or a stream
file open, (journal code 'B', entry type 'OF').</li>
<li>User-generated journal entries that use the Send Journal Entry (SNDJRNE) command or the Send Journal Entry API (QJOSJRNE) might not be sent to the target system. If either you, or your application,
do not request to force these user-generated entries they will only be replicated to the remote journal when some other action forces them. Therefore, periodically specify FORCE(*YES) when using the send
journal entry functions.</li>
<li>Journal entries that are associated with commitment control transactions might not be immediately sent to the remote system. These entries will be retrievable after the following journal entries have
been deposited into the source journal: <ul><li>Journal code 'C', journal entry type 'CM' (Commit)</li>
<li>Journal code 'C', journal entry type 'RB' (Rollback)</li>
</ul>
</li>
<li>See Remote journal considerations for retrieving journal entries when using commitment control for more information. <p>When journal caching is being used (JRNCACHE(*YES) on the CHGJRN
command), entries that exist only in the cache are not available on the target system. With journal caching, entries are not sent to the target system until they are written from the cache to disk on the
source system.</p>
</li>
<li>If the local journal is using journal caching, then journal entries will be bundled up before they are sent to the target.</li>
</ul>
</div>
<div class="section"><h4 class="sectiontitle">Asynchronous delivery mode</h4><p>Replicating a journal entry <strong>asynchronously</strong> means that the journal entry is replicated to the target system after control is returned to the application
depositing the journal entry on the source system. Using this mode allows for recovery that might lose some journal entries if the source system fails. However, this mode has less affect to the journal
throughput on the local system in comparison with the synchronous mode.</p>
<p><strong>Journal entry latency</strong> might occur when remote journals are asynchronously maintained. Journal entry latency is the difference
between the journal entries that exist in the remote journal on the target system from those residing in the journal on the source system. From a recovery standpoint, the source system might be some number
of journal entries ahead of what journal entries are known on the target system.</p>
</div>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakiplanrjrn.htm" title="The following topics provide detailed information for planning to set up remote journals:">Plan for remote journals</a></div>
</div>
<div class="relconcepts"><strong>Related concepts</strong><br />
<div><a href="rzakiaddprocess.htm" title="Adding a remote journal creates a remote journal on a target system or independent disk pool and associates that remote journal with the journal on the source system. This occurs if this is the first time the remote journal is being established for a journal. The journal on the source system can be either a local or remote journal.">Add remote journal process</a></div>
<div><a href="rzakiretrrievecommit.htm" title="Special performance related processing is done by the system when depositing entries that are associated with commitment control transactions to a local journal.">Remote journal considerations for retrieving journal entries when using commitment control</a></div>
<div><a href="rzakiconfirm.htm" title="For a local journal, all entries are confirmed entries. There is no concept of unconfirmed entries.">Confirmed and unconfirmed journal entries</a></div>
</div>
<div class="reltasks"><strong>Related tasks</strong><br />
<div><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>
</body>
</html>