Shutting down an IBM MQ queue manager correctly protects persistent messages, finishes units of work, and keeps partners from seeing half-closed channels. Killing the process without endmqm invites long log replay and in-doubt transactions that operations resolve at 3 a.m. This page covers endmqm options, quiesce versus immediate stop, draining applications and transmission queues, stopping listeners and channels first, z/OS considerations, maintenance window runbooks, and how shutdown pairs with startup and lifecycle decommission. Beginners learn the commands; operators learn the sequence enterprises expect before patching a server.
endmqm QM1 asks the queue manager to stop after disconnecting clients according to policy. Review IBM documentation for your version's flags: waiting for all applications, quiesce mode, and immediate stop. Scripted shutdown in Ansible or shell should log each step and verify dspmq shows ended state before OS patching reboots the host.
| Mode | Behavior | Use when |
|---|---|---|
| Controlled / wait for apps | Waits for disconnect | Planned maintenance, apps can stop |
| Quiesce | Blocks new connections | Drain in-flight work |
| Immediate | Fast stop, more recovery later | Emergency only |
| OS kill / power loss | Unclean | Never planned |
Stopping while depth remains on XMITQ leaves messages safe if persistent—they forward after next start when channels run. Partners may see channel failures during your shutdown—coordinate windows. In-doubt channel batches may need resolution; check DISPLAY CHSTATUS and partner DLQs after restart.
Applications should MQCMIT or roll back open units of work before disconnect. CICS tasks should end with SYNCPOINT or ROLLBACK. Abrupt disconnect mid-UoW leaves messages visible again after restart for syncpoint gets—at-least-once semantics continue. Idempotent consumers handle redelivery after unclean shutdown.
Queue sharing group members may require coordinated shutdown per IBM recovery procedures. CICS and IMS regions depending on MQ should quiesce first. Started task automation should not restart MQ while maintenance runs on shared CF structures. Follow site standards for VARY CFG and structure recovery.
OS patches, certificate updates in key.kdb, disk expansion, and backup jobs run while MQ is down. Document object changes made offline (rare). strmqm brings service back—verify listeners, channels, and a smoke-test put/get before opening full traffic. Compare DLQ and backout depth to pre-maintenance baselines.
Retiring a queue manager: controlled endmqm, full backup of /var/mqm or data sets, export MQSC definitions, stakeholder sign-off, then dltmqm to remove. Skipping backup before dltmqm is a career-limiting event. Lifecycle tutorial covers governance; shutdown tutorial covers the stop command itself.
12345678910# 1. Stop inbound traffic (apps, triggers) echo "STOP CHANNEL(TO.PARTNER)" | runmqsc QM1 echo "STOP LISTENER(LISTENER.TCP)" | runmqsc QM1 # 2. Optional: DISPLAY QLOCAL(*) CURDEPTH — document backlog endmqm QM1 dspmq -m QM1 /* verify not running */ # --- OS maintenance --- strmqm QM1 echo "START LISTENER(LISTENER.TCP)" | runmqsc QM1 echo "START CHANNEL(TO.PARTNER)" | runmqsc QM1
The library closes for the night: finish checking out books (drain apps), lock the drop box (stop listeners), turn off lights (endmqm). If you pull the fire alarm and run away (kill process), the librarian spends extra time sorting scattered books tomorrow morning (log recovery).
A script runs dltmqm for nightly restart. What is wrong?
10,000 persistent messages on XMITQ; controlled endmqm. Are they safe? What on next start?
Write customer-facing notice text for a 30-minute MQ maintenance window.
1. endmqm without immediate flags generally:
2. Immediate or kill-style stop increases:
3. Before production endmqm you should:
4. dltmqm is used when: