All topics
10 / 60
COBOLadvanced

Sorting Internal Tables

Know the techniques for sorting COBOL tables in memory when data must be ordered before further processing.

Sorting a whole dataset is DFSORT's job, in the JCL, before COBOL sees it. This is about sorting data already loaded into a table in memory.

Sorting an in-memory COBOL table by hand is like re-alphabetizing a small stack of index cards on your desk yourself, versus sending a whole filing cabinet's worth of paperwork to an outside sorting service — fine for a dozen cards, a bad idea for ten thousand.

Key Concepts

1
The first question is whether you should be doing it at all.
    sort the dataset in JCL     DFSORT, before the program runs.
                                Optimised, no program memory used,
                                handles any volume.
    sort a table in the program a few dozen to a few hundred entries
                                already in working storage.
2
If the data is coming from a file and you want it ordered, sort it with DFSORT in a prior step or in the same step's SORT card. Reading ten million records into a table to sort them in COBOL is the wrong shape, and it is what the question is checking.
SORT
3
When an in-memory sort is right. The table was not read from a file in sorted order — accumulated totals per region, say, built during processing and now needing to be ranked for a report.
4
There is no file to sort. The data exists only in working storage.
5
COBOL's SORT verb with procedures handles this on modern compilers:
SORT
6
    SORT SORT-FILE ON ASCENDING KEY SD-AMOUNT
        INPUT PROCEDURE  IS LOAD-FROM-TABLE
        OUTPUT PROCEDURE IS WRITE-REPORT
7
INPUT PROCEDURE releases records from your table into the sort; OUTPUT PROCEDURE returns them in order. The sort itself is handled by the runtime.
INPUT PROCEDUREOUTPUT PROCEDURE
8
And the hand-written version, which you will meet in older code. Before that was standard, shops wrote a bubble sort against the table:
9
    PERFORM VARYING WS-I FROM 1 BY 1 UNTIL WS-I > WS-COUNT
      PERFORM VARYING WS-J FROM 1 BY 1 UNTIL WS-J > WS-COUNT - WS-I
        IF ENTRY(WS-J) > ENTRY(WS-J + 1)
            MOVE ENTRY(WS-J)     TO WS-TEMP
            MOVE ENTRY(WS-J + 1) TO ENTRY(WS-J)
            MOVE WS-TEMP         TO ENTRY(WS-J + 1)
        END-IF
      END-PERFORM
    END-PERFORM
10
That is O(n²). At 100 entries it is 5,000 comparisons and finishes instantly. At 10,000 it is 50 million, and the program appears to hang.
11
Which is the whole point to make. The algorithm is adequate for the table sizes COBOL programs normally hold, and catastrophic past them — and a table that large should not have been built in the first place.
12
The answer that lands. Not a sorting algorithm. It is knowing that dataset sorting and table sorting are different problems: DFSORT for anything from a file, an in-program sort only for a small working set that exists nowhere else.
13
What the interviewer is probing.1. "When would you sort in the program rather than with DFSORT?" Probing: the judgement. Stalls: "Always in the program." Moves up: only for small in-memory tables; a sort utility is dramatically faster and cheaper for file-sized data.
14
2. "What is the usual internal sort approach?" Probing: the practical answer. Stalls: "Bubble sort." Moves up: keep the table ordered as you build it by inserting in position, which avoids sorting at all for modest volumes.
15
3. "What is the cost consideration here?" Probing: the mainframe reality. Stalls: "None." Moves up: CPU is metered and billed, so an inefficient in-program sort over a large table shows up directly on the monthly charge.
16
4. "How does SORT with INPUT and OUTPUT PROCEDURE work?" Probing: the breadth. Stalls: "It sorts." Moves up: the program feeds records with RELEASE and consumes them with RETURN, so you can filter or transform on both sides of the sort.
Use cases:sortinginternal-tablesalgorithmsperformance