On z/OS, IBM MQ speaks to operators through CSQ messages while applications still receive MQRC integers from COBOL, Java, and CICS programs. A coupling facility structure rebuild, a queue sharing group member failure, or a CHINIT address space problem surfaces on the console long before a distributed admin sees an alert email. Distributed teams joining mainframe MQ programs need a CSQ primer: what the numbering means, where messages are recorded, how CSQ relates to AMQ on hybrid systems, and which codes appear during IPL, recovery, and peak online windows. This page is the z/OS encyclopedia companion to every-mq-amq-message—same troubleshooting discipline, different log destination.
CSQ messages follow IBM subsystem conventions: message ID, severity, and explanatory text. Severity guides response—informational during planned START MQM, error when a structure is unavailable, severe when data integrity or sharing group membership is at risk. Copy the exact message ID into change records. Mainframe operations often correlate CSQ timestamps with SMF, syslog, and CICS transaction dumps; your ticket should include LPAR, QSG name, queue manager name, and member role (full repository, partial repository, or non-cluster member).
| Destination | Audience | Retention notes |
|---|---|---|
| z/OS operator console | Operations on shift | Scrolls; capture with automation |
| CSQOUT data sets | Post-incident review | Site policy; archive to tape or log platform |
| Related SMF records | Capacity and audit | Billing and compliance teams |
| Application logs (MQRC) | Developers | Correlate timestamp with CSQ |
During START MQM or automation-driven queue manager start, CSQ messages confirm subsystem initialization, CHINIT and CSQINXZ tasks, and connection to the coupling facility when in a QSG. Failures here prevent RUNNING status on any member—distributed clients see 2059 QM_NOT_AVAILABLE even when the LPAR is up. Check that the started task proc matches installation standards, that data sets are mounted, and that no duplicate queue manager name conflicts exist in the sysplex. Compare with a known-good IPL trace from change documentation.
12345Operator workflow (conceptual): 1. Note exact CSQ message ID and time from console or CSQOUT 2. DISPLAY QMSTATUS on the affected queue manager 3. For QSG: DISPLAY QSG and CF structure status 4. Correlate with CICS or IMS if bridge transaction abends
Queue sharing groups place shared queues in coupling facility structures. CSQ messages about structure rebuilds, structure failures, or member disconnects explain why puts fail with reason codes tied to unavailable shared queues or why channels stall. Partial repository members have different symptoms than full repository loss—learn your QSG topology before an incident. REFRESH CLUSTER and repository fixes on distributed MQ do not replace CF structure recovery on z/OS.
| Theme | Business symptom | First action |
|---|---|---|
| CF structure not available | Shared queue puts fail | CF recovery with operations; verify structure name |
| QSG member not active | Workload imbalance or total outage | DISPLAY QSG; restart member per runbook |
| Repository sync issues | Cluster routing wrong | Repository role; REFRESH CLUSTER on affected members |
| Channel to distributed partner | XMITQ growth on hub | CHSTATUS plus distributed AMQ on partner |
Many enterprises run hub queue managers on z/OS and spoke queue managers on Linux or Kubernetes. A channel failure may log AMQ9208 on Linux and CSQ channel-related text on z/OS within the same second. Build hybrid runbooks that require both logs in tickets. Developers on spokes should not dismiss mainframe CSQ as not my platform—their messages stop at the hub.
z/OS uses RACF profiles for MQ resources in addition to OAM on the queue manager. CSQ messages may reference security product failures or profile gaps that still produce MQRC 2035 to applications. Correlate CSQ with RACF SMF and with dspmqaut-equivalent displays on z/OS. MCAUSER on channels must map to a valid RACF user with correct access to queues and topics.
After an abnormal shutdown, CSQ messages document log replay, media recovery, and whether the queue manager entered consistent state. Operators distinguish clean shutdown restarts from recovery modes that extend RTO. Application teams should plan for longer unavailability windows when CSQ indicates recovery—not merely strmqm on distributed. Document expected CSQ informational sequences for DR tests so night shift recognizes normal versus abnormal recovery.
Distributed AMQ is the speaker in the Linux server room. CSQ is the panel in the z/OS control room that lights up when the shared elevator (coupling facility) or power bus (QSG) has a fault affecting every tenant on the floor.
The big computer building has its own alarm words starting with CSQ. When the shared toy box for many apps breaks, the building manager hears CSQ first; your app might only know it cannot put a message in the box.
From a DR test, list three CSQ messages that are normal during QSG member restart.
Draw a hybrid diagram: app on Linux, hub on z/OS, and which log each side writes on failure.
Match one MQRC from a CICS bridge failure to a CSQ timestamp window in lab.
1. CSQ messages are primarily for:
2. CSQOUT is typically:
3. QSG problems may show as:
4. Applications still see failures as: