IBM MQ for z/OS does not maintain a separate permission database like the Object Authority Manager file on distributed systems. Instead, when an application issues MQCONN or MQOPEN, or when an operator runs an administrative command, the queue manager asks the System Authorization Facility (SAF) whether the caller is allowed to perform the operation. RACF, as the most common external security manager on z/OS, answers with return codes that permit or deny access. This integration is why mainframe MQ security skills overlap with RACF administration: the queue name your developer sees in a JCL or CICS definition must have matching RACF profiles, and the user ID under which the channel initiator runs must be permitted for channel and queue access. Beginners coming from Linux MQ must relearn grants as profiles and classes, not setmqaut. This tutorial explains the RACF integration model, major MQ RACF classes and what they protect, how access levels map to put and get, started tasks versus interactive users, administration profiles, relationship to CHLAUTH and TLS, auditing with SMF, and troubleshooting 2035 and CSQ security messages.
MQ does not call RACF directly by name in application code—it calls SAF with a resource class, profile name, and requested access. SAF routes to the active external security manager (RACF, ACF2, or Top Secret). The same SAF interface is used by CICS, Db2, and datasets. Enterprise security standards therefore apply uniformly: revoke a user in RACF and MQ access disappears along with other resources. MQ product documentation lists the RACF class names and profile naming conventions for each release; your security team may use custom generic profiles for naming standards.
| RACF access | General meaning | MQ example use |
|---|---|---|
| READ | Inspect or consume where read applies | Browse or get where profile maps to read |
| UPDATE | Change data or put messages | Put to queue, some operational updates |
| CONTROL | Broader control short of full admin | Varies by class—see IBM MQ z/OS security manual |
| ALTER | Administrative change authority | Define or alter MQ objects where class allows |
IBM MQ defines multiple RACF classes so security can be granular. Exact class names and profile formats are release-specific—always use the IBM MQ for z/OS RACF guide for your version. Conceptually: classes exist for queue manager-level access (who may connect or administer the queue manager), queue profiles (who may open named queues or patterns), channel profiles, and administrative functions. Profiles often embed the queue manager name and object name so QM1 and QM2 production isolation is possible. Generic profiles with wildcards reduce profile sprawl but increase risk if patterns are too broad—a profile that covers all queues on a queue manager is convenient and dangerous.
12345/* Illustrative RACF commands — syntax varies by site standards */ /* PERMIT profile naming must match IBM MQ RACF profile rules */ RDEFINE MQQUEUE qmgr1.queue.payment.in UACC(NONE) PERMIT qmgr1.queue.payment.in CLASS(MQQUEUE) ID(PAYSRV) ACCESS(UPDATE) SETROPTS RACLIST(MQQUEUE) REFRESH
A developer’s TSO user ID may work in test because personal RACF groups include MQ permissions. In production, CICS transactions and batch jobs run under application user IDs; channel initiators run under dedicated started task IDs. Each needs explicit PERMIT statements. A common production incident is promoting code that worked under the developer ID while the CICS region user lacks UPDATE on the queue profile. Channel security also maps partner identity through MCAUSER and CHLAUTH, but RACF still gates whether that MCAUSER may put to the target queue. Document every user ID in the message path, not only the last mile application.
Operators using CSQUTIL or console commands need RACF authority appropriate to the command class. Defining queues, altering channels, and displaying objects each map to profiles documented by IBM. Emergency break-glass IDs should be rare, monitored, and time-bound. MQ administrators should not share superuser RACF access when CONTROL on specific queue managers is sufficient for daily work.
RACF integration is giving IBM MQ a single building security desk shared with the rest of the mainframe. Before you enter a room (open a queue), the desk checks your badge (user ID) against a list (profile) for that room name.
CHLAUTH rules decide which channel connections are accepted and which MCAUSER applies at the channel layer. RACF decides whether that MCAUSER may perform the MQI operation on the queue. TLS authenticates the network peer. All three layers are required in modern architectures: TLS without RACF leaves authorized network peers able to abuse weak MCAUSER mapping; RACF without CHLAUTH may allow unwanted connections before identity is established. Security architecture documents should show all three for inbound distributed traffic to z/OS.
RACF generates SMF records for failures and sometimes successes depending on SETROPTS and audit settings. MQ also logs not authorized events. Correlate RACF audit, MQ AMQ messages, and application 2035 return codes during investigations. Regulated environments require periodic access reviews of MQ profiles just like dataset profiles.
RACF is the list of who may use each IBM MQ mailbox name on the mainframe computer, shared with all the other programs in the building.
List all user IDs that touch one CICS-to-MQ payment flow and the RACF profile each needs.
Explain to a Linux MQ admin why setmqaut does not apply on z/OS production.
Write a RACF change request template for new queue PAYMENT.IN on QM1.
1. On z/OS MQ, authorization is checked via:
2. RACF profiles for MQ live in:
3. Channel initiator needs:
4. RACF versus OAM on Linux: