bdfp1m0o | Programming Concepts and Reference |
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.
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.
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)
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.