258 lines
16 KiB
HTML
258 lines
16 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="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> |