Power is one of the most common homes for WebSphere, and it has a counting rule that trips up teams who think of licensing in terms of utilization. On Power LPAR, IBM does not count the cores WebSphere was busy on. It counts the cores the partition was entitled to use. A core sitting idle inside an allocated partition is still a licensed core. Capacity provisioned for a peak that almost never arrives is capacity you pay for every quarter, and an audit reconciliation surfaces it precisely.
Allocated, not used.
The principle is straightforward once stated plainly: sub-capacity on Power licenses the cores assigned to the partition running the IBM software, regardless of average utilization. If a WebSphere LPAR is given eight cores but typically runs on two, the licensable figure is eight, not two. This is the opposite of how many capacity planners think, and it is why over generous partition sizing is a silent cost. The fix is not to monitor utilization. It is to size and cap the partition to what WebSphere actually needs.
Capped versus uncapped partitions.
How a partition can consume processor matters enormously to the count:
- Capped partitions. A partition that cannot exceed its entitled capacity gives IBM a clear, defensible ceiling to count, which is the position you want.
- Uncapped partitions. A partition allowed to borrow from a shared processor pool can be counted up to the maximum it could reach, which may be the whole pool or the server, far more than its entitled capacity.
- Shared processor pools. The pool boundary becomes the relevant maximum, so an undefined or oversized pool inflates the count for every uncapped partition inside it.
An uncapped WebSphere partition on a large Power server is one of the fastest ways to turn a modest deployment into a server sized charge.
Why ILMT alone does not settle it.
ILMT records the partition configuration it observes, but the licensing outcome depends on how that configuration is set. A partition that was uncapped during the lookback, or sat in an oversized shared pool, will be counted on those terms even if utilization was low. Defending the position means showing the cap, the entitled capacity and the pool definition as they actually stood, and correcting any place where ILMT read the configuration in a way that overstates the count.
On Power, the licensable number is the cores the WebSphere partition could use, not the cores it did use. Idle allocated cores count, and uncapped partitions can be counted to the pool maximum. The buyer side defense is to prove the cap and the entitled capacity for the disputed period, and to confine any genuine gap to the partitions and window the evidence cannot cover.
The buyer side position.
Defending WebSphere on Power means reconciling each partition against its entitled capacity and cap state across the lookback, challenging any full-capacity or pool wide assumption IBM applied to a capped partition, and documenting the configuration that supports the lower count. Where partitions were genuinely over allocated, the result feeds a remediation plan to cap and resize them, and that forward posture is folded into the settlement so the next audit starts from a clean position.