Monthly License Charge (MLC) Explained.

MLC covers a family of IBM Z products, z/OS, CICS, Db2 for z/OS, IMS, and MQ among them, charged monthly rather than bought outright. The metric is the MSU, a measure of processing capacity. Under sub-capacity terms, IBM calculates a rolling four hour average of MSU usage, recomputed every five minutes from twelve five minute samples per hour. Each month the Sub-Capacity Reporting Tool identifies the single highest rolling four hour average hour for each product, and that peak MSU figure is what IBM prices.

Two properties make MLC behave unlike most software cost. First, it is a peak metric: a handful of hours, often a month end batch window, can set the entire monthly charge regardless of how quiet the other seven hundred hours were. Second, the rate table is regressive: the per MSU price falls as capacity rises, so the marginal MSU at the top of a large estate costs far less than the first MSU. Both properties are levers once you can see them, and traps when you cannot.

Directional only, using illustrative per MSU figures to show the mechanic, not a quote. A machine rated at 1,500 MSU runs a workload whose measured peak rolling four hour average is 1,000 MSU. The full capacity basis bills the rated machine; the sub-capacity basis bills the measured peak.

Illustrative relative cost, regressive tiers applied to the blended rate. Not pricing.

Moving from full capacity to a clean sub-capacity position removes roughly a third of the bill in this example, which is consistent with the 30 to 50 percent range commonly observed when disciplined sub-capacity reporting replaces full capacity. Shaving the peak a further 10 percent, by moving non urgent batch out of the peak hour, takes more off again. None of it touches IBM's rate. It all acts on the billable MSU.

MLC exposure concentrates in a few failure modes. Lapsed or incomplete SCRT submissions risk reverting to full capacity, the most expensive basis, and an audit with unreliable data lands the same way. Peak creep is the quieter cost: a single new batch job or a poorly timed report scheduled into the existing peak window can lift the rolling four hour average for the month, repricing the whole stack on one hour of work. And because the tiers are regressive, capacity decisions made without modeling the curve can leave money on the table at the margin.

Every MLC lever acts on the peak rolling four hour average. Shift non urgent batch and reporting out of the peak window so it never contributes to the billed hour. Set defined capacity, soft capping, on LPARs to hold the rolling four hour average below a ceiling you choose. Offload eligible work to the zIIP engine, which does not count toward the general purpose peak. Keep SCRT submissions clean and on time so sub-capacity holds. And model the regressive tiers before any capacity change. For estates moving to consumption pricing, weigh MLC against IBM Tailored Fit Pricing, where the baseline window replaces the monthly peak as the thing to manage.

Where MLC products are licensed: z/OS licensing. Related metric work: MSU consumption optimization and zIIP offload. Put it to work: IBM cost optimization.