Re: problem with QSYSARB holding a lock on a library object

[CRPence <CRPbottle@xxxxxxxxx>]

  Do the other system jobs all have the locks, or only the QSYSARB 
job(s) has the lock?  If all of the system jobs [likely any job 
using *SYSVAL for the library list portions] then presumably the 
CHGSYSVAL QKBDTYPE either did not take or was changed back to '1'.

  In searching the web for that SVal name, there are topics noting 
MIMIX requires the value be '1', so possibly something like that 
software may have effectively overridden the change, by returning 
the value to '1'.

  Probably best to refer to the history log by DSPLOG MSGID(CPF1806 
CPF1808) to verify the change was issued before the IPL as claimed 
and that the value was not changed back [by whom or whatever] before 
or during the IPL; security auditing, if active for the appropriate 
special value, would log a change to the QAUDJRN as well.

  If there is no confirmation the result of the system having 
started using QLIBLCKLVL='1' is correct due to the system value 
either not having been changed or correctly changed back to '1' 
[before the near-end of the IPL; even if changed back to '0' after 
the IPL completed], then reporting the issue as a defect would seem 
the best next step.

Regards, Chuck

Mark S. Waterbury wrote:
> With V5R3M0 and above, we have the system value QLIBLCKLVL that
> can be set to 0 to inhibit the *SHRRD lock on *LIB objects that
> are added to each job's library list.  This is convenient when we
> need to be able to rename a library (for example, on a test
> system).
>
> Last week, I was working with a customer running V6R1, and they
> changed QLIBLCKLVL from 1 to 0, but the next day, there were
> still a large number of system jobs (spool jobs, etc.) that held
> a *SHRRD lock on the library in question, presumably because
> those jobs started before they changed QLIBLCKLVL. They decided
> to wait for the next scheduled IPL of the system over the 
> week-end.  Now, I see the QSYSARB job holds a *SHRRD lock on
> several libraries, including the one we want to rename.
>
> Does anyone know what is going on here?
>
> Under what conditions does QSYSARB hold a *SHRRD lock on a
> library, and why does it appear not to honor the QLIBLCKLVL
> system value?