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."
>