RE: Pointer Question -- RPG400-L

Hans,

On tighter debugging, I've determined that the 601 error is occuring on a
CLEAR *ALL to the MODS name.  I'm doing REALLOC's to this MODS one record at
a time and the pointer address changes each time (as it should) I reallocate
the additional amount of memory needed.  At the time of the CLEAR operation,
the pointer is still pointing to the address it was changed to on the last
REALLOC operation.  The offending code is:

C                   CLEAR     *ALL          ScanReplSrc

An interesting point is that even though ScanReplSrc is a 150 byte
datastructure, the dump obtained after the MCH0601 shows it to be a type of
ZONED(5,0).  In the dump, the pointer is still showing the valid address
that was set at the last REALLOC, but the MODS name shows a value of NOT
ADDRESSABLE.

Apparently, I just can't use CLEAR *ALL after a MODS has been moved?  Is
CLEAR trying to clear the MODS at it's original address rather than it's
current address?  If I just REALLOC the MODS back down to 1 byte, and then
REALLOC it back up to it's current size, will that effectively clear out all
the prior data? Or, will it reset the pointer to the same address (since the
amount of memory is the same) and see the data that was previously loaded
there?

> -----Original Message-----
> From: Hans Boldt [SMTP:boldt@ca.ibm.com]
> Sent: Wednesday, June 19, 2002 3:53 PM
> To:   rpg400-l@midrange.com
> Subject:      Re: Pointer Question
>
> Smith, Nelson wrote:
> > I've got a MODS based on a pointer with OCCURS = 32767.  I ALLOC &
> REALLOC
> > memory to the pointer all during the program.  At some point, I DEALLOC
> the
> > pointer and it changes to a NULL pointer.  If I then ALLOC to it again,
> the
> > pointer takes on a valid address, but references to the MODS cause a
> space
> > offset error (MCH0601) due to trying to operate outside of  "an implicit
> > process space for activation group-based heap storage".
>
> For that last ALLOC before the abend, are you allocating *less*
> storage than the previous?  The occurrence number is assigned to
> static storage, and does not change when storage for a based MODS is
> reallocated.  Perhaps the program is abending because the occurrence
> number points to an occurrence beyond the end of the allocated storage?
>
>
>
>
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.


************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information 
which maybe confidential or privileged and is intended only for the individual 
or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the 
contents of this message.
All personal messages express views solely of the sender, which are not to be 
attributed to Lincare Holdings Inc., and may not be copied or distributed 
without this disclaimer.
If you received this message in error, please notify us immediately at 
MailAdmin@lincare.com or (800) 284-2006.
************************************************************************************************************************************************************************************************************