The SORT Verb and Sort-Work Files
COBOL provides a native SORT verb that reorders records without the programmer writing a sort algorithm by hand, delegating the actual work to the underlying system sort utility (DFSORT on IBM mainframes). A sort-work file is declared with SD (Sort Description) instead of FD in the DATA DIVISION, and the SORT statement itself names that file, the ON ASCENDING/DESCENDING KEY fields, and either USING/GIVING for whole-file sorts or INPUT PROCEDURE/OUTPUT PROCEDURE when records need to be filtered or transformed before or after sorting. The simplest form, SORT SORTFILE ON ASCENDING KEY CUST-ID USING INPUT-FILE GIVING OUTPUT-FILE, reads every INPUT-FILE record, sorts it by CUST-ID, and writes the result directly to OUTPUT-FILE with no procedural code required.
Cricket analogy: SORT is like handing a stack of scorecards to a statistician to arrange by run-rate rather than doing it by hand — you specify the key (run-rate) and get back an ordered result without writing the sorting logic yourself.
INPUT PROCEDURE and OUTPUT PROCEDURE
When records must be filtered, edited, or summarized before sorting, INPUT PROCEDURE names a section that reads the original file and uses RELEASE (instead of WRITE) to hand qualifying records to the sort's work file; symmetrically, OUTPUT PROCEDURE names a section that uses RETURN (instead of READ) to pull sorted records back out one at a time for further processing, such as generating control-break totals, before writing the final report. This combination — INPUT PROCEDURE to pre-filter and OUTPUT PROCEDURE to post-process — is extremely common in production COBOL where a plain USING/GIVING sort is too simplistic, for example excluding closed accounts before the sort and inserting subtotal lines after it.
Cricket analogy: INPUT PROCEDURE is like a selector filtering out players who didn't meet the fitness test before submitting the squad list for ranking, and OUTPUT PROCEDURE is like adding category labels (batsmen, bowlers) to the sorted list afterward.
The MERGE Verb
MERGE differs from SORT in that its input files must already be individually sorted on the same key; MERGE simply interleaves them into a single ordered output without re-sorting each one from scratch, which is far more efficient than concatenating unsorted files and running a full SORT. Syntax closely parallels SORT — MERGE SORTFILE ON ASCENDING KEY CUST-ID USING FILE-A FILE-B GIVING OUTPUT-FILE — but MERGE only supports an OUTPUT PROCEDURE (no INPUT PROCEDURE), since there is nothing to pre-filter before the merge; each input file is simply required to already be sorted.
Cricket analogy: MERGE is like combining two already-sorted batting averages tables from two different tournaments into one ranked list, faster than re-sorting every player from a jumbled combined list.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT SORT-WORK ASSIGN TO 'SORTWK1'.
SELECT INPUT-FILE ASSIGN TO 'RAWDATA'.
SELECT OUTPUT-FILE ASSIGN TO 'SORTED'.
DATA DIVISION.
FILE SECTION.
SD SORT-WORK.
01 SORT-REC.
05 SORT-CUST-ID PIC 9(6).
05 SORT-NAME PIC X(30).
FD INPUT-FILE.
01 IN-REC PIC X(80).
FD OUTPUT-FILE.
01 OUT-REC PIC X(80).
PROCEDURE DIVISION.
MAIN-LOGIC.
SORT SORT-WORK
ON ASCENDING KEY SORT-CUST-ID
INPUT PROCEDURE IS FILTER-ACTIVE
GIVING OUTPUT-FILE
STOP RUN.
FILTER-ACTIVE SECTION.
OPEN INPUT INPUT-FILE
PERFORM UNTIL WS-EOF-FLAG = 'Y'
READ INPUT-FILE
AT END MOVE 'Y' TO WS-EOF-FLAG
NOT AT END
IF IN-REC(35:1) = 'A'
RELEASE SORT-REC FROM IN-REC
END-IF
END-READ
END-PERFORM
CLOSE INPUT-FILE.The sort-work file's SD record layout does not need to match the FD layouts of the input or output files exactly, but the key fields used in ON ASCENDING/DESCENDING KEY must be present and correctly positioned in the SD record.
MERGE requires every input file to already be sorted on the merge key. Feeding it unsorted or differently-sorted files does not produce an error but silently yields incorrect, out-of-order output.
- SORT is declared with SD (not FD) and delegates ordering to the system sort utility (e.g., DFSORT).
- USING/GIVING performs a simple whole-file sort with no procedural code.
- INPUT PROCEDURE with RELEASE lets a program filter/transform records before sorting.
- OUTPUT PROCEDURE with RETURN lets a program post-process sorted records, e.g., for control breaks.
- MERGE combines already-sorted files by interleaving, avoiding a full re-sort.
- MERGE supports only OUTPUT PROCEDURE, not INPUT PROCEDURE.
- Feeding MERGE unsorted input produces silently incorrect output rather than an error.
Practice what you learned
1. What DATA DIVISION entry describes a sort-work file, as opposed to a regular file?
2. Which verb is used inside an INPUT PROCEDURE to hand a record to the sort?
3. What must be true of files used as input to a MERGE statement?
4. Which procedure type does MERGE support that allows post-processing of the merged output?
5. In SORT ... USING file-a GIVING file-b, what happens if no INPUT or OUTPUT PROCEDURE is coded?
Was this page helpful?
You May Also Like
Sequential File Processing
Learn how COBOL reads, writes, and updates records in a sequential file, the oldest and most common file organization in mainframe batch systems.
File Status Codes
Learn how COBOL's two-character FILE STATUS codes let a program detect and react precisely to the outcome of every file I/O operation.
Report Writer Basics
Explore COBOL's Report Writer feature, a declarative way to generate formatted, control-broken reports without manually coding line spacing and totals.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics