×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
This is true, but the consequences of accessing an *OMIT parameter
that's set to *OMIT are well-known, and 100% predictable.
However, the consequences of accessing a *NOPASS parameter that hasn't
been passed are not predictable. It might give you an error, it might
not. It might change unused memory, it might not. It might change
actual used memory, or it might not. It's unpredictable.
With *OMIT, testing your code properly is sufficient to know that it was
written properly. With *NOPASS it's not -- you could have success during
testing, but have it screw up the program in unpredictable ways during
production.
So *NOPASS requires you to be an "expert" of sorts. (Very much like
*VARSIZE). You need to be able to determine via your own knowledge of
the environment whether your code is safe, and not via testing.
I find myself agreeing with others on this list when they say IBM should
do something about it. But, what, exactly? Should the procedure make
it's own copy of the parameter area, use the prototype to null out any
areas that weren't passed in it's own copy? Or should all ILE languages
be extended to know how many optional parameters there are, and fill the
optional parms with nulls? (That'd be very hard to do, since languages
like C and Cobol would have to be changed significantly, and they're
both following ANSI standards.)
Solving it within RPG might be better, but would be more costly for
performance. (Copying all parameters to a new space in memory on every
call.)
Oh well.
On 3/11/2011 10:21 AM, Rory Hewitt wrote:
Larry,
If a procedure has a parameter passed to it as *OMIT, then the address of
that parameter is null. If this parameter is referenced (including simply
passing it to another procedure), could that cause runtime problems?
I assumed (there I go again, making an ass...) that using that parameter
directly could give the same sort of problems as referencing an unpassed
parameter (even though they are very different things).
Essentially, all parameters are based variables and an omitted parameter is
simply one where the basing pointer is null. Thus my concern over passing an
omitted parameter to another procedure...
Rory
midrange.com
