#1298 A detail or sum counter qualified by its report-name is "not defined": GENERATE DET OF R1, TOT OF R1

[Brent Rector]

cobc does not accept a report-name as the qualifier of a detail report group or a sum counter. GENERATE DET OF R1 gets "'DET IN R1' is not defined", so when two reports each have a detail named DET, neither can be generated.

To reproduce

gq2.cob (attached, free format):

IDENTIFICATION DIVISION.
PROGRAM-ID. GQ2.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
    SELECT RPT-FILE ASSIGN TO "gq2.out".
DATA DIVISION.
FILE SECTION.
FD RPT-FILE REPORT IS R1 R2.
REPORT SECTION.
RD R1.
01 DET TYPE DETAIL LINE PLUS 1.
   05 COLUMN 1 PIC X(2) VALUE "R1".
RD R2.
01 DET TYPE DETAIL LINE PLUS 1.
   05 COLUMN 1 PIC X(2) VALUE "R2".
PROCEDURE DIVISION.
    OPEN OUTPUT RPT-FILE
    INITIATE R1 R2
    GENERATE DET OF R1
    GENERATE DET IN R2
    GENERATE DET IN R2
    TERMINATE R1 R2
    CLOSE RPT-FILE
    DISPLAY "DONE"
    STOP RUN.

cobc -x -free -std=cobol2014 -fno-diagnostics-show-caret -o gq2 gq2.cob

What happens

3.2.0 and 3.3-dev r5751 both stop with

gq2.cob:20: error: 'DET IN R1' is not defined

With GENERATE DET on line 20 the error is "'DET' is ambiguous; needs qualification". The attached gq1.cob (one report, GENERATE DET OF RPT), gq3.cob (a sum counter, ADD TOT OF R1 TO W) and gq6.cob (SOURCE TOT OF R1 inside RD R1) get the same "not defined" error.

What should happen

The program should display DONE and write R1, R2, R2 to gq2.out. ISO/IEC 1989:2023 14.9.16.3 syntax rule 1: "Data-name-1 shall name a detail report group. It may be qualified by a report-name." The general format of a qualified data-name in 8.4.2.2.2 ends with an optional IN/OF file-name or report-name, so a sum counter can be qualified the same way wherever it can be referenced, for example in the procedure division (13.8.6.2.3) and in a SOURCE clause of its own report (13.18.53.3 syntax rule 4). The rules are the same in 2002 and in the 2014 FCD.

Why it happens

In cobc/tree.c, cb_ref_internal matches a qualifier against the item's parents and then against a file or CD (field_is_in_file_record, field_is_in_cd_record). There is no check for a report, so a report-name is never consumed as a qualifier. And cb_field.report is set only by finalize_report at the end of the RD, so items of the RD being parsed have no report yet.

Proposed fix

The attached n10-generate-detail-of-report.patch (against 3.3-dev r5751) adds field_is_in_report beside the file and CD checks in cb_ref_internal. For the RD being parsed, it looks for the item's record on the report's records chain, which report_group_description_entry in parser.y now sets at the RD's first entry, not at its end. A qualified name thus resolves to the item its unqualified name would, so nothing else changes. cobc does not check 13.18.53.3 rule 4, so SOURCE TOT OF R1 in RD R2 now compiles, as SOURCE TOT already does when the name is unique. USE BEFORE REPORTING DET OF R2 now compiles too.

With the patch, gq1 writes 007, gq3 displays W = 0021 (7 + 14) and gq6 prints its footing as 7 7.

It adds the testsuite case "Report items qualified by report-name" to run_reportwriter.at, with ChangeLog entries. make check: 1373 expected, 9 skipped, 0 failed (1372 unpatched); the new test fails without the patch. The NIST suite gives the same results with and without it.

Related

We found no ticket on this.

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. The same error with -std=default, cobol2002, cobol85, ibm and mf.