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 FASTSRT Compiler Option: When DFSORT Handles Sort I/O

A COBOL program that sorts a million records with SORT ... USING and SORT ... GIVING can spend extra CPU passing control back to COBOL for file input and output. The FASTSRT compiler option changes that path for eligible sorts: DFSORT, or a comparable sort product, performs the input and output instead of Enterprise COBOL.

Let DFSORT handle eligible I/O.

What is the COBOL FASTSRT compiler option?

FASTSRT controls whether the sort product performs input and output for eligible COBOL SORT and MERGE operations. IBM documents the default as NOFASTSRT. With FASTSRT, the sort product can handle files named in USING or GIVING, which avoids returning to COBOL after each record is read or written.

FASTSRT vs NOFASTSRT

Option	Who handles sort file I/O?	Best fit
NOFASTSRT	Enterprise COBOL	Sorts that need COBOL file error semantics, file status behavior, or unsupported file handling.
FASTSRT	DFSORT or comparable sort product	Eligible direct file sorts using USING and/or GIVING, especially high-volume batch sorts.

Simple eligible SORT example

This direct sort is the kind of pattern where FASTSRT can help. The program gives COBOL an input file and an output file, and no custom input or output procedure is needed.

CBL FASTSRT

SELECT INPUT-FILE  ASSIGN TO INFILE.
SELECT SORT-FILE   ASSIGN TO SORTWK.
SELECT OUTPUT-FILE ASSIGN TO OUTFILE.

SD  SORT-FILE.
01  SORT-REC.
    05 SORT-ACCOUNT-NO     PIC X(10).
    05 SORT-DATE           PIC X(8).
    05 SORT-AMOUNT         PIC S9(9)V99 COMP-3.

PROCEDURE DIVISION.
    SORT SORT-FILE
       ON ASCENDING KEY SORT-ACCOUNT-NO
       USING INPUT-FILE
       GIVING OUTPUT-FILE
    GOBACK.

For this shape, the sort product can perform the file I/O when the full list of FASTSRT requirements is met.

When FASTSRT does not help much

FASTSRT does not remove the COBOL logic in an INPUT PROCEDURE or OUTPUT PROCEDURE. If the program must inspect each record, run business rules, and call subprograms before releasing records to the sort, most of the cost may still be in COBOL logic.

SORT SORT-FILE
   ON ASCENDING KEY SORT-ACCOUNT-NO
   INPUT PROCEDURE 2000-BUILD-SORT-RECS
   OUTPUT PROCEDURE 3000-WRITE-REPORT.

Use FASTSRT as a file-I/O improvement for eligible paths, not as a cure for expensive record-level business processing.

Important restrictions

SORTIN and SORTOUT DFSORT options

IBM notes that you cannot use DFSORT SORTIN or SORTOUT options when using FASTSRT. The COBOL USING and GIVING files define the input and output for the statement.

Line-sequential files

FASTSRT does not apply to line-sequential files used as USING or GIVING files. If the program sorts text-style line-sequential data, do not expect this option to change that path.

FILE STATUS behavior

IBM documents that if file status is specified and FASTSRT is used, file status is ignored during the sort. Keep NOFASTSRT when COBOL file error semantics must be preserved for the sort processing.

DCB and sort work files

The compiler can check many FASTSRT eligibility rules, but IBM notes two checks that are not fully verified at compile time: whether sort work files use a device other than direct-access storage, and whether input or output file DCB parameters match the FD. Check the JCL and file definitions before promotion.

How to decide whether to use FASTSRT

• Use it first on simple SORT ... USING ... GIVING programs.
• Check whether COBOL file status handling is needed during the sort.
• Confirm the sort work data sets and DCB information match site standards.
• Compare CPU time, EXCP counts, elapsed time, and DFSORT messages before and after the change.
• Keep the compile option visible in the build procedure or compiler listing.

Performance expectation

IBM performance guidance recommends FASTSRT for eligible sorts when COBOL file error handling is not needed. IBM also gives an example where one program processing 100,000 records was faster and used fewer EXCPs with FASTSRT. Treat that as an example, not a fixed promise. Your result depends on record size, sort keys, I/O path, work files, and how much logic remains in COBOL.

Common mistakes

Turning on FASTSRT without checking file status usage

If the program depends on file status during sort I/O, FASTSRT can change the behavior that support teams expect. Review the FD and error handling before changing the compiler option.

Expecting FASTSRT to speed up business logic

FASTSRT targets sort file I/O. It does not make an expensive input procedure cheap if that procedure runs many calls, table scans, or database reads.

Leaving the change undocumented

Record the compiler option change in the build procedure or change record. A future compiler migration is easier when the reason for FASTSRT is visible.

Related Mainframe Forum guides

For related topics, read COBOL SORT procedure, JCL SORT examples, SORT INREC and OUTREC examples, COBOL OPTIMIZE compiler option, and COBOL performance tuning.

External references

IBM documents the Enterprise COBOL FASTSRT compiler option, improving sort performance with FASTSRT, and COBOL 6 performance guidance for FASTSRT.

FAQ

What does FASTSRT do in COBOL?

FASTSRT lets DFSORT or a comparable sort product perform I/O for eligible COBOL sort and merge operations instead of Enterprise COBOL doing that I/O.

What is the default FASTSRT setting?

IBM documents the default as NOFASTSRT, meaning Enterprise COBOL performs the input and output for the sort or merge.

Does FASTSRT work with INPUT PROCEDURE and OUTPUT PROCEDURE?

FASTSRT does not remove the COBOL logic inside input or output procedures. It applies to eligible USING and GIVING file I/O portions.

When should I avoid FASTSRT?

Avoid it when the program needs COBOL file status behavior during sort processing, uses unsupported file types, or cannot meet the FASTSRT requirements.