Re: *NOPASS parameter retaining old value

Rick,

From the RPG Reference on OPTIONS(*NOPASS): If the unpassed parameter is

accessed in the called program or procedure, unpredictable results will
occur. This tip can also be found: 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. The compiler will not do any
checking for this.

When calling a sub-procedure I generally use OPTIONS(*OMIT) and then test
the address of the omitted parameter (for null). This does mean passing
*OMIT on all of the sub-procedure calls that do not pass the fourth
parameter.

Bruce

On Wed, Jan 27, 2010 at 9:15 AM, <Rick.Chevalier@xxxxxxxxxxxxxxx> wrote:

I ran across what I think is strange behavior in a sub-procedure.

I have a procedure with four parameters. The fourth, ForceRead, being
defined with *NOPASS. Most calls to this procedure do not pass the
ForceRead parameter, only those that require the data file be read to get
any updated information. I am seeing a situation where the ForceRead
parameter has a value of 1 in the called procedure even though it wasn't
passed by the caller. Because ForceRead isn't being passed I expected to
get something like a null pointer message. Can anyone explain this to me?


d GetLoanInformation...

d pi

d Found n

d Bank 3s 0 Const

d LoanNumber 12s 0 Const

d ForceRead n Options(*NoPass) Const



// Only chain to the loan master if working on a new loan

If (PreviousBank <> Bank or PreviousLoan <> LoanNumber) or

(%Parms > 3 and ForceRead);





Rick Chevalier
IT Software Solutions - Loan Servicing
[http://www.americredit.com/images/acf_email_sig.gif]



________________________________
Privileged and Confidential. This e-mail, and any attachments there to, is
intended only for use by the addressee(s) named herein and may contain
privileged or confidential information. If you have received this e-mail in
error, please notify me immediately by a return e-mail and delete this
e-mail. You are hereby notified that any dissemination, distribution or
copying of this e-mail and/or any attachments thereto, is strictly
prohibited.

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