5 MIN de lectura
Optimización de Mainframe
Most Batch Problems are Peak Problems: The Hidden Cost of Mainframe Bottlenecks
Many mainframe batch issues are peak problems, not capacity limits. Learn how shifting COBOL workloads to zIIP reduces GP spikes and improves performance.
It’s a familiar problem: during your most critical processing windows, your General Purpose (GP) processors redline and latencia climbs, putting mission-critical SLAs at risk.
El natural instinct is to add more capacity. If the engine is full, we need a bigger engine, right?
In good news for your mainframe TCO, the answer is not necessarily. In fact, many batch problems aren’t capacity problems at all—they’re peak problems.
The peak myth: It’s not a capacity problem
A CPU at peak capacity is a city deadlocked during rush hour. Too many vehicles trying to squeeze through the same narrow bottleneck turns the highway into a parking lot. But with proper planning—and a few express lanes—traffic can flow once again.
Batch peaks aren’t necessarily a sign that your mainframe is full. Instead, they could be hinting that your GP engines are being utilized inefficiently. Simply adding more GP capacity might relieve bottlenecks in the short term, but it’s akin to widening the highway when there are easier solutions.
The express lane strategy: Enter the zIIP
If the GP engines are the standard city streets, the IBM zIIP (System Procesador Integrado de Información) is the express lane. Traditionally, zIIPs were reserved for very specific workloads like Db2 or XML.
However, it’s now possible to make 80% or more of standard COBOL batch eligible for execution on zIIP.
By redistributing the heavy lifting of COBOL batch from GP to zIIP, you flatten the GP peaks, and stay safely beneath your peak usage limits by reclaiming your existing capacity.

Why this is the most scalable solution
There are three reasons why zIIP redirection is the sustainable path forward for capacity-conscious mainframe shops:
- This transition happens without code changes. Your developers don’t have to rewrite or refactor decades of COBOL logic. The redirection happens at the functional level.
- By lowering your GP utilization, you stay under your Rolling 4-Hour Average (R4HA) limits, even when latent workloads enter the mix. For users on a Tailor-Fit Pricing model, avoiding capacity spikes will keep you in a lower tier for the next contract cycle.
When you remove the carga de trabajo contention, your batch window becomes predictable. The risk of an SLA breach vanishes.
Resultados
By leveraging zIIP, you aren’t just moving work, you’re moving it faster. Data becomes available to the business sooner, reducing downstream latency. Most importantly, freeing up GP cycles gives the business the space it needs for new initiatives, without requiring new capital.
Reclaim resources: Free your mainframe from endless optimization efforts, while saving over 80% batch COBOL CPU for new projects.
Solve workload contention: Get high performance even at peak processing times.
Create budget predictability: Plan for upgrades on your schedule instead of reacting to capacity pressure.
Risk-free modernización: Preserve existing applications, data stores, scheduling frameworks, and outputs while modernizing in place.
Think traffic, not engines
The goal of modern mainframe management isn’t to have the biggest engine—it’s to have the smartest traffic flow. If you are struggling with batch windows and GP spikes, don’t look for more capacity. Look at how your workloads are optimized.
Our recommendation: audit your peak GP utilization. See how much contention is actually routine COBOL batch, and get in touch to see how JOPAZ can help you reclaim GP capacity by making workloads eligible for zIIP.