COBOL SEARCH ALL key ordering precondition without compiler validation

Question

The SEARCH ALL statement in COBOL performs a binary search on an OCCURS table that includes a KEY phrase. The ISO standard requires the table to be in ascending or descending key sequence before the search executes, yet it imposes no obligation on the compiler to verify that precondition at compile time or run time. Unlike arithmetic statements, SEARCH ALL has no SIZE ERROR or declarative exception phrase to signal a violated assumption.

When a table has been updated in place after its last sort, the binary search may return an incorrect index or take the AT END path with no diagnostic. Because the standard defines the result as undefined rather than erroneous, identical source can behave differently across IBM Enterprise COBOL, GnuCOBOL, and Micro Focus compilers. Vendor-specific runtime checks may cover subscript bounds but do not standardize sort-order validation.

This creates an unresolved boundary between application responsibility and compiler enforcement: the standard places the ordering precondition on the programmer but offers no standard mechanism to assert it, leaving teams to decide how to manage table maintenance without portable diagnostic feedback.

Which documented compiler options, if any, provide runtime detection of unsorted keys for SEARCH ALL across major COBOL implementations? What is the standard-conforming behavior when SEARCH ALL encounters a table whose KEY order has been broken by in-place updates? Do any ISO COBOL mechanisms exist to assert table key sequence before a binary search, or must the precondition be managed entirely outside the language?

Tasadduq Burney · Answer

Direct answer
No documented compiler option in IBM Enterprise COBOL, GnuCOBOL, or Micro Focus provides runtime detection of unsorted KEY values for SEARCH ALL. Range-checking options such as SSRANGE validate subscript bounds only; they do not scan the table for ascending or descending key sequence. The standard places the ordering precondition on the programmer and does not require the compiler to diagnose a violation.
Standard-conforming behavior
ISO COBOL defines SEARCH ALL results as undefined when the table is not in the required ascending or descending KEY sequence. There is no SIZE ERROR, ON OVERFLOW, or declarative phrase for SEARCH ALL. After in-place updates break key order, the statement may return an incorrect index, take AT END incorrectly, or produce different results across compiler vendors and releases.
ISO mechanisms for asserting key sequence
No ISO COBOL language mechanism exists to assert table key sequence before a binary search. The precondition must be managed outside SEARCH ALL: re-sort after in-place updates, preserve order during updates, or use SEARCH for unordered tables.
Verification steps

Identify the target COBOL compiler and release; option names and support change between versions.
Compile with default settings and with any available range-checking option.
Run against a deliberately unsorted KEY table and observe whether a diagnostic is emitted or the index/AT END result changes.
Record behavior for the target release before assuming portability to another compiler.

Missing diagnostic detail: which COBOL compiler and release are you targeting? This changes the recommendation only if a newer release added a non-standard order-validation option; current documentation does not document one.
Assumptions and uncertainty: this answer synthesizes documented compiler behavior from the supplied brief, not live verification. Vendor documentation can change, and the brief flags current verification as required. Treat all compiler-option claims as pending confirmation against the target release's manual.

COBOL SEARCH ALL key ordering precondition without compiler validation

1 answer

Direct answer

Standard-conforming behavior

ISO mechanisms for asserting key sequence

Verification steps

Your perspective belongs here.

0 question comments