|
Phil, That looks good... I think I'll go with that. (Don't much cotton to the extraneous IF, but...) Thanks. jt | -----Original Message----- | Behalf Of Phil | Sent: Sunday, December 30, 2001 10:58 AM | | Using chain to position the file & read the first record, won't this work: | | | C key chain testfile | C if %found(testfile) | C dow not %eof(testfile) | C | * -- do whatever | C | C key reade testfile | C enddo | C endif | | Phil | | | > -----Original Message----- | > Behalf Of Joe Pluta | > Sent: Sunday, December 30, 2001 5:25 AM | > | > I did some researching back a ways, and I found that there have | been a few | > discussions regarding the use of the file I/O BIFs. It seemed to always | > revolve around which of the basic CHAIN/SETLL/READE loops you | used. Now, | > ever since I was able to, I've used the following standard code: | > | > CHAIN | > *IN90 DOWEQ *OFF | > (process) | > READE | > ENDDO | > | > This, I know, is only one of many possible variations, but it's | > the one that | > has always appealed to my sense of decorum. This is definitely | not a good | > argument for its use, but it has always worked quite nicely for me. The | > only other mode I found nearly as appealing was the following: | > | > SETLL | > *OFF DOWEQ *ON | > READE | > *IN90 IFEQ *ON | > LEAVE | > ENDIF | > (process) | > ENDDO | > | > This is basically the equivalent of the RCVF/GOTO loop I use in | > CL, with an | > unconditional loop and a LEAVE being the "structured" | equivalent. I'm not | > happy with the four extra lines of code, but hey, it's relatively | > efficient | > and has a couple of benefits, such as allowing the use of ITER. | > | > The second form can fairly readily be converted to use the file I/O BIF | > %eof, thereby removing indicator use. The first, however, | > because the CHAIN | > and READE command set different BIFs, is a little harder. Has anyone | > figured out a way to do it? I tried to use (%found or not %eof) | > along with | > the operation extenders, and it seems to always return true | (putting me in | > an infinite loop reprocessing the last record over and over). Am | > I missing | > something here (more than usual)? | > | > Joe
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.