On 19/04/2009, at 12:27 AM, Joep Beckeringh wrote:
I see only two comments advising not to use READC. Jack said 'I have
been bit many times by missed readc's for various reasons' but did not
specify whether READC or he was to blame; Booth just said 'Get rid
of a
lot of headaches. Forget the read'. So you're slightly
exaggerating :-)
Ahh but that makes for better story--however I was mentally including
the various appends you'll find in the archives with similar
sentiments. Seems to be a common complaint (and not only about READC)
where supposedly something in the system is broken but really the
problem is one of:
1. comprehension
or
2. inappropriate use
There are very few parts of the system that are truly broken, there
are some that are badly designed, and there are very many that are
simply not understood.
The problem with READC is that the name is wrong: it should have been
READT - read touched.
That's just quibbling over semantics.
Because if the user enters something but then
decides to blank the field or just rekeys the original value, the
record
will be read by READC, even if nothing actually changed.
So you consider 'blanking' the field (i.e., replacing the existing
data with blanks) as not changing the record? Interesting.
The record HAS been modified. It doesn't matter that the user typed
the same value. As far as the system is concerned the record has been
changed therefore it will be read by READC. This operates in the same
way as the CHANGE keyword. User does "something" to a field and the
MDT is set on and therefore the CHANGE indicator is on. The user might
have cleared the field or typed the same data but either way it's been
modified. That's consistent behaviour.
It's not the system's job to decide whether a record "really" changed.
That's an application issue and has to be dealt with whether you use a
READC loop or a READ loop.
I'd rather have READC give me a few unwanted records (and possibly
perform a few unnecessary DB updates) than the guaranteed unnecessary
I/O imposed by a READ loop.
Mostly I am not
interested whether a user touched a record after I last displayed it,
but whether the contents of the record have changed since I filled it.
You need to do that with your proposed READ loop too. At least READC
will only give you records the user 'did something' with instead of
all records--most of which you likely don't care about.
If I use READC, I still have to compare the actual to the original
values
Only if you want to avoid updating a DB record with the same values.
Can't see it makes much difference if a DB record gets updated with
the same values it had previously except in the case where the record
contains fields for the user who made the update and the time-stamp of
the last update. In that case you may not want to update the DB record
if is hasn't "really" changed. But, again, you still have to handle
this situation with your READ loop alternative.
and if for some reason I do not want to process the touched
records immediately, I have to mess with SFLNXTCHG to 'remember' that
the record was touched.
Hardly "messing". Turn on an indicator for SFLNXTCHG and update the
record you just read. How hard is that? At most it's three lines of
code. OK, it's a bit harder than not doing anything at all but it's
still trivial code.
That makes READC problematic, even it works flawlessly as documented.
Not at all. It just means you don't like the way it works. You'd
rather perform unnecessary I/O to the subfile than use a system
facility to reduce that overhead.
I agree strongly with Booth; a FOR-loop is much easier to understand.
Only if you don't understand READC. The READ loop requires you to
reset the RRN, it causes unnecessary I/O by reading records that
haven't changed, and it still requires you to compare old values with
new values to see if something did change.
The expected 'design pattern' for processing a subfile is a READC
loop. When I see code that does not implement the expected pattern I'd
think two things; first, the coder must have had a reason for doing so
and I would waste time examining the code to see what I'd missed and
then when I could not find evidence to support any rational reason for
a avoiding READC in the code I'd think the coder was a numpty who
simply didn't know about READC or how it works and that would make me
suspicious of the rest of the code in that program and indeed of
anything written by that coder.
Seems to me there is no advantage to a READ loop (except you don't
need to learn about READC) because you still have to do processing to
determine if a record was changed vs. 'knowing' it was changed.
Further, a READ loop is guaranteed to be less efficient because you
are processing all records in the subfile vs. only those the user
modified. Of course, now that systems are faster we don't need to
worry about performance do we. It'll be "fast enough".
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
