COBOL File I/O Modes: INPUT, OUTPUT, I-O, and EXTEND

A batch job often fails before the first business rule runs because the file was opened in the wrong mode. A program that needs to read customer records should not use OPEN OUTPUT. A program that appends audit records should not recreate the file. In COBOL, the OPEN mode tells the runtime what the program plans to do with the file.

Choose the mode first.

What are COBOL file I/O modes?

COBOL file I/O modes are the phrases used with the OPEN statement: INPUT, OUTPUT, I-O, and EXTEND. They decide which file statements are valid after the file is open. If the wrong mode is used, later READ, WRITE, REWRITE, or DELETE statements can fail or damage data.

OPEN INPUT  CUSTOMER-FILE
OPEN OUTPUT REPORT-FILE
OPEN I-O    MASTER-FILE
OPEN EXTEND AUDIT-FILE

Good file handling is simple: open the file in the mode that matches the next operation, check FILE STATUS, process the records, and close the file before the program ends.

Quick comparison

OPEN mode	Use it when	Common valid statements	Main risk
INPUT	The program only reads an existing file.	READ	Fails if a required file is missing.
OUTPUT	The program creates a new file or replaces old records.	WRITE	Can clear existing records when used on the wrong file.
I-O	The program reads records and updates them.	READ, REWRITE, DELETE	Can fail when the organization or access mode does not allow updates.
EXTEND	The program appends new records after the last record.	WRITE	Fails for a missing non-optional file and is not valid for every file type.

OPEN INPUT: read an existing file

Use OPEN INPUT when the program reads records and does not change the file. A daily balance report, customer extract reader, or validation job usually opens the input file this way.

SELECT CUSTOMER-FILE ASSIGN TO CUSTIN
    FILE STATUS IS WS-CUST-STATUS.

OPEN INPUT CUSTOMER-FILE
IF WS-CUST-STATUS NOT = "00"
   DISPLAY "CUSTOMER OPEN FAILED: " WS-CUST-STATUS
   GOBACK
END-IF

If the required data set is missing, a typical status is 35. If the file is declared OPTIONAL, the open can succeed with a different status, so support teams should check the program's SELECT clause before assuming the JCL is wrong.

OPEN OUTPUT: create or replace records

Use OPEN OUTPUT for a new output file, such as a report, extract, or unload file. Be careful with existing files. On many jobs, opening an existing file for output means the old contents are replaced by new data.

SELECT REPORT-FILE ASSIGN TO REPTDD
    FILE STATUS IS WS-REPT-STATUS.

OPEN OUTPUT REPORT-FILE
IF WS-REPT-STATUS = "00"
   WRITE REPORT-REC
ELSE
   DISPLAY "REPORT OPEN FAILED: " WS-REPT-STATUS
END-IF

This is the mode that deserves the most review in production changes. A wrong DD name or copied program can point OPEN OUTPUT at a valuable file and replace records that were meant to be kept.

OPEN I-O: read and update records

Use OPEN I-O when the same file is read and changed. A VSAM KSDS maintenance program may read a customer master record, change a field, and then issue REWRITE. A delete program may read a key and then issue DELETE.

OPEN I-O CUSTOMER-MASTER
IF WS-MASTER-STATUS NOT = "00"
   DISPLAY "MASTER OPEN FAILED: " WS-MASTER-STATUS
   GOBACK
END-IF

READ CUSTOMER-MASTER
   INVALID KEY DISPLAY "CUSTOMER NOT FOUND"
END-READ

REWRITE CUSTOMER-MASTER-REC
   INVALID KEY DISPLAY "REWRITE FAILED"
END-REWRITE

I-O is not a shortcut for every file. The file organization, access mode, and data set allocation must support update processing. If a file is sequential and the program only needs to append new rows, EXTEND is often the clearer choice.

OPEN EXTEND: append new records

Use OPEN EXTEND when the program must keep existing records and add new records at the end. Audit logs, transaction history files, and daily append files often use this mode.

OPEN EXTEND AUDIT-FILE
IF WS-AUDIT-STATUS = "00"
   MOVE WS-AUDIT-TEXT TO AUDIT-REC
   WRITE AUDIT-REC
ELSE
   DISPLAY "AUDIT OPEN FAILED: " WS-AUDIT-STATUS
END-IF

If the file may not exist yet, review whether the file should be defined as OPTIONAL. IBM documents different open results for available and unavailable files, so this choice should be deliberate rather than left to a copied file definition.

File status codes to check after OPEN

Every production COBOL program should check FILE STATUS after OPEN. The exact value depends on file organization and runtime behavior, but these statuses appear often in support work.

Status	Typical meaning during OPEN	First check
00	Open completed normally.	Continue processing.
05	Optional file was not available, but open processing continued.	Confirm whether SELECT OPTIONAL is intended.
35	Required file was not found or not available.	Check the DD statement, catalog entry, and data set name.
39	File attributes do not match the COBOL description.	Compare RECFM, LRECL, keys, and record layout.

JCL checks before changing the mode

The COBOL source is only half of the story. The DD statement must point to the right data set and allow the intended action. Before changing an open mode, check the production JCL and scheduler variables.

//CUSTIN   DD DSN=PROD.CUSTOMER.INPUT,DISP=SHR
//REPTDD   DD DSN=PROD.REPORT.DAILY,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(5,2)),
//            DCB=(RECFM=FB,LRECL=133)

For read-only files, DISP=SHR is common. For new output files, the job often uses DISP=(NEW,CATLG,DELETE). For update jobs, review enqueue rules, restart behavior, and whether another job can read the same data set while updates are running.

Common mistakes

Opening an input file as OUTPUT

This is the dangerous one. A copy-paste change can replace a file that should only be read. Review OPEN OUTPUT statements carefully during code review.

Skipping FILE STATUS after OPEN

If the program does not test the status, the next READ or WRITE may fail far away from the real problem. Log the DD name and status so production support can act quickly.

Using EXTEND when the file is not optional

OPEN EXTEND can fail when a required file is missing. If the first run should create the file, define and test that behavior before the job reaches production.

Practical rule for choosing the mode

• Use INPUT when the program only reads.
• Use OUTPUT when the program creates a new result or intentionally replaces old contents.
• Use I-O when the program reads existing records and updates or deletes them.
• Use EXTEND when the program keeps existing records and appends new ones.
• Always check FILE STATUS immediately after the OPEN.

Related Mainframe Forum guides

For the next file-handling topics, read COBOL File Operation, COBOL OPEN Statement, COBOL READ Statement, COBOL File Status, COBOL File Organization, and COBOL FD Entries.

External references

IBM documents these details in the Enterprise COBOL OPEN statement, OPEN statement notes, and opening ESDS, KSDS, and RRDS files pages.

FAQ

Which COBOL open mode is used for reading?

Use OPEN INPUT when the program only needs to read records from an existing file.

Which COBOL open mode appends records?

Use OPEN EXTEND when the program needs to add records after the last existing record.

Can COBOL read and update the same file?

Yes, but the file must be opened with OPEN I-O, and the file organization and access mode must support the update operation.

Why is OPEN OUTPUT risky?

OPEN OUTPUT is risky because it can replace existing records. Use it only when the job is meant to create a fresh output file or clear old contents.

COBOL Disk I/O: How z/OS Reads and Writes Data

READ CUSTOMER-FILE asks COBOL for one logical record. It does not tell a disk arm to find one sector. On z/OS, the COBOL run time and an access method such as QSAM manage buffers and blocks, the channel subsystem handles the I/O request, and the storage controller may satisfy that request from cache before any back-end media access is needed.

A COBOL record request passes through QSAM, asynchronous I/O services, and cached DASD storage.

COBOL record I/O versus physical storage I/O

COBOL programs work with records defined under an FD. A sequential READ returns the next logical record; a WRITE supplies one logical record. The program normally does not address a track, cylinder, or sector.

QSAM places physical blocks in buffers. One block can contain one record or several records, depending on RECFM, LRECL, and BLKSIZE. If the requested record is already in an input buffer, QSAM can return it without starting a new device I/O. If an output buffer has room, a WRITE can add the record without immediately sending a block to the device.

Keep the units separate: the COBOL statement handles a logical record, QSAM transfers physical blocks, and CKD track geometry belongs below the application interface.

What happens during a COBOL READ

1. The program issues READ CUSTOMER-FILE.
2. The COBOL run time asks QSAM for the next logical record.
3. If that record is already in a QSAM input buffer, it is moved or made available to the program.
4. If another block is required, z/OS starts an I/O request through the channel subsystem.
5. The storage controller checks its cache. A cache hit can satisfy the read without accessing back-end media.
6. After the block reaches the QSAM buffer, QSAM returns the required logical record and retains other records in the block for later reads.

The COBOL sequential-file guide shows the surrounding OPEN INPUT, READ, end-of-file, and CLOSE logic.

What happens during a COBOL WRITE

1. The program fills its output record and issues WRITE CUSTOMER-RECORD.
2. QSAM places the logical record in an output buffer.
3. When the block is ready to be written, the access method submits the I/O request.
4. The channel subsystem carries the request to the control unit and storage system.
5. A modern storage system can accept the write into protected cache and later destage the data to its managed media.
6. CLOSE completes access-method processing, including the final partially filled output block.

Use the correct open mode for the operation. The COBOL file I/O modes guide distinguishes INPUT, OUTPUT, I-O, and EXTEND.

Why the channel subsystem matters

IBM Z does not require a central processor to control every byte transfer. The channel subsystem accepts the I/O request and communicates with control units and devices independently. While one task waits for its read or write, z/OS can dispatch other ready work on the processors.

A subchannel represents an I/O device to the operating system, and a channel path supplies a route between the processor complex and external equipment. Multiple paths and storage functions can affect availability and response time, but those details remain outside ordinary COBOL source code.

Tracks and cylinders are CKD address concepts

Traditional z/OS DASD uses count-key-data or extended count-key-data formatting. A cylinder contains a fixed number of tracks, and each track contains formatted records. z/OS still exposes CKD-compatible volumes and device types such as 3390 even when the storage system implements them on modern cached hardware.

The old post treated a sector, a physical head, and a COBOL record as if they formed one direct path. That physical-disk description is not a safe model for a current z/OS application. The companion DASD tracks, cylinders, and data-set layout article owns the storage-geometry intent; this page owns the runtime I/O path.

Why storage cache changes the read path

For a read, the controller can return data already present in cache. IBM calls this a cache hit. A cache miss requires the storage system to obtain the requested data from a lower storage layer, so response time can be higher.

For writes, enterprise storage uses cache and nonvolatile protection so the host request does not have to mirror the timing of a literal platter write. Storage tools therefore report metrics such as cache-hit percentage, I/O rate, bandwidth, response time, and write-cache delay.

Do not diagnose current DASD performance from actuator movement alone. Start with host response-time data and storage metrics, then determine whether the delay is in the access method, channel path, cache, control unit, or back-end storage.

Where blocks and buffers affect performance

For a large QSAM sequential pass, blocked records reduce the number of physical I/O requests compared with transferring one record per block. Additional QSAM buffers can also allow access-method processing to overlap more effectively with the program, at the cost of storage.

Use system-determined blocking for eligible new sequential data sets unless an interface requires a specific value. The detailed COBOL blocked-versus-unblocked records guide covers FB, VB, BLKSIZE, blocking factor, and BLOCK CONTAINS 0.

COBOL and JCL example

SELECT CUSTOMER-FILE ASSIGN TO CUSTIN
    ORGANIZATION IS SEQUENTIAL
    FILE STATUS IS WS-FILE-STATUS.

FD  CUSTOMER-FILE
    RECORDING MODE IS F
    BLOCK CONTAINS 0 RECORDS
    RECORD CONTAINS 100 CHARACTERS.
01  CUSTOMER-RECORD PIC X(100).

READ CUSTOMER-FILE
    AT END SET END-OF-FILE TO TRUE
END-READ

//CUSTIN  DD DSN=APP.CUSTOMER.MASTER,
//            DISP=SHR

For an existing cataloged input data set, the DD statement does not need to repeat its DCB attributes. At OPEN, the program description must be compatible with the actual data set. A mismatch can produce file status 39. The COBOL file-operations guide covers OPEN, READ, WRITE, REWRITE, and status handling.

How to investigate a slow I/O-bound step

1. Confirm the DD name, data-set organization, RECFM, LRECL, and BLKSIZE.
2. Separate sequential access from random access; they create different request patterns.
3. Compare elapsed time with CPU time to see whether the step spends substantial time waiting.
4. Review I/O count, average response time, transfer size, cache-hit percentage, and delay fields in the monitoring data available at your site.
5. Check whether the access method and buffer count match the workload.
6. Ask storage support to correlate host measurements with controller metrics before changing allocation rules.

EXCP counts are useful when the access method reports them, but one EXCP is not the same as one physical media access. Caching, channel programs, access-method behavior, and storage implementation break that one-to-one assumption.

Common misconceptions

Misconception	Better model
One COBOL READ equals one sector read.	One READ returns one logical record; QSAM may already hold it in a buffered block.
One EXCP equals one physical disk movement.	An EXCP reflects an access-method I/O request, while cache and storage implementation affect physical activity.
A cylinder always describes literal rotating platters.	For z/OS work, cylinder and track are CKD-compatible address and allocation units presented by DASD.
COBOL controls the channel path.	COBOL requests record I/O; z/OS and the channel subsystem manage device communication.
A faster CPU always fixes a slow batch step.	An I/O-bound step can remain limited by response time, request pattern, buffering, or storage delay.

Related record and file definitions

Record format changes how a block is interpreted. Review fixed versus variable-length COBOL records for FB, VB, RDW, and FD examples. The sequential-file FD entries guide covers the file description clauses that establish the program view.

Official IBM references

• IBM: z/OS data-set structure, DASD, cylinders, tracks, records, and blocks
• IBM: Channel subsystem and asynchronous I/O
• IBM: Using QSAM files and I/O buffers
• IBM: DS8000 I/O, response-time, and cache metrics
• IBM: DS8000 cache, cache hit, and DASD fast-write terms

COBOL disk I/O FAQ

Does a COBOL READ access one disk sector?

No. A COBOL READ requests one logical record. QSAM can return it from an existing input buffer or request another physical block. The storage controller can then satisfy that I/O from cache or obtain the required data from its managed storage.

What is the difference between a record and a block?

A logical record is the unit processed by the COBOL program. A physical block is the transfer unit used by a non-VSAM access method such as QSAM and can contain one or several logical records.

Why can COBOL continue while an I/O request is active?

IBM Z uses a channel subsystem that performs I/O independently of the central processors. The requesting task can wait, and the processors can dispatch other ready work while the device operation proceeds.

Which measurements help diagnose slow DASD I/O?

Check elapsed time, I/O response time, I/O rate, transfer size, cache-hit percentages, and delays reported by host and storage monitoring. EXCP counts can help for some access methods, but they are not a complete latency measure.

Read the measurements in the same layers as the request: COBOL record, QSAM buffer and block, channel-subsystem I/O, storage cache, then DASD volume.

COBOL Sequential File Organization: READ, WRITE, and EOF

A daily billing job often reads yesterday's transaction file from top to bottom, totals the amounts, writes a report, and stops when it reaches end-of-file. That is the natural fit for COBOL sequential file organization: records are processed in the order they were written.

Read records in stored order.

What is a COBOL sequential file?

A sequential file stores records in a fixed order. IBM describes sequential organization as a predecessor-successor relationship: each record, except the first and last, has one record before it and one record after it. A program reads the records one after another.

Sequential organization works well when the job processes most or all records. Payroll extracts, report input files, unload files, tape files, and batch interface files often use this style.

How sequential access works

With sequential access, the program cannot jump directly to record 200 without reading the earlier records first. That sounds limiting, but it is efficient for full-file processing because records are read in order and can be blocked.

OPEN INPUT EMPLOYEE-FILE

PERFORM UNTIL WS-END-OF-FILE = 'Y'
   READ EMPLOYEE-FILE
      AT END
         MOVE 'Y' TO WS-END-OF-FILE
      NOT AT END
         PERFORM PROCESS-EMPLOYEE
   END-READ
END-PERFORM

CLOSE EMPLOYEE-FILE

FILE-CONTROL example

The FILE-CONTROL paragraph connects the COBOL file name to an external data set or ddname. If the ORGANIZATION clause is omitted, IBM Enterprise COBOL assumes ORGANIZATION IS SEQUENTIAL, but coding it explicitly is easier for learners and code reviewers.

ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
    SELECT EMPLOYEE-FILE
        ASSIGN TO EMPIN
        ORGANIZATION IS SEQUENTIAL
        ACCESS MODE IS SEQUENTIAL
        FILE STATUS IS WS-EMP-STATUS.

FD and record layout example

The FD entry describes the file in the FILE SECTION. The record description that follows tells COBOL how to move bytes from the file buffer into fields.

DATA DIVISION.
FILE SECTION.
FD  EMPLOYEE-FILE
    RECORD CONTAINS 80 CHARACTERS.
01  EMPLOYEE-RECORD.
    05 EMPLOYEE-ID        PIC X(06).
    05 EMPLOYEE-NAME      PIC X(30).
    05 EMPLOYEE-DEPT      PIC X(04).
    05 EMPLOYEE-SALARY    PIC 9(07)V99.
    05 FILLER             PIC X(31).

Sequential file operations

Operation	Typical statement	Common use
Read existing records	OPEN INPUT, READ	Batch input, report input, unload processing.
Create a new file	OPEN OUTPUT, WRITE	New extract or report file.
Add records at the end	OPEN EXTEND, WRITE	Append records to an existing sequential file.
Update current record	REWRITE	Allowed only in the proper open/access context and without changing fixed record length.

QSAM, VSAM ESDS, and line sequential

On z/OS, COBOL sequential files are commonly handled through QSAM for physical sequential data sets or through VSAM for ESDS files. IBM also documents line-sequential files for z/OS UNIX files, where records contain character data and end with a newline-style record delimiter.

QSAM sequential file

Use QSAM when the job reads or writes a physical sequential data set, including many tape and batch interface files. It is the normal choice for simple full-file processing.

VSAM ESDS

A VSAM entry-sequenced data set is also sequential by nature. Records are stored in entry order. Use ESDS when the site design needs VSAM services but the program still processes records sequentially.

Line sequential

Line-sequential files are character-oriented files. IBM notes that they are used for z/OS UNIX file-system data and each record ends with a record delimiter. They are not the same thing as a standard MVS QSAM data set.

When to sort a sequential file

A sequential file is often useful only when it is in the order the program expects. A billing job may need account number order. A report may need department order. If the incoming file arrives in a different order, sort it before the COBOL step or use a COBOL SORT statement when that fits the site standard.

//SORTIN   DD DSN=PROD.TRANS.UNSORTED,DISP=SHR
//SORTOUT  DD DSN=PROD.TRANS.BYACCT,DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(20,5)),UNIT=SYSDA
//SYSIN    DD *
  SORT FIELDS=(1,10,CH,A)
/*

Performance notes

Sequential files are fast when the program reads a large percentage of the file. IBM guidance says sequential access is usually faster than random or dynamic access when a large percentage of records is referenced or updated. The weak pattern is a program that repeatedly scans the same file looking for one record.

• Use blocking for batch files instead of reading tiny physical blocks.
• Process the file in the same order as the business key when possible.
• Avoid reading the same file from the beginning inside another loop.
• Use a sort, indexed file, database table, or lookup table when direct retrieval is needed.

Sequential vs indexed vs relative

Need	Better file organization	Reason
Read all records in order	Sequential	Simple and efficient for full-file batch work.
Find records by customer number	Indexed	Key access avoids scanning the whole file.
Access records by relative number	Relative	Record number controls placement and lookup.
Read text files in z/OS UNIX	Line sequential	Records are character data with delimiters.

Common mistakes

Using sequential files for repeated single-record lookup

If the program reads 500,000 records to find one account, and does that thousands of times, the file organization is probably wrong for the access pattern. Consider indexed access, DB2, or a preloaded table.

Missing file status checks

Always define a file status field and check it in error paths. End-of-file is expected. Status values such as open failure, write failure, or record-length issues need a message and a clear return code.

Confusing sequential and line sequential

A line-sequential file is not just a QSAM file with a different name. It is character-oriented and delimiter-based, so trailing blanks and record lengths can behave differently.

Related COBOL file topics

For nearby file-handling topics, read COBOL File Operation, COBOL File I/O Modes, COBOL File Status, COBOL Fixed and Variable Records, COBOL Indexed Sequential File, and COBOL Relative Organization.

External references

Technical notes in this refresh were checked against IBM COBOL file organization documentation, IBM guidance for choosing file organization and access mode, and IBM FILE-CONTROL paragraph documentation.

FAQ

What is sequential file organization in COBOL?

It is a file organization where records are processed in the order they were placed in the file. The program reads records one after another until end-of-file.

Can a COBOL sequential file be read randomly?

No. A sequential file is read sequentially. Use indexed or relative organization when the program needs random or dynamic access.

When is a sequential file a good choice?

Use it for full-file batch processing, reports, unloads, tape files, and interface files where most records are read or written in order.

Is line sequential the same as sequential?

No. Line sequential is character-oriented and delimiter-based, often used for z/OS UNIX files. Standard sequential files on z/OS are commonly QSAM or VSAM sequential files.

JCL Spanned Records: RECFM=VBS, LRECL=X, and Safe Usage

A JCL DD statement with DCB=(RECFM=VBS,LRECL=X) tells z/OS that a logical record may be too large to fit in one physical block. The record is still one record to the program, but the access method can store it as segments across more than one block.

One record can span blocks.

What is a spanned record in JCL?

A spanned record is a variable-length logical record that is stored in pieces when the full record does not fit into a single block. You normally see this on sequential data sets that carry long business records, large print records, XML-like payloads, or converted reports where one logical row can grow past the normal block boundary.

In everyday batch work, most files use FB or VB. A fixed blocked file has the same record length on every row. A variable blocked file can hold records of different sizes, but each logical record still fits inside a block. A spanned variable file, commonly coded as VBS, allows one logical record to continue into the next block when needed.

When should you use RECFM=VBS?

Use RECFM=VBS only when the application has a real need for very long variable records. It is not a default choice for normal transaction files, control files, extract files, or small report feeds. If every record is short enough for a normal VB file, keeping RECFM=VB is simpler and easier for downstream jobs to handle.

Record format	Meaning	Common use
FB	Fixed blocked records	Flat files where every record has the same length
VB	Variable blocked records	Files where records have different lengths but fit inside a block
VBS	Variable blocked spanned records	Files where one logical record may need more than one block

JCL example for a spanned record data set

The DD statement usually carries the record format in the DCB parameter. Existing shops may also let SMS data classes supply these attributes, so check local standards before hard-coding every value.

//STEP010  EXEC PGM=MYPROG
//OUTFILE  DD  DSN=PROD.REPORT.LONGREC,
//             DISP=(NEW,CATLG,DELETE),
//             SPACE=(CYL,(20,10),RLSE),
//             DCB=(RECFM=VBS,LRECL=X)

The LRECL=X part is used for QSAM when the logical record length can be greater than 32,760 bytes. That is the detail many short notes miss. Without it, someone may copy RECFM=VBS into a job and still fail when the record length is not described correctly for the access method and program.

How RDW, BDW, and segments fit together

Variable records include a record descriptor word, usually called an RDW. Variable blocked records also use a block descriptor word, usually called a BDW, at the start of a block. In a spanned file, z/OS needs extra segment information so it can rebuild the logical record correctly when the record has been split across blocks.

For a COBOL or assembler program, the useful rule is simple: the program should process the logical record, not guess at physical block pieces. If a program reads the file through the normal access method, it should receive the data according to the file definition and program definition. Problems usually appear when a utility, copy program, FTP setup, or downstream reader assumes ordinary VB records.

Why DISP=MOD can be risky with spanned records

The old warning about DISP=MOD is worth keeping. Appending to a spanned-record data set can introduce short-block behavior that surprises later processing. If a job must add more records, the safer pattern is often to create a new output data set and copy or merge the old and new data with a controlled utility step.

//BADAPPND DD DSN=PROD.REPORT.LONGREC,
//            DISP=MOD
//*
//* Better: build a new output generation, then replace by standard process.

That approach also gives operations a cleaner restart point. A failed append can leave the support team asking whether the last logical record was complete, whether the block was closed correctly, and which downstream job consumed the partial file.

Checks before using a spanned record file

Before moving this kind of file into production, check the data set attributes, the program definition, and every job that reads the file. One weak reader in a later step can turn a good file design into a late-night incident.

• Confirm that the producing program really needs records larger than a normal variable blocked file can handle.
• Check whether the consumer supports RECFM=VBS, especially sort, copy, transfer, reporting, and unload steps.
• Use a naming standard or comment that tells support staff why the file is spanned.
• Avoid casual append processing with DISP=MOD.
• Test the longest realistic record, not only a small sample file.

Common mistakes

Using VBS for a normal file

Some developers use VBS because it sounds more flexible than VB. That adds a special case where none is needed. If the largest record is comfortably within the normal limit, VB is usually easier for utilities and support teams.

Forgetting the downstream jobs

A file may be created correctly and still fail in a later step. Check any JCL SORT, copy, archive, and transfer process that reads the data set.

Copying only the DCB line

The DCB line is only one part of the design. Space allocation, restart rules, file transfer rules, and program record definitions must match the expected long records.

Related Mainframe Forum guides

For the surrounding JCL basics, read JCL Tutorial: JOB, EXEC and DD Statements, JCL DD Statement, and JCL Data Set Protection. If the output is kept as generations, also review Generation Data Group in JCL.

External references

IBM documents the main record formats, including fixed, variable, blocked, undefined, and spanned formats, in its z/OS record-format material. See IBM: Data set record formats and IBM: Record formats for the formal wording.

FAQ

What does RECFM=VBS mean?

RECFM=VBS means variable blocked spanned records. Records can have different lengths, more than one record can be placed in a block, and a single logical record can continue into another block.

Is RECFM=VBS the same as RECFM=VB?

No. VB handles variable blocked records where each logical record fits in a block. VBS handles variable blocked records that may span blocks.

Why is LRECL=X used with spanned records?

For QSAM, LRECL=X indicates that the logical record length can be greater than 32,760 bytes. Use it only when the program and data set design require that behavior.

Should I use DISP=MOD with spanned records?

Avoid it unless your site has a tested standard for that exact case. Creating a new output data set is usually easier to restart, audit, and support.