① Explainer · Licensing concept
The model number on the side of your mainframe is a licensing decision wearing a hardware costume. It sets the MSU your full capacity software is billed on and the ceiling your sub-capacity bill sits under. Here is how the rating becomes the bill, with the table.
You do not negotiate your software bill only at the contract table. You also set it when you choose the model, because the model rating is the MSU your software prices on.
A model capacity rating is IBM's published capacity for a given machine configuration, expressed in MSU and used directly to price software. On recent IBM Z, sub-capacity configurations are identified by capacity levels such as 7xx, 6xx, 5xx, and 4xx, where the 7xx level is approximately full capacity per engine and the lower levels deliver a defined fraction of it. The rating matters because it is the number software bills on: full capacity licensed products are charged on the machine's rated MSU no matter how little you use, and sub-capacity products are charged on measured consumption up to that rated ceiling.
The practical consequence: choosing a lower capacity level that still carries your workload reduces the rated MSU, which lowers the full capacity bill and the sub-capacity cap at the same time. A configuration with fewer, faster engines can sometimes carry the same throughput at a lower rating than a configuration with more, slower ones. That is why hardware refresh and licensing have to be planned as one decision. The worked table shows how the rating moves the bill across capacity levels.
Illustrative capacity levels for a single engine configuration, showing how the level sets the rated MSU and therefore what full capacity software bills on. The percentages reflect the published pattern; the MSU figures are rounded illustrations of the mechanism, not a model lookup.
| Capacity level | Approx. share of full | Illustrative rated MSU | Full capacity software billed on |
|---|---|---|---|
| 7xx (full) | 100% | 300 | 300 MSU |
| 6xx | ~66% | 198 | 198 MSU |
| 5xx | ~41% | 123 | 123 MSU |
| 4xx | ~12% | 36 | 36 MSU |
Same engine, four ratings. A full capacity licensed product on the 7xx level bills on 300 MSU; the same product on a 5xx level configuration that still meets the workload bills on roughly 123 MSU, about 59% less, purely from the rating. Sub-capacity products are billed on measured use rather than the rating, but the rating still sets the ceiling and the full capacity products on the estate. The model choice is a recurring software cost decision, not a one time hardware purchase.
Capacity ratings bite when hardware is sized for headroom and software is left to follow. Order a model rated well above real need and every full capacity product on the estate pays for capacity you never use, every month, for the life of the machine. The levers below are how to keep the rating tied to actual workload rather than to a comfortable hardware margin.
| Lever | How it works | What it touches |
|---|---|---|
| Right size the model | Choose the lowest capacity level that meets real throughput | Lowers rated MSU and the full capacity bill |
| Fewer, faster engines | Carry the same work at a lower aggregate rating | Reduces the MSU software prices on |
| Sub-capacity adoption | Bill measured use instead of the full rating | Decouples cost from rated ceiling |
| Plan refresh with licensing | Model the software bill before ordering the box | Stops a hardware choice locking in software cost |
| Full capacity product review | Move eligible products to sub-capacity terms | Removes products from rating based billing |
Capacity ratings, level percentages, and MSU values are defined by IBM per machine generation and configuration and change across models. The figures here are illustrative of the mechanism; the exact rating for your machine must be read from IBM's capacity tables for your specific configuration.
The capacity rating is the ceiling above the rolling four hour average and the basis for full capacity versus sub-capacity billing on MSU. It also shapes what you can offload to a zIIP and changes with any outsourcing move to a provider's machine. Modeling the software bill against a hardware refresh, and timing the model choice with the renewal, is the work on mainframe cost optimization and MSU optimization.
Audit notice or renewal under 18 months out? We mobilize within 48 hours. Refreshing hardware? Model the software bill against each capacity level before you order the box.
A model capacity rating is IBM's published capacity for a given machine configuration, expressed in MSU and used to price software. On recent IBM Z, sub-capacity configurations are labeled by levels such as 7xx, 6xx, 5xx, and 4xx, where the 7xx level is full capacity and the lower levels deliver a defined fraction of it. The rating is what full capacity software is billed on, and the ceiling that sub-capacity billing sits under.
Full capacity licensed software is billed on the machine's rated MSU regardless of how much you actually use. Sub-capacity software is billed on measured consumption up to that rated ceiling. Either way the model rating sets the number: a higher rated model raises the full capacity bill and the cap on sub-capacity, so the model you order is a licensing decision, not just a hardware one.
On recent IBM Z, the second and third digits of the model identify a capacity level: 7xx is approximately full capacity, with 6xx, 5xx, and 4xx delivering progressively smaller defined fractions of the full rating per engine. Choosing a sub-capacity level can deliver the throughput you need at a lower MSU rating, which directly lowers full capacity software cost, as the worked table above shows.
Sometimes. Moving to a configuration with a lower MSU rating that still meets your throughput need reduces the rated capacity that full capacity software bills on and lowers the sub-capacity ceiling. This is why hardware refresh and software licensing should be planned together: a faster, fewer engine configuration can carry the same work at a lower rating, but only if the workload profile fits.