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

115 lines
7.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="concept" />
<meta name="DC.Title" content="Commitment control during abnormal system or job end" />
<meta name="abstract" content="This topic applies only to commitment definitions with job-scoped locks." />
<meta name="description" content="This topic applies only to commitment definitions with job-scoped locks." />
<meta name="DC.Relation" scheme="URI" content="rzakjsysteminit.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakjimprollcmit.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakjupdatenotify.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="rzakjabmnlend" />
<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 during abnormal system or job end</title>
</head>
<body id="rzakjabmnlend"><a name="rzakjabmnlend"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Commitment control during abnormal system or job end</h1>
<div><p>This topic applies only to commitment definitions with job-scoped
locks.</p>
<p>The system ends all commitment definitions for a job when the job ends
abnormally. These commitment definitions are ended during the end job processing.
If the system ends abnormally, the system ends all commitment definitions
that were started and being used by all active jobs at the time of the abnormal
system end. These commitment definitions are ended as part of the database
recovery processing that is performed during the next IPL after the abnormal
system end.</p>
<div class="attention"><span class="attentiontitle">Attention:</span> The recovery for commitment definitions refers to an
abnormal end for the system or a job due to a power failure, a hardware failure,
or a failure in the operating system or licensed internal code. You must not
use the End Job Abnormal (ENDJOBABN) command to force a job to end abnormally.
The abnormal end can result in pending changes for active transactions for
the job you are ending to be partially committed or rolled back. The next
IPL might attempt recovery for any partial transactions for the job ended
with the ENDJOBABN command.<p>The outcome of commitment control recovery that
the system performs during an IPL for a job that you end with the ENDJOBABN
command is uncertain. It is because all locks for commitment resources are
released when the job is ended abnormally. Any pending changes due to partial
transactions are made available to other jobs. These pending changes can then
cause other application programs to make additional erroneous changes to the
database. Likewise, any ensuing IPL recovery that is performed later can adversely
affect the changes made by applications after the job was ended abnormally.
For example, an SQL table might be dropped during IPL recovery as the rollback
action for a pending create table. However, other applications might have
already inserted several rows into the table after the job was ended abnormally.</p>
</div>
<p>The system performs as follows for commitment definitions
being ended during an abnormal job end or during the next IPL after an abnormal
system end:</p>
<ul><li>Before ending a commitment definition, the system performs an implicit
rollback operation if the commitment definition has pending changes, unless
processing for the commitment definition was interrupted in the middle of
a commit operation. If ended in the middle of a commit operation, the transaction might
be rolled back, resynchronized, or committed, depending on its state. The
processing to perform the implicit rollback operation or to complete the commit
operation includes calling the API commit and rollback exit program for each
API commitment resource associated with the commitment definition. After the
API commit and rollback exit program is called, the system automatically removes
the API commitment resource. <div class="attention"><span class="attentiontitle">Attention:</span> Ending the job while a
transaction is in doubt (transaction state is LAP or PRP) can cause inconsistencies
in the database (changes might be committed on one or more systems and rolled
back on other systems). <ul><li>If the <var class="varname">Action if Endjob</var> commitment option is COMMIT,
changes on this system are committed if the job is ended, without regard to
whether changes on the other systems participating in the transaction are
committed or rolled back.</li>
<li>If the <var class="varname">Action if Endjob</var> commitment option is ROLLBACK,
changes on this system are rolled back if the job is ended, without regard
to whether changes on the other systems participating in the transaction are
committed or rolled back.</li>
<li>If the <var class="varname">Action if Endjob</var> commitment option is WAIT,
the job will not end until resynchronization completes to the system that
owns the commit or rollback decision. To make the job end before resynchronization
is complete, a heuristic decision must be made and resynchronization must
be canceled.</li>
</ul>
<p>Ending the job or system abnormally during a long-running rollback
is <strong>not</strong> recommended. This will cause another rollback to occur as the
job ends (or during the next IPL if the system is ended). The subsequent rollback
will repeat the work performed by the original rollback and take significantly
longer to run.</p>
</div>
</li>
<li>If a notify object is defined for the commitment definition, it might
be updated.</li>
</ul>
<p>If a process ends before commitment control is ended and protected conversations
are still active, the commitment definition might be required to commit or
roll back. The action is based on the State option and the Action if end job
option for the commitment definition.</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="rzakjimprollcmit.htm" title="In some instances a commit or rollback operation is initiated by the system for a commitment definition. These types of commit and rollback operations are known as implicit commit and rollback requests.">Implicit commit and rollback operations</a></div>
<div><a href="rzakjupdatenotify.htm" title="This topic lists the uncommitted changes for purposes of the notify object.">Updates to the notify object</a></div>
</div>
</div>
</body>
</html>