Example: Implicitly shared access paths

This example shows how to implicitly share access path.

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.

Table 1. Physical and logical files before save and restore
	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 causes the user no unexpected results because the access paths are not shared. However, after a save and restore of the physical file and both logical files, the program appears to do nothing and takes longer to process.

Unless you do something to change the restoration, the iSeries™ system:

Restores the logical file with the largest number of keys first
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.

Table 2. Physical and logical files after save and restore. Note that the only difference from before the save and restore is that the logical files now share the same access path.
	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 records to be tested and changed contain:

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 via 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.