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

[Frank Kany <FrankKany@xxxxxxxxxx>]

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,

Frank

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

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.