COBOL Fixed vs Variable-Length Records: FB, VB, and FD Examples

A COBOL program does not read a file as a vague stream of bytes. The FD entry, record description, and data set attributes tell the runtime whether every row has the same size or whether each row can be different. That choice affects READ, WRITE, file status codes, and the JCL used to allocate the data set.

Match the FD to the file.

What is a fixed-length record in COBOL?

A fixed-length record has the same logical length for every record in the file. If a customer extract uses 80 bytes per row, record 1 is 80 bytes, record 2 is 80 bytes, and the last record is also 80 bytes. On z/OS, this is commonly paired with a fixed record format such as RECFM=FB.

FILE SECTION.
FD  CUSTOMER-FILE
    RECORD CONTAINS 80 CHARACTERS.
01  CUSTOMER-REC.
    05  CUSTOMER-ID        PIC X(10).
    05  CUSTOMER-NAME      PIC X(30).
    05  CUSTOMER-STATUS    PIC X(01).
    05  FILLER             PIC X(39).

This layout is easy to test because every READ returns the same shape. It is also friendly to sort, copy, and compare jobs because positions stay stable. If account status is byte 41 today, it is byte 41 on every record.

What is a variable-length record in COBOL?

A variable-length record can hold rows with different logical lengths. One record might carry only a short header. Another record might carry a detail area with repeated values. COBOL describes this with a variable record clause or with record descriptions that make the compiler infer variable format.

FILE SECTION.
FD  ORDER-FILE
    RECORD IS VARYING FROM 20 TO 400 CHARACTERS
    DEPENDING ON WS-ORDER-LENGTH.
01  ORDER-REC.
    05  ORDER-ID           PIC X(10).
    05  ITEM-COUNT         PIC 9(03).
    05  ITEM-LINE          OCCURS 1 TO 20 TIMES
                           DEPENDING ON ITEM-COUNT.
        10 ITEM-CODE       PIC X(08).
        10 ITEM-QTY        PIC 9(03).

The DEPENDING ON value must match the real data being written or read. If the program says a record is shorter than it really is, useful bytes may be missed. If it says the record is longer than it really is, the next process may see padded or leftover data.

Fixed vs variable records at a glance

Area	Fixed-length record	Variable-length record
Typical z/OS format	RECFM=FB	RECFM=VB
COBOL FD clue	RECORD CONTAINS 80 CHARACTERS	RECORD IS VARYING FROM 20 TO 400
Best fit	Stable rows, fixed reports, code tables, positional feeds	Optional fields, repeated groups, message-style records
Main support risk	Wrong LRECL or shifted field positions	Wrong length value, ODO mismatch, reader expects fixed rows

How COBOL decides the record format

IBM Enterprise COBOL can use the RECORDING MODE clause for QSAM files. RECORDING MODE F is fixed. RECORDING MODE V is variable. If you omit it, the compiler can infer the mode from the RECORD clause and the level-01 record descriptions.

If all associated level-01 records are the same size and none contains OCCURS DEPENDING ON, the file is a natural fixed-record candidate. If record descriptions differ in size, or one contains OCCURS DEPENDING ON, the file usually belongs in the variable-record camp.

JCL and data set attributes still matter

The COBOL source and the JCL allocation must agree. A COBOL program compiled for an 80-byte fixed file should not be pointed at a variable blocked file and expected to behave like nothing changed.

//FIXIN    DD DSN=PROD.CUST.FIXED,
//            DISP=SHR,
//            DCB=(RECFM=FB,LRECL=80)
//VARIN    DD DSN=PROD.ORDER.VARIABLE,
//            DISP=SHR,
//            DCB=(RECFM=VB,LRECL=404)

For variable blocked records on z/OS, remember that the data set length includes control bytes used by the access method. Your COBOL record description describes the business data. The runtime and access method handle the record and block descriptor fields outside your 01 layout.

Common mistakes

Treating VB like FB

A reader that assumes fixed positions can fail when the input is variable. Check every later step, especially sort control cards, report programs, file transfers, and quick one-off copy jobs.

Using OCCURS DEPENDING ON without setting the count

The count field is not decoration. It controls how many table entries are part of the current record. Set it before WRITE, and validate it after READ if bad input can reach the job.

Changing the FD but not the JCL

A source change can look correct and still fail in production if the DD statement or cataloged data set attributes still describe the old record format.

Production checklist

• Confirm the intended data set format: FB, VB, or another format.
• Match the COBOL FD record clause to the largest and smallest valid business record.
• Check OCCURS DEPENDING ON values before writing variable records.
• Test the shortest record, the longest record, and a normal middle-size record.
• Review downstream jobs that use SORT, COPY, FTP, or reporting tools.

Related Mainframe Forum guides

For surrounding file-handling topics, read COBOL READ Statement, COBOL OPEN Statement, COBOL File Status, COBOL File Operation, COBOL File Organization, and COBOL Block vs Unblock Records.

External references

IBM documents these rules in the Enterprise COBOL RECORDING MODE clause, defining variable-length records, and defining fixed-length records pages.

FAQ

What is the main difference between fixed and variable-length records?

A fixed-length file uses the same record size for every row. A variable-length file allows different rows to have different sizes, within the limits declared for the file.

When should I use fixed-length records?

Use fixed-length records when the layout is stable and every row can use the same length. They are simple to read, sort, compare, and support.

When should I use variable-length records?

Use variable-length records when rows naturally change size, such as records with optional trailing data or repeated groups controlled by OCCURS DEPENDING ON.

Does COBOL include RDW and BDW fields in my 01 record?

No. For normal QSAM variable records, descriptor fields are handled outside the COBOL record description. Your 01 layout describes the application data.