The Cost of the Wrong Choice
The adage says, “You’ve got to spend money to make money.” But in the world of mainframes, that’s not always true. You can often spend the same amount and still save money. For example, a 1% increase in your mainframe IT budget can yield 2–5% total savings – if you select the right CPC model.
Many customers, however, don’t. They buy capacity instead of capability, assuming that more MIPS or MSUs automatically deliver better performance. It doesn’t work that way. Each IBM model generation has unique cache designs, processor speeds, and dispatching rules. Simply asking, “Do we need more or fewer MIPS?” misses the point.
The smarter question: “Which CPC runs my workload most efficiently today and tomorrow?”
Buying Power vs. Buying Performance
When it’s time to upgrade, many organizations panic when CPU utilization nears 90%. They rush to buy additional capacity, hoping to avoid bottlenecks. But that move often increases costs and decreases performance.
IBM’s z17 gives you a second chance. If you missed it with the z16, you can still migrate from full-speed 7## processors to slower ones with more engines—gaining performance, not losing it.
The irony is that slower processors can make your mainframe faster and cheaper when configured right. It’s a wild truth.
The Real Risks: Cost and Performance
Mainframe CPC replacement comes with real risks if done blindly. Customers who simply “buy bigger” often discover later that the new system consumes 10–25% more MSUs for the same workload. The culprits are poor cache alignment, overcommitted engines, and inefficient LPAR assignments.
By contrast, those who right-size their engines see the reverse: 10–25% MSU reductions without any loss of throughput.
Investing in software efficiency has a far higher ROI than throwing hardware at the problem.
Every new generation—from EC/BC12 forward—has changed the chip cache architecture, directly affecting workload behavior. Cache misses equal cycles wasted, and cycles wasted mean dollars burned.
The Software Cost Illusion
Reducing MSUs doesn’t guarantee an equal drop in software license costs. Most IBM and ISV pricing models are tiered: the first MSUs are expensive, and each additional one costs less. The real savings come from the incremental MSU, not the average.
For example, MSU 1 might cost $1,000, while MSU 1,976 costs $45.
The real savings come from the incremental MSU, not the average.
That’s why incremental analysis matters. Tuning your CPC to reduce peak MSU usage saves money where it counts—during the billing window. If you’re optimizing off-peak workloads, you might never see the benefit reflected in your monthly invoice.
Why “More Slower” Often Wins
Most customers overcommit their logical engines to the physical ones they own. That means too many LPARs chasing too few cores, making a recipe for cache chaos.
The fix sounds counterintuitive: buy more engines, but slower ones. There’s a word for this: IBM calls it “sub-capacity configuration.” It’s often the key to both performance and savings.
The Upside
-
HiperDispatch tuning can save 2–25% in MSUs, depending on configuration.
-
Slower GCPs mean zIIPs run relatively faster, boosting specialty engine throughput.
- Reduced spin time improves zHyperlink and CF Sync performance for DB2, IMS, and VSAM RLS workloads.
The Downside
For extremely large LPARs, “more slower” can backfire. Too many engines may exceed a single drawer—bad news on z16 and later systems. If zIIPs spill over drawers, SMT-2 mode or cloned LPARs might be the only solution.
Migrating to Sub-Capacity Models
Migrating to sub-capacity CPCs is generally low risk, especially if you’re coming from a pre-z15 system. The z16-6## engines, for instance, offer similar capacity ratings but greater efficiency thanks to better cache design.
Software typically makes up 50% or more of a mainframe budget, while hardware, including storage, accounts for less than 20%.
Many full-capacity configurations never achieved their rated performance anyway, due to cache overcommitment. A sub-capacity migration corrects that imbalance.
Remember, software typically makes up 50% or more of a mainframe budget, while hardware—including storage—accounts for less than 20%. Investing in software efficiency has a far higher ROI than throwing hardware at the problem.
Strategy: Buy More, Run Slower, Cap Lower
Personally, I recommend buying significant excess capacity—as many slower engines as you can—then cap the system below its peak to minimize software billing. The result is the same workload, lower MSUs, and less wasted CPU time.
Of course, you’ll need to negotiate sub-capacity pricing with all your software vendors. And before committing, conduct a critical path analysis to determine how much slowdown your key workloads can tolerate without user impact. This is where the art meets the science.
When Purchase Isn’t an Option
Sometimes there’s no budget for a new CPC, or the new one just arrived. That doesn’t mean you’re stuck. When done well, HiperDispatch tuning and cache optimization can still deliver real savings, up to 25% in MSU reduction.
Even without hardware changes, tuning LPAR assignments and workload placement can yield 5–10% improvements. The key is ensuring your high-MSU LPARs have Vertical High engines and that your online and batch settings differ by shift.
Understanding HiperDispatch Tuning
HiperDispatch isn’t just about speed; it’s also about structure. Each drawer in a CPC acts like its own mini-system, and keeping your LPARs confined to one improves efficiency. Drawer sizes grow with every new IBM generation, so smart tuning gets easier.
For many sites, simply right-sizing LPARs to fit drawers and aligning GCP/zIIP ratios delivers better results than any hardware upgrade.
The z16 6## Challenge
IBM shook up performance metrics with the z16 6## models. All other z16 versions were 10% faster than z15. However, the 6## line jumped 28% faster. The intent was clear: entice 7## customers to move down to sub-capacity 6## models with more engines and lower software costs.
Then came the z17, adding another 10–12% improvement. The kicker? The z17 6## runs only 3% slower than a z13 7##, meaning your older workloads may actually perform better on newer “slower” hardware.
Risks and Rewards
For most shops, the z16-6## is a fantastic move. But a few workloads—especially those with single-threaded CPU-bound tasks—might struggle. You must analyze whether your applications rely on full-engine bursts or distributed throughput.
Upgrading from older 6## models also carries risk. You’ll get the same MSUs with fewer engines, which increases zIIP crossover and reduces Vertical High processor availability. The result? More cycles per instruction (CPI) and higher billed MSUs for the same workload. Nobody wants that.
Specialty Engines and ICF Speeds
The z16-6## has the smallest specialty-engine advantage in the z1# family. The zIIPs are only about 10% faster, while GCPs jumped 28%. However, IBM removed the old 2:1 zIIP limit, giving you freedom to add more specialty engines if needed.
The tradeoff: coupling facility service times can spin GCPs harder. That mainly affects 6#-to-6# migrations; for those moving from 7## models, it’s often a non-issue.
Why z16 6## Works for 7## Customers
For small and mid-size customers—and even large ones with LPARs that fit neatly in a drawer—the z16-6## is a clear win. Few workloads ever drive a single TCB beyond 100 MSUs. For those coming from z13-7## systems, the effective difference is just 12%, easily erased by better HiperDispatch performance.
z15-7## migrations require more analysis since their engines run significantly faster. But smaller shops with limited HiperDispatch share often never achieve full 253-MSU engine potential anyway.
A move to z16-6## could deliver equivalent performance at lower software cost.
The Bottom Line
Buying a new CPC is more than a procurement decision because it’s also a strategic workload investment. The right CPC selection, tuned configuration, and dispatch optimization can yield double-digit performance and cost improvements.
The formula is simple: Buy smarter, tune deeper, spend less. Don’t just buy more MIPS. Buy the right mainframe.
This article originally appeared in Cheryl Watson’s Tuning Letter. It has been edited for length and content.
0 Comments