① Guide · IBM MLC optimization
IBM Monthly License Charge bills on a single peak, not on the work you do. Shape the peak and the bill falls with no application touched. Soft capping and R4HA management commonly recover 10 to 20% of MLC. Here are the buyer side levers, worked.
MLC bills the peak, not the total. That is the opening.
Monthly License Charge (MLC) covers IBM's recurring mainframe software: z/OS, CICS Transaction Server, Db2 for z/OS, IMS, and MQ. Under sub-capacity terms the charge for each product is driven by the rolling 4 hour average, the highest sustained four hour MSU window in the month, captured by IBM's Sub-Capacity Reporting Tool (SCRT) from your SMF records. One spike sets the bill for thirty days.
That billing shape is the lever. Because the charge tracks a single peak rather than total throughput, the same applications can produce a smaller invoice when the peak is flattened, when work moves to zIIP specialty engines that are not counted against MLC, or when the estate sits on the pricing model that fits its profile. None of this requires changing what the business runs. It requires reading your own SCRT data more closely than the vendor does.
| Lever | Mechanism | Typical MLC impact | Watch for |
|---|---|---|---|
| Soft capping (defined capacity) | Caps an LPAR's billable MSU so spikes do not lift the R4HA peak. | Commonly 10 to 20% where peaks are spiky. | Cap set too low starves production; model first. |
| Group capping | Shares a capacity ceiling across LPARs so peaks offset rather than stack. | Adds to soft capping on multi LPAR estates. | Needs WLM policy discipline across the sysplex. |
| Batch and online scheduling | Moves heavy batch out of the online prime time window. | Flattens the four hour peak directly. | Requires scheduling change, not code change. |
| zIIP offload | Eligible Db2, Java, and XML work runs on zIIP engines, off the MLC clock. | Removes eligible cycles from the R4HA. | Verify zIIP is not saturated and spilling to GP. |
| Pricing model selection | WLC, AWLC, or Tailored Fit Pricing matched to the actual profile. | Structural, can reset the whole run rate. | Multi year, hard to reverse; model both ways. |
Ranges are indicative patterns we observe, not guarantees. Actual recovery depends on the shape of your own R4HA, which is why every engagement starts from your SCRT data.
One spike, thirty days of charge.
Take an LPAR whose normal R4HA sits near 800 MSU but spikes to 1,000 MSU for a single four hour window each month when a heavy batch run overlaps the online peak. Sub-capacity MLC for that product bills on the 1,000 MSU peak, not the 800 MSU it runs the rest of the time. The extra 200 MSU of billable capacity is bought for thirty days to cover four hours.
Soft capping the LPAR at, say, 850 MSU, or rescheduling that batch run two hours earlier, holds the billable peak near 850 rather than 1,000. That is roughly a 15% reduction in the peak that sets the charge, with the same work completed and no application changed. Applied across several products on several LPARs, peaks that were independently inflating each bill come down together. The recovery is real, repeatable, and invisible to the business.
The discipline is continuous, not one time. R4HA drifts back up as the estate grows, so the levers are monitored and re tuned each cycle. That ongoing management is the core of our MSU optimization and cost optimization work, and it feeds directly into every IBM renewal we run.
④ What changes with us in the room
IBM reads your SCRT file every month. We read it first.
Typical MLC recovered through peak management
Engagements delivered since 2019
Mainframe spend negotiated on the buyer side
Yes. MLC bills the rolling 4 hour average MSU peak, not total work. Shaping the peak through soft capping, moving eligible work to zIIP, or moving to a pricing model that fits the profile all lower the bill without an application rewrite. Soft capping and peak management commonly recover 10 to 20%.
The highest sustained four hour window of MSU consumption per product in a month, captured by SCRT from your SMF records. Sub-capacity MLC bills on that single peak, so one spike, often batch overlapping online prime time, can set the charge for the whole month. Shape the peak, not the total. See our R4HA explainer.
It is widely used, but model it before applying it. A cap too low starves the workload; too high protects nothing. Simulate candidate caps against historical SMF data to find the level that trims the billable peak without breaching service levels, then monitor continuously. On your own measured data it is routine.
Only if the profile fits. It replaces peak based billing with a capacity or consumption subscription, which suits stable or growing, predictable estates. For volatile or declining usage it can lock cost above disciplined R4HA management. Model both before committing, since the move is multi year. Our Tailored Fit Pricing explainer lays out the math.
Related: IBM licensing hub · IBM cost optimization · MSU optimization service · consolidating MLC and IPLA
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →