① Explainer · Licensing concept
Same business, same transactions, bigger bill. Capacity consumption drifts up a few percent a year on its own, and because software is priced on capacity, the cost follows. Here is the creep modeled out, and the levers that reverse it.
Nobody approved more capacity. The transactions are flat. And the bill is up again. That gap has a name.
MIPS creep is the slow, year over year rise in mainframe capacity consumption, and therefore software cost, that happens without any deliberate increase in business volume. The same transaction count, the same overnight batch, the same business processes quietly consume more MIPS and more MSU each year. Because mainframe software is priced on capacity, not on business outcomes, the bill rises in lockstep with the creep, even though nobody asked for more.
It is dangerous precisely because it is invisible. No project drove it, no change ticket flagged it, no one signed off on a bigger machine. It arrives as a slightly higher peak each cycle, and the renewal that lands two or three years later is built on the accumulated total. By then the vendor treats the higher consumption as the new normal and prices the next term from it. The worked model below shows how a modest annual creep compounds into a materially larger commitment.
One estate, flat business volume, starting at 600 peak MSU. A 4 percent annual creep, well within what we commonly observe, with the software bill indexed to 100 in the base year. Watch the gap between business volume and billed capacity open.
| Year | Business volume | Peak MSU | Software cost index |
|---|---|---|---|
| Base | 100 | 600 | 100 |
| Year 1 | 100 | 624 | 104 |
| Year 2 | 100 | 649 | 108 |
| Year 3 | 100 | 675 | 112 |
| Year 4 (renewal) | 100 | 702 | 117 |
Business volume never moved. By the renewal in year four, billed capacity is up 17 percent and the vendor anchors the new term on 702 MSU as if it were demand the business created. Add an indexation clause on top and the two effects compound. The creep rate is illustrative; the compounding mechanic is what matters.
Creep has no single cause, which is why it is so easily missed. It is the sum of small, individually defensible changes, each adding a fraction of a percent to cycles per unit of work. The table pairs each common cause with the lever that pulls against it. None of them stops the business. All of them break the assumption, baked into most renewals, that consumption only ever rises.
| Cause | What it adds | Lever |
|---|---|---|
| Software upgrades | More cycles per transaction each release | Challenge upgrades that raise consumption |
| Inefficient SQL and code | Heavier database and CPU paths over time | Tune the heaviest consumers first |
| Agent accumulation | Monitoring and security overhead stacks up | Audit and prune resident agents |
| Data and index growth | Larger scans, longer batch windows | Reorg, archive, retire dead data |
| Dead and duplicate workload | Jobs nobody owns still consume capacity | Retire workload no longer needed |
| Configuration drift | Workloads spread, peaks widen | Cap defined capacity, offload to zIIP |
These are patterns we commonly observe. The mix and magnitude of creep on any estate depend on its software currency, application portfolio, and configuration.
MIPS creep runs through the MIPS metric itself and lands on the R4HA that sets your bill, and it is one of the main drivers behind a rising cost per MSU. The levers that fight it are the same ones in MSU consumption optimization and zIIP software cost offload. A flat or falling MSU trend is a negotiating asset, which is the work on MSU optimization and mainframe cost optimization.
Audit notice or renewal under 18 months out? We mobilize within 48 hours. Want the creep out of your MSU before the vendor prices it in? Start here.
MIPS creep is the slow, year over year rise in mainframe capacity consumption, and therefore software cost, that happens without any deliberate increase in business volume. The same transaction count, the same batch, the same business, quietly consumes more MIPS and more MSU each year. Because software is priced on capacity, the bill follows the creep upward even though nothing the business asked for has changed.
Several causes, usually compounding: software upgrades that consume more cycles per transaction, new code paths and instrumentation added with each release, inefficient SQL and application changes, database and index growth, the gradual accumulation of monitoring and security agents, and configuration drift that lets workloads spread. None of these is visible as a project. Together they push consumption up a few percent a year, which compounds into a materially larger bill at renewal.
Yes. MIPS and MSU both measure capacity, so creep in one shows up in the other. As consumption rises, the rolling four hour average rises, the peak MSU SCRT reports rises, and the sub-capacity bill rises with it. On full capacity metrics the effect arrives when creep forces a hardware upgrade. Either way, capacity creep is software cost creep, because the metric the vendor bills on is capacity.
You do not stop it entirely, but you can claw it back: tune the heaviest consumers, retire dead and duplicate workload, offload eligible work to zIIP engines that fall outside MLC counting, cap defined capacity to hold the peak, and challenge software upgrades that raise cycles per transaction. The goal is to break the assumption, baked into many renewals, that consumption only ever goes up. A flat or falling MSU trend is itself a negotiating asset.