RE: Object lock

["Wintermute, Sharon" <Sharon.Wintermute@xxxxxxxxxxxxxxxx>]

You beat me to it Vern!!

One of our nightly processes that does a lot of copying uses the alcobj
with *EXCL first.  If it doesn't get the lock, then it calls the RPG pgm
that uses APIs to report back what jobs are holding it up.  Then we page
out to tell the support staff. 


Sharon Wintermute


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Vern Hamberg
Sent: Tuesday, February 24, 2009 7:33 AM
To: Midrange Systems Technical Discussion
Subject: Re: Object lock

Even easier than the job log - it should be an escape message and should

be monitorable - if so, then RCVMSG and get the message data - the 
object name and type will be there - oh, and DSPOBJLCK does not exist, 
might it be WRKOBJLCK?

There is also an API - QWCLOBJL - that is probably a simple CALL and can

return this information without resorting to reading a spooled file 
(always a possibly unreliable solution, as it can change from release to

release). This API returns a list of object locks into a user space - 
very workable in CL, albeit much easier in RPGLE and pointers.

HTH
Vern

James F Hawkins wrote:
> > A CPYF in a nightly batch job has been failing for the last couple of

> >     
> weeks because the target file is in use.
> What can I put in the CLP to see what's locking the object and avoid 
> coming to work at 2am?
>
> If you know the object, 
>
> DSPOBJLCK  (lib/obj) OUTPUT(*PRINT)
>
> .  You should be able to identify the object by looking in the joblog.
>
>
>
>
>
> Thank you,
> - Jim
>
>
>
>
>
>
>
>