RE: %EOF, %FOUND and the infamous Dow loop

On Sun, 2001-12-30 at 14:39, jt wrote:
> 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.

jt, Joe

For years when I've had to tidy code up, I've converted a SETLL/READE to
a CHAIN, and now I'm having to do the reverse ;-)

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

Odd. I thought that behind the scenes, these two approaches were near
identical - could we have a ruling from Hans/Barbara ?

> 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've once come across a situation where a CHAIN was *not* the same as a
SETLL/READE with the same key. One job was locking out another on a
non-existant record! Let me try to explain that - the first job was
doing a chain (for update) with a key that didn't exist in the file. The
other job had the next nearest keyed record already locked for update,
and the first job failed because it couldn't access the record in order
to reject it. I swapped that for a SETLL with the EQ indicator, then a
READE if found, and the problem went away. I assume from that, that
SETLL does no locking at all, but the SETLL equivalent function within a
CHAIN does, if the file is opened that way.

> 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

I like the new %BIFs if for no other reason than to get rid of
indicators :) The downside is not being able to view/change the %BIF
value directly when in debug. I know I can set my own flag, but that
seems to be a backward step, as I'd want to code the loop on that value.
D EndOfFile     S     N


FileKey    SETLL   File
FileKey    READE   File
           EVAL    EndOfFile = %EOF(File)
           DOW     NOT EndOfFile
          (...)
FileKey    READE   File
           EVAL    EndOfFile = %EOF(File)
           ENDDO

This has a similar disadvantage to the old indicator method - the
likelyhood of using the wrong indicator on, or forgetting to set the
EndOfFile flagon after, the loop-end READE. %BIFs in contrast seem clean
and reduce the chance of mistakes. Particularly so in some of the
monolithic pgms that have several hundred lines between the two READEs
:(

You could use this to imitate the %NRF (or a %RF, as I prefer to test a
positive) though:

FileKey    CHAIN   File
           EVAL    RcdFound = %FOUND(File)
           DOW     RcdFound
          (...)
FileKey    READE   File
           EVAL    RcdFound = %EOF(File) = *OFF
           ENDDO

Hmmm, somehow I don't think there'd be many takers for that one...

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  /
\