Running Java in CICS for the first time

Running Java in CICS for the first time

Robert Crawford, Contributor
The competition amongst transaction processors is getting tough. It used to be CICS just had to worry about its archrival on the mainframe. Now we have Websphere, along with any number of other application servers on a myriad of platforms. Fortunately, for those of us too lazy to switch jobs, IBM keeps CICS up to date with the latest technologies, such as Java. A few months ago, I set up a Java transaction at the request an application team. This column outlines what I discovered along the way.
More on programming languages and CICS:
Writing CICS transactions in Java vs COBOL

Running C++ Applications in CICS

Let me start with something that may already be obvious to a lot of you. Java programs run under z/Os' UNIX System Services (USS). UNIX cares deeply and profoundly about letter case in file names. The directory /lpp/cicsts is not the same as /LPP/CICSTS or even /LpP/CiCsTs. This means that you will need to turn off upper-case translation for CEDA or define resources through alternate means, such as the resource definition online (RDO) batch utility DFHCSDUP.

You also must be careful to preserve case when you change the system initialization table (SIT) or SIT overrides. The profile directory is a good place to start. You specify the profile directory in SIT parameter JVMPROFILEDIR. This parameter points to a directory containing the specific profile files specified in the Java program definition. CICS passes values in the profile to the Java Virtual Machine (JVM) when a transaction invokes a Java program.

Some of the more important values in these profiles include:

  • The directory for CICS' Java classes
  • The directory for Java
  • A LIBPATH for additional executables
  • File names for STDOUT and STDERR. By default these files go into the /tmp directory.
  • A CLASSPATH for the Java programs you want to run. Note that you do not specify the directory where the class actually resides. Instead, Java uses qualifiers in the class name for some of the subdirectories. For instance, CICS' sample hello world program's fully qualified class name is examples.HelloWorld.HelloCICSWorld. Therefore, you would specify a CLASSPATH of /u/cics/appls to find the class /u/cics/appls/examples/HelloWorld/HelloCICSWorld.class.

    Note that CICS doesn't support the 64 bit JVM. Therefore, if the 64 bit JVM is your default you will have to look for the "classic" 31 bit JVM and put its directory in the profile.

    The profile also presents an interesting twist to preventative maintenance because the profiles' CICS_DIRECTORY symbol points to the CICS Java classes. If you start running Java in production you will need to work out a strategy to include, and possibly back out, maintenance applied to the CICS classes; whether it's a wholesale copy into a static directory or changing the profile to switch to another.

    The next item in line is the program definition, which includes two important pieces of information. The first is the profile which should be set up as described above. The second is the fully qualified name of the main class of the program. Again, the fully qualified class name includes some of the directory names as shown above for examples.HelloWorld.HelloCICSWorld.

    I was pleasantly surprised to see that I didn't need to do much else when I set up the first Java program, although I will say there were a few bumps along the way. The previously mentioned case sensitivity bit me a couple of times when CEDA changed everything to capital letters behind my back. I also had to dig through the UNIX file system for a while before I had all the directories correct. For getting the correct names into the right places, I'm forever indebted to whoever invented cut and paste. I also spent a little time trying to find the STDOUT and STDERR files.

    To date, my experience with Java on CICS is limited. But that won't prevent me from making the following recommendations:

  • Send STDOUT and STDERR some place easy to find. Given the flexibility of JVM profiles, you may even set up separate directories for each application. You also want to avoid "chatty" applications, as that would fill up the UNIX file system dataset and cause problems for everyone.
  • Copy the IBM sample profiles and create your own. The new names should have a strong naming convention making it easy to identify who the profile is for. Remember, you're not limited to the standard eight bytes. My personal preference would be to set one upper application unless required to do otherwise.
  • Create separate CICS class directories for each maintenance level of CICS, then build a process to change the CICS_DIRECTORY parameter in the JVM profiles. Similarly, you'll need another process to update the profiles should you need to back out of the maintenance. If you build profiles for each application you also have the flexibility to back out the maintenance for only the transactions in trouble.

    I also welcome any comments from readers who want to share their recommendations from real world experience.

    Running Java in CICS is a much more complex issue than what's in this column. There are some performance parameters I didn't touch on, as well as issues about JVM reuse and tuning the number of open TCB's. CICS can also take advantage of the zAAP processors introduced with the Z990 processor series, which is supposed to be another performance boost. As for our shop, I hope the application teams get serious about running Java on CICS because this could get interesting . . . in a good way.

    Let us know what you think about this tip; e-mail: Matt Stansberry, Site Editor

    This was first published in December 2006

    • Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

    Back to top