ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzakj_5.4.0.1/rzakjcommitrecov.htm

106 lines
7.2 KiB
HTML

<?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="Commitment control recovery during initial program load after abnormal end" />
<meta name="abstract" content="When you perform an initial program load (IPL) after your system ends abnormally, the system attempts to recover all the commitment definitions that were active when the system ended." />
<meta name="description" content="When you perform an initial program load (IPL) after your system ends abnormally, the system attempts to recover all the commitment definitions that were active when the system ended." />
<meta name="DC.Relation" scheme="URI" content="rzakjsysteminit.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakjstates.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="rzakjcommitrecov" />
<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>Commitment control recovery during initial program load after abnormal
end</title>
</head>
<body id="rzakjcommitrecov"><a name="rzakjcommitrecov"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Commitment control recovery during initial program load after abnormal
end</h1>
<div><p>When you perform an initial program load (IPL) after your system
ends abnormally, the system attempts to recover all the commitment definitions
that were active when the system ended.</p>
<p> Likewise, when you vary on an independent disk pool,
the system attempts to recover all the commitment definitions related to that
independent disk pool that were active when it was varied off or ended abnormally.</p>
<p>The recovery is performed by database server jobs that are started by the
system during IPL. Database server jobs are started by the system to handle
work that cannot or must not be performed by other jobs.</p>
<p>The database server jobs are named QDBSRVnn, where <samp class="codeph">nn</samp> is
a two-digit number. The number of database server jobs depends on the size
of your system. Likewise, the name of the database server job for an independent
disk pool or independent disk pool group is QDBSxxxVnn, where <samp class="codeph">xxx</samp> is
the independent disk pol number and <samp class="codeph">nn</samp> is a two-digit number.
For example, QDBS035V02 can be the name of the database server job for independent
disk pool 35.</p>
<p>States of the transaction for two-phase commitment control shows the actions
that the system takes, depending on the state of the transaction when the
failure occurred. For two states, PRP and LAP, the system action is in doubt.</p>
<div class="note"><span class="notetitle">Notes:</span> <ul><li>The following applies only to commitment definitions with job-scoped locks.</li>
<li>The transaction manager recovers commitment definitions associated with
XA transactions (whether their locks are job-scoped or transaction-scoped)
using XA APIs, not the resynchronization process described in this topic.</li>
</ul>
</div>
<p>The system cannot determine what to do until it performs resynchronization
with the other locations that participated in the transaction. This resynchronization
is performed after the IPL or vary on operation completes.</p>
<p>The system uses the database server jobs to perform this resynchronization.
The commitment definitions that need to be recovered are associated with the
database server jobs. During the IPL, the system acquires all record locks
and other object locks that were held by the commitment definition before
the system ended. These locks are necessary to protect the local commitment
resources until resynchronization is complete and the resources can be committed
or rolled back.</p>
<p>Messages are sent to the job logs of the database server jobs to indicate
the status of resynchronization with the remote locations. If the transaction
is in doubt, resynchronization must be completed with the location that owns
the decision for the transaction before local resources can be committed or
rolled back.</p>
<p>When the decision for a transaction is made, the following messages might
be sent to the job log for the database server job.</p>
<dl><dt class="dlterm">CPI8351</dt>
<dd>&amp;1 pending changes being rolled back</dd>
<dt class="dlterm">CPC8355</dt>
<dd>Post-IPL recovery of commitment definition &amp;8 for job &amp;19/&amp;18/&amp;17
completed.</dd>
<dt class="dlterm">CPD835F</dt>
<dd>IPL recovery of commitment definition &amp;8 for job &amp;19/&amp;18/&amp;17
failed.</dd>
</dl>
<p>Other messages related to the recovery can also be sent. These messages
are sent to the history (QHST) log. If errors occur, messages are also sent
to the QSYSOPR message queue.</p>
<p>You can determine the progress of the recovery by using iSeries™ Navigator,
by displaying the job log for the database server job, or by using the Work
with Commitment Definitions (WRKCMTDFN) command. Although iSeries Navigator
and the Work with Commitment Definitions display allow you to force the system
to commit or roll back, you must use this only as a last resort. If you anticipate
that all of the locations that participated in the transaction will eventually
be returned to operation, you must allow the systems to resynchronize themselves.
This ensures the integrity of your databases.</p>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakjsysteminit.htm" title="The system can end commitment control, or perform an implicit commit or rollback operation. Sometimes the system-initiated end of commitment control is normal. Other times, commitment control ends with an abnormal system or job end.">System-initiated end of commitment control</a></div>
</div>
<div class="relconcepts"><strong>Related concepts</strong><br />
<div><a href="rzakjstates.htm" title="A commitment definition is established at each location that is part of the transaction program network. For each commitment definition, the system keeps track of the state of its current transaction and previous transaction.">States of the transaction for two-phase commitment control</a></div>
</div>
</div>
</body>
</html>