----------
From:   Ken Hirsch[SMTP:[log in to unmask]]
Sent:   Tuesday, April 30, 1996 7:00 PM
To:     Multiple recipients of list HP3000-L
Subject:        Re: Image Locking
 
> Surely there must be a solution other than not having entries locked =
during
> "think" time?
 
If you mean that you hold locks across terminal reads, there are =
alternatives
to this.  Lock contention is rarely a problem for short transactions.
 
You can use a field in the record to mark it for a "soft lock."  This is =
like
a "read with intent to write" lock, but you have to do it yourself.  You
have to make sure that you unlock the record whether you modify it or =
not.
The difficult case is when your program aborts!  There are ways to deal =
with
this.
 
Still think that the following is simpler and will solve the problem:
 
1.  Read the record to be updated (no locks).Save original contents.
2.  Input update information.
3.  Lock record. (by entry or even dataset if you have others locking =
entire dataset anyway for PUTs and DELETEs.
 4.  Re-read record.  Compare to saved original.
 5.  If the same (no changes mad by someone else), UPDATE.
 6.  If changed, UNLOCK and go back to step 2. with message like "Record =
changed during previous input, please re-enter data.
 7.  If the situation in 6.  happens often, you could add a routine to =
check which field were changed and if they were not related to the =
current up-date, update the new record.
 
The above unequivally avoids locks during think time and amkes the =
situation no worse than it already is ithe the system goes down.
 
NMD  [log in to unmask]