115 lines
7.2 KiB
HTML
115 lines
7.2 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="DDS logical files with more than one record format" />
|
|
<meta name="abstract" content="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." />
|
|
<meta name="description" content="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." />
|
|
<meta name="DC.subject" content="logical files, multiple record formats" />
|
|
<meta name="keywords" content="logical files, multiple record formats" />
|
|
<meta name="DC.Relation" scheme="URI" content="lkeynm.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="simpmult.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="logmultrecfmts" />
|
|
<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>DDS logical files with more than one record format</title>
|
|
</head>
|
|
<body id="logmultrecfmts"><a name="logmultrecfmts"><!-- --></a>
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
|
<h1 class="topictitle1">DDS logical files with more than one record format</h1>
|
|
<div><p>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.</p>
|
|
<p>It is not necessary to specify the same number of key fields in each key.
|
|
Also, key fields specified in one record format must have the same field attributes
|
|
and access path keywords as the corresponding key fields in other record formats
|
|
in the same logical file. Variable-length key fields are not be allowed to
|
|
align with a fixed-length key field, even if the field types and lengths are
|
|
the same.</p>
|
|
<p>A key is required for every record format so that the logical file members
|
|
can have a single access path sequencing records of each record format. When
|
|
records are returned from the various members of the physical file on which
|
|
the logical file is based, they are merged according to the values of the
|
|
key fields in the access path for the logical file member.</p>
|
|
<p>When records of a logical file member are sequenced, the operating system
|
|
builds a <em>key value</em> for each record by concatenating the values in its
|
|
key fields. The key value is then used to build the access path for use by
|
|
your program. </p>
|
|
<p>Each key field in a composite key has a <em>key position</em>. The first
|
|
key field specified is in position 1, the second key field specified is in
|
|
position 2, and so on. During I/O operations to a logical file, the <span class="keyword">i5/OS™</span> program compares the key values
|
|
of the records written to or read from the database. When you create a logical
|
|
file that has more than one record format (with or without different key fields
|
|
specified), the operating system performs <em>key position attribute checking</em>.
|
|
For key position attribute checking to succeed, key fields of different record
|
|
formats that are in the same key positions must have the same data type, length,
|
|
decimal positions, and access path keywords specified at the key field level.
|
|
This ensures a meaningful record sequence from the comparisons made during
|
|
an I/O operation.</p>
|
|
<p>Floating-point fields used as key fields must have the same data type and
|
|
precision but need not have the same length and decimal positions.</p>
|
|
<p>In the following example, FIELD1, FLD1, and F1 must have the same attributes,
|
|
and FIELD2, FLD2, and F2 must have the same attributes. FIELD1, FLD1, and
|
|
F1 are in key position 1; FIELD2, FLD2, and F2 are in key position 2. One
|
|
record format can have more key fields than another, and the additional fields
|
|
do not need key position attribute checking. FLD3 is such a field.</p>
|
|
<div class="fignone" id="logmultrecfmts__cfig5"><a name="logmultrecfmts__cfig5"><!-- --></a><span class="figcap">Figure 1. Key field attribute checking</span><pre>|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
|
|
00010A R RECORD1 PFILE(PF1)
|
|
00020A FIELD1 5 0
|
|
00030A FIELD2 10
|
|
00040A FIELD3 10
|
|
00050A K FIELD1
|
|
00060A K FIELD2 DESCEND
|
|
00070A*
|
|
00080A R RECORD2 PFILE(PF2)
|
|
00090A FLD1 5 0
|
|
00100A FLD2 10
|
|
00110A FLD3 20
|
|
00120A K FLD1
|
|
00130A K FLD2 DESCEND
|
|
00140A K FLD3
|
|
A*
|
|
A R RECORD3 PFILE(PF3)
|
|
A F1 5 0
|
|
A F2 10
|
|
A F3 30
|
|
A K F1
|
|
A K F2 DESCEND
|
|
A
|
|
A</pre>
|
|
</div>
|
|
<p>In examples of key fields in a logical file with more
|
|
than one record format, fields named ITEM are specified in each key. For record
|
|
formats INVFMT and ACTFMT, ITEM is the only key field specified. For record
|
|
format ORDFMT, a composite key is specified. This composite key includes ITEM,
|
|
SHPYR, SHPMO, and SHPDA. Each of the fields used in a key must also exist
|
|
at the field level. Therefore, ITEM must exist in the record format for the
|
|
physical file INVENTORY so that it can be copied into this logical file for
|
|
INVFMT. Also, ITEM must exist in the record format for the logical file ACCOUNTL
|
|
so that it can be copied into this logical file for ACTFMT. ITEM must also
|
|
exist in physical file ACCOUNTS.</p>
|
|
</div>
|
|
<div>
|
|
<div class="familylinks">
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="lkeynm.htm" title="When you specify K in position 17, the name specified in positions 19 through 28 is a key field name.">Key field name</a></div>
|
|
</div>
|
|
<div class="reltasks"><strong>Related tasks</strong><br />
|
|
<div><a href="simpmult.htm" title="You must specify the PFILE keyword at the record level for simple and multiple format logical files. In a multiple format logical file, a record format can use only the fields common to all the physical files specified on the PFILE keyword for that record format.">Simple and multiple format logical files in DDS</a></div>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html> |