Sortwork datasets (SORTWK) are temporary work space DFSORT uses when the data to be sorted does not fit entirely in memory. The product writes partially sorted segments (runs) to sortwork and then performs merge passes until one sorted run remains, which it writes to SORTOUT. If sortwork space is insufficient, the sort fails (e.g. ICE046A). You can provide sortwork by coding SORTWK01, SORTWK02, … in JCL or by using OPTION DYNALLOC so DFSORT allocates it dynamically. This page explains what sortwork is, how DFSORT uses it, how much you need, and how to provide it (explicit DDs vs DYNALLOC).
During a sort, DFSORT reads input records and builds sorted runs. As long as the data fits in the allocated memory (SIZE/MOSIZE), it can do much of the work in central storage. When the data exceeds that capacity, it must write runs to some other storage—that storage is sortwork. Sortwork datasets are typically on DASD (disk). DFSORT writes runs to them, and in subsequent merge passes it reads from sortwork, merges runs, and writes merged runs back. So sortwork is the “second tier” of storage: memory first, then sortwork. Without enough sortwork, the sort cannot complete when data exceeds memory.
| Term | Meaning |
|---|---|
| SORTWK | DD name for a sortwork dataset (SORTWK01, SORTWK02, …); DFSORT uses them for overflow when memory is full. |
| Run | A sorted segment of data; DFSORT writes runs to sortwork and merges them. |
| Merge pass | Reading multiple runs from sortwork, merging into a larger run, writing back; repeated until one run remains. |
| ICE046A | Sort capacity exceeded; often due to insufficient sortwork or underestimated FILSZ. |
| DYNALLOC | OPTION that lets DFSORT dynamically allocate sortwork instead of using pre-coded SORTWK DDs. |
The amount of sortwork needed depends on the volume of data to be sorted, the amount of memory (SIZE/MOSIZE), record length, and the product’s internal algorithms. Roughly, when data exceeds memory, the “overflow” goes to sortwork; merge passes may require additional space (multiple runs exist temporarily). DFSORT uses the FILSZ (file size estimate) you provide to plan how much sortwork to request when using DYNALLOC, or to guide you in how much to allocate when you use explicit SORTWK. If FILSZ is too low, DFSORT may request too little sortwork (with DYNALLOC) or you may allocate too little (with SORTWK), and the job can fail with ICE046A. So a realistic—or slightly high—FILSZ is important, and when using explicit SORTWK you must provide enough DDs and space to cover the estimated need. See the FILSZ estimation tutorial for how to set FILSZ.
You can define sortwork datasets in JCL with DD names SORTWK01, SORTWK02, SORTWK03, and so on. Each DD defines one work dataset. You specify the space (e.g. SPACE=(CYL,(100,20)) or TRK) and optionally DCB (LRECL, BLKSIZE, RECFM) to match your sort. DFSORT uses these datasets in an order and manner determined by the product. You must provide enough datasets and enough total space. Example (illustrative):
123456//SORTWK01 DD DSN=&&SW1,DISP=(NEW,PASS),SPACE=(CYL,(500,50)),UNIT=SYSDA, // DCB=(RECFM=FB,LRECL=80,BLKSIZE=32760) //SORTWK02 DD DSN=&&SW2,DISP=(NEW,PASS),SPACE=(CYL,(500,50)),UNIT=SYSDA, // DCB=(RECFM=FB,LRECL=80,BLKSIZE=32760) //SORTWK03 DD DSN=&&SW3,DISP=(NEW,PASS),SPACE=(CYL,(500,50)),UNIT=SYSDA, // DCB=(RECFM=FB,LRECL=80,BLKSIZE=32760)
Here three work datasets are provided, each with 500 cylinders primary and 50 secondary. The total space and number of DDs must be sufficient for your sort; if not, you get ICE046A or space abends. For very large allocations (e.g. over 4,369 cylinders per volume), you may need DSNTYPE=LARGE or multi-volume; check your installation.
With OPTION DYNALLOC, DFSORT does not require you to code SORTWK01, SORTWK02, … in JCL. Instead, it requests that the system (MVS) dynamically allocate work datasets. DFSORT uses FILSZ (and product logic) to decide how much space to request and how many work datasets to create. That simplifies JCL and adapts to varying input sizes. You must still provide a realistic FILSZ so DFSORT requests enough. Installation options (e.g. limits on how many dynamic work datasets or how much space) may apply. For full details on DYNALLOC syntax and behavior, see the DYNALLOC and dynamic allocation tutorials.
ICE046A usually means DFSORT ran out of sortwork (or hit a capacity limit). Common causes: (1) FILSZ was too low, so with DYNALLOC too little was allocated. (2) Too few or too small SORTWK datasets when using explicit DDs. (3) Memory (SIZE/MOSIZE) was very small, so almost everything spilled to sortwork and exceeded what was provided. Fixes: increase FILSZ to a realistic value, provide more or larger SORTWK datasets, or increase DYNALLOC limits if applicable. Also ensure REGION is large enough so DFSORT can use the memory you intended (SIZE/MOSIZE); otherwise it may spill more than expected. See tuning parameters and FILSZ estimation.
Sortwork datasets have a record format and block structure. LRECL should match (or accommodate) the record length of your sort data; BLKSIZE should be a multiple of LRECL for efficiency. Larger BLKSIZE can reduce I/O count. When you use explicit SORTWK DDs, you set these in the DD’s DCB. When you use DYNALLOC, the product or installation defaults determine them. See the blocksize tuning tutorial for BLKSIZE and LRECL guidance.
The more memory (SIZE/MOSIZE) DFSORT has, the less data spills to sortwork. So increasing memory can reduce sortwork requirement and sortwork I/O, which can improve performance. But you still need enough sortwork for whatever does spill. So both memory and sortwork must be sufficient: memory to reduce spill and improve speed, sortwork to avoid ICE046A when spill occurs. See memory usage and tuning parameters.
Imagine sorting cards on a table. When the table is full, you put sorted piles into boxes (sortwork). You need enough boxes for all the piles. If you run out of boxes (not enough sortwork), you can’t finish (ICE046A). You can bring your own boxes (SORTWK in JCL) or tell the grown-ups how many cards you have so they bring enough boxes (FILSZ and DYNALLOC). A bigger table (memory) means fewer piles to put in boxes, but you still need enough boxes for whatever doesn’t fit on the table.
1. What are sortwork datasets used for in DFSORT?
2. What happens when sortwork runs out of space?
3. How can you provide sortwork to DFSORT?
4. What influences how much sortwork DFSORT needs?
5. For large allocations (e.g. over 4,369 cylinders), what may be required in JCL?