5 Mainframe Performance Tuning Examples That Deliver Quantifiable Value

Aug 5, 2026

Penney Berryman, MPH (she/her), is the Content Editor for Planet Mainframe. She also writes health technology and online education marketing materials. Penney is based in Austin, Texas. Connect with her on LinkedIn.

Mainframe performance tuning does not always require a bigger budget, and lower resource consumption does not always produce a smaller bill. 

The real opportunity for optimizing mainframe business value lies in understanding where tuning creates usable capacity, avoids future costs, improves service, or reduces risk.

As Donald Zeunert explained in Don’t Buy More MIPS—Do This Instead, “A 1% increase in your mainframe IT budget can yield 2–5% total savings.” 

But those savings depend on choosing the right CPC model and configuration for your organization’s needs. Many customers do not.

A Common Misunderstanding

“They buy capacity instead of capability, assuming that more MIPS or MSUs automatically deliver better performance,” Zeunert wrote. “It doesn’t work that way.”

Organizations that simply buy a bigger system may discover that it consumes 10–25% more MSUs for the same workload. Poor cache alignment, overcommitted engines, and inefficient LPAR assignments can erase the expected performance gains.

Buying more capacity cannot compensate for an inefficient configuration or workload.

But organizations that right-size their engines and configurations may achieve the opposite: 10–25% MSU reductions with no loss of throughput, Zeunert noted.

Buying more capacity cannot compensate for an inefficient configuration or workload. Tuning helps organizations get more value from the capacity they already own.

Five Examples of Tuning Value for Business

Not every reduction in CPU, I/O, or MSUs reduces the bill. Mainframe pricing depends on peaks, tiers, commitments, chargeback formulas, and incremental rates, to name a few elements.

Zeunert agrees, “Lower utilization only creates savings if it reduces billable hardware or software costs.” Read five reasons why that doesn’t always happen. 

But even if tuning does not produce immediate financial savings, it can create value:

  1. Technical improvement: Consuming fewer resources or reducing delays
  2. Capacity value: Releasing headroom, supporting more work, or deferring an upgrade
  3. Financial savings: Producing a measurable reduction in spending
  4. Business value: Improving service, protecting revenue, increasing resilience, or reducing risk.

The following five examples from Cheryl Watson’s Tuning Letter (Tuning Letter) archives show how different forms of value can appear in real mainframe environments.

Example 1:
Reduce More Than One Million I/Os

The problem

A client requested help with a system-tuning exercise. One mainframe job was running so long that it had begun to affect the batch schedule.

The job used the IBM Workload Scheduler Workload Automation Programming Language, or WAPL. Analysis of its SMF type 30 records showed that it performed more than one million I/Os to the IWS load library.

The change

The team added the load library to the LNKLST. This allowed the Library Lookaside facility, or LLA, to manage the load library and its directory entries.

The result

The change produced:

  • A 99% reduction in I/Os issued by the job
  • A 53% reduction in elapsed time
  • A 5% reduction in CPU time

The value

This change delivered a clear technical improvement while protecting a critical business outcome: completion of the batch schedule.

Will every job produce such dramatic results? Of course not. But a handful of improvements like this can recover meaningful capacity and make the performance team very popular.

Read the full analysis and process in the Tuning Letter.

Example 2:
Save $25,000 Without Missing an SLA

The problem

Meeting response-time objectives does not always mean a system runs efficiently. An organization may still need to reduce CPU consumption, especially when its chargeback model depends on CPU time.

At one outsourced data center, a customer met its service-level objectives (SLA) but continued to pay for avoidable CPU use.

The changes

The tuning work included:

  • Reducing I/O and FCT searches
  • Making selected programs resident
  • Cleaning up programs with high CPU use
  • Making minor changes to several high-use file-record structures

The result

The customer saved $25,000 per month.

The value

This example produced direct financial savings even though service levels had already been met. Performance tuning should not begin and end with response time. A workload can meet its SLA while consuming more resources – and more money – than necessary.

Don't miss these other great articles

Example 3:
Understand Who Benefits From Optimization

Technical improvement does not always benefit every party in the same way.

