Scott -
Thanks, this definitely does make sense. Unfortunately, the value of
arrayPtr is the same immediately following the %ALLOC and just prior to
the %REALLOC. I had a feeling that was the problem so that was one of
the first things I checked. Is it possible that somehow somewhere, this
memory is being reallocated or deallocated outside of this service
program?
Interestingly when the program is run outside of debug, we also get a
call stack error:
Cause . . . . . : Call stack entry *PRV, specified for the send,
receive,
move or delete message operation, could not be found in the call
stack.
Perhaps that is irrelevant though, it's coming after an error regarding
a buffer length problem and the reallocation error happens about a
minute later.
So really most of our confusion is stemming from the fact that the
pointer value does seem to be the same and is not changing; so, we can't
determine when/where the memory is being lost.
Lorraine
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Wednesday, July 30, 2008 12:02 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: CEE0810 Error on Reallocate Statement
Hi Lorraine,
Please run the program in debug, and place a breakpoint right after the
%ALLOC statement, and another breakpoint right before the %REALLOC
statement.
Right after the %ALLOC, display the value of the pointer. Write it down
or screen print or something for later reference.
Just before the %REALLOC display the value of the same pointer. Are
they the same? (The error message suggests that they are not.) You
need to make sure that the value in arrayPtr doesn't change between the
%ALLOC and the %REALLOC. (If the %REALLOC is successful, it may change
that address -- and that's okay -- but between the initial %ALLOC and
the %REALLOC they need to be unchanged.)
Here's what's going on: The memory in your computer is shared by lots
of different jobs/threads that are all running concurrently. It's very
important two different jobs/threads don't end up using the same memory.
So when you call %ALLOC, the computer reserves that memory, and won't
give it out again until you deallocate it. How does it reserve the
memory? It keeps a table of all of the starting addresses, i.e. the
addresses returned by %ALLOC.
If you want to make the allocation larger (i.e. %REALLOC) the system has
to look up the old address in that table -- and the problem is that
address you've provided isn't found in the table.
So, either your address has changed from what %ALLOC assigned you, or
the memory has already been deallocated.
Hope that makes sense.
Lorraine.Ford@xxxxxxxxxxx wrote:
One of our developers is running into a hard halt error, CEE0810, on a
reallocate statement. This is in a service program, which another
program is using CALLP to access. She has her pointer and array
defined
as follows:
d array s 32a dim(32767)
d based(arrayPtr)
d arrayPtr s *
Does her initial allocation:
// allocate storage, if necessary
if wa = *zero;
wa = 100;
arrayPtr = %alloc(wa * 32);
endif;
And then reads records from a file using SQL. It's that data she's
going to store in the array. So, if it's determined she needs to
store
more than 100 elements, the program attempts to reallocate:
if b2 > wa;
wa += 100;
arrayPtr = %realloc(arrayPtr:wa * 32);
endif;
The reallocate fails with CEE0810:
The starting address for reallocation is not valid.
Function check. CEE0810 unmonitored by PGMNAME at statement
0000000855,
instruction X'0000'
No one has any idea what the problem is, research has turned up
nothing.
Could the problem be something like since this is a service program,
and
it's on the 5th call to the service program that the reallocate logic
is
executed, somehow the program has lost the location of the original
allocation so it doesn't know where to go to reallocate? There's no
other logic in the program that's manipulating the value of the
pointer
other than the allocate and reallocate statements above.
Thanks for any ideas,
Lorraine
midrange.com
