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

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?