×
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.
On 7/17/2023 12:35 PM, James H. H. Lampert via MIDRANGE-L wrote:
I had a program (ILE RPG) running in batch, over the weekend, on a
customer box.
Very early Saturday morning, it apparently ran into a lock conflict of
some sort, on a file whose F-spec opens it as "UF A E K DISK,"
not USROPN, never closing it, with the program continuously active.
Anybody have any idea what could have ripped a lock away from a running
program?
Without specifics, one is reduced to guessing, and yet...
Consider the situation where the program in question is continuously
running. Reading, adding, and updating records. This sort of access does
not require an exclusive lock on the file - *SHRUPD will do. Now, along
comes say a weekly backup, which wants a *EXCL lock on that file. That
would result in the backup throwing a 'Cannot allocate object' error.
Another possibility is that a weekly batch process started running that
needs to update each record to say, tag it as processed for that week.
Since that second program is going to read each record for update, it
will require a lock on that record. At some point, luck might run out,
and the two processes will want the same record.
The actual job log messages would help considerably.
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
