Example: Implicitly shared access paths
This example shows how to implicitly share an access path between logical files.
Two logical files, LFILE1 and LFILE2, are built over the physical file PFILE. LFILE1, which was created first, has two key fields, KFD1 and KFD2. LFILE2 has three key fields, KFD1, KFD2, and KFD3. The two logical files use two of the same key fields, but no access path is shared because the logical file with three key fields was created after the file with two key fields.
| Description | Physical file (PFILE) | Logical file 1 (LFILE1) | Logical file 2 (LFILE2) |
|---|---|---|---|
| Access path | KFD1, KFD2 | KFD1, KFD2, KFD3 | |
| Fields | KFD1, KFD2, KFD3, A, B, C, D, E, F, G | KFD1, KFD2, KFD3, F, C, A | KFD1, KFD2, KFD3, D, G, F, E |
An application uses LFILE1 to access the records and to change the KFD3 field to blank if it contains a C, and to a C if it is blank. This application does not cause any unexpected results because the access paths are not shared. However, after the physical file and both logical files are saved and restored, the program appears to do nothing and takes longer to process.
Unless you change the way you restore the logical files (for example, if you restore LFILE1 and LFILE2 separately with the Restore Object (RSTOBJ) command), the system restores the logical file with the largest number of keys first or does not build unnecessary access paths.
Because it has three key fields, LFILE2 is restored first. After recovery, LFILE1 implicitly shares the access path for LFILE2. Users who do not understand implicitly shared access paths do not realize that when they use LFILE1 after a recovery, they are really using the key for LFILE2.
| Description | Physical file (PFILE) | Logical file 1 (LFILE1) | Logical file 2 (LFILE2) |
|---|---|---|---|
| Access path | KFD1, KFD2, KFD3 | KFD1, KFD2, KFD3 | |
| Fields | KFD1, KFD2, KFD3, A, B, C, D, E, F, G | KFD1, KFD2, KFD3, F, C, A | KFD1, KFD2, KFD3, D, G, F, E |
The following records are tested and changed.
| Relative record | KFD1 | KFD2 | KFD3 |
|---|---|---|---|
| 001 | 01 | 01 | <blank> |
| 002 | 01 | 01 | <blank> |
| 003 | 01 | 01 | <blank> |
| 004 | 01 | 01 | <blank> |
The first record is read through the first key of 0101<blank> and changed to 0101C. The records now look like this.
| Relative record | KFD1 | KFD2 | KFD3 |
|---|---|---|---|
| 001 | 01 | 01 | C |
| 002 | 01 | 01 | <blank> |
| 003 | 01 | 01 | <blank> |
| 004 | 01 | 01 | <blank> |
When the application issues a get next key, the next higher key above 0101<blank> is 0101C. This is the record that was just changed. However, this time the application changes the KFD3 field from C to blank.
Because the user does not understand implicit access path sharing, the application accesses and changes every record twice. The end result is that the application takes longer to run, and the records look like they have not changed.