Introduction

Java workloads running on z/OS support many critical enterprise systems such as financial transaction processing, integration platforms, and large-scale batch operations. As enterprises continue to modernize applications and expand the use of Java on the platform, managing CPU consumption becomes increasingly important.

The z/OS platform provides powerful capabilities such as z Integrated Information Processors (zIIPs), advanced Workload Manager (WLM) scheduling, and tight integration with subsystems like Db2 and IMS. However, default configurations are designed for general workloads and may not fully exploit these capabilities.

By carefully tuning Java execution environments, increasing zIIP eligibility, optimizing database connectivity, and leveraging JVM capabilities such as shared class caching, enterprises can significantly improve CPU efficiency while maintaining high levels of performance and scalability.

The following sections describe several practical techniques that help reduce CPU consumption and improve efficiency for Java workloads running on z/OS.

Key Optimizations for CPU Efficiency in Java Workloads on z/OS

Modern enterprise workloads running on z/OS often rely heavily on Java-based applications integrated with Db2 and IMS environments. While these workloads provide flexibility and interoperability, they can also introduce significant CPU consumption if not properly optimized.

Several targeted optimizations can significantly improve CPU efficiency while maximizing the use of specialty processors such as zIIP.

Maximizing zIIP-Eligible Processing

One of the most effective cost-optimization strategies in a z/OS environment is increasing the proportion of processing that can run on z Integrated Information Processors (zIIPs) rather than general-purpose processors (GCPs).

zIIPs are designed to handle workloads such as Java execution, database processing, and certain middleware tasks. Because zIIP cycles are not counted toward software licensing costs, shifting eligible workloads to zIIPs can provide substantial cost savings.

In Java-based environments, increasing zIIP utilization can be achieved by:

• Designing applications with higher Java workload components
• Structuring code paths to increase zIIP-eligible execution
• Leveraging middleware and database interactions that support zIIP offload

When these techniques are applied effectively, a larger portion of processing is redirected away from GCPs, reducing overall CPU consumption costs while maintaining performance.

Configuring Workload Manager (WLM) Honor Priority = NO

Another important optimization involves configuring Honor Priority = NO in z/OS Workload Manager (WLM).

Under normal conditions, when zIIPs are busy, zIIP-eligible work can spill over to general-purpose processors to maintain response time. While this behavior improves responsiveness, it can also increase GCP utilization.

Setting Honor Priority = NO changes this behavior by prioritizing cost efficiency over response time.

With this configuration:

• zIIP-eligible work is forced to execute on zIIP processors
• Spillover to GCPs is minimized
• GCP consumption is significantly reduced

This configuration is particularly beneficial for workloads where CPU cost reduction is a higher priority than minimal latency, such as batch processing or high-volume transactional systems that can tolerate slight variations in response time.

Reducing Database Overhead with Db2 Connection Pooling

Database connectivity is another area where CPU overhead can accumulate, especially in high-transaction environments where applications frequently establish and terminate database connections.

Db2 connection pooling addresses this problem by allowing existing database connections to be reused rather than recreated for every transaction.

Connection pooling reduces CPU usage by:

• Eliminating repeated authentication and connection setup
• Reusing prepared SQL statements
• Reducing thread creation and teardown overhead

These benefits are particularly noticeable in environments with large transaction volumes and frequent database access.

Several JVM environment parameters within the DFSJVMEV member help enable and optimize this functionality.

DB2JCC_ESAF_THREAD_NOTIFICATION

DB2JCC_ESAF_THREAD_NOTIFICATION=YES

This parameter instructs the IMS system to notify the Db2 JCC driver about ESAF threads used by the application.

When enabled:

• Db2 is aware of the executing ESAF thread
• Prepared SQL statements can be reused
• Database processing overhead is reduced

This parameter is required when Db2 IMS attachment connection pooling is enabled.

ESAF_SIGNON_ACEE

ESAF_SIGNON_ACEE=YES

When enabled, IMS creates and manages the Accessor Environment Element (ACEE) used during ESAF sign-on processing.

This optimization improves efficiency because:

• The ACEE is created only once per commit cycle
• The external subsystem does not need to create the ACEE repeatedly
• Security context creation overhead is reduced

As a result, CPU cycles spent on repeated authentication operations are minimized.

DB2JCC_CONN_REUSE

DB2JCC_CONN_REUSE=Y

This option allows Db2 JCC connections to be reused across transactions when possible.

When enabled:

• Existing database connections remain active
• Subsequent transactions can reuse the same connection
• CPU overhead associated with connection establishment is eliminated

However, connection reuse occurs only when:

• The transaction user ID remains the same
• The application remains scheduled
• Multiple Units of Recovery (UORs) exist within the workload

In high-throughput environments, enabling this parameter can significantly reduce CPU consumption associated with database connectivity.

Improving JVM Efficiency with Shared Class Cache

Another optimization that can reduce CPU consumption is enabling the Java Shared Class Cache.

The shared class cache allows compiled Java classes to be reused across multiple JVM instances, avoiding repeated class loading and compilation.

This optimization provides several benefits:

• Faster JVM startup times
• Reduced Just-In-Time (JIT) compilation overhead
• Lower sustained CPU utilization

The shared class cache is enabled using the following JVM option:

-Xshareclasses

Configuring Shared Class Cache Parameters

Specifying Cache Location

-Xshareclasses:cacheDir=<directory>

This option defines where shared class cache data is stored.

On z/OS systems, the default location is:

/tmp/javasharedresources

It is recommended not to place the cache on NFS or shared mounts across LPARs, as this can introduce contention and performance issues.

Ensuring JVM Startup Resilience

-Xshareclasses:nonfatal

This option allows the JVM to start even if the shared class cache fails to initialize.

Without this setting, the JVM might refuse to start if the cache cannot be accessed. Enabling nonfatal ensures that the application can still run even if class sharing is temporarily unavailable.

Defining a Named Cache

-Xshareclasses:name=<cacheName>

Using a named cache allows an application to maintain its own dedicated shared class cache.

This avoids conflicts with other applications and ensures that cache capacity is allocated specifically for the workload.

Configuring Cache Size

-Xscmx<size>

This parameter defines the maximum size of the shared class cache.

Proper sizing ensures that frequently used class data can remain cached, reducing repeated class loading and compilation across JVM instances.

Additional JVM Tuning Parameters for z/OS

Beyond shared class caching, several JVM options can further improve CPU efficiency and runtime behavior for Java workloads on z/OS.

Heap Sizing

-Xms<size>
-Xmx<size>

Setting the initial heap size (-Xms) and maximum heap size (-Xmx) to the same value prevents dynamic heap expansion during runtime. This can reduce garbage collection overhead and provide more predictable performance for long-running enterprise workloads.

Garbage Collection Policy

-Xgcpolicy:gencon

The generational concurrent garbage collection policy is commonly used for transactional workloads that create large numbers of short-lived objects.

Benefits include:

• Reduced GC pause times
• Improved application throughput
• More efficient memory management under heavy transaction loads

JIT Compilation Optimization

-Xjit
-XcompilationThreads

These options control Just-In-Time (JIT) compilation behavior and compilation threading. Proper tuning allows frequently executed methods to be optimized more efficiently, reducing CPU overhead during sustained workloads.

Performance Impact

When applied together, these optimizations provide multiple performance benefits:

• Higher utilization of zIIP specialty processors
• Reduced GCP CPU consumption
• Lower database connection overhead
• Faster JVM startup and warm-up times
• Improved throughput in high-transaction environments

These improvements make JVM-based workloads more efficient and cost-effective on z/OS platforms.

Notes on the Measured Results

The measurements in this document were captured during testing on our machine.

These numbers help illustrate how the tuning changes affected Java GCP and Java zIIP usage in our test environment. Results will vary for each application using Java based on workload design, transaction mix, JVM level, middleware stack, Db2 and IMS configuration, z/OS release, hardware model, LPAR contention, WLM policy, and application behavior.

The data should therefore be treated as representative of our test observations rather than as a universal outcome for every environment.

Illustrative CPU Measurements

The following measurements were captured during our testing:

What the Numbers Suggest

The data shows a consistent pattern: as tuning changes are applied, Java work shifts away from GCP consumption and toward zIIP consumption.

1. Baseline vs. WLM Honor Priority = NO

Baseline:

• Java GCP: 738 µs
• Java zIIP: 297 µs

Base + WLM HP=NO:

• Java GCP: 293 µs
• Java zIIP: 400 µs

Illustrative effect:

• GCP drops by 445 µs
• This is approximately a 60.3% reduction in Java GCP time versus baseline
• zIIP rises by 103 µs
• This is approximately a 34.7% increase in Java zIIP time

Interpretation: This strongly suggests that enabling WLM Honor Priority = NO can materially reduce GCP usage by keeping more eligible work on zIIP processors rather than allowing spillover to general-purpose CPUs.

2. High Compute vs. High Compute with WLM HP=NO

High compute:

• Java GCP: 751 µs
• Java zIIP: 1.23 ms

High compute + WLM HP=NO:

• Java GCP: 285 µs
• Java zIIP: 1.79 ms

Illustrative effect:

• GCP drops by 466 µs
• This is approximately a 62.0% reduction in Java GCP time
• zIIP rises by 0.56 ms
• This is approximately a 45.5% increase in Java zIIP time

Interpretation: For more compute-intensive Java activity, the same pattern appears even more clearly: WLM policy can substantially reduce demand on GCPs, with a corresponding increase in zIIP processing.

3. Connection Pooling Impact

Compared with the high-compute WLM HP=NO case:

High compute + WLM HP=NO:

• Java GCP: 285 µs
• Java zIIP: 1.79 ms

Connection Pooling:

• Java GCP: 267 µs
• Java zIIP: 1.73 ms

Illustrative effect:

• GCP drops by 18 µs
• This is approximately a 6.3% reduction in Java GCP time
• zIIP drops by 0.06 ms
• This is approximately a 3.4% reduction in Java zIIP time

Interpretation: Connection pooling appears to reduce both GCP and zIIP demand by eliminating repeated connection setup, authentication, and related processing overhead.

4. Shared Class Cache Impact

Compared with the connection pooling case:

Connection Pooling:

• Java GCP: 267 µs
• Java zIIP: 1.73 ms

Shared Class Cache:

• Java GCP: 261 µs
• Java zIIP: 1.89 ms

Illustrative effect:

• GCP drops by 6 µs
• This is approximately a 2.2% reduction in Java GCP time
• zIIP rises by 0.16 ms
• This is approximately a 9.2% increase in Java zIIP time

Interpretation: The shared class cache appears to produce a small additional reduction in GCP demand. The increase in zIIP time suggests that the broader runtime behavior may be shifting in a way that still favors lower GCP consumption, though the exact explanation would need workload-specific analysis.

Observed CPU Reduction

Taken together, the measured results show a clear reduction in Java GCP time across the tuning steps.

• Baseline Java GCP time: 738 µs
• Final Java GCP time after tuning: 261 µs
• Observed reduction: 477 µs
• Observed percentage reduction: approximately 64.6%

Additional stage-by-stage observations:

• Baseline to Base + WLM HP=NO shows an observed Java GCP reduction of approximately 60.3%
• High compute to High compute + WLM HP=NO: shows an observed Java GCP reduction of approximately 62.0%
• Adding connection pooling shows a further observed Java GCP reduction of approximately 6.3%
• Adding shared class cache shows a further observed Java GCP reduction of approximately 2.2%

These measurements were captured during testing on our machine and are provided to illustrate observed behavior in that environment.

Results may vary depending on workload design, transaction mix, JVM level, middleware stack, Db2 and IMS configuration, z/OS release, hardware model, LPAR contention, WLM policy, and application behavior.

The observed shifts in Java GCP and Java zIIP time should not be interpreted as a guarantee, warranty, or commitment of specific operational, financial, or capacity outcomes.

Any production decision should be validated through controlled testing in the target environment.

Conclusion

Java workloads continue to grow in importance within enterprise environments running on z/OS. While the platform provides powerful capabilities for scalability, reliability, and integration, achieving optimal efficiency requires thoughtful tuning of both the JVM runtime and subsystem configurations.

By combining zIIP-aware workload design, WLM tuning, Db2 connection reuse, JVM shared class caching, and additional JVM performance parameters, enterprises can significantly reduce CPU consumption while maintaining high levels of throughput and application performance.

The measured results included here help make that value more concrete by showing how Java GCP demand can be reduced and more work can be directed toward zIIP processing under tuned conditions.

These techniques help ensure that Java applications running on z/OS fully leverage the platform's strengths while controlling operational costs and maximizing the use of specialty processors.