|
I've been watching this discussion with some interest and I thought I'd jump in with my thoughts.... Not sure I see a difference between returning 1 data structure and an array of them. I wouldn't want to use a MODS, but I have been leaning toward something like: //------------------------------------------------------------------------ // Data Structure Templates //------------------------------------------------------------------------ d t_BasicListEntry... d ds based( TEMPLATE ) qualified d myKey1 like(t_key1) d myKey2 like(t_key2) d myName like(t_name) //------------------------------------------------------------------------ d PositionBasicList... d pr d myKey1 const like(t_key1) d myKey2 const like(t_key2) //------------------------------------------------------------------------ d GetBasicList... d pr n d nbrRecReq const like(t_Int4) d nbrRecRtn like(t_Int4) d entryArray likeds(t_BasicListEntry) d dim(32767) d options(*VARSIZE) Then using it like so: /free noMoreRecs = SeqExcp_GetBasicList(SUBFILE_PAGE_SIZE:nbrRecsAvail:dataArray); For x = 1 to nbrRecsAvail; MoveDataToSubfile(dataArray(x)); wrkSlfRrn = wrkSlfRrn + 1; Clear SelIo; Write wrkSlf; EndFor; dspfControl.endofSubfile = noMoreRecs; /end-free It seems to me, the requirement to "get a basic list" is often repeated. Doesn't matter if the calling application is a green screen subfile or a web app. My definition of a "basic list" would be unique key fields and a minimum number of descriptive fields. For example, item#, description, and size. If your list requirements change, then you create a new format and modify the applications that need it. Basically, I'm following IBM's example here. How many APIs do they have that return some sort of list? In addition, I disagree that returning an data structure or an array provides any info into the service program internals. This is an argument you often see in OO programming. The concern is valid if you are in fact returning a reference or a pointer to some internal structure. But if instead of a reference, you return a new copy of the internal array. Then you've got no problem. If you need to move the internal representation from an array to say a linked list, you can. Just make sure you can build an array to return from the internal linked list. The fact the procedure returns (or changes) an array, a given DS, or simply an integer doesn't tell you anything more than that procedure knows how to build or write to that particular "data type". The data type is simply part of the procedures defined interface. Charles Wilt -- iSeries Systems Administrator / Developer Mitsubishi Electric Automotive America ph: 513-573-4343 fax: 513-398-1121 > -----Original Message----- > From: rpg400-l-bounces@xxxxxxxxxxxx > [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Alan Campin > Sent: Wednesday, July 06, 2005 2:01 PM > To: RPG programming on the AS400 / iSeries > Subject: RE: Multi Occurrence Data Structure returned from a procedure > > > I still can't see why we need to do something like this is > ILE/RPG. Create the list internally and code a procedure to > retrieve each record. Just don't see a reason to return > arrays or multiple occurrence data structures. ILE/RPG gives > us the tools. IBM has made procedures extremely fast. I don't > see any reason not to use them. If I am making 10 calls at > .00000054 seconds per call, I don't see much in the way of overhead. > > The other issue I see is that the caller has to know the > internal structure. I am really not that comfortable with > even returning data structures but creating a function to > retrieve each value doesn't seem to work very well. I > struggle with that one. > > Anyway, my opinion again. >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.