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.