Re: subfile issue

Simon, you are unusually bright, have years of experience on the platform, and have a point of view few of us will ever achieve. Dare I say that things that are easy for you are not that easy for some of us? This is not any sort of an attack, but rather an admission that some of this easy stuff is really pretty hard for me.

Simon Coulter wrote:

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



------------------------------------------------------------------------


No virus found in this incoming message.
Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.12.0/2066 - Release Date: 04/18/09 09:55:00