Re: *NOPASS parameter retaining old value

I assume either that Rick was checking the value of ForceRead in debug, or
that somewhere later in his code, he checks ForceRead again. As has been
pointed out, if this is the case (and it's probably good practice anyway),
he should set a work variable to the value of ForceRead (if it was passed)
or to a default value, and then only use that work variable. My personal
preference is to preface optional parameters with a value and then give the
work field the 'proper' name, e.g.:

D pForceRead N Const Options(*Nopass)
...
D ForceRead S N Inz(*off)

/free

if %parms > 3;
ForceRead = pForceRead;
endif;

If (PreviousBank <> Bank or PreviousLoan <> LoanNumber) or ForceRead;
...

Rory

On Wed, Jan 27, 2010 at 10:18 AM, Scott Klement
<rpg400-l@xxxxxxxxxxxxxxxx>wrote:

Hello,

The code works fine. What I don't understand is why ForceRead has a
value. When I run in debug I would expect the evaluation of the
ForceRead parameter to not be addressable because it wasn't passed.

You are using an area of the computer's memory that you weren't meant to
use. The value of that area of memory is undefined. It might contain a
valid pointer, but it might not...

In your example, when you previously called it with the ForceRead set to
'1', it put a pointer in that spot in memory that points to a value of
'1'. By some stroke of luck, nothing else has re-used that area of
memory, so you end up getting the '1'.

If "something else" reuses the area of memory, then that routine might
by chance store a pointer there. In that case, you might get a
"garbage" value (actually, just a value that doesn't make sense in
context.)

If "something else" reuses the memory for a non-pointer, then you'd end
up with the pointer error you're expecting.

Ultimately, reading that area of memory without first checking %PARMS to
make sure it belongs to you is NOT valid. You MUST check %PARMS before
using it (which you are doing in your code, just not when you evaluate
the variable in the debugger.)