bdfp1m0oProgramming Concepts and Reference

Using Keys When Reading LRECs

When keys are active on a read operation, the TPFDF product searches all the LRECs in the subfile (depending on the options specified) and returns the first LREC with key fields that match the ones specified in the active keys. The DBRED macro and dfred function are not the only macro and function that perform read operations. Other macros and functions perform read operations during internal processing. For example, the DBDEL macro and dfdel function both do a read operation to locate the correct LREC and then they do the delete operation.

If the same set of keys is used on multiple read operations, they do not have to be specified on each macro or function. Once activated by a macro or function, keys remain active and can be used by subsequent macros or functions (except as noted in Overview of Keys). Instead of specifying keys each time you read or delete LRECs, you can specify them when you open a subfile or use the DBKEY macro or dfkey function. If you then read LRECs without specifying any more key parameters, the TPFDF product supplies only those LRECs that match the keys specified with the DBOPN macro, dfopn function, DBKEY macro, or dfkey function.

Reading LRECs Using Partial Keys

You can read LRECs using just some of the keys that are used to organize the LRECs in each subfile. This is known as using a partial key.

For example, assume that the LRECs shown in Figure 4 are UP organized on fields PKY and FLD1, DOWN organized on field FLD2, and UP organized on field FLD3.

Figure 4. LRECs Organized on Four Key Fields


Figure 5 shows the sample contents of such a file.

Figure 5. LREC Data Organized on Four Key Fields

       PKY     FLD1      FLD2      FLD3
       80      1000      4000      2000
       80      1000      4000      4000
       80      1000      3000      1000
       80      1000      3000      2000
       80      2000      3000      3000
       80      2000      3000      4000
       80      2000      2000      2000
       80      3000      3000      1000
       80      3000      3000      3000
       80      3000      3000      5000
       80      3000      1000      1000
       80      3000      1000      4000
       80      5000      4000      2000
       80      5000      4000      4000

The TPFDF product lets you read LRECs without specifying all the keys used in the file organization. You can specify only a selection of the key fields in the search. For example, you could use fields PKY, FLD1 and FLD3. However, because you are omitting one of the key fields in the search argument, the LRECs must not be treated as UP or DOWN organized on any of the less-significant key fields (in this case, field FLD3).

It is essential that you define the organization of the LRECs on these less-significant key fields as NOORG. Otherwise, you will not locate all the LRECs matching your criteria. For example:

DBRED REF=zzzzzz,                                    *
      KEY1=(PKY=#zzzzK80,UP),                        *
      KEY2=(R=zzzzFLD1,S=EBW000,UP),                 *
      KEY3=(R=zzzzFLD3,S=EBX000,NOORG)

Specifying an organization of NOORG (or not specifying organization) on a file that has organization can cause the TPFDF product to unnecessarily search for more LRECs that match the selection criteria. However, the same LRECs will be retrieved whether organization is specified or not.

Reading LRECs Using a B+Tree Index

Large subfiles can require many DASD accesses for the TPFDF product to search for a particular LREC. DASD accesses can be minimized by using B+Tree indexing.

The TPFDF product uses a B+Tree index to quickly find an LREC in a B+Tree data file. The TPFDF product uses the B+Tree index while reading a B+Tree data file when the active keys match the order, organization, and displacement of the default keys. The active keys are used until one does not match the default keys.

In the following example, KEY1, KEY2, and KEY4 in the DBRED statement match KEY1, KEY2, and KEY4 in the DBDEF statement, but KEY3 does not match. In this example, the TPFDF product uses the B+Tree index to locate the first LREC matching KEY1 and KEY2. The TPFDF product then searches sequentially through the subfile until it finds an LREC matching KEY3 and KEY4.

DBDEF FILE=GR91SR,
      KEY1=(PKY=#GR91K80,UP),
      KEY2=(R=GR91FLD1,UP),
      KEY3=(R=GR91FLD3,DOWN),
      KEY4=(R=GR91FLD4,UP)
 
DBRED REF=GR91SR,
      KEY1=(PKY=#GR91K80,UP),
      KEY2=(R=GR91FLD1,S=EBW000,UP),
      KEY3=(R=GR91FLD6,S=EBX000,DOWN),
      KEY4=(R=GR91FLD4,S=EBW044,UP)
Note:
The TPFDF product will not use a key to search the B+Tree index if the key was defined with one of the following: The TPFDF product will use only a previously active key to search the B+Tree index. This key and any subsequent keys are then used by the TPFDF product to sequentially search for the requested LREC.

You can read LRECs specifying only the part of the key that is used to organize the file. For example, suppose we have a file that is organized in the ascending order of seat number in a flight number as shown in Figure 6.

Figure 6. LRECs on a Keyed File

    LREC ID  Flight      Seat      Customer
    (Hex.)   number      number    Name
 
      80     1233        A99       xxxxxx
S     80     1234        C31       xxxxxxxxxx
S     80     1234        C45       xxxxxxxxxxxxx
S     80     1234        D17       xxxxxxx
S     80     1234        E05       xxxxxxxxxx
      80     1236        A02       xxxxxx
      80     1236        D01       xxxxxx
      ----------------------
      key of the file (ascending)

To extract the customers travelling on flight 1234, you could request the TPFDF product to read LRECs with a primary key of X'80' and a secondary key (flight number) of 1234. The TPFDF product would give you the first LREC marked with an S. On subsequent reads it gives you the next LREC and so on until it has given you all the matching LRECs.

Now assume that the file uses B+Tree indexing and the flight and seat number were coded as default keys in the DBDEF, but only flight number 1234 is supplied when you read the file. The first time DBRED is issued, the B+Tree index is used to find the first LREC with flight number 1234. The next time DBRED is issued, DBRED does not use the B+Tree index to find the next LREC with flight number 1234. The file is searched sequentially.

Applications do not have to be updated to use B+Tree indexing. B+Tree indexing provides a more effective method for accessing LRECs in large files that have unusual, unknown, or changing distributions.