Midrange News for the IBM i Community

Posted by: Bob Cozzi
Rogue Programmer
Cozzi Productions, Inc.
Any downside to turning off QLIBLCKLVL?
has no ratings.
Published: 16 Feb 2012
Revised: 23 Jan 2013 - 4051 days ago
Last viewed on: 22 Feb 2024 (5048 views) 

Using IBM i? Need to create Excel, CSV, HTML, JSON, PDF, SPOOL reports? Learn more about the fastest and least expensive tool for the job: SQL iQuery.

Any downside to turning off QLIBLCKLVL? Published by: Bob Cozzi on 16 Feb 2012 view comments(1)

I'm considering changing the System Value QLIBLCKLVL from the shipped default of '1' (on) to '0' (off). This would avoid having jobs that contain a library on their library list from locking those libraries from other functions, such as save/restore, clear, delete, rename, etc.

Has anyone ever worked with this system value before?

Return to midrangenews.com home page.
Sort Ascend | Descend


(Sign in to Post a Comment)
Posted by: DaleB
Premium member *
Reading, PA
Comment on: Any downside to turning off QLIBLCKLVL?
Posted: 12 years 9 days 18 hours 14 minutes ago

No, but found a Redpaper authored by Dawn May and others. They recommend '0'. Apparently system jobs, subsystem monitors, and secondary threads do not lock the library list anyway. It's only a regular job's primary thread that locks. It mentioned a performance benefit by reducing number of locks on the system.

Don't know what happens to an active job if you delete or rename a library that's in it's library list. Guessing it will probably would be OK until next time it tries to find an unqualified object, then it will end abnormally. (Not entirely unlike *PGM in a call stack, DLTPGM, then calls eventually return to the non-existent program.)

Before I clear, delete, or rename, I do WRKOBJLCK on *LIB; you'll lose that. To be safe you'd need a little program or command that lists all jobs and checks their library lists.

Save won't be affected, really. You'll still need save-while-active because of objects in the library.