My preference is to understand how to do this from the TSO command line, and not with ISPF. I would also like to understand if a systems programmer needs to be involved for setting up the group first
2 Answers
First you have to create a RACF dataset profile to cover the dataset in question if it doesn't already exist using ADDSD:
ADDSD 'userid1.JCL.CNTL'
Where userid1.JCL.CNTL is the dataset you want to give access to.
Note that this command will create a discrete profile, unless you add the optional GEN
(for generic) to the ADDSD
. Discrete profiles only ever protect a single data set, and more importantly, discrete profiles are deleted when the data set they protect is deleted. This is mostly unwanted, so most always it is better to create a generic profile even if it shall protect a single data set only.
Also, you should decide what access level you want allow to the "universe" by specifying the UACC
keyword. The default for UACC
depends on your current connect group. You may disallow access to anyone, except the ones you PERMIT
access by specifying UACC(NONE)
ADDSD 'userid1.JCL.CNTL' GEN UACC(NONE)
Then PERMIT access to this newly created profile.
PERMIT 'userid1.JCL.CNTL' GEN ID(userid2) ACCESS(READ)
Where userid1 is your userid and userid2 is your collaborator. Under typical conventions you will be allowed to have control of the permissions of datasets under your high level qualifier. You can also create generic profiles to give access to multiple datasets:
ADDSD 'userid1.JCL.*' GEN UACC(NONE)
PERMIT 'userid1.JCL.*' ID(userid2) ACCESS(READ)
You can also permit a group of users to your datasets by entering a group name in the ID field:
PERMIT 'userid1.JCL.*' ID(groupa) ACCESS(READ)
It's likely you'll need help from a systems programmer if you need a new group created. To add a user to a group you need the CONNECT command.
CONNECT (userid2) OWNER(groupa)
You need AUTH=CONNECT authority to add (connect) new users to the group. You can check if you have connect authority to the groups you have access to by issuing the LISTUSER command:
LISTUSER userid1
Where userid1 is your userid. The output will be similar to:
USER=userid1 NAME=your name OWNER=groupa CREATED=23.033
DEFAULT-GROUP=groupa PASSDATE=23.153 PASS-INTERVAL= 30 PHRASEDATE=N/A
ATTRIBUTES=NONE
REVOKE DATE=NONE RESUME DATE=NONE
LAST-ACCESS=23.171/21:55:05
CLASS AUTHORIZATIONS=NONE
NO-INSTALLATION-DATA
NO-MODEL-NAME
LOGON ALLOWED (DAYS) (TIME)
---------------------------------------------
ANYDAY ANYTIME
GROUP=groupa AUTH=USE CONNECT-OWNER=groupa CONNECT-DATE=23.033
CONNECTS= 68 UACC=NONE LAST-CONNECT=23.171/21:55:05
CONNECT ATTRIBUTES=NONE
REVOKE DATE=NONE RESUME DATE=NONE
GROUP=IZUUSER AUTH=USE CONNECT-OWNER=groupb CONNECT-DATE=23.167
CONNECTS= 00 UACC=NONE LAST-CONNECT=UNKNOWN
CONNECT ATTRIBUTES=NONE
REVOKE DATE=NONE RESUME DATE=NONE
SECURITY-LEVEL=NONE SPECIFIED
CATEGORY-AUTHORIZATION
NONE SPECIFIED
SECURITY-LABEL=NONE SPECIFIED
READY
But you need AUTH=JOIN authority in a superior group in order to use the ADDGROUP command to create a new subordinate group. Groups in RACF are in a hierarchical structure and you'll need the appropriate authority in a superior group.
ADDGROUP mygroup SUPGROUP(groupa)
ICH00007I INSUFFICIENT AUTHORITY TO SUPERIOR GROUP.

- 121
- 4
-
1This is a great answer - and I could certainly do this for multiple users (userid2, userid3, etc.). Would be nice to see one that also showed up to work with a group too. – mike Jun 21 '23 at 03:45
-
I made an attempt to explain grouping in RACF, but we may need a RACF admin. – Gabe Jun 21 '23 at 04:38
-
1thanks Gabe - I appreciate the group addition - that helps! – mike Jun 21 '23 at 15:33
-
Your answer is incomplete and confusing. It implies that you can *directly* permit access to data sets. This is **not** how RACF works! In RACF, you first create *data set profiles* using the `ADDSD` command, then you `PERMIT` access to *data set profiles* (not data sets). The benefit: Access rules are independent of data set existance. I.e. you can delete and recreate a data set and the access rights are still as set before. – phunsoft Jun 21 '23 at 20:32
-
@phunsoft edits made - before you know it we'll have recreated the manual here – Gabe Jun 21 '23 at 22:40
-
@Gabe Thanks for editing. I have added some details to the `ADDSD` command. You can edit my changes as you like. – phunsoft Jun 22 '23 at 07:48
-
@Gabe I don't get the point of your statement *before you know it we'll have recreated the manual here* – phunsoft Jun 22 '23 at 07:49
-
1@phunsoft Just a poor attempt at humor about how explaining something supposedly simple creeps into something much larger than intended. Thanks for your edits - the answer is much better now, thanks. – Gabe Jun 22 '23 at 13:00
-
2@Gabe for the first example, don't I need to also specify GENERIC, e.g. PERMIT 'userid1.JCL.CNTL' ID(userid2) ACCESS(READ) GENERIC – mike Jul 02 '23 at 02:51
-
@Mike - yes thanks for catching that – Gabe Jul 02 '23 at 14:19
-
@gabe you can edit your answer to fix it – mike Jul 02 '23 at 16:15
-
I think I did: PERMIT 'userid1.JCL.CNTL' GEN ID(userid2) ACCESS(READ) Do you think it clearer another way? – Gabe Jul 02 '23 at 20:18
One thing I don't see mentioned yet is the ability to grant "universal" access. This can come in handy to create data set profiles so access is automatically granted without having to create new profiles when new data sets are created.
For example: Perhaps there is a scenario where all the data sets matching a filter like BOB.SHARE.*.** should be "readable" by everyone. This can be accomplished with the UACC keyword in RACF when defining or altering a data set profile.
To add a new RACF profile:
ADDSD 'BOB.SHARE.*.**' UACC(READ)
To alter an existing RACF profile:
ALTDSD 'BOB.SHARE.*.**' UACC(READ)
UACC(READ)
could be changed to UACC(ALTER)
if desired!
Of course it should be mentioned that setting any kind of universal access must be carefully considered.

- 146
- 2
-
1Thank you for the information on the universal access. Sounds comparable I guess to a file system where you set up a chmod -R type of approach... – mike Jun 21 '23 at 15:35
-
1No, `UACC` is comparable to the *world access bits" in the file mode, i.e. it defines access for anyone not being the owner and not being a member of one of the groups that have explicitly been `PERMITted` access to the data set profile. – phunsoft Jun 21 '23 at 20:36
-
1There is nothing in "chmod -R" that says the isn't on the "world access bits" as the command is incomplete. The idea was conveyed successfully. – Gabe Jun 21 '23 at 23:17