DFSORT Blocksize Tuning

Why Blocksize Matters

Sortwork datasets hold intermediate data when the sort does not fit entirely in memory. Every time DFSORT reads from or writes to sortwork, it does so in units of one block. So the total number of I/O operations is (data volume) / (block size), roughly speaking. A larger BLKSIZE means fewer blocks for the same data, hence fewer I/Os. I/O has a cost in elapsed time (and possibly CPU), so reducing the number of I/Os by increasing BLKSIZE—within limits—can improve performance when sortwork I/O is a significant part of the job.

BLKSIZE and LRECL Relationship

BLKSIZE should be a multiple of LRECL. For fixed-length records, each block then holds an integer number of records (e.g. BLKSIZE=32760, LRECL=80 → 409 records per block). If BLKSIZE is not a multiple of LRECL, you get partial records spanning blocks or wasted space, and the product may not support it or may behave in a product-specific way. For variable-length records, the block usually includes record descriptors (e.g. RDW); the product documentation specifies how LRECL and BLKSIZE relate (e.g. max record length vs block size). Always set LRECL to match (or exceed) the maximum record length of your data; then choose BLKSIZE as a multiple of LRECL that fits within device and product limits.

Device and Product Limits

DASD and other devices have maximum block sizes. For many z/OS DASD types, the maximum BLKSIZE is 32,760 bytes. Exceeding the device limit can cause allocation or I/O errors. The DFSORT product may also impose a maximum BLKSIZE. So when tuning, you choose a value that is: (1) a multiple of LRECL, (2) no larger than the device maximum, (3) no larger than the product maximum, and (4) reasonable for buffer space—each open dataset may use buffers proportional to BLKSIZE, and the step’s region must accommodate them. Tuning guides often recommend a value in the range of several thousand to the device maximum (e.g. 32760) for large sorts, depending on record length and buffer constraints.

Explicit SORTWK DDs: Where You Set BLKSIZE

When you code SORTWK01, SORTWK02, … in JCL, you control the DCB (or equivalent) for each dataset. You specify BLKSIZE and LRECL (and optionally other DCB parameters) so that they match your sort record length and your tuning goals. Example (illustrative):

1
2
3
//SORTWK01 DD DSN=&&SW1,DISP=(NEW,PASS),
//   SPACE=(CYL,(100,10)),UNIT=SYSDA,
//   DCB=(RECFM=FB,LRECL=80,BLKSIZE=32760)

Here LRECL=80 matches an 80-byte fixed-length record; BLKSIZE=32760 is a multiple of 80 (32760/80=409) and is a common maximum for DASD. So each block holds 409 records, and I/O is efficient. For a different LRECL (e.g. 256), you might use BLKSIZE=32768 (128*256) or 32256 (126*256), staying within 32760.

Dynamic Allocation (DYNALLOC)

When DFSORT uses OPTION DYNALLOC to allocate sortwork dynamically, it does not use your JCL SORTWK DDs (or may ignore them depending on installation). The dynamically allocated work datasets get their attributes from installation defaults, SMS ACS, or product-specific options. So you may not directly set BLKSIZE for each dynamic work dataset; the installation or SMS determines it. Some products allow specifying block size or DCB attributes for dynamic allocation; see your DFSORT Application Programming Guide and installation notes. If you need precise control over BLKSIZE and LRECL, use explicit SORTWK DD statements. If you rely on DYNALLOC, ensure your installation’s defaults or ACS deliver an appropriate BLKSIZE (multiple of LRECL, within device limits).

Buffer Management

DFSORT manages its own buffers for sortwork and typically ignores or overrides BUFNO (or equivalent) that you might specify on the DD. So the main way to influence sortwork I/O efficiency is through BLKSIZE (and having enough sortwork space). The product allocates buffers based on its internal logic; larger BLKSIZE means more data per I/O but may mean more buffer memory per dataset. The step REGION must be large enough for the product’s buffer and memory needs; see memory usage and tuning parameters for REGION and SIZE.

Variable-Length Records

For variable-length records, sortwork typically uses RECFM=VB (or similar). LRECL usually indicates the maximum record length (including the RDW if applicable). BLKSIZE must accommodate the block descriptor word (BDW) and multiple variable-length records. The product documentation specifies the exact relationship. The same principle applies: larger BLKSIZE (within limits) reduces I/O count; BLKSIZE and LRECL must be set according to product and device rules.

Putting It Together

For a large sort with explicit SORTWK DDs: (1) Set LRECL to match (or exceed) your record length. (2) Choose BLKSIZE as a multiple of LRECL, as large as is practical within device (e.g. 32760) and product limits and without exhausting buffer/region. (3) Ensure you have enough SORTWK datasets (or DYNALLOC) so that capacity is sufficient; blocksize tuning improves I/O efficiency once you have enough space. When using DYNALLOC, rely on installation defaults or product options for BLKSIZE and verify they are appropriate for your record length.

Explain It Like I'm Five

Imagine moving toys from your room to the garage in boxes. Small boxes mean more trips; big boxes mean fewer trips. BLKSIZE is like the size of the box. Bigger boxes (up to a limit) mean fewer trips (I/Os) and faster work. But the box has to fit whole toys (BLKSIZE a multiple of LRECL), and you can’t use a box bigger than the door (device limit). So we pick a box size that fits the toys and the door and makes fewer trips.

Exercises

1. Your sort uses fixed-length records of 200 bytes. What BLKSIZE would you choose for SORTWK if the device max is 32,760? Why?
2. Why might DFSORT ignore BUFNO on SORTWK? What should you tune instead?
3. You use DYNALLOC for sortwork. How can you influence the BLKSIZE of the dynamically allocated datasets?