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.