MQ Upgrades

MQ upgrades are how your queue managers move from IBM MQ 9.3.0.5 to 9.4.0.0, from WebSphere MQ 7.5 to a supported 9.x LTS, or from a years-old fix pack to the current cumulative update that closes a security advisory. The word upgrade sounds like running one installer, but production success depends on release type (LTS versus CD), platform (Linux, Windows, z/OS, containers), supported migration path, client compatibility, and whether partners must retune TLS or channel attributes. Beginners sometimes treat upgrades as a weekend surprise for applications that still ship 7.5 clients, or they copy qmgr directories without reading that cross-version copy is not always valid. This tutorial explains IBM release models, pre-upgrade inventory, distributed versus z/OS upgrade flows at overview level, fix pack versus new LTS, client and channel coordination, validation checklists, and rollback thinking—so you can plan upgrades as a controlled project, not a gamble.

LTS, CD, and Fix Packs

dspmqver on the queue manager and on client machines tells you what is running today. Build a spreadsheet: queue manager name, version, OS, install path, last backup date, and dependent application client versions. EOS versions belong on a risk register with a target date—not on indefinite deferral.

Supported Migration Paths

IBM publishes migration guides per platform. A path might allow in-place upgrade from 9.3 LTS to 9.4 LTS on Linux but require different steps on z/OS. Jumping from 7.5 to 9.4 may need intermediate releases or export/import of definitions with message drain. Copying /var/mqm from an old major version to a new install without following the guide invites repository and log mismatch. When in doubt, open the official migration PDF for your source and target pair before scheduling production.

Pre-Upgrade Checklist

1. Read release notes for deprecated features and behavior changes.
2. Export definitions: dmpmqcfg or scripted MQSC from non-prod mirror.
3. Clean endmqm and verify backup restores in lab.
4. Inventory channels, TLS ciphers, and CHLAUTH rules that may need updates.
5. Confirm disk space for new install and log growth during first start.
6. Agree maintenance window and partner notifications.

1
2
3
4
5
6
7
8
9
dspmqver
dspmq -m QM1
dmpmqcfg -m QM1 -a > QM1_before_upgrade.mqsc
* After upgrade in lab:
dspmqver
runmqsc QM1 << EOF
DISPLAY QMSTATUS ALL
DISPLAY CHSTATUS(*) WHERE (CHSTATUS NE INACTIVE)
EOF

Distributed Upgrade Flow (Overview)

Typical pattern: install new MQ binaries alongside or over old per IBM instructions, run setmqinst or platform installer, upgrade queue manager with documented command (name varies by version—follow current doc), allow recovery on first strmqm, verify listeners and channels. Container estates often replace image tag and roll StatefulSet with persistent volume unchanged only when version supports it. Kubernetes MQ Operator upgrades follow operator documentation separately from bare-metal Linux.

z/OS Upgrade Flow (Overview)

z/OS upgrades use SMP/E, CSQ* procedures, and often coordination with sysprog for APF, started tasks, and page set capacity. Queue sharing groups require QSG-wide planning—one member on wrong version breaks the group. Read z/OS migration guide chapters before PROD. Skills from distributed upgrades transfer as concepts (backup, test, rollback) but not as copy-paste commands.

Clients and Applications

• MQ client version should be compatible with queue manager—often same major or supported mix per IBM matrix.
• JMS and .NET clients need matching redistributable libraries in application builds.
• Java clients: update com.ibm.mq.allclient or equivalent in dependency management.
• Test syncpoint, XA, and request-reply patterns under load after client bump.

Post-Upgrade Validation

strmqm succeeds without media recovery errors. DISPLAY QMSTATUS shows RUNNING. Test PUT/GET on representative queues. Start critical channels and confirm MSGS increment. Review AMQERR for new warnings. Run application regression suite. Compare dmpmqcfg output for unexpected missing objects. Monitor log utilization and CPU for 48 hours—some issues appear only under Monday peak.

Rollback Planning

Rollback is viable only if you prepared: backup before upgrade, documented old binaries, and know whether IBM supports downgrade (often limited). Some sites keep old VM snapshot or parallel queue manager until cutover confidence is high. After applications wrote messages on new version, rolling back binary without data plan loses consistency—treat rollback as a designed scenario, not improvisation.

Explainer: Car Inspection Before a Long Trip

Upgrading MQ is like servicing the engine before a cross-country drive: you check tires (disk), oil (backups), and the map (migration guide)—not just paint the hood a new color (new version number in dspmqver).

Explain Like I'm Five: MQ Upgrades

MQ upgrades are giving the mail-sorting machine a newer brain so it can do new tricks and stay safe—but you practice on a toy machine first and save a picture of all the settings before you touch the real one.

Practice Exercises

Exercise 1

Build a version inventory for every QM and client in your lab estate.

Exercise 2

Perform fix pack upgrade in non-prod and document validation steps used.

Exercise 3

Find IBM EOS date for your oldest production version and set target LTS.

Frequently Asked Questions

Test Your Knowledge