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

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