×
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 23 Jul 2013 10:37, Alan Shore wrote:
It's a file lock and the program is ended with option 4 (*immed) from
WRKACTJOB
A lock on the *FILE object for a SELECT or any DML should only ever
be *SHRRD; same for the MBR I believe. It is the DATA lock that would
normally manifest a wait due to the WAITFILE setting for the database
file member opened for update according to the RPG F-Spec, if indeed the
origin of the alluded conflicting lock should only be from the noted
aggregate query SELECT. That is because the OPEN per the RPG F-Spec
[for update] will also only ever have a *SHRRD lock on the file and
member; neither the file nor the member lock of *SHRRD will preclude the
other job from obtaining their own *SHRRD lock.
The WRKOBJLCK I had noted previously would reveal the actual locking
[of the locks presented by that interface], and the DSPJOB of the job in
apparent conflict would help reveal possible conflicts in locking or
possibly something else entirely [e.g. from its overall job status and
program stack; esp. if not in status LCKW, for which the Job Locks
information should show what requested locks are awaited].
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
