Allocation of sort work space
It is critical that you have the right amount of space allocated to handle all of the data without causing performance degradation or abends.
Common problems occur because of inefficient placement of the sort work files or not allocating enough space because bad file size estimate is passed to the sort. In most cases, letting BMCSORT dynamically allocate sort work spaces provides good performance.
To determine the size of sort work data sets, see Determining sort work space requirements.
When you hard-code sort work files in JCL, use the following guidelines:
Allocate in cylinders.
Allocate all sort work files on one device type, preferably the device with the fastest data transfer rate.
If possible, allocate sort work files on different volsers across different channel paths.
Do not use VIO data sets for sort work.
Allocate enough sort work space in primary storage to contain all input data.
When sorting multi-gigabyte files, prefer direct JCL allocation of sort work files to dynamic allocation because of the large number of resources needed. Depending on the file size, allocate between four to twelve sort work data sets on separate devices and, preferably, an equivalent number of channel paths for optimal performance.
While BMCSORT allows the allocation of up to 32 hard-coded sort work files for any one sort, hard-coding more than 12 sort work files can cause performance to degrade because of high overhead. Start by allocating four sort work files, and allocate more only if you must because of problems in obtaining extents.