|
Years ago. Don't want to get into a big deal with this. IBM sent a representative to Common to talk about performance issues. He indicated in the first release of the System 38, IBM did a read of the buffer for READE but ran into problems so they changed the behavior of READE to flush the buffers each time a READE was done, like a CHAIN. IBM called this a Logical I/O and claimed nothing took up more resources on an AS/400 than issuing a Logical I/O. In contrast, they indicated that a READ was implemented by RPG and read from the buffer looking for the next record. A process they indicated was a lot more efficient. I am just passing along what I was told. It is possible that IBM has changed the behavior of READE but I doubt it. Maybe somebody from IBM will speak to the issue. I like the code because it is simple and easy. The SETLL sets the position and there is only one read. I use the DoU because I always go into the loop no matter what the result of the SETLL. SETLL just sets the position. -----Original Message----- From: Paul Morgan [mailto:pmorgan@xxxxxxxxxxxxxx] Sent: Tuesday, March 29, 2005 3:03 PM To: rpg400-l@xxxxxxxxxxxx Subject: Re: Chain doesn't set %EOF Alan, Had a prior thread on DoW vs DoU read loops. Who the heck was the IBMer who said never to use ReadE? How long ago was the Common conference? Possible old performance problems with ReadE? I doubt Barbara would agree with this recommendation to never use ReadE. Paul -- Paul Morgan Senior Programmer Analyst - Retail J. Jill Group 100 Birch Pond Drive, PO Box 2009 Tilton, NH 03276-2009 Phone: (603) 266-2117 Fax: (603) 266-2333 "Alan Campin" wrote > My recommendation. > > SetLL(SomeKey) File; > DoU 0 = 1; > Read (File); > If %Eof(File) or > SomeKey <> KeyField; > Leave; > EndIf; > // Do something > EndDo; > > Was told by IBM to never use a READE, always use a READ. From a Common conference years ago.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.