RE: Main Proc for Subproc not compiling

["Chevalier, Rick" <Rick.Chevalier@xxxxxxxxxxxxxxx>]

Joe,

I don't think it's as easy as it sounds to allocate the storage and pass
back the record read.  I have tried this in some sub-procedures and ran into
a problem.  When the sub-program ended the memory was released.  The pointer
made it back to the calling program OK but the storage it pointed to didn't
contain the data I wanted.  I had to pass the pointer into the sub-procedure
to make it work.

Of course it could be I just wasn't doing something correctly with the
sub-procedure.

Rick

 -----Original Message-----
From:   Joe Pluta [mailto:joepluta@PlutaBrothers.com]
Sent:   Friday, November 22, 2002 1:30 PM
To:     rpg400-l@midrange.com
Subject:        RE: Main Proc for Subproc not compiling

> From: Barbara Morris
>
> You could return the structure instead of using a parm, but that might
> involve returning a "large value", which is not really recommended.

This is an interesting point, Barbara.  Let's say I want to create a group
of procedures that are, for lack of a better term, object-like.  By that, I
mean that I use them to grab data from the database, pass it around to other
procedures, and eventually perhaps update it.  For example, let's say it's
item data.

Okay, I want to use a data structure to hold this data.  And since I can
have multiple "instances" of the data, I want the application, not the
procedure, to keep track of the storage.  Finally, say that one of the
procedures is the "create" (or perhaps "get" is a better word) procedure.
Something like this:

H nomain
FITEMFILE if      e       disk
D ItemDS      e ds               extname(ITEMFILE)

D GetItem   pr                   like(ItemDS) EXTPROC('GETITEM')
D   ItemKey                      like(ITEMNUMBER) const

ITEMBUMBER is an alpha field, so I could conceivably do:

C           eval  ItemDS = GetItem('MyItemKey')

But you're suggesting that returning a DS is not a good idea.  Why is that?
And what would you recommend instead?

D GetItem   pr             10I 0 EXTPROC('GETITEM')
D   ItemPtr                  *   const
D   ItemKey                      like(ITEMNUMBER) const

C           eval  rc = GetItem(%addr(ItemDS):'MyItemKey)

And having the called procedure copy the data into the pointer?  I actually
can see where this might have more utility, because the 'rc' allows for
better error checking.  I'm just trying to get my head around a generic way
to handle these sorts of object-based issues.

Way back when, we did exactly this sort of thing with C, although we usually
went one step further:

H nomain
FITEMFILE if      e       disk
D ItemDS      e ds               extname(ITEMFILE) BASED(pItemDS)

D GetItem   pr                   like(pItemDS) EXTPROC('GETITEM')
D   ItemKey                      like(ITEMNUMBER) const

C           eval  pItemDS = GetItem('MyItemKey)

GetItem would actually allocate the memory for the ItemDS and return it.
We'd check pItemDS for null to check for an error.  I suppose I could just
as easily code:

D GetItem   pr             10I 0 EXTPROC('GETITEM')
D   ItemPtr                      like(pItemDS)
D   ItemKey                      like(ITEMNUMBER) const

C           eval  rc = GetItem(pItemDS:'MyItemKey)

Since pItemDS is not constant, the called procedure could allocate the
memory and update the pointer.

Given this plethora of options, which is suggested and why?

Joe

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.