Re: Calling similiar (overloaded) procedure that has *nopass *omit in the parameter

My point is that *NOPASS is only a problem because IBM implemented it
that way. :)

I'm sure Barbara and co. had good reasons...but I can't help but think
that part of issue was RPG's limited support of NULL. After all
options(*NULLIND) didn't come around till v5r4 and you still can't
define a stand-alone null variable.

I can't think of another language that differentiates between "not
passed" and "passed as NULL"...

From the perspective of the called procedure, disregarding the

existing implementation requirements...does it really matter to the
called proc if it was called
MyProc(var1);
or
MyProc(var1:*OMIT);

Not that I can see...in either case, the second parm is not available for use.

Charles


On Tue, Mar 8, 2011 at 6:17 PM, Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> wrote:

It's only jumping through extra hoops because he allowed *NOPASS (not
because of *OMIT, which *can* be passed through without problems, as you
yourself have already pointed out.)

Having a null-capable variable (like you have in a database) with
*NOPASS support would cause the same problem as *OMIT:*NOPASS.. because
the problem isn't the *OMIT or the null-support... it's the *NOPASS.

to put it another way:  The reason you use *NOPASS is because you don't
want to have to pass all of the variables each time you call the
routine.  *OMIT is clumsier to the caller, because you have to specify
*OMIT, even if you don't pass it.  Using null-capable fields (taken from
a database, and passed with options(*nullind)) would have the same the
same problem.  You'd have to pass all of the parameters each time.  You
couldn't leave them off when you don't need them.  Only *NOPASS gives
you the ability to leave them off.  If *NOPASS is desired, you'll always
have to check %PARMS, not only the null indicator.