RE: How can I Improve this procedure...

Hi Brad,

<snip>
This begs the questions:

1.  Is 1k, 32k or 64k considered a LOT of memory these
days?
2.  When is this temp memory reclaimed?  I assume at the
completion of the call to the subproc
3.  How much memory, compared to this, would a Java app (or
something like Websphere alone, without even considering
the apps) use?  When this is thought about, is it really "a
lot" or "too slow?" to use large string return variables?
4.  Was the return parm implemeted wrong at the machine
level?  Are we programming around that by returning a
pointer or using a parm return value instead of a return
value?
<snip>

My thoughts on these questions....

1. Depends on who you ask.  In this case, the answer is "RPG thinks its a
lot"...  From a modern standpoint, these are not really very big at all, but
if returning 5000 bytes via a return value sucks all the wind from your app,
then the question is moot.  

2. Return values, I would assume (I know, DANGEROUS), use automatic storage
to do their thing.  In this case, this should be freed after RPG gets the
copy into static storage.
Here's a short article about storage classes...
http://search400.techtarget.com/tip/1,289483,sid3_gci818503,00.html

3. Performance is relative....  If the use of large return values is
necessary, then performance becomes secondary in importance to the correct
functional result.  However, if this performance penalty can be eliminated
with a minor revision (to use in/out parm to pass back return data), then
that clearly becomes the better approach.  I understand that sometimes we
MUST use return values.  Not much to do about that but make the best of
it...

4. I don't know...  I'm pretty happy with what we've got.  I think Scott and
Bob covered the under the hood stuff pretty well, and it's clear that return
values have a lot of data management overhead....  I haven't had any bad
experiences with return values yet...

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863