Brian,

     If you have Glancexl, you could look at which files are open by a
     particular pin # or job #. This has helped me to track down potential
     db problems. Once you select the pin # to track (in Glancexl) use the
     'next keys' to get to the 'display files' key. I also use dbutil and
     a program called undedlok, you might find another way to list 'file
     accessors' by using MPEX (if you have it on your system.)

     Michele Conant
     Cardinal Health
     [log in to unmask]

     He who has knowledge without learning, has wings but no feet.



______________________________ Reply Separator _________________________________
Subject: Deteermining who is holding locks
Author:  Brian White <[log in to unmask]> at internet
Date:    5/2/97 8:40 AM


Distribution: Global

We are having trouble establishing locks in a particular application.
While no deadlocks are occurring, we are getting failures in some of
transactions. We can't seem to locate the offending process. All of the
processes are locking at the dataset level. We use conditional locks
with 15 retries 5 seconds apart. We don't think we have reached a
situation that would have been a deadlock, just a process that is
locking for a longer period of time than we had anticipated.

We can easily trap the dblock Image intrinsic, and detect the 10th (or
more) successive retry; however, once that has been detected, we would
like to be able to determine who has what set locked, so that we can
figure out what is going on. DBUTIL won't work, because the users are
not logged on as the creator user. MPEX for MPE/iX version 5.0 doesn't
show us who has the datasets locked. I can't find in our TurboImage
manual (1987 version - don't ask why  :-{( ) any DBINFO modes that would
provide this information.

Do any of you gurus out there know how we can get this information from
a non-creator logon?

Thanks in advance.
--

Brian J. White
[log in to unmask]

"Make it idiot-proof and someone will make a better idiot."