There is a system value, Library Locking Level (QLIBLCKLVL), that you can use to control whether libraries that are in a job’s library search list are locked. This system value is not new – it has been around since the V5R1 release – but it seems that it’s not very well known as I’ve talked with several people who’ve never heard of it.
The Library Locking Level system value has the default value of ‘1’, which indicates that the libraries in the library search list are to be locked in each job. Each library in a job’s library search list is locked when the job is started and the locks are released when the job ends.
As the number of active jobs on a system grows, the number of locks just for libraries can get very large. Consider an example where there are 1,500 user jobs and the library search list has 10 libraries – that’s 15,000 locks held on the system just to protect those 10 libraries. This is not an efficient use of the system’s locking table. This affects the performance of job initiation and termination when the locks are allocated and released; it also has an effect on overall system performance as there is a single lock table and additional overhead as this table grows very large.
The “Best Practices for Managing IBM i Jobs and Output” Redpaper documents IBM’s recommendation of setting this system value to 0 to not lock the libraries in the library list.
While IBM recommends setting this system value to 0, to not lock the libraries, it could not make that value the default value because, without additional changes, setting this system value to 0 would allow a library to be deleted or renamed even when the library is in the library search list.
If you change the QLIBLCKLVL system value to 0, you need to take an additional step to prevent the libraries from being deleted or renamed—you just need one job to allocate the libraries you want to protect. This job can be set up as an autostart job that runs in the controlling subsystem; it would simply do an Allocate Object (ALCOBJ) on each library that needs to be protected, then loop on a Delay Job (DLYJOB) command. This job would remain active until the controlling subsystem is ended or the job is explicitly ended.
By using this strategy, you can protect the libraries from being deleted or renamed and you can greatly reduce the number of locks on the system.
One final point – the QSYSARB system job locks the libraries that are defined in the system library list (QSYSLIBL) and the user library list (QUSRLIBL) system values. IBM has a support article on this.
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.