Introduction
|
Note: Since the last update of this IBM Redbooks publication in February 2009, four new releases of CICS Transaction Server have been made available:
•CICS TS 4.1 (June 2009)
•CICS TS 4.2 (June 2011)
•CICS TS 5.1 (Dec 2012)
•CICS TS 5.2 (June 2014)
Significant changes to the CICS support for Java applications were introduced in each release:
•New JVM server runtime allowing 256 concurrent tasks per JVM.
•Support for the OSGi platform specification allowing component-based development of Java applications.
•64-bit Java.
•Java-based Axis-2 support for web services pipeline processing.
•New web container based on the IBM WebSphere Application Server Liberty profile providing a simple, dynamic, flexible and extensible runtime environment for the development of modern presentation applications.
Architects, designers, and application developers looking to create new Java applications may use this publication as a reference to the technology available in CICS TS V3 but they should not use the information in this book, especially as related to the now obsolete Pooled JVM technology, as the basis for decision making. It is strongly recommended that, in addition to the CICS Transaction Server IBM Knowledge Center documentation, the following publications are reviewed to clearly understand the significant enhancements available in the newer versions of CICS:
•A Software Architect's Guide to New Java Workloads in IBM CICS Transaction Server, SG24-8225
•IBM CICS and the JVM server: Developing and Deploying Java Applications, SG24-8038
|
In this chapter, we familiarize you with the basic concepts of and developments in object-oriented (OO) technology in relation to the z/OS and CICS Transaction Server for z/OS (CICS TS). Java rapidly grew in popularity throughout the Information Technology (IT) industry and is now the programming language of choice for many organizations. CICS extended the support for Java-based workloads over a number of releases in response to the uptake of the Java programming model. CICS Transaction Server for z/OS Version 3 adds further support for Java, which includes the provision of greater controls for the Runtime Environment that Java application programs use.
The main topics that we cover in this chapter are:
•Positioning of z/OS, CICS TS, and Java
•Using Java in a CICS environment
1.1 z/OS
z/OS is a highly secure, scalable, high-performance enterprise operating system on which you can build and deploy Internet and Java-enabled applications, providing a comprehensive and diverse application execution environment.
z/OS:
•Provides a highly secure, scalable, high-performance base for on demand applications
•Can simplify IT infrastructure by allowing the integration of applications in a single z/OS image
•Takes advantage of the latest open software technologies to extend existing applications and to add new on demand applications
•Incorporates world-class optimization features, security services, distributed print services, storage management, and Parallel Sysplex® availability
z/OS is the robust IBM eServer™ zSeries mainframe operating system that is designed to meet the demanding quality of service requirements for on demand business. With the IBM eServer zSeries servers, z/OS serves as the heart your on demand infrastructure.
z/OS takes advantage of the latest open and industry software technologies, such as Enterprise JavaBeans, XML, HTML, C/C++, and Unicode. z/OS UNIX System Services allows you to develop and run UNIX programs on z/OS and exploit the reliability and scalability of the z/OS platform.
z/OS also incorporates world-class optimization features, security and IP networking services, distributed print services, storage management, and Parallel Sysplex availability.
Some of the unique classic strengths of z/OS are:
On demand infrastructure z/OS has optimization features to help provide the responsiveness needed for on demand applications. The z/OS Workload Manager (WLM) is at the heart of z/OS optimization and is designed to manage the priority of mixed workloads based on business policies that are defined in Service Level Agreement terms. Intelligent Resource Director (IRD) extends the z/OS Workload Manager to work with PR/SM™ on zSeries servers with features to dynamically manage resources across multiple logical partitions (LPARs). Based on business goals, WLM is designed to adjust processor capacity, channel paths, and I/O requests in real time across LPARs without human intervention.
Together with the IBM zSeries servers and with interoperability with Linux for zSeries and z/VM®, z/OS can play a critical role in simplifying your infrastructure. Both z/OS and Linux for zSeries support much of the server differentiation that sets the zSeries apart from other servers. With zSeries servers, z/OS provides the base for the z/Architecture® with support for 64-bit storage, Intelligent Resource Director (IRD), and HiperSockets™ (for inter-partition communications).
Performance High-volume transaction processing and heavy batch processes are common on z/OS. z/OS is efficient in managing its use of hardware and software resources.
Availability The high availability of z/OS is a key reason why so many clients rely on z/OS for their most critical applications. To continue to improve this availability, z/OS provides automation capabilities in a new element, Managed System Infrastructure for Operations. This element provides automation for single system and sysplex operations to help simplify operations and improve availability.
Self-configuring z/OS Managed System Infrastructure for Setup (msys for Setup) is the z/OS solution for simplifying product installation, configuration, and function enablement. msys for Setup uses wizard-like configuration dialogs, which helps to reduce configuration errors. msys for Setup provides multi-user and multi-system support. Also, msys for Setup can use the IBM Directory Server, OpenLDAP, on any IBM platform, which includes OpenLDAP on z/OS, which can simplify the initialization of msys for Setup.
Scalability z/OS is a highly scalable operating system that can support the integration of new applications. z/OS can scale up in a single logical partition and scale out in a Parallel Sysplex cluster for higher availability.
64-bit support The z/OS scale is extended with support for 64-bit real and virtual storage on System z servers, while continuing to support 24-bit and 31-bit applications. The 64-bit real support eliminates expanded storage, helps eliminate paging, and might allow you to consolidate your current systems into fewer LPARs or to a single native image. z/OS delivers 64-bit virtual storage management support. This 64-bit support is used by DB2 V8 and other middleware.
Security z/OS extends its robust mainframe security features to address the demands of on demand enterprises. Technologies, such as Secure Sockets Layer (SSL), Kerberos, Public Key Infrastructure, multilevel security, and exploitation of System z cryptographic features, are available in z/OS. Integrated Cryptographic Service Facility (ICSF) is a part of z/OS, which provides cryptographic functions for data security, data integrity, personal identification, digital signatures, and the management of cryptographic keys. Together with cryptography features of the IBM System z servers, z/OS provides high-performance SSL, which can benefit applications that use z/OS HTTP Server and WebSphere, TN3270, and CICS Transaction Gateway server.
z/OS provides support for digital certificates, including the ability to provide full life cycle management. With Public Key Services in z/OS, you can create and manage digital certificates and leverage your existing z/OS mainframe investments, which can provide significant cost savings over other digital certificate hosting options.
TCP/IP networking z/OS provides TCP/IP network support with high performance, security, and scale. High availability is provided across a Parallel Sysplex where TCP/IP traffic uses the Sysplex Distributor and Dynamic VIPA (virtual IP addressing). Together with the Workload Manager, these functions are designed to provide failure independence in the face of TCP/IP or system outages. Load balancing of network traffic can be self-optimized with z/OS, which enables consistent response times for critical traffic in a complex multi-application network.
z/OS evolved to a fully open operating system that supports:
•Internet Web serving
•High security and integrity required for electronic commerce
•Distributed object-oriented application architectures
This support, combined with the classic strengths of z/OS, makes it an excellent operating system for your current and future mission-critical applications and data.
1.2 CICS Transaction Server Version 3
CICS Transaction Server for z/OS Version 3 provides an efficient and effective environment for applications that are written in COBOL, PL/I, C, C++, and Java. This version strengthens application development capabilities, enables enhanced re-use of 3270 applications, and enables applications to be accessed as Web Services within a services-oriented architecture (SOA).
The transaction processing strengths of CICS in an enterprise computing environment are appreciated and exploited worldwide. CICS has always provided a reliable transaction processing environment that:
•Provides a robust, high-performance runtime environment for enterprise applications written in Java.
•Supports EJB session beans, providing another dimension for application architects. Where an EJB component needs to incorporate procedural logic modules to accomplish its business function, CICS enables this mixed-language component to run in a single execution environment with good isolation from other components, improving robustness and manageability.
•Provides a runtime environment that is optimized for business logic written as EJBs that can run alongside, and interoperate with, business logic that is written in languages, such as COBOL. Both EJB applications and COBOL applications can access existing (and new) DB2, IMS DB, and VSAM data concurrently and with complete integrity.
•Provides enhancements for applications that use TCP/IP communication for e-business enablement. These offer a range of benefits in terms of management and improved scalability and performance.
•Provides enhanced DB2 facilities, which provides a significant improvement in performance and a greater level of availability.
•Assists the evolution to on demand computing through integration, openness, autonomic computing and virtualization.
1.3 Java overview
Java has become a popular programming language and runtime environment for building new applications on all platforms, including the System z and System z mainframes. Of course, in many mainframe installations new programs are created in languages, such as COBOL, C/C++, or PL/I, but with the increasing use of middleware, such as WebSphere Application Server, the Java programming model is also expanding. However, Java is not only used in relatively new middleware, such as WebSphere Application Server, but also in the traditional transaction managers, such as CICS, IMS, and DB2. Using Java in CICS is the theme of this book. In a standalone environment, you can use Java for programs that are submitted from a UNIX System Services command line or in JCL. This form of Java is not running inside middleware, a transaction, or a database server.
The Java specifications are maintained by Sun Microsystems, but other companies, IBM in particular, provide input for these specifications. The Java language is based on a philosophy:
Develop once, run everywhere
Java was originally developed in the early 90s by Sun Microsystems Inc.® as an object-oriented programming language. The syntax used in Java code originates from C++ and is therefore recognizable for those with C++ experience. However, there are big differences between C++ and Java:
•The Java programming model was expanded with numerous APIs that are organized in libraries. The Java 2 Enterprise Edition (J2EE) programming model goes even further and defines a syntax for writing programs and a way of packaging applications and much more.
•Java programs are not compiled into persistent load modules; however, technologies were added over the years to do compiles “on the fly” while running the applications. The first technology to support this was the Just-In-Time compiler (JIT). Later on, more technologies were included in the Java Virtual Machine (JVM) to speed up this process.
•Java, or actually the JVM, has its own memory management. The programmer does not need to worry about memory allocation and de-allocation because the JVM does this.
Over the years, Java grew to be popular, and the JVM is available on nearly all available operating systems, such as Microsoft Windows, Apple OS-X, OS/400®, Linux, UNIX, and z/OS UNIX.
1.3.1 Java language
The Java programming language is unusual because Java programs are both compiled (translated into an intermediate language called Java bytecodes) and interpreted (bytecodes parsed and run by the JVM). Compilation occurs once, although interpretation happens each time the program is run. Compiled bytecode is a form of optimized machine code for the JVM. The interpreter is an implementation of the JVM.
Java is object oriented but without all of the complications. It has a single inheritance model, simple data types, and code that is organized into classes. These classes provide an excellent way of packaging functions.
As a language, Java is statically typed and most types of checking occur at compile time. However, runtime checks, such as array bounds, are still required. A key function of Java is that numeric precision is defined with the IEEE floating point notation, which ensures the same results everywhere for mathematical calculations.
The sample Java source code in Example 1-1 on page 9 shows some Java source code (the typical "Hello World" program) and the basic structure and elements of a Java application. It begins with block documentation comments that are started with /** and end with */. If this program were processed by the Java-Javadoc utility, a standard part of the Software Development Kit (SDK), these comments along with the structure of the program, its methods, and other documentation comments, would be automatically included in a documentation file in HTML format.
A second form of comment can also be seen in the program: // display string. This is a private comment and is not included in the HTML file that Javadoc produces.
Java also supports a third style of comment: The classical C comment that starts with /* and ends with */. These are also private and are not included in Javadoc HTML files.
Example 1-1 shows sample Java source code.
Example 1-1 Sample Java source code
/**
* HelloWorldApp class implements an application that simply
* displays "Hello World" to the standard output device.
*/
public class HelloWorldApp {
public static void main(String[] args) {
System.out.println("Hello World!"); //display string
}
In Example 1-1, after the documentation comment, the name of the class is defined: HelloWorldApp. This part of the program gives us important information, such as whether this is an application, an applet, or a servlet. In this case, the sample program is an application (it has a main() construct in its source code), and you can execute it from a command line.The name of the class is case sensitive and must match the name of the file. The file type is .java, which makes the full file name HelloWorldApp.java. The file name (for example, javac HelloWorldApp.java) is used when you compile the program. A Java program is compiled into a .class file. The class name without its file type of .class (for example, java HelloWorldApp) is used when you run the program.
The next part of the program defines the properties of the Java program or class. In this case, it is a public class that can be called by any other class. Our sample program returns no data, and it takes as input a character string of command line arguments.
Finally, our sample program performs its function: In this case, to print out "Hello World" by creating an instance of a Java class. If you are only familiar with procedural programming, you can think of this as a call to a system-provided function. In reality, it is different, but that is beyond the scope of this introduction.
The source code shown in Example 1-1 is compiled into machine-independent bytecode with the Java compiler, javac. The bytecode is conceptually similar to an object deck in z/OS terms. It is executable but still needs to be link-edited.
Java bytecode is dynamically linked, which means that functions that are external to the program are located and loaded at runtime rather than being statically bound to the Java bytecode. Thus, functions can be loaded on demand over the network when needed, with unused code never loaded. If the Java program is an application or servlet, it can still be dynamically linked by loading classes over a network-based file system, such as network file system (NFS), distributed file system (DFS), or Andrew file system (AFS™). Typically, however, all of the required classes are installed locally for applications and servlets.
After it is loaded and linked, Java bytecodes are ready for execution. Originally Java bytecode was always interpreted (translated) into native instructions. However, by default almost all JVMs include a just-in-time (JIT) compiler. The JIT compiler dynamically generates machine code for frequently used bytecode sequences in Java applications and applets while they are running.
The IBM Software Developer Kit for z/OS (SDK), Java 2 Technology Edition, which became generally available in September, 2002, provides the SUN SDK1.4 APIs and is periodically updated with cumulative service and improvements. The SDK for z/OS includes the JIT, which is enabled by default. You can disable the JIT to help isolate a problem with a Java application, an applet, or the compiler itself.
Because Java bytecode is in a machine-independent, architecture-neutral format, it can be run on any system with a standard Java implementation. An extensive library of underlying classes or functions can be used to do everything from graphics to network communication. Because these classes are Java bytecode, they too are machine independent.
1.3.2 Java Virtual Machine
At the core of the Java concept and implementation is the JVM, a complete software microprocessor with its own instruction set and operation (op)-codes. The JVM provides automatic memory management, garbage collection, and other functions for the programmer.
The IBM JVM, and most other JVMs, are implemented through licensed source code from Sun Microsystems. The source code is provided in C and Java and is highly portable. IBM ported it to many platforms: IBM AIX®, OS/2, OS/400, z/OS, and others.
The JVM uses z/OS UNIX System Services for z/OS for base operating system functions; therefore, you must correctly install and tune UNIX System Services to get optimum performance from the JVM.
The JVM is the "essence" of Java because it provides the machine independence that is the most significant advantage of Java. Although the JVM is not a unique concept and there were other software microprocessors over the past 20 years, it is the first and only one to achieve broad acceptance. This acceptance is primarily a result of Sun Microsystems making the source code for the JVM available under license. It is much quicker to implement through the source code than from scratch working from a reference document.
For more information about the Java Virtual Machine see Chapter 2, “Java Virtual Machine support in CICS” on page 17.
1.3.3 Java on z/OS
IBM is a major supporter and user of Java across all of the IBM computing platforms, which includes z/OS. The z/OS Java implementation provides the same full function Java APIs that are on all other IBM platforms. Additionally, the z/OS Java program products were enhanced to allow Java access to z/OS-unique file systems. Also, Java on z/OS provides a z/OS implementation of the Java Native Interface (JNI).
The Java implementation on z/OS, as on other platforms, includes an Application Programming Interface (API) and a Java Virtual Machine (JVM) to run programs. The existence of a Java Virtual Machine means that applications written in Java are largely independent of the operating system used.
|
Note: To stimulate the use of Java on the mainframe, IBM introduced a new specialty processor for running Java applications called the System z Application Assist Processor, also known as zAAP. This type of processor is an optional feature in the System z9® and z10™ hardware. After installed and enabled, it allows you to benefit from additional resources that are available for Java code, and in some select cases, non-Java code closely related to the execution of Java. For zAAP processors, no software license fees are paid for certain IBM software products. Using zAAP processors, you can expand the system’s CPU capacity at a relatively low cost, if the workload that is run is based on Java.
On the hardware level settings, in PR/SM, zAAPs are treated and managed as a separate pool of logical processors. So the weight factors can be different from what you have in place for the General Purpose (GP) processors.
For zAAP processors, special hardware and operating system requirements exist. For more information about the zAAP processors, see Java Stand-alone Applications on z/OS, Volume I, SG24-7177.
|
Java Software Development Kit on z/OS
Java Software Development Kits (SDKs) contain application programming interfaces (APIs). You can order and service each SDK product independently and separately. The Java SDKs for z/OS are available electronically through the Internet or by placing a regular software order at IBM Software Manufacturing. Visit the following Web site for more information about these products and for download instructions:
At this time the following SDK products for z/OS are available:
•IBM SDK for z/OS, Java 2 Technology Edition, V1.4 (5655-I56), SDK1.4.2
•IBM 64-bit SDK for z/OS, Java 2 Technology Edition, V1.4 (5655-M30), SDK1.4.2
•IBM 31-bit SDK for z/OS, Java 2 Technology Edition, V5 (5655-N98), SDK5
•IBM 64-bit SDK for z/OS, Java 2 Technology Edition, V5 (5655-N99), SDK5
All of these SDK products are available in a non-SMP/e installable format and an SMP/e installable flavor.
As time and technology progress, products are withdrawn from service and new ones are introduced.
1.3.4 Runtime Environment and tools
The SDK contains a Java Runtime Environment (JRE) and several development tools. In this section, we describe the contents of the Runtime Environment and the SDK tools.
Runtime Environment
The Runtime Environment contains:
•Core classes: The compiled class files for the platform that must remain zipped for the compiler and interpreter to access them. Do not modify these classes; instead, create subclasses and override where you need to.
•JRE tools: The following tools are part of the Runtime Environment and are in the /usr/lpp/java/J5.0/bins directory (where /usr/lpp/java/J5.0/ is the directory in which you installed the SDK):
– JVM runs Java classes. The Java Interpreter runs programs that are written in the Java programming language.
– Java Interpreter (javaw) runs Java classes in the same way that the java command does, but does not use a console window.
– Key and Certificate Management Tool (keytool) manages a keystore (database) of private keys and their associated X.509 certificate chains that authenticate the corresponding public keys.
– Hardware Key and Certificate Management Tool (hwkeytool) works, such as keytool, but also allows you to generate key pairs and store them in a keystore file of type JCA4758KS.
– Policy File Creation and Management Tool (policytool) creates and modifies the external policy configuration files that define your installation’s Java security policy.
– RMI activation system daemon (rmid) starts the activation system daemon so that objects are registered and activated in a Java virtual machine (JVM).
– Common Object Request Broker Architecture (CORBA) Naming Service (tnameserv) that starts the CORBA transient naming service.
– Java Remote Object Registry (rmiregistry) creates and starts a remote object registry on the specified port of the current host.
– Dump extractor (jextract) converts a system-produced dump into a common format that jdmpview can use. For more information, see the relevant chapter in the IBM JVM Diagnostics Guide that is located at:
Earlier versions of the IBM JRE shipped with a file called rt.jar in the jre/lib directory. From Java v1.4 onwards, this file is replaced by multiple JAR files that reside in the jre/lib directory. Examples of these JAR files are:
•core.jar: contains the majority of the class libraries, which includes the system, IO, and net class libraries.
•graphics.jar: contains the awt and swing class libraries.
•security.jar: contains the security framework code. For maintenance reasons, security.jar is split up into smaller JAR files for this release.
•v server.jar: contains the RMI class libraries.
•xml.jar: contains the xml and html class libraries.
This change must be completely transparent to the application. If an error is received about a missing rt.jar file in CLASSPATH, this error points to a setting that was used in Java V1.1.8 and was made obsolete in subsequent versions of Java. You can safely remove references to rt.jar in CLASSPATH.
Software Development Kit tools
The following tools are part of the SDK and are located in the /usr/lpp/java/J5.0/bin directory:
•Java Compiler (javac) compiles programs that are written in the Java programming language into bytecodes (compiled Java code).
•Java Applet Viewer (appletviewer) tests and runs applets outside of a Web browser.
•Class File Disassembler (javap) disassembles compiled files and can print a representation of the bytecodes.
•Java Documentation Generator (javadoc) generates HTML pages of API documentation from Java source files.
•C Header and Stub File Generator (javah) enables you to associate native methods with code written in the Java programming language.
•Java Archive Tool (jar) combines multiple files into a single Java Archive (JAR) file.
•JAR Signing and Verification Tool (jarsigner) generates signatures for JAR files and verifies the signatures of signed JAR files.
•Native-To-ASCII Converter (native2ascii) converts a native encoding file to an ASCII file that contains characters that are encoded in either Latin-1, Unicode, or both.
•Java Remote Method Invocation (RMI) Stub Converter (rmic) generates stubs, skeletons, and ties for remote objects, which includes RMI over Internet Inter-ORB Protocol (RMI-IIOP) support.
•IDL to Java Compiler (idlj) generates Java bindings from a given IDL file.
•Serial Version Command (serialver) returns the serialVersionUID for one or more classes in a format that is suitable for copying into an evolving class.
•Extcheck utility (extcheck) detects version conflicts between a target jar file and currently installed extension jar files.
•Cross-platform dump formatter (jdmpview) is a dump analysis tool that allows you to analyze dumps. For more information, see the relevant chapter in the IBM JVM Diagnostics Guide located at:
•INCLUDE FILES: C headers for JNI programs.
•DEMOS: The demo directory contains a number of subdirectories that contain sample source code, demos, applications, and applets, that you can use.
•COPYRIGHT: Copyright notice for the SDK for z/OS software. The user guides and the accompanying copyright files and demo directory are the only documentation that are included in this SDK for z/OS. You can view Sun’s software documentation by visiting the Sun Web site, or you can download Sun’s software documentation package from the Sun Web site:
The following tools are not included in the IBM SDK:
•MIF doclet
•orbd
•servertool
1.4 CICS Transaction Server for z/OS 3.2 enhancements for Java
CICS Transaction Server for z/OS, Version 3 Release 2 can support the JVM that is provided by the 31-bit version of IBM SDK for z/OS, Java 2 Technology Edition, Version 5.
1.4.1 Usability enhancements
JVM profile and properties changes:
•You can now specify any JVM option or system property
•You can specify system properties in JVM properties or profile
Improved error messages and trace output:
•Validation checks to address common user errors
•CICS formats JVM trace output
New Garbage collection in CICS TS 3.2
Garbage Collection scheduling algorithm in CICS changed:
•Occurs at a target heap utilization:
– GC_HEAP_THRESHOLD parameter in the JVM profile (default 85%)
– 100% implies no CICS-scheduled GC
•Performed asynchronously in a CICS system task:
– The application does not suffer bad response times simply because a scheduled GC happened to take place
New transaction CJGC:
•Unscheduled GC within the JVM can still occur at any time:
– But with a little tuning you can minimize the likelihood of this happening
1.4.2 Java Virtual Machines management enhancements
Specify a JVM timeout value:
•IDLE_TIMEOUT=30
•After timeout JVMs become eligible for termination
Pre-initialize JVMs by profile:
•PERFORM JVMPOOL START JVMCOUNT() JVMPROFILE()
•Performed asynchronously using CJPI transaction
Selectively phase out JVMs by profile:
•PERFORM JVMPOOL PHASEOUT JVMPROFILE()
1.4.3 Continuous Java Virtual Machines versus resettable Java Virtual Machines
Continuous JVMs perform better than resettable and more consistent with other versions of Java:
•Lower CPU cost per transaction
•Simpler to set up and tune (fewer different storage heaps)
•Compatible with future versions of Java
Resettable mode was deprecated in CICS TS 3.2:
•IBM JVM CICS Application Isolation Utility (support pac CH1B)
1.4.4 CICS Java applications using JCICS
You can write Java application programs that use CICS services and execute under CICS control.
You can write Java programs on a workstation or in the z/OS UNIX System Services shell. You can use any editor of your choice or a visual composition environment, such as Rational Application Developer.
CICS provides a Java class library, known as JCICS, supplied in the dfjcics.jar JAR file. JCICS is the Java equivalent of the EXEC CICS application programming interface that you use with other CICS supported languages, such as COBOL. It allows you to access CICS resources and integrate your Java programs with programs that are written in other languages. Most of the functions of the EXEC CICS API are supported. We discuss the JCICS API extensively in Chapter 6, “The Java CICS API” on page 89.
The Java language is designed to be portable and architecture-neutral. The bytecode that is generated by compilation is portable, but it requires a machine-specific interpreter for execution on different platforms. CICS provides this execution environment by means of a Java Virtual Machine that executes under CICS control.
1.4.5 CICS support for the Java Virtual Machine
Java has rapidly grown in popularity throughout the IT industry, and for many organizations, it is now their programming language of choice. CICS Transaction Server extended the support for Java technology-based workloads over a number of releases in response to the uptake of the Java programming model. CICS Transaction Server, Version 3.2 adds further support for Java, making this version essential for anyone who is already running Java workloads in earlier-version CICS environments.
From a historical perspective, the expectations that users had for CICS Transaction Server and Java matured over time. When IBM first introduced Java support in CICS Transaction Server, it was expected that Java might behave as similar to COBOL as possible from within the CICS runtime environment. Today, the expectation is that Java in CICS Transaction Server is much like Java on other platforms.
The unique characteristics of the persistent reusable Java Virtual Machine (JVM) that were traditionally supported in earlier versions of CICS Transaction Server make it more difficult to write Java programs that run as intended in CICS Transaction Server. As a result of this and other performance-related issues, many users of Java in a CICS Transaction Server, Version 2.3 environment elected to use the continuous JVM exclusively and abandoned the persistent reusable JVM altogether.
Recent versions of the JVM do not include the persistent reusable JVM extensions. To make CICS Transaction Server consistent with this Java change, CICS Transaction Server, Version 3.2 also does not support the persistent reusable JVM (support is for the continuous JVM only). Support for the class cache remains unaffected.
The persistent reusable JVM was first made available for use in CICS Transaction Server, Version 2.1. It offers the ability to reset the state of a JVM between tasks to help ensure that subsequent users of the same JVM are fully isolated from states left behind by previous users of the JVM. The time taken to reset a JVM depends on there being no cross-heap references between the middleware and the application heaps within the JVM. If these references exist, the JVM scans the heap to determine if the references are in live objects. The scan process is rather slow. If the attempt to reset the JVM fails, CICS Transaction Server discards the JVM and creates a new one. These unresettable events (UREs) are a major performance problem for some users of CICS Transaction Server and Java.
The continuous JVM was introduced in CICS Transaction Server, Version 2.3. It offers the ability to omit resetting the JVM between CICS tasks, helping to ensure that there are no performance problems due to cross-heap references.
It also offers the ability to cache states between transactions to help improve performance. As a Java application-execution environment, it is more consistent with Java in other environments and on other platforms (for example, the class loading, threading, just-in-time [JIT] and garbage-collection components are the standard ones). CICS Transaction Server is still designed to ensure complete isolation between concurrently running tasks that run in different JVMs in both JVM modes, but isolation issues might exist between serial tasks that are running in the same JVM. In practice, most CICS Java workloads now use the continuous JVM to benefit from the considerable performance advantages. With the new release of CICS Transaction Server, Version 3.2, the focus is now firmly on continuous JVM and the operational advantages that this feature confers.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.