Gary writes:
...
> DBUTIL shows a session is locking a dataset in preparation to perform a
> write.  Dozens of other users are waiting for the lock to free.
...
 
(John Spivey does a good summary of the usual culprits)
 
 
One way you can determine precisely what the process is doing is to get
a stack trace of it...although many products (SHOT, Glance, SOS) have
a "stack trace" capability, most will leave you without detailed information
about the procedures in the user's program (although they will generally
show you the names of the procedures in XL.PUB.SYS and NL.PUB.SYS).
 
Here's how to get a stack trace with complete procedure names (generally):
 
   1) determine the PIN (Process Identification Number) of the process
      in question.  Let's say it is #123  (decimal 123)
 
   2) logon as MANAGER.SYS
 
   3) :run theprogram; debug
 
      I.e., run the *EXACT* program file, complete with any "XL=" (if
      appropriate) and the ";DEBUG" option.  This will put you into Debug.
 
   4) Enter the following Debug command:
 
         pin #123; tr,i,d
 
      Note: you may have to do the above several times to get a "good"
      stack trace.  Note also that the "#" means "decimal".  The "tr"
      is on the same line as the "pin" in order to minimize the time
      elapsing between the "pin" command (wherein Debug takes a snapshot
      of the process' registers) and the "tr" command.
 
   5) Enter the following Debug command:
 
      abort
 
      This will abort your local run of the program...since you probably
      didn't really want it to start executing.
 
The key trick: by running a copy of the *same* program file, you've
enabled Debug to understand the code addresses inside the program file when
it does a stack trace.
 
Hope it sheds some light on what is happening!
 
--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html