① Guide · IBM sub-capacity disputes
Your IBM monthly license charge follows the peak rolling four hour average in your SCRT report. Most buyers submit that report as routine compliance. It is the single most important negotiating document on the mainframe, and it is full of recoverable error. Here is how to defend your position.
48 hour mobilization Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →Under sub-capacity licensing, you are not billed on the size of your machine. The Sub-Capacity Reporting Tool measures the rolling four hour average of MSU consumption, per product, per LPAR, and reports the highest such average reached during the month. That peak, smoothed across four hours and isolated to the products actually running, is what sets your monthly license charge. Two facts follow from this, and both are levers. The bill is an average, so a brief spike rarely matters. And the bill is per product, so software reported where it does not run inflates the charge for no reason.
Because the report is generated from your own systems and submitted by you, IBM disputes are unusual in one respect: you write the document the bill is based on. That makes the defense a matter of validating the report before it leaves the building, every month, with the same rigor you would bring to a contract.
The recoverable error map
| Error in the report | What it does to the bill | The defense |
|---|---|---|
| Product reported where installed but unused | Bills that product at the LPAR peak for nothing | Correct the product table to deployed and used only |
| Peak driven by a one off batch event | Inflates the month on a non recurring spike | Reschedule discretionary work out of the peak interval |
| Missing or misapplied soft capping | Lets the R4HA run above the intended ceiling | Set and verify defined capacity limits per LPAR |
| Stale product entitlement data | Bills for software no longer deployed | Reconcile the table against current deployment |
The monthly discipline
A clean, validated SCRT history does more than lower this month's bill. It is the evidence base for every IBM negotiation that follows. When the renewal comes, a buyer who can show a disciplined, defensible sub-capacity position negotiates from data; a buyer who submitted whatever the tool produced negotiates from a number IBM understands better than they do. This is the foundation of our IBM mainframe cost optimization work, where the SCRT position is validated first and the renewal is built on it.
The rolling four hour average MSU consumption per product per LPAR, reporting the peak of that average across the month. You are billed on that peak, not on raw capacity or a single spike. See SCRT explained.
Because the bill follows the rolling four hour average peak, not installed capacity. Shifting discretionary work out of the peak, soft capping, and reporting products only where they run all reduce the measured peak without changing the machine.
Products reported where unused, a peak driven by a one off batch event, missing or misapplied soft capping, and stale product tables billing for retired software. Each is a recoverable line.
The defensible path is to validate before submission, because the report becomes the billing basis. Correction after the fact is possible but harder. Treat every monthly report as a negotiating document reviewed on your side first.
The mechanics of the report, with a worked R4HA example.
The consumption model that replaces the R4HA, and when to take it.