① Explainer · Licensing concept
One program turns your SMF data into the MSU figure IBM bills you on every month. You run it, you validate it, you submit it. Get it wrong and you pay for capacity you never used. Here is how it works, with a worked multiplex report.
SCRT is not a meter IBM reads. It is a report you write, about yourself, that becomes your invoice.
The Sub-Capacity Reporting Tool, SCRT, is the IBM program that reads your z/OS SMF data and produces the report that sets how many MSUs you are charged for on sub-capacity eligible Monthly License Charge (MLC) and IPLA products. The current level is SCRT Version 25, and it ships with z/OS 2.3 and later. It reads SMF type 70 and type 89 records, computes the rolling four hour average for each product in each LPAR, and records the highest peak across the month. That peak, summed where products aggregate, is what you pay on.
The mechanic that matters: SCRT is self reported. IBM does not generate the report for you. You run the tool, you check the numbers, and you submit a comma separated file, typically monthly. IBM accepts it as the basis for the bill and can request the underlying SMF data later. So the same document is both your invoice and your audit trail. When it overstates your consumption, and it routinely can, you have paid the difference before anyone notices.
A simplified sub-capacity report for one machine running four products across three LPARs. SCRT records the peak R4HA per product per LPAR, then rolls products up to a single billable MSU figure. The full capacity of this machine is 900 MSU.
| Product | PROD1 peak | PROD2 peak | TEST1 peak | Billed MSU | Full capacity |
|---|---|---|---|---|---|
| z/OS | 540 | 210 | 60 | 810 | 900 |
| Db2 for z/OS | 480 | 150 | 0 | 630 | 900 |
| CICS TS | 390 | 0 | 0 | 390 | 900 |
| MQ | 120 | 0 | missing 89 | 900 | 900 |
z/OS, Db2, and CICS each bill well under full capacity because sub-capacity measurement caught the real peaks. MQ is the trap: a missing SMF type 89 record in TEST1 forces SCRT to default that product to full machine capacity, 900 MSU, even though its true peak was 120. That single gap can add hundreds of MSU to the bill. The fix is data hygiene, not negotiation, and it has to happen before the report is submitted.
Because SCRT is self reported and defaults aggressively to full capacity when data is incomplete, most overcharges are quiet and self inflicted. They do not show up as a vendor dispute. They show up as a monthly number that is simply higher than it should be, month after month, until someone reads the report the way IBM does. These four patterns account for most of what we recover.
| Pattern | What happens | The fix |
|---|---|---|
| Missing type 89 data | A product with incomplete SMF type 89 records defaults to full machine capacity | Validate SMF89 collection in every LPAR before submitting |
| Idle enabled products | A product left enabled where it does no real work still reports a peak | Disable or properly retire products not in production use |
| Test counted as production | Development and test LPAR consumption folds into the billed peak | Confirm LPAR classification and product scope per environment |
| Stale registration | A retired product keeps appearing on the report and billing | Reconcile the product list against what is actually licensed and live |
SCRT behavior depends on your z/OS level, your SMF collection, and your machine. These are common patterns we observe, not guarantees about any one estate.
SCRT sits directly under the rolling four hour average and the broader question of sub-capacity versus full capacity licensing, and its peaks aggregate under the sysplex aggregation rules. The MSU it reports is the unit explained in MSU, million service units, and the report is what every renewal proposal is priced from. When the figure looks wrong, the leverage is in the data, and that is the work on MSU optimization and the buyer side of an audit defense.
Audit notice or renewal under 18 months out? We mobilize within 48 hours. Want your SCRT reports read before IBM reads them for you? Start here.
The Sub-Capacity Reporting Tool (SCRT) is the IBM program that reads your z/OS SMF data and produces the report that determines how many MSUs you are billed for on sub-capacity eligible Monthly License Charge (MLC) and IPLA products. The current level is SCRT Version 25, and it ships with z/OS 2.3 and later. The report you submit each month is the document IBM uses to invoice you.
SCRT reads SMF type 70 and type 89 records, computes the rolling four hour average MSU consumption for each sub-capacity product in each LPAR, and records the highest such peak across the reporting month. For products that run in multiple LPARs in the same machine or aggregated sysplex, it sums the peaks. The output is a comma separated report that IBM accepts as the basis for billing.
Yes, commonly. Missing or incomplete SMF type 89 records cause a product to default to full machine capacity. A product left enabled in an LPAR where it does no real work still reports MSU. Test and development LPARs counted as production inflate the peak. And a stale product registration keeps billing a product you retired. Each is a recoverable overcharge if caught before the report is submitted.
You are. SCRT is self reported: the customer runs the tool, validates the output, and submits it to IBM, typically monthly. IBM does not generate it for you, and IBM does not audit every submission, but it can request supporting SMF data later. That makes the SCRT report both your bill and your audit exposure, which is why the numbers should be validated independently before they leave your shop.