× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.