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.
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.
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.
When records of a logical file member are sequenced, the operating system builds a key value 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.
Each key field in a composite key has a key position. 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 i5/OS™ 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 key position attribute checking. 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.
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.
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.
|...+....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
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.