× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Joe, Martin

I like Martin's approach...  Cleanest I know of.


But I've never really liked the SETLL/READE combo, even going back to
RPGIII.  Seen it probably a million times, in big-name packages, and it's
used by better than half the programmers I've seen.

Still don't like it.


It's not so much the extra I/O (which IS hugely ineffecient).


I have, on very rare occasions, needed to SETLL with one KLIST, but READE on
a different KLIST.  That's a rare, but extremely useful technique.

But when you use SETLL/READE, using the same exact KLIST, that equates to a
CHAIN.  Different technique entirely...  So I allus preferred CHAIN, both
for it's effeciency, and mainly because it makes the technique above STAND
OUT.  In my code, when I see SETLL followed by READE, I know immediately
this is a very rare situation...  I like things like that to stick out like
a sore thumb.


I understand WHY the compiler-developers set up two different %BIF
indicators, because that's how it's done in RPGIII.  There's the HI
indicator for CHAIN, and the EQ indicator for READE...

But IMHO, what's called for is an additional %BIF called %NRF (No Record
Found), that is set on in either case.  I don't look for that to happen,
because the compiler-developers would have to admit they didn't understand
how RPG is commonly used, in creating business apps.

I don't know of a good way to emulate this, other than using an *IN (I
commonly use *INLR), on the I/O opcode.

Haven't decided what approach I settle on, myself.

jt

| -----Original Message-----
| From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]On
| Behalf Of Martin Rowe
| Sent: Sunday, December 30, 2001 5:41 AM
| To: RPG400-L
| Subject: Re: %EOF, %FOUND and the infamous Dow loop
|
|
| On Sun, 2001-12-30 at 10:25, Joe Pluta wrote:
| > 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
| >
|
| Hi Joe
|
| We pretty much all used this method in our department, and got a bit
| confused with the right %BIF to use when moving to RPGIV. We settled on
| a one line extension to it and just used the (functional equivalent)
| SETLL/READE pair instead of the CHAIN and just use %EOF.
|
|  FileKey  SETLL          File
|  FileKey  READE    File
|           DOW      not %EOF(File)
|          (process)
|  FileKey  READE    File
|           ENDDO
|
| Regards, Martin
| --
| martin@dbg400.net  jamaro@firstlinux.net  http://www.dbg400.net
| /"\
| DBG/400 - DataBase Generation utilities - AS/400 / iSeries Open        \
| /
| Source free test environment tools and others (file/spool/misc)
| X
| [this space for hire]  ASCII Ribbon Campaign against HTML mail & news  /
| \
|
| _______________________________________________
| 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.
|



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.