Re: LCKW Problem

Hi, Kevin:

I can say that WRKOBJLCK will not show what your job is waiting for.

WRKJOB OPTION(*JOBLCK), according to the documentation, will provide all
job locks, including those for which it is waiting.

This is hindsight, but what I will usually do, is to look at the invocation
stack, where I can find the application that's waiting - and also its
instruction number.  Then a quick compile of its source (GENOPT(*NOGEN) or
whatever) will reveal the line of code involved.  Of course, if it's a
vendor program for which you have no source, the next step is to call the
vendor instead.

But as far as getting a list of locks that are pending, I'm not aware of
any publicly-available tool for that.

You indicated that these other jobs took off after the (ouch!) ENDJOBABN
had done its task.  That implies that those jobs were waiting for the
problem job to move along.  Is that the case, or did I read more into it
than was there?

Dennis





"Brunk, Kevin" <Kevin.Brunk@wabutler.com>@midrange.com on 10/24/2002
12:12:49 PM

Please respond to midrange-l@midrange.com

Sent by:    midrange-l-admin@midrange.com


To:    <midrange-l@midrange.com>
cc:
Subject:    LCKW Problem


This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
We experienced a problem today that I've not encountered before.  A job was
running and entered a LCKW state (as shown on WRKACTJOB) and stayed in that
state for a long time.  So long, in fact, that I ended up ENDJOB *IMMED and
then eventually needed to use ENDJOBABN.

What confounds me is that I was unable to determine what resource the job
was waiting on.  When I displayed job record locks, there were none.  I
tried using the WRKOBJLCK from the job's list of locks and besides being
tedious, I was still unable to identify a resource for which the job was
waiting.  I also used WRKACTJOB and scanned the job lists to see if any
other jobs were in an unusual state that might have been causing the
conflict (especially the QDBSRVxx jobs) - and found none.  Finally, I used
DSPLOG to see if the system was reporting any messages like damaged objects
or such - again, nothing reported (I also check DSPMSG QSYSOPR).
Interestingly, there were no other user-submitted "batch" jobs running at
the time - so I couldn't blame it on a query building an index!

As soon as the job was ended, other queued jobs which ran the same programs
and accessed the same files began running and continued without incident.

Does anyone have an idea of what may have been behind this?  Is there
another command or way to see what resources a job is waiting for?


`