In this article we will look at common user administration, data set protection and resource access tasks, with an example for each command. Note that these are simplified examples. The manuals linked throughout the article provide the complete syntax and authority requirements.
Although the three products perform similar functions, their commands and access control rules work differently. These differences are important when moving between products.
The following tables contain useful IBM RACF, Broadcom ACF2 and Broadcom Top Secret (TSS) commands for Security Administrators working in a z/OS environment.
Product versions
The reference levels used for this article are:
| Product | Documentation level |
|---|---|
| IBM RACF | z/OS Security Server 3.2 |
| Broadcom ACF2 for z/OS, formerly CA ACF2 | 17.0 |
| Broadcom Top Secret for z/OS, formerly CA Top Secret | 17.0 |
ACF2 and Top Secret 17.0 became generally available in March 2026. The examples below use the current product documentation available on 20 October 2026. Individual functions can also depend on installed maintenance. See the Broadcom release announcements for ACF2 17.0 and Top Secret 17.0, and IBM’s z/OS 3.2 RACF changes.
Before using the examples
The commands are deliberately simplified. They assume that the administrator has the required authority and scope, and that any referenced groups, departments, profiles and resources already exist unless the example creates them.
USER01, APPGRP, APPDEPT and APPPROF are example names. Replace NEWPASS with a temporary password that meets your installation’s requirements. Protect any command logs and output containing passwords or password phrases.
These are individual examples, not a script to execute from beginning to end. Creating a base user definition does not complete TSO, CICS, USS or application provisioning.
IBM RACF
RACF administration is based on user, group, data set and general resource profiles. The examples use the full command names and assume execution through the RACF TSO command interface. Operator commands have additional issuing requirements. See IBM’s summary of command issuing options.
User profiles and group connections
| Task | Command example | Description |
|---|---|---|
| Create a user | ADDUSER USER01 NAME('EXAMPLE USER') DFLTGRP(APPGRP) OWNER(APPGRP) PASSWORD(NEWPASS) REVOKE | Creates the user and connects it to its default group. The ID is initially revoked while provisioning is completed. The initial password is expired. |
| List a user | LISTUSER USER01 | Displays the user’s base profile and group connection information, subject to the issuer’s authority. |
| Change the user’s name | ALTUSER USER01 NAME('UPDATED USER') | Changes the NAME field. |
| Reset a password | ALTUSER USER01 PASSWORD(NEWPASS) | Sets an expired password, requiring a change when the user next authenticates with it through an interface supporting password changes. |
| Revoke a user | ALTUSER USER01 REVOKE NORESUME | Revokes the ID and clears a pending RESUME date. Ordinary revocation takes effect at the next logon; it does not provide the active-session protection of containment. |
| Resume a user | ALTUSER USER01 RESUME | Resumes an ordinarily revoked ID. Additional action is needed if it is contained or has a revoke date that must be cleared. |
| Connect a user to another group | CONNECT USER01 GROUP(APPREAD) AUTHORITY(USE) | Connects the user to the existing APPREAD group with USE group authority. |
| Remove a group connection | REMOVE USER01 GROUP(APPREAD) | Removes the connection to APPREAD. Do not use this to remove the user’s current default group without first changing the default group. |
| Delete a user | DELUSER USER01 | Deletes the user profile. Review ownership, resource access lists and application dependencies as part of the removal procedure. |
Notes:
NOREVOKEclears a revoke date. It is not a substitute forRESUMEwhen the ID is already revoked.- Group connections can affect the authority held in an existing security environment. Account for a new logon or the application’s supported security refresh procedure when verifying a change.
- A password reset does not reset a separately defined password phrase. Use the appropriate
PHRASEoperand when administering a phrase. - IBM warns that issuing
ADDUSERfrom ISPF can write the command buffer, including the password, to ISPLOG. Issuing it as an operator command can expose the password in the system log. Use a suitable TSO administration session and protect its output. - Before
DELUSER, resolve user data set profiles, user ID associations and ownership dependencies. Deletion removes group connections but does not remove every reference to the ID from other profiles and access lists. See IBM DELUSER.
References: IBM ADDUSER, ALTUSER and LISTUSER, in the z/OS Security Server RACF Command Language Reference.
User ID containment
RACF provides containment for situations where ordinary revocation is insufficient. Containment causes subsequent RACF-protected access requests to fail, including requests from active sessions. It does not undo work already performed or terminate every running process.
ALTUSER USER01 CONTAINTo inspect the user:
LISTUSER USER01After the incident has been investigated and reinstatement approved:
ALTUSER USER01 NOCONTAIN RESUMENOCONTAIN removes containment but does not clear the REVOKE setting; RESUME is also needed. The RACF address space must be active to add or remove IDs from containment. IBM documents this function for z/OS 3.2 and z/OS 3.1; verify the applicable maintenance for APAR OA67286. See RACF user ID containment.
Group profiles
| Task | Command example | Description |
|---|---|---|
| Create a group | ADDGROUP APPGRP SUPGROUP(SYS1) OWNER(SYS1) | Creates APPGRP under the existing SYS1 group. Use the superior group appropriate for your organisation. |
| List a group | LISTGRP APPGRP | Lists the group and its connected users. |
| Change installation data | ALTGROUP APPGRP DATA('APPLICATION SUPPORT') | Updates the group’s installation-defined information. |
| Delete a group | DELGROUP APPGRP | Deletes the group after its connections, subgroups and ownership dependencies have been resolved. |
Group authority, such as USE or CONNECT, and group attributes, such as group-SPECIAL, serve different purposes. Membership alone does not give an administrator unrestricted authority over the group’s users and resources. See IBM ADDGROUP and ALTGROUP.
Data set profiles
The following examples use a fully qualified generic profile for APPTEST.DEMO.DATA. The explicit GENERIC operand distinguishes it from a discrete profile even though the name contains no wildcard characters. Generic data set processing must already be enabled.
A fully qualified generic profile protects a single data set name and remains defined if the data set is deleted and recreated. This differs from a discrete profile. See IBM Choosing between discrete and generic data set profiles.
| Task | Command example | Description |
|---|---|---|
| Define protection | ADDSD 'APPTEST.DEMO.DATA' GENERIC UACC(NONE) OWNER(APPGRP) | Creates the profile with no universal access. |
| List the profile | LISTDSD DATASET('APPTEST.DEMO.DATA') GENERIC ALL | Lists the generic profile and its access list. |
| Change universal access | ALTDSD 'APPTEST.DEMO.DATA' GENERIC UACC(NONE) | Sets UACC to NONE. Existing access list entries are retained. |
| Grant READ access | PERMIT 'APPTEST.DEMO.DATA' GENERIC ID(APPREAD) ACCESS(READ) | Adds or updates the APPREAD group’s access list entry. |
| Remove that entry | PERMIT 'APPTEST.DEMO.DATA' GENERIC ID(APPREAD) DELETE | Removes APPREAD from this access list. Other sources of authority can still apply. |
| Delete the profile | DELDSD 'APPTEST.DEMO.DATA' GENERIC | Deletes the security profile, not the data set. Review the resulting protection before doing this. |
After changing generic data set protection, refresh the cached generic profiles as required:
SETROPTS GENERIC(DATASET) REFRESHDo not assume that UACC(NONE) means nobody can access the data set. Access lists, group membership, global access checking, WARNING and privileged authority can also affect the result. Always check the profile actually protecting the data set. References: IBM ADDSD, ALTDSD, LISTDSD and PERMIT.
General resources and RACF options
APPTEST.READ below is an illustrative FACILITY resource. Defining it does not make an application check it: the application must issue the corresponding security request.
| Task | Command example | Description |
|---|---|---|
| Define a resource profile | RDEFINE FACILITY APPTEST.READ UACC(NONE) OWNER(APPGRP) | Defines the FACILITY profile. |
| List a resource profile | RLIST FACILITY APPTEST.READ ALL | Displays its base information and access list. |
| Change a resource profile | RALTER FACILITY APPTEST.READ UACC(NONE) | Changes the profile’s universal access. |
| Grant resource access | PERMIT APPTEST.READ CLASS(FACILITY) ID(APPREAD) ACCESS(READ) | Grants READ to APPREAD. |
| Delete a resource profile | RDELETE FACILITY APPTEST.READ | Deletes the profile. |
| Find user profiles | SEARCH CLASS(USER) MASK(USER) | Searches for user profile names beginning with USER. |
| Display RACF options | SETROPTS LIST | Displays the options visible to the command issuer. Auditing information depends on the issuer’s attributes. |
Where FACILITY is already active and SETROPTS RACLISTed, make relevant profile changes effective with:
SETROPTS RACLIST(FACILITY) REFRESHThis is different from SETROPTS GENERIC(DATASET) REFRESH. The appropriate action depends on the class and how its profiles are held in storage. References: IBM RDEFINE, general resource command examples and SETROPTS.
Broadcom ACF2
ACF2 commands depend on the current command setting. For example, DELETE USER01 under SET LID processes a logonid, while DELETE APPTEST under SET RULE processes an access rule set. Always establish the setting explicitly.
Enter the command processor from TSO READY:
ACFLogonid administration
Start with:
SET LID| Task | Command example | Description |
|---|---|---|
| Create a logonid | INSERT USER01 NAME(EXAMPLE USER) PASSWORD(NEWPASS) PSWD-EXP SUSPEND | Creates a basic logonid with an expired password, initially suspended while provisioning is completed. |
| List a logonid | LIST USER01 | Displays its fields, privileges and restrictions within the issuer’s authority. |
| Change a name | CHANGE USER01 NAME(UPDATED USER) | Updates the NAME field. |
| Reset a password | CHANGE USER01 PASSWORD(NEWPASS) PSWD-EXP | Sets a password and marks it expired. Password phrase expiry is controlled separately. |
| Suspend a logonid | CHANGE USER01 SUSPEND | Sets the SUSPEND attribute. |
| Remove suspension | CHANGE USER01 NOSUSPEND | Removes SUSPEND. A CANCEL attribute or another restriction can still prevent access. |
| Delete a logonid while retaining its matching access rule | DELETE USER01 NORULE | Deletes the logonid without also deleting the access rule whose key matches the logonid. Associated user profile records are still subject to deletion. |
Note: without NORULE, deletion of a logonid also deletes the access rule with the matching key by default. NORULE does not preserve the associated user profile records or remove references to the user from other rules. Review these dependencies and archive the definitions before deletion.
References: Broadcom ACF2 17.0 INSERT, CHANGE and DELETE. Broadcom also documents password expiry and the separate password phrase controls.
Data set access rules
ACF2 uses compiled access rules to control data set access. The following example creates a new rule set for APPTEST and allows users matching the UID mask FINPAY01 to read APPTEST.DEMO.DATA:
SET RULE
COMPILE
$KEY(APPTEST)
DEMO.DATA UID(FINPAY01) READ(ALLOW)
END
STORECOMPILE enters the rule compiler. The first END finishes compiler input; STORE saves the compiled rule set. The leading spaces on the control statement and rule entry are intentional. Terminal prompts are not part of the input.
Note that UID(FINPAY01) is a mask. It also matches longer UID strings beginning with FINPAY01; a trailing dash is not required. It must not be read as an exact-user selection. An ACF2 UID string is not automatically the logonid and is not a USS numeric UID.
Before using a UID mask, check which logonids it matches within your administrative scope. The LIST example uses an explicit trailing mask character:
SET LID
LIST UID(FINPAY01-)Return to SET RULE before continuing rule administration. Do not substitute UID(-) unless the rule is intended to apply to all users. See Broadcom UID mask matching and the ACF2 17.0 LIST subcommand.
$KEY(APPTEST) supplies the high-level qualifier. DEMO.DATA supplies the remaining qualifiers. READ(ALLOW) does not grant WRITE or ALLOCATE, but it also permits EXECUTE: ACF2 uses the more permissive of the READ and EXECUTE settings for execute access. Adding EXECUTE(PREVENT) would not override READ(ALLOW).
These settings describe the rule’s permissions. Actual data set access also depends on the active security mode, other applicable rules and privileges such as SECURITY or NON-CNCL. Test the result with an ordinary user, not just an administrator. See Broadcom data set security modes and the limits of rule simulation for privileged users.
Use this as a new rule set example. Compiling and storing a replacement for an existing key can replace rules protecting other data sets under that key. Decompile and preserve the complete existing rule set before editing it.
| Task | Command example | Description |
|---|---|---|
| Select access rule processing | SET RULE | Establishes the data set access rule setting. |
| Display a rule set | DECOMP APPTEST | Decompiles the stored APPTEST rule set for inspection. |
| Compile rule source from a PDS member | COMPILE 'SECADMIN.RULESRC(APPTEST)' | Compiles rule text from the named member. Review the compiler result before storing. |
| Store a compiled rule set | STORE | Saves the current compiled rule set. |
| Delete a rule set | DELETE APPTEST | Deletes the entire APPTEST access rule set, not just one rule entry. |
If APPTEST is a globally resident data set access rule, reload it using the operator command:
F ACF2,RELOAD(APPTEST)ACF2 is the assumed started task name. This is an MVS operator command, not input to the rule compiler. See ACF2 17.0 Create Access Rule Sets, Access Rule Entries and Process Access Rules.
Global options and command help
To inspect the GSO password options record:
SET CONTROL(GSO)
LIST PSWDThis displays the stored record. It should not be confused with a complete display of every active authentication control.
To display operating state information:
SHOW STATETo obtain help for the current command setting:
HELPTo leave the ACF command processor, outside compiler input:
ENDSee the ACF2 17.0 Command Reference and ACF Subcommands.
Broadcom Top Secret (TSS)
Top Secret uses Accessor IDs (ACIDs). ACID types include USER, PROFILE, DEPARTMENT and DIVISION. A PROFILE ACID is commonly used to collect permissions for assignment to users; it should not be confused with a RACF resource profile.
ACID administration
| Task | Command example | Description |
|---|---|---|
| Create a user ACID | TSS CREATE(USER01) TYPE(USER) NAME('EXAMPLE USER') DEPARTMENT(APPDEPT) PASSWORD(NEWPASS,,EXP) SUSPEND | Creates a user in the existing department, with an expired password and an initial administrative suspension. The omitted password interval uses the installation default. |
| List a user | TSS LIST(USER01) DATA(ALL) | Lists the user’s security data. |
| Include connected profile data | TSS LIST(USER01) DATA(PROFILE,ALL) | Includes the contents of the profiles connected to the user. |
| Change a name | TSS REPLACE(USER01) NAME('UPDATED USER') | Replaces the NAME field. |
| Reset a password | TSS REPLACE(USER01) PASSWORD(NEWPASS,,EXP) | Issues an expired password. On REPLACE, omitting the interval retains the existing interval. |
| Suspend a user administratively | TSS ADDTO(USER01) SUSPEND | Adds an administrative suspension. |
| Remove an administrative suspension | TSS REMOVE(USER01) ASUSPEND | Removes the administrative suspension. Other suspension causes must be checked separately. |
| Remove a password or violation suspension | TSS REMOVE(USER01) SUSPEND | Removes the suspension types documented for SUSPEND. It is not the replacement for ASUSPEND when clearing an administrative suspension. |
| Delete a user ACID | TSS DELETE(USER01) | Deletes the ACID. Resource ownership and dependent ACIDs can prevent deletion and must be reviewed first. |
For a temporary administrative suspension created with FOR or UNTIL, use the corresponding form when removing it. For example:
TSS ADDTO(USER01) SUSPEND FOR(5)
TSS REMOVE(USER01) ASUSPEND FORReferences: Top Secret 17.0 Command Functions, administrator PASSWORD keyword, SUSPEND and ASUSPEND.
Profiles, ownership and access
The following examples use the data set prefix APPTEST.. This scope is deliberately broader than the individual data set used in the RACF and ACF2 examples.
| Task | Command example | Description |
|---|---|---|
| Create a profile ACID | TSS CREATE(APPPROF) TYPE(PROFILE) NAME('APPLICATION READERS') DEPARTMENT(APPDEPT) | Creates a profile to hold application permissions. |
| Connect the profile | TSS ADDTO(USER01) PROFILE(APPPROF) | Connects APPPROF to USER01. |
| Disconnect the profile | TSS REMOVE(USER01) PROFILE(APPPROF) | Removes this profile connection. |
| Assign data set ownership | TSS ADDTO(APPDEPT) DSNAME(APPTEST.) | Assigns ownership of the prefix to the department. Review existing ownership first. |
| Permit access | TSS PERMIT(APPPROF) DSNAME(APPTEST.) ACCESS(READ) | Gives the profile READ access to data sets matching the prefix. The resource must already be owned. |
| Revoke that permission | TSS REVOKE(APPPROF) DSNAME(APPTEST.) ACCESS(READ) | Revokes the simple READ permit shown above. For a permit with additional restrictions, reproduce the relevant criteria from its XAUTH listing. |
| Find the owner | TSS WHOOWNS DSNAME(APPTEST.) | Displays matching ownership information within the administrator’s scope. |
| Find access assignments | TSS WHOHAS DSNAME(APPTEST.) | Displays matching ownership and permit information within the administrator’s scope. |
Notes:
- Resource ownership and resource access are different operations.
ADDTOassigns ownership;PERMITauthorises access to an owned resource. - If a resource is already owned,
ADDTOcan transfer ownership and leave the previous owner with full access through a permit. CheckWHOOWNSbefore changing ownership and review the resulting permissions afterwards. - Ownership on an individual user or profile gives that ACID ALL access. Assigning ownership to the appropriate department or division avoids using ownership as a routine user permission.
REMOVEremoves ownership or attributes.REVOKEremoves permissions. Do not interchange them.- A
REVOKEcontaining only the resource, with no additional criteria, can remove multiple matching permits. Inspect the access authorisation data before constructing a selective revocation. - Removing a permit from APPPROF affects users receiving access through that profile. It does not remove access provided by another connected profile, a direct permit or resource ownership.
WHOHASoutput must be interpreted alongside connected profiles, matching rules, security mode and administrative scope. It is not a substitute for testing the actual access request.
References: Top Secret 17.0 ADDTO, PERMIT, REVOKE and PROFILE.
Display the security environment
TSS MODIFY STATUSThis displays the status of the security environment. Other uses of MODIFY can change control options. Dynamic control option changes generally revert to the startup parameter values at the next IPL or Top Secret recycle unless the startup parameters are also updated. See the Top Secret 17.0 MODIFY function.
Some considerations when working across the three products
| Area | RACF | ACF2 | Top Secret |
|---|---|---|---|
| User definition | User profile | Logonid record, with associated profile records where applicable | USER ACID |
| Common shared access mechanism | Group membership and profile access lists | UID-based rules or the installation’s role-based rules | Permissions on connected PROFILE ACIDs |
| Data set access | Matching data set profile and its access list | Compiled access rule entries | Resource ownership and permits |
| Example storage update | GENERIC or RACLIST refresh, as appropriate | RELOAD for globally resident data set rules; other record types have their own activation procedures | Follow the applicable security record and cache refresh procedure |
Access levels also need care. RACF UPDATE includes READ, whereas ACF2 WRITE does not imply READ. However, ACF2 READ can also permit EXECUTE, as explained above. We should therefore check the documented behaviour of each access type instead of assuming that the levels map directly between products. See the ACF2 17.0 Access Rule Entries reference.
After making a change, list the updated definition, refresh the relevant in-storage records where required, and test the result. Confirm that the user can perform the intended action and is denied actions outside that requirement. Existing sessions and application security caches also need to be taken into account.
For the complete syntax, authority requirements and restrictions, refer to the IBM and Broadcom manuals linked throughout this article.
Be the first to comment