MAXKSORT integer

The MAXKSORT option specifies the maximum number of index key sorts and index rebuilds that can run in parallel subtasks.

Important

When you rebuild the indexes of a multi-data-set, nonpartitioned table space, the UNLOADs run serially in the main task, but the REBUILDs are multitasked.

Valid values are 1 to 999. If you do not specify a value for MAXKSORT, BMC AMI Recover uses the value of the MAXKSORT installation option, which defaults to the following formula:

minimum((2 * the number of CPUs), 12)

Important

Each sort requires about 256 KB of memory below the line. Values for MAXKSORT greater than 12 are not recommended.

For a description of the MAXKSORT installation option, see MAXKSORT.

Important

When the value of MAXKSORT is greater than 1, BMC AMI Recover ignores the WORKDDN option on the REBUILD INDEX command and issues a warning message. To use the WORKDDN option, specify a value of 1 for MAXKSORT. For a description of WORKDDN, see WORKDDN DDName.

Using the MAXKSORT option can improve recovery performance.

The MAXKSORT value determines the level of concurrency that can be achieved for index key sorts and index rebuilds. If this value is too small, the level of concurrency could be unnecessarily limited and the size of each sort will be larger. If this value is too large, the recovery job could overuse system resources and degrade recovery performance and overall system performance.

The concurrency that is reached by using MAXKSORT is limited by the following items:

  • The amount of memory that is available below the 16-MB line for BMCSORT processing

    In most environments, available memory below the 16-MB line creates a practical limit of 15 to 20 sorts.

  • The value assigned to the KSORTSHARE option (MAXLSORT integer and KSORTSHARE=YES)

    KSORTSHARE specifies if key sorts are shared among BMC AMI Recover table space recoveries (MERGE phases) running in parallel.

If the key lengths of the indexes vary widely in size, MAXKSORT increases efficiency because it allocates only the amount of memory that is needed for each key.

If the index rebuild includes both partitioned and nonpartitioned indexes, MAXKSORT, if set to a value of 3 or greater, could allow the sorting of the partitioned indexes separately from the nonpartitioned indexes and might improve efficiency.

For each table space, index keys for all indexes being rebuilt are distributed over the number of sorts that you specify for this option and these sorts can run in parallel. If BMC AMI Recover is recovering a partitioned table space and is rebuilding the partitioning index, the rebuild of each partition may be performed at the completion of the MERGE for each partition of the table space. The rebuild can run concurrently with the MERGE for the next partition if the MAXKSORT number is not exceeded. Running concurrent index key sorts and index rebuilds can increase the speed of the recovery.

Restart can cause keys that have already been extracted and sorted to be extracted and sorted again, but the restart process is relatively straightforward.

The following files are dynamically allocated if you do not code them in JCL:

  • SYSOUnnn: sort message files

    nnn is a number between 1 and the value specified for MAXKSORT.

  • SxxxWKnn: key sort work files

    xxx is a number between 1 and the value specified for MAXKSORT. nn is a number between 1 and the value specified for the SORTNUM installation option or the OPTIONS SORTNUM parameter.

When you use dynamic allocation for these files, BMCSORT determines the optimal number of files to use.

For more information about setting MAXKSORT, see MAXKSORT option.

Was this page helpful? Yes No Submitting... Thank you

Comments