Sub-capacity eligibility by IBM product.
Sub-capacity licensing lets you pay for the virtual cores running IBM software instead of the whole physical host. But eligibility is conditional, and it turns on the product, the virtualization technology, and the tooling behind it. Here is how to read it before an audit reads it for you.
The single largest swing in most IBM audits is the gap between full-capacity and sub-capacity charging. License only the four cores a product touches on a thirty two core host and you owe a fraction of the bill. License the whole host because the eligibility conditions were not met and the number multiplies. Whether you land on the right side of that gap depends on conditions that are decided long before the auditor arrives.
Eligibility is not a property of the product alone
It is common to ask whether a given product "is sub-capacity eligible," but eligibility is really a set of conditions that all have to hold at once. A product that qualifies on paper still defaults to full-capacity charging if the tooling or the platform is wrong. Three layers decide it.
Layer one: the product is on the eligible list
Most of the high-risk middleware products that draw audits are eligible for sub-capacity terms under Passport Advantage: WebSphere, Db2, MQ, Cognos, Maximo, and the broader Tivoli family among them. Eligibility is published per product, so it is checked product by product rather than assumed across a portfolio. A small number of products and editions are full-capacity only, and treating one of those as sub-capacity eligible is a self-inflicted finding.
Layer two: the platform is eligible technology
Sub-capacity only applies on virtualization technology IBM recognizes as eligible. Run an eligible product on an ineligible platform, such as an old server release outside the eligible technology list, and the sub-capacity claim is void for that environment regardless of the product. Each hypervisor also has its own counting rule, so the same product can be sized differently on Power LPAR, on VMware, and in public cloud.
Layer three: the tooling is in place and current
Sub-capacity requires the IBM License Metric Tool, or an approved alternative such as Flexera One ITAM or HCL BigFix Inventory, deployed within 90 days of first eligible deployment, running continuously, with quarterly reports retained for two years. Miss any one of those and IBM is entitled to default the environment to full-capacity charging for the affected period.
WebSphere using 4 of 32 host cores is 480 PVU under sub-capacity. The same deployment defaulted to full-capacity is 3,840 PVU, eight times the number, purely because an eligibility condition was not met. The product never changed. The paperwork did.
How we read eligibility under audit
- Confirm each in-scope product against the published eligible product list rather than assuming portfolio-wide eligibility.
- Map every deployment to its platform and apply the correct counting rule for that hypervisor.
- Verify ILMT or an approved tool was deployed in time, ran continuously, and has the quarterly reports retained for the lookback period.
- Where a condition slipped, scope the exposure to the specific environment and period rather than letting IBM apply full-capacity across the estate.
Most full-capacity findings we see are not genuine over-deployments. They are eligible products that lost their sub-capacity standing on a technicality, and the standing is often recoverable with the right evidence and a corrected reporting record.
Sub-capacity eligibility is a chain of three conditions: an eligible product, eligible virtualization technology, and current tooling with retained reports. Break any link and IBM charges full-capacity for that environment. Establish all three before the data leaves your network and the position holds at the sub-capacity number.