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

Martin,

Thanks, as always...!  See inline.

jt

| -----Original Message-----
| Behalf Of Martin Rowe
| Sent: Sunday, December 30, 2001 3:26 PM
|
| 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 ;-)

Ain't that the way...!?!

|
| >
| > 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 ?

Check the I/O counts.  (Apply the PTF first, so you don't have to press
F11...;-)  Last time I did, it registered 2 vs 1.  that coulda changed,
however.

|
| > 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,

Whoa...!  Come again...?!?  I've never hearda this...? ?


| 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 would assume something else was goin' on...  But I dunno...

|
| > 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 :)

Most of mine only use *INLR...  So never saw a big problem...


| The downside is not being able to view/change the %BIF
| value directly when in debug.

Yep.  No small matter, to me anyway.  I haven't used the built-ins enough,
but that may make me reconsider using them as my standard technique.
(Almost all of my coding is for my clients, where I do as they do..  So the
issue hasn't come up much...)


| 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.

Exactly.  That's why I'm thinking about keeping the indicators.


| %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
| :(

Oooops...  Don't have time to start another long thread on flat program
structure with many subs vs. top-down flow structure.

But here's the thing:  If you set an indicator, and ALWAYS TEST IT ON THE
NEXT LINE (which I do), you don't get many mistakes, no matter what.  If an
indicator gets set, and I need to check it someplace other than the very
next line, I set a variable.  That's just me.. but I almost never have
loops, etc...

|
| 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...

Not here...  That's the same problems as the previous example.  I wouldn't
set a variable, when I can test an indicator/%BIF on the next line.. and
then forget about it completely.  Just saw Phil's post...  I would NOT do it
the way RPGWIZ does...  (Unless it was ALWAYS AUTOMATICALLY done through a
code-generator.)


|
| Regards, Martin
| --


Likewise Regards...!

jt