ibm-information-center/dist/eclipse/plugins/i5OS.ic.apis_5.4.0.1/jc3.htm

172 lines
7.8 KiB
HTML

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Copyright" content="Copyright (c) 2006 by IBM Corporation">
<title>Journaling for Journal and Commit APIs</title>
<!-- Begin Header Records ========================================== -->
<!-- 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. -->
<!-- Change History: -->
<!-- YYMMDD USERID Change description -->
<!-- 050516 Levering:(changed sjrne API info DCR 99779) -->
<!-- JC1 SCRIPT A converted by B2H R4.1 (346) (CMS) by V2KEA304 -->
<!-- at RCHVMW2 on 17 Feb 1999 at 11:05:09 -->
<!-- File cleanup completed by Janet Brauckman, Sept 2001 -->
<link rel="stylesheet" type="text/css" href="../rzahg/ic.css">
</head>
<body>
<!--End Header Records -->
<!-- Java sync-link -->
<script type="text/javascript" language="Javascript" src="../rzahg/synch.js">
</script>
<h2>Journaling for Journal and Commit APIs</h2>
<p>Journaling allows you to specify database files or access paths you want to
protect for recovery purposes, or allows you to provide an audit trail for
changes to database files. In addition, journaling allows you to provide an
audit or activity trail for other objects or activities either by system
activities, such as security auditing, or by user activities, such as the Send
Journal Entry (SNDJRNE) command or QJOSJRNE API.</p>
<p>Two objects are associated with journaling: journals and journal
receivers.</p>
<p>A <strong>journal</strong> is the object that identifies:</p>
<ul>
<li>The journaled objects, if any</li>
<li>The current journal receivers</li>
<li>Any journal receivers on the system that have been, or are, associated with
the journal</li>
<li>Any remote journals that are associated with the journal</li>
</ul>
<p>A <strong>local journal</strong> is the journal that is the initiator of the
original journal deposit. Objects can be journaled to a local journal, and
journal entries are deposited into a local journal due to changes made to the
journaled objects, or because journal entries were sent to the local
journal.</p>
<p>A <strong>remote journal</strong> is a journal that has been associated with
another journal via the Add Remote Journal (QjoAddRemoteJournal) API. Objects
cannot be journaled to a remote journal nor can journal entries be directly
deposited into a remote journal. Instead, a remote journal has journal entries
replicated to it from its upstream source journal. The upstream source journal
can be either a local journal or a remote journal.</p>
<p>A <strong>journal receiver</strong> is the object that contains journal
entries, and can be associated with either a local or remote journal. For a
journal receiver attached to a local journal, journal entries are directly
deposited into the journal receiver. For a journal receiver attached to a
remote journal, journal entries are replicated into the journal receiver from
the source journal receiver associated with the upstream source journal.</p>
<p>Journal entries contain information such as:</p>
<ul>
<li>The job name, program name, and user that caused the journal entry to be
deposited into the local journal.</li>
<li>The date and time the journal entry was deposited into the local
journal.</li>
<li>Journal code.</li>
<li>Entry type.</li>
<li>Information that is unique to each journal entry type, called entry
specific data.</li>
</ul>
<p>For example, the entry specific data associated with the put of a record to
a physical file member (journal code R, entry type PT) contains an image of the
actual record that was put. The rest of the journal entry information helps
determine at what time, by what user the entry was sent, and other details. If
a user sends information to the journal using the SNDJRNE command or QJOSJRNE
API (journal code U, entry type is defined at send time by the user), the entry
specific data contains what was specified at that time.</p>
<p>When journaling is started for an object, a unique identifier called a
<strong>journal identifier (JID)</strong> is assigned. This identifier remains
the same even if the object is renamed or moved. The journal identifier is
associated with every journal entry that is associated with a specific
journaled object.</p>
<p>The JID allows the journal facility to associate the current name of an
object with the journal entries, even if the entry was made before the object
was renamed. To determine what name is currently associated with a particular
JID, use the QJORJIDI API. See <a href="QJORJIDI.htm">Retrieve Journal
Identifier Information</a> (QJORJIDI) API for more information on the JID and
this API.</p>
<p>The SNDJRNE command and the QJOSJRNE API provide similar function, the
sending of a journal entry at a user's request. See <a href="QJOSJRNE.htm">Send
Journal Entry</a> (QJOSJRNE) API for more information on this API. The major
differences between the API and command are:</p>
<ul>
<li>The API allows up to
<img src="delta.gif" alt="Start of change">
15761440
<img src="deltaend.gif" alt="End of change">
bytes of entry specific data, as opposed to 3000
bytes with the command.</li>
<li>The API allows the association of the current commit cycle identifier with
the journal entry. This support can be used with the QTNADDCR API. For more
information see <a href="QTNADDCR.htm">Add Commitment Resource</a> (QTNADDCR)
API.</li>
<li><img src="delta.gif" alt="Start of change">The API
can optionally return the journal sequence number and journal
receiver information for the entry that was deposited.
<img src="deltaend.gif" alt="End of change"></li>
</ul>
<p>The QjoAddRemoteJournal, QjoRemoveRemoteJournal, and QjoChangeJournalState
APIs allow you to establish, manipulate, and maintain a remote journal
environment. A remote journal environment allows you to replicate journal
entries from one system to another via communications methods such as TCP/IP,
SNA, and OptiConnect for i5/OS<SUP>(TM)</SUP>. This support can be used to help replicate
data from one iSeries<SUP>(TM)</SUP> server to one or more additional iSeries servers. Using application
programs, the replicated entries can then be used to maintain a backup, or
replica of the primary systems data. If desired, the backup data can be used in
the event the primary system fails. See <a href="QJOADDRJ.htm">Add Remote
Journal</a> (QjoAddRemoteJournal) API, <a href="QJOCHGST.htm">Change Journal
State</a> (QjoChangeJournalState) API, and <a href="QJORMVRJ.htm">Remove Remote
Journal</a> (QjoRemoveRemoteJournal) API for more information on these APIs.
The Add Remote Journal (ADDRMTJRN), Change Remote Journal
(CHGRMTJRN), and Remove Remote Journal (RMVRMTJRN) commands provide support
similar to these APIs.</p>
<p>The QjoRetrieveJournalInformation and QjoRtvJrnReceiverInformation APIs
provide information that is similar to the Work with Journal Attributes
(WRKJRNA) and Display Journal Receiver Attributes (DSPJRNCVA) commands,
respectively. See <a href="QJORJRNI.htm">Retrieve Journal Information</a>
(QjoRetrieveJournalInformation) API and <a href="QJORRCVI.htm">Retrieve Journal
Receiver Information</a> (QjoRtvJrnReceiverInformation) API for more
information on these APIs.</p>
<hr>
<center>
<table cellpadding="2" cellspacing="2">
<tr align="center">
<td valign="middle" align="center"><a href="#Top_Of_Page">Top</a> | <a href=
"jc1.htm">Journal and Commit APIs</a> | <a href="aplist.htm">APIs by
category</a></td>
</tr>
</table>
</center>
</body>
</html>