① Journal · Benchmarks
BMC (BMC Software) increasingly meters its mainframe tools on actual z/OS consumption under zConsumption Licensing, where you pay on last year's MSU and true up the overage. That moves the benchmark question away from list price and onto the baseline itself. Get the baseline wrong and the true up does the damage quietly. Here is how to read BMC spend against your own consumption before it sets the floor.
48 hour mobilization Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →BMC has moved much of its mainframe estate, the AMI families spanning operations, cost, security, data, and DevX tooling, onto zConsumption Licensing. Under zCL you pay a fee based on the prior year's actual z/OS MSU consumption, then true up any overage at the end of the period. On paper this aligns cost with use, which is genuinely better than paying for entitled capacity you never touch. In practice it relocates the risk: the number that governs your bill is the consumption baseline, and a baseline measured during a peak heavy year becomes the recurring floor.
So the BMC benchmark is not really a price comparison. It is a measurement question. Was the baseline taken from a representative period or an inflated one, and is the true up mechanic capped or open ended. Two customers running the same BMC tools on the same hardware can pay very differently depending entirely on how their baseline was captured.
The BMC bill concentrates around a handful of drivers. The benchmark exercise is to test each one against whether it reflects genuine steady state consumption or a transient spike that got captured:
| Spend driver | How it works | Where it inflates |
|---|---|---|
| Consumption baseline (zCL) | Prior year actual z/OS MSU sets the committed fee | Baseline captured in a peak heavy year, then carried forward |
| Annual true up | Overage above the baseline billed at period end | Uncapped overage rate, no ceiling negotiated |
| AMI bundle scope | Tools sold as bundled families | Paying bundle scope for modules a team never adopted |
| Tools displacing IBM equivalents | BMC priced against the IBM alternative | The switching math never re-tested at renewal |
The recurring pattern is that the baseline is treated as a fact rather than a negotiated measurement. It is set once, often early, and then anchors every subsequent year. Bringing the baseline back to representative steady state consumption is usually a larger lever than arguing the unit rate, because the baseline compounds and the rate does not.
A defensible BMC benchmark begins with your own SMF derived consumption history, not the vendor's baseline proposal. Establish what representative steady state MSU looks like across a full cycle, including the quiet months, so a single peak does not define the commitment. Negotiate a cap on the true up rate before signature, because an open ended overage is where an aligned to consumption model stops being aligned. And re-test the displacement math on any BMC tool that exists to replace an IBM equivalent, since that comparison is the real leverage on price. External benchmark bands help calibrate the unit rate, but with zCL the baseline is the number that decides the bill.
The full method is in the guide on benchmarking your mainframe software spend, and the displacement angle is covered in displacing IBM tools with BMC. The sibling reads are benchmarking IBM spend and benchmarking Compuware (BMC) spend. When the BMC renewal lands and the baseline is on the table, our mainframe license negotiation work makes sure the baseline is measured, not assumed. The estate level view sits in the BMC licensing hub.