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