① Journal · IBM · Db2 for z/OS
Db2 for z/OS is a Monthly License Charge product, so the rolling four hour peak measured by SCRT moves the bill more than the list rate ever does. Here are the seven levers that actually shift a Db2 renewal, and how each one works.
The list rate is the negotiation people expect. The measured peak is the one that decides the bill.
Db2 for z/OS is licensed under IBM's Monthly License Charge model, which means the charge is driven by the rolling four hour average peak measured by SCRT on the LPARs where Db2 runs, not by a flat per seat or per core license. That single fact reorders the whole renewal. Buyers arrive expecting to argue the list rate and the annual increase, but the number the contract is actually built on is the monthly peak MSU, and whatever sets that peak sets the charge. The largest levers on a Db2 renewal therefore reduce or reshape the measured peak before the baseline is captured, rather than contesting the published rate after the fact.
Around the peak sit the structural levers: zIIP offload that moves eligible work off the general purpose engine, the choice between standard MLC, Value Unit Edition, and Tailored Fit Pricing, swap rights that protect against shelfware, an S&S concession in exchange for a multi year term, and a hard cap on the annual uplift with a fixed list reference. Each is decided on independently validated SCRT and R4HA data, because the wrong model or an uncapped term locks in overspend for the life of the deal. Read this with our explainer on the R4HA and peak shaving and the IBM publisher hub.
What we commonly observe · the lever and how it shifts the Db2 number
| Lever | How it works | What it moves |
|---|---|---|
| Reduce the measured peak | Workload timing and soft capping cut the monthly R4HA peak | The MLC baseline the renewal is built on |
| Maximize zIIP offload | Eligible Db2 work moves off the general purpose engine | The general purpose peak that drives the charge |
| Choose the right model | Standard MLC, Value Unit Edition, or Tailored Fit Pricing | The whole cost structure for the term |
| Secure swap rights | Exchange unused entitlement for products of equal value | Shelfware risk across the term |
| Trade term for S&S relief | A multi year commitment in exchange for a support concession | The effective support rate and any one time credit |
| Cap the annual uplift | A hard ceiling on the yearly increase, list reference fixed | Every year of the term, not just signing |
| Validate the SCRT data | Independent check of the peak and offload figures | The accuracy of the number everything else rests on |
Levers are what we commonly observe working across buyer side engagements, not statements of IBM policy, and the effect of each depends on your workload. Your SCRT data, model, and entitlement govern the real number.
The rolling four hour peak measured by SCRT is the number the renewal is built on, so the highest leverage action is to reduce it before the baseline is captured. Workload timing moves batch and reporting off the online peak window, soft capping holds the measured MSU under a defined ceiling, and both flow into the contract when done early. Lower the profile first, then renew on it; do it after, and the headroom is given away.
Shape the peak, and you shape the bill.
Db2 for z/OS offloads eligible work, including parts of certain queries and utilities, to the zIIP specialty engine, and zIIP cycles do not count toward the general purpose MSU that drives MLC. Increasing eligible offload lowers the general purpose peak and the charge with it. The offload is bounded by workload type, so the lever is to maximize what is eligible and verify it in the SCRT data, not to assume a fixed share.
Every eligible cycle off the GP engine is MSU off the bill.
Value Unit Edition and Tailored Fit Pricing each change the cost structure, and each suits a different estate. Value Unit Edition converts MLC to an upfront charge plus support and can favor a stable workload; Tailored Fit Pricing commits to a consumption baseline and floor that can favor a growing one. Decide on independently validated SCRT and R4HA data, model each against staying on standard MLC, and move only on the math.
Take the model that your data favors, not their forecast.
④ Where the Db2 number is moved
The list rate is the argument you expect. The peak, the offload, the model are the ones that count. Lower the peak, push the zIIP, model the move.
Typical reduction negotiated on renewal spend
Mainframe spend negotiated on the buyer side
Engagements delivered since 2019
Db2 for z/OS is an MLC product, so the rolling four hour average peak measured by SCRT drives the charge, not a flat license. Whatever sets the monthly peak MSU sets the bill, which is why reducing or reshaping the peak is the largest lever. See peak shaving and the R4HA.
Yes, within limits. Db2 offloads eligible work to the zIIP engine, and zIIP cycles do not count toward the general purpose MSU that drives MLC. Maximize eligible offload and verify it in the SCRT data rather than assuming a fixed percentage. See MIPS and MSU explained.
It depends on the estate. Value Unit Edition suits a stable workload as an upfront charge plus support; Tailored Fit Pricing commits to a consumption baseline and floor that can favor a growing one. Decide on validated SCRT and R4HA data, modeling each against standard MLC. See Tailored Fit Pricing.
Lower the measured peak before the baseline, maximize zIIP offload, model any move to VUE or TFP on validated data, secure swap rights, trade term for an S&S concession, and cap the annual uplift. Our license negotiation service sets the structure and our cost optimization lowers the peak. See also IBM price increase patterns.
Related: IBM publisher hub · peak shaving and the R4HA · Tailored Fit Pricing · IBM price increase patterns · license negotiation
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →