Re: File/Service Program/Data Structure Problem...

[Scott Klement <klemscot@xxxxxxxxxxxx>]

Hi Brad,

Interesting problem! :)   I tried it myself, and got the same results that
you describe...  Rather strange.  Here's my only guess at the problem:

The compiler must create a routine that copies data from the file into
each field in your program.  

In other words, when compiling it looks at the input specs that it pulled
in from your external description, and creates a routine to copy the data
from those positions in the file into variables that are locally allocated
to your program (which it also defined from your external description.)
Perhaps the compiler gets tripped up when those local variables are 
based on a pointer?

My tests seem to indicate that the compiler cant properly handle that
situation.  Perhaps Hans or Barbara could shed some light on why?

An alternate approach would be to have the data structure in the service
program NOT be based on a pointer.  Instead, have the calling program 
base its data structure on a pointer.   Call the service program asking
to open the file, and have it pass back the address of the data structure.

For example:


----------------------------SERVICE PROGRAM----------------------------
     H NOMAIN

     FCUSTMAS   IF   E           K DISK    USROPN

     D OpenFile        PR            10I 0
     D   p_struct                      *

     D ReadNext        PR            10I 0
     D  p_struct                       *

     D CloseFile       PR            10I 0

     D dsData        E DS                  ExtName(CUSTMAS)


     P OpenFile        B                   export
     D OpenFile        PI            10I 0
     D   p_struct                      *
     c                   open      CUSTMAS                              10
     c   10              return    -1
     c                   eval      p_struct = %addr(dsData)
     c                   clear                   dsData
     c                   return    0
     P                 E


     P ReadNext        B                   export
     D ReadNext        PI            10I 0
     D   p_struct                      *
     c     cuCust        setgt     CUSTMAS
     c                   read      CUSTMAS                                10
     c   10              return    -1
     c                   return    0
     P                 E


     P CloseFile       B                   export
     D CloseFile       PI            10I 0
     c                   close     CUSTMAS                              10
     c   10              return    -1
     c                   return    0
     P                 E


----------------------------------CALLING PROGRAM-------------------------

     D OpenFile        PR            10I 0
     D   p_struct                      *

     D ReadNext        PR            10I 0
     D  p_struct                       *

     D CloseFile       PR            10I 0

     D p_struct        S               *
     D dsStuff       E DS                  ExtName(CUSTMAS) based(p_struct)

     c                   if        OpenFile(p_struct) < 0
     c                   eval      Msg = 'OpenFile() failed.'
     c                   dsply                   Msg              50
     c                   endif

     c                   dow       ReadNext(p_struct) >= 0
     c     cuCust        dsply
     c                   enddo

     c                   callp     CloseFile

     c                   eval      *inlr = *on



If you wanted to be more fancy about it, you could define dsData in
the service program as multiple occurance data structure.  Then, each
time OpenFile is called, add 1 to the occurance.  

Then your calling program could potentially define several data structures
and call OpenFile multiple times, essentially giving you "many copies" of
that file open...

Hope that helps...



On Thu, 11 May 2000, Stone, Brad V (TC) wrote:

> This is a tough one to explain, so bare with me.
> 
> Ok... 
> 
> I have PGMA.  It is using FILE1. 
> I have SRVPGMA that contains a procedure that passes me back the value of
> the field that I pass it.  For example, I say:
> 
> eval value = #RtvValue('FIELDNAME':Field@)
> 
> Field@ is a pointer to a data structure that is defined in PGMA as an
> external data structure using FILE1.  This is so they have the same field
> names and the data is loaded into the DS automatically when I read a record.
> 
> I do this so that I pass the service program the values in the file, the
> service program does a big SELECT statment, and returns the value of the
> 'FIELDNAME' parameter.
> 
> Now, in SRVPGM1, I accept the field name and the pointer to the DS that
> contains the value.  In SRVPGM1, I have another external DS defined from
> FILE1, same as in PGM1.
> 
> The DS is SRVPGM1 gets the data just fine, etc... etc...
> 
> Now the tricky part.
> 
> In SRVPGM1, I also have an option to retrieve the *NEXT value (like for a
> detail file.)  So, I do a SETGT on FILE1 in SRVPGM1 to position to the next
> record, then read.  The key list is made up of the fields in the DS.
> 
> Now, because the DS is created from FILE1, it has the same field names as
> the DS.  This is what I want.  So, when I read the file, the fields in the
> DS will automatically contain the "NExt" record.
> 
> But, after the read, the values do not change in the DS.  I watched the file
> pointer and everything moves fine, even does an IO on the read and is
> positioned on the RRN of the records I expect it to read.  But the data
> stays the same as when I passed it in with the pointer, and doesn't change
> to the values of the current record I read in the file.
> 
> Hard to follow, yes.  But, if anyone has any ideas why the values of the
> fields in the DS aren't changing, that would be great.
> 
> Brad

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---