From the RPGIV reference in the page concerning OPTIONS(*NOPASS *OMIT ... I find
When OPTIONS(*NOPASS) is specified on a definition specification, the parameter does not have to be passed on the call. Any parameters following that specification must also have *NOPASS specified. When the parameter is not passed to a program or procedure, the called program or procedure will simply function as if the parameter list did not include that parameter. If the unpassed parameter is accessed in the called program or procedure, unpredictable results will occur.
So it says if the unpassed parameter is accessed unpredictable results will occur. It doesn't say anything about how you access the unpassed parameter, just that if you do the results are unpredictable. Just because it doesn't specifically mention the %addr() builtin, doesn't mean that you can use it. No built-in's or op codes are specifically mentioned.
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
-----rpg400-l-bounces@xxxxxxxxxxxx wrote: -----
To: RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
From: "Morgan, Paul"
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
Date: 03/09/2011 09:34AM
Subject: RE: Calling similiar (overloaded) procedure that has *nopass *omit in the parameter
I'm curious where in the V5R4 documentation it mentions that using %addr() on a *NOPASS parameter is unreliable? With my testing on program subprocedures it works. Maybe with further testing it won't. Maybe it won't work with a service program procedure. The RPG documentation (reference and user guide) talks about using %addr() on an *OMIT parameter but no mention of results on a *NOPASS parameter.
Paul Morgan
Principal Programmer Analyst
IT Supply Chain/Replenishment
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of John McKay
Sent: Wednesday, March 09, 2011 1:35 AM
To: RPG programming on the IBM i / System i
Subject: Re: Calling similiar (overloaded) procedure that has*nopass *omitinthe parameter
Barbara,
Lucky programmers document and test, test and document. They also
read the documentation and the code.
Regards,
John McKay mba
On 08/03/2011 23:00, Barbara Morris wrote:
On 2011/3/8 3:18 PM, Morgan, Paul wrote:
Have you tried to check the address of a *nopass parameter if it
wasn't passed? I get *NULL when I check in my test program and the
program doesn't break.
You've been unlucky then. If you were lucky, you would have seen a
non-null pointer that just happened to be lying around where your
program was looking for it, and your program would have broken because
it thought the parameter had actually been passed.
Sometimes programs and procedures that access unpassed parameters can
work for years, and then something changes about what happens before the
program or procedure gets called, and *boom*, you get an error.
Everything might seem to work fine until you demo it to your boss, or
until just after it goes into production, or until just before you go on
vacation, or ...
midrange.com
