When the library's CRTAUT value is *EXCLUDE, new objects created within the library will be set to *PUBLIC AUT(*EXCLUDE), based upon the CRTAUT of the library. Note: Be careful to specify the correct CRTAUT for your libraries, since CRTAUT(*SYSVAL) is the default value when initially creating a Library.

Overriding the Library's CRTAUT Value

You do not need to accept the CRTxxx command default of AUT(*LIBCRTAUT). You can specify the authority for the object as needed, as in the following command to Create a Data Area:

CRTDTAARA DTAARA(MYLIBRARY/MYDATA) TYPE(*CHAR) LEN(100) AUT(*USE)

Here, the CRTAUT value of MYLIBRARY is not considered, and the data area is assigned *PUBLIC AUT(*USE) authority.

Using an Authorization List

When setting the value for a library's CRTAUT parameter, the name of an authorization list can be assigned, as shown here on the Change Library (CHGLIB) command:

CHGLIB LIB(MYLIBRARY) CRTAUT(MYAUTL)

Then, when a new object is created in the library, the new object will be secured by the MYAUTL authorization list. This assumes that we accepted the default value on the CRTxxx command of AUT(*LIBCRTAUT) or that we specified AUT(MYAUTL).

Using an authorization list to assign the authority for a newly created object gives you some nice flexibility. You are not limited to only assigning *PUBLIC authority, but when using an authorization list, you can assign all private authorities to the object at the time the object is created.

Object Ownership: The Gotcha

The only gotcha when it comes to assigning authority to a new object is that the object will be owned by the creator or by the creator's primary group profile. The owner will have *ALL authority to the new object, which might not be what you want, especially if you are securing the new object with an authorization list. In these cases, you will need to develop a method to reassign the ownership of the new object.

I'd be anxious to hear your ideas on the best way to set the exact authority that you want on a newly created object when the creator/owner should not have a distinct authority to the object.

I am one who believes that most objects types should be owned by an "owning" profile, whose sole purpose for existence is to own objects. For example, create the user profile PRODOWNER. Assign PRODOWNER as the owner of your production objects. This owning profile PRODOWNER is not a group profile. It is simply a profile to own objects.

This works great until someone creates a new object, which makes them (or their primary group) the owner of the new object, and not PRODOWNER.

What I'd Like to See

It would be great to have an OBJOWNER parameter on all the Create commands, where you could specify something like OBJOWNER(*LIBOBJOWN), which would assign the ownership of the new object based upon a library attribute of "Library Default Object Owner." But alas, right now we may need to retrofit the ownership of these newly created objects to set them correctly. Another option may be to restrict users from creating new objects in sensitive libraries.