3

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

mike
  • 819
  • 4
  • 14

2 Answers2

4

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.
Gabe
  • 121
  • 4
  • 1
    This 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
  • 1
    thanks 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
2

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.

ZEOD
  • 146
  • 2
  • 1
    Thank 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
  • 1
    No, `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
  • 1
    There 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