RE: Generically Handling Record Locks in *PSSR

Hi Dave,

Unfortunately I don't have the answer you want (I suggest possibly
running a test with a record lock and see what the error status is and
monitor for it in code).

I know you don't want to recode everything, but in the event that you
do...
What I suggest, based on your comment of using the (e) extender, is to
instead code so that system record locks (hopefully) never happen. If 2
people shouldn't be maintaining doing something at the same time, I
suggest implementing something akin to a Process In Use flag. Also,
only ever lock a record if you're going to unlock it right away, so it's
never locked for more than a second (if even that).

I offer this from past experience.

Also, I know your pain about that "This has been broken for years"
comment. "Yes, Mr & Mrs User, thank you or sharing that with me...
years after it happened."

-Kurt

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of David Wright
Sent: Monday, January 19, 2009 3:57 PM
To: rpg400-l
Subject: Generically Handling Record Locks in *PSSR

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