Exercise 1: Why the Same Compiled Program Processes Different Data Each Run — Possible Solution
====================================================================

WHAT ASSIGN TO TXNFILE GENUINELY NAMES, PER THIS CHAPTER
This chapter's own finding-box explains that SELECT TRANSACTION-FILE
ASSIGN TO TXNFILE doesn't name a literal, fixed file path baked into
the program at all - it names a real ddname, a symbolic reference the
compiled program's own runtime looks for at execution time. The
compiled program itself never contains a real, specific dataset
location.

WHAT THE JCL'S DD STATEMENT ACTUALLY SUPPLIES
This chapter's own real JCL example, //TXNFILE DD
DSN=PROD.TXN.DAILY,DISP=SHR, is what genuinely resolves that symbolic
ddname to an actual real dataset for one specific run of the job.
Whoever writes the JCL for a given execution decides, at that moment,
which real dataset TXNFILE actually points to.

WHY CHANGING THE JCL, NOT THE PROGRAM, IS GENUINELY SUFFICIENT
Because the compiled TXNBATCH program only ever refers to the
symbolic name TXNFILE - never to any specific real dataset name
directly - a real, different DD statement supplied by a different
run's own JCL is all that's needed to point the exact same compiled
program at genuinely different data. Nothing inside TXNBATCH's own
compiled form has to change for this to work, since it was never
compiled with a specific real dataset baked into it in the first
place.

WHY THIS GENUINELY MATTERS FOR REAL NIGHTLY BATCH WORK
This chapter's own material frames this directly as "the same compiled
program, genuinely different data every run" - exactly the real
situation a nightly batch job needs. Each night's transaction file has
a genuinely different real name or generation, but the compiled
TXNBATCH program stays completely unchanged; only the real JCL
submitted for that night's run needs to point TXNFILE at that night's
own actual dataset.

ANSWER: SELECT TRANSACTION-FILE ASSIGN TO TXNFILE names a real,
symbolic ddname rather than a specific dataset path, and the actual
real dataset used on any given run is supplied entirely by that run's
own JCL DD statement - //TXNFILE DD DSN=PROD.TXN.DAILY,DISP=SHR in
this chapter's own example. Because the compiled program itself never
contains a specific real dataset name, pointing it at genuinely
different data across two separate nightly runs only requires
supplying different real DD statements in each run's own JCL - the
compiled TXNBATCH program itself never needs to change or be
recompiled at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly explains the real division of responsibility (the
compiled program holds only a symbolic ddname; the JCL supplies the
actual dataset per run) rather than treating the behavior as
unexplained flexibility, and grounds the explanation directly in this
chapter's own stated real example.