RE: Pointer suggestion -- RPG400-L

Hi Tom,

<snip>
I see the point about using an array since it is passed by reference rather
then value. But I was thinking more along the lines of the amount of data
that can be passed to a variable. I believe the max size would be around
32k. The record length I  will be using is around 250. If I need to return
say 500 records, that would put me way beyond that variable size limit. Does
using pointers allow me to access a greater amount of data?
</snip>

A pointer can allocate almost 16Mb of memory from the default heap of your current job. I say "almost" because I believe you can only allocate 1kb less than 16Mb.

Regarding passing file records from your subproc, you can:

Create a dynamic array (each element defined like your file record format), and a counter field to hold the number of elements you are processing. Base your array on a data pointer. You can then pass the pointer and the counter to your subproc. The subproc can then allocate memory to the pointer, increment the counter, and add data to the pointer for each record you retrieve. If you pass the pointer by value and the counter by reference then the array will automatically be populated when the subproc returns and you can then use a for loop to "read" the records from the array - using the counter as the maximum. This is better, IMHO, than passing a static array because you only allocate (and pass) enough memory for the pointer - 16bytes. If no records are found/returned then there's no overhead. If 100 records are returned then the memory is allocated dynamically - and you're still only passing 16bytes around. I use a similar technique when creating XML documents to send to a remote system - the XML docs can easily exceed 100kb. Just ensure you check that your memory (re)allocations succeed - wrap your code in a MONITOR block and check for pointer errors. It doesn't happen often, but there is a possibility that the system can not allocate the memory you require at that particular point.

However, if the number of records will always be within an expected/determinable range then I'd probably suggest creating a static array, with a pre-defined max size, and passing the address of the array along with the counter. This is less flexible but will run faster because the array is held in static storage and not heap storage. (faster than very very fast might not buy you as much time as you think though. :-) )

Basically, it all depends on the nature of your returned data, and how simple/complex you want to make it. If you expect wild deviations in array size then dynamic allocation would be better, if you don't then use a static array.

Cheers

Larry Ducie