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