Jan 4 ’10
CICS Transaction Server for z/OS: A Robust Platform for Java
Java is popular throughout the IT industry and, for many organizations, is now their programming language of choice. CICS Transaction Server (TS) has steadily extended its support for Java-based workloads as part of the drive toward modernizing business applications and using them in a Service-Oriented Architecture (SOA).
CICS TS Version 3.2 adds further support for Java, making this version essential for anyone already running Java workloads in CICS environments. It includes enhancements, based on real use cases, for better manageability, serviceability, and usability when running Java technology-based workloads in CICS TS.
The expectations of CICS customers for Java have matured over time. When IBM first introduced Java support in CICS TS, Java was expected to behave much like COBOL; today, the expectation is that Java in CICS TS should be much like Java everywhere else.
Before CICS TS V3, the preferred Java implementation in CICS was the IBM persistent reusable Java Virtual Machine (JVM) to distribute the cost of starting the JVM over multiple runs. Providing applications were appropriately coded, the JVM was able to reset itself to a clean state after each application run. This usage model made it more difficult to write Java programs for CICS. Because of this and performance-related issues, many users of Java in a CICS TS environment elected to exclusively use the continuous JVM.
Recent versions of the JVM don’t include the persistent reusable JVM extensions. To make CICS TS consistent with this change, CICS TS V3.2 now supports only the continuous JVM, first introduced in Version 2.3. To enhance performance, it offers the ability to omit resetting the JVM between CICS tasks, and to cache states between transactions. The CICSPlex system manager Web User Interface (WUI) also has been made consistent with the changes by removing options related to the persistent reusable JVM.
As a Java application-execution environment, the continuous JVM is more consistent with Java in other environments and on other platforms. It ensures complete isolation between concurrently running tasks in different JVMs, though consideration must to be applied to tasks running serially in the same JVM and their use of static variables.
Adapting to a Continuous JVM
IBM provides the CICS JVM application isolation utility for checking the suitability of Java applications so they can be used in the continuous JVM environment. It details the use of a static state in an application (the main cause of isolation issues between serial users of a JVM) to help identify dependencies on the initialization of static variables.
The tool also is useful in general deployment scenarios for determining whether Java applications are suitable candidates for deployment in CICS TS. The tool helps the system administrator audit compiled Java programs to see whether they’re likely to experience problems when deployed to a continuous JVM environment.
In practice, most CICS Java workloads now use the continuous JVM to benefit from its considerable performance advantages.
Java Enhancements to CICS TS
Several manageability, serviceability and usability enhancements were made in response to feedback from CICS and Java users:
Improved performance through scheduled garbage collection: The garbage-collection process reclaims de-referenced storage so it can be reallocated and reused. Java applications tend to generate many objects that slowly consume storage heap. When the heap is getting full, the garbage-collection process is initiated to free storage for allocation of new objects. In CICS systems, Java garbage collection can occur because either the JVM has run short of storage or CICS schedules a collection.
Traditionally, CICS TS has scheduled garbage collections to occur after a specified number of JVM uses (configurable since CICS TS V2.3). With this approach, the cost of the garbage collection is included in the cost of the running task and application response times can suffer. CICS TS V3.2 introduced the ability to target garbage collections to occur at a specified percentage of heap utilization. This new process also runs in a separate CICS system task, meaning the cost of garbage collection can be accounted for separately.
Optimized workload with JVM timeout values: CICS administrators can now access a new JVM profile-idle-timeout option that specifies how long an idle JVM remains in the JVM pool before removing it and freeing its resource. Values can be specified to the nearest minute for any time up to seven days (a value of zero is infinite and means the JVM is never terminated).
This new parameter helps reduce the system processing overhead and increases performance because CICS carefully manages the number of idle JVMs to ensure it maintains a balanced capacity in the JVM pool. Those JVMs that have timed out but haven’t yet been terminated are still available for reuse by applications if an increase in workload occurs. Should a JVM be reused, then its timeout value is reset. CICS TS never automatically terminates the last JVM in the JVM pool.
Faster response with pre-initialized JVMs: The same administrators who experience problems with JVMs being discarded too soon typically require the ability to pre-initialize JVMs so the first CICS Java application task doesn’t incur the processing cost and delay of starting a JVM. CICS TS V3.2 includes a new System Programming Interface (SPI) command for creating a specified number of JVMs from the same JVM profile. Users can write a program that initializes the required number and type of JVMs in advance (e.g., at start-up), at a specified time, or after a JVM pool is phased out.
Greater flexibility with easier-to-use JVM profiles: While previous versions let users phase out all JVMs in the JVM pool regardless of profile, CICS TS now can selectively phase out JVMs with a specific profile. This provides much greater management flexibility and also helps maintain running workloads because the user doesn’t have to take down all JVMs in the pool to change only some.
The JVM profile in CICS TS V3.2 is simpler than the JVM profiles used in earlier versions. Some profile options were removed, and now JVM properties can be specified in the JVM profile itself rather than in a separate properties file.
There are additional validation checks to address common user errors such as the accidental use of a CICS directory entry that’s not at the latest level. The latest JVM profile configuration options are consistent with Java configurations on other platforms, so it’s now possible to use standard JVM configuration parameters throughout.
To help users identify the JVM profiles in use when diagnosing Java problems, JVM domain trace messages now include the JVM profile name; previously, it wasn’t always obvious which JVM profiles were used by tasks.
Java 5 has arrived on CICS TS V3.2. The latest support allows the choice of either Java 1.4.2 or Java 5, but only one version can run in a CICS region at a time. APAR PK59577 enables Java 5 support in CICS TS V3.2.
Key Java 5 improvements include a new generational garbage collector and a Just-In-Time (JIT) compiler that progressively optimizes methods the more they’re used. The new shared class cache is now an autonomous entity. This means it doesn’t require a master JVM (as was needed up to Java 1.4.2) and is independent of the CICS region that started it, so it persists even across CICS restarts.
Java 5 also offers new language enhancements:
• The for-each loop
• Type safe enums
• Variable arguments
• Static imports
These changes represent some of the biggest to the Java language syntax since it was first introduced.
Java enhancements to CICS TS V3.2 let businesses run Java applications as part of modern, flexible, services-based, business-oriented IT infrastructures. These Java enhancements also help deliver better productivity and cost savings through improved manageability, serviceability, and usability when running Java-based workloads in CICS systems. Enhancements in this release also let Java in CICS TS behave similarly to Java in other environments, resulting in shorter application development lead times, more effective system management, and better user expectations.