① Journal · Benchmarks
IBM (International Business Machines) software commonly absorbs 30 to 50 percent of a mainframe budget, yet most buyers have no reference point for whether their number is reasonable. The problem is that IBM spend is not one number. It is three pricing systems stacked on the same estate, and each one benchmarks differently. Here is how to read your IBM bill against the patterns we see at the table.
48 hour mobilization Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →When a CFO asks what the IBM mainframe bill should be, the honest first answer is a question: which bill. IBM charges for mainframe software through three distinct systems that share nothing but the machine. Monthly License Charge, the recurring sub-capacity charge for z/OS and the major subsystems such as Db2, CICS, IMS, and MQ, is metered against your rolling four hour average peak and reported each month through the Sub-Capacity Reporting Tool. International Program License Agreement products, the tools layer, carry a one time charge plus annual support and subscription and do not move with your peak at all. Tailored Fit Pricing, the container model IBM now pushes hard, replaces the MLC peak mechanic with an annual committed baseline and a per MSU rate for consumption above it.
A benchmark that averages across all three is meaningless, because the same dollar buys completely different things in each. The useful exercise is to split the bill into its layers first, then benchmark each layer against what drives it.
Across the IBM estates we work, the bill concentrates in predictable places. The benchmark question is never the headline rate, it is whether each layer is being driven by genuine need or by inattention:
| Spend layer | Pricing basis | What inflates it |
|---|---|---|
| z/OS and subsystems (MLC) | Sub-capacity R4HA peak via SCRT | Unmanaged peaks, batch and online colliding in the same hour, no soft capping |
| Tools (IPLA) | One time charge plus annual S&S, Value Unit based | Shelfware kept on support, duplicate tools across LPARs, no retirement discipline |
| Tailored Fit Pricing | Committed annual MSU baseline plus consumption rate | A baseline set from an inflated historic year, then never revisited |
| Specialty engines | zIIP and zAAP offload, lower charged capacity | Eligible work not routed to zIIP, so it lands on general purpose MSU |
The pattern that recurs is that the largest savings rarely come from arguing the per MSU rate. They come from the structure: shaving the R4HA peak with disciplined soft capping, retiring IPLA tools that have not been used in years but still draw annual support, and stress testing a Tailored Fit baseline before it becomes the floor every future year builds on.
A credible IBM benchmark is built from your own estate before it reaches for any external figure. Express MLC as cost per peak MSU, not total dollars, so growth in the bill can be separated from growth in the workload. Track IPLA support as a percentage of one time charge already paid, because support quietly outliving its value is the most common form of waste we find. And model any Tailored Fit Pricing baseline forward across the full term, since the committed number is far easier to set high than to bring back down. External benchmark bands are useful as a sanity check, but they are reference points, not targets. Two shops on identical hardware can sit far apart on cost per MSU and both be correct, because workload shape and discipline differ.
The deeper read on the capacity metric itself sits in our explainer on cost per MSU benchmarks and drivers, and the step by step method is in the guide on benchmarking your mainframe software spend. When the IBM renewal lands and the baseline conversation starts, our IBM mainframe cost optimization work turns the benchmark into a negotiating position rather than a talking point. For the entry and exit mechanics of the container model, see negotiating Tailored Fit Pricing.