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.