Brian, If this is happening often, would you consider a job running as the creator? The application could send a message (via message files or something else) to the job. When the job receives the message, indicating that there is a problem, it could execute DBUTIL. One of the major problems I see with this, is that the time sequence could be too long to show the problem. However, if you signaled the job after the fifth retry instead of after the tenth retry, you would either complete in the next 50 seconds, or the job should be able to catch this. I think the only other way is if the application had PM, then you could get this information regardless of whether you are the creator. LB On Friday, May 02, 1997 7:40 AM, Brian White wrote: > 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." >