IBM Z systems licensing: MLC, IPLA, sub capacity, and Tailored Fit Pricing.

IBM Z and the mainframe licensing problem.

IBM Z is the mainframe platform, descended from System 360 and continually updated through every generation since. The current generation, z16, runs at peak instruction throughput on workloads that no other commercial platform competes with. Fortune 500 customers in banking, insurance, retail, government, healthcare, and transportation continue to rely on Z for transaction processing, batch processing, and high value middleware. The mainframe is therefore one of the largest single cost lines on the IBM bill at most of these customers, often comparable to the entire distributed Passport Advantage portfolio.

Mainframe software licensing is structurally different from distributed software licensing. Two distinct programmes apply: Monthly Licence Charge (MLC) for the IBM control and supporting products including z/OS, and International Programme Licence Agreement (IPLA) for most middleware and tool products on the mainframe. Each programme has its own metric, its own sub capacity rules, its own audit profile, and its own discount mechanics.

This article works through both programmes from the buyer side. For mainframe in the broader cost optimization context see the IBM Cost Optimization Guide and the mainframe expertise page. We work as an independent firm. We are not an IBM Business Partner, reseller, or affiliate, and we hold no resell margin on any mainframe product.

Monthly Licence Charge programme.

MLC is the programme under which z/OS, CICS, IMS, Db2 for z/OS, MQ for z/OS, and a number of other Z products are sold. MLC products are metered in Million Service Units (MSU), a measure of mainframe processor capacity. The customer pays a monthly fee that scales with MSU consumption. Sub capacity rules permit measurement at the LPAR rather than CEC level and at the four hour rolling peak rather than the all hours peak.

The Workload Licence Charge (WLC) variant of MLC, and the Advanced Workload Licence Charge (AWLC) variant, are the typical pricing models on modern Z hardware. Both are sub capacity programmes. The four hour rolling peak across the month, by LPAR group, is the billing measure. The buyer side discipline is to minimise this peak through workload management.

Tailored Fit Pricing.

Tailored Fit Pricing, introduced in 2019, is the alternative pricing model that prices a customer baseline at a flat rate with overage handled separately. Tailored Fit Pricing trades the variability of peak driven MLC for the predictability of a flat fee, with the trade off that workload growth above the baseline incurs additional cost. The buyer side discipline on a Tailored Fit Pricing decision is to model the three year cost path under both pricing models against the realistic workload profile.

IPLA programme on the mainframe.

IPLA is the programme under which most mainframe middleware (including parts of the WebSphere portfolio on z/OS, Tivoli on z/OS, and a wide range of utilities) is sold. IPLA products are typically licensed on Reference Based Capacity (RBC), which permits sub capacity measurement based on the LPAR utilisation of the product.

RBC requires the customer to deploy the Sub Capacity Reporting Tool (SCRT) or its successor. SCRT collects the capacity utilisation data, generates the audit report, and serves as the evidence base for the IPLA sub capacity bill. The buyer side discipline is to ensure SCRT runs on every LPAR, that the reports are retained, and that the LPAR configuration matches the report.

IPLA products carry Subscription and Support similar to distributed software. The customer pays an annual S and S fee that maintains the perpetual licence. The harvest move is the same as on distributed: drop S and S on shelfware IPLA entitlement at the next anniversary, and reinstate later if needed. See IBM Software Subscription and Support.

zCAP and Container Pricing.

Container Pricing and the related zCAP programme allow a customer to consolidate workloads into a container for licensing purposes, with the container priced as a unit. The container approach can reduce mainframe software cost on specific workload patterns. The buyer side discipline is to model the container price against the conventional MLC and IPLA path on the workload in question.

Specialty engines and zIIP, zAAP.

Specialty engines are processor types that execute specific workloads at a reduced or zero MLC cost. zIIP processes selected workload types (including some Db2 and Java workloads). The buyer side opportunity on specialty engines is to maximise the workload routed to zIIP, which reduces the general purpose processor utilisation and therefore reduces the MLC peak.

The discipline on specialty engines is operational. The application portfolio must be tuned to route eligible workloads to zIIP. The capacity planning must ensure adequate specialty engine capacity to absorb the routed workload. The buyer side preparation is to inventory zIIP eligible workloads, measure current routing, and identify routing gaps where additional zIIP capacity would pay back through MLC reduction.

Specialty engines are hardware features and carry hardware acquisition cost, but they carry zero MLC charge on the workload routed to them. The hardware cost is paid back through the MLC saving when the routing is optimised.

Z hardware refresh and capacity sizing.

Z hardware refresh is a substantial event, typically every five to seven years. The new generation provides more capacity per MSU, which means the same workload consumes fewer MSUs on newer hardware. The buyer side discipline on hardware refresh is to capture the MSU saving as part of the refresh business case rather than absorbing it into capacity headroom.

The capacity sizing question at refresh is the projected MSU baseline. IBM proposes sizings that incorporate growth headroom. The buyer side discipline is to verify the sizing against the realistic workload projection, including the impact of any application modernisation, workload offloading, or workload retirement that is committed for the refresh period.

The hardware refresh negotiation is also the natural point to renegotiate Z related multi year commitments, including any Tailored Fit Pricing arrangement, any Container Pricing arrangement, and any IPLA S and S commitment that has accumulated shelfware over the prior cycle.

Z at renewal and through the year.

Z has continuous billing rather than annual renewal on the MLC side. The monthly MLC bill arrives every month and reflects the four hour rolling peak on the prior month. The buyer side discipline on MLC is operational: peak management, workload shifting, and specialty engine optimisation. There is no annual renewal lever on MLC equivalent to the distributed S and S harvest.

On the IPLA side, the renewal cycle is annual on the Subscription and Support anniversary, similar to distributed software. The harvest moves are the same: drop S and S on shelfware, decline any IBM proposal to broaden coverage, and align the IPLA anniversary to the broader Passport Advantage anniversary where this is permissible. See Renewal Strategy.

Multi year commitments on Z are common, particularly Tailored Fit Pricing arrangements and container pricing arrangements. The buyer side discipline on multi year is the same as elsewhere: model the cost path at the realistic workload, retain the right to exit, and align the term to the hardware refresh cycle. See Multi Year Strategy.

Z in an IBM audit.

Mainframe audits are less common than distributed audits but they happen. The most common audit findings on Z are SCRT report gaps, LPAR configuration mismatches against the SCRT report, IPLA entitlement gaps where deployed product instances exceed entitled instances, and Container Pricing arrangements where the container scope is disputed.

The buyer side audit defense on Z is to control the SCRT data, document the LPAR configuration explicitly, inventory the IPLA entitlement against the deployed instances, and refuse any IBM proposal to broaden the Container Pricing scope. See IBM Audit Complete Guide and the Audit Defense service page.

Z audits can produce very large settlement exposure because the MSU baseline and the IPLA peak interact, and because the mainframe estate often carries decades of accumulated entitlement. The buyer side discipline is to settle to the verifiable position, not to the IBM proposed position, and to use the settlement as the anchor for the next renewal. See Settlement Negotiation.

Z conclusion and next steps.

Z licensing is the most complex single line on most Fortune 500 IBM bills. MLC, IPLA, sub capacity rules, specialty engines, Tailored Fit Pricing, Container Pricing, and the hardware refresh cycle all interact. The buyer side discipline integrates all of them: peak management on MLC, harvest discipline on IPLA, specialty engine optimisation, hardware refresh negotiation, and continuous SCRT discipline.

For a buyer side advisor on your Z estate see the License Consulting service page or the mainframe expertise page. To talk to a senior advisor see the contact page.