CICS® Transaction Server for z/OS Version 3 Release 1 supports the JVM provided by
the IBM Software Developer Kit for z/OS, Java 2 Technology Edition, Version 1.4.2, which features the persistent reusable JVM technology.
CICS Transaction Server for z/OS®, Version 2 Release 2 supported the JVM provided by the IBM® Developer Kit for OS/390® Java™ 2 Technology Edition Version 1.3.1s, which also featured the persistent reusable JVM technology. Java programs that ran under CICS Transaction Server for z/OS, Version 2 Release 2 and CICS Transaction Server for z/OS, Version 2 Release 3 can also run under CICS Transaction Server for z/OS Version 3 Release 1.
However, the older type of JVM that was introduced in CICS Transaction Server for OS/390, Version 1 Release 3, which was not reusable, is no longer supported. Any Java programs that ran under CICS Transaction Server for OS/390, Version 1 Release 3 must be migrated to Java 2 to run under the reusable JVM. Application migration issues are discussed at:
http://java.sun.com/j2se/1.4/compatibility.html
http://java.sun.com/products/jdk/1.3/compatibility.html#incompatibilities1.3
and
http://java.sun.com/products/jdk/1.2/compatibility.html
Support for the JVM provided by the IBM Software Developer Kit for z/OS, Java 2 Technology Edition, Version 1.4.2 completely replaces the JVM support provided in CICS TS 1.3. However, you can modify a JVM to run as a single-use JVM and not attempt serial reuse. A single-use JVM is initialized, is used to run a single Java program, and then is automatically destroyed without attempting a JVM reset. You can modify a JVM to be a single-use JVM by specifying either REUSE=NO, or the older option Xresettable=NO, in the JVM profile. The single-use JVM is like the earlier JVM that was supported by CICS in CICS TS 1.3. New Java applications should not be developed in such a way that they can only run in a single-use JVM.
To avoid problems with deprecated APIs, you should develop all new Java programs for CICS Transaction Server for z/OS Version 3 Release 1 using an application development environment that supports Java 2 at the same version of Java as used by CICS. You may run code compiled with an older version of Java in a new runtime, provided that it does not use APIs that have been removed in the newer version of Java. Note also that enterprise beans that support the EJB 1.0 specification need to be migrated to the EJB 1.1 specification level using the Assembly Toolkit (ATK) or the Application Assembly Tool (AAT), which are supplied with IBM WebSphere® Application Server.. Enterprise beans developed using any version of the EJB specification after EJB 1.1 must restrict themselves to the EJB 1.1 APIs.
The one-JVM-per-stack restriction has been removed. Previously, a stack of programs formed by a succession of EXEC CICS LINK commands, or JCICS program invocations, within the same CICS task, could not contain more than one JVM. (Distributed program link (DPL) requests were not restricted in this way.) As a CICS task could only use one JVM, applications designed in this way could only contain one Java component. Now, multiple JVMs can be allocated to a CICS task, so you can create an application that links together multiple Java programs in the same CICS region. You can also convert your existing complex applications piece by piece, by replacing programs written in other languages with programs written in Java.
Enterprise beans can now link to another Java program within the same CICS task. However, a single CICS task still cannot contain more than one enterprise bean, because CICS treats an execution of an enterprise bean as the start of a new task. You can create an application that includes more than one enterprise bean, but the application will not operate as a single task.
The EXECKEY parameter on the PROGRAM resource definition is no longer ignored for Java programs. In CICS Transaction Server for OS/390, Version 1 Release 3 and CICS Transaction Server for z/OS, Version 2 Release 2, CICS made all Java programs execute in CICS key, but they now execute as specified by the EXECKEY parameter.
The default for this parameter is EXECKEY(USER), which means that the program runs in a JVM that executes in user key. (A new type of open TCB, the J9 TCB, is used for these JVMs.) As running applications in user key extends CICS storage protection, it could be beneficial to let most of your Java programs run in a JVM in user key.
You might find that in most cases, the PROGRAM resource definitions for your Java programs are still set to the default of EXECKEY(USER). If you changed the EXECKEY parameter on the PROGRAM resource definitions for any of your Java programs to specify EXECKEY(CICS), you will need to change them back to EXECKEY(USER) if you want them to run in user key. No changes are needed to your JVM profiles, because you can use the same JVM profile to create JVMs in both storage keys.
However, you might need to execute a JVM in CICS key if the Java program that uses the JVM is part of a transaction that specifies TASKDATAKEY(CICS). If this is the case, you need to ensure that the PROGRAM resource definition for the Java program specifies EXECKEY(CICS). Before CICS Transaction Server for z/OS, Version 2 Release 3, this setting would not have mattered, because CICS would have forced the program to execute in CICS key.
For enterprise beans, CIRP (the default transaction for REQUESTMODEL definitions) specifies TASKDATAKEY(USER), and the PROGRAM resource definition for DFJIIRP (the default request processor program) specifies EXECKEY(USER), so by default enterprise beans run in user key.
A JVM can be reused by programs that specify the same execution key on their PROGRAM resource definition. You can use the INQUIRE JVM command to find out the execution key in which a JVM has been invoked. A single CICS task can include Java programs running in CICS key, and Java programs running in user key.
[[ Contents Previous Page | Next Page Index ]]