15 pts.
Edit Object Authority
EDTOBJAUT I am no expert, but I would like to try and make my life easier. I need to find out if there is a way for me to add/edit/delete these authorities per user in a CL program for instance. I am sitting with the problem that multiple files need to be created in multiple libraries, and the authorities in each of these libraries are different for different users. If I could write a CL for each user/library combination this would make my life a lot easier, seeing that new files are created on a daily basis. Is this a dumb question?

Answer Wiki

Thanks. We'll let you know when a new response is added.


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 :-



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 :-

File 1:

YourlibA USER1
YourlibA USER2
YourlibB USER3
YourlibB USER5

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 Gilbert.


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.


Discuss This Question: 1  Reply

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • graybeard52
    This depends on your application setup, but I offer 2 suggestions 1. Put the security at the library level, and let it secure all objects under it by default. 2. Its my opinion, but I (almost) never give any user access to any object in the system. I give authority to a group, and assign the user to the group. Then I can add/del the user from the group an be done with it. Both these suggestions may or may not be advisable in your specific case.
    3,115 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: