SIZE Tuning

What SIZE/MOSIZE Controls

During a sort, DFSORT builds runs of sorted data in memory and then merges them, often using sortwork datasets when data does not fit in memory. The maximum size of the memory objects used for this work is what SIZE (or MOSIZE) limits or specifies. A larger value means DFSORT can use more central storage for the sort, so more data can be processed in memory before being written to SORTWK. That typically means fewer I/Os to work datasets and sometimes fewer merge passes, which can improve elapsed time. So SIZE/MOSIZE is a primary lever for memory-based tuning.

Ways to Specify SIZE/MOSIZE

Exact keyword and syntax depend on your DFSORT version. Common forms:

With MOSIZE=p%, “available” central storage is determined by the system at run time; the actual amount used can vary from run to run depending on system load and other DFSORT (or other) tasks. With MOSIZE=n (fixed MB), you get a predictable cap. Your installation may have defaults or limits; check your DFSORT Application Programming Guide for the exact option name (SIZE vs MOSIZE) and allowed values.

Syntax Examples

1
2
  OPTION SIZE=MAX
  SORT FIELDS=(1,80,CH,A)

1
2
  OPTION MOSIZE=50,FILSZ=E10000000,DYNALLOC
  SORT FIELDS=(20,4,PD,D)

In the second example, MOSIZE=50 might mean “use up to 50% of available central storage” for sort memory objects; FILSZ and DYNALLOC help with sortwork planning and allocation. Combine these as needed for your job size and site standards.

Why Increase SIZE for Large Sorts

• Fewer sortwork writes — More memory means longer runs in memory, so less data is written to SORTWK.
• Fewer merge passes — Fewer initial runs can mean fewer passes over sortwork during the merge phase.
• Better elapsed time — Less I/O and fewer passes often translate to shorter run times for large files.

IBM’s tuning recommendations for large DFSORT tasks emphasize providing adequate memory (SIZE/MOSIZE), a good file size estimate (FILSZ), and sufficient sortwork (SORTWK or DYNALLOC). So SIZE is one of several parameters to tune together.

Risks of Setting SIZE Too High

If you set SIZE/MOSIZE very high, DFSORT may request a large amount of central storage. That can:

• Reduce memory available for other address spaces or the system.
• Hit region or address-space limits (the job may not get as much as requested).
• Be capped by the product (e.g. a maximum MB value documented by IBM).

So the goal is to give DFSORT enough memory for good performance without starving other work. Many shops use a percentage (e.g. MOSIZE=50) so that the amount scales with what is available, or a fixed MB value that has been validated for their workload.

Interaction with FILSZ and DYNALLOC

FILSZ tells DFSORT how much data to expect; it influences how much sortwork is requested and how the sort is planned. SIZE/MOSIZE determines how much memory is used for sort objects. DYNALLOC controls whether and how many work datasets are allocated dynamically. If FILSZ is too low, DFSORT may under-allocate sortwork (risk of ICE046A/ICE083A) even if SIZE is large. If SIZE is too small, DFSORT may do more I/O to sortwork and run longer even if FILSZ and DYNALLOC are set. So for large sorts, tune all three: provide a realistic FILSZ, an appropriate SIZE/MOSIZE, and enough sortwork (explicit or via DYNALLOC).

ICE046A and Memory vs Sortwork

ICE046A (sort capacity exceeded) usually means DFSORT ran out of sortwork space or resources, not necessarily that it ran out of memory. So increasing SIZE=MAX alone may not fix it. You typically need to increase sortwork (more or larger SORTWK datasets, or more DYNALLOC) and ensure FILSZ is sufficient. SIZE tuning helps performance; sortwork and FILSZ help avoid capacity failures.

Variable-Length Records

For variable-length records, DFSORT’s sizing uses assumptions about record length. If the effective data volume is misestimated (e.g. with DYNALLOC and no FILSZ, or a wrong FILSZ), you can get over- or under-allocation of sortwork regardless of SIZE. See the FILSZ estimation and DYNALLOC tutorials for the average/max LRECL adjustment; that affects sortwork planning. SIZE still controls memory; FILSZ and DYNALLOC affect work datasets.

Explain It Like I'm Five

When you sort cards, you can either use a big desk (memory) to hold lots of cards at once, or use many small tables (sortwork). The bigger the desk (SIZE), the more cards you can sort on it before needing the tables. So a bigger desk means you need fewer tables and fewer trips to the tables—faster sorting. But if the desk is too big, there’s no room for anyone else! So we pick a desk size that’s big enough to help but not so big it causes problems.

Exercises

1. Your large sort is slow and you have region to spare. What option would you consider increasing first, and what other options (FILSZ, DYNALLOC) should you review?
2. You set SIZE=MAX and still get ICE046A. What does that tell you about the cause, and what would you check next?
3. Look up your DFSORT documentation: is the keyword SIZE or MOSIZE, and can you specify both a percentage and a fixed MB? What is the maximum value allowed?
4. Why might a shop prefer MOSIZE=50% over MOSIZE=2048 (fixed 2048 MB)? When might the fixed value be better?