105 lines
6.4 KiB
HTML
105 lines
6.4 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="task" />
|
||
|
<meta name="DC.Title" content="Minimize locks" />
|
||
|
<meta name="abstract" content="A typical way to minimize record locks is to release the record lock. (This technique does not work if LCKLVL(*ALL) has been specified.)" />
|
||
|
<meta name="description" content="A typical way to minimize record locks is to release the record lock. (This technique does not work if LCKLVL(*ALL) has been specified.)" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rzakjoptimize.htm" />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rzakjdeadlocks.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="rzakjminimizelock" />
|
||
|
<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>Minimize locks</title>
|
||
|
</head>
|
||
|
<body id="rzakjminimizelock"><a name="rzakjminimizelock"><!-- --></a>
|
||
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
<h1 class="topictitle1">Minimize locks</h1>
|
||
|
<div><p>A typical way to minimize record locks is to release the record
|
||
|
lock. (This technique does not work if LCKLVL(*ALL) has been specified.)</p>
|
||
|
<div class="section"><p>Here is an example of minimize record by releasing
|
||
|
the record lock. A single file maintenance application typically follows these
|
||
|
steps:</p>
|
||
|
<ol><li>Display a prompt for a record identification to be changed.</li>
|
||
|
<li>Retrieve the requested record.</li>
|
||
|
<li>Display the record.</li>
|
||
|
<li>Allow the workstation user to make the change.</li>
|
||
|
<li>Update the record.</li>
|
||
|
</ol>
|
||
|
<p>In most cases, the record is locked from the access of the requested
|
||
|
record through the update. The record wait time might be exceeded for another
|
||
|
job that is waiting for the record. To avoid locking a record while the workstation
|
||
|
user is considering a change, release the record after it is retrieved from
|
||
|
the database (before the record display appears). You then need to access
|
||
|
the record again before updating. If the record was changed between the time
|
||
|
it was released and the time it was accessed again, you must inform the workstation
|
||
|
user. The program can determine if the record was changed by saving one or
|
||
|
more fields of the original record and comparing them to the fields in the
|
||
|
same record after it is retrieved as follows:</p>
|
||
|
<ul><li>Use an update count field in the record and add 1 to the field just before
|
||
|
an update. The program saves the original value and compares it to the value
|
||
|
in the field when the record is retrieved again. If a change has occurred,
|
||
|
the workstation user is informed and the record appears again. The update
|
||
|
count field is changed only if an update occurs. The record is released while
|
||
|
the workstation user is considering a change. If you use this technique, you
|
||
|
must use it in every program that updates the file.</li>
|
||
|
<li>Save the contents of the entire data record and compare it to the record
|
||
|
the next time it is retrieved.</li>
|
||
|
</ul>
|
||
|
<p>In both cases above, the sequence of operations prevents the simple
|
||
|
use of externally described data in RPG where the same field names are used
|
||
|
in the master record and in the display file. Using the same field names (in
|
||
|
RPG) does not work because the workstation user's changes are overlaid when
|
||
|
the record is retrieved again.You can solve this problem by moving the record
|
||
|
data to a data structure. Or, if you use the DDS keyword <span class="keyword">RTNDTA</span>,
|
||
|
you can continue to use externally described data. The <span class="keyword">RTNDTA</span> keyword
|
||
|
allows your program to reread data on the display without the operating system
|
||
|
having to move data from the display to the program. This allows the program
|
||
|
to do as follows:</p>
|
||
|
</div>
|
||
|
<ol><li><span>Prompt for the record identification.</span></li>
|
||
|
<li><span>Retrieve the requested record from the database.</span></li>
|
||
|
<li><span>Release the record.</span></li>
|
||
|
<li><span>Save the field or fields used to determine if the record was changed.</span></li>
|
||
|
<li><span>Display the record and wait for the workstation user to respond.</span></li>
|
||
|
</ol>
|
||
|
<div class="section"><p>If the workstation user changes the record on the display, the
|
||
|
program uses the following sequence:</p>
|
||
|
<ol><li>Retrieve the record from the database again.</li>
|
||
|
<li>Compare the saved fields to determine if the database record has been
|
||
|
changed. If it has been changed, the program releases the record and sends
|
||
|
a message when the record appears.</li>
|
||
|
<li>Retrieve the record from the display by running a read operation with
|
||
|
the <span class="keyword">RTNDTA</span> keyword and updates the record in the database
|
||
|
record.</li>
|
||
|
<li>Proceed to the next logical prompt because there are no additional
|
||
|
records to be released if the workstation user cancels the request.</li>
|
||
|
</ol>
|
||
|
<p>LCKLVL(*CHG) and LCKLVL(*CS) work in this situation. If LCKLVL(*ALL)
|
||
|
is used, you must release the record lock by using a commit or rollback operation.</p>
|
||
|
</div>
|
||
|
</div>
|
||
|
<div>
|
||
|
<div class="familylinks">
|
||
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakjoptimize.htm" title="Using commitment control requires resources that can affect system performance. Several factors affect system performance regarding commitment control.">Optimize performance for commitment control</a></div>
|
||
|
</div>
|
||
|
<div class="reltasks"><strong>Related tasks</strong><br />
|
||
|
<div><a href="rzakjdeadlocks.htm" title="Find deadlock conditions by using these instructions.">Detect deadlocks</a></div>
|
||
|
</div>
|
||
|
</div>
|
||
|
</body>
|
||
|
</html>
|