Re: dealloc (Correction)

An addendum to Scott's post:

Remember that when you use the DEALLOC opcode, you're simply telling OS/400
that it CAN use the pointed-to memory for something else. It MAY do so
immediately, or it may leave it alone for a while, retaining the value it
had before you deallocated it. You have no control over it - once you use
DEALLOC, that memory isn't 'yours' any more.

You can run into serious trouble if you accidentally leave code in your
program which subsequently uses the memory pointed to by the pointer, even
after the pointer has been deallocated. It may work fine in some
circumstances (because OS/400 hasn't yet done anything else with the memory)
and it may fail in others. You might not experience a problem on a
development machine, but it might cause a crash or data corruption on a
production box - it's purely down to how OS/400 decides to (re)use memory.

My favorite analogy is of you pulling out of a parking spot (doing a
DEALLOC), driving around the block and coming back and trying to pull into
the parking spot again - if you're LUCKY, it'll be free. If you're not
lucky, there's the sound of rending metal and insurance bills.....

These errors are HORRIBLE to find in production, because there may be no
obvious cause, the problem might be intermittent and the same program will
work fine in some jobs/astrological signs on some machines/dates/solar
phases and not on others.

Hence, it's ALWAYS a good idea to use the N extender to the DEALLOC op-code.
That way, you'll pick up any of these errors in testing, because your
program will throw an error. Frankly I don't know why IBM didn't make the
N-extender the default - backwards-compatibility, I assume.

Rory


On 12/6/06, Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> wrote:

DEALLOC does have an optional (N) extender that tells it to set the
pointer to null -- just a convienience feature, mind you -- but don't
think of deallocating and setting the pointer to null as being related,
you'll just get yourself confused.