Re: Record loked

On 12-Sep-2015 10:41 -0600, Raul A Jager W wrote:

Sometimes a record gets locked, DSPRCDLCK shows the job that is
holding the record, but not the program that caused the lock.

It is likely that a program returned (or failed) without releasing
all records it has read for update, but I don't know which one.
DSPJOB just shows in the stack the http server ready to receive data
and the log shows only errors or info messages.

How can I find out which program left the record locked?

Logging would be the typical means. Locks are not tracked to a program; instead locks are tracked to a process, a thread, or a lock space (¿LckSpc?). However, row-locks not held under isolation should be associated with an existing open; see the Open Files (*OPNF) option for the Work With Job (WRKJOB) or Display Job (DSPJOB). I do not recall if [but think not, that] the Open Data Path (ODP) records the name of the program that opened the file [and that would involve Dump System Object (DMPSYSOBJ)]; the information about what program opens the file does appear in a Job Trace. as part of the trace DATA-records produced by\for the Common Data Management Open (QDMCOPEN) processing.

If the row was locked for more than just the reading [i.e. an actual update; or perhaps insert or delete under commitment control], then that non-read I/O would be recorded as activity in the journal, which would also include the program name. Of course that assumes the file is journaled [which if using CmtCtl, journaling is a requirement vs merely a nicety]. And if under commitment control, then the held-lock can be forcibly dropped by forcing the uncommitted changes to be Rolled Back (ROLLBACK) [with a side effect of locks being removed for locks held for isolation] even without ending of the job; an effective requirement exists to end the job [or to make the job close the file or re-obtain and release the row-lock], to effect removal of row-locks obtained\held without the use of isolation.