John,
     Try this:

1. Find the pin number of the process. SOS or the SHOWPROC command
(use the ":JOB=" format) will give it to you.

2. Go into DEBUG

3. "PIN" to the process. At the nmdebug prompt enter "pin #xyz", where
you substitute the pin number for "xyz" and be sure you enter the "#"
to tell debug that the pin number is supplied in decimal.

4. Trace the stack to be sure you have the correct process.

5. Extract the variable passed to proc_pause, which is the pause
value expressed in milliseconds. To do this, enter:

nmdebug > lev 6;dv sp-#484,1,#

This should give you the pause time in decimal, in milliseconds.

If things are working as you have stated, then somebody is holding the
lock way too long and you should use DBUTIL to find out who it is and
then try to determine what that process is doing. Good luck.

--
                 --Pete Crosby  ([log in to unmask])


>
>The program in question implements a sort of application-level record
>locking in which a flag field in the database indicates a lock condition.
>When this program finds a lock on a record it wants, it's supposed to pause
>2 minutes then try again, failing after six tries.  However, for some reason
>this particular instance has paused for *way* more than two minutes, even
>after I have forcibly cleared the database lock.  I have a call out to the
>application vendor to see if they can shed any light, but it seems very
>strange that a 2-minute pause would just wait indefinitely.  Does the stack
>trace (or any other tool) give us a clue as to what delay value was passed
>to the PAUSE intrinsic (i.e. is there a bug in the calling program which
>caused it to invoke pause for, say, 2000 minutes instead?)