VLSHRT

Two Meanings of VLSHRT

The name VLSHRT stands for "variable-length short." In older or product-specific documentation it refers to how DFSORT handles variable-length (VB) records that are shorter than the maximum record length (LRECL). In that context, VLSHRT may allow or optimize handling of "short" VB records (e.g. not padding them to full length). The behavior can be product- and version-dependent. The meaning you will use most often is SUM overflow: when you sum a numeric field and the total is larger than the output field can hold, VLSHRT means "truncate to fit" and NOVLSHRT means "do not truncate; fail on overflow." This page focuses on the SUM overflow behavior, which applies to both fixed-length (FB) and variable-length (VB) datasets.

SUM Overflow: The Problem

When you use SUM FIELDS=(position, length, format), DFSORT adds the values in that field across all records in each key group and writes the total back into the same position and length in the output record. So the output field has the same number of bytes as the input field. If the total is larger than can be represented in that many bytes (e.g. you sum 1000 values of 99999 in a 5-byte field—the total can be 99,999,000, which needs more than 5 digits), you get overflow. The question is: should DFSORT truncate the value to fit (and continue) or should it stop and report an error? VLSHRT and NOVLSHRT answer that question.

VLSHRT: Truncate to Fit

With OPTION VLSHRT (or when VLSHRT is the default), if the summed value overflows the output field length, DFSORT truncates the result so it fits in the field. The job continues and writes the truncated value. Truncation usually drops high-order digits (or the value is reduced to fit the format), so the stored total can be wrong. For example, a true total of 1,234,567 in a 5-byte zoned decimal field might be stored as 34567 or a similar truncated value. So VLSHRT avoids an abend but at the cost of possible silent data loss. Use VLSHRT when you prefer the job to complete and accept that overflow might produce incorrect totals, or when you have validated that overflow cannot occur (e.g. small groups and small values).

NOVLSHRT: Fail on Overflow

With OPTION NOVLSHRT, if the sum overflows the output field, DFSORT does not truncate. Instead, the step terminates with an overflow error (e.g. an ICE message or abend). You then fix the problem: increase the size of the summed field (e.g. use INREC to build a longer numeric field and SUM that), or correct the data so the total fits. NOVLSHRT is the safe choice when the totals must be correct—for example in financial reporting, audit trails, or any aggregation where silent truncation would be unacceptable. Many sites use NOVLSHRT in production for SUM and rely on proper field sizing (via INREC) to avoid overflow.

Syntax and Placement

Specify VLSHRT or NOVLSHRT on the OPTION statement in SYSIN. You can combine them with other options. Example:

1
2
3
  OPTION NOVLSHRT
  SORT FIELDS=(1,10,CH,A)
  SUM FIELDS=(21,5,ZD)

Some DFSORT versions also allow the option on the SUM statement itself, for example:

1
2
  SORT FIELDS=(1,10,CH,A)
  SUM FIELDS=(21,5,ZD),NOVLSHRT

If both OPTION and SUM specify the behavior, the SUM-level option may override for that statement; see your product documentation. When in doubt, specify OPTION NOVLSHRT so the whole step fails on any overflow.

Avoiding Overflow: Field Sizing

Instead of relying on truncation or failure, you can avoid overflow by making the summed field large enough. The output field has the same position and length as the input field. So if you SUM a 5-byte field, the result must fit in 5 bytes. To allow larger totals, use INREC before the sort to build a record that has a longer numeric field in the sum position. For example, move the original 5-byte amount into bytes 21–28 as an 8-byte field, then SORT FIELDS=(1,10,CH,A) and SUM FIELDS=(21,8,ZD). The sum is written into 8 bytes, which can hold a much larger total. Estimate the maximum possible sum (e.g. max value per record × max records per group) and choose a length that can hold that value in the format you use (PD, ZD, etc.). See the "Handling overflow" tutorial for byte-length guidelines.

Variable-Length (VB) Record Handling

In addition to SUM overflow, VLSHRT/NOVLSHRT can affect how DFSORT handles variable-length (VB) records that are shorter than the maximum record length. VB records have a 4-byte RDW (Record Descriptor Word) followed by the data; the actual length of each record can be less than LRECL. VLSHRT may allow or optimize processing of these "short" records (e.g. not padding them to full length, or handling them in a way that saves space or time). NOVLSHRT may use a different strategy (e.g. padding or different internal handling). The exact effect is product-dependent. If you use VB input and encounter odd behavior with SUM or record length, try switching between VLSHRT and NOVLSHRT and check your product manual for "variable-length short" or "VLSHRT" in the context of VB.

When to Use Each

• Use NOVLSHRT when you sum numeric fields and must guarantee correct totals. The step will fail on overflow so you can fix the layout or data. Recommended for production aggregation and financial data.
• Use VLSHRT when you have validated that overflow cannot occur (e.g. small groups and small values), or when you accept that in rare cases a truncated total might be written and you prefer the job not to abend. Less common in production for critical totals.

Examples

Sum a 5-byte ZD field and fail if the total overflows (safe for production):

1
2
3
  OPTION NOVLSHRT,EQUALS
  SORT FIELDS=(1,8,CH,A)
  SUM FIELDS=(9,5,ZD)

Same sort and sum, but allow truncation (faster completion if overflow occurs; use with caution):

1
2
3
  OPTION VLSHRT
  SORT FIELDS=(1,8,CH,A)
  SUM FIELDS=(9,5,ZD)

Explain It Like I'm Five

Imagine you are adding up how much money each friend has. You have a small box to write the total. If the total is too big for the box, with VLSHRT we squeeze the number in and only part of it fits (so the number might be wrong). With NOVLSHRT we stop and say "the number doesn’t fit in the box—get a bigger box or check the numbers." So VLSHRT = "fit it in even if wrong"; NOVLSHRT = "don’t fit it in, tell me so I can fix it."

Exercises

1. You sum a 4-byte PD field; max value per record is 999,999 and you have up to 100 records per group. Can the total overflow 4 bytes? What should you do?
2. Why is NOVLSHRT often preferred over VLSHRT for financial aggregation?
3. How can you avoid overflow without using NOVLSHRT? (Hint: INREC and field length.)
4. Your VB file has short records and SUM gives odd results. What option might you try changing?