×
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.
My experience is that usually it is one or two programs where this is an
issue and fixing those programs makes the problem go away.
First, why is a record locked for more than a fraction of a second,
ever? Almost always it is a maintenance program where a record is read
in as locked, and then displayed on a user's screen waiting for
user-action. Stop doing that and record locks disappear,
* read the record (unlocked).
* display the record, along with a hidden data structure of the
original values.
* when ENTER pressed, check new values to original values.
* If changes were made, get the record again (locked).
* Compare new values to original values (maybe changed by another user?)
* if OK, do the update. Record lock is sub-second.
On 9/6/2018 12:33 PM, Justin Taylor wrote:
When I convinced the boss that an OS retry option wasn't practical, I implemented something like you suggest. We already have an old program (that I prob found somewhere) that you pass it a PF name and an RRN, and it will send the current job a break msg saying who has that row locked. All I had to do was monitor for the lock, do a no-lock I/O to get the RRN and then call this pgm.
Thanks everyone!
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.
midrange.com
