Linux on IBM Z: priced by the IFL, not the MSU.

Linux on IBM Z is enterprise Linux running natively on the mainframe, on a dedicated processor pool called the Integrated Facility for Linux (IFL). It lets an organization consolidate distributed Linux workloads onto the same hardware that runs z/OS, with the reliability and density of the platform, while keeping the Linux estate out of the z/OS software accounting. The distributions are the familiar ones, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, and Ubuntu, and the stack supports z/VM, KVM, and Red Hat OpenShift for virtualization and containers.

The metric is the IFL core, not the MSU. The Linux distribution is licensed per IFL by its vendor on a subscription, the middleware that runs on Linux on Z is commonly licensed by IFL count, and IBM programs for Linux on Z follow the same engine based logic, with sub-capacity terms available for some products. Because IFLs carry no MSU rating and do not change the machine model designation, none of this touches the general purpose MSU figure that SCRT reports for z/OS. The Linux estate is a parallel licensing world on the same iron, counted in cores.

The IFL keeps Linux growth off the MLC bill. To see how the z/OS side is counted instead, read the MIPS to MSU conversion question and sysplex vs standalone pricing.

The dominant driver is the number of licensed IFLs, since the distribution, the middleware, and the IBM programs all scale with engine count. The second is the software stack layered on each IFL: a database, an application server, or a monitoring product on top of Linux each adds its own per core stream. The third is the full capacity versus sub-capacity question, which on a machine with many IFLs is the difference between licensing the workload and licensing the whole engine pool. The fourth is virtualization density: how many IFLs you actually need depends on how well z/VM or OpenShift packs the workload, so capacity planning is a direct cost lever here.

The IFL world has its own exposures, distinct from MLC. Common traps we see at pattern level:

Because the bill scales with cores, the levers all work on the IFL count and the stack. The five that pay:

For the platform itself the alternative is distributed x86 or cloud Linux, and the trade is real but not a renewal tactic: the case for Linux on Z rests on consolidation density, resilience, and colocation with z/OS data, and unwinding it is a migration program. Within the platform, the credible moves are at the distribution and middleware layers, where Red Hat, SUSE, and Ubuntu genuinely compete and where open source middleware can displace a licensed stack. Treat the platform decision as strategic and the layer decisions as the negotiable ground.