① Explainer · Licensing concept
The R4HA is the single most important number in your monthly mainframe software bill, and almost nobody outside the licensing desk understands how it is built. Here it is, worked end to end, with the four levers that move it.
You are not billed on your peak. You are billed on your peak four hour average. The gap between the two is money.
The rolling four hour average, or R4HA, is the metric IBM uses to bill sub-capacity Monthly License Charge (MLC) software on z/OS. Rather than charging on the highest instantaneous MSU your machine touches, IBM charges on the average MSU consumed over a rolling four hour window, and specifically on the single highest such window recorded in the month, per product. The monthly proposal you receive is built on these peaks.
This matters because a short, intense spike, the classic overnight batch surge, gets diluted when it is spread across four hours. Two hours of heavy consumption inside a four hour window is averaged with two quieter hours, so the number you pay on is well below the instantaneous peak. Manage which work lands in which window and you manage the bill. The worked example below shows exactly how the dilution happens.
One LPAR, one product, eight hourly MSU readings across an overnight batch window. The R4HA for each hour is the average of that hour and the prior three. SCRT bills you on the highest R4HA of the month.
| Hour | MSU consumed | 4 hour window | R4HA |
|---|---|---|---|
| 00:00 | 200 | n/a | n/a |
| 01:00 | 210 | n/a | n/a |
| 02:00 | 800 | n/a | n/a |
| 03:00 | 820 | 200, 210, 800, 820 | 507.5 |
| 04:00 | 300 | 210, 800, 820, 300 | 532.5 |
| 05:00 | 250 | 800, 820, 300, 250 | 542.5 |
| 06:00 | 240 | 820, 300, 250, 240 | 402.5 |
| 07:00 | 230 | 300, 250, 240, 230 | 255.0 |
The instantaneous peak is 820 MSU at 03:00. The peak R4HA is 542.5 MSU at 05:00, which rounds to 543 MSU billed. You pay on 543, not 820, a 34% gap created purely by averaging. This is a simplified hourly illustration; SCRT samples at finer intervals, but the mechanic is identical.
The R4HA bites when uncontrolled work stacks into a single window: overnight batch colliding with early online ramp up, month end processing landing on top of normal load, or a new workload quietly raising the floor under the peak. Because the highest window of the month sets the bill for that whole month, one bad night can define thirty days of charges. The four levers below pull that peak window down.
| Lever | How it works | What it touches |
|---|---|---|
| Soft capping | Defined capacity or group capacity limits hold the four hour average under a set MSU ceiling | Caps the reported peak directly |
| Workload shifting | Move heavy batch out of the window where online load already peaks | Flattens the curve so no window spikes |
| zIIP offload | Push eligible work to zIIP engines that fall outside MLC MSU counting | Lowers the MSU that feeds the average |
| LPAR placement | Isolate the products driving the peak so their R4HA is measured separately | Stops one product inflating another's bill |
"Sub-capacity" and these mechanics are IBM constructs; behavior on your estate depends on your machine, your z/OS configuration, and your contract.
The R4HA feeds the MLC charges on IBM's core stack, so it sits underneath products like WebSphere Application Server for z/OS and the rest of the z/OS subsystem family. It is also the baseline data behind any move to a consumption model: Broadcom's Mainframe Consumption Licensing (MCL) and IBM Tailored Fit Pricing both negotiate against your R4HA history. If a renewal or a metric transition is on the table, the R4HA is where the leverage starts. That is the work on mainframe cost optimization and MSU optimization.
Audit notice or renewal under 18 months out? We mobilize within 48 hours. Want your R4HA history read before the vendor reads it for you? Start here.
The R4HA is the metric IBM uses to bill sub-capacity Monthly License Charge (MLC) software on z/OS. Instead of charging on the instantaneous peak MSU your machine reaches, IBM charges on a rolling average of MSU consumption over the preceding four hours. The highest such average across the month, per product, is what you pay on.
The Sub-Capacity Reporting Tool (SCRT) reads SMF data, computes the average MSU consumed over each rolling four hour window at fine grained intervals, and records the peak window per product per LPAR for the month. Because it is an average, short spikes are smoothed: a two hour batch surge to 820 MSU can be billed at roughly 543 MSU once it is averaged across four hours, as the worked example above shows.
Four levers, commonly used together: soft capping or defined capacity to hold the four hour average under a chosen MSU limit, workload shifting so heavy batch does not pile into the same window as online peaks, offloading eligible work to zIIP engines that fall outside MLC, and LPAR placement so the products driving the peak are isolated. Each lowers the peak window that SCRT reports.
Tailored Fit Pricing replaces the monthly R4HA peak with an annual consumption baseline, so the peak management game changes. But most estates still run R4HA based sub-capacity MLC, and the R4HA history is the data that anchors any Tailored Fit Pricing baseline negotiation. Understanding it is a prerequisite for evaluating the alternative, not an obsolete skill.