RE: CHAIN or READ without lock

Jim, take a look at Carr & Harvey's solution.  It really is boiler plate,
just as John says.  The idea is to read the record(unlocked) and move the
record's information to a "before" datastructure.  Then, when your user
pushes The "go do it" button, read the record again(locked this time) and
move the record's information to an "after" datastructure. Then, if the
"before" datastructure does not equal the "after" datastructure you know
someone else changed the record so then you can tell the user and go to Plan
B.  Otherwise, update the record and continue.  The feature of this solution
is that the record is never locked while waiting for a keystroke.

-----Original Message-----
From: Jim Langston [mailto:jlangston@conexfreight.com]
Sent: Friday, February 11, 2000 11:11 AM
To: boothm@goddard.edu
Subject: Re: CHAIN or READ without lock


Take the same scenario.  The operator keys in some changes, then goes
and answers the phone without pressing enter.  Meanwhile, another
operator makes some changes on the record, presses enter and updates
the record.  Now the first operator comes back and presses enter, and
updates the record.  The second operator's changes just got stepped on,
and no one is the wiser.  That is the whole reason to read a record while
locking it, you are intending to change the record, and don't want anyone
else able to read it for changes while you have it open.

That is the key, though, read it for changes.  If the operator has the
record
locked and is changing it, a report program can still read the record as it
exists without any difficulties, as long as it is reading it for input only,
no
changes.  Which is how you want it.

Neither is perfect though, I will grant you that.  But, in theory, your
batch
program running should stop and wait for the record to be unlocked before
it continues.  You need to make sure you are waiting long enough for records
to become unlocked before you bomb out.

The only big problem is a dead lock situation.  That is, operator A reads
a record from file 1 for update.  Operator B reads a record from file 2 for
update.  Now, Operator A tries to read the same record from file 2 for
update.  Then, operator B tries to read the same records from file 1 for
update.  It is a deadlock situation.  Operator A's process will never finish
until it reads from file 2, which is locked by operator B.  But operator
B's process won't finish until it reads from file 1, which is locked by
operator A.

Luckily, deadlocks are far and few between, but they do happen.

Regards,

Jim Langston

Carl Pitcher wrote:

> I respectfully submit that if you're writing code for file updates &
locking
> the records (especially in subfiles or file maintenance applications),
> you're building in alligators.  Consider a customer file maintenance
program
> for example:  the operator keys in the customer number and displays the
> information for change, the phone rings and the record remains locked for
> the duration of the phone call (unless it's time to go to lunch) -
> meanwhile, the alligator waits to bite you in the ass because the batch
job
> posting invoices is just sitting in the q waiting to update the customer
> balance in the locked record, which causes a program check, which gets
> cancelled by the system operator, which screws up your data.  Design your
> code so that you get the information without locking the record and only
> lock the record when you are ready to update it.

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---