Re: Generically Handling Record Locks in *PSSR

Forgot to add that for batch jobs I still use the (E) extender and SDS
and then either loop back on the CHAIN #times (interactive waits
WAITRCD, batch waits # * WAITRCD) or go ahead with a get QSYSOPR or
ABEND processes.

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