× 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.



Here is a clip from the V5R4 RPG manual.

--------------------------------------
if OPTIONS(*NOPASS) is coded and you choose not to pass the parameter, the
procedure must check that the parameter was passed before it accesses it.

If the unpassed parameter is accessed in the called program or procedure,
unpredictable results will occur.
--------------------------------------




-----Original Message-----
From: Dennis [mailto:iseries@xxxxxxxxxxxx]
Sent: Wednesday, March 09, 2011 2:28 PM
To: RPG programming on the IBM i / System i
Subject: Re: Calling similiar (overloaded) procedure that has *nopass *omit
in the parameter

I didn't se Paul questioning Barbara's knowledge/expertise. (Maybe I
missed that.) I _did_ see him ask a valid question about where this may be
documented. One could argue, I suppose that we should 'just know,' but I,
for one, would disagree in this case since rules have changed to a point.

"Scott Klement" <rpg400-l@xxxxxxxxxxxxxxxx> wrote:

hi Paul,

Here's a program that should demonstrate the problem. Not sure why
you're arguing the point (do you really think you know more about this
than the lead developer of the RPG compiler?!) but I've known about
this
for QUITE a long time (longer even than ILE has existed) and I can
vouch
for her.

But, anyway... try this program, you will (most likely) see the
problem:

H DFTACTGRP(*NO)

D myProc PR
D parm1 10a
D parm2 10a options(*nopass)

D one s 10a inz('blah')
D two s 10a inz('blah')
/free
// For this call, %ADDR() will PROBABLY (but not guaranteed)
// work, because nothing in the parm stack has been used yet.

myProc(one);

// This call passes both parameters, so will work.

myProc(one: two);

// This call will PROBABLY (but not guaranteed) show that
// only one parm was passed, but %addr(parm2) won't be null.

myProc(one);

return;
/end-free


P myProc B
D PI
D parm1 10a
D parm2 10a options(*nopass)
D count s 10i 0
D msg s 52a
/free
count = %parms();
msg = 'You passed ' + %char(count) + ' parms.';
dsply msg;

if %addr(parm1) = *null;
dsply ('parm1 = *NULL');
else;
dsply ('parm1 <> *NULL');
endif;

if %addr(parm2) = *null;
dsply ('parm2 = *NULL');
else;
dsply ('parm2 <> *NULL');
endif;
/end-free
P E

When I call this, I get:

CALL MYPGM
DSPLY You passed 1 parms.
DSPLY parm1 <> *NULL
DSPLY parm2 = *NULL
DSPLY You passed 2 parms.
DSPLY parm1 <> *NULL
DSPLY parm2 <> *NULL
DSPLY You passed 1 parms.
DSPLY parm1 <> *NULL
DSPLY parm2 <> *NULL

Note that on the final call, it says you've passed only 1 parameter
(which makes sense, since that's what the code does) but parm2<>*NULL.



On 3/9/2011 8:28 AM, Morgan, Paul wrote:
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 ...




--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
Sent from my Galaxy tablet phone with with K-9 Mail. Please excuse my
brevity.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.