Sharing existing access paths between logical files

 

When two or more logical files are based on the same physical files with the same key fields in the same order, they automatically share the same keyed sequence access path.

When access paths are shared, the amount of system activity required to maintain the access paths and the amount of auxiliary storage used by the files are reduced. So when a logical file with a keyed sequence access path is created, the system always tries to share an existing access path. For access path sharing to occur, an access path that satisfies the following conditions must exist on the system:

• The logical file member to be added must be based on the same physical file members that the existing access path is based on.

• The length, data type, and number of decimal positions specified for each key field must be identical in both the new file and the existing file.

• If the FIFO, LIFO, or FCFO keyword is not specified, the new file can have fewer key fields than the existing access paths. That is, a new logical file can share an existing access path if the beginning part of the key is identical. However, when a file shares a partial set of keys from an existing access path, any record updates made to fields that are part of the set of keys for the shared access path might change the record position in that access path.

• The attributes of the access path (such as UNIQUE, LIFO, FIFO, or FCFO) and the attributes of the key fields (such as DESCEND, ABSVAL, UNSIGNED, and SIGNED) must be identical. Exceptions:

  1. A FIFO access path can share an access path in which the UNIQUE keyword is specified if all the other requirements for access path sharing are met.

  2. A UNIQUE access path can share a FIFO access path that needs to be rebuilt (for example, has *REBLD maintenance specified), if all the other requirements for access path sharing are met.

• If the new logical file has select/omit specifications, they must be identical to the select/omit specifications of the existing access path. However, if the new logical file specifies DYNSLT, it can share an existing access path if the existing access path has either:

  • The dynamic select (DYNSLT) keyword specified

  • No select/omit keywords specified

• The alternative collating sequence (ALTSEQ keyword) and the translation table (TRNTBL keyword) of the new logical file member, if any, must be identical to the alternative collating sequence and translation table of the existing access path.

Logical files that contain concatenated or substring fields cannot share access paths with physical files. The owner of any access path is the logical file member that originally created the access path. For a shared access path, if the logical member owning the access path is deleted, the first member to share the access path becomes the new owner. The FRCACCPTH, MAINT, and RECOVER parameters on the Create Logical File (CRTLF) command need not match the same parameters on an existing access path for that access path to be shared. When an access path is shared by several logical file members, and the FRCACCPTH, MAINT, and RECOVER parameters are not identical, the system maintains the access path by the most restrictive value for each of the parameters specified by the sharing members. The following list illustrates how this occurs:

• MBRA specifies:

  FRCACCPTH (*NO)
  MAINT (*IMMED)
  RECOVER (*AFTIPL)

• MBRB specifies:

• FRCACCPTH (*YES)
  MAINT (*DLY)
  RECOVER (*NO)

• System does:

  FRCACCPTH (*YES)
  MAINT (*IMMED)
  RECOVER (*AFTIPL)

Access path sharing does not depend on sharing between members; therefore, it does not restrict the order in which members can be deleted.

The Display File Description (DSPFD) and Display Database Relations (DSPDBR) commands show access path sharing relationships.

• Example: Implicitly shared access paths
  This example shows how to implicitly share an access path between logical files.

 

Parent topic:

Describing access paths for logical files

 

Related concepts

Arranging duplicate keys