DFSORT Dynamic Allocation

What Dynamic Allocation Means

When you run a sort, DFSORT needs temporary work space (sortwork) to hold data that does not fit in memory. You can provide that space by coding SORTWK01, SORTWK02, … in your JCL and specifying space (e.g. SPACE=(CYL,(100,20))) on each. That is static or explicit allocation: you decide in advance how many work datasets and how much space. With dynamic allocation, you do not code those DDs (or you code fewer). Instead, you specify OPTION DYNALLOC, and DFSORT requests that the system (MVS) create and allocate work datasets when the step runs. The system allocates them according to its rules (default unit, SMS ACS, installation). So “dynamic” means the allocation happens at run time, in response to DFSORT’s request, rather than from your fixed JCL definitions.

Why Use Dynamic Allocation?

• Variable data size: When the amount of data to be sorted changes from run to run (e.g. different input files), you may not know in advance how much sortwork to reserve. With DYNALLOC, DFSORT uses FILSZ to estimate and requests what it needs. You set FILSZ (or let the product infer it when possible), and the allocation adapts.
• Simpler JCL: You avoid maintaining a long list of SORTWK01 through SORTWKnn. That reduces JCL size and the chance of under- or over-allocating when requirements change.
• Fewer catalog or static definitions: Dynamically allocated work datasets are temporary; they are created for the step and then deleted. You do not need to pre-define them or manage their names.

The trade-off is that you typically cannot specify which volume or storage group gets the work datasets. Allocation follows system defaults, SMS policy, or installation setup. If your site requires sortwork on specific devices (e.g. for performance or policy), you use explicit SORTWK DDs instead.

Dynamic vs Explicit Sortwork

Role of FILSZ

With dynamic allocation, DFSORT must tell the system how much space it needs. It does that based on an estimate of the data volume—the file size estimate, or FILSZ. You provide FILSZ in the OPTION statement (e.g. OPTION DYNALLOC,FILSZ=E5000000 for an estimate of 5 million bytes or the format your product uses). If FILSZ is too low, DFSORT requests too little sortwork and the sort can fail with ICE046A (sort capacity exceeded) or with space/resource abends (e.g. SB37, ICE083A). So when using DYNALLOC, a realistic or slightly high FILSZ is critical. See the FILSZ estimation tutorial for how to compute or specify FILSZ. When you use explicit SORTWK, FILSZ is still useful for planning (e.g. for the product’s internal logic), but you control total space by how many SORTWK DDs you provide and how much space you give each.

Example: Using DYNALLOC

To use dynamic allocation, add OPTION DYNALLOC and a good FILSZ. Exact syntax is product-dependent; the following is illustrative.

1
2
3
  OPTION DYNALLOC,FILSZ=E10000000
  SORT FIELDS=(1,80,CH,A)
  INREC FIELDS=(1,80)

Here FILSZ might represent an estimate of 10 million bytes of input (or the unit your product expects). DFSORT uses that to request enough sortwork. For the exact FILSZ format (e.g. bytes vs records, E vs other prefixes), see your DFSORT Application Programming Guide and the FILSZ estimation tutorial. For full DYNALLOC syntax (e.g. DYNALLOC=(,n) for number of work datasets), see the DYNALLOC tutorial.

When Both SORTWK and DYNALLOC Are Coded

Some jobs code both SORTWK DDs and OPTION DYNALLOC. Behavior depends on your installation. In some installations, an option such as DYNAUTO=IGNWKDD is in effect: DFSORT then ignores your SORTWK DDs and uses only dynamically allocated work. In others, DFSORT uses your SORTWK datasets first and may allocate more dynamically if it needs additional space. To avoid confusion, check your site’s DFSORT installation guide. If your site ignores SORTWK when DYNALLOC is on, then coding SORTWK has no effect and you rely entirely on FILSZ and DYNALLOC for sizing.

Performance and Tuning

Dynamic allocation does not by itself make the sort faster or slower; it only changes how sortwork is obtained. Performance still depends on: having enough sortwork (so FILSZ and DYNALLOC limits must be sufficient), having enough memory (SIZE/MOSIZE), and optionally blocksize and device choice. With DYNALLOC you usually do not control volume or BLKSIZE directly—installation defaults or SMS apply. So for performance tuning, ensure FILSZ is realistic (and, if supported, consider DYNALLOC=(,n) to allow enough work datasets). If you need to place sortwork on specific fast volumes or tune BLKSIZE, use explicit SORTWK DDs. See sortwork datasets, blocksize tuning, and tuning parameters.

ICE046A and Resource Failures

If you get ICE046A (sort capacity exceeded) or space/resource abends when using DYNALLOC, the usual cause is insufficient sortwork. Increase FILSZ to a realistic value (or slightly high). If your product supports it, you can also increase the number of dynamic work datasets (e.g. OPTION DYNALLOC=(,16)) so that more work datasets are allocated. Check installation limits on how many work datasets or how much space can be dynamically allocated. Also ensure REGION and SIZE/MOSIZE are adequate; if the step cannot use enough memory, it spills more to sortwork and may exceed what was allocated. See the DYNALLOC tutorial for option syntax and the sortwork datasets tutorial for capacity planning.

Explain It Like I'm Five

You need boxes to put sorted piles of cards in. You can bring your own boxes and put them in a row (SORTWK in JCL), or you can tell the grown-up how many cards you have and they bring boxes for you (FILSZ and DYNALLOC). The second way is “dynamic”: you don’t have to bring boxes yourself, but you have to say how many cards so they bring enough. If you say too few cards, they bring too few boxes and you get stuck (ICE046A). You also can’t choose exactly where they put the boxes (which volume); they put them where the rules say. So dynamic is easier if you don’t care where the boxes go and you give a good estimate.

Exercises

1. Your job uses OPTION DYNALLOC and fails with ICE046A. What would you check first and how would you fix it?
2. When would a site choose explicit SORTWK DDs instead of DYNALLOC?
3. How does FILSZ affect what happens when DYNALLOC is used?