With that approach, you have to do analysis on hundreds of programs to
be sure that they don't read from or overwrite that portion of the LDA.
And, since the LDA is only 2000 bytes long, if you use it for
everything, there's a good chance that there will be a conflict.
So you have to know exactly where the program is called from every time
it's called, and you have know every other program that can be called in
the job stream of every place it's called, and exactly when each of
these other programs is called, and exactly how they use the LDA.
Contrast this with a parameter. A parameter is ALWAYS only for one call
from one program to another. You don't ever have to worry about
conflicts, except between direct callers of your immediate program.
And assuming that you're changing an existing program that already
receives parameters, you can add the new parms to the end of the list,
and make them "optional" parameters. Use %PARMS to verify that the
parameter is only used if it's passed. When that's an option, then no
analysis or changes to callers is needed at all. Saving you a TON of
time and effort.
Frank Kany wrote:
I might be lazy, but I'd rather use a simple LDA to pass a parm than modify
& test hundreds of programs just because I want to add another parm to 1