① Journal · IBM · NetView for z/OS
Tivoli NetView for z/OS is a Monthly License Charge product, so the rolling four hour peak measured by SCRT and the LPARs it runs on move the bill more than the list rate ever does. Here are the seven levers that actually shift a NetView renewal, and how each one works.
The list rate is the negotiation people expect. The measured peak and the footprint are the ones that decide the bill.
Tivoli NetView for z/OS, IBM's network and automation management product, is licensed under IBM's Monthly License Charge model. That means the charge is driven by the rolling four hour average peak MSU measured by SCRT on the LPARs where NetView runs, not by a flat per copy license. Buyers arrive at a NetView renewal expecting to argue the list rate and the annual increase, but the number the contract is actually built on is the monthly peak on those LPARs, and whatever sets that peak sets the charge. The largest levers therefore reduce the measured peak and confine the product to the systems that genuinely need it, before the baseline is captured, rather than contesting the published rate after the fact.
Around the peak sit the structural levers: the footprint of LPARs the product is licensed on, eligible offload to specialty engines, 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 an oversized footprint 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 NetView 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 |
| Confine the footprint | License NetView only on the LPARs that genuinely need it | Which systems carry the charge at all |
| Maximize eligible offload | Move eligible automation work to specialty engines | The general purpose peak that drives the charge |
| Right size the entitlement | Match the contracted capacity to the real automation load | The contracted MSU the bill rests on |
| 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 the licensed LPAR set | 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, footprint, 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.
Under sub-capacity MLC the charge follows the peak of the LPARs the product is licensed on. A NetView instance left active on a large general purpose LPAR it does not need to manage can carry far more cost than its automation footprint justifies. Confine the product to the systems that require it, validate that the SCRT report reflects only those, and the number often moves more than any rate discussion delivers.
You pay for the footprint, so size the footprint.
An uncapped MLC renewal hands the vendor every future year at once. A hard ceiling on the annual increase, with the list reference fixed at signing, protects the back half of the term where most of the cost actually lands. Pair it with a multi year commitment traded for an S&S concession, decided on validated data, and the structure holds rather than drifting upward.
Cap the year you cannot see, not just the one you sign.
④ Where the NetView number is moved
The list rate is the argument you expect. The peak, the footprint, the cap are the ones that count. Lower the peak, confine the footprint, cap the uplift.
Typical reduction negotiated on renewal spend
Mainframe spend negotiated on the buyer side
Engagements delivered since 2019
NetView is an MLC product, so the rolling four hour average peak measured by SCRT on the LPARs where it runs drives the charge, not a flat license. Whatever sets the monthly peak on those LPARs sets the bill, which is why reducing the peak and confining the footprint are the largest levers. See peak shaving and the R4HA.
Yes. Under sub-capacity MLC the charge follows the peak of the LPARs the product is licensed on, so an instance left active on a large LPAR it does not need to manage carries cost its footprint does not justify. Confine NetView to the systems that require it and validate the SCRT report. See MIPS and MSU explained.
Lower the measured peak before the baseline, confine the footprint to the LPARs that need it, push eligible work to specialty engines, trade term for an S&S concession, and cap the annual uplift against a fixed list. Our license negotiation service sets the structure and our cost optimization lowers the peak.
Network and automation management is sticky because automation routines and operator procedures build up around it, so displacement is rarely fast. The more reliable lever is to right size the footprint and cap the renewal rather than threaten a migration you cannot run on the renewal clock. See IBM price increase patterns.
Related: IBM publisher hub · peak shaving and the R4HA · Db2 for z/OS renewal negotiation · IBM price increase patterns · license negotiation
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →