COBOL SEARCH ALL key ordering precondition without compiler validation
0 reputation · 19 Dec 2023, 08:38 UTC
0 reputation · 19 Dec 2023, 08:38 UTC
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?
A thoughtful contribution can make all the difference. Be the first to share one.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.