The RDW (Record Descriptor Word) is a 4-byte prefix at the beginning of every variable-length record in z/OS. It tells the system how long that record is so it knows how many bytes to read. The length stored in the RDW is the total length of the record—including the 4-byte RDW itself. So a record with 80 bytes of data has an RDW that contains the value 84 (4 + 80). In DFSORT, when you specify positions in control statements (SORT FIELDS, INREC, OUTREC, INCLUDE, OMIT), those positions refer to the data portion of the record: position 1 is the first byte after the RDW. DFSORT maintains the RDW when reading and writing variable-length records; you do not normally build or modify it in control statements. This page explains the RDW layout, how the length is stored, how it differs from the BDW (Block Descriptor Word), and how DFSORT uses it.
The Record Descriptor Word (RDW) is a 4-byte field that precedes the data of each variable-length record. It is used by the access method (e.g. QSAM, VSAM) and by utilities like DFSORT to determine how many bytes belong to that record. Without the RDW, the system would not know where one variable-length record ends and the next begins. So the layout of a variable-length record is: [RDW 4 bytes][data N bytes], and the value in the RDW equals 4 + N (the total length).
The exact format of the 4-byte RDW can be platform- and access-method-specific. A common layout is:
| Bytes | Content |
|---|---|
| 1–2 | Record length (binary, typically big-endian), including the 4-byte RDW |
| 3–4 | Reserved (often binary zeros or low-values) |
So for a record with 80 bytes of data, the total length is 84. In hexadecimal, 84 is 0x54. In big-endian, the first 2 bytes might be X'0054' (00*256 + 84 = 84). The system reads the RDW, gets 84, and then reads 84 bytes total for that record (including the RDW); the remaining 80 bytes are the data. Your program or DFSORT then treats "position 1" as the first of those 80 data bytes.
The length stored in the RDW is always the total length of the record, including the 4-byte RDW itself. So:
This convention lets the system read the RDW (4 bytes), interpret the length, and then read the rest of the record (length − 4 bytes of data) in one consistent way.
When DFSORT reads variable-length records from SORTIN, it reads the RDW and the data as one logical record. It uses the RDW to know how many bytes to read. When it writes to SORTOUT (if the output is VB), it writes the RDW and then the data. The RDW is not included in the position numbers you specify in control statements. So when you code:
1SORT FIELDS=(1,20,CH,A)
position 1 is the first byte of the data (the byte after the RDW). DFSORT automatically skips the RDW when applying SORT FIELDS, INREC, OUTREC, INCLUDE, and OMIT. You never have to say "position 5" to get the first data byte; position 1 is always the first data byte for variable-length records.
In variable blocked (VB) datasets, there are two descriptor words:
| Term | Meaning |
|---|---|
| RDW | Record Descriptor Word: 4 bytes at the start of each logical record; contains the record length (including RDW). |
| BDW | Block Descriptor Word: 4 bytes at the start of each physical block; contains the block length. A block can contain many records. |
So a physical block might look like: [BDW][RDW+data][RDW+data][RDW+data].... The BDW tells how long the whole block is; each RDW tells how long that record is. DFSORT works with logical records (RDW + data); the blocking (BDW) is handled by the access method.
Normally no. When you use INREC or OUTREC, you specify positions and build the data portion. DFSORT (and the access method) take care of generating or preserving the RDW when writing variable-length output. If you build a 60-byte data record and write it to a VB dataset, the product will typically write a 4-byte RDW containing 64 followed by your 60 bytes. For special cases (e.g. building the RDW explicitly), behavior is product-dependent—see your DFSORT manual.
Fixed-length (FB) records do not have an RDW. Each record is exactly LRECL bytes; the system knows the length from the DCB. So for FB, position 1 is simply the first byte of the record. The RDW exists only for variable-length (V or VB) records.
Imagine each variable-length "paper" has a tiny sticker at the very top that says "This paper is 84 lines long." That sticker is the RDW. The computer reads the sticker first, sees 84, and then reads 84 lines (including the sticker). So it knows exactly where that paper ends and the next one begins. When we talk about "line 1" of the paper, we mean the first line of the actual content, not the sticker. The sort program uses the sticker to read the right amount, but when we say "sort by the first 10 lines," we mean the first 10 lines of the content—that's why position 1 is after the RDW.
1. How many bytes is the RDW?
2. What does the length in the RDW include?
3. In DFSORT control statements, do you reference the RDW bytes as position 1–4?
4. What is the BDW in a VB block?
5. If a variable-length record has 100 bytes of data, what value (decimal) would typically be in the RDW length field?