Re: Handling record locks

Why not this simple scenario.

User 1 opens a record and locks it as the programme has defined it as UPDATE.
User 2 tries to open the same record, BUT cannot access it. Instead he will get 
the message (as the QSYSOPR at the same time).

Will end a lot of frustration, I think.

Your solution may cause problems, as the first user wants to modify the data, 
gets a temporarily lock, but at the update he has lost the lock due to the 
time-out. What will happen next?

Regards,
Carel Teijgeler.

*********** REPLY SEPARATOR  ***********

On 24-10-03 at 11:21 York, Albert wrote:

>As we all know, problems with record locks have been around since day 
>one.Resolving them isn't easy and someone is going to >lose out. 
>
>I have an idea that I would like to present for discussion.  
>
>Perhaps if we added another extension to the READ and CHAIN op codes. 
>Something like (T), which would be a 'temporary' lock.
>
>If another job already has a T-lock an error would be returned, unless a 
>certain period of time has elapsed since they read the record >(like when 
>someone leaves a screen up). In that case then the previous job would lose the 
>'lock' and you would get the record. 
>
>It you're unable to 'lock' the record you could then present a screen to the 
>operator giving them an option to force a timeout on the >other job (perhaps 
>this requires a supervisor override).
>
>When you try to update the record if you lost the T-lock to another job an 
>error message is returned. You then display a 'sorry' message to the operator. 
>
>If you close the file or release the record, or if your job ends,  then the 
>T-lock goes away.