FILSZ Estimation

Why File Size Matters to DFSORT

A sort or merge needs work space—temporary datasets (SORTWK01, SORTWK02, …) or dynamically allocated equivalents—to hold data during the sort phases. How much work space DFSORT asks for depends on how much data it expects. When the input is a normal dataset, DFSORT can often read the dataset attributes (record count, block size, etc.) and compute the size. In other cases—for example when an E15 exit filters or generates records, or when reading from tape with compacted data—DFSORT cannot know the size in advance. In those cases, if you do not provide an estimate, DFSORT may guess. A guess that is too low leads to under-allocation: the sort runs out of space (ICE046A sort capacity exceeded, or ICE083A/SB37-04 resource errors). A guess that is too high wastes DASD and can affect how many work datasets are allocated. FILSZ is the way you tell DFSORT: “expect roughly this much data.”

What FILSZ Does

OPTION FILSZ= supplies a file size value. The exact format depends on your DFSORT version and installation. Common forms include:

• FILSZ=Ennnnnnn — The E often means “estimate.” The number may be in bytes (total size) or in record count, depending on product documentation. DFSORT uses it to derive how much sortwork to request.
• FILSZ=nnnnnnn — Some versions allow a numeric value without E when it is an exact or estimated size; again, units (bytes, blocks, records) depend on the product.

You code FILSZ in the OPTION statement in SYSIN, often alongside other options such as DYNALLOC or SIZE. Check your site’s DFSORT Application Programming Guide or installation notes for the precise syntax and units (bytes vs records vs blocks).

When FILSZ Is Required or Recommended

• E15 (or other) user exits — If an exit can add, drop, or change records, DFSORT may not know the effective input size. Providing FILSZ (based on expected record count or bytes) helps DFSORT allocate correctly.
• Compacted or special tapes — When the physical file size does not reflect the logical data volume, DFSORT cannot infer size; FILSZ fills the gap.
• Dynamic allocation (DYNALLOC) — When DFSORT dynamically allocates sortwork, it uses size estimates to decide how many and how large the work datasets should be. A reasonable FILSZ reduces the risk of ICE046A/ICE083A/SB37-04 and avoids excessive allocation.
• Very large sorts — Even when the input is a standard dataset, some shops specify FILSZ for large jobs so that allocation is consistent and documented.

Syntax and Placement

FILSZ is specified in the OPTION statement. Example (syntax may vary by site):

1
2
  OPTION FILSZ=E5000000
  SORT FIELDS=(1,80,CH,A)

Here, the value might mean 5,000,000 bytes or 5,000,000 records—confirm with your DFSORT documentation. You can combine FILSZ with other options:

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

When in doubt, provide an estimate that is slightly high rather than low, so that DFSORT allocates enough space and you avoid capacity or abend issues. Over-estimating may use more DASD but is usually safer than under-estimating.

Variable-Length Records and FILSZ

With variable-length records and dynamic allocation, DFSORT’s internal sizing uses assumptions about record length. IBM documents that:

• If the average record length is much shorter than half the maximum record length, DFSORT may over-allocate sortwork.
• If the average record length is much greater than half the maximum, DFSORT may under-allocate, which can lead to ICE046A or ICE083A.

To correct the estimate, you can scale the record count (or size) by the factor:

(average LRECL) / (max LRECL × 0.5)

So if your variable-length file has a maximum record length of 1000 bytes and an average of 200 bytes, the factor is 200 / (1000 × 0.5) = 0.4. You might then provide a FILSZ that reflects the effective data volume after this scaling, or adjust the record count you pass to FILSZ according to your product’s rules. Exact application depends on your DFSORT version; see IBM APARs and the Application Programming Guide for variable-length FILSZ handling.

Under-Allocation: ICE046A, ICE083A, SB37-04

When sortwork is too small, DFSORT can abend or issue messages:

Providing a sufficient FILSZ (and enough SORTWK or DYNALLOC headroom) helps DFSORT request adequate work space up front and reduces the chance of these failures.

Over-Allocation and Efficiency

If FILSZ is much larger than the actual data, DFSORT may request more sortwork than needed. That uses extra DASD and can increase the number of work datasets. For most jobs, slightly over-estimating is acceptable and safer than under-estimating. For very large or repeated runs, tuning FILSZ closer to the real size can make allocation more efficient; use job logs or SMF data to see actual record counts and adjust over time.

Interaction with DYNALLOC and SORTWK

When you do not allocate SORTWK datasets in JCL and use OPTION DYNALLOC, DFSORT asks the system to create work datasets. The size and number of those datasets are influenced by FILSZ (and SIZE/MOSIZE, depending on product). When you do allocate SORTWK01, SORTWK02, … explicitly, FILSZ can still help DFSORT plan how to use them (e.g. how many passes, how to split data). So FILSZ is useful both with and without DYNALLOC; with DYNALLOC it is often critical for large or variable-length inputs.

Explain It Like I'm Five

Imagine you are sorting a huge pile of cards and need to borrow tables to lay them out. If you tell the teacher “I have about 1000 cards,” they give you a few tables. If you really have 5000 cards, you run out of space and everything stops. If you say “I have about 5000 cards,” you get enough tables. FILSZ is you telling DFSORT “I have about this many cards (records)” so it can get the right number of “tables” (sortwork) and not run out or waste too many.

Exercises

1. Your sort reads from a tape that was compacted; DFSORT cannot determine the logical record count. How would you choose a FILSZ value, and where would you code it?
2. After a large sort you see ICE046A. What role might FILSZ play in resolving it, and what other options (e.g. SORTWK, DYNALLOC, SIZE) might you check?
3. You have a variable-length file with max LRECL 2000 and average 100. Why might the default FILSZ behavior be wrong, and what scaling factor (from the formula above) would you consider?
4. Look up your site’s DFSORT documentation: does FILSZ use bytes, record count, or blocks, and what is the exact keyword format (e.g. FILSZ=Ennnnnnn)?