Re: Generically Handling Record Locks in *PSSR

David,

Not what I really would suggest but a software house I worked for
briefly changed all there files to WAITRCD(*NOMAX) or some such (not at
a system right now) so that record locks would wait for ever. They also
changed SBMJOB so that it didn't send completion messages. Did I mention
they had upgraded from S36 and thought that since it did this the /400
would be better doing this also?

What I do for interactive programs is the (E) extender and then get the
message text from the program SDS to tell the user who has the record
locked. Put the blame where it belongs. Nine times out of ten it is the
user's other session they forgot about. The rest it is another user that
went to lunch or a meeting. I know others say that is the perfect reason
not to lock records between retrieval and actual update but almost every
time user A walks over to user B's session and gets them out of the
lock, user B b*tches all h*ll that they lost a lot of work time because
their update was canceled. The b*tching would be a lot more frequent and
aimed at me instead if I used lockless updating and the resulting
feedback that "someone else changed the record(s) and they would have to
redo their work".

Please, no re-igniting the flame wars over locking strategies. It's been
throughly hashed over.

Roger Vicker, CCP

On 1/19/2009 3:56 PM, David Wright arranged the binary bits such that:

Hi All,

We have been enhancing our error handling routines to make sure that
every error gets reported to IT, and not just to the CEO :) Kinda
tired of hearing that "it has not worked in years" during management
meetings...

Anyhow, we are trapping errors and sending dumps and job logs directly
to our support queue, etc. In the past an error would prompt the user
to 'Contact IT' - a prompt that was largely ignored. This new process
has allowed us to clean up our daily operations a lot.

One area I see that we could still improve on is Record locks. Every
now and then we see two users attempting to lock the same record,
which causes one of the programs to dump. Obviously we could recode
every chain/read to handle lock errors using monitor or (E), but we
want something more universal that will not require touching so many
members. The original authors did not believe in error handling at
all :(

Is there a way to capture this type of error in *PSSR, display an
error panel, and allow processing to continue once the lock is
resolved? Basically looking for a way to tell the PSSR that it is ok
to resume the program and retry the operation on this specific type of
error.

Is that possible?

Thanks,
Dave