friedkiwi/ibm-information-center
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
14ed2849c6
ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzakb_5.4.0.1/lkeynm.htm

309 lines
19 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="Key field name" />
<meta name="abstract" content="When you specify K in position 17, the name specified in positions 19 through 28 is a key field name." />
<meta name="description" content="When you specify K in position 17, the name specified in positions 19 through 28 is a key field name." />
<meta name="DC.subject" content="key field name, physical files, key field name, logical files, key field name" />
<meta name="keywords" content="key field name, physical files, key field name, logical files, key field name" />
<meta name="DC.Relation" scheme="URI" content="lfname.htm" />
<meta name="DC.Relation" scheme="URI" content="accpathkwds.htm" />
<meta name="DC.Relation" scheme="URI" content="logmultrecfmts.htm" />
<meta name="DC.Relation" scheme="URI" content="nonekeyfield.htm" />
<meta name="DC.Relation" scheme="URI" content="logfileviewex.htm" />
<meta name="DC.Relation" scheme="URI" content="logfileviewex2.htm" />
<meta name="DC.Relation" scheme="URI" content="logfileviewex3.htm" />
<meta name="DC.Relation" scheme="URI" content="logfileviewex4.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakbmstlconcat.htm" />
<meta name="copyright" content="(C) Copyright IBM Corporation 2001, 2006" />
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2001, 2006" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="lkeynm" />
<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>Key field name</title>
</head>
<body id="lkeynm"><a name="lkeynm"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Key field name</h1>
<div><p>When you specify <tt>K</tt> in position 17, the name specified
in positions 19 through 28 is a key field name.</p>
<p>It must be one of the field names within the physical file record format.
The contents of this field are used to sequence the records for retrieval
from the database. Specifying a key is optional. If no key field is specified,
the default sequence is arrival sequence (the order that the records were
put into the file).</p>
<p>Use key fields (and optionally, select/omit fields) to define a keyed sequence
access path for record formats in the logical file member. The logical file
member includes the physical file members specified on the DTAMBRS parameter
on the Create Logical File (CRTLF) or Add Logical File Member (ADDLFM) command.</p>
<p>You can change the sequence of records as they are read from the file by
specifying a sequencing keyword. The sequencing keywords are ALTSEQ, NOALTSEQ,
SIGNED, UNSIGNED, ABSVAL, ZONE, DIGIT, DESCEND, FCFO, FIFO, and LIFO.</p>
<div class="p">When you do not specify any sequencing keyword for a key field, the default
sequence for that key field is ascending order. The default for character,
hexadecimal, date, time, and timestamp fields is the UNSIGNED attribute. The
default for numeric fields is the SIGNED attribute, except for zoned decimal
fields (S specified in position 35) in the following cases: <ul><li>When you specify ALTSEQ at the file level, all zoned decimal key fields
in the file are set to UNSIGNED as default.</li>
<li>When you specify DIGIT or ZONE for a zoned decimal key field, the field
is set to UNSIGNED as default.</li>
</ul>
</div>
<p>If you specify more than one record format for a logical file or more than
one physical file for the PFILE keyword, you must specify at least one key
field for all record formats of that logical file.</p>
<p>A key can have more than one key field. This is called a <dfn class="term">composite
key</dfn>. In a composite key, specify the key field names in the order of
importance (major to minor), and specify each key field name on a separate
line.</p>
<p><a href="#lkeynm__cfig3">Figure 1</a> shows a multiple format logical file
with two record formats, one of which uses a composite key. In this example,
RECORD1 has a single key field, FIELD1. RECORD2 has a composite key that includes
FIELD4 and FIELD5.</p>
<div class="fignone" id="lkeynm__cfig3"><a name="lkeynm__cfig3"><!-- --></a><span class="figcap">Figure 1. Specify a multiple format logical file with two record
formats</span><pre>|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
00010A R RECORD1 PFILE(PF1)
00020A FIELD1
00030A FIELD2
00040A FIELD3
00050A K FIELD1
00060A*
00070A R RECORD2 PFILE(PF2)
00080A FIELD4
00090A FIELD5
00100A K FIELD4
00110A K FIELD5
A</pre>
</div>
<p>If you do not specify a key field for a logical file, the file you are
defining has an arrival sequence access path.</p>
<p><img src="./delta.gif" alt="Start of change" />The number of fields that make up a key is restricted
to 120. The total key length cannot exceed 32 768 bytes. (If the FCFO keyword
is specified, the total key length cannot exceed 32 763 bytes. In a DDM environment,
the key length is limited to 12 000.) The total key length includes the length
of each key field. If any of the key fields allow the null value, add 1 byte
for each key field that allows the null value. The operating system uses the
extra byte to determine whether the key contains the null value. If any of
the key fields is variable length, add 2 bytes for each variable-length key
field. The operating system uses the extra 2 bytes to store the allocated
length of the field.<img src="./deltaend.gif" alt="End of change" /></p>
<p>When you specify more than one record format
in a logical file, an additional byte for the first *NONE key field position
is required. An additional byte might also be required for each additional
key field position. The operating system uses the extra bytes when records
from different physical files have duplicate key values.</p>
<p>For example, suppose a key consists of fields named FIELDA, FIELDB, and
FIELDC (in that order). The DDS appears as shown in <a href="#lkeynm__bfig2">Figure 2</a>.</p>
<div class="fignone" id="lkeynm__bfig2"><a name="lkeynm__bfig2"><!-- --></a><span class="figcap">Figure 2. Composite key</span><pre>|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
00010A* SAMPLE COMPOSITE KEY (PHYSICAL FILE)
00020A R RECORD
00030A FIELDA 3 0
00040A FIELDB 3 0
00050A FIELDC 3 0
00060A FIELDD 3 0
00070A K FIELDA
00080A K FIELDB
00090A K FIELDC
A</pre>
<div class="note"><span class="notetitle">Note:</span> Lines 00070 to 00090 make up the composite key.</div>
</div>
<div class="p">The records are sequenced in the following order: <ol><li>They are sequenced according to the contents of FIELDA.</li>
<li>If two or more records with the same value in FIELDA exist, the operating
system sequences those records according to the values in FIELDB.</li>
<li>If two or more of those records have the same value in both FIELDA and
FIELDB, they are sequenced according to the values in FIELDC.</li>
</ol>
</div>
<p>Consider the following file:</p>
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" width="100%" frame="void" border="0" rules="none"><thead align="left"><tr><th align="center" valign="top" width="25%" id="d0e101">Record</th>
<th align="center" valign="top" width="25%" id="d0e103">FIELDA</th>
<th align="center" valign="top" width="25%" id="d0e105">FIELDB</th>
<th align="center" valign="top" width="25%" id="d0e107">FIELDC</th>
</tr>
</thead>
<tbody><tr><td align="center" valign="top" width="25%" headers="d0e101 ">1</td>
<td align="center" valign="top" width="25%" headers="d0e103 ">333</td>
<td align="center" valign="top" width="25%" headers="d0e105 ">99</td>
<td align="center" valign="top" width="25%" headers="d0e107 ">67</td>
</tr>
<tr><td align="center" valign="top" width="25%" headers="d0e101 ">2</td>
<td align="center" valign="top" width="25%" headers="d0e103 ">444</td>
<td align="center" valign="top" width="25%" headers="d0e105 ">10</td>
<td align="center" valign="top" width="25%" headers="d0e107 ">45</td>
</tr>
<tr><td align="center" valign="top" width="25%" headers="d0e101 ">3</td>
<td align="center" valign="top" width="25%" headers="d0e103 ">222</td>
<td align="center" valign="top" width="25%" headers="d0e105 ">34</td>
<td align="center" valign="top" width="25%" headers="d0e107 ">23</td>
</tr>
<tr><td align="center" valign="top" width="25%" headers="d0e101 ">4</td>
<td align="center" valign="top" width="25%" headers="d0e103 ">222</td>
<td align="center" valign="top" width="25%" headers="d0e105 ">12</td>
<td align="center" valign="top" width="25%" headers="d0e107 ">01</td>
</tr>
<tr><td align="center" valign="top" width="25%" headers="d0e101 ">5</td>
<td align="center" valign="top" width="25%" headers="d0e103 ">222</td>
<td align="center" valign="top" width="25%" headers="d0e105 ">23</td>
<td align="center" valign="top" width="25%" headers="d0e107 ">45</td>
</tr>
<tr><td align="center" valign="top" width="25%" headers="d0e101 ">6</td>
<td align="center" valign="top" width="25%" headers="d0e103 ">111</td>
<td align="center" valign="top" width="25%" headers="d0e105 ">06</td>
<td align="center" valign="top" width="25%" headers="d0e107 ">89</td>
</tr>
<tr><td align="center" valign="top" width="25%" headers="d0e101 ">7</td>
<td align="center" valign="top" width="25%" headers="d0e103 ">222</td>
<td align="center" valign="top" width="25%" headers="d0e105 ">23</td>
<td align="center" valign="top" width="25%" headers="d0e107 ">67</td>
</tr>
</tbody>
</table>
</div>
<p>Assuming ascending sequencing for all fields, the records are retrieved
in this order:</p>
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" width="100%" frame="void" border="0" rules="none"><thead align="left"><tr><th align="center" valign="top" width="25%" id="d0e183">Record</th>
<th align="center" valign="top" width="25%" id="d0e185">FIELDA</th>
<th align="center" valign="top" width="25%" id="d0e187">FIELDB</th>
<th align="center" valign="top" width="25%" id="d0e189">FIELDC</th>
</tr>
</thead>
<tbody><tr><td align="center" valign="top" width="25%" headers="d0e183 ">6</td>
<td align="center" valign="top" width="25%" headers="d0e185 ">111</td>
<td align="center" valign="top" width="25%" headers="d0e187 ">06</td>
<td align="center" valign="top" width="25%" headers="d0e189 ">89</td>
</tr>
<tr><td align="center" valign="top" width="25%" headers="d0e183 ">4</td>
<td align="center" valign="top" width="25%" headers="d0e185 ">222</td>
<td align="center" valign="top" width="25%" headers="d0e187 ">12</td>
<td align="center" valign="top" width="25%" headers="d0e189 ">01</td>
</tr>
<tr><td align="center" valign="top" width="25%" headers="d0e183 ">5</td>
<td align="center" valign="top" width="25%" headers="d0e185 ">222</td>
<td align="center" valign="top" width="25%" headers="d0e187 ">23</td>
<td align="center" valign="top" width="25%" headers="d0e189 ">45</td>
</tr>
<tr><td align="center" valign="top" width="25%" headers="d0e183 ">7</td>
<td align="center" valign="top" width="25%" headers="d0e185 ">222</td>
<td align="center" valign="top" width="25%" headers="d0e187 ">23</td>
<td align="center" valign="top" width="25%" headers="d0e189 ">67</td>
</tr>
<tr><td align="center" valign="top" width="25%" headers="d0e183 ">3</td>
<td align="center" valign="top" width="25%" headers="d0e185 ">222</td>
<td align="center" valign="top" width="25%" headers="d0e187 ">34</td>
<td align="center" valign="top" width="25%" headers="d0e189 ">23</td>
</tr>
<tr><td align="center" valign="top" width="25%" headers="d0e183 ">1</td>
<td align="center" valign="top" width="25%" headers="d0e185 ">333</td>
<td align="center" valign="top" width="25%" headers="d0e187 ">99</td>
<td align="center" valign="top" width="25%" headers="d0e189 ">67</td>
</tr>
<tr><td align="center" valign="top" width="25%" headers="d0e183 ">2</td>
<td align="center" valign="top" width="25%" headers="d0e185 ">444</td>
<td align="center" valign="top" width="25%" headers="d0e187 ">10</td>
<td align="center" valign="top" width="25%" headers="d0e189 ">45</td>
</tr>
</tbody>
</table>
</div>
<div class="p">The following information applies: <ul><li>Because records 3, 4, 5, and 7 have the same contents in FIELDA, FIELDB
becomes the determining field.</li>
<li>Within those four records, 5 and 7 have the same values in FIELDB. For
these two records, FIELDC becomes the determining field.</li>
<li>If FIELDC also contains duplicate values, the records are retrieved in
first-in first-out (FIFO), last-in first-out (LIFO), or first-changed first-out
(FCFO) order. To guarantee the order, specify the FIFO keyword, the LIFO keyword,
or the FCFO keyword. Specify the UNIQUE keyword to prevent duplicate key values.</li>
</ul>
</div>
<p>See the <a href="rzakbmstsign.htm">SIGNED (Signed) keyword for physical and logical files</a> topic for an example that
includes a key field with negative (-) contents.</p>
<p>Special restrictions apply to key field specifications when either FILETYPE(*SRC)
is used on the Create Physical File (CRTPF) command or for the Create Source
Physical File (CRTSRCPF) command.</p>
<div class="p">For logical files, the following rules apply to fields that you specify
as key fields: <ul><li>For simple and multiple format logical files, the following search order
is used to match key field names with defined fields: <ol><li>Fields specified in DDS positions 19 through 28</li>
<li>Fields specified as parameters on the CONCAT or RENAME keyword</li>
</ol>
<p>If the field name is specified more than once, the first occurrence
is used.</p>
<p>The field name on a CONCAT or RENAME keyword and the associated
field name in positions 19 through 28 cannot both be specified as key fields.</p>
<p>The
parameter name on the SST keyword is not valid as a key field unless it is
defined elsewhere in the logical file format.</p>
</li>
<li>For join logical files, the key field name you specify must be specified
at the field level in positions 19 through 28 and must be a field described
in the primary file (the first physical file specified on the JFILE keyword).
<div class="note"><span class="notetitle">Note:</span> If you specify a field as a parameter value on the CONCAT, RENAME,
or SST keyword, but do not specify the field in positions 19 through 28 of
the join logical file, you cannot specify the field as a key field.</div>
</li>
</ul>
</div>
<p>If you are concatenating numeric with either character or hexadecimal,
you cannot specify the numeric fields as key fields. If you are concatenating
zoned decimal and fields of any other numeric data type, you cannot specify
the fields of the other data types as key fields.</p>
<p><a href="#lkeynm__cfig4">Figure 3</a> illustrates which concatenated fields
can and cannot be used as key fields.</p>
<div class="fignone" id="lkeynm__cfig4"><a name="lkeynm__cfig4"><!-- --></a><span class="figcap">Figure 3. Correct and incorrect concatenated fields</span><pre>|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
00010A R RECORD1 PFILE(PF1)
00020A FLD1
00030A FLD2
00040A Z CONCAT(ZFLD PFLD)
00050A A CONCAT(AFLD NFLD)
00060A K ZFLD
00070A K AFLD
A</pre>
</div>
<p>In physical file PF1, ZFLD is zoned decimal and PFLD is packed decimal.
Therefore Z is zoned decimal, and PFLD cannot be used as a key field. ZFLD
and Z can be used as key fields but not in the same record format.</p>
<p>In physical file PF1, AFLD is a character field and NFLD is a numeric field.
Therefore A is character, and NFLD cannot be used as a key field. AFLD and
A can be used as key fields but not in the same record format.</p>
</div>
<div>
<ul class="ullinks">
<li class="ulchildlink"><strong><a href="accpathkwds.htm">DDS access path keywords</a></strong><br />
You can specify one or more access path keywords to affect the way the operating system builds and uses key values.</li>
<li class="ulchildlink"><strong><a href="logmultrecfmts.htm">DDS logical files with more than one record format</a></strong><br />
When you specify more than one record format in a logical file, you must specify at least one key field for every record format in the logical file.</li>
<li class="ulchildlink"><strong><a href="nonekeyfield.htm">Use *NONE in the key field when creating a DDS file</a></strong><br />
Key fields having the same key position should not be compared under two conditions.</li>
<li class="ulchildlink"><strong><a href="logfileviewex.htm">Specify the key field (example 1)</a></strong><br />
In this example, a logical file views records of two physical files through two different record formats: CLSHST (class history) and JOBHST (job history).</li>
<li class="ulchildlink"><strong><a href="logfileviewex2.htm">Specify the key field (example 2)</a></strong><br />
In this example, a logical file views the same two physical files as in Example 1, but the second record format in the logical file has *NONE specified in key position 2.</li>
<li class="ulchildlink"><strong><a href="logfileviewex3.htm">Specify the key field (example 3)</a></strong><br />
In this example, consider a logical employee file over five physical files.</li>
<li class="ulchildlink"><strong><a href="logfileviewex4.htm">Specify the key field (example 4)</a></strong><br />
In this example, assume that an employee has repeated a class. To sequence two records with the same values for EMPNBR and CLSDTE, a third key field, DATE, is specified in record format CLSHST.</li>
</ul>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="lfname.htm" title="Use these positions to specify record or field names.">Name for physical and logical files (positions 19 through 28)</a></div>
</div>
<div class="relref"><strong>Related reference</strong><br />
<div><a href="rzakbmstlconcat.htm" title="Use this field-level keyword when you want to combine two or more fields from the physical file record format into one field in the logical file record format you are defining. The name of this concatenated field must appear in positions 19 through 28.">CONCAT (Concatenate) keyword—logical files only</a></div>
</div>
</div>
</body>
</html>
Reference in New Issue Copy Permalink