× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

Just to give you my companies experience with this. . . We are putting an
interface over the data base with ILE and have getter and setter methods to
retrieve stuff out of "objects".  One of the reasons we were going to do the
interface was to lessen the amount of programs that would need to be
recompiled in the event that we added another field to a file.  The reason
we opted out of passing data structures back and forth was because then you
have to have your item file defined in your program as an external data
structure vs. doing something like the following:

C            if     chainItemFile('HAT102') = found
C            eval   item = getItem()
C            eval   desc = get ItemDesc()
C            eval   qoh = getQtyOnHand()
C            endif

The above example allows us to add fields to the Item file and only have to
recompile the *module that is used to interface with the Item file.  If a
program uses the Item file, but doesn't need a new field, then we don't have
to recompile it, and in the long run we don't have to distribute it to our
companies.  We had to do it this way because we have 20+ companies that need
our business software and when we make an addition to the customer, item, or
order files we have to send a ton of programs, and that just takes too much
time.

my .02

Aaron Bartell

-----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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.