DFSORT uses central storage (memory) to hold records and perform the sort. The more memory it has, the more data it can process in memory before writing to sortwork datasets, which can reduce I/O and improve performance. This page explains how DFSORT uses memory, what limits it (SIZE/MOSIZE and REGION), what happens when data exceeds memory (spill to sortwork), and how to tune memory usage for large sorts or to reduce impact on other jobs.
During a sort, DFSORT reads input records and builds sorted runs in memory. As long as the data fits in the allocated memory, it can complete the sort in memory (or with minimal spill). When the data exceeds that capacity, it writes sorted segments (runs) to sortwork datasets and then performs merge passes: reading from sortwork, merging runs, and writing back until one sorted run remains. So memory is the “first tier” of sort storage; sortwork is the second. More memory means fewer runs written to sortwork and often fewer merge passes, which reduces I/O and can significantly improve elapsed time for large sorts.
Two things limit how much memory DFSORT can use:
For large sorts, set both: SIZE/MOSIZE to the amount of memory you want DFSORT to use, and REGION to at least that amount (plus overhead for the program and buffers). Otherwise the sort may use less memory than you expect and rely more on sortwork.
| Term | Meaning |
|---|---|
| Central storage | Main memory (real storage) used by the address space; REGION limits it for the step. |
| Memory object (MO) | Block of memory DFSORT uses for sort work; size limited by SIZE/MOSIZE. |
| Sortwork (SORTWK) | DASD datasets that hold data when it does not fit in memory; I/O to sortwork can dominate elapsed time. |
| REGION | JCL EXEC parameter; maximum address space for the step; must be ≥ effective memory use. |
When the volume of data to be sorted is larger than the allocated memory, DFSORT does not fail (as long as there is enough sortwork). It writes initial sorted runs to SORTWK datasets. The number and size of these runs depend on memory size and record size. Then it merges: reading multiple runs, merging them into a larger run, writing back. It repeats until one run remains, which is then written to SORTOUT. So sufficient sortwork space is essential when data exceeds memory. If sortwork is insufficient, you get ICE046A (sort capacity exceeded). Tuning memory (SIZE, REGION) reduces the amount of data that goes to sortwork and can reduce the number of merge passes; tuning sortwork (DYNALLOC, SORTWK count/size) ensures there is enough space when data does spill.
To let DFSORT use more memory: (1) Increase OPTION SIZE or MOSIZE (e.g. higher percentage or more MB). (2) Increase the step REGION in JCL so the step has enough address space (e.g. REGION=0M for system default, or REGION=512M for a specific value). (3) Ensure the system has enough central storage so that granting the region and the memory does not cause paging or impact other workloads. Balance: more memory can speed up the sort but uses more of the system’s resources.
If you want to limit how much memory DFSORT uses (e.g. to avoid impacting other jobs on the system), specify a smaller SIZE or MOSIZE. For example, use a lower percentage (e.g. MOSIZE=10) or a fixed value (e.g. SIZE=64 for 64 MB). The sort will then use more sortwork I/O and may run longer, but it will consume less central storage. Make sure you still have enough sortwork (SORTWK or DYNALLOC) and a realistic FILSZ so the sort can complete successfully.
FILSZ tells DFSORT how much data to expect; it is used to plan sortwork allocation, not to limit memory. So you can have a large FILSZ (lots of data) and a large SIZE (lots of memory): DFSORT will use memory first and spill the rest to sortwork. Or a large FILSZ and a small SIZE: more will spill to sortwork. Sortwork (SORTWK or DYNALLOC) must be sufficient for whatever spills; FILSZ helps DFSORT request enough. So memory (SIZE, REGION) and sortwork (and FILSZ for planning) work together: memory reduces how much goes to sortwork; sortwork must be there when memory is full.
Imagine you’re sorting cards on a table. The table is like memory: the bigger the table, the more cards you can lay out and sort without putting any in boxes. When the table is full, you put sorted piles into boxes (sortwork). Later you take boxes back to the table and merge the piles. A bigger table means fewer boxes and less carrying. The “room” you’re in (REGION) has to be big enough for the table; if the room is tiny, you can’t have a big table no matter what. So: big table (SIZE) + big room (REGION) = less use of boxes (sortwork) and faster sorting.
1. What does DFSORT use central storage (memory) for?
2. What limits how much memory DFSORT can use?
3. What happens when the sort data exceeds the allocated memory?
4. Why might increasing REGION improve sort performance?
5. What is a memory object in DFSORT context?