Re: SQL select seems to be creating a lock on a file

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.

>