friedkiwi/ibm-information-center
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
8826eae394
ibm-information-center/dist/eclipse/plugins/i5OS.ic.dbp_5.4.0.1/rbafofifoo.htm

258 lines
16 KiB
HTML
Raw Normal View History

Add readme and dist folders
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="Arrange duplicate keys" />
<meta name="abstract" content="If you do not specify the UNIQUE keyword in data description specifications (DDS), you can specify how the system stores records with duplicate key values, if duplicate key values occur." />
<meta name="description" content="If you do not specify the UNIQUE keyword in data description specifications (DDS), you can specify how the system stores records with duplicate key values, if duplicate key values occur." />
<meta name="DC.subject" content="duplicate key field, arranging, key field, preventing duplicate, LIFO (Last-In First-Out) keyword, Last-In First-Out (LIFO) keyword, keyword, DDS, LIFO (Last-In First-Out)" />
<meta name="keywords" content="duplicate key field, arranging, key field, preventing duplicate, LIFO (Last-In First-Out) keyword, Last-In First-Out (LIFO) keyword, keyword, DDS, LIFO (Last-In First-Out)" />
<meta name="DC.Relation" scheme="URI" content="rbafoksapa.htm" />
<meta name="DC.Relation" scheme="URI" content="rbafoshrap.htm" />
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1998, 2006" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="rbafofifoo" />
<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>Arrange duplicate keys</title>
</head>
<body id="rbafofifoo"><a name="rbafofifoo"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Arrange duplicate keys</h1>
<div><p>If you do not specify the UNIQUE keyword in data description specifications
(DDS), you can specify how the system stores records with duplicate key values,
if duplicate key values occur. </p>
<div class="p">You specify that records with duplicate key values are stored in the access
path in one of the following ways: <ul><li>Last-in-first-out (LIFO). When the LIFO keyword is specified (<strong>1</strong>),
records with duplicate key values are retrieved in LIFO order by the physical
sequence of the records. Here is an example of DDS using the LIFO keyword. <pre>|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
A* ORDERP2
A <strong>1</strong> LIFO
A R ORDER2
A .
A .
A .
A K ORDER
A</pre>
</li>
<li>First-in-first-out (FIFO). If
the FIFO keyword is specified, records with duplicate key values are retrieved
in FIFO order by the physical sequence of the records.</li>
<li>First-changed-first-out
(FCFO). If the FCFO keyword is specified, records with duplicate key values
are retrieved in FCFO order by the physical sequence of the keys.</li>
<li>No specific order for duplicate key fields (the default). When the FIFO,
FCFO, or LIFO keyword is not specified, no guaranteed order is specified for
retrieving records with duplicate keys. No specific order for duplicate key
fields allows more access path sharing, which can improve performance. </li>
</ul>
</div>
<p>When
a simple- or multiple-format logical file is based on more than one physical
file member, records with duplicate key values are read in the order in which
the files and members are specified on the DTAMBRS parameter of the Create
Logical File (CRTLF) or Add Logical File Member (ADDLFM) command. Examples
of logical files with more than one record format can be found in <a href="../dds/kickoff.htm">DDS concepts</a>.</p>
<p>The LIFO or FIFO order of records with duplicate key values is not determined
by the sequence of the updates made to the contents of the key fields, but
only by the physical sequence of the records in the file member. Assume that
a physical file has the FIFO keyword specified (records with duplicate keys
are in FIFO order), and that the following table shows the order in which
records were added to the file.</p>
<table cellpadding="4" cellspacing="0" border="1" class="tableborder"><tr><td>
<table cellpadding="4" cellspacing="0" summary="" width="100%" border="0"><thead align="left"><tr><th align="center" valign="top" width="58.333333333333336%" id="d0e148">Order records were added to file</th>
<th align="center" valign="top" width="41.66666666666667%" id="d0e150">Key value</th>
</tr>
</thead>
<tbody><tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e148 ">1</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e150 ">A</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e148 ">2</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e150 ">B</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e148 ">3</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e150 ">C</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e148 ">4</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e150 ">C</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e148 ">5</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e150 ">D</td>
</tr>
</tbody>
</table>
</td></tr></table>
<p>The sequence of the access path is (FIFO, ascending key).</p>
<table cellpadding="4" cellspacing="0" border="1" class="tableborder"><tr><td>
<table cellpadding="4" cellspacing="0" summary="" width="100%" border="0"><thead align="left"><tr><th align="center" valign="top" width="58.333333333333336%" id="d0e186">Record number</th>
<th align="center" valign="top" width="41.66666666666667%" id="d0e188">Key value</th>
</tr>
</thead>
<tbody><tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e186 ">1</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e188 ">A</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e186 ">2</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e188 ">B</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e186 ">3</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e188 ">C</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e186 ">4</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e188 ">C</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e186 ">5</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e188 ">D</td>
</tr>
</tbody>
</table>
</td></tr></table>
<p>Records 3 and 4, which have duplicate key values, are in FIFO order. That
is, because record 3 was added to the file before record 4, it is read before
record 4. This would become apparent if the records were read in descending
order. This can be done by creating a logical file based on this physical
file, with the DESCEND keyword specified in the logical file.</p>
<p>The sequence of the access path is (FIFO, descending key).</p>
<table cellpadding="4" cellspacing="0" border="1" class="tableborder"><tr><td>
<table cellpadding="4" cellspacing="0" summary="" width="100%" border="0"><thead align="left"><tr><th align="center" valign="top" width="58.333333333333336%" id="d0e226">Record number</th>
<th align="center" valign="top" width="41.66666666666667%" id="d0e228">Key value</th>
</tr>
</thead>
<tbody><tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e226 ">5</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e228 ">D</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e226 ">3</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e228 ">C</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e226 ">4</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e228 ">C</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e226 ">2</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e228 ">B</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e226 ">1</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e228 ">A</td>
</tr>
</tbody>
</table>
</td></tr></table>
<p>If the key value of physical record 1 is changed to C, the sequence of
the access path for the physical file is (FIFO, ascending key).</p>
<table cellpadding="4" cellspacing="0" border="1" class="tableborder"><tr><td>
<table cellpadding="4" cellspacing="0" summary="" width="100%" border="0"><thead align="left"><tr><th align="center" valign="top" width="58.333333333333336%" id="d0e264">Record number</th>
<th align="center" valign="top" width="41.66666666666667%" id="d0e266">Key value</th>
</tr>
</thead>
<tbody><tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e264 ">2</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e266 ">B</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e264 ">1</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e266 ">C</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e264 ">3</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e266 ">C</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e264 ">4</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e266 ">C</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e264 ">5</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e266 ">D</td>
</tr>
</tbody>
</table>
</td></tr></table>
<p>Finally, changing to descending order, the new sequence of the access path
for the logical file is (FIFO, descending key).</p>
<table cellpadding="4" cellspacing="0" border="1" class="tableborder"><tr><td>
<table cellpadding="4" cellspacing="0" summary="" width="100%" border="0"><thead align="left"><tr><th align="center" valign="top" width="58.333333333333336%" id="d0e302">Record number</th>
<th align="center" valign="top" width="41.66666666666667%" id="d0e304">Key value</th>
</tr>
</thead>
<tbody><tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e302 ">5</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e304 ">D</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e302 ">1</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e304 ">C</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e302 ">3</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e304 ">C</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e302 ">4</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e304 ">C</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e302 ">2</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e304 ">B</td>
</tr>
</tbody>
</table>
</td></tr></table>
<p>After the change, record 1 does not appear after record 4, even though
the contents of the key field were updated after record 4 was added.</p>
<p>The FCFO order of records with duplicate key values is determined by the
sequence of updates made to the contents of the key fields. In the example
above, after record 1 is changed such that the key value is C, the sequence
of the access path (FCFO, ascending key only) is.</p>
<table cellpadding="4" cellspacing="0" border="1" class="tableborder"><tr><td>
<table cellpadding="4" cellspacing="0" summary="" width="100%" border="0"><thead align="left"><tr><th align="center" valign="top" width="58.333333333333336%" id="d0e342">Record number</th>
<th align="center" valign="top" width="41.66666666666667%" id="d0e344">Key value</th>
</tr>
</thead>
<tbody><tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e342 ">2</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e344 ">B</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e342 ">3</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e344 ">C</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e342 ">4</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e344 ">C</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e342 ">1</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e344 ">C</td>
</tr>
<tr><td align="center" valign="top" width="58.333333333333336%" headers="d0e342 ">5</td>
<td align="center" valign="top" width="41.66666666666667%" headers="d0e344 ">D</td>
</tr>
</tbody>
</table>
</td></tr></table>
<p>For FCFO, the duplicate key ordering can change when the FCFO access path
is rebuilt or when a rollback operation is performed. In some cases, your
key field can change but the physical key does not change. In these cases,
the FCFO ordering does not change, even though the key field has changed.
For example, when the index ordering is changed to be based on the absolute
value of the key, the FCFO ordering does not change. The physical value of
the key does not change even though your key changes from negative to positive.
Because the physical key does not change, FCFO ordering does not change.</p>
<p>If the reuse deleted records attribute is specified for a physical file,
the duplicate key ordering must be allowed to default or must be FCFO. The
reuse deleted records attribute is not allowed for the physical file if either
the key ordering for the file is FIFO or LIFO, or if any of the logical files
defined over the physical file have duplicate key ordering of FIFO or LIFO.</p>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rbafoksapa.htm" title="A keyed sequence access path for database files is based on the contents of the key fields as defined in data description specifications (DDS). This topic describes how the key fields are arranged for the file.">Use a keyed sequence access path for database files</a></div>
</div>
<div class="relconcepts"><strong>Related concepts</strong><br />
<div><a href="rbafoshrap.htm" title="When two or more files are based on the same physical files and the same key fields in the same order, they automatically share the same keyed sequence access path. When access paths are shared, the amount of system activity required to maintain access paths and the amount of auxiliary storage used by the files is reduced.">Use existing access paths</a></div>
</div>
</div>
</body>
</html>
Reference in New Issue Copy Permalink