Exercise 1: Why SEARCH ALL Is Correct Here, and the Real Risk If the Table Is Ever Unsorted — Possible Solution ==================================================================== WHY SEARCH ALL IS THE GENUINELY RIGHT CHOICE FOR THIS TABLE Chapter 6's own real material distinguishes SEARCH (a sequential scan) from SEARCH ALL (a real binary search) - and states that SEARCH ALL's own real speed advantage comes specifically from jumping to the midpoint of the remaining range each time, rather than checking every element one by one. WS-CUSTOMER-TABLE, as declared in this chapter's own TXNBATCH program, is a real 100-entry table - genuinely large enough that a plain sequential SEARCH would, in the worst case, have to check all 100 entries to find or rule out a single customer, while SEARCH ALL narrows the same search down in only a handful of real comparisons. A nightly batch job processing many transactions against a table this size benefits directly from that real difference, multiplied across every single transaction record read. WHAT MAKES SEARCH ALL VALID HERE, PER THE TABLE'S OWN DECLARATION This chapter's own WS-CUSTOMER-TABLE is declared with ASCENDING KEY IS WS-CUST-ID directly in its OCCURS clause - exactly the real declaration Chapter 6 states SEARCH ALL requires before it can be used at all. Without that real key declaration, SEARCH ALL wouldn't even be a valid choice; only a plain SEARCH would be usable against an undeclared table. THE REAL, SILENT RISK IF THE TABLE WERE LOADED OUT OF ORDER Chapter 6's own warn-box states this risk directly: declaring ASCENDING KEY IS WS-CUST-ID is a genuine promise made to the compiler about how the real data will be arranged - it does not sort the data itself. If WS-CUSTOMER-TABLE were ever loaded from a customer master file whose records weren't genuinely in ascending WS-CUST-ID order, nothing in this chapter's own TXNBATCH program - or in SEARCH ALL itself - would detect that mismatch. SEARCH ALL would still run its real binary-search algorithm exactly as if the data were correctly sorted, since it has no verification step of its own. WHAT THAT WOULD MEAN FOR REAL TRANSACTION PROCESSING Applying Chapter 6's own warning directly to this program: a real customer who genuinely exists in the unsorted table could come back through the AT END path as "UNKNOWN CUSTOMER," causing their legitimate transaction to be silently skipped and reported as unrecognized, with no error raised anywhere to reveal the real cause was an unsorted table rather than a genuinely missing customer. ANSWER: SEARCH ALL is genuinely correct here because WS-CUSTOMER-TABLE holds up to 100 entries and is declared with ASCENDING KEY IS WS-CUST-ID, meeting Chapter 6's own real requirement for binary search - letting each customer lookup complete in far fewer comparisons than a plain sequential SEARCH would need, a real advantage that compounds across every transaction the batch processes. The real risk, exactly as Chapter 6's own warn-box describes, is that declaring ASCENDING KEY only promises the compiler the data will be sorted - it doesn't sort it. If the customer master were ever loaded out of order, SEARCH ALL would still run its real binary-search algorithm on the assumption the data is sorted, and a genuinely present customer's real transaction could be wrongly reported as "UNKNOWN CUSTOMER" and silently skipped, with no error raised anywhere. WHY THIS WORKS AS AN ANSWER ------------------------------ This correctly ties SEARCH ALL's real advantage to the table's actual size and declared key, and applies Chapter 6's own specific silent- failure warning directly to this program's own real consequence (a legitimate customer's transaction wrongly rejected as unknown) rather than restating the warning in the abstract.