When you allocate a library (*LIB object) with an *EXCLRD lock, it does not behave the way you think it should. You assume that no changes can be made to the objects in that library, but the CL Programmer's Guide states the following:

"[...] allocation of a library does not restrict the operations that can be performed on the objects within the library. That is, if one job places an exclusive-allow-read or shared-for-update lock state on a library, other jobs can no longer place objects in or remove objects from the library; however, other jobs can still update objects within the library."

I have found this item to be extremely important when allocating libraries. When I allocate a library with an *EXCLRD, other users can no longer add or delete objects from that library, but they can update objects in the library. This is a source of frustration, as I have applications where I need to lock all the objects in a library from both deletion and update.

Editor's Note: As far as we know, the only way of allocating all objects in a library (say, for *EXCL or *EXCLRD use) is to allocate each object individually with the Allocate Object (ALCOBJ) command, performing a loop in a CL program. You need to run the Display Object Description (DSPOBJD) command to an outfile in order to obtain a list of objects in the library. Then you can ALCOBJ each of them in turn. The problem, of course, is that such allocation doesn't happen all at once. It is therefore possible for a job to start updating an object before the ALCOBJ cycle reaches it.