This should be a straight forward job. You should be able to use GRTOBJAUT and RVKOBJAUT to set all your object authorities. Something like this :-
RVKOBJAUT OBJ(YourlibA/*ALL) OBJTYPE(*FILE) USER(*ALL) AUT(*ALL)
GRTOBJAUT OBJ(YourlibA/*ALL) OBJTYPE(*FILE) USER(USER1) AUT(*ALL)
GRTOBJAUT OBJ(YourlibA/*ALL) OBJTYPE(*FILE) USER(USER2) AUT(*ALL)
RVKOBJAUT OBJ(YourlibB/*ALL) OBJTYPE(*FILE) USER(*ALL) AUT(*ALL)
GRTOBJAUT OBJ(YourlibB/*ALL) OBJTYPE(*FILE) USER(USER3) AUT(*ALL)
GRTOBJAUT OBJ(YourlibB/*ALL) OBJTYPE(*FILE) USER(USER5) AUT(*ALL)
You could also make this work with parameters or a parameter file. I would suggest using 2 files, which you can then maintain with the correct authorities.
File1 contains list of libraries to process, file2 contains users to be authorised to libraries :-
Make 2 CL programs :-
CL pgm 1 – Reads file 1, revokes all authorities on the library read, calls CL pgm 2 with library name as parameter.
CL pgm 2 – Reads file 2, if library is = parameter, then grant authorities to objects for the user.
You could also expand this to be for certain object types or certain objects.
Just a few ideas.
Martin’s answer is correct in how it discusses the question. However, the question itself has a flaw in how it proposes the overall security scheme.
The implied security scheme involves setting multiple private authorities for multiple user profiles. This eventually becomes a nightmare as the web grows. One inevitable result is that saving security data becomes extremely time consuming as large numbers of objects and profiles must be cross-referenced during every single save. Each SAVSYS or SAVSECDTA must process many objects and profiles.
Better would be to focus first on libraries. Only grant authority for a library to profiles that need it. Authorities for objects in the libraries are less critical then since only those who are suppose to know about the objects can even see them.
For the libraries, grant authority to only a single profile, and make everyone else simply a member of that group. And grant the authority by placing the library on an *AUTL and add the group profile to that *AUTL.
Objects within the library often need specific authorities for different sets of users. Some will need greater authorities than others. You can usually establish two or three categories of authorities. That may call for two or three application group profiles.
One or two users might be administrators with high authority to many objects. They can added to an application ADMIN group. The ADMIN group can be added to a DATA *AUTL with those high authorities. Another set might part of an INQUIRE group that would be on the DATA *AUTL with only *READ rights to data objects.
Applications can be broken down and catregorized. Data objects may be on a DATA *AUTL and programs on a PGM *AUTL. Two or three group profiles would be on the *AUTLs with appropriate authority for their classes of access. Individuals are simply added to or removed from groups — no individual authorities need to be assigned at all.
Of course, in unusual cases, a particular individual might be added to an *AUTL or even given private authority to specific objects, but that should be a rare exception. Individual can be granted authorities that are higher <i>or lower than</i> the authorities of any group that they’re a member of.
The authority checking will stop <i>as soon as</i> an appropriate authority is found. Individual authority is checked before group authority. If, for example, an individual is granted *EXCLUDE authority, then the object is restricted even if the group has *ALL (or even *ALLOBJ special authority, though there are other concerns in that case.)
When you grant private authorities, locks must be established on the objects in order to set those authorities. When authorities are maintained through *AUTLs, then only the *AUTLs are locked as authorities are changed.This makes it far easier to manage authorities during normal working hours while objects are in use.
There is much more to designing an appropriate authority scheme. This has only been a discussion of the kinds of thoughts that should be given to get started. Once a scheme is in place, and authorities are held on group profiles and *AUTLs, then moving to more advanced schemes is far easier. You only need to deal with a couple of profiles and perhaps three or four *AUTLs for a large application.