bdfd1m0k | Database Administration |
Each LREC in the passenger number file contains the fields shown in Table 26. Table 26 also shows the number of bytes in each
field.
Table 26. LREC Fields for the Passenger Number File
Field | No. of bytes |
---|---|
size | 2 |
key | 1 |
passenger number | 8 |
pointer to passenger file | 5 |
Total | 16 |
From this, you can see that each LREC in the passenger number file contains 16 bytes.
The following calculation shows how many LRECs from the passenger number file can be held in a 4-K block:
4033 ÷. 16 = 252 LRECs in each block
The database must be able to hold 1.825 million passenger LRECs.
The calculation that follows shows how many blocks you would need to accommodate the 1.825 million passenger number LRECs. (The calculation assumes an even distribution of LRECs):
1.825 million ÷. 252 = 7243 blocks
Again, the number of overflow blocks required is too many for a real-time system. Choose an algorithm to distribute the LRECs over subfiles.
The algorithms used with the passenger name file cannot be used here because passenger numbers are not alphabetic. However, the TPFDF product provides a hashing algorithm that distributes LRECs numerically.
The hashing algorithm (#TPFDB09) distributes the LRECs evenly. They do not need to be stored in any particular order, because you will never need to access more than one at a time. For instance, you will not need to access a range of passenger numbers all at once.
Algorithm #TPFDB09 uses the algorithm string as a seed. It divides the result of the calculation by the number of subfiles in the file. The remainder is the ordinal number of the destination subfile.
To ensure the least number of overflow blocks possible, choose the prime number nearest to 7243 (the number of blocks required for the passenger number file).
Because the LRECs in this file are distributed by passenger number, you need to ensure that this field gives a good distribution over the subfiles.
The passenger number is the algorithm seed from which the pseudo-random number is calculated. Because many passenger numbers begin with zeros, the resulting distribution is not likely to be even. You can improve the distribution by manipulating the algorithm string before it is used.
For example, if the first 4 bytes of the passenger number are swapped with
the second 4 bytes, the difficulty is overcome as you can see in Table 27.
Table 27. Manipulating the Algorithm String
Passenger number | Algorithm string |
---|---|
00087628 | 76280008 |
00987653 | 76530098 |
Manipulating the algorithm string has given a good distribution of LRECs. If there is any overflow, it is likely to be small. Because of this, 1-K overflow blocks will probably be adequate. (You can change the size of overflow blocks by changing the value of the DBDEF ARS parameter and entering the ZUDFM OAP command.)
The passenger number file has a classic index structure that the TPFDF product can maintain easily. Here the ALG string is the passenger number, which algorithm #TPFDB09 uses to access the subfiles.
The LREC structure for the passenger number file is as follows: