Integrated Facility for Linux Licensing, Explained.

An Integrated Facility for Linux is a specialty processor on IBM Z and LinuxONE dedicated to running Linux and z/VM, where one IFL equals one core. The cost significance is simple: work on an IFL does not consume z/OS MSU and does not attract z/OS Monthly License Charge software charges. That is why eligible Linux workloads are placed on IFLs rather than general processors. The IFL is one of the specialty engines, alongside zIIP and zAAP, that exist precisely to keep certain work out of the MSU based bill.

What changes is the metric, not the existence of cost. Software on IFLs, the Linux distribution subscription, middleware, and ISV products, is licensed per IFL or per core rather than by MSU. Much IBM middleware uses a Processor Value Unit model, and ISV products set their own per core or per IFL terms. The workload leaves the MSU world and enters the per core world, and the two have to be compared, not assumed.

Under a Processor Value Unit model, the entitlement for a middleware product is the PVU per core rating multiplied by the number of cores it runs on. Take a middleware product on an estate of 6 IFLs with an illustrative PVU per core rating of 70, licensed at full capacity:

Input	Value	Calculation
IFL cores	6	Physical cores available to the program
PVU per core rating	70	Illustrative, set by IBM per processor
Full capacity entitlement	420 PVU	6 × 70
Sub-capacity (4 cores virtualized)	280 PVU	4 × 70
Entitlement avoided by sub-capacity	140 PVU	The reporting requirement earns this

Illustrative PVU rating for arithmetic only. Real per core ratings are set by IBM per processor model and vary; ISV products use their own metrics.

Two lessons sit in that table. First, IFL software cost scales with cores, so an oversized IFL pool licensed at full capacity pays for cores the workload may not need. Second, sub-capacity (also called virtualization capacity) licensing lets you license only the cores made available through virtualization, here 4 instead of 6, but only if you maintain the tracking and reporting the vendor requires. Skip the reporting and full capacity applies by default, which quietly hands back the saving. The per core world has its own version of the same discipline the MSU world demands.

There is no single IFL licensing metric. The stack on a Linux LPAR can mix several, and knowing which applies to each product is half the cost control.

Model	Unit	Where it shows up
Per IFL / per core	Each IFL core	Linux subscriptions, simple per core ISV terms
Processor Value Unit (PVU)	Cores × PVU rating	Much IBM middleware on Linux on Z
Full capacity	All available cores	Default where sub-capacity is not tracked
Sub-capacity / virtualization capacity	Virtualized cores only	Where reporting is maintained

ISV products on Linux on Z frequently set bespoke per core or per IFL terms, so the contract governs, not a single industry rule.

The trap is mixing the saving on one metric with a cost on another. Moving a workload to IFLs to escape MSU is sound, but if the workload drags a heavy middleware stack licensed per core, the per core bill can erode much of the MSU saving. The decision is never IFL or not in the abstract. It is this specific workload, with this specific stack, priced both ways, with sub-capacity claimed where the reporting supports it. For the broader Linux on Z and LinuxONE pricing picture, see software pricing on LinuxONE.

Across 500+ engagements and $180M+ of negotiated mainframe spend, IFLs are a genuine cost lever when the per core stack is priced as carefully as the MSU saving that justified the move. The estates that disappointed were the ones that treated escaping MSU as the end of the analysis rather than the start of a second one. The core based bill is real, and it is just as movable as the MSU based one.