The memory size specifies the number of words in memory to be used when sorting. If memory size is not specified, SORT assumes a default value of 12,000 words. SORT calculates the number of records to be kept simultaneously in memory with a limit of 65535 records. SORT also calculates the number of buffers to be used for each string, with a limit of 256 buffers per string.

When the SORT utility is invoked from a COBOL85, FORTRAN77, or C program, a memory size of at least 1524 words is required. If the memory requested is less than 1524 words, the required memory size is estimated, based on the size and expected number of records. The maximum memory size estimate provided by the software in such a case is 200,000 words.

The memory size estimate determines stringing and merging vector sizes, which, in turn, control string length and merging. Producing a small number of long strings is desired for sorting because fewer merge passes are required. Increasing the memory available to SORT is the most effective way to increase sorting efficiency. However, if the memory size is increased beyond the optimum, SORT might run slower rather than faster. The optimum memory size varies according to file size, which includes the record size, the blocking factor, and the number of records. Optimum memory size is also affected by the number of other jobs in the mix at the time of the sort operation.

SORT attempts to be processor-bound in both the stringing and merging phase (as opposed to processor-bound during the stringing phase and I/O-bound during the merging phase). Unless the memory size specified is relatively small for a given sort, SORT achieves the goal of being processor-bound. When this condition is obtained, speed improvements can be realized only by methods that reduce processor time. Decreasing the amount of processor time helps system throughput as well as reducing sort timings.

In general, memory allocation proceeds through the following steps:

In general, Unisys recommends a memory estimate of 4,000 or more words. Memory estimates of 20,000 or more are recommended only on large systems. Information on how to determine memory size for different sorting modes is given later in this section.

When the memory allocation is completed, SORT initializes its internal files with the proper computed attributes. SORT takes into account any change made to these file attributes through file equation. However, these file attributes override memory size specification; therefore, actual memory size can be less than or greater than the memory size specified to SORT. Refer to “SORT Files” in this section for more information on file equation of SORT internal files.

Determining Memory Size for Disk Sorting

A SORT that specifies disk requires memory to be used for the actual sorting. If memory size is not specified, then a default of 12,000 is assumed.

Perform the following procedure to determine memory size for disk sorting:

Determining Memory Size for Tape Sorting

Use the following to determine memory size for tape sorting:

Tape sorts are similar to disk sorts in that providing more memory generally yields faster sorts. However, the point of diminishing returns is more data-dependent for tape sorting. In general, using more sort work tapes rather than providing additional memory is more efficient. Providing more memory and more tapes is ideal when speed is the most important factor.

Determining Memory Size for Memory Sorting

Use the following for memory-only sorting:

If you specify a value less than 1524 words, the system calculates a memory size estimate for you by multiplying the record size as computed in the above three steps by the number of records to be sorted. The memory size estimate provided by the system cannot exceed 200,000 words.

Disk Sorts Involving Files with Exceptionally Large Record Counts

Memory-size-estimate calculations for a fast disk sort provide acceptable performance levels across a wide range of sorting environments. Sorting disk files that contain an especially large number of records requires additional attention. The appropriate method for dealing with exceptionally large record counts includes providing a sort with larger amounts of memory than normal.

Before using larger amounts of memory, evaluate your particular SORT requirement with regards to the following alternatives:

SORT performance depends on many environmental factors. If memory is the primary performance restriction, giving more of it to an extremely large sort potentially will improve performance by enabling SORT to support larger block sizes for its work file (DISKF), as well as larger internal tables. Larger block sizes enable more work to be done before having to go to disk, but significant amounts of memory are generally needed to cause block size increase. Doubling an estimate for a fast sort is likely to have minimal or no effect.

Internal computations used by the sort to derive optimal block sizes are complex and do not lend themselves to a simple formula or table. The most straightforward way to determine a suitable memory estimate is simply pick a 'large' initial amount, and test it in the special case sort. If additional performance is needed, increment and continue tuning until you either reach an acceptable performance level or encounter your limit (zero, negative, or marginal performance increase). A general guideline for the 'large' initial amount is enough memory (words) to hold 65K records. The value is the approximate maximum size of a 'String vector' (a collection of sequenced records).

The following example illustrates the differences in memory amounts for a fast SORT and for an exceptionally large one:

Example

File record size: 120 byte records
Memory estimate computed for a fast sort:
((120)/6 + 3) * 2000 + 1500 -or- 47,500 words
Memory estimate computed using this technique:
((120)/6) * 65000 -or- 1,300,000 words 

The MCP has extensive checks and balances for SORT parameters. The following are possible risks: