ADDGROUP
Creates a new, empty group in RACF.
Also written AG
Why it matters. You give access to a team once, on the group. Then new people only need to join it.
Syntax
{ADDGROUP | AG} group-name [OWNER(userid | group)] [SUPGROUP(group)] [DATA('text')] [UNIVERSAL]- group-name
- The new group. It comes first. It must not be a name already used by a group or a user ID.
- OWNER(id)
- Who looks after the group. If you leave it out, you do.
- SUPGROUP(group)
- The group above it. If you leave it out, it is your current connect group.
- DATA('text')
- Notes stored with the group, up to 255 characters.
- UNIVERSAL
- A group that can hold a very large number of users.
Try it ADDGROUP
- 1
Create a group called ZBDEV for the developers.
ADDGROUP ZBDEV - 2
Check that RACF knows ZBDEV now.
LISTGRP ZBDEV - 3
Try to create ZBDEV a second time.
ADDGROUP ZBDEV
Remember
- The group name comes right after ADDGROUP.
- A new group is empty. CONNECT puts users in it.
- Success is silent. Check with LISTGRP.
The usual mistake
ADDGROUP ZBDEVELOPERS
A group name can be at most 8 characters. ZBDEVELOPERS has 12, so the command is refused.
ADDGROUP ZBDEV
On real z/OS
MF/OS models the group name, OWNER and SUPGROUP. DATA, UNIVERSAL and the DFP and OMVS segments are not modelled, and MF/OS does not check whether the name is already a user ID. Real ADDGROUP prints nothing on success, so MF/OS adds a 'Mainframe101 sim:' note.
Where can I practise ADDGROUP?
Right here, at ZedBank. You take a junior job at a simulated bank and use ADDGROUP in real work, with Zed beside you. There's nothing to install.
Start at ZedBankRelated
- RACFThe security manager for z/OS, which decides who may sign on, read a dataset, or run a transaction.
- RACF groupA named collection of users, used to grant access to many people at once rather than one at a time.
- RACF user IDA person or program's identity on the system. Short, unique, and the basis of every access decision.