Thanks Scott. I appreciate the feedback. I wasn't aware of %PARMS() &
OPTION(*NOPASS) until you and Michael informed me.

I won't be using a local data area now. They can be a bigger pain than what
I had previously thought.

Thanks again,


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Scott Klement
Sent: Tuesday, August 26, 2008 5:03 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Stuck on accessing the LDA -- manuals no help so far


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
& 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-2019 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].