Re: Leaving records locked. was(Re: Message line: Another approach?)

Hello Patrik

Having to slap the user is imo very poor system design.
Having a simple recovery for a rare event is imo good system design.

It is not the waiting job that crashes, it is other jobs that attempt to access the locked record.
Having jobs crash when attempting to access a locked record was helped somewhat by IBM implementing a R reply to the error message.
Having to intervene and cancel jobs manually is imo unnecessary and even silly.

I believe it is better to write code that offers self recovery than to intervene and reeducate and monitor people.

Users never complained that their work was lost.  Even in the case where a message did pop up it was often the result of a procedure not being followed.
eg. 2 Users attempting to update the production data on the same work order.
eg.  User for a different department updating master file data they were not responsible for.

This is my last word on this matter.

Regards
Frank


On 02/02/2020 11:21 pm, Patrik Schindler wrote:

. A user opens a record for update then goes to lunch. In the meantime another job crashes because it needs the record.
. Multiple jobs attempt to open records for update, and each are waiting for the other to complete,

Yes. The first is a good reason to slap the selfish user, the latter the outcome of the first one.

But why should a waiting job crash? If you think about a telnet session being town down for apparent network outage: Sensible configuration to end the job soon or immediately instead of waiting for the user to come back and sign in again is a sensible solution to this scenario.