Re: Generically Handling Record Locks in *PSSR

[Booth Martin <booth@xxxxxxxxxxxx>]

Ah, the "Last one in wins" solution.   That is building in your next set 
of "Its been like that for years" comments.  :)   Are you really sure 
you want to do that?

Most of the record lock problems I have ever seen involve chaining to an 
update file without the (n) extender when records are being retrieved 
for screen displays.

The solution is fairly simple and may not affect as many members as you 
suspect because its probably only happening with programs that have 
display files, and probably only high usage programs at that..



David Wright wrote:
> 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
>   
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.176 / Virus Database: 270.10.8/1897 - Release Date: 1/16/2009 6:52 AM
>
>