Let's face it. You've been avoiding Java in CICS, haven't you? We can hear you mumbling about performance, scalability, the lack of an Integrated Development Environment (IDE), and the propensity of Java-based scripting languages to proliferate. You don't want all this airy-fairy stuff polluting your finely tuned CICS regions, hogging storage, and gobbling MIPS.
That presents a problem. This article is about the radical new Java support in CICS, the long-term vitality and future of application development in CICS, and making Java a first-class language in which to write CICS applications and access your wealth of CICS data.
You don't want to hear about this because you have a succession of young COBOL programmers enthusiastic about writing 3270 applications for years to come, right? Maybe not. Perhaps it's fortunate there have been huge advances in Java Virtual Machine (JVM) performance since Java was introduced to CICS. It's fortunate IBM offers the specialty processors to run Java workloads at a fraction of the cost of general processors, and that Java programmers are far more abundant than COBOL programmers.
Furthermore, CICS has introduced a radical new Java model known as JVM server that significantly enhances both the development and run-time aspects of Java in CICS.
For several releases, CICS has used a “pooled” model of Java. Each transaction wishing to run some Java is gifted a whole JVM to itself. Each transaction is also offered an Application Program Interface (API) to access CICS resources. However, to serve concurrent transactions requires multiple JVMs. The JVMs are pooled to help reduce start-up and shutdown overhead. Yet this isolation of Java programs has a cost; there are only so many JVMs you can fit in a CICS address space and only so many Java transactions a single CICS region can process.
Not anymore. JVM server runs Java the way it was meant to be run. The JVM server is essentially a single, long-running JVM placed under the control of CICS. Its defining principle is the ability to run many CICS tasks concurrently. In this new model, each CICS transaction runs as a thread in the same JVM. As you might expect, compared with the pooled model, which requires an exclusive JVM per task, the storage savings can be significant (see Figure 1).
Sound good so far? It gets better. The JVM server also scales horizontally. Multiple JVM servers can be deployed into a single CICS region. Theoretically, you could even choose to deploy hundreds of JVM servers into one CICS region. Applications can be isolated in different servers, or each JVM server can be configured with a different set of run-time components—or even different sets of middleware components—keeping each server lightweight and specific to a particular need.
But didn't we just say there are only so many JVMs you can fit in a CICS address space? We weren't talking about JVM servers in CICS Transaction Server 4.2, which take full advantage of the IBM 64-bit JVM. For these JVMs, storage can be held above the bar. No longer constrained by a 31-bit address space, you can choose to run huge applications and hundreds of JVM servers.