Exercise 3: What Happens Automatically When WS-BRANCH-CODE Changes — Possible Solution
====================================================================

WHAT CONTROL IS WS-BRANCH-CODE ACTUALLY DECLARES
This chapter's own real CUSTOMER-REPORT example names WS-BRANCH-CODE
in the RD entry's own CONTROL IS clause. This tells the Report Writer
facility, at a declarative level, that WS-BRANCH-CODE is the real
field to watch for changes as records are processed - it's a stated
fact about the report's own structure, not a manually-triggered check
the program has to perform itself.

WHAT GENERATE ACTUALLY DOES ON EACH CALL
This chapter's own material explains that GENERATE produces one real
detail line each time it's called, and automatically fires a real
control break whenever the field named in CONTROL genuinely changes
value between one processed record and the next. This checking
happens as a built-in real part of what GENERATE does - the program
never has to compare the current and previous WS-BRANCH-CODE values
itself.

WHAT GENUINELY HAPPENS THE MOMENT WS-BRANCH-CODE CHANGES
Per this chapter's own real material, the instant GENERATE detects
that WS-BRANCH-CODE holds a genuinely different value than it did for
the previous processed record, Report Writer automatically triggers a
real control break - the kind of event that would normally, in
hand-written reporting code, require explicitly printing a subtotal
line, resetting an accumulator, or starting a new page. Report
Writer's own real declarative design means this entire sequence is
handled internally once the control field is declared, without the
program's own code ever spelling out "if the branch code changed, do
X."

WHY THE PROGRAMMER NEVER HAD TO WRITE THIS LOGIC BY HAND
This chapter's own material states directly that Report Writer's whole
real purpose is letting the programmer specify only the report's
layout and the data it needs, rather than writing the actual
procedural logic for control breaks, page breaks, and formatting.
Declaring CONTROL IS WS-BRANCH-CODE once, in the RD entry, is genuinely
sufficient - GENERATE's own built-in behavior handles detecting and
acting on every future change to that field for the rest of the
report's run.

ANSWER: The moment WS-BRANCH-CODE genuinely changes value between one
processed record and the next, GENERATE automatically detects that
change and fires a real control break - exactly the kind of event that
would normally need hand-written comparison logic in a manually coded
report. The programmer never had to write that logic directly because
Report Writer is a genuinely declarative facility: declaring CONTROL IS
WS-BRANCH-CODE once in the RD entry is enough to make GENERATE watch
for changes to that field automatically on every subsequent call,
handling the control-break detection and response internally rather
than requiring the program's own procedural code to check for it.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly explains the real mechanism (CONTROL IS declaring what
to watch, GENERATE automatically detecting and reacting to changes)
rather than treating the control break as unexplained magic, and ties
the explanation directly to Report Writer's own stated declarative
purpose.