RE: Pointer suggestion

Why are you using pointer and arrays at all? The whole concept of ILE is to 
make create procedures that do one thing very quickly so if you have one 
function to build the records, a function to return a count and a function to 
return a record in a loop, why would you need an array at all? Why not use ILE 
as it was meant to be used. 

Also, as to using pointers. My opinion only but returning pointer is very poor 
programming practice assuming this is coming from a service program. I can't 
think of worse way to implement a service program than returning a pointer. I 
have just written a memo in our office, that my boss will not release, about 
this entire subject. 

-----Original Message-----
From: Larry Ducie [mailto:larry_ducie@xxxxxxxxxxx]
Sent: Friday, February 18, 2005 7:43 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: Pointer suggestion


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