MQ for z/OS licensing: messaging middleware priced on MSU capacity.

IBM MQ for z/OS is the mainframe edition of IBM MQ, the messaging middleware that moves transactional messages between applications with assured, once only delivery. On the mainframe it runs as one or more queue managers, each a set of z/OS address spaces, and it is the integration backbone in many banking, insurance, payments, and retail estates, connecting CICS, IMS, Db2 for z/OS, and batch to distributed and cloud systems. It is decoupling and reliability infrastructure: applications hand messages to a queue and trust MQ to deliver them. Because those queue managers run real production work on the mainframe, MQ falls inside the IBM Monthly License Charge family, billed the same way as z/OS, CICS, Db2, and IMS.

MQ for z/OS is a Monthly License Charge product, charged every month on capacity measured in MSU, and in modern estates almost always under sub-capacity rules. Under sub-capacity the bill follows the rolling four hour average, the R4HA, of the LPARs where MQ runs rather than the full machine rating, and the monthly position is reported through the Sub-Capacity Reporting Tool, SCRT, which IBM bills from. Container Pricing for IBM MQ is an alternative vehicle that meters and prices the MQ workload as its own container, separate from the rest of the MLC peak, which can help where MQ bursts would otherwise inflate the aggregate. The metric is shared with the rest of the stack; what makes MQ specific is how its message bursts land against everyone else's peak.

Directional and pattern level. Confirm your MLC terms, sub-capacity status, and whether Container Pricing or Tailored Fit Pricing applies in your own IBM agreements before modeling a renewal.

The first driver is the rolling four hour average on the LPARs where MQ runs, because MLC follows the peak, not the average load. The second is workload placement: MQ spread across many LPARs lands in more peak intervals and contributes to more of them, so the footprint matters as much as the throughput. The third is timing, where MQ heavy batch or message bursts that coincide with the CICS or Db2 peak compound the R4HA rather than smoothing it. The fourth is the pricing vehicle itself, since standard sub-capacity, Container Pricing for IBM MQ, and Tailored Fit Pricing can produce very different numbers for the same workload. The volume of messages is rarely the headline; where and when MQ runs against the rest of the stack is.

MQ exposure is mostly capacity attribution and reporting accuracy. Common traps we see at pattern level:

Because MQ is an MLC product billed on the peak, the levers are about placement, timing, the vehicle, and the wider MLC deal. The five that pay:

MQ has technical alternatives, including Kafka and other streaming platforms, lighter weight message brokers, and distributed MQ running off the mainframe, and some message flows genuinely belong on those platforms. But MQ for z/OS earns its place where assured, transactional, once only delivery tightly coupled to CICS, IMS, and Db2 is the requirement, and moving those flows means rebuilding integration patterns, requalifying delivery guarantees, and carrying dual running risk through a long transition. For most estates the practical leverage is not displacement but managing the MSU: place the workload, shape the peak, and pick the pricing vehicle deliberately. Where a genuine architectural shift is already underway, the residual MQ footprint becomes part of that wider platform decision rather than a standalone renewal.