Re: WRKOBJLCK: Any way to DSPJOB each of the locking jobs automatically?

On 1/26/11 6:53 AM, Peter_Vidal@xxxxxxxx wrote:

Good morning / afternoon:

I have a job "A" that gets locked intermittently due to some 10-15
other jobs. I am printing the WRKOBJLCK report to see the jobs but
when I have access to the report is already too late to get the job
that is really affecting my "A" job.

I know that I can write a pgm to read the WRKOBJLCK report, parse
its content and do a DSPJOB on each of them, but I do not have much
time and I was wondering if there is any idea or ideas that you can
share to do this quickly or maybe a one shot type of thing. I need
to know, from these job, how they are allocating the object I am
having conflict with so I can understand the purpose of that
affecting job.

Any feedback is greatly appreciated.

A DSPJOB will not necessarily divulge the why nor how the object was locked. While the joblog also may provide little assist, having that additionally is nice, especially with CL logging active in case ALCOBJ was used. The object type and lock level for the lock being held can be even more important; e.g. a *SHRRD on a *FILE, a *MEM, and Data is typically the effect of an "open" for which journal logging and usage auditing can track, while locks to that and many other types may be available most typically by ALCOBJ which can also be logged for usage. Since locks are transient even a programmed data collection may already be "too late" , logging is often a better tool for review.

However I find the best means to find what a job might be doing to have acquired a lock, is first to obtain a lock myself, but one which conflicts with the usage by the other jobs; e.g. *EXCL lock. Given the other jobs have a sufficient wait time established for their allocation, watching the other jobs for LCKW status or reviewing the failures in their job[log] for the "can not allocate" pinpoints an [not "the", as there may be others] exact point at which their request to allocate was made. So rather than trying to inquire of why and how they obtained the lock, prevent them from obtaining the lock to expose the when and where they attempt to obtain the lock, then review the code to answer why and how.

FWiW subsystems [and job queues] are a great option for routing work that can be grouped by access to a feature or object. The ENDSBS provides a means to both end and prevent new access to a feature when that might be desirable; HLDJOBQ to prevent normal [additional] routing into a specific subsystem. Although apparently not fully understood how the allocation came about, the users and their work may already be understood enough to be isolated to some specific applications and data for which routing to a specific subsystem has value, if only to enable ENDSBS [when some new incident requires resolution to or investigation of locking].

Regards, Chuck