Infrastructure & Reliability · Middleware — Messaging · Chapter 25 of 33
IBM MQ from the inside
Queue managers, channels, transmission queues and units of work — how IBM MQ moves a payment between two data centres exactly once, the high-availability options from a pair of servers to a mainframe coupling facility, and the reason codes every MQ interview asks about.
IBM MQ is the message broker most large banks run their core integration on. It began as MQSeries in 1993, was renamed WebSphere MQ in 2002 and IBM MQ in 2014, and the names still overlap in job descriptions and in conversation — “MQ” on its own, in a bank, almost always means this product, though in a vendor-selection meeting it can mean Gartner’s Magic Quadrant instead. IBM’s own product blog says 98 of the top 100 global banks use IBM MQ; the figure is undated and unexplained, but no one disputes the direction.
The objects
| Object | What it is | Why it exists |
|---|---|---|
| Queue manager | The server process that owns queues, stores messages and runs channels. A bank has hundreds | The unit of administration, recovery and licensing |
| Local queue | A queue that physically lives on this queue manager | Where messages wait for their consumer |
| Remote queue definition | A local name that points at a queue on another queue manager | Applications put to a local name and never need to know where the target lives |
| Transmission queue | A special local queue holding messages bound for another queue manager | Where messages wait while the other side is unreachable |
| Alias queue | Another name for a queue | Lets a queue be moved or renamed without changing applications |
| Model queue | A template for queues created on demand | Temporary reply queues for request/reply |
| Channel | A one-way connection between queue managers (sender and receiver), or between a client application and a queue manager (server-connection) | The only way messages cross the network |
| Listener | The process accepting network connections for channels | Usually on port 1414 by convention |
An application connects to a queue manager in one of two ways. In bindings mode it runs on the same machine and talks to the queue manager through shared memory — fast, and common on the mainframe. In client mode it connects across the network through a server-connection channel — the norm for applications running in containers or on separate servers.
Persistence and the recovery log
A persistent message is written to the queue manager’s recovery log before the put completes. That write, forced to disk, is the dominant cost of persistent messaging: the speed of the log disk sets the throughput ceiling of a queue manager, which is why logs go on the fastest, lowest-latency storage available and on different volumes from the queue files.
| Log type | What it can recover | Operational cost |
|---|---|---|
| Circular | Restart recovery: messages that were on the queue manager when it stopped | Low — log space is reused automatically |
| Linear | Restart recovery and media recovery: rebuilding a damaged queue file from the log | Higher — old log extents must be archived and deleted, or the disk fills |
Units of work, backout and poison messages
An application gets and puts messages under syncpoint: nothing it does is visible or final until it commits, and a rollback undoes all of it — the message returns to the queue with its backout count increased by one. When the count passes the queue’s backout threshold, a well-written application moves the message to the named backout queue rather than trying again. When the unit of work must include a database update, the queue manager can act as the coordinator of an XA two-phase commit, or take part in one run by the application server.
* Define a production queue: persistent by default, deep enough to buffer an outage,
* and a backout queue for poison messages after three failed attempts
DEFINE QLOCAL('PAYMENTS.IN') DEFPSIST(YES) MAXDEPTH(500000) +
BOTHRESH(3) BOQNAME('PAYMENTS.BACKOUT')
* The first three commands of every MQ investigation
DISPLAY QLOCAL('PAYMENTS.IN') CURDEPTH IPPROCS OPPROCS
DISPLAY QSTATUS('PAYMENTS.IN') MSGAGE LGETTIME
DISPLAY CHSTATUS('QM1.TO.QM2') STATUS MSGSClusters are not high availability
IBM MQ clusters let many queue managers share definitions and spread messages across several instances of the same queue. They simplify administration and balance workload. They do not make a message highly available: a message already sitting on a queue manager that fails stays there, stranded, until that queue manager comes back. It is one of the most common misunderstandings in MQ architecture, and a favourite interview question.
The real high-availability options
| Option | How it works | Where |
|---|---|---|
| Multi-instance queue manager | Active and standby instances on two servers sharing networked storage; the standby takes over the files if the active one fails | Linux, Windows, AIX |
| RDQM — Replicated Data Queue Manager | Three Linux nodes; the queue manager’s disk is replicated synchronously between them, and a cluster manager restarts it on a surviving node | MQ Advanced, on Linux |
| Native HA | Three replicas in containers; the active one streams its log to the other two, and a majority must confirm each write. Since MQ 9.4.2, Cross-Region Replication copies a Native HA group to a second region for disaster recovery | OpenShift or Kubernetes |
| Queue-sharing group | Several queue managers on the mainframe share queues held in the sysplex’s coupling facility, a shared memory structure; messages survive the loss of any one queue manager, and CICS can connect to the group rather than to one member | IBM Z (z/OS) only |
CICS, the Customer Information Control System, is the mainframe transaction server behind much core banking; its tight integration with IBM MQ through queue-sharing groups is the single largest reason banks do not simply swap IBM MQ out.
Security
- TLS on every channel, with a named cipher specification, so messages are encrypted on the network.
- Channel authentication records (CHLAUTH), which block or map connections by address, certificate or user — the first line against an unknown client connecting to a production queue manager.
- Connection authentication, which requires client applications to present a user and password or a certificate.
- Object authorities, granting each application only the queues it needs, and only the operations it needs — put, get, browse.
- Advanced Message Security (MQ Advanced only), which signs and encrypts the message body end to end, so even an administrator on an intermediate queue manager cannot read a payment.
Reason codes worth knowing by number
| Code | Name | What it usually means |
|---|---|---|
| 2009 | MQRC_CONNECTION_BROKEN | The network or the queue manager dropped the connection mid-operation |
| 2033 | MQRC_NO_MSG_AVAILABLE | A get found the queue empty — normal, not an error, when polling |
| 2035 | MQRC_NOT_AUTHORIZED | Security refused the connection or the operation; the queue manager’s error log says why |
| 2053 | MQRC_Q_FULL | The queue reached its maximum depth — the consumer has stopped or fallen far behind |
| 2059 | MQRC_Q_MGR_NOT_AVAILABLE | The queue manager is down, or the listener or network is unreachable |
| 2085 | MQRC_UNKNOWN_OBJECT_NAME | The queue name does not exist on this queue manager — usually a configuration or environment mismatch |
What MQ Advanced adds
IBM sells two main editions. The base product provides the messaging. MQ Advanced adds Advanced Message Security, RDQM and Native HA, and IBM MQ Managed File Transfer — file transfer carried over MQ channels, which links this sub-section to the file transfer one. IBM also provides connectors that move messages between IBM MQ and Kafka. What each edition costs is in messaging licensing.
Check yourself