Virtual storage limitations

With the possible exception of in-main storage sorts, providing more storage than needed to do an efficient sort (see Table 1 for storage guidelines) will probably not result in any significant performance improvement. In fact, elapsed time (and possibly CPU time) may even increase slightly. While this degradation might not be very noticeable, increasing virtual storage increases the overall effect DFSORT has on the system by tying up more central storage than necessary. This can result in fewer jobs being able to run at the same time as well as increased paging activity on the system.

If user exit routines are used, they will affect DFSORT virtual storage requirements. The exit routines will occupy virtual storage, and any storage requests they issue will reduce the amount of storage available to DFSORT. The MODS control statement should be used to reserve storage for exit routines.

If the storage available to DFSORT below 16 MB virtual is severely limited (for example, to less than 256 KB), the use of any of the following can result in storage failures or terminations:

Spanned records
COBOL exit routines
CHALT, LOCALE, or SMF options
ALTSEQ, INCLUDE, OMIT, SUM, OUTFIL, OUTREC, or INREC control statements
Very large blocks or logical records
VSAM data sets
An Extended Function Support (EFS) program
An ICETEXIT routine
A large ICEIEXIT routine
A large number of JCL or dynamically allocated work data sets

You can avoid storage problems and achieve better DFSORT performance by making sure MINLIM is always set to a reasonable value (for example, the supplied default of 440 KB) and by using SIZE/MAINSIZE=MAX with DSA at 32 or more (the supplied default is 64), or SIZE/MAINSIZE=nM with n set to at least the minimum value recommended in Table 1.

The DSA run-time option can be used to override the DSA installation option for a particular sort application.