RE: Programmatically determine number of parms inprocedureprototype?

'NEVER' might be better said as 'Typically.'

Maybe assumptions are being made, but I interpreted the person's post as
such:
D TestProc        PR                                      
D  Parm1                         1A                       
D  Parm2                         1A    Options( *NoPass ) 

Some modules call this procedure as "TestProc( fld1 : fld2 )"
Others may call it as "TestProc( fld1 )"

Now there is a change in the requirements for the program, and a new
parameter (parm3) is needed by the procedure. (which seems to be the
case in the original post)

Parm3 can't just go at the end, unless it meets the criteria of only
ever being needed if and only if parm2 is received.

If Parm3 does go at the end, and doesn't meet the criteria above, then
Parm2 must have Options( *NoPass ) removed (and more than likely replace
it with Options( *Omit )), and in doing so, all modules that call this
procedure that don't pass the 2nd parameter must now pass the parameter
or pass *Omit.  And you now have to code this program to check for a
null address.

I suppose if you strongly believe in using *Omit over *NoPass, then
yeah, you wouldn't want to change the order.  I enjoy the versatility of
*NoPass however.

Though I'm willing to learn.  Is there a reason (other than
circumstantial) for me to be using *Omit instead of *NoPass?

- Kurt

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Barbara Morris
Sent: Thursday, November 18, 2004 10:53 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Programmatically determine number of parms
inprocedureprototype?

Bob Cozzi wrote:
> 
> NEVER ADD PARMS BEFORE EXISTING PARMS in a procedure. All your 
> existing code would then need to be recompiled. Of course if it is a 
> local proc used only by one program, then that's a different story. 
> But still... that's a very bad "standard".

"NEVER ADD PARMS BEFORE EXISTING PARMS" is a great rule.  But even for a
local procedure, inserting parms can lead to trouble if the data types
of the parameters are such that an unmodified or incorrectly modified
call would pass the compile.  For instance, say the procedure previously
had two numeric parameters and you insert a new second numeric
parameter; if you incorrectly add the new parameter at the end for one
of the existing calls, you now have a bug.  If the parameters have
similar ranges of reasonable values, you may have a bug that you will
never detect.  (It's always possible to have this type of bug even when
you aren't changing the number of parameters, but inserting parameters
dramatically increases the potential.)

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.