×
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.
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 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.