First thing you need to do is create at least 2 Authorization Lists: One to hold the authority to "Data-containing objects" (ie files, data areas, data queues, etc.); the second to hold the authority to "Program-type objects" (ie programs, display files, etc.). Use the WRKAUTL command.
Then WRKAUTL and grant authority to the Authorization List for each user profile that needs authority, using the same settings as if you were setting authority for each individual object. This assumes that each user has the same authority to all files, and so on.
Then grant/revoke authority to each object in the library, pointing the object to the Authorization List. You only have to make one change to the object to point it to the Authorization List, instead of granting authority to each individual user to each object. This assumes that all files have the same authority, and all programs have the same authority.
You don't need to add all users to the authorization lists-- as long as they're part of a Group Profile. You should be grouping your users into Group Profiles. Then the authorization list only needs to show authority for the Group Profile, and all of the individual users that are part of that Group Profile "adopt" the same authority. -Greatly- reduces the amount of typing!
If there are a few users who have special authority, they can be dealt with separately. They can be part of a different group profile that has different authority on the authorization lists.
We wrote our own utility command/program to align authority. We specify the library name, the profile that should own programs &c, the profile that should own files &c, the authorization list to point programs &c to, and the authorization list to point files &c to. Here are some fragments of that program (I hope the formatting survives!):
First step in the program is to verify that all of the objects listed in the parameters really do exist! This is a bunch of CHKOBJ commands. Use the MONMSG command after each CHKOBJ and "do something" if the object doesn't exist-- ideally you can send a message to the user, or just quit-- the joblog will contain the reason for the problem.
There are 2 possible ways to handle the authority changes required--
a) rip out all authority for all objects, then put it back the 'right' way
b) rip out authority one-object-at-a-time, then put that one object back together.
We elected "method b." This lets us run the command during the day and only affect one object at a time (and skip any object that is currently locked).
For method B we DSPOBJD to an outfile for all objects in the library.
For each object listed in that outfile:
RVKOBJAUT OBJ(&ODLBNM/&ODOBNM) OBJTYPE(&ODOBTP) +
CHGVAR VAR(&TESTAT) VALUE(%SST(&ODOBAT 1 2))
/* &TESTAT is *CHAR LEN(2) */
CHGVAR VAR(&TESTOBJ) VALUE(%SST(&ODOBTP 1 5))
/* &TESTOBJ is *CHAR LEN(5) */
/* These 2 statements create variables exactly the length we need to compare to */
/* This may not be necessary, but we did it anyway. */
This program has been around for years (most recently re-compiled in 2007 on our test machine; the copy on our production machine was created in 2001!), so the details are fuzzy. The RCVMSG and its logic 'bubble up' any errors so the user can deal with them. We normally ignore errors such as "can't allocate" and re-run the command again later.
Field names &ODLBNM, &ODOBNM, and &ODOBTP are from the outfile created by DSPOBJD. Passed-in PARMS for the various profiles and lists are (&LIB, &OLDOWN, &NEWDTAOWN, &NEWPGMOWN, &NEWDTAAUTL, and &NEWPGMAUTL. The &OLDOWN parm lets us change just objects owned by this profile, but we usually use *ALL.
CPF2227 = "Error Occurred Doing Whatever You Asked Me To" We added this so the program will nobly struggle onward, ignoring objects it can't deal with.
This is best submitted to batch-- if the library is large, it could take a while. And change the job DFTWAIT(5) (only wait 5 seconds if you find a lock on an object). Otherwise the program will wait for the job's default wait time (ours is around 30 seconds, maybe more), and if the library is very busy this job could run for -quite- a while!
Paul E Musselman
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Ryan Hunt
Sent: Tuesday, May 10, 2011 2:21 PM
Subject: Commands For File Permissions
Because of environment refreshes, I need to be able to recreate a very
specific set of user/table permissions after copying a large library. right
now I either use iSeries Nav or green screen to add users to files and then
specify specific Add/Delete/Update permissions for the user to the file.
I really need to automate this. Does anyone know what the related CL
commands are for this?
This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact