As IMS environments continue to modernize, upgrading the Java runtime has become a key decision point for many enterprises. With Java 21 now available as a Long-Term Support (LTS) release, a common and practical question arises:

Does Java 21 actually deliver better performance than Java 8 for IMS workloads?

A detailed IMS performance investigation was conducted to compare Java 8 (64-bit) and Java 21 (64-bit) across multiple IMS workloads involving mixed Java and COBOL processing. This blog summarizes the objectives, test scope, observations, and conclusions from that study.

Study Objective and Focus Areas

The primary goal of this performance investigation was to analyze and compare the runtime efficiency of Java 21 against Java 8 (64-bit) in an IMS transaction-driven environment. The focus was on understanding differences in:

• CPU utilization (GCP usage) - Measure overall CPU efficiency
• zIIP offloading – Evaluate specialty engine utilization
• Transaction response metrics (ETR / ITR) – Assess end-user impact
• Overall IMS workload efficiency – End-to-end performance view

Upgrading to Java 21 in IMS environments also requires COBOL version 6.4 or later and DB2 13.1 or later (if COBOL and DB2 are involved), making it essential to validate both performance and compatibility before adoption.

Test Scope and IMS Workloads Evaluated

Both Java versions were tested under identical hardware, IMS, and workload conditions to ensure a fair and meaningful comparison.

The study evaluated several IMS workloads on both Java versions under identical conditions:

• IMS COBOL to Java transactions (Java-Intensive Path)
• IMS Java to COBOL transactions

These scenarios were selected to represent varying degrees of Java and COBOL involvement in IMS transaction processing, allowing the investigation to observe how Java version differences manifest across diverse execution paths.

Key Performance Observations

1. IMS COBOL → Java Transaction Flow (Java-Intensive Path)

In the IMS COBOL → Java Transaction Flow (Java-Intensive Path), a transaction request first enters the mainframe through IMS Connect using TCP/IP and is routed by the IMS Control Region to an available MPP region, where an IMS-associated COBOL program is invoked. This COBOL program acts primarily as a lightweight adapter that performs basic message parsing and validation, then hands off control and data to a Java runtime (via JNI, JCA, or Language Environment calls). Java then performs the majority of the transaction processing, including core business logic, rule evaluation, orchestration, and most or all database interactions (such as IMS DB or DB2 access using JDBC).

Java executes the core logic under IMS transaction control and returns the response to COBOL, which sends it back via OTMA to IMS Connect. This approach modernizes application logic in Java while keeping IMS responsible for transaction management.

Key Results (Java 21 vs Java 8):

• 23% reduction in GCP usage
• 8% reduction in zIIP busy percentage
• 22% improvement in ETR
• 37% improvement in ITR
• 72% improvement in RMF WLM and IMSPA response times

Result Summary: Java 21 consistently and measurably outperformed Java 8 in Java-heavy IMS transaction paths, delivering both CPU cost savings and improved response times.

2. IMS Java → COBOL Transaction Flow

In the IMS Java → COBOL Transaction Flow, a transaction request first enters the mainframe through IMS Connect using TCP/IP and is routed by the IMS Control Region to an available JMP region, where the JMP region loads and executes the Java program in 64-bit mode using the JVMAP configuration to resolve the program name. The Java program processes the transaction logic and then calls a COBOL program, triggering a 64-bit to 31-bit mode transition within the JVM. This COBOL program performs the majority of the transaction processing, including core business logic, rule evaluation, orchestration, and most or all database interactions (such as IMS DB or DB2 access), and returns the response to Java, which sends it back via OTMA to IMS Connect. 

Key Results (Java 21 vs Java 8):

• 2% reduction in GCP usage
• 9% increase in zIIP offloading
• 10% improvement in ETR
• 12% improvement in ITR

Result Summary: Even when Java plays a smaller role in IMS transactions, Java 21 delivers noticeable CPU efficiency gains.

Conclusion

The results of the performance investigation strongly indicate that Java 21 represents a robust upgrade candidate for IMS environments:

• Better performance in Java-intensive IMS workloads
• Reduced GCP utilization through improved zIIP offloading
• Improved or stable IMS transaction response metrics
• No significant increase in storage requirements
• Comparable performance in IMS workloads with limited Java involvement

While not every IMS workload shows dramatic improvement, Java 21 consistently matches or exceeds Java 8 performance, with the most significant gains observed where Java plays a central role in IMS transaction processing

What This Means for IMS Customers

• If Java plays a central role in your IMS workload, Java 21 has the potential to deliver noticeable CPU performance improvements
• Even for COBOL-heavy flows, Java 21 offers incremental performance improvements
• Combined with LTS support, Java 21 represents a low-risk, high-value modernization step
  
  

Final Thoughts

This analysis demonstrates that migrating from Java 8 to Java 21 in IMS environments offers measurable performance gains without compromising stability. Combined with long-term support and ongoing JVM optimizations, Java 21 is a future-ready choice for modern IMS transaction processing.

DISCLAIMER: Performance results shared are based on measurements using standard IBM benchmarks in a controlled environment. Results may vary. All statements regarding IBM's future direction and intent are subject to change or withdrawal without notice and represent goals and objectives only.