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.