RE: Procedure returning a pointer, and debugging

 >> I see where you're coming from I think, but maybe an explanation (or a
link) to why it's a no-no would be helpful.

I'm afraid I haven't the time to dig out the link in the archives, but this
has been extensively discussed here before.

The way I view it is that it is OK to do this if the requirement is to
return fixed information that the subproc is responsible for
holding/generating.  What's the next invoice/PO/Customer number type of
thing.  But if the data changes on each request (e.g. the subproc is
building up a "record" that is the combination of a number of DB hits plus
calcs) then you run into issues of "ownership".  By definition a
subprocedure can be called from different points in an application.  If you
have it return a pointer to its internal storage, then the data can be
changed behind the back of the code that requested it because another
routine has called the subproc and requested a different "record'.  If the
data is not that large (say <200 bytes or so) I'd simply return it.  If the
data is too large for this approach, return the data as parm and return a
count (if returning a set) or a flag (sucess/fail).

Jon Paris
Partner400

www.Partner400.com
www.RPGWorld.com