|
Why would I? It's a priming read. Performance is not an issue (only happens once). Readability may a reason be for most people. It's preference you're talking about here, not structure. Bradley V. Stone BVS/Tools http://www.bvstools.com -----Original Message----- From: Colin Williams [mailto:Williamsc@technocrats.co.uk] Sent: Friday, June 18, 1999 9:00 AM To: 'RPG400-L@midrange.com' Subject: RE: %EOF Why do you do a SETLL followed by a READE, why don't you do a CHAIN? -----Original Message----- From: Stone, Brad V (TC OASIS) [mailto:bvstone@taylorcorp.com] Sent: Friday, June 18, 1999 2:14 PM To: 'RPG400-L@midrange.com' Subject: RE: %EOF Key SETLL Filename Key READE Filename DOW not %EOF(Filename) (do some code here) Key READE Filename Enddo Change it to this... More structurally correct as well. Bradley V. Stone BVS/Tools http://www.bvstools.com <http://www.bvstools.com/> -----Original Message----- From: Nelson C. Smith [mailto:ncsmith@gate.net] Sent: Thursday, June 17, 1999 8:04 PM To: RPG400-L@midrange.com Subject: %EOF Has anyone here had problems associating a filename with the %EOF bif? I've been experiencing intermittent problems which seem to be occuring only in service programs. When I pull the code out to a separate program to try to isolate it, it works fine (naturally). Here's what I'm seeing: Key SETLL Filename DOU %EOF(Filename) Key READE Filename If %EOF(Filename) Leave Endif If %EOF Leave Endif (do some code here) Enddo When executing this code against an empty file, the first LEAVE does not execute, but the second one does. When I put a numeric indicator on the READE, it comes on normally. This is the entire code in a procedure in a service program (second LEAVE was added in testing) and, as I say, when pulled out into a test program it works fine. Does anyone know how the filename gets associated with the %EOF and what might disrupt that association? There is no code between the READE and the first IF. I'm on V4R3. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This is the RPG/400 Discussion Mailing List! To submit a new * * message, send your mail to "RPG400-L@midrange.com". To unsubscribe * * from this list send email to MAJORDOMO@midrange.com and specify * * 'unsubscribe RPG400-L' in the body of your message. Questions should * * be directed to the list owner / operator: david@midrange.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This is the RPG/400 Discussion Mailing List! To submit a new * * message, send your mail to "RPG400-L@midrange.com". To unsubscribe * * from this list send email to MAJORDOMO@midrange.com and specify * * 'unsubscribe RPG400-L' in the body of your message. Questions should * * be directed to the list owner / operator: david@midrange.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This is the RPG/400 Discussion Mailing List! To submit a new * * message, send your mail to "RPG400-L@midrange.com". To unsubscribe * * from this list send email to MAJORDOMO@midrange.com and specify * * 'unsubscribe RPG400-L' in the body of your message. 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.