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



Larry,

I understand the dangers of accessing unpassed parameters all too well :)

My concern was with whether you could pass on an omitted parameter - it
wasn't clear to me whether the act of referencing the omitted parameter
(even just passing it to another program without attermpting to retrieve or
set its value) could cause a PNS error. As that is not the case, then this
whole thing becomes much easier, as my original code to check for parms and
simulate *OMIT for unpassed ones would work fine (although whether the
called procedure is coded to handle that is another matter).

Rory

On Sun, Mar 13, 2011 at 1:33 AM, Larry Ducie <larry_ducie@xxxxxxxxxxx>wrote:


Hi Rory,

Here is a quick sample program that shows how we can pass *OMIT along a
call chain: http://code.midrange.com/e73d188de3.html

In this program I have created a proc1 and proc2 with the following pi:

d procX pi
d parm1 1a
d parm2 1a options(*omit : *nopass)
d parm3 1a options(*omit : *nopass)

proc1 calls proc2 as follows:

proc2(parm1 : parm2 : parm3);

Note: ALL THREE of its parms (whether they are passed, omitted, or
missing) are ALWAYS passed to proc2.

proc1 is called from the main procedure in the following ways:

proc1(var1 : *omit : var3);
proc1(var1 : var2);
proc1(var1);

In all three instances proc1 happily passes parm1, parm2, and parm3 to
proc2, even when they are not passed to proc1. This is fine if a *OMIT is
passed because proc2 can still check the address and if not null use it. It
is the calling of proc2 with all three parms using parameters that were not
passed to proc1 that is the real danger. The value of %parms within proc2
will always be 3 in every call from proc1 so it is of no use in checking if
a parm was passed. Checking the address is now a danger too because
sometimes it actually might not be null - even when the parm was not passed.

Copy-n-paste the code. Compile and run it in debug. You should check the
values as the calls are made. The debugger will give you 'pointer not set
for location referenced' in proc1 and proc2 for parm2 when it is omitted.
What it will give for the missing parms in proc2 is anybody's guess.
Sometimes it will even give you a value - even though it was never passed!

Cheers, and have fun!

Larry Ducie



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





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.