The eligibility rules, and the four obligations you take on in exchange for the smaller number. Three knowledge checks along the way, and 4 clips from a senior licensing analyst.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. 4 times in the session the frame splits and a senior licensing analyst gives the view from inside real IBM negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome to session seven. Last time we established that full capacity is the default, and I left you with a promise that there is a cheaper count available and that you have to earn it. Today is how you earn it. Sub capacity is the largest single discount IBM gives, larger than anything you are likely to negotiate, and it is not a discount at all in the ordinary sense. Nobody grants it to you in a meeting. It is a qualification, it has four conditions, and you hold it for exactly as long as you keep meeting them. Three knowledge checks. Let's begin.
Five objectives. First, recite the four obligations, which are an eligible product on an eligible technology, the tool within ninety days, kept current, and reported quarterly and retained for two years, and miss any one of them and the count is full capacity. Second, check eligibility rather than assume it, because both lists are published by IBM, both change, and a technology not on the list does not support sub capacity regardless of how well it caps cores. Third, start the ninety day clock correctly, because it runs from the first eligible deployment anywhere in the estate rather than from when the software asset team was told. Fourth, treat the reports as the exhibit, because an audit tests two years of report history rather than the install date. And fifth, name the approved alternatives, because only a short list substitutes for the tool, containers report through a different service, and manual counting ended in May 2023.
Four numbers that frame the bargain. Forty five to sixty five percent, the PVU reduction a compliant tool delivered on virtualised hosts, and on dense estates the published range runs higher still. Four legs, because the obligations hold together as a chain, eligibility is only as strong as its weakest quarter, and one broken leg drops the whole count rather than a quarter of it. Ninety days, the window to have the tool live after the first eligible deployment, after which the discount is unearned for the period you cannot prove. And one in three, the share of estates carrying a gap that exposed full capacity for at least one month, which tells you the gap is normal, and normal is exactly why it is worth checking your own. The note underneath is the sentence I would put on the wall. The tool is free. The discipline is the price of the discount.
Guest analyst clip. I want to reframe something before you go any further, because the word discount is doing damage here. When people hear that sub capacity saves half the count, they file it mentally alongside every other discount they have ever been given, which means they file it as something the vendor granted and the vendor could take away in a negotiation. That is not what this is. Sub capacity is a right you qualify for by doing four specific operational things, and IBM has no discretion over it at all. If you meet the conditions, you have it, and no account manager can price it away from you. If you do not meet them, you do not have it, and no account manager can give it back either. Which cuts both ways, and the second half is the half that costs money. There is nobody to appeal to. What I find is that once a room understands this properly, the conversation changes shape entirely. It stops being about IBM's goodwill and starts being about whether an internal process runs every quarter. And that is a far better problem to have, because it is one you control completely.
There is nobody to appeal to, in either direction. So the whole question becomes whether an internal process runs every quarter, and here is what that process has to satisfy.
The four obligations, and what breaking each one costs. An eligible product on an eligible technology, where both lists are published by IBM and both change, and if you fall outside either one the product is full capacity whatever your tooling shows. The tool live within ninety days, measured from the first eligible deployment in the estate, and if you miss it the discount applies from installation forward and never backward. Kept current, meaning new hosts get agents, upgrades get applied and coverage gets verified rather than presumed, and every unscanned host is a full capacity host on its own. And reported quarterly and retained for two years, generated, reviewed, signed and filed, and without the exhibit there is no discount for the whole unproven period. Read them as a chain rather than a checklist. Eligibility is only as strong as its weakest quarter, and the audit will find that quarter rather than your best one.
Knowledge check one. Your tool is deployed, current and scanning everything, but nobody has generated a report in fourteen months. What is your position? A, sub capacity, because the tool has the data and the reports can be produced on request. B, full capacity for the unreported period, because the report is what converts scan data into a licence position. C, sub capacity, provided the tool is current at the time of the audit. D, undetermined until IBM specifies which quarters it wants. Pause here, and ask which of these an auditor can actually be shown.
The answer is B. The obligation is to generate the report at least quarterly and retain it, and a report you could theoretically produce is not a report you produced. Answer A is the most common belief in the room, and it fails on what looks like a technicality and is not one, because the position cannot be rebuilt backward at audit time. A report generated today describes today. It does not describe the second quarter of last year, and the second quarter of last year is what you are being asked about. Answer C misreads which moment matters, since the audit tests the history rather than the state of the tool this morning.
So, eligibility, which is two lists. The product list covers the middleware and database families you would expect, WebSphere, MQ, DataPower, Db2 enterprise editions, Informix, Tivoli, and selected Cognos and SPSS editions. The technology list covers VMware, PowerVM, Hyper V, KVM and Solaris Zones, and here is the rule people trip on, a technology not on the list does not support sub capacity regardless of how well it caps cores. Some products are full capacity only, and licensing one of those as sub capacity creates a gap that surfaces in an audit, so where a product is full capacity only you plan the deployment to limit physical cores instead. Containers sit outside the tool entirely, because Cloud Pak and containerised deployments meter Virtual Processor Cores through the IBM License Service, since the inventory tool cannot see inside Kubernetes. So check rather than assume. Both lists change, an eligibility error is silent, it costs nothing to make, and it has put five to twelve percent of products at full capacity without the team knowing.
Now the ninety day window, five points. The rule is that the measurement tool must be deployed and live on eligible servers within ninety days of the first sub capacity eligible installation. Where the clock starts is the part that catches people, because it starts at that first eligible deployment anywhere in the estate, not at the software asset team's convenience, and not when the project that installed the product got round to telling anybody. Installation fixes the future and not the past, so a tool installed late earns the discount from installation forward while the uncovered period stays uncovered, permanently, assessed at full capacity. Which makes this the one deadline in this session worth memorising, because almost every other control here can be repaired and this one cannot, since you cannot retrospectively have measured something. And it applies to every new environment, because a new eligible product, in a new estate, after an acquisition, restarts the question.
Guest analyst clip. The acquisition case is where I have seen this hurt most, and it is worth understanding because it is entirely predictable and almost never predicted. You buy a company. Somewhere in the diligence pack there is a line about software licences, and it says the target holds perpetual licences for various IBM middleware, which is true. What the pack does not say, because nobody asked, is whether the target ever deployed the measurement tool. And if it did not, then every eligible product in that estate has been running at full capacity, on paper, for however many years it has been there. You did not create that exposure. You bought it, and you bought it without pricing it. Now the practical part. This is a diligence question, and it is a cheap one. It is two lines in a questionnaire: is the sub capacity measurement tool deployed, and can you produce the last eight quarterly reports. If the answer to either is no, you have found something before it becomes yours, and the time to price it is while there is still a negotiation happening. I have watched organisations do thorough technical diligence on an acquisition and never ask those two questions, and then meet the answer three years later in an audit letter.
Two lines in a diligence questionnaire. Is the tool deployed, and can you produce the last eight quarterly reports. Cheap to ask, expensive to inherit unasked.
Knowledge check two. You acquire a company running WebSphere on VMware. It has never deployed the measurement tool. You deploy it within ninety days of the acquisition. What is the position? A, clean, because the ninety day clock started when you acquired the estate. B, the prior period stays exposed, because the clock started at their first eligible deployment, not at the acquisition. C, clean, because the previous owner carries the liability. D, full capacity permanently, because the window was missed once. Pause here, and ask what event starts the clock, and who the obligation follows.
The answer is B, the prior period stays exposed. Deploying the tool now is exactly the right move and it fixes everything from today forward, which is why answer D is too pessimistic, and I want to be clear about that because the instinct after a bad finding is to assume the position is unrecoverable and it is not. What deploying cannot do is prove a period nobody measured. Answer C is the assumption worth testing in every acquisition, because the exposure usually travels with the software rather than staying with the seller, and that makes it a diligence question rather than a licensing one.
The third obligation is the one that decays quietly. Every new host needs an agent, and the full capacity trap almost never comes from a missing tool, it comes from a new host added without the reporting agent months after everybody declared the project finished. Every unscanned host stands alone, because coverage is not an average, so a host outside the scan is a full capacity host for the products on it whatever the other four hundred hosts are doing. Disaster recovery hosts count, since a DR host running an eligible product needs the agent and the entitlement even when the workload is idle, and a failover onto an uncovered host is a finding waiting to be discovered. Agents decay without anybody deciding, because operating system patching breaks agents nobody monitors and the reports keep generating from stale data, which looks like health right up until it is examined. So hold a coverage number, ninety eight percent or better, with every gap treated as an incident rather than a backlog item, because drift on new hosts has gone uncaught for one to two quarters on most estates.
Guest analyst clip. The failure mode I would most want you to picture is not the tool being down, because a tool that is down gets noticed. It is the tool that is up, generating reports on schedule, looking entirely healthy, and reporting on a shrinking fraction of your estate. Think about what that looks like from a monitoring dashboard. Green. The scheduled job ran. The report was produced. Nothing alerted, because nothing failed. Meanwhile forty hosts were built last quarter from an image without the agent, and the report is a beautifully formatted document about the hosts that still have one. And here is the part that makes it dangerous rather than merely untidy: every one of those quarterly reports is now evidence, and it is evidence for a smaller estate than you actually run. So the control is not, is the tool working, which is the question everyone asks. It is, does the tool's host list match the hypervisor's host list, which is a comparison, and comparisons are the thing nobody schedules. Run that comparison once and I promise you will find something. Run it every quarter and you will stop finding things, which is the point.
The question is not whether the tool is working. It is whether the tool's host list matches the hypervisor's, and that is a comparison nobody schedules.
The fourth obligation is the exhibit, and it has five parts. Quarterly at minimum, because the report is what converts scan data into an auditable licence position, and the quarter is the contractual floor rather than a target to aim at. Two years of history retained, because generation without retention earns nothing, and reports had been generated but not retained on two estates in five, which breaks the trail as thoroughly as never running the tool at all. Signed by somebody accountable, since an internal sign off each quarter by the IBM software owner is the cheapest single control against audit risk, and three signatures on a summary costs about an hour a quarter. Watch the upgrade, because tool upgrades are the moment most enterprises lose their historical reports, so the export and the archive happen before the upgrade rather than after it. And keep them findable, a rolling two years where an audit response team can produce them within days, because a report you cannot locate in the window you are given is a report you do not have.
Now the alternatives, because people always ask whether they have to use IBM's own tool. Two accepted substitutes exist, HCL BigFix Inventory and Flexera One with IBM Observability ITAM, and a third party discovery tool you already own almost certainly is not one of them. There is a lighter path for smaller estates, since the disconnected scanner variant is pre approved under five thousand virtual machines or partitions, which covers a great many estates that assumed they needed the full deployment and quietly did nothing instead. Containers report elsewhere, through the IBM License Service with its own snapshot and retention duties, so moving workloads into containers does not escape the obligation, it adds a second one. Manual counting has ended, on the first of May 2023, so without an approved tool the position is full capacity and a spreadsheet is not a defence. And changing tools never changes obligations, because the ninety day window, the scan cadence and the quarterly signed report apply identically to every approved path.
Knowledge check three. An auditor challenges your sub capacity position. What decides the argument? A, a clear technical explanation of how your virtualisation caps the workload. B, the retained quarterly reports covering the disputed period. C, the current state of the tool at the time of the audit. D, the commercial relationship and your spend history with IBM. Pause here, and ask which of these can actually be produced as evidence for a period that has already passed.
The answer is B, the retained quarterly reports. Sub capacity is granted as an exception you continuously earn, which means IBM does not have to prove you owe full capacity. You have to prove you earned the discount, quarter by quarter, with reports you still possess. Answer A is the one people reach for and it never works, and I want to say why with some sympathy, because the technical explanation is usually correct. The workload really was capped. The engineering really was sound. It just is not evidence of anything for a period that has passed. Nobody was ever saved from a full capacity finding by a good explanation. They were saved by eight quarterly reports in a folder.
Guest analyst clip. Eight quarterly reports in a folder. I keep coming back to that image because of how unglamorous it is, and I think the unglamorousness is precisely why organisations underinvest here. Consider the asymmetry. Producing and filing a quarterly report is perhaps an hour of somebody's time, four times a year, so call it half a day annually. The thing it protects is a discount worth roughly half your PVU count across a virtualised estate, and in the settlements I have seen, the gap between having those reports and not having them is measured in millions rather than in percentage points. There is almost nothing else in enterprise software with that ratio. And yet it is nobody's favourite work. It does not get presented to a board. It does not appear in anybody's objectives. So it gets skipped, quietly, for a quarter, and then for a year, and the estate does not feel any different, right up until a letter arrives. What I say to clients is: this is not a compliance task, it is a treasury task. You are buying an option on a very large number, and the premium is half a day a year. If somebody put that in front of you as an investment you would sign it immediately.
So here is how estates that keep the discount actually run, five things. A named owner with a financial mandate rather than only an operational one, because the tool that belongs to nobody is installed by a project, inherited by no team, and discovered broken by an audit. The agent in the gold image, so new hosts arrive covered rather than getting covered, which turns the hardest obligation into a build standard instead of a chase. A quarterly close in the calendar, meaning generate, review, sign, export, archive, on a date that exists before the quarter starts and with a name against it. Coverage monitored as an incident class, so a host that stops reporting raises a ticket that week, because the alternative is discovering it two audits later. And eligibility re checked annually, because both lists change, estates change faster, and an hour a year against the published lists is the cheapest item in this entire course.
Three sentences. Sub capacity is four obligations rather than a setting, an eligible product on an eligible technology, the measurement tool live within ninety days of the first eligible deployment, kept current on every host including disaster recovery, and reported at least quarterly with two years of reports retained. The obligations behave as a chain rather than a checklist, so eligibility is only as strong as its weakest quarter, and the position cannot be rebuilt backward at audit time because installation fixes the future and not the past. And the discount is worth forty five to sixty five percent of the PVU count on virtualised hosts while the tool itself is free, which means what estates actually fail to pay is the discipline, and the discipline is an owner, a build standard and a date in the calendar.
Homework, about an hour. Read the original wording, so open the current Passport Advantage terms and read the four sub capacity obligations as written, because a summary is not the contract and this one is short enough to read properly. Find your report archive, and ask for the last eight quarterly reports, not the tool, the reports, then note how many arrive and how long it took somebody to find them. Check one host that is not there, by comparing the tool's host list against the hypervisor's, because the difference is your coverage gap and it is usually larger than the coverage number people quote. Check two products against the lists, confirming that both the product and its virtualisation technology appear on the published lists today rather than when somebody last looked. And name the owner, asking whether they have a financial mandate or only an operational one, because if the answer is that the tool belongs to a project, that is your finding.
Five guides. IBM sub capacity licensing and ILMT compliance sets the four conditions out as a chain, explains why full capacity is the default rather than a penalty, and prices what a broken quarter costs. The PVU sub capacity licensing guide covers the eligible technologies, the products that are full capacity only, and the measured saving on virtualised hosts. And the ILMT comprehensive pillar takes the tool end to end, including the retention question and why most failed audits are deployment failures rather than licensing decisions.
The deploy and configure guide gives you the seven rules of sub capacity entitlement, the five common audit findings and the disaster recovery trap, and it is the natural companion to next session. And the audit defence playbook explains what the evidence trail is worth in a settlement, and why remediation before the letter is priced so differently to remediation after it. Next time, the tool itself: deployment, the scan cadence, the quarterly report, the two year retention, and the five failures that create findings. See you there.