× 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: Scott Mildenberger <Smildenber@xxxxxxxxxxxx>
  • Date: Fri, 12 May 2000 07:25:55 -0600

Brad,

        How is the DS defined in SRVPGM1?  Is it defined within the
subprocedure?  If so, it is a local definition and 'hiding' the global
definition of the field names which is where the fields from the file are
defined.  You can move the DS definition outside the subprocedure so it is
defined globally to the service program then the fields are the same as
those from the file.  When you define a externally defined DS inside a
subprocedure the fields defined because of it are not the same as those
defined from the file (they have the same names but are not the same field).
Hope this description isn't confusing, I have run into this before and the
first time had me puzzled for awhile.

Scott Mildenberger

> -----Original Message-----
> From: Stone, Brad V (TC) [SMTP:bvstone@taylorcorp.com]
> Sent: Thursday, May 11, 2000 3:55 PM
> To:   'RPG400-L@midrange.com'
> Subject:      File/Service Program/Data Structure Problem...
> 
> 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
+---

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.