Re: *NOPASS parameter retaining old value

[Bruce Vining <bvining@xxxxxxxxxxxxxxx>]

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.