① Journal · Renewal Playbook
WebSphere Application Server for z/OS is an MLC product billed on the rolling four hour average MSU, not on cores or seats. That means the renewal number is a function of measured peak capacity, and a handful of levers, zIIP Java offload, the Liberty footprint, sub-capacity accuracy, and workload placement, move it. Here is what actually changes the bill.
The charge tracks peak MSU. So the negotiation is about capacity, not list price.
On distributed platforms, WebSphere Application Server is priced per processor core through the PVU model. On z/OS it is different: WebSphere is generally an MLC product, billed monthly on the capacity it contributes to the rolling four hour average MSU, reported through SCRT under sub-capacity terms. That single fact reframes the whole renewal. The number is not a fixed price you either accept or reject; it is the output of a measurement, and the measurement is the MSU peak your WebSphere workload helps create during the window. Everything that reshapes that peak, especially the use of zIIP specialty engines for Java, reshapes the bill.
That makes a WebSphere for z/OS renewal unusually controllable for a buyer who knows the mechanics. WebSphere runs Java, Java on z/OS is largely zIIP eligible, and zIIP cycles do not draw general purpose MSU. The Liberty profile is lighter than the traditional Network Deployment runtime. Sub-capacity reporting can be accurate or sloppy, and sloppy reporting always favors a higher number. And underneath all of it sits the deepest lever of all, whether the workload truly needs to be on z/OS in the first place. Reading the renewal means working those levers in order. This builds on our WebSphere for z/OS licensing page and our IBM renewal advisory.
Lever · what it moves · how to pull it
| Lever | What it moves | How to pull it |
|---|---|---|
| zIIP Java offload | Shifts WebSphere Java off general purpose MSU, lowering the peak | Verify zIIP capacity is adequate and offload is actually occurring |
| Liberty vs traditional profile | Lighter runtime reduces the general purpose footprint | Migrate eligible apps to WebSphere Liberty to cut the MSU contribution |
| Sub-capacity reporting accuracy | Correct SCRT reporting prevents overstated billable MSU | Validate the SCRT report and LPAR definitions before the renewal close |
| Peak window management | Reshaping the four hour average peak lowers the measured MSU | Move or smooth WebSphere batch and spikes out of the contributing peak |
| Workload placement | Questions whether the z/OS premium should be paid at all | Hold a costed plan to move suitable workload to Linux on Z or distributed |
Four levers reshape the MSU peak the renewal is priced on. The fifth questions whether the workload belongs on z/OS at all.
Java belongs on the zIIP. Every cycle that is not there is MSU you are billed for.
The most direct lever on a WebSphere for z/OS renewal is also the least disruptive: make sure the Java is running where it should. WebSphere Java workload on z/OS is largely eligible for the zIIP specialty engine, and zIIP cycles do not count toward the general purpose MSU that drives the MLC charge. When zIIP capacity is adequate, eligible Java executes there and contributes nothing to the billable peak. When zIIP is undersized or saturated, that eligible work spills back onto general purpose processors, silently inflating the MSU the renewal is priced on. Verifying zIIP adequacy and confirming that offload is actually happening, not just configured, is often the single highest return action before a WebSphere renewal, and it requires no migration at all. The Liberty profile compounds the effect, since its lighter runtime reduces the general purpose footprint further for applications that can adopt it.
Beneath the tuning levers sits the question that gives a buyer real leverage: does this workload need to be on z/OS? WebSphere on z/OS earns its premium when the application genuinely benefits from co-location with z/OS data and transactions. Where it does not, the same workload can frequently run on WebSphere Liberty on Linux on IBM Z, or on distributed infrastructure, at a different cost base. A buyer does not need to complete a migration to use it; a credible, costed plan to move a portion of the estate reframes the renewal from a captive cost into a contestable one. Pair that placement option with accurate sub-capacity reporting, so the SCRT number reflects only the MSU actually consumed, and the renewal stops being a price you accept and becomes a number you negotiate. Our MSU optimization service works the peak, and our license negotiation service turns the placement option into a position.
Confirm zIIP capacity is adequate and that WebSphere Java is actually executing there. Saturated zIIP pushes eligible work onto general purpose engines and inflates the MSU peak the renewal is priced on. This is leverage with no migration required.
Java off the zIIP is MSU you pay for twice.
The WebSphere Liberty profile is lighter than the traditional Network Deployment runtime. Migrating applications that can adopt it reduces the general purpose footprint and the MSU contribution before you ever reach the negotiating table.
A lighter runtime is a lighter bill.
The renewal is priced on SCRT measured MSU. Check the report and the LPAR definitions before the close, because overstated or misconfigured sub-capacity reporting always moves the number in the vendor's favor.
An unchecked SCRT report is a number written by the vendor.
Where the workload does not truly need z/OS, a costed plan to move it to Linux on IBM Z or distributed infrastructure reframes the renewal from captive to contestable. The plan does not need to be executed to be leverage.
A credible exit reprices the workload that stays.
⑤ The discipline that pays
The WebSphere number is a measurement, not a list price. Control the MSU peak and question the placement, and the measurement moves.
Typical reduction negotiated on renewal spend
Mainframe spend negotiated on the buyer side
Engagements delivered since 2019
On z/OS it is generally an MLC product, billed monthly on the capacity it contributes to the rolling four hour average MSU, reported through SCRT under sub-capacity terms, rather than the PVU per core model used on distributed platforms. The renewal number is a function of measured peak capacity, so anything that reshapes that peak, especially zIIP Java offload, moves the bill.
WebSphere runs Java, Java on z/OS is largely zIIP eligible, and zIIP cycles do not draw general purpose MSU. The more Java runs on zIIP, the lower the MSU peak the workload adds. Undersized or saturated zIIP forces eligible work back onto general purpose engines and quietly inflates the number. Verifying offload is one of the most direct levers, with no migration required.
Workload placement, because it questions whether the z/OS premium should be paid at all. Where the application does not truly need z/OS co-location, the workload can often run on WebSphere Liberty on Linux on IBM Z or on distributed infrastructure. A credible, costed plan to move part of the estate reframes the renewal from captive to contestable.
Verify the zIIP offload, migrate eligible applications to Liberty, validate the SCRT sub-capacity report and LPAR definitions, and hold a costed placement option for workload that does not need z/OS. Work the MSU peak first, then question the placement. See our WebSphere for z/OS licensing page.
Related: WebSphere for z/OS licensing · IBM renewal advisory · Linux on IBM Z licensing · MSU optimization · license negotiation
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →