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 AWO Compiler Option: APPLY WRITE-ONLY for QSAM Files

A COBOL job that writes variable-length QSAM records can waste output buffer space when every block is cut for the largest possible record. The AWO compiler option applies APPLY WRITE-ONLY behavior to eligible files, so the buffer is written only when the next record will not fit. On the right file shape, that can reduce EXCPs and improve batch run time.

Use AWO for eligible VB output.

What is the COBOL AWO compiler option?

AWO stands for APPLY WRITE-ONLY. IBM documents that it activates APPLY WRITE-ONLY processing for physical sequential files with variable blocked format. The default is NOAWO.

In practical terms, AWO helps COBOL use output blocks more efficiently for QSAM files that have variable-length blocked records. It is a file-output option, not a general CPU tuning switch for every program.

AWO vs NOAWO

Option	Behavior	Good fit
NOAWO	Does not add implicit APPLY WRITE-ONLY to eligible files.	Programs that do not write variable blocked QSAM output, or programs where existing behavior must stay unchanged.
AWO	Applies APPLY WRITE-ONLY processing to eligible files.	Programs that write blocked variable-length QSAM files, especially when record sizes vary a lot.

How APPLY WRITE-ONLY changes buffering

Without APPLY WRITE-ONLY, the buffer can be written when there is not enough space left for the maximum-size record. With APPLY WRITE-ONLY, the buffer is written only when the next actual record does not fit in the unused part of the buffer.

That difference matters when output records vary in size. If many records are much smaller than the maximum record length, the program can fit more records into each block and issue fewer I/O calls.

Eligible file shape

AWO matters for physical sequential QSAM files with blocked variable-length records. It does not help a fixed-block file in the same way, and it is not meant for VSAM output.

SELECT OUT-FILE ASSIGN TO OUTDD.

FD  OUT-FILE
    RECORDING MODE IS V
    BLOCK CONTAINS 0 RECORDS.
01  OUT-REC.
    05 OUT-ID      PIC X(10).
    05 OUT-TEXT    PIC X(500).

The file must still be defined correctly in JCL. Check RECFM=VB, LRECL, and block-size rules with the storage and operations standards used at your site.

How to specify AWO

The exact place depends on your compile procedure. Some shops set compiler options in cataloged procedures or build tools. For a source-level example, the option can appear in a CBL statement.

CBL AWO

IDENTIFICATION DIVISION.
PROGRAM-ID. WRITVB.

ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
    SELECT OUT-FILE ASSIGN TO OUTDD.

Keep the compile listing or build record with the change. AWO is easy to forget because it changes generated file handling code without changing the visible WRITE statement.

Performance expectation

IBM performance guidance says AWO can save time because fewer calls are made to data management services for input and output handling. IBM also gives examples where programs writing variable-length files ran faster with fewer EXCPs. Treat those examples as proof that the option can matter, not as a promise for every program.

The biggest gains usually come from output files with large variation in record length. If every output record is close to the maximum length, there may be little room to improve block usage.

AWO and BLOCK0

BLOCK0 can make more physical sequential files use system-determined block sizes when the FD does not specify a block size. IBM notes that when BLOCK0 is in effect, AWO might apply to more files because more files may become blocked.

That interaction is useful, but it also means the change deserves testing. A compile-option change can affect more files than the one the developer had in mind.

When to avoid AWO

Avoid treating AWO as a blanket answer for all I/O performance problems. It is useful only for a specific file pattern. Be careful when a job depends on immediate write behavior, custom recovery assumptions, or exact timing of output availability during execution.

If the written record must be forced out as soon as possible, IBM performance guidance recommends avoiding AWO. That is uncommon for ordinary batch output files, but it can matter for special operational files.

Review checklist before changing AWO

• Confirm the file is physical sequential QSAM output.
• Confirm the records are variable-length and blocked.
• Check whether record sizes vary enough to benefit from better buffer use.
• Review BLOCK0 because it can increase the files where AWO applies.
• Compare EXCP count, CPU time, and elapsed time before and after the compile change.
• Keep the compiler listing and JCL evidence with the change record.

Common mistakes

Using AWO on the wrong file type

AWO is not a VSAM tuning option and does not help ordinary fixed-block files in the same way. Start by checking the FD and JCL.

Ignoring the block-size setup

AWO works with blocked variable-length output. If the file is not blocked, review BLOCK CONTAINS, BLOCK0, and the JCL before expecting a result.

Comparing only elapsed time

Elapsed time can move because of system load. Compare EXCPs and CPU time too, especially when the job runs in a busy batch window.

Related Mainframe Forum guides

For nearby topics, read COBOL fixed vs variable-length records, COBOL file organization, COBOL WRITE statement, COBOL BLOCK0 compiler option, and COBOL performance tuning.

External references

IBM documents performance-related compiler options, APPLY WRITE-ONLY buffer behavior, and Enterprise COBOL option comparison.

FAQ

What does AWO do in COBOL?

AWO applies APPLY WRITE-ONLY processing to eligible physical sequential files with variable blocked records.

What is the default for AWO?

IBM documents the default as NOAWO, meaning the compiler does not implicitly apply APPLY WRITE-ONLY to eligible files.

When does AWO help most?

AWO helps most when a program writes blocked variable-length QSAM records and the actual record sizes vary enough to improve buffer use.

Does AWO apply to VSAM files?

No. The AWO compiler option is for eligible physical sequential QSAM files, not VSAM files.