Re: Memory being reused by %alloc on second call to program.

Hi Bryce,

If I F12 back to the first screen and change my search criteria to
something that shouldn't return results it still does but refined by
whatever I just searched by.

It's unclear to me whether this (the 'refine' stuff quoted above) is what you intended? Or what you're complaining about?

But, if it's the error, then I'd say it _has_ to be a bug in your code. I would step through the code to the point where it's starting the search and see why it's "refining" the criteria further.

If I F3 out of ProgramA then all the memory used by the StoredProc is
released even if I don't do a RCLACTGRP of ProgramA's activation
group.

Sorry, I don't follow this. How do you know all of the memory is released? Is it because you designed it that way, and have code to release the memory, and have tested it and it works? Or is this an oddity that you don't understand? And if it's an oddity, then how do you know it's happening?

If I search a second time after doing the full exit by the criteria
that should not return results then it works and returns no results.
(no results could also be a search that is too generic to have good
results, this is handled by the StoredProc).

No idea what you're saying here -- unless you're just saying that it's working as designed?

In the StoredProc I am doing the following Destroy call, the
DestroyArray() procedure just take a pointer to an array memory address
and does a dealloc(n) pWholeArray;

pArrayElem = *null;
DestroyArray(pWholeArray);
pWholeArray = *null;

I nulled the pointers for good measure but that didn't do anything.

"Nulling" pointers doesn't deallocate memory... The only reason to set a pointer to null is to cause the code to error-out if by mistake you end up using the pointer again. Or perhaps as a flag to tell your code that the memory isn't allocated.

It looks like the second call is doing an %alloc and starting at the same
memory address as the previous call had done.

Yes? The whole point of calling DEALLOC is so that the memory gets reused. Why would it surprise you when it _does_ get reused?

So when I %alloc a block the memory already contains the data from
the previous call. How do I handle this?

Are you assuming that the memory will be set to a value before it's given to you? When you allocate memory, it can have _any_ value in it... the system makes no promises about what the bytes will contain.

Often times it's set to hex zeroes -- thats probably the most common value. But there's no promise of that. The memory could have data from your previous program call, or it could have data that was previously set by another program in your job, or even parts of the OS. Never assume the memory you're given will have a particular value.

Most of the time, it doesn't matter. If you're coding a dynamic array, you have a static variable containing how many elements you've already allocated. Each time you add a new element, you add 1 to that number. You increase the memory size accordingly, and then you set the new element to it's new value. So there's no need to blank out the memory because you always set it to a value after allocating it.

But if you have a different scenario (and I can't think of one off the top of my head) where you _do_ need the memory to always start at blanks or zeroes or something else, you need to set it to that value yourself.