RE: Reading Files -- RPG400-L

Sounds like it's working the way file I/O works.  While local (non static)
variables in the procedure get initialized with each call, the state of the
file cursor will persist from call to call unless you do something like
close the file or explicitly reposition the file cursor.  You might want to
look at the way you're accumulating the totals and see if you can reduce the
amount of I/O.  A single SETLL should have a trivial effect on performance
in an interactive program.



> -----Original Message-----
> From: Justin Houchin [mailto:jhouchin9@charter.net]
> Sent: Friday, April 12, 2002 8:50 AM
> To: rpg400-l@midrange.com
> Subject: Re: Reading Files
>
>
> Let me restate my questions with a little more detail. I have
> one program
> that will display a list of inventory items and there quantities. To
> calculate the inventory quantities I have created a procedure
> that I call to
> calculate the quantities and then return a value. The problem
> is that when
> the procedure reads through all of the individual items calculating
> quantities it will reach the EOF and return the vaule back to the main
> program. OK, the value comes back correctly for the first
> item. But now it
> starts the do loop back again calling the procedure again to calculate
> another quantity for a different item, the procedure thinks that the
> inventory physical file is still at the EOF position,
> therefore not reading
> it and not returning a value. I corrected the problem by
> inserting SETLL
> before the read in the procedure. Now the program works but
> it is Slow and I
> think it is because of the SETLL. Is there a way that I can
> release the EOF.
>
> Justin Houchin
> Programmer
> Reliatek, Inc
> ----- Original Message -----
> From: <Mike.Collins@syan.co.uk>
> To: <rpg400-l@midrange.com>
> Sent: Friday, April 12, 2002 10:29 AM
> Subject: Re: Reading Files
>
>
> >
> > That depends on whether you share the open data path when
> you open the
> file
> > (the SHARE on either the CRTPF/LF or OVRDBF commands). If a
> file is opened
> > with SHARE(*YES) then if program A has read say the first
> record in the
> > file, if you then call program B and read the same file it
> will read the
> > SECOND record. Specifying SHARE(*YES) can be more
> efficient, but you need
> > to design your system so as to allow for the previous
> scenario. If ni your
> > case the file is opened SHARE(*NO) then when you issue your
> first read,
> yes
> > it will read the first record in the file, in terms of
> either the key or
> > the RRN, depending on how the file is defined in the RPG.
> >
> > _______________________________________________
> > This is the RPG programming on the AS400 / iSeries
> (RPG400-L) mailing list
> > To post a message email: RPG400-L@midrange.com
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> > or email: RPG400-L-request@midrange.com
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/rpg400-l.
> >
> >
>
>
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L)
> mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>
NOTICE:
All e-mail sent to or from this e-mail address will be received or otherwise
recorded by The Sharper Image corporate e-mail system and is subject to
archival, monitoring, review by and/or disclosure to Sharper Image security
and other management.  This message is intended only for the use of the
addressee and may contain information that is privileged and confidential.
If you are not the intended recipient, dissemination of this communication
is prohibited.