RE: Multi Occurrence Data Structure returned from a procedure

["Wilt, Charles" <CWilt@xxxxxxxxxxxx>]

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