Exercise 2: Why an INDEXED BY Index Is Faster, and Why SEARCH Requires One — Possible Solution
====================================================================

WHAT AN ORDINARY SUBSCRIPT LIKE WS-I ACTUALLY IS
This chapter's own finding-box explains that a plain numeric field
used as a subscript, like WS-I, holds a real occurrence number - 1,
2, 3, and so on. That number by itself doesn't directly correspond to
a real storage address. Every time WS-I is used to reference an
element, the runtime has to take that occurrence number and multiply
it by the element's own size to work out where in memory the real
element actually sits.

WHAT AN INDEXED BY INDEX GENUINELY IS INSTEAD
This chapter's own material describes an INDEXED BY index as
something structurally different - it's stored directly as a
displacement, already scaled to the element's own size, rather than a
plain count. Advancing it with SET ... UP BY 1 doesn't add "1" the
way an ordinary occurrence number would - it adds one element's worth
of real storage distance, since that's already how the index's own
value is represented.

WHY THIS MAKES A REAL, MEASURABLE PERFORMANCE DIFFERENCE
Because the index already holds a real, ready-to-use storage
displacement, the runtime can go straight to the correct element with
no multiplication step needed - unlike a plain subscript, which has to
be multiplied by the element's own size every single time it's used.
This chapter's own material specifically calls out that on a table
accessed millions of times in a real batch job, that difference is
genuine and measurable, not a cosmetic or purely stylistic one.

WHY SEARCH SPECIFICALLY REQUIRES INDEXED BY
This chapter's own SEARCH example explains that SEARCH walks a table
starting from wherever the index currently points, and automatically
advances that same index itself on every failed comparison as it
moves through the table. That automatic advancing is only possible
because the table was declared with a real INDEXED BY index in the
first place - SEARCH has no equivalent mechanism for automatically
stepping a plain ordinary subscript like WS-I on its own, since a
plain subscript is just an ordinary numeric field with no special
built-in connection to the table at all.

ANSWER: An INDEXED BY index is genuinely faster than an ordinary
subscript like WS-I because it's stored directly as a real
displacement already scaled to the element's own size, letting the
runtime go straight to the correct element with no multiplication
needed - while a plain subscript is just a numeric occurrence count
that must be multiplied by the element size on every single reference.
SEARCH specifically requires INDEXED BY because SEARCH's own real
mechanism is to automatically advance the index itself as it walks the
table on each failed comparison, and that automatic advancing depends
on the table having a real index already declared - there's no
equivalent way for SEARCH to automatically step an ordinary subscript
field on its own.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies the specific real mechanism behind the index's speed
advantage (a pre-scaled displacement vs. a value needing multiplication
on every reference) rather than just asserting indexes are "faster,"
and explains SEARCH's own INDEXED BY requirement through the concrete,
chapter-stated fact that SEARCH automatically advances the index
itself.