#1291 SORT/MERGE without a COLLATING SEQUENCE phrase reuse the alphabet of an earlier phrase or clause

[Brent Rector]

A SORT or MERGE without a COLLATING SEQUENCE phrase, or with one for national keys only, can use an alphabet left over from earlier in the same program: the phrase of an earlier SORT or MERGE, or the COLLATING SEQUENCE clause of a SELECT.

To reproduce

tabcol.cob (attached) sorts the same table three times: with no phrase, with COLLATING SEQUENCE IS CI (an alphabet in which "a" sorts with "A" and "b" with "B"), then with no phrase again:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. TABCOL.
       ENVIRONMENT DIVISION.
       CONFIGURATION SECTION.
       SPECIAL-NAMES.
           ALPHABET CI IS "A" ALSO "a" "B" ALSO "b".
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 T VALUE "bAaB".
          05 E PIC X OCCURS 4 TIMES.
       PROCEDURE DIVISION.
           SORT E ON ASCENDING KEY E
           DISPLAY "NATIVE 1 " T
           SORT E ON ASCENDING KEY E COLLATING SEQUENCE IS CI
           DISPLAY "CI       " T
           SORT E ON ASCENDING KEY E
           DISPLAY "NATIVE 2 " T
           STOP RUN.

cobc -std=cobol2014 -x tabcol.cob && ./tabcol

What happens

3.2.0 and 3.3-dev r5751 both print

NATIVE 1 ABab
CI       AaBb
NATIVE 2 AaBb

and on r5751 cobc -C passes s_CI to the third cob_table_sort_init. The other attachments show the same: pcol.cob, where an earlier SORT's phrase beats PROGRAM COLLATING SEQUENCE IS AL-REV (PROG ABC); dcol.cob, the same with -fdefault-colseq; mrgcol.cob and srtcol.cob, a file MERGE and a file SORT; selcol.cob, a table SORT after an indexed SELECT with the clause; and natcol.cob, a SORT whose phrase names only FOR NATIONAL, so its alphanumeric key keeps the earlier AL-REV. On r5751 each SELECT first stores the default file collating sequence, so only the last SELECT's clause leaks (selcol2.cob), and -fdefault-file-colseq=EBCDIC reaches a table SORT (fdefcol.cob).

What should happen

Each SORT and MERGE uses its own phrase if it has one, otherwise the program collating sequence, so tabcol should print NATIVE 2 ABab and pcol PROG CBA. The rule is ISO/IEC 1989:2023 14.9.40.4 SORT general rule 5 b), for all formats, and the same MERGE rule in 14.9.24.4: "Second, the collating sequences established as the program collating sequences." A PROGRAM COLLATING SEQUENCE clause sets the alphanumeric one (12.3.6.4 rule 9). The same in 2002 and in the 2014 FCD.

Why it happens

In cobc/parser.y, coll_sequence_values stores the alphabet in the file-static alphanumeric_collation. A statement without a phrase, or with a FOR NATIONAL phrase only, does not reset it, and sort_merge_body passes it to cb_emit_sort_init for every SORT and MERGE.

Proposed fix

The attached n10-sort-merge-collating.patch (against 3.3-dev r5751; its parser.y part also applies to 3.2 with offsets) sets alphanumeric_collation and national_collation to NULL in sort_statement and merge_statement, before the phrase is parsed, so libcob uses the program collating sequence for anything a phrase does not name. A SELECT's clause still applies to its own file's keys. It also changes one other behavior: -fdefault-file-colseq no longer reaches a SORT or MERGE (fdefcol prints NATIVE 1Aa). With the patch every program gives the expected result. It adds testsuite case 794, "SORT / MERGE: COLLATING SEQUENCE applies per statement", to tests/testsuite.src/run_misc.at, with ChangeLog entries. make check: 1373 expected, 9 skipped, 0 failed (1372 unpatched); the new test fails without the patch.

Related

• feature-requests #459: COLLATING SEQUENCE on SELECT for indexed files, the clause that leaks here.
• feature-requests #426: the options -fdefault-colseq and -fdefault-file-colseq.

Details

GnuCOBOL 3.2.0 (Ubuntu gnucobol3 3.2-4build1) and 3.3-dev r5751 (CI snapshot 3.3-dev.138 of 2026-10-29), x86_64 Linux, both run 2026-11-04.