PUB Authority

PUB authority is the gate that separates legitimate event producers from everyone else who can connect to IBM MQ. When an order service publishes to prod/retail/order/created, the queue manager resolves the topic string in the tree and asks whether this connection’s effective identity may publish there. If not, MQPUT fails—often reason code 2035—while the same connection might still put to ORDERS.REQUEST queue without error. PUB is intentionally separate from SUB so analytics teams cannot inject fraudulent events, and so compromised read-only consumers cannot publish. This tutorial goes deep on +pub grants, setmqaut patterns, wildcard breadth, pairing PUB with application and channel identity (MCAUSER, TLS DN mapping), cluster publish scope, monitoring unexpected publish rates, denying PUB on sensitive subtrees, and troubleshooting publish failures that are authorization—not network or topic spelling issues.

What PUB Controls

PUB applies when an application uses MQPUT with a topic handle, JMS publish, or REST publish APIs that target a topic. The check uses the published string after alias and cluster resolution. Passing PUB does not grant SUB, TOPIC admin, or +get on subscriber queues—publishers do not need DEST access unless they also consume. Each publication still fans out only to existing subscriptions; PUB does not bypass SUB registration on the consumer side.

PUB grant breadth examples
Topic profileAllows publish to (examples)Risk level
prod/retail/order/createdExact leaf onlyLow—narrow
prod/retail/order/#All order events under retailMedium—domain team only
prod/retail/#All retail production eventsHigh—few principals
prod/#Entire prod treeCritical—break-glass only
#Very broad—avoid in productionExtreme—never for apps

Granting PUB on Distributed MQ

shell
1
2
3
4
5
* Payment engine may publish payment events only setmqaut -m QM1 -t topic -n 'prod/finance/payment/#' -p PAYENG +pub * Deny explicit test of broader grant - should fail: * Application as ANALYT user MQPUT prod/finance/payment/posted -> 2035 dspmqaut -m QM1 -t topic -n 'prod/finance/payment/#' -p PAYENG

Use groups: -p MQ.PAYENG.PUB +pub. Rotate service IDs without renaming topics. After MCAUSER changes on SVRCONN, retest PUB—channel connect uses new identity. SSLPEERMAP that maps certificates to overly powerful MCAUSER with prod/# +pub is a common audit finding.

Producer Identity Design

  • One service ID per publisher application class—not shared developer IDs.
  • SVRCONN MCAUSER matches setmqaut principal or group membership.
  • Bindings connections use explicit OS user with PUB grants—not admin personal accounts.
  • Document allowed topic prefixes in API contracts next to JSON schema version.

PUB and Cluster PUBSCOPE

PUB on QM_LONDON allows local publish; cluster PUBSCOPE on topics determines whether publications propagate to remote subscribers. Missing PUB on remote queue managers does not block outbound propagation from authorized local publish in typical cluster designs—remote delivery is subscription and routing concern. However, applications that publish while connected to multiple QMs need consistent PUB grants on each connection target. Review clustered topics tutorial alongside PUB grants when fan-out crosses data centers.

Deny and Revoke

Remove +pub with setmqaut -remove or RACF DELETE on z/OS. Emergency revoke stops new publishes immediately; in-flight messages already accepted continue routing. Pair revoke with application credential disablement. DISPLAY AUTHREC or dspmqaut audits who retains PUB after reorganizations.

Monitoring and Abuse Detection

Alert on publish rate per topic branch per producer ID. Unexpected PUB success after HR termination indicates credential cleanup failure. Retained publications plus broad PUB can overwrite last-known-good status topics—limit RETAIN publishers to narrow PUB profiles.

PUB vs Queue PUT Authority

+put on QLOCAL is insufficient for topics. Conversely, +pub on topic does not allow put to arbitrary queues. Applications migrating from point-to-point must add topic profiles, not only reuse queue grants. Test with amqspub or minimal MQI program using production MCAUSER in lab.

Explainer: Microphone in the Auditorium

PUB is permission to use the microphone in a given hall. Without it, you can stand in the hall (connect) but cannot announce (publish). Other halls require separate permission—finance hall versus retail hall.

Explain Like I'm Five: PUB Authority

PUB means you are allowed to press the talk button on the loudspeaker for that subject. Without PUB, the button does not work even if you are in the building.

Practice Exercises

Exercise 1

Write setmqaut for ORDPROD +pub only on prod/retail/order/#.

Exercise 2

Why should ANALYT not receive +pub on prod/finance/#?

Exercise 3

Connect OK, MQPUT topic 2035—list identity checks.

Frequently Asked Questions

Frequently Asked Questions

Test Your Knowledge

Test Your Knowledge

1. PUB authority allows:

  • Publish to topic
  • MQGET from DEST only
  • START CHANNEL
  • ALTER QMGR

2. setmqaut +pub is on object type:

  • topic
  • channel
  • namelist
  • process

3. Producer should normally have:

  • PUB without SUB on prod branches
  • SUB only
  • No OAM
  • DLT on all topics

4. 2035 on publish means check:

  • Effective user +pub on topic string
  • MAXMSGL only
  • JCL class
  • COBOL sequence
Published
Read time17 min
AuthorMainframeMaster
Verified: IBM MQ 9.3 documentation