Date Last Reviewed:
03/15/2007
The Access Control Facility, ACF2, is a data security system installed on the MVS operating system. Its purpose is to protect your data sets from unauthorized access. If you do nothing (set no rules of any kind), any access by another user to your data sets will be denied. In order to allow other users to get at your data sets, you will have to set "rules," specifying the user(s) and the type(s) of access permitted. There are four types of access you can specify: read, write, alloc, and exec.
READ
permits a data set to be opened for input.
WRITE
permits a data set to be opened for output.
ALLOC
permits a data set to be allocated,scratched, or have its catalog entry changed.
EXEC
permits a data set to be accessed to load a program into memory to be executed.
The ACF2 access requirements for various SUPERWYLBUR commands are given below:
|
Command |
ACF2 Access Required |
|---|---|
| CATALOG | ALLOC |
| FETCH | READ |
| FROM option on any command | READ |
| WRITE | |
| PURGE | ALLOC |
| RECATALOG | ALLOC |
| RENAME | ALLOC |
| RESAVE a sequential data set | WRITE and ALLOC |
| RESAVE a member of a pds | READ, WRITE, ALLOC |
| SAVE new sequential data set | WRITE and ALLOC |
| SAVE into a new pds | READ, WRITE, ALLOC |
| SAVE new member into old pds | READ and WRITE |
| SCRATCH | ALLOC |
| SHOW DDNAMES | EXEC |
| SHOW DSNAME MEMBERS | READ |
| UNCATALOG | ALLOC |
| USE | READ |
As you can see, there is no simple equivalent function for each access type. Some commands require that more than one type of access be permitted. ACF2 allows you to specify:
Two terms that occur frequently in regard to ACF2 rules are LID and UID. Although related, they serve very different functions. The LID (logon identification) identifies the account running the job. The form of the LID is CDDIIII where
C refers to the college.
DD refers to the department.
IIII refers to the individual account holder.
If the AccountID owner is setting rules for his own account, the LID will be the same as the field in the $KEY card. However, the LID may not necessarily be the ID to whom the rules refer. (See "Who Can Change ACF2 Rules" below.) In any case, the LID is required for any MVS session.
The UID (user identification), on the other hand, identifies the user(s) to whom the rule applies. If omitted, the rule pertains to all users. The UID is of the form CDDGGGGIIII where
C refers to the college
DD refers to the department
GGGG refers to the group
IIII refers to the individual account
Note that the LID is a subset of the UID (the group field is not part of the LID).
When writing access rules for your data sets, you may use the following symbols:
- a hyphen in column 2 of the data set name field indicates that this rule is set for all data sets. For example, this rule allows any user with an LID beginning with T99 to read all your data sets: - UID(T99) READ(A)
(*) an asterisk enclosed in parentheses after the UID field indicates this rule is set for all users. For example, this rule allows any user to read any of your data sets: - UID(*) READ(A)
(A) an "A" enclosed in parentheses after the type of access indicates that this access is allowed. For example, this rule grants WRITE access to any user for any of your data sets: - UID(*) WRITE(A)
(P) a "P" enclosed in parentheses after the type of access indicates that this access is prevented. If an access is not specified, it defaults to the prevent (P) access, except in the case that EXEC is not specified--then it defaults to the access for READ. For example, this rule prevents WRITE access by any user: - UID(*) WRITE(P)
Using these symbols, you may write the following rule to allow any user READ access to all your data sets:
- UID(*) READ(A)
More than one rule may be written, allowing you to specify a combination of accesses. For example, the rules shown below allow any user READ access to all data sets except FINAL.EXAM:
- UID(*) READ(A)
FINAL.EXAM UID(*) READ(P)Comments can be included when writing rules. Comments are written by putting an asterisk in column 1 followed by the message:
* THIS RULE GIVES ANYONE READ ACCESS TO MY DATA SETS
- UID(*) READ(A)
* BUT THIS RULE PREVENTS EVERYONE FROM READING FINAL.EXAM
FINAL.EXAM UID(*) READ(P)The following ACF2 rules may aid you in setting up your rules ($KEY refers to the AccountID for which these rules will be set):
$KEY(T99ABC1)
* ALLOW ANYONE IN MY DEPARTMENT TO READ MY DATA SETS
- UID(T99) READ(A)
* ALLOW T99BOB1 WRITE AND ALLOC ACCESS TO TOM.MESSAGES
TOM.MESSAGES UID(T99****BOB1) WRITE(A) ALLOC(A)
* ALLOW ANY STUDENT IN MY CLASS READ AND EXEC ACCESS TO
* CLASS.DATA
CLASS.DATA UID(ZH1) READ(A) EXEC(A)The first rule allows anyone whose AccountID begins with T99 to read all the data sets. This is done by specifying a prefix after the UID field. The second rule allows a specific account access to a data set. The format is three digits of the AccountID, four asterisks, and the last four digits of the AccountID. In this case, T99BOB1 may have WRITE and ALLOCATE access to only the data set TOM.MESSAGES. The third rule specifies that any AccountID beginning ZH1 may have READ and EXEC access to the data set CLASS.DATA.
$KEY(T99XYZ1)
* ALLOW EVERYONE COMPLETE ACCESS TO MY DATA SETS
- UID(*) READ(A) WRITE(A) EXEC(A) ALLOC(A)Setting rules that allow everyone complete access to your data sets is not a good idea. You have no way to protect your data sets or your account from unauthorized use.
Comments are denoted by an asterisk (*) in column 1. Comments may be placed anywhere in a rule set but not between continued lines of a rule. Note that these comments will not appear in the compiled output.
Control cards ($KEY, %CHANGE, etc.) must begin in column 1. $ control cards must appear before any % control cards or rules.
Rules must start in column 2. A rule can be continued by putting a hyphen (-) as the last character in the previous line.
Data set names (DSNs) in ACF2 access rules may contain patterns. An asterisk (*) indicates that any character present (including a null character) is valid (matched). A hyphtn (-) in a DSN indicates that any number of index levels may be substituted. Some examples should help make this clear.
Note that each asterisk represents only the number of characters specified, or none. For example, A.123.DATA would not match in the above example.
A hyphen can be used as a shorthand notation for the rightmost filling of a single index level with asterisks. For example, A*******.DATA is equivalent to A-.DATA.
Once you have determined the access rules you wish to set, you must run a program to actually "set" those rules for your AccountID. The procedure that must be run to set your rules is ACFRULES. A typical example follows:
// JOB statement
/*JOBPARM ROOM=123
// EXEC ACFRULES
//RULES DD *
$KEY(T90ABC1)
- UID(T99) READ(A) WRITE(A) EXEC(A) ALLOC(A)
//This program will set a rule allowing anyone with a AccountID beginning with T99 complete access to T90ABC1's data sets. $KEY must refer to the AccountID for which these rules will be set. (See "Who Can Change ACF2 Rules" for more information.) You may set one or more rules by running this program.
If you have a Superwylbur account, there is another way you can set your ACF2 rules. The Superwylbur macro ACFRULES can be invoked to accomplish this. In order to use this macro you must have created a WYLIB PDS (see "Quick PDS" for more information). First, you should collect a data set containing all the ACF2 rules you wish to set. A typical data set might be:
1. $KEY(Z99ABC1)
2. - UID(A10) READ(A) WRITE(A) EXEC(A) ALLOC(A)
3. IMSPROC UID(T90) READ(A)
4. DUMPROC UID(T90****PAT1) READ(A)This set of rules allows any AccountID beginning with A10 complete access to the author's (Z99ABC1) datasets. Any AccountID beginning with T90 is permitted to read Z99ABC1's data set IMSPROC. Read access to the data set DUMPROC has been given to the AccountID T90PAT1. The asterisks in the fully qualified UID string are necessary as there is another field that must be matched. An asterisk indicates that any character is to be considered valid (matched).
Once collected, this data set should be saved into WYLIB:ACFRULES. This will create the member ACFRULES in your WYLIB PDS. (See "Quick PDS" for more information.)
Then issue the command
CALL FROM &PUBLIC.MACROS:CMDS
Then type ACFRULES and follow the directions. (If you have previously called from &PUBLIC.MACROS:CMDS in your profile, simply type in ACFRULES). As the documentation explains, this macro will compile and store your ACF2 access rule set. Once completed, the job will be in the fetch queue. There you can check that it ran successfully and then purge or print it.
The owner of the AccountID may, at any time, change his ACF2 access rules by running the program outlined above. The new rules will replace the previous rules set, not add to them.
The %CHANGE card can also be used to specify the UID's that, in addition to the AccountID owner, may update the access rule set. Use of the %CHANGE card allows you to delegate the authority for changing rules to another UID. The format of the %CHANGE card is:
%CHANGE uid1,uid2...uidn
where the UID's may contain asterisks to indicate that any characters may be present to be valid (matched). For example, the following rules contain the %CHANGE control card:
$KEY(T99ABC1)
PROGRAM.DATA UID(T99) READ(A) WRITE(A)
SAS.INPUT UID(Z11) READ(A) ALLOC(A)
%CHANGE T99****PUG1,T99****ZOK1Here the owner (T99ABC1) is setting rules to permit any AccountID beginning with T99 read, write, and allocate access to his PROGRAM.DATA data set. He is allowing any AccountID beginning with Z11 read access to his SAS.INPUT data set. Two users, T99PUG1 and T99ZOK1, are authorized to change these access rules. As mentioned above, the asterisks are necessary since there is another field that must be matched. Note that $ control cards must appear before any % control cards or rules.
In order to retrieve or otherwise manipulate jobs other than your own that have been run HOLD or FETCH, certain ACF2 rules will have to be set. When you attempt to execute any job reference commands (FETCH, PRINT, PURGE, and SHOW DDNAMES), the system constructs a pseudo dataset name in this form:
AccountID.$JOBCNTL.jobname.Njobnumber
where:
AccountID is the AccountID of the job owner. This forms the high level index for the name.
$JOBCNTL is the actual string $JOBCNTL
jobname is the name of the job.
N is the character N.
jobnumber is the number of the job.
In order to allow another AccountID to be able to execute job reference commands on the jobs that you have run, the following ACF2 rules must be set:
Command ACF2 Access
FETCH READ
PRINT WRITE
PURGE ALLOC
SHOW DDNAMES EXECThe following examples should help illustrate how the ACF2 rules control access to your jobs:
$JOBCNTL.-.N**** UID(*) READ(A) EXEC(A)
$JOBCNTL.- UID(*) READ(A) EXEC(A)These rules, which are equivalent, will allow any user to FETCH or SHOW DDNAMES on any of the jobs you have run. As previously mentioned, a hyphen indicates that any number of index levels may be substituted.
$JOBCNTL.JOBXYZ.- UID(Z01) WRITE(A)
This rule will allow any user whose UID begins with the string Z01 to PRINT your job JOBXYZ.
$JOBCNTL.MY.-.N1*** UID(M99) READ(A) EXEC(A)
This rule will allow any user whose UID begins with the string M99 to FETCH any of your jobs whose name begins with the string MY and whose job number is between 1000 and 1999.