IBM Sub-Capacity Licensing on Mainframe vs Distributed
IBM’s sub-capacity licensing is one of the most misunderstood areas in enterprise IT. Even seasoned IT asset managers find the rules complex and the stakes high.
At its core, sub-capacity licensing allows you to pay for software based on actual usage rather than the full capacity of your hardware—if you follow IBM’s requirements to the letter. Read our ultimate guide to IBM Mainframe Licensing (z Systems): Models, Costs, and Negotiation Tips.
On distributed (x86 or virtualized) environments, sub-capacity compliance hinges on the IBM License Metric Tool (ILMT). On IBM mainframes (z/OS), it revolves around the Sub-Capacity Reporting Tool (SCRT).
Mismanaging either tool can expose your company to being charged at full machine capacity and lead to severe compliance risks. In other words, getting sub-capacity wrong means potentially paying for far more computing power than you actually use.
This guide explains how sub-capacity licensing works on distributed and mainframe platforms, highlights the differences between ILMT and SCRT, and provides practical tips to avoid pitfalls, ensuring you stay protected and avoid unexpected charges on your IBM bill.
After all, IBM software investments are significant, and mastering sub-capacity licensing is key to keeping those costs in check.
Sub-Capacity Defined Across Platforms
Distributed (x86/virtualized):
In IBM’s distributed environments (x86 servers, VMs, cloud), sub-capacity licensing is enforced through the IBM License Metric Tool (ILMT). ILMT monitors the CPU core usage of IBM’s PVU-licensed software on each machine.
To license IBM products on less than the server’s full physical capacity (for example, within a limited CPU virtual machine), you must have ILMT installed and configured. Suppose ILMT isn’t in place or isn’t reporting properly.
In that case, IBM will assume full-capacity licensing – meaning you’re billed as if the IBM software fully utilizes every processor core of that server.
Mainframe (z/OS):
On IBM mainframes, sub-capacity licensing is handled by the Sub-Capacity Reporting Tool (SCRT). SCRT measures the peak usage of eligible mainframe software (in MSUs, or Millions of Service Units) across all logical partitions (LPARs) on a physical machine.
Typically run monthly, SCRT identifies each product’s highest consumption point (peak MSU usage) during the month. IBM then uses that peak to calculate your Monthly License Charge (MLC) bill for those products.
In essence, SCRT lets IBM charge you for the peak capacity you actually used rather than the system’s total capacity – provided you submit the SCRT report on time. If you don’t run SCRT or fail to submit the report, IBM defaults to charging as if the mainframe was used at full capacity.
Shared Principle:
Whether distributed or mainframe, sub-capacity means paying for what you use, not what you could use. For example, with ILMT on distributed systems, if an IBM application only uses two cores of an 8-core server, you license just those two cores (instead of all 8).
On the mainframe side, if a product peaks at 100 MSUs on a machine capable of 500 MSUs, you’re billed for ~100 MSUs rather than the full 500. The common goal is cost savings – but it only works if you diligently follow IBM’s mandated tools (ILMT or SCRT) and reporting rules.
Read about the pricing changes, IBM Tailored Fit Pricing for Z: A Game Changer or Cost Trap?.
How Mainframe Sub-Capacity (SCRT) Works
The Sub-Capacity Reporting Tool (SCRT) is IBM’s official mechanism for tracking sub-capacity usage on the mainframe. Each month, your mainframe team runs SCRT against the system’s accounting records (SMF data) to produce a detailed usage report.
This report displays the peak MSU consumption for each IBM product (such as z/OS, DB2, IMS, etc.) across all LPARs. You then submit this SCRT report to IBM, and IBM uses it to calculate your monthly bill for those products. In effect, SCRT tells IBM exactly how much capacity you really used at peak, so they charge you accordingly.
Accuracy and timeliness are absolutely critical. If you misreport data, submit it late, or skip a month, IBM will default to charging you at full machine capacity for that period.
There’s no leniency for errors – a forgotten SCRT submission can literally multiply your costs overnight. It’s the customer’s responsibility to run SCRT correctly and on schedule; IBM’s role is to receive the report and verify it.
IBM can cross-check your SCRT data against system performance logs if anything appears to be off. That’s why it’s essential to verify each report internally before sending it, and to maintain an audit trail of what was submitted in case IBM ever questions your numbers.
Checklist:
☐ SCRT runs every month (without fail)
☐ Reports validated internally for accuracy before submission
☐ Audit trail maintained (keep copies of reports and relevant data for IBM review)
How to optimize Mainframe costs, Leveraging IBM Specialty Processors (zIIP, zAAP) to Reduce Licensing Costs.
Distributed Sub-Capacity (ILMT)
In the distributed (non-mainframe) world, IBM enforces sub-capacity licensing via the IBM License Metric Tool (ILMT). Suppose you run IBM software on virtualized or partitioned servers with Processor Value Unit (PVU) licensing.
In that case, deploying ILMT is not optional – it’s a mandatory requirement to qualify for sub-capacity pricing. ILMT automatically discovers IBM software installations and tracks their usage in terms of processor cores used.
The tool generates reports that show IBM exactly how much capacity your software consumed. Unlike SCRT on the mainframe, ILMT reports are not sent to IBM regularly; however, they must be made available for inspection.
During an audit, IBM will demand ILMT evidence; if you cannot produce complete ILMT reports, IBM will retroactively charge you at full physical capacity for those servers.
To remain compliant, organizations must generate ILMT reports at least quarterly and retain those records for a minimum of two years.
In practice, many companies run ILMT continuously and review its data monthly to catch any anomalies. All servers (and any virtual machines or clusters) hosting IBM PVU-based software should be covered by ILMT. If even one VMware cluster or cloud instance is left unmonitored, it creates a compliance gap that IBM can exploit.
The rules do allow a few narrow exceptions to using ILMT – for example, if your entire enterprise is very small (with fewer than 1,000 employees or fewer than 1,000 PVUs in total usage) or if ILMT doesn’t support a particular platform.
However, IBM has largely eliminated most of these exceptions in recent years, and they only apply if you’ve documented them with IBM. The safe assumption is that you need ILMT across the board in any sizable environment.
Checklist:
☐ ILMT deployed on every server/VM where IBM software is running
☐ ILMT reports are generated quarterly and archived for at least 2 years
☐ Any allowed exceptions documented (e.g., small enterprise size or unsupported platform)
Compliance & Risk Factors
IBM’s sub-capacity rules carry significant compliance implications. On the mainframe side, a single missed or late SCRT submission means IBM can immediately bill you for the full capacity of that machine for the month.
There’s no second chance – if you forget to run SCRT or submit the report, the invoice will assume maximum usage. That could mean paying for, say, 5,000 MSUs instead of the 500 MSUs you actually used, which would blow a hole in your budget.
In distributed environments, ILMT gaps surface during audits. If ILMT isn’t properly deployed everywhere, IBM auditors will find the unchecked servers or VMs running IBM software.
The result? IBM will likely demand that you purchase licenses for the full physical capacity of those uncovered systems (often retroactively for the past two years), plus back-support costs. In an audit, lack of ILMT proof is treated as non-compliance – and IBM’s default remedy is to charge you for worst-case usage.
In both cases, IBM leverages any compliance gap as a means of negotiation. During contract renewals or “true-up” discussions, a history of missing reports or ILMT issues puts you on the defensive.
IBM’s sales team knows that if you’re out of compliance, you’ll be eager to settle – often at the expense of extra spend or less favorable terms. By staying fully compliant with ILMT and SCRT, you remove that leverage and keep more control in negotiations.
Pitfalls to Avoid
Even with sub-capacity tools in place, there are plenty of mistakes that can undermine your compliance.
Watch out for these common pitfalls:
- Mainframe (SCRT) pitfalls: Incorrect LPAR configuration can disqualify sub-capacity eligibility. Ensure all relevant LPARs are configured and included in SCRT reports. If an LPAR or workload is omitted or miscategorized, IBM may revert that portion to full-capacity billing. Also, don’t ignore your monthly peak workloads. A single uncontrolled spike (for example, a batch job running out of control) can set a high MSU peak and drive up costs unexpectedly.
- Distributed (ILMT) pitfalls: Failing to deploy ILMT on every server or VM running IBM software is a classic mistake. Any server left unmonitored is a compliance gap. Another pitfall is failing to keep ILMT up-to-date – an outdated ILMT version or missing software catalog updates can make your reports invalid in IBM’s eyes. Finally, incomplete or error-filled ILMT reports can’t be swept under the rug. If ILMT displays deployment errors or unrecognized software, address them immediately; otherwise, you’re essentially providing IBM with evidence of non-compliance.
- Assuming IBM “won’t check”: The worst mistake is complacency. Never assume IBM isn’t paying attention. Both ILMT and SCRT outputs are enforceable records. IBM auditors can and will examine them (sometimes years of data) during an audit. Thinking “we can slide by” will backfire – IBM’s revenue depends on identifying compliance issues, so expect them to check thoroughly.
ILMT vs SCRT – Comparison Chart
To summarize the differences, here’s a side-by-side comparison of ILMT (distributed) versus SCRT (mainframe):
| Factor | Distributed (ILMT) | Mainframe (SCRT) |
|---|---|---|
| Tool | ILMT (IBM License Metric Tool) | SCRT (Sub-Capacity Reporting Tool) |
| Products Covered | PVU-based software on x86/virtualized servers | z/OS, DB2 z/OS, IMS, CICS, MQ, etc. (MLC products) |
| Who Runs It | Customer IT / SAM team | Customer mainframe operations team |
| Report Frequency | Quarterly (at minimum) | Monthly |
| Submission | Retained for audit (not routinely sent to IBM) | Submitted to IBM every month |
| Consequence if Missing | Charged at full physical capacity (full server) | Charged at full machine capacity (full mainframe) |
FAQs
Q: Do I need ILMT for z/OS products?
No. ILMT is only for distributed PVU-based products. z/OS and other mainframe workloads use SCRT. Mixing tools across environments is a common mistake that results in compliance issues and overpayment.
Q: Can IBM audit my SCRT submissions?
Yes. IBM can validate SCRT data against system performance records. Any discrepancies can trigger recalculated bills at full-capacity rates. Maintaining a clean audit trail is critical to defend the MSU usage figures you report.
Q: What happens if I don’t submit SCRT reports?
IBM will charge you at full machine capacity, rather than based on actual usage. This can multiply costs dramatically. Missing even one monthly SCRT submission exposes you to hefty financial penalties and the loss of sub-capacity pricing benefits for that period.
Q: How often must ILMT reports be generated?
ILMT reports should be generated at least quarterly and retained for a minimum of two years. Even if not submitted to IBM directly, they must be available upon request during an audit. Failure to produce these reports will result in IBM defaulting to full-capacity licensing charges.
Q: Can I consolidate sub-capacity across environments?
No. SCRT and ILMT are platform-specific tools. You cannot combine distributed and mainframe sub-capacity data into one report or framework. Each environment must be managed and optimized separately – though both will impact your overall leverage in negotiations with IBM.
Read about our IBM Licensing Advisory Services
