COBOL Performance Tuning: Compiler Options and Runtime Tips

A COBOL batch job that runs for four hours rarely has one magic fix. The slow part may be a table search inside a million-record loop, a small QSAM block size, a SORT returning control record by record, decimal data that needs extra sign handling, or a production compile still using development options. Good COBOL performance tuning starts with evidence from the job log, SMF data, Application Performance Analyzer, RMF, or the site tool your shop uses.

Measure before changing options.

What is COBOL performance tuning?

COBOL performance tuning means reducing CPU time, elapsed time, I/O waits, storage pressure, or chargeable cost without changing the business result. On z/OS, that usually means checking the program logic, compile options, Language Environment settings, file handling, DB2 or VSAM access, and SORT usage together.

The compile listing is the first low-effort check. It shows the actual compiler options used at your site, including any installation defaults that were applied even when the JCL did not specify them.

Start with measurement

Do not tune a job from memory or from a copied option list. Capture the current behavior first. A small change that reduces CPU but increases elapsed time may still be a bad trade in a nightly batch window.

Signal	What it tells you	Where to look
CPU time	Program instruction cost.	Job log, SMF, performance tool.
Elapsed time	Wall-clock batch window impact.	Scheduler history, job output, SMF.
EXCP or I/O count	Dataset access cost.	SMF, job accounting, monitor reports.
DB2 calls	SQL access path and fetch volume.	DB2 accounting, EXPLAIN, package stats.
Abends or bad data	Options may be hiding data issues.	SYSUDUMP, CEEDUMP, application logs.

Compiler options that affect runtime

IBM lists several Enterprise COBOL compiler options that can affect runtime behavior. The right setting depends on the compiler level, processor level, program data, and whether the compile is for test or production.

OPT, ARCH, and TUNE

IBM recommends OPT(2), ARCH(x), and TUNE(y) for best Enterprise COBOL 6 performance. Choose ARCH for the oldest processor where the program may run, including disaster recovery. Choose TUNE for the processor where it usually runs. TUNE must be equal to or higher than ARCH.

//COBOL.SYSIN DD *
       CBL OPT(2),ARCH(12),TUNE(12)
       IDENTIFICATION DIVISION.
       PROGRAM-ID. PAYTUNE.
       ...
/*

Do not copy the sample values blindly. A module compiled for a higher ARCH level can fail if it is moved to an older machine.

TEST and SSRANGE

TEST and SSRANGE are useful during testing and debugging. They can also add overhead. For production, many shops move to NOTEST or a lower-impact debug setting, and NOSSRANGE after bounds issues have been tested. Keep the site standard and audit requirements in mind.

NUMPROC, TRUNC, and ARITH

Numeric options can affect both speed and correctness. NUMPROC(PFD) can reduce extra sign-fix processing, but only when packed and display numeric data contains preferred signs. TRUNC(OPT) can avoid extra binary truncation code, but it assumes data follows the declared picture and usage. ARITH(EXTEND) allows larger intermediate decimal results and can cost more CPU for decimal-heavy programs.

DYNAM, RENT, and THREAD

DYNAM can make maintenance easier because called subprograms can be replaced without relinking the main load module. It can add call overhead. RENT and THREAD may be needed for the runtime environment, but do not treat them as free speed settings. Use them because the program and environment need them.

File I/O tuning

Many COBOL batch jobs spend more time waiting on data than calculating. For QSAM files, check block size, record format, buffering, and whether the file is read in the best sequence. IBM notes that AWO can reduce calls to data management services for QSAM variable-mode output files, and BLOCK0 can let the system determine block size for eligible QSAM output files.

Check these file items

• Use sensible block sizes instead of forcing tiny blocks.
• Read the file in key or physical sequence when the job allows it.
• Avoid opening and closing the same file repeatedly inside a loop.
• Use the file status field so failed I/O does not trigger wasteful retry paths.
• For VSAM, check whether the access pattern matches KSDS, ESDS, RRDS, or LDS usage.

SORT and FASTSRT

If a COBOL program uses the SORT statement, check whether FASTSRT applies. IBM describes FASTSRT as a way for DFSORT or an equivalent product to handle input and output without returning to COBOL after each record. Not every sort is eligible, so verify the compile listing and SORT messages.

       SORT SORT-FILE
            ON ASCENDING KEY SORT-ACCOUNT
            USING INPUT-FILE
            GIVING OUTPUT-FILE.

When the SORT step is the bottleneck, also review SORT work space, input order, record length, and whether the sort belongs inside COBOL or as a separate JCL SORT step.

Code patterns that often cost CPU

Compile options help, but source code still matters. A clean compile cannot save a program that searches a 50,000-row table for every input record when a sorted table, binary search, or indexed lookup would fit the problem better.

Look for these patterns

• Linear table searches inside high-volume loops.
• Repeated date or string conversion for the same value.
• Moving large group items when only one elementary field is needed.
• Calling a small subprogram millions of times when inline logic would be safer and faster.
• Repeated SQL singleton SELECTs where one cursor fetch can reduce DB2 calls.

A practical tuning checklist

1. Capture current CPU, elapsed time, I/O count, and major waits.
2. Read the compile listing and record the actual compiler options.
3. Check whether production modules are still compiled with debug-heavy settings.
4. Review hot loops, table searches, calls, file reads, and SQL calls.
5. Change one major item at a time and rerun the same workload.
6. Keep a note of the old value, new value, test data, and measured result.

Safe production approach

Tuning should go through the same control path as any other production change. Recompile with the chosen options, compare output files, compare return codes, check numeric totals, and keep the old load module available for rollback. For money fields and packed decimals, include bad-data tests before changing NUMPROC, TRUNC, or ARITH.

Related COBOL tuning topics

For specific compiler option notes, read COBOL OPTIMIZE Compiler Option, COBOL ARITH Compiler Option, COBOL FASTSRT Compiler Option, COBOL AWO Compiler Option, COBOL SSRANGE Compiler Option, COBOL TEST Compiler Option, and COBOL NUMPROC Compiler Option.

External references

Technical notes in this refresh were checked against IBM guidance for tuning COBOL 6 compiler options, IBM performance-related compiler options, and IBM Enterprise COBOL compiler options.

FAQ

Which COBOL compiler options usually affect performance?

Common options include OPT, ARCH, TUNE, FASTSRT, AWO, NUMPROC, TRUNC, ARITH, SSRANGE, TEST, DYNAM, and THREAD.

Should production COBOL always use OPT(2)?

IBM recommends OPT(2) for best Enterprise COBOL 6 performance, but production settings must match your shop standard, debug needs, data quality, and processor compatibility.

Can compiler options fix slow SQL?

No. If the main cost is DB2 access, review SQL predicates, indexes, EXPLAIN output, fetch count, and commit pattern. COBOL compile options will not fix a bad access path.

When should I use FASTSRT?

Use FASTSRT when the COBOL SORT is eligible and the site SORT product can handle the input and output path more efficiently than record-by-record COBOL control.

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.