Where to Find More Value Before Your Next Mainframe Upgrade

A bank shortened its critical batch window by nearly 15% by eliminating redundant backups. Ramanathan Perinkolam shares where to look for similar gains before your next mainframe upgrade.

A large North American bank shortened its critical batch window by nearly 15% by eliminating redundant backups. It made improvements on its existing platform.

Before your next mainframe upgrade, look for similar opportunities in the workloads you already run. Start with four areas where changes can free capacity, shorten processing time, or make existing services more useful.

Find the Work you no Longer Need to Do

Start with backup jobs on the critical path. Check whether another job already provides the same recovery coverage. Review recovery requirements before removing a duplicate or moving a necessary database image copy outside the critical path.

The same approach applies to software and capacity. Reviewing the software stack can reveal tools that perform the same function, while LPAR and vendor consolidation can reduce fragmentation and improve shared-capacity utilization. System and database tuning can unlock capacity before an organization commits to more disruptive changes.

For each opportunity, establish a baseline and measure the result. A shorter batch window has greater business value when it makes data available earlier, protects a processing deadline, or creates room for additional work.

Match Workloads to the Right Execution Environment

Workload placement affects both resource consumption and economics. Enterprises should review opportunities to use specialty processors such as zIIP and IFL for eligible workloads, alongside the licensing implications of their current processing arrangements.

A large healthcare provider in North America achieved significant cost savings primarily by avoiding expensive general-purpose processor software licensing costs and reducing peak capacity. The example reinforces why capacity planning and software economics deserve consideration together.

The opportunity depends on the workload. Teams need to assess eligibility, performance requirements, software terms, and operational dependencies before changing where work runs. Linux on IBM Z may also offer opportunities to consolidate distributed servers, where application requirements and the economics support that choice.

Database access deserves similar attention. A large European retailer cut CPU consumption by nearly 15% with Multi-Row Insert and nearly 35% with Multi-Row Fetch. The changes also reduced network traffic and client-server round trips. These techniques address how applications interact with Db2, making them worth examining alongside infrastructure upgrades.

Results will vary by application and access pattern. The useful lesson is to identify repeated work, test an appropriate technique, and measure its effect on the workload that matters.

Extend Proven Applications Around a Business Need

Start with a business function a digital channel needs or an integration that creates delays or duplicate work. Use call-graph analysis to see which programs the function depends on before deciding how to expose it.

IBM z/OS Connect can expose mainframe functions and data as REST APIs. Before opening a CICS or Db2-backed service to a new application, define who can access it, estimate transaction volumes, and assess how the added demand could affect core processing.

Examine the Cost of Moving Data

Mainframe data often supports decisions and services well beyond the applications that created it. Moving that data elsewhere can introduce additional expense and complexity. Enterprises should assess whether selected analytics or AI workloads could run closer to the source.

The placement decision should follow the workload’s requirements:

• How quickly must the model respond?
• Which data does it need?
• How much movement does the current architecture require?
• What processing and operational costs would change?

Keeping processing close to core data can add substantial value, but the business case must account for the full workload. Compare the alternatives using response time, data movement, capacity requirements, and operating costs.

5 Questions to Ask Before a Mainframe Upgrade

Mainframe strategy should extend beyond a sequence of technical upgrades. Each review should connect platform capabilities to a measurable business or operational outcome.

Before the next upgrade, ask these five questions:

1. Where do we consume capacity unnecessarily? Review redundant jobs, repeated database calls, duplicate software, and fragmented environments.
2. Which available capabilities could improve a priority workload? Evaluate relevant Db2 techniques, specialty processors, integration options, and development practices.
3. What result would justify the change? Define a target such as lower CPU consumption, a shorter batch window, faster delivery, or reduced data movement.
4. What must we protect? Identify recovery requirements, service levels, security controls, and application dependencies.
5. How will we verify the outcome? Establish the baseline, test the change, and compare results under representative conditions.

Next

Interested in more mainframe tuning insights? Check out these articles:

• 5 Mainframe Performance Tuning Examples with Quantifiable Value by Penney Berryman
• Tuning for Business Value, Not Cost: Building a Better Business Case for Mainframe Modernization by Donald Zeunert
• CICS. Db2. IPL. The Latest Cheryl Watson’s Tuning Letter by Mark Wilson