MQ PVU and VPC Metrics Compared

IBM MQ is the messaging backbone in countless estates, and it has been sold under more than one metric. Older entitlements tend to be PVU, newer ones VPC, and the metric you actually hold decides how the audit counts your queue managers. The same MQ deployment can price two ways depending on the metric behind it.

PVU and VPC are different ways to count the same servers

PVU, the processor value unit, is a core based metric: value units per core times the cores allocated to MQ. An Intel core is rated at roughly 70 PVU, so the count scales with the processor model and the number of cores the software can use. VPC, the virtual processor core, counts virtual cores more directly and is the metric IBM has moved much of the portfolio toward. Since Passport Advantage v11, VPC metered products carry sub-capacity reporting obligations and manual counting is no longer permitted, which means a VPC MQ deployment needs an approved reporting tool just as a PVU one does.

Where the two metrics diverge in practice

• Conversion confusion: a deployment moved from a PVU entitlement to VPC, with both counted at once
• Sub-capacity under either metric: both require continuous reporting to license virtual cores rather than the whole host
• PVU table errors: the wrong value per core applied to a PVU deployment, inflating the count
• VPC manual counting: a VPC product still being counted by hand, which is no longer allowed

How sub-capacity bites on MQ

Whichever metric applies, the sub-capacity rule is the same: you may license only the virtual cores running MQ instead of every core on the physical host, but only if an approved tool such as ILMT was deployed within 90 days of first eligible deployment, ran continuously, and produced quarterly reports retained two years. Miss any of those and IBM defaults to full-capacity, charging every core on the host. A four core MQ footprint on a thirty two core server is the difference between a small bill and one more than seven times larger, and the reporting record is what decides which one you pay.

How buyers defend the MQ count

We start by confirming which metric each MQ entitlement actually carries, because the response is built differently for PVU and VPC. For PVU deployments we recheck every value per core against the published table and rebuild the sub-capacity record. For VPC deployments we confirm the reporting tool is capturing virtual cores correctly and that no manual count is being relied on. Where a conversion left both metrics in play, we resolve the double count to the single entitlement that applies, and challenge any full-capacity finding wherever continuous reporting exists.