Re: Stuck on accessing the LDA -- manuals no help so far

Frank,

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
program.