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

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].