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