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

84 lines
8.1 KiB
HTML
Raw Permalink 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="Confirmed and unconfirmed journal entries" />
<meta name="abstract" content="For a local journal, all entries are confirmed entries. There is no concept of unconfirmed entries." />
<meta name="description" content="For a local journal, all entries are confirmed entries. There is no concept of unconfirmed entries." />
<meta name="DC.Relation" scheme="URI" content="rzakirgetinfo.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakistate.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakisynch.htm" />
<meta name="DC.Relation" scheme="URI" content="../apis/QJORJRNE.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakirecovery.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakirerrmessage.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="rzakiconfirm" />
<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>Confirmed and unconfirmed journal entries</title>
</head>
<body id="rzakiconfirm"><a name="rzakiconfirm"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Confirmed and unconfirmed journal entries</h1>
<div><p>For a local journal, all entries are confirmed entries. There is no concept of unconfirmed entries.</p>
<p>For a remote journal that is maintained asynchronously, all entries are confirmed entries. For a remote journal that is maintained synchronously, there are both confirmed and unconfirmed entries. Unconfirmed
entries will only become important if you are using the remote journal support for a hot-backup or data replication environment, and the source system has a failure such that the target system will take
over processing.</p>
<p><span class="uicontrol">Confirmed journal entries</span> are journal entries replicated to a target system, and the state of the I/O to auxiliary storage for the same journal entries on the primary system is
known to have completed.</p>
<p><span class="uicontrol">Unconfirmed journal entries</span> are entries replicated to a target system, but the state of the I/O to auxiliary storage for the same journal entries on the primary system is not known.
Unconfirmed entries only pertain to remote journals that are maintained synchronously. The remote I/O to the remote journal is overlapped with the local I/O to the local journal for better performance.
Such journal entries on the target system are held in the data portion of the journal receiver. However, the journal entries are not officially included with the remainder of the journal entries until the
confirmation of the I/O for the same entries is received from the primary system. For performance reasons, confirmation of these entries is not typically sent to the target system until some later delivery
of journal data to the target system.</p>
<p>While the journal entries are unconfirmed on a target system, the entries typically cannot be retrieved from the remote journal. You can retrieve the journal entries by using the INCENT(*ALL) parameter
on the following commands:</p>
<ul><li>Display Journal (DSPJRN)</li>
<li>Retrieve Journal Entry (RTVJRNE)</li>
<li>Receive Journal Entry (RCVJRNE)</li>
</ul>
<p>You can also retrieve the journal entries by specifying *ALL for the include entries key for the Retrieve Journal Entries (QjoRetrieveJournalEntries) API. The INCENT(*ALL) parameter, or include entries
key specification of *ALL, requests that all confirmed and unconfirmed entries are included. This means that for synchronous remote journal function, the last few journal entries are not immediately retrievable
from the remote journal by using the default command invocations. This is true even though all journal entries physically reside in both the local journal and the remote journal. This is done so that application
programs do not make decisions on the target system by using journal entries that may not end up being deposited into the local journal. This is because those journal entries would not cause a change to
the original data.</p>
<p>With respect to a hot-backup application apply, in most circumstances only the confirmed journal entries in the remote journal are of interest. In the data replication environment, a hot-backup application
apply would probably never want to apply any unconfirmed journal changes. This is because any subsequent activation of the remote journal will ensure that the journal entries in the remote journal will
match the journal entries in the source journal. However, as described in Scenario: Recovery for remote journaling, knowledge of the unconfirmed journal entries is essential during the switch-over and switch-back
processing for a hot-backup environment.</p>
<p>When a remote journal is inactivated, all unconfirmed entries are removed from the remote journal. It is important that those entries are retrieved prior to the remote journal being inactivated, if those
entries are desired for additional processing on the backup system. The message that is sent to the journal message queue when the remote journal is inactivated by the system will indicate if the remote
journal has any unconfirmed journal entries. See Work with remote journal error messages.</p>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakirgetinfo.htm" title="Working with the journal entries in a remote journal is essentially the same as working with the journal entries in a local journal.">Get information about remote journal entries</a></div>
</div>
<div class="relconcepts"><strong>Related concepts</strong><br />
<div><a href="rzakistate.htm" title="The journal state describes an attribute for a journal. The attribute value can be *ACTIVE, *INACTIVE (remote journal only), or *STANDBY (local journal only). For a local journal, *ACTIVE indicates that journal entries are currently allowed to be deposited into the journal. *STANDBY indicates that most journal entries are not deposited.">Journal state and delivery mode</a></div>
<div><a href="rzakisynch.htm" title="The terms asynchronously maintained and synchronously maintained both describe a remote journal function delivery mode for journal entry replication.">Synchronous and asynchronous delivery mode for remote journals</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="relref"><strong>Related reference</strong><br />
<div><a href="../apis/QJORJRNE.htm">Retrieve Journal Entries (QjoRetrieveJournalEntries) API</a></div>
</div>
<div class="relinfo"><strong>Related information</strong><br />
<div><a href="rzakirecovery.htm" title="This scenario describes a hot-backup environment in which the local system, JKLINT fails. It is necessary to restore the local system, and synchronize it with the remote system, JKLINT2.">Scenario: Recovery for remote journaling</a></div>
</div>
</div>
</body>
</html>