Thomas said:
 
>This is the procedure that we are using now for adding master entries.
>We still have the
>problem of "sneaking" that (1) DBLOCK the DS in when the dataset
>is already locked with
>a mode 5/6 for a particular entry.
 
 
Yes, we had the same issues. Our fix assumed that of the
umpteen screens that access the data set(s) in question, only
2 or 3 of them have a high volume of use. On some of the others we were
able to write a general purpose lock routine that could be used by
about 5 of the screens. Therefore, the actual time to fix was
minimal:
 
(Fix A) On the screen trying to get a lock, do a DBLOCK,
erroring if already locked. You can then tell the user to wait, or
the routine could loop several times and try before failure.
 
(Fix B) On the screen that already has a lock (over a screen
read, doing think time), we did a time-out read (like 2-5 minutes).
A time-out read is usually real easy to do without many logic issues in
current code.
 
These easily fixed the problem of people going for coffee, bathroom,
talking, telepone, etc.
 
The combination of both fixes took care of contention problems
for 99.9% of the time.
 
Note: These solutions in no way negate the recommendations of
previous locking strategies if you have the luxury of implementing such.
But these are some ways one can
fix a design problem without changing MASTERs to DETAILs,
rewriting gobs of code, bla, bla, bla. In other words, spending
a lot of time to make it perfect, when something a little less than
perfect may make business sense. (i.e. user doesn't fund it)
 
 
Elbert