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


  • Subject: RE: File/Service Program/Data Structure Problem...
  • From: "Stone, Brad V (TC)" <bvstone@xxxxxxxxxxxxxx>
  • Date: Fri, 12 May 2000 07:44:37 -0500

Funny thing is, which I also responded to someone else, in the SErvice
program I tried prefixing the data structure and it STILL didn't update the
file fields.

I am using the same file in the program and service program.  Program uses
AG QILE, Service Program uses *CALLER.  File pointers change, etc... but the
fields don't. It's really quite odd.

I'm going to try running the service program in a different AG to see if
that helps, but I am guessing it shouldn't make a difference.

Hans, Barbara, any ideas?  

> -----Original Message-----
> From: Scott Klement [mailto:klemscot@klements.com]
> Sent: Thursday, May 11, 2000 7:17 PM
> To: 'RPG400-L@midrange.com'
> Subject: Re: File/Service Program/Data Structure Problem...
> 
> 
> 
> 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
> +---
> 
+---
| 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
+---

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.