|
There was a problem in V4R3 at one time, but a PTF fixed it. Works fine now. There are previous posts here about it (around 6 months ago). ----- Original Message ----- From: "Stone, Brad V (TC)" <bvstone@taylorcorp.com> To: <RPG400-L@midrange.com> Sent: Wednesday, March 01, 2000 9:04 AM Subject: RE: using files within subprocedures > Just an FYI. I used this method and also tried using the flag for the INFDS > and it wasn't always correct. I don't remember the exact circumstances, but > the file was closed and the system thought it was open. > > So, test test test. > > Brad > > > > -----Original Message----- > > From: pcunnane@learningco.com [mailto:pcunnane@learningco.com] > > Sent: Wednesday, March 01, 2000 9:01 AM > > To: RPG400-L@midrange.com > > Subject: Re: using files within subprocedures > > > > > > James, > > > > Code the file with USROPN. In the procedure: > > > > if not %open(CUSTMAST) > > open CUSTMAST > > endif > > > > You will want a cleanup routine to explicitly close the > > file, or allow > > it to be closed when the activation group ends. > > > > -- > > Paul > > > > > > ______________________________ Reply Separator > > _________________________________ > > Subject: using files within subprocedures > > Author: James David Rich <james@dansfoods.com> at InterNet > > Date: 2000-02-29 6:53 pm > > > > > > I'm trying to figure out a problem which doesn't appear to be > > explained in > > any doco that I have read. I want to have a subprocedure > > that given a > > customer number returns the customer name, like this: > > > > eval name=get_name(number) > > > > The customer name is stored in a database file (duh). This > > subprocedure > > could be called many times within a program. I don't want to > > have the > > customer file opened and closed over and over for every invocation of > > get_name(). How can I code get_name() so that the customer > > file stays > > open throughout the life of the calling program? > > > > > > James Rich > > james@dansfoods.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 > > +--- > > +--- > > | 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 > +--- > +--- | 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.