A queue manager passes through predictable phases from the day architecture names it to the day operations deletes its data directories. Understanding lifecycle prevents the classic mistake of upgrading OS without planning MQ maintenance windows, or deleting a folder that held ten years of audit queues. Lifecycle spans creation with crtmqm or z/OS procedures, configuration of queues and channels, daily start and stop, high availability failover, version upgrades, certificate rotation, capacity growth, and decommission. This page walks the timeline beginners need before touching startup and shutdown commands in detail, ties persistent message survival to each phase, and notes where multi-instance and queue sharing groups change the story on enterprise platforms.
Before creation, agree queue manager name, environment (DEV, TEST, PROD), platform, directory paths or z/OS data sets, listener ports, and channel partners. Names must be unique in the connected network. Document owners, escalation, and backup strategy. Naming conventions tutorial follows later in the track; lifecycle starts with decisions that are expensive to change later.
| Phase | Typical actions | Main risk if skipped |
|---|---|---|
| Create | crtmqm, define paths, initial MQSC | Wrong paths or name collisions |
| Configure | Queues, channels, auth, listeners | Open security or missing DLQ |
| Run | strmqm, applications connect | Disk full, poison messages |
| Maintain | Fixpack, certs, capacity | Expired certs stop channels |
| Upgrade | Version migration, compatibility | Incompatible clients |
| Retire | Drain, backup, endmqm, dltmqm | Accidental data loss |
On distributed systems, crtmqm creates the queue manager and default directories under /var/mqm or custom paths. You specify log size, default queue manager flag, and code page options. z/OS creation uses SMP/E and customization dialogs or commands appropriate to your site standards. Creation does not start the process—startup is the next phase. Object definitions (queues, channels) are usually scripted in MQSC and stored in source control.
Define business queues with DEFPSIST, BOTHRESH, and MAXDEPTH. Create channels with TLS, set CHLAUTH rules, restrict ADMIN access, configure DEADQ, and deploy listeners. Run application connectivity tests from each client platform. Lifecycle quality here determines how painful run phase becomes—most incidents trace to missing DLQ or weak channel auth.
Queue manager process runs continuously in production. Applications MQCONN, channels move traffic, operators monitor depth and channel status. Logs grow—lifecycle includes media management and archive. Queue sharing groups on z/OS may run multiple queue manager members against shared structures; failover is part of run phase operations.
Maintenance windows renew certificates, apply IBM MQ fix packs, extend disk, and tune log settings. Upgrades require compatibility matrices for client versions, staged migration in multi-site estates, and rollback plans. Persistent messages must remain recoverable—backup before major upgrade. Read release notes for object format or command behavior changes.
Building a lemonade stand: build the stand (create), put signs and cups ready (configure), open for customers (run), fix broken pitchers (maintain), move to a bigger corner (upgrade), close and pack up when summer ends (retire).
Draw DEV, TEST, PROD queue managers and which may share channels (hint: usually none across PROD/DEV).
List order of operations to retire QM_OLD without losing persistent audit messages.
Disk with /var/mqm deleted while QM stopped. What lifecycle phase failed?
1. crtmqm on distributed systems:
2. Persistent messages survive:
3. Decommissioning usually includes:
4. A new production queue manager per microservice is often: