How Global Leaders are Solving the Mainframe Capacity Crisis: Three Real-World Case Studies 

We talk to customers every day about the challenges inherent in managing high-volume mainframe environments where efficiency and cost containment are top priorities, and we know capacity concerns aren’t always just about high workload volume. They’re about too much workload concentrated in the same window on the same resource. 

Contention happens when: 

• Too many batch jobs hit GP CPU at the same time
• Competing for the same constrained resource 
• Causing delays, SLA misses, and overlap with online 

JOPAZ rebalances the scales by redistributing heavy COBOL batch workloads to more efficient engines, changing the behavior of those peaks without touching the applications. 

What changes: Execution path, CPU behavior, and runtime environment (JVM) 

What doesn’t: COBOL source code, data, scheduling framework, and outputs 

Below, we look at how three major companies across different sectors achieved incredible CPU savings while solving their contention challenges for good. 

1. Member-Service Organization: Solving the R4HA Peak 

For a major North American member-service organization providing automotive, travel, and financial services, creating predictability was a top priority. Their batch processing was driving up Rolling 4-Hour Average (R4HA) costs, creating an urgent need for better workload distribution. 

The strategy:

The organization turned to JOPAZ to address the root cause of workload contention. 

• They compiled COBOL batch source code into Java bytecode 
• This code was then run on the Unix System Services JVM 

This allowed them to leverage IBM zIIP engines, reducing peak GP pressure by redistributing execution 

The Setup: 

• COBOL Db2 environment  
• Results were also tested using a sequential file 

The results:

The impact was immediate and substantial: 

Without JOPAZ 

• 47.96 seconds of CPU time 

With JOPAZ 

• 2.47 seconds of CPU time (95% decrease) 
• 94.84% batch COBOL CPU savings 
• Reclaimed MSUs for new workloads 
• Zero changes were required to the original source code 

2. Retail Energy Provider: Investing in Efficiency

A major North American energy provider with a large Db2 footprint needed a more strategic way to use their existing processing resources.

The Strategy:

Similar to the first case, the customer turned to JOPAZ to make their batch COBOL eligible for execution on their zIIP engine. In this instance, the zIIP engine had limited available capacity for use by JOPAZ, so following the success of the initial results, a second zIIP was added.

The Setup:

• COBOL Db2 environment
• We used three batch processes. Each of these batch processes had COBOL programs that accessed Db2, and each process had multiple steps.

The Results:

Without JOPAZ

• 2:26.27 Minutes of CPU time
• 14:10 minutes clock time

With JOPAZ – single zIIP engine

• 14.4 seconds of CPU time (90% decrease)
• 5:44 minutes clock time (60% decrease)
• 76% batch COBOL CPU savings

With JOPAZ –  2 zIIP engines

• 6.97 seconds of CPU time (95% decrease)
• 8:40 minutes clock time (39% decrease)
• 96.7% batch COBOL CPU savings

Initial testing was so promising that the customer immediately contracted dedicated resources to see the project through to completion. Most importantly, this was achieved with no change to code or business logic.

3. Payment Technology Company: Tackling Complexity and VSAM

In South America, a leading payment technology company processes billions of transactions annually. Unlike the other examples, this was a pure VSAM environment with no traditional databases, and it featured exceptionally large and complex applications.

The Strategy:

With four underutilized zIIP processors already sitting in their rack, the company saw JOPAZ as the perfect way to reclaim GP capacity. They started by recompiling a complex 54,000-line program. In the words of our customer, “If JOPAZ can handle this application, it can handle anything.”

The Setup:

• 35% of the total workload is comprised of COBOL batch
• Pure VSAM environment with no traditional databases
• 4 underutilized zIIP processors available

The Results:

• 97% reduction in batch COBOL CPU usage
• Maximized mainframe ROI by getting more capacity out of the existing footprint
• Maintained business as usual with no disruption

The Bottom Line

As our customers can attest, modernization doesn’t have to mean a risky, years-long migration to the cloud. The challenge is not whether COBOL works. It is whether a small number of jobs are driving disproportionate pressure during critical windows. Rather than changing their workloads—rewriting, rescheduling, or removing them–companies are reclaiming nearly all of their batch COBOL CPU usage by changing where they execute.

Whether you’re working with Db2, VSAM, Adabas, or sequential files, the results consistently show above 80% CPU savings, and often as much as 97%, all while keeping your proven business logic exactly as it is.

You may also like:

Page

JOPAZ Demo

Discover how JOPAZ demo Modernization transforms your COBOL workloads to free up valuable resources without business risk.

Page

Reduce mainframe COBOL workload with JOPAZ

JOPAZ compiles COBOL code into Java bytecode to run workloads on the zIIP processor, reducing mainframe CPU use and freeing capacity without code changes.

BLOG schedule 4 MIN read

Mainframe optimization:  Maximize the potential of your IBM Z without risk

JOPAZ optimizes COBOL workloads on IBM Z by compiling them to zIIP-eligible Java, reclaiming GP capacity for AI, analytics, and innovation with zero disruption.