CONNECT
Puts a user into a group.
Also written CO
Why it matters. A user gets a team's access by belonging to the team. CONNECT is how they join.
Syntax
{CONNECT | CO} userid GROUP(group) [AUTHORITY(USE | CREATE | CONNECT | JOIN)] [UACC(access)] [OWNER(userid | group)]- userid
- The user to connect. It comes first.
- GROUP(group)
- The group to join. If you leave it out, it is your current connect group.
- AUTHORITY(level)
- The user's level in the group. USE if you leave it out. You cannot give more than you have.
- UACC(access)
- The default universal access for new profiles the user makes while this group is current. NONE if you leave it out.
- OWNER(id)
- Who owns the connection.
- REVOKE | RESUME
- Block or unblock the user in this one group.
- SPECIAL, OPERATIONS, AUDITOR
- Powers that apply only inside this group.
Try it CONNECT
- 1
Put the user ZB0003 into the group ZBDEV.
CONNECT ZB0003 GROUP(ZBDEV) - 2
Look at the members of ZBDEV.
LISTGRP ZBDEV - 3
Change ZB0003's level in ZBDEV to CONNECT.
CONNECT ZB0003 GROUP(ZBDEV) AUTHORITY(CONNECT)
Remember
- CONNECT, then the user ID, then GROUP(name).
- AUTHORITY is the level inside the group. USE is the plain one.
- Leave GROUP out and you get your own group, not the one you meant.
The usual mistake
CONNECT ZB0003
Without GROUP, RACF uses your own group. ZB0003 joins SYS1, not ZBDEV, and RACF says nothing.
CONNECT ZB0003 GROUP(ZBDEV)
On real z/OS
MF/OS models GROUP, AUTHORITY, UACC and OWNER, and says so when it ignores another operand. Real CONNECT prints nothing on success, so MF/OS adds a 'Mainframe101 sim:' note. For an unknown user or group MF/OS prints its own note, because IBM documents no ICH message for it.
Where can I practise CONNECT?
Right here, at ZedBank. You take a junior job at a simulated bank and use CONNECT 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.
- Access levelHow much a user may do to a resource: read it, change it, or control it, with each level including the ones below.