① Explainer · Licensing concepts
Software on IBM LinuxONE is licensed per IFL core, not by MSU. That puts the whole cost model on a different axis from z/OS Monthly License Charge software, with its own levers and its own audit traps. Here is how core based pricing works, why LinuxONE work stays off the z/OS bill, and a worked per core example.
A different processor, a different meter.
IBM LinuxONE runs Linux and z/VM workloads on the Integrated Facility for Linux, the IFL processor. Software on it, the Linux distributions, middleware, container platforms, and databases, is licensed primarily per core or per virtual processor core, not on the MSU metric that drives z/OS Monthly License Charge software. The IFL carries no MSU rating and does not raise the MSU rating of z/OS workloads on the same machine. So the LinuxONE software bill runs on a separate axis from the traditional mainframe bill, governed by core counts and virtualization rules rather than by a Rolling 4-Hour Average peak.
This separation is the structural reason organizations consolidate distributed Linux onto LinuxONE or onto IFLs in a shared frame: the Linux workload is licensed per core and stays entirely off the z/OS MSU meter, while the underlying engine is one of the specialty engines that sit outside MLC. The levers, and the audit exposure, move from peak management to core counting. This explainer pairs with our IBM audit defense, where core based products are a standard area of scrutiny.
Why the two cost models do not share a lever
| Dimension | z/OS MLC software | LinuxONE software |
|---|---|---|
| Processor | General purpose CP | IFL, dedicated to Linux and z/VM |
| Metric | MSU on the R4HA peak | Core or virtual processor core |
| Reporting | Monthly SCRT submission | Core counts and virtualization records |
| Main lever | Peak shaping, capping, zIIP offload | Core counting, virtual core sub-capacity, consolidation |
| Effect on the other bill | Drives the z/OS bill | Does not touch the z/OS MSU meter |
| Main audit trap | Missed SCRT defaulting to full capacity | All cores counted where sub-capacity not configured |
The core count is the whole question.
Take a container platform on LinuxONE running across a cluster with 16 IFL cores, but the workload is sized to use 6 virtual processor cores. If the product permits virtual core sub-capacity counting and the configuration is documented, you license 6 cores. If sub-capacity counting is not applied, or not evidenced, the same workload can be billed against all 16 physical cores in the host. The work is identical; only the counting basis differs. The illustration indexes the per core charge at 100 units to make the gap visible without quoting vendor pricing.
The units are an index, not vendor pricing, and the gap depends on the product's rules. The structural point holds: on LinuxONE the core count is the bill, so virtual core sub-capacity counting, where the product allows it, is the equivalent of getting sub-capacity right on z/OS. The audit trap is being billed against every physical core because the sub-capacity configuration was never set or never documented.
Know whether each product allows virtual core sub-capacity counting and configure for it where it does. The difference between physical and virtual core counting is the LinuxONE equivalent of full versus sub-capacity on z/OS.
The core count is the bill; count it deliberately.
In a virtualized cluster, affinity and capping keep a workload from exposing more cores than intended. Without them a mobile workload can drift across cores and inflate the licensable count.
A workload that roams is a workload that bills wide.
Linux running on distributed servers and licensed per socket or core can often consolidate onto IFLs at a lower aggregate core count, and stays entirely off the z/OS MSU meter. Model the consolidation as a licensing move, not just a hardware one.
Fewer cores, and none of them on the z/OS bill.
Keep records of the core counts you are entitled to license and the sub-capacity configuration behind them. On a per core metric, the evidence of how many cores you license against is what turns an audit query into a non event.
The core count you cannot prove is the one they will charge.
Primarily per IFL core or virtual processor core, not by MSU. Linux distributions, middleware and container platforms are counted per core across the cluster. The IFL carries no MSU rating and does not raise any z/OS MSU rating.
No. IFL work does not count toward the general purpose MSU that drives z/OS MLC software, and the IFL does not add to the MSU rating. That separation is why Linux consolidates onto LinuxONE without touching the z/OS meter.
Per core counts physical or logical cores; virtual processor core counts the cores assigned to the workload and can count fractionally across a cluster. For products like OpenShift on IBM Z the subscription is core based, with one IFL typically mapping to one core subscription.
Core counting and virtualization scope. Per core software can be billed against all cores in a host unless sub-capacity virtual core counting is allowed and configured. Set affinity and capping, and keep evidence of the core counts you license against.
Related: licensing concepts hub · specialty engines explained · sub-capacity vs full capacity · IBM licensing hub · IBM audit defense
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →