No it is not true. The address (pointer value) is all the system sees, it has no idea what procedure allocated the storage. Any procedure with that address can access the storage, so if the caller allocates the storage passes the pointer to another procedure and reallocates storage using that pointer the system just looks up that address does the realloc, and returns the new pointer, which may or may not be the same address as the original. Thats why you have to pass that pointer by reference so that the caller has the new address passed back.
If you have a procedure in a different activation group from the caller, the same idea holds true. Except storage allocated in the called procedure is allocated in the heap in that activation group and if it is a *NEW activation group or if the RCLACTGRP command is run then the returned pointer is meaningless and you will get an exception if you attempt to use it. If the pointer is initially allocated in the caller then you can avoid this possable problem.
Duane Christen
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Lim Hock-Chai
Sent: Friday, September 19, 2008 11:13 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Dynamic Array as return/output parameter in export
procedure
Ok. Thanks Duane.
I did not state my main concern very well in my OP. The main concern
I've in the op is that the called procedure is allocating the memory and
returns it to the caller to consume, which Scott has already stated that
memory allocation is usually done my caller not called procedure.
In your example, you did an allocation in the caller first. The called
procedure then does the %realloc if needed. I was thinking, since
caller did the allocation first, that might trick the system to think
that the memory is still belongs to the caller after the %realloc in
called procedure. I doubt this is true.
"Christen, Duane J." <Duane.Christen@xxxxxxxxxxxxx> wrote in message
news:<mailman.11998.1221840185.2545.rpg400-l@xxxxxxxxxxxx>...
First, Scott has a point, several infact. But to your questions here.
The caller does not know how many elements are needed but it will need
to know how many elements are used if it has to do any processing of the
array. The caller will also have to know how many elements are used from
previous calls so there must be some kind of counter/index to keep track
of the elements used. You also have to keep track of the storage used so
you don't try to use storage you have not allocated.
The %realloc isn't a trick, a dynamic array (or any allocated storage)
is, partly, an attempt to use storage sparingly/wisely. %Realloc takes
the storage currently pointed at by the pointer parameter and
extends/contracts the storage allocated to that pointer to the size
parameter. %Realloc may need to find a larger area of unreserved storage
to fit the request, so it will copy the contents of the currently
allocated storage to the new block, this will change the value of the
pointer.
If you look at the structure arrayDs there is a field called "static"
that has nothing to do with the RPG keyword static. I use the field
"static" in the structure to describe the un-changing portion of the
structure, the storage that is initially allocated to store the "count"
of elements and "size" of allocated storage, both fields overlay the
"static" field.
Duane Christen
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Lim Hock-Chai
Sent: Friday, September 19, 2008 10:05 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Dynamic Array as return/output parameter in export
procedure
In my case, the caller does not really know how many elem is needed.
The called procedure (export procedure) determines that. From your
example, are you saying that the %realloc would trick the system to
think that the heap storage belongs to the caller? Or am I over
thinking?
Note: The export procedure could get called multiple times before the
caller dealloc the dyna array. Making the array static in the export
procedure might not work for me.
From
"Christen, Duane J." <Duane.Christen@xxxxxxxxxxxxx> wrote in message
news:<mailman.11963.1221835629.2545.rpg400-l@xxxxxxxxxxxx>...
This is the way I would do it.
Build your structure like this:
D arrayDs DS based(pointer)
D Qualified
D static
D count 10I 0 Overlay(static)
D size 10I 0 Overlay(static : *NEXT)
D array 20A Dim(32767)
Use a template in a copybook if possable, because both the caller and
called procedure need the definition.
Then, in the caller allocate the storage needed for the static part of
the structure:
pointer = %Alloc(%Size(arrayDs.Static));
Call the procedure, making sure that the pointer is passed by reference.
In the called procedure, when you need more storage for your array do:
arrayDs.Size += %Size(arrayDs.Array * 200);
arrayDs.Count += 200;
piRtnListDynaArray = %ReAlloc(arrayDs.Size);
When you are done loading your array set the arrayDs.Count value to the
last element in the array that was loaded, so that the caller knows how
many elements of the array were loaded.
Duane Christen
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Lim Hock-Chai
Sent: Friday, September 19, 2008 9:14 AM
To: RPG programming on the AS400 / iSeries
Subject: Dynamic Array as return/output parameter in export procedure
is there a way to safely return a dynamic array from an export procedure
to the caller? Something like below just doesn't look very safe for me.
P getListInDynaArray...
D pi
D piKey 4
D piRtnListDynaArray...
D *
D myDynaArray s 20 dim(32767) based(myDynaArray_p)
/free
myDynaAry_p = %alloc(200);
. . .
piRtnListDynaArray = myDynaArray_p
/end-free
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/rpg400-l.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit
http://www.messagelabs.com/email
______________________________________________________________________
NOTICE: This electronic mail transmission may contain confidential
information and is intended only for the person(s) named. Any use,
copying, or disclosure by any other person is strictly prohibited. If
you have received this transmission in error, please notify the sender
via e-mail.
----------
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/rpg400-l.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit
http://www.messagelabs.com/email
______________________________________________________________________
NOTICE: This electronic mail transmission may contain confidential
information and is intended only for the person(s) named. Any use,
copying, or disclosure by any other person is strictly prohibited. If
you have received this transmission in error, please notify the sender
via e-mail.
----------
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/rpg400-l.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit
http://www.messagelabs.com/email
______________________________________________________________________
NOTICE: This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying, or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
midrange.com
