In a DFSORT variable-blocked (VB) record, the four-byte Record Descriptor Word (RDW) comes before the application data. Therefore, DFSORT positions include those four bytes: data byte n is at record position n + 4. Data bytes 3–5, for example, are positions 7–9, so a three-byte character key for them is coded as SORT FIELDS=(7,3,CH,A).
What a VB record contains
VB means variable-length, blocked records. Each physical block starts with a four-byte Block Descriptor Word (BDW), and each logical record inside that block starts with its own four-byte RDW.
The RDW
The RDW belongs to one logical record. IBM describes it as “a 4-byte binary field with the length of the record in the first two bytes” in z/OS DFSORT: Getting Started, Version 3.1. The length includes the four-byte RDW itself; IBM’s example shows zeroes in bytes 3 and 4. The first application-data byte is therefore record position 5.
The BDW
The BDW belongs to the physical block, not to each logical record. It describes the block length, while each record’s RDW describes that record’s length. A single VB block can contain several complete variable-length records.
#1 Best Overall
- Murach's Mainframe COBOL
- Mike Murach & Associates
- ABIS BOOK
Convert data offsets to DFSORT positions
When documentation or a layout describes a field by its offset within the data portion, add four before coding a DFSORT field position.
| Data description | DFSORT position | Length |
|---|---|---|
| First data byte | 5 | 1 |
| Data bytes 3–5 | 7–9 | 3 |
| Data byte n | n + 4 | As defined by the field |
Worked SORT example
To sort on the third through fifth data bytes, code:
SORT FIELDS=(7,3,CH,A)
Position 7 is used because positions 1–4 are the RDW and position 5 is data byte 1. The field is three bytes long, character format, ascending order.
Rank #2
Make sure a control field exists in every record
DFSORT sort and merge fields must be present in every input record. A field that extends beyond the end of some shorter VB records is a short control field. Missing bytes have no values, so that incomplete field cannot validly be used as-is for sorting or merging.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Check the key against the guaranteed record length
Compare the key’s final DFSORT position with the shortest record that can occur. For example, a VB data set with 25 fixed data bytes and an LRECL of 45 can have logical record lengths from 29 bytes (four-byte RDW plus 25 data bytes) through 45 bytes. A key coded at positions 21–32 is valid only for records that are at least 32 bytes long. Records shorter than 32 bytes do not contain the complete key and make the control field short.
- Identify the key’s starting position and length.
- Calculate its ending position.
- Establish the minimum logical record length for the input.
- Do not use the key without handling records that are too short.
When to specify RECORD TYPE
For non-VSAM input, DFSORT determines the record type from the input data set’s RECFM and ignores a RECORD TYPE specification. Consequently, a normal VB SORTIN data set does not automatically require a TYPE statement.
In processing contexts where DFSORT needs the type explicitly—such as applicable VSAM input or an E15/E32 exit that supplies all input—use:
RECORD TYPE=V
TYPE=VB can be used as the equivalent variable-length specification. Record type can also be determined from output and OUTFIL attributes in contexts described by the DFSORT reference. Follow the RECORD control-statement rules for the z/OS and DFSORT release installed at your site.
Recommended Free Tools
Preserve the RDW when using INREC
When reformating variable-length records with INREC, the resulting record must retain or include the unedited four-byte RDW as its first field. IBM’s z/OS 2.5 INREC notes require the first FIELDS, BUILD, or IFTHEN BUILD entry to specify or include that RDW.
Practical checklist for an INREC layout
- Start the output layout with the original four-byte RDW.
- Add or rearrange data fields after the RDW.
- Recalculate the resulting record layout and lengths.
- Verify that later SORT, MERGE, OUTREC, or OUTFIL field positions refer to the new layout, including the RDW.
Diagnose common VB-position errors
Key is four bytes too early
Symptom: The sort uses bytes from the RDW or starts before the intended data. Fix: Add four to the one-based data offset. Data byte 1 is position 5, not position 1.
Key works for long records but fails for short ones
Symptom: Some records do not contain the full sort or merge field. Fix: Compare the key’s ending position with the minimum logical record length and redesign the key or handle short records before sorting or merging.
Reformatted VB output is malformed
Symptom: A variable-length INREC result has incorrect boundaries or lengths. Fix: Keep the original, unedited RDW as the first INREC output field, then validate the new record layout and length.
Free tools Windows power users keep installed
One-click scans. No signup required.
Quick Recap
Reference rules at a glance
| Question | Rule |
|---|---|
| Where does data begin? | At DFSORT position 5, after the four-byte RDW. |
| How are data offsets converted? | Add four to the one-based offset from the data area. |
| What does the RDW length cover? | The complete logical record, including the RDW. |
| What does the BDW describe? | The physical block containing one or more logical records. |
| Can a key extend past short records? | No; it becomes a short control field and is not valid as-is. |
| Is RECORD TYPE required for every VB SORTIN? | No. For non-VSAM input, RECFM determines the type and DFSORT ignores TYPE. |
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
