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

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

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.



On 3/8/2011 1:43 PM, Charles Wilt wrote:
> Basically I mean there's no way to define a standalone null capable variable...
>
> Using *OMIT:*NOPASS means jumping though hoops when you need to just
> pass them along to other procedures...
>
> In the OP's case, I could see where better null support would allow
> proc1 to just call proc2 (disregarding the differences in type for
> parm1).
>
> Charles