Exercise 3: Loading an Unsorted File into a Table Declared ASCENDING KEY — Possible Solution ==================================================================== WHAT ASCENDING KEY IS WS-CUST-ID ACTUALLY DOES This chapter's own warn-box makes the key point directly: declaring ASCENDING KEY IS WS-CUST-ID is a real promise made to the compiler about how the table's data will genuinely be arranged - it is not an instruction that sorts anything itself. The clause tells SEARCH ALL "trust that this table is already in ascending order by WS-CUST-ID," but it does nothing at all to actually put the data into that order. WHAT HAPPENS WHEN THE COLLEAGUE LOADS UNSORTED DATA ANYWAY If real customer records are loaded into WS-CUSTOMER-ENTRY in whatever order they happen to arrive from an unsorted file, the table's actual contents will not genuinely be in ascending WS-CUST-ID order, even though the table's own declaration claims they are. Nothing in COBOL checks this at load time - the mismatch between what the declaration promises and what the data actually contains passes completely unnoticed when the records are read in. WHY SEARCH ALL DOESN'T CATCH THE MISMATCH This chapter's own material explains that SEARCH ALL performs a real binary search - it jumps to the midpoint of the remaining range and narrows from there, exactly the same way it would on a genuinely sorted table, with no verification step of its own. It has no way to tell, and makes no attempt to check, whether the real data it's searching actually matches the ascending order its own declaration claims. THE REAL, CONCRETE CONSEQUENCE Because binary search's whole algorithm depends on the data genuinely being sorted, running it against data that isn't produces wrong results with no error raised anywhere. A real customer record that is genuinely present in the table can come back reported as "not found" via the AT END path, simply because the binary search jumped past its actual position based on false assumptions about the surrounding data's order. Equally, the wrong entry could be returned as if it were a real match. Either way, the program has no way of knowing anything went wrong - it behaves as if the search completed correctly. ANSWER: Declaring ASCENDING KEY IS WS-CUST-ID only tells the compiler that the table's data will be in ascending order by WS-CUST-ID - it does not sort the data itself. If the colleague loads real records straight from an unsorted file, the table's actual contents won't genuinely match that declared order, and nothing checks for this mismatch at load time. Because SEARCH ALL performs a real binary search that assumes the data is genuinely sorted, with no verification step of its own, running it against this unsorted table can produce silently wrong results - a real, present customer record reported as "not found," or the wrong record returned as if it matched - with no error raised anywhere to reveal that anything went wrong. WHY THIS WORKS AS AN ANSWER ------------------------------ This correctly distinguishes between declaring a sort order and actually enforcing one, identifies the specific real failure mode (silently wrong binary-search results with no error) rather than a vague "it won't work," and grounds the explanation directly in this chapter's own warn-box material.