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



So given the WRKOBJLCK OBJ(the_lib/FILEA) OBJTYPE(*FILE) MBR(*ALL) and DSPRCDLCK FILE(the_lib/FILEA) MBR(*FIRST) RCDNBR(*ALL) [hopefully just one member] taken when the problem is active, plus the other information noted in the earlier reply, and ideally also the debug joblog of the job running PGM01 [to see what the query debug messages reveal], then what is the issue might be more clear [even if, still unexpected and origin unknown]. There may be value in the PGM02 using USROPN so as to have the problem manifest in an explicit OPEN vs having the file opened in the implicit-open path of the RPG run-time, but not necessary [I just seem to recall the stack is clearer, to me]

Regards, Chuck

On 23 Jul 2013 09:54, Alan Shore wrote:
My "attempting to update FILEA" means that the file is defined as
update on the f-spec. The program doesn't time-out (production work,
with time constraints), we have to end the program with the SQL so
that the second program that updates the file can proceed.

CRPence on Tuesday, July 23, 2013 12:44 PM wrote:

On 23 Jul 2013 04:50, Alan Shore wrote:
Before I forget, we are on V5r4
I have an RPG program (PGM01) with embedded SQL The ONLY SQL in
this program are:
exec sql Set Option Commit = *None;
exec SQL Select count(*) Into :Reccount from FILEA;
and there are NO F-specs for this
file (or one of its logical files) within PGM01

When another program (PGM02) is running, it is attempting to
update FILEA, but FILEA is locked by PGM01. The only way that I
can get PGM02 to continue is by ending PGM01 <<SNIP>>

Define explicitly what "attempting to update FILEA" means, and
what is the error(s) [from the spooled joblog] when processing of
the PGM02 is allowed to timeout, and if the timeout takes
sufficiently long to allow DSPJOB OUTPUT(*PRINT) on the job running
the PGM02 then obtain that to reveal minimally its awaited lock and
program stack.
>


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.