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

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