Key records

Key records will contain the following in the order listed:
  1. The z/TPFCS record header as described in z/TPFCS record header. The record ID will be the ID of a key (index) record as defined in the ITO2 DSECT.
  2. An NDXPAGE object, which is the object used to store keys and associated RRNs in the key record.
    Note: The NDXPAGE object fills the remaining portion of the record after the record header. Furthermore, it contains its own trailer, which will be located at the end of the record in place of the z/TPFCS record trailer.
The following example is a representation of a key record that contains five active entries. Note that the entries are sorted using locators in a similar way to how entries were sorted in a MemKey structure.
Figure 1. Example of a key (index) record containing five entries
Alternate text
You can determine the exact format and contents of the NDXPAGE control information preceding its data area from the definition of the NDXPAGE instance attributes in the z/TPFCS source code. The exact format of the NDXPAGE trailer is defined under the NDXPG_Trailer tag in the same source module. The contents of this trailer include the following:
  • The number of entries in use
  • The displacement to the beginning of the available space in the data area relative to the start of the key record itself rather than the start of the NDXPAGE object
  • The number of bytes in the available space.
Each entry in the data area consists solely of a unique key followed immediately by an associated RRN. There is no DSECT that defines these entries in the z/TPFCS source code because the length of an entry depends on the key length, which varies from collection to collection. The entry length is stored in the NDXPAGE locator for that entry and equals the collection key length plus the length of an RRN (4 bytes). If the NDXPAGE locators are corrupt, you can determine the collection key length in several ways:
  • The collection key length is stored in DASDINDEX_I_MaxKeyLength. You can display the collection key length by using the ZBROW COLLECTION command for the collection.
  • If you suspect that the collection is corrupted and the response to these commands is incorrect, check the application program that defined and populated the collection.
The locators are used to sort the entries by key (from lowest to highest) as shown in Figure 1. Each locator consists of 6 bytes in the following format:
  • A 2-byte displacement field to the associated entry
    Note: For the key records, this displacement is relative to the beginning of the record (that is, starting at the z/TPFCS record header) rather than the NDXPAGE object or its data area.
  • A 2-byte field containing the length of its associated entry
  • 2 bytes reserved for future use.
Note: z/TPFCS does not remove the unused bytes from the data area before filing an NDXPAGE object in a key record on DASD.