IBM Power licensing: activation, AIX, Enterprise Pools, and middleware.

IBM Power and the licensing question.

IBM Power Systems is the brand for the AIX, IBM i, and Linux on Power server line. Power is one of the longest running IBM platform businesses and remains material at many Fortune 500 customers, particularly in banking, insurance, retail, manufacturing, and government. Power is not a software product line in the same sense as Db2 or WebSphere. It is a hardware platform with operating system and middleware licences attached. The licensing question on Power is therefore the integrated cost of the platform: hardware acquisition, AIX or IBM i operating system entitlement, IBM middleware entitlement on the platform, sub capacity discipline through ILMT, and the Power specific concepts of activated cores, CoD, and Power Enterprise Pools.

This article works through the Power specific licensing concepts from the buyer side. It does not duplicate the more general PVU and sub capacity articles; for that material see PVU Explained and Sub Capacity Explained. It focuses instead on the cost levers specific to the Power platform: activation, CoD, Power Enterprise Pools, AIX entitlement, and the renewal mechanics that apply to mainframe class hardware refresh cycles. For mainframe see MQ and the upcoming Z Systems coverage.

We work as an independent firm. We are not an IBM Business Partner, reseller, or affiliate, and we hold no resell margin on any Power hardware or software.

Activated cores and Capacity on Demand.

A Power server ships with a physical core count and an activated core count. The activated core count is the number of cores enabled by IBM for use, set by the activation entitlement the customer purchases. Cores that are physically present but not activated are dark cores: they sit on the silicon but are not available to the operating system. Activation is the first cost lever on Power.

Capacity on Demand, abbreviated CoD, is the IBM mechanism that allows activated core count to be increased temporarily or permanently. Permanent CoD adds activated cores to the system for the life of the system. Temporary CoD activates additional cores for a day count or processor day count purchased separately. Power Enterprise Pools extend this concept across multiple systems.

The buyer side discipline on activation is to right size the activated core count to the actual workload, not to the worst case projection. Customers commonly buy more activation than they actually use, sometimes because the original sizing was conservative, sometimes because the workload was projected to grow and did not, sometimes because a migration consolidated workloads onto fewer activated cores than was originally planned. The activation excess sits on the system for the life of the system unless explicitly addressed.

Power Enterprise Pools and shared capacity.

Power Enterprise Pools allow a customer to pool processor and memory entitlement across multiple Power systems. The pool entitlement is consumed by any system in the pool, providing flexibility in capacity allocation and supporting high availability strategies. Power Enterprise Pools 2.0, introduced in 2020, extends this with a pay per use model on a defined base.

The buyer side discipline on Power Enterprise Pools is to compare the pool cost path to the alternative of fixed per system activation. Pools cost more on the base, but they may save activation cost across the estate if the pool sizing is materially less than the sum of per system worst case sizings. The break even point is workload pattern specific. A customer with synchronised peaks across many systems will not benefit; a customer with offset peaks across many systems will benefit substantially.

Enterprise Pools negotiation moves include pool size optimization, pool composition optimization (which systems are in the pool), and pool term length. The buyer side preparation is to model the three year cost path under fixed activation and under pool activation at the realistic peak pattern, not the worst case pattern. See Multi Year Strategy.

AIX entitlement on Power.

AIX is the IBM Unix operating system and the dominant operating system on Power systems in Fortune 500 estates. AIX is licensed per processor core, with entitlement tied to the Power system on which it runs. AIX has a Subscription and Support stream similar to other IBM software, and the renewal mechanics are similar.

The buyer side discipline on AIX is to align the AIX entitlement to the active core count and to harvest excess entitlement when the active core count is reduced. AIX entitlement that exceeds active core count is shelfware, and the S and S stream on shelfware AIX is a recoverable cost.

A particular cost lever on AIX is the migration of workloads from Power to Linux on x86 or to public cloud. As workloads migrate off AIX, the AIX entitlement should be harvested at the next renewal. We routinely find AIX entitlement preserved on contracts for years after the underlying workloads migrated away. The harvest move at the next renewal can recover material annual S and S cost. See IBM Shelfware Recovery.

IBM i on Power.

IBM i, the operating system descended from AS/400 and OS/400, is licensed in tiers tied to the Power hardware. IBM i deployments are typically more stable than AIX deployments and are often tied to long running ERP and manufacturing workloads. The harvest opportunity on IBM i is more limited than on AIX, but it does exist where customers have over sized IBM i entitlement at hardware refresh.

IBM middleware on Power and sub capacity.

IBM middleware running on Power (Db2, WebSphere, MQ, Cognos, and the rest of the Passport Advantage portfolio) is licensed under the same metrics that apply on x86 or Linux. PVU is the most common metric. Sub capacity eligibility applies to most middleware products. ILMT is the discipline that enforces sub capacity. The middleware cost on Power tracks PVU consumption, which tracks activated core count weighted by the PVU per core ratio for the Power processor.

Power processors have varying PVU per core ratios depending on processor generation and configuration. Newer Power generations typically carry lower PVU per core ratios than older Power generations for many product lines, which means the same workload consumes fewer PVUs after a Power hardware refresh. The buyer side move on hardware refresh is to model the PVU consumption change and to claim the saving as part of the refresh business case. See PVU optimization and PVU Explained.

Power at renewal and refresh.

Power has two renewal cycles. The hardware refresh cycle is typically three to five years, driven by the technology roadmap and the depreciation cycle. The software Subscription and Support cycle is annual, on the Passport Advantage anniversary date. The buyer side discipline is to coordinate the two cycles to maximise leverage.

At hardware refresh the buyer side moves include right sizing activation, optimising the Power Enterprise Pool configuration, re evaluating the PVU consumption on middleware, harvesting AIX entitlement no longer required, and renegotiating the maintenance contract on the new hardware. The refresh negotiation is also the natural point to renegotiate any multi year commitment that touches Power workloads.

At Subscription and Support anniversary the buyer side moves are the standard harvest moves: drop S and S on shelfware AIX entitlement, drop S and S on shelfware middleware entitlement, and decline any IBM proposal to broaden coverage without a clear business case. See Renewal Strategy.

Power in an IBM audit.

Power workloads attract audit attention because they often run high value middleware in virtualised configurations where sub capacity discipline is required. The most common audit findings on Power are ILMT lapse, missed quarterly retention, virtualisation configurations outside the eligible list, and AIX entitlement gaps where the active core count exceeds the entitled count. See IBM Audit Complete Guide and the Audit Defense service page.

The buyer side audit defense on Power workloads is to control the data the customer provides, narrow the scope to the Power systems and the products in question, dispute any inflated PVU computation, and refuse any reclassification of the virtualisation environment without evidence. The Power virtualisation environment (PowerVM with shared processor pools) is generally on the eligible list, but the configuration details must match the eligible configuration. See VM Virtualization Rules.

Power conclusion and next steps.

Power is a high leverage cost discipline. Activation, Enterprise Pools, AIX harvest, middleware PVU compression at refresh, and disciplined ILMT operation together produce material annual savings. The discipline is integrated rather than fragmented: hardware, operating system, middleware, and contractual cycles must move together. The customer who treats them separately overpays.

For a buyer side advisor on your Power estate see the License Consulting service page or contact us through the contact page.