Partition selection using high keys

If you use high-key partitioning, high keys define the partition boundaries and determine how the records are distributed across your partitions.

IMS performs partition selection based on the high key that is defined for each partition. The high key of a partition also defines the range of keys that the partition contains. IMS assigns a root segment to the partition with the lowest high key that is greater than or equal to the key of the root segment. For example, suppose that there are three partitions with high keys of 1000, 2000, and 3000. Root segment keys of 1001 through 2000 are in the partition with a high key of 2000.

The high keys of the partitions also define the order of the partitions within the HALDB database.

High-key partitioning is the simpler method to implement because you do not have to write an exit routine. You only need to assign a high key to each partition.

In PHIDAM and PSINDEX databases that use high-key partitioning, the records are in key sequence across the entire database, just as they are in HIDAM and non-HALDB secondary index databases. In PHIDAM or PSINDEX databases that use a partition selection exit routine, records are in key sequence within a partition, but not necessarily across partitions, which makes these databases inconsistent with HIDAM and non-HALDB secondary index databases. Application programs that require database records to be in key sequence across partitions do not work correctly when a partition selection exit routine is used.

Recommendation: When you use high-key partitioning, specify a high key value of all X'FF's for the partition that has the highest high key in the database. A high key value of all X'FF's ensures that all keys can be assigned to a partition. If the last partition (the partition with the highest key specified) has a key value other than all X'FF's, any attempt to access or insert a database record with a key higher than the high key specified results in an FM status code for the call. Application programs written for non-HALDB databases are unlikely to be able to process the FM status code.