While working for an outsourcer, one tuning expert increased block sizes to improve performance. Larger block sizes reduced the number of EXCPs. Because the outsourcer’s chargeback model generated revenue from EXCPs, the optimization reduced its revenue by thousands of dollars in a single month.

The outsourcer was not pleased. The customer was.

The value

The lesson extends beyond block size: optimization can change who pays and who benefits.

Before declaring a tuning effort successful, understand the organization’s pricing, contracts, chargeback model, and incentives. A technical gain may create direct savings for one party while reducing revenue for another.

That does not make the optimization wrong. It makes the financial model essential.

Example 4:
Cut a Batch Job From 1 Hour to 15 Minutes

The problem

With a few exceptions, I/O delay ranks among the most significant contributors to resource consumption and response-time degradation. Reducing either the number of I/Os or the time required to complete them can improve elapsed time.

“Organizations sometimes focus exclusively on CPU metrics while overlooking I/O inefficiencies,” Mullins notes. “In many cases, excessive I/O is the underlying cause of elevated CPU consumption.”

The change

Large buffers for sequential access can reduce the number of physical I/Os required to access a data set. Buffering does not change the amount of disk storage the data set consumes.

Because the blocks are read sequentially, buffering can reduce disconnect time for seeks and pend time while waiting for a path.

The result

In one example, buffering reduced a batch job from one hour to 15 minutes.

The value

The technical improvement delivered substantial business value by shortening the batch window. Depending on the environment, it could also release capacity, improve downstream processing, or reduce the risk of missing an SLA.

Read more about batch application tuning in the Tuning Letter.

Example 5:
Find Hundreds of MIPS Hidden in XCF Activity

The problem

While reviewing a client’s RMF Cross-System Coupling Facility (XCF) reports, a tuning expert noticed consistent, significant spikes in XCF activity every hour. Investigation traced the spikes to a process that woke up hourly and attempted to access thousands of resources already in use elsewhere.

The activity appeared across three XCF groups – SYSGRS, SYSENF and IXCLOxxx – in essence, masking its total effect.

The IRLM XCF group used for false-contention negotiation by one Db2 data-sharing group accounted for 50% of all XCF activity. It processed more than five times as many messages as the next-highest user, and consumed hundreds of MIPS across the sysplex.

The finding

The activity did not crash systems or cause an obvious outage. But it was atypical, expensive, and worthy of further investigation. Addressing it offered the potential to save a few hundred MIPS during the peak rolling four-hour average, or R4HA.

The value

This example demonstrates why performance teams should look beyond visible failures. Unnecessary activity can consume significant capacity without producing an obvious service problem.

Recovering that capacity could create more headroom, delay an upgrade, or reduce peak-related costs.

See the complete findings in theTuning Letter.

Your Turn: Translate Technical Findings Into a Business Case

The preceding Tuning Letter examples show why tuning should not focus on one metric alone. A lower CPU number, fewer I/Os, or a shorter batch window matters only when the organization understands what that improvement makes possible.

To help teams make that connection, Planet Mainframe created the Mainframe Performance and Value Tuning Scorecard.

This fillable and printable worksheet helps:

  • Establish a technical and business baseline.
  • Identify common tuning opportunities.
  • Score opportunities based on performance, cost, business value, and effort.
  • Estimate the technical, capacity, financial, and business results.
  • Translate the expected improvement into an executive summary.

The scorecard also prompts teams to validate financial assumptions with the people who understand the organization’s contracts, chargeback model, and software pricing.

Start With the Opportunity That Creates the Most Value

As you’ve gleaned, the best tuning target is not always the workload consuming the most resources. Start with the opportunity where technical improvement can create the greatest usable business value.

That may mean reducing a bill. It may mean delaying an upgrade, completing a batch cycle sooner, supporting more transactions, improving resilience, or reducing risk.

Download the fillable Mainframe Performance and Value Tuning Scorecard to establish your baseline, rank your opportunities, and build the case for action. Then let us know how it goes!

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Sign up to receive the latest mainframe information

This field is for validation purposes and should be left unchanged.

Read More