Exercise 3: GOBACK vs. an Accidental STOP RUN Inside BALCHECK — Possible Solution ==================================================================== WHAT GOBACK ACTUALLY DOES INSIDE A REAL SUBPROGRAM This chapter's own real compare-table states this directly: inside a called subprogram like BALCHECK, GOBACK behaves like EXIT PROGRAM - it returns control back to whatever program issued the CALL, resuming execution right after that CALL statement. The calling program's own processing genuinely continues normally from that point onward. WHAT WOULD GENUINELY HAPPEN IF STOP RUN WERE WRITTEN INSTEAD This chapter's own material states that STOP RUN "is never appropriate inside a real subprogram meant to return" because it "would end the entire application rather than hand control back." If BALCHECK's own code accidentally used STOP RUN in place of GOBACK, executing it would genuinely terminate the whole running application at that exact point - not just BALCHECK itself, but the calling program too, along with any further processing either one still had left to do. WHY THIS DIFFERENCE IS GENUINELY SEVERE, NOT COSMETIC With the correct GOBACK, the calling program's own real logic - for instance, going on to check WS-VALID-FLAG and act on the real result - executes exactly as designed. With an accidental STOP RUN inside BALCHECK instead, that calling code is never reached at all. The program doesn't produce a wrong answer that could be caught by checking output; it simply stops running altogether, mid-task, with no further real processing happening after BALCHECK's own single validation. WHY THIS CONNECTS BACK TO GOBACK'S OWN REAL DUAL BEHAVIOR This chapter's own material explains that GOBACK behaves differently depending on context - like EXIT PROGRAM in a subprogram, like STOP RUN in a main program. That dual behavior is precisely why writing STOP RUN literally, rather than trusting GOBACK to do the context- appropriate thing automatically, is a genuine risk: it forces the "end everything" behavior onto a subprogram that was actually meant to return control, rather than letting GOBACK adapt correctly to where it's actually used. ANSWER: GOBACK inside BALCHECK genuinely returns control to whichever program called it, letting that caller's own processing continue right after the CALL statement - exactly as intended for a subprogram meant to hand a result back. An accidental STOP RUN in the same spot would instead terminate the entire running application immediately, meaning the calling program's own further processing - such as checking the real result in WS-VALID-FLAG - would never execute at all. This is a genuinely severe difference, not a stylistic one: it's the difference between a subprogram correctly finishing its one job and handing back control, versus the whole application halting mid-task with real work left undone. WHY THIS WORKS AS AN ANSWER ------------------------------ This correctly contrasts GOBACK's real return-to-caller behavior against STOP RUN's genuine whole-application termination, grounding both in this chapter's own explicit statements, and explains the concrete practical consequence rather than treating the two as merely different keywords with similar effect.