Java Virtual Machine support in CICS
In this chapter, we discuss Java Virtual Machine (JVM) support in CICS. In particular, we discuss the various modes of operation that a JVM can operate in and the implications of choosing one of those modes. We look at the Java class cache and how it can reduce the JVM size and optimize class loading times. Also, we discuss different categories of classes that are loaded into a JVM, the rationale behind having those categories, and related performance and application design issues.
2.1 Overview
Java applications running in a server environment, such as CICS Transaction Server, have characteristics that are quite different from client applications. The latter tend to be long-lived, performing a variety of tasks (for example, a GUI application, such as Rational® Application Developer). Server applications, on the other hand, typically perform a narrow set of functions in a more “predictable” way, and they are designed for throughput and tend to be short-lived.
Also, in a transaction processing system, it is vital that no transaction effects the outcome of other transactions that run in parallel or subsequently, other than by updating resources under transactional control, which did not lend itself well to the JVM concept. The first problem is that the cost of creating and initializing a JVM is very high. Therefore, if a JVM was started and destroyed for each invocation of a transaction program, this leads to an unacceptable throughput rate.
The obvious solution to this problem is to start up and initialize the JVM once, and then use it to run multiple programs sequentially. This is the approach in today’s Web application servers, such as IBM WebSphere Application Server.
There is a new problem with this approach, however. A misbehaved program might change the state of the JVM in such a way that the outcome of subsequent program invocations on that JVM can be affected (a rather extreme example is a change to the current time zone). In a transaction processing system, such situations must be avoided at all cost.
One way to get around this problem is to carefully review all application programs, making sure that they are “well-behaved.” Some global state changes might be all right, or even desired, such as reading configuration information that can be accessed by the next invocation of the same program without having to read it again. However, behavior, such as the reliance of static initialization of fields in a class, can bring unexpected application activity.
Further benefits are made when sharing classes across JVMs with the Java class cache, which has two benefits: First, it reduces memory footprint, and second, it further reduces the JVM startup cost (in terms of both CPU and I/O) because shared classes are loaded and initialized only once—the next JVM to start up can then use the shared version.
2.2 History of JVM support in CICS
In the next few sections, we review the history of JVM support in CICS, starting at CICS TS 1.3 and going through to the current version CICS TS 3.2.
2.2.1 CICS Transaction Server 1.3
CICS TS 1.3 was the first level of CICS Transaction Server to support Java, at the JDK 1.1 level. Initially, however, Java programs were not run under a JVM; instead, they were compiled using the High Performance Java (HPJ) product, which produces a Java Program Object. HPJ took the Java bytecodes and compiled them to S/390 machine code. The programs then ran natively in the control of CICS Language Environment®, just like a C application. Obviously, with this approach you lose platform independence.
Because the startup cost for an HPJ compiled application is very high, much like that of a JVM, a later PTF for CICS TS 1.3 introduced a technique called Hot Pooling. With Hot Pooling enabled, the HPJ environment is saved and reused between applications.
JVM support (for JDK 1.1 only) was introduced with another PTF to CICS TS 1.3. Because the JDK 1.1 JVM was not designed for reuse, a JVM was initialized, used, and then terminated for each CICS JVM program, which made it very expensive in terms of path length. Realistically this single use JVM was only good for programs that were either run very infrequently or were long-lived.
JVM support was only provided in CICS TS 1.3 to provide the ability to execute those parts of the Java API that were not supported by HPJ, to provide Java compliance.
2.2.2 CICS Transaction Server 2.1 and 2.2
These two releases of CICS support the Java JDK 1.3. (The JDK 1.1 JVM is no longer supported.)
HPJ and Hot Pooling (discussed in 2.2.1, “CICS Transaction Server 1.3” on page 18) are still supported in CICS TS 2.1 and CICS TS 2.1, but only for migration. Now, you are encouraged to migrate to JVM (which really must not be more than setting up the JVM environment and re-deploying your application as Java bytecodes instead of Java Program Objects).
Support for the resettable JVM (described in 2.3.3, “Resettable JVM” on page 23) was introduced.
One restriction for CICS programs running under the JVM, in these two releases, is that a JVM program cannot link, either directly or indirectly, to another JVM program in the same CICS region, which was true for CICS TS 1.3 too.
2.2.3 CICS Transaction Server Version 2.3
This level of CICS supports JDK 1.4.1 of the IBM Software Developer Kit for z/OS, Java 2 Technology Edition. It has support for the continuous JVM (see 2.3.2, “Continuous JVM” on page 21) and introduces the shareable class cache (see 2.5, “The shared class cache” on page 27), which allows for classes and the results of JIT compilation to be shared between several JVMs.
Also, the restriction mentioned in 2.2.2, “CICS Transaction Server 2.1 and 2.2” on page 19, was lifted. You can now have more than one JVM program in the LINK stack, meaning that one JVM program can LINK to another JVM program (directly or indirectly).
2.2.4 CICS Transaction Server 3.1
CICS TS 3.1 provides new Web Services capabilities to extend CICS applications to a service-oriented architecture (SOA), enabling them to be exposed directly as Web services.
Also, JCICS support was added for the new Channels and Containers mechanism for inter-program data transfer. See 6.6.4, “Communicating through Channels and Containers” on page 105 for an example on how to use the new API.
2.2.5 CICS Transaction Server 3.2
Java 5 support was added to CICS TS 3.2 through PTF PK59577, which gives support for both Java 1.4.2 and Java 5; however, only one level can run in a CICS region at a time. Java 1.4.2 support will be removed in the next release.
 
Note: Java 5 runs byte codes built on earlier releases without problem.
With Java 5 comes a simplified shared class cache mechanism, enhanced garbage collection (GC), and optimizing just in time (JIT) compiler technology.
Also introduced in CICS TS 3.2 are many features for managing JVMs inside CICS, which includes usability enhancements to the JVM profile and properties files and the ability to initialize and terminate JVMs by profile.
When using Channels and Containers in CICS TS 3.2, the container data is now placed in 64-bit storage. With the JCICS support of Channels and Containers, the JVM can store and retrieve information in 64-bit storage.
2.3 JVM operation modes
IN CICS TS 3.2 the JVM can run under one of two modes:
In earlier versions of CICS (2.3 & 3.1) a third JVM mode is supported, though a deprecation message is put out when used in CICS TS 3.1:
Anyone using resettable mode must migrate to a continuous mode JVM, taking into consideration the behavioral changes.
The REUSE parameter in the associated JVM profile determines what mode a JVM runs in. Figure 2-1 illustrates the three different JVM modes.
Figure 2-1 Single use, continuous mode, and resettable mode
2.3.1 Single use JVM
Single use means that for each transaction a JVM is created, the Java application is run, and then the JVM is thrown away, which effectively prevents the actions of one Java program from interfering with any other.
 
Enabling single use JVMs: To enable single use JVMs, add the value ‘REUSE=NO’ to your JVM profile.
Obviously, this mode is expensive because every application incurs the cost of starting and initializing the JVM, loading all the classes needed by it, and destroying it after the program terminated. Also, the results of JIT compilation are lost.
A typical use for this mode is testing changes to Java programs. Because no caching of classes is performed, you can be certain that when the program is restarted, the newly started JVM reloads any classes that changed on the file system. It is not recommended for use in a production environment, other than to run applications that were originally designed for single use JVMs and are not yet reviewed for suitability to run in a continuous JVM.
Single use JVMs are also required when you debug a Java program that is running in CICS. See Chapter 8, “Problem determination and debugging” on page 193 for more information about Java debugging.
2.3.2 Continuous JVM
The continuous JVM mode was introduced in CICS TS 2.3 as a way to mirror the modern behavior of Java application servers. It creates a potentially long-lived JVM, which uses a single storage heap.
 
Enabling continuous JVM: To enable continuous JVMs, add the value ‘REUSE=YES’ to your JVM profile.
In contrast to the resettable JVM mode described in 2.3.3, “Resettable JVM” on page 23, there is no mechanism for automatically resetting the state of the JVM when a Java program finishes execution.
Continuous mode offers the best performance for running Java programs in CICS; however, this comes at a price: Application designers need to be aware that actions that change the JVM’s state can change the behavior of the next program (be it the same or another) that uses the same JVM. Therefore, understand the application behavior (especially when using static variables) before you deploy into a production system.
 
Attention: Not specifying a REUSE value in your JVM profile causes it to default to ‘REUSE=YES’.
The fact that applications can pass state data can also be put to good use. Suppose, for example, an application as part of its initialization must read configuration data. This might be an expensive operation — it might involve reading DB2 tables, parsing huge XML configuration files, or doing JNDI lookups. By taking advantage of the continuous JVM, you can cache this configuration information by anchoring it in static variables, which avoids the initialization overhead on subsequent invocations of the program. Any objects that are anchored in static, that is, that are reachable from a static variable, are never subject to garbage collection. Example 2-1 demonstrates the technique.
Example 2-1 Caching shared configuration data
import java.util.*;
 
public class StaticLeveraging {
private static List<String> configuration; // (1)
public static void main(String[] args) {
if (configuration == null) populateConfigurationData(); // (2)
else System.out.println("Using cached configuration data");
showConfigurationData();
}
private static void populateConfigurationData() { // (3)
System.out.println("Populating with new configuration data");
ArrayList<String> newList = new ArrayList<String>();
// Insert some entries
for (int i = 0; i < 3; i++) newList.add("#" + i);
// Create a non-modifiable view of the list
configuration = Collections.unmodifiableList(newList); // (4)
}
 
private static void showConfigurationData() {
System.out.println("Values: ");
for (String s : configuration) System.out.println("[" + s + "]");
}
}
•This is the static variable where we store our configuration data.
•Check for null to see if we must initialize.
•Populate configuration data: In this example, we simply insert dummy String data. In a real application, this can be a much more expensive operation, such as reading and parsing a complex XML document.
•To make sure that the configuration data cannot inadvertently be changed by the program, we wrap them in an unmodifiable collection. In general, it is good practice to make static variables final or immutable, if possible, when programming for the continuous JVM.
When the program runs for the first time using a continuous JVM, it prints out the message in Example 2-2.
Example 2-2 Message written to stdout on first invocation
Populating with new configuration data
Values:
[#0]
[#1]
[#2]
When the program is run for a second time, the static initialization already occurred, which means that the program uses the cached data and prints out the message in Example 2-3.
Example 2-3 Message written to stdout on subsequent invocations
Using cached configuration data
Values:
[#0]
[#1]
[#2]
Be aware that there is no guarantee that subsequent executions of an application are assigned to the JVM that contains the items created by the first execution of the application. In other words, there is no guarantee that the next invocation of the program can see the data. Thus, your application must not rely on the presence of the persistent items that you create in the JVM; instead, it must check for their presence to avoid unnecessary initialization, but it must be prepared to initialize them if they are not found in the present JVM.
If you need to ensure that two applications using a continuous JVM cannot see each other’s persistent state (for example, because you are not sure they will not interfere with each other), set up separate JVM profiles for the applications to use. You can specify the same options because just by using different names you make sure that they run in distinct JVMs.
2.3.3 Resettable JVM
 
Important: The resettable JVM mode was removed in CICS TS 3.2 and is not available in any future CICS releases. It was intended as an intermediate solution for running applications that are not known to be safe for running in continuous mode JVM. With the introduction of Java 5, the resettable mode is no longer supported at the JVM level. Therefore, you must design and code new applications that can run in continuous mode, and be prepared to migrate existing code.
2.3.4 Summary of JVM modes
Table 2-1 summarizes the different supported JVM modes.
Table 2-1 Comparison of JVM modes
 
REUSE option in profile
Can program invocations pass state?
Relative performance
Compatible with the shared class cache?
Single use
NO
N/A (JVM destroyed)
Lowest (JVM initialized for each use)
No
Continuous
YES
Yes
High
Yes
2.4 Analyzing programs for use in a continuous JVM
In 2.3.2, “Continuous JVM” on page 21, we discussed the application considerations that are required when using a continuous mode JVM. The main area that needs attention is the use of static variables in a program, with special attention paid on the reliance of static initialization. To aid in the analysis of a program’s suitability for running in a continuous mode JVM, you can use the CICS JVM Application Isolation Utility to produce a report on the static usage in a program, or collection of programs. Supplied as part of the CICS TS 3.2 install, or available as a SupportPac CH1B, the CICS JVM Application Isolation Utility scans compiled Java programs and reports any updates to static variables.
 
Attention: For CICS release CICS TS 2.2 and later, the utility is available as SupportPac CH1B, which you can download from the IBM CICS SupportPac site:
2.4.1 Configuring the application isolation utility on UNIX System Services
The CICS JVM Application Isolation Utility that comes with the CICS TS 3.2 installation is located in the/usr/lpp/cicsts/cicsts32/utils/isolation directory (or the equivalent CICS install directory on your system) on Unix System Services. Example 2-4 shows the contents of this directory.
Example 2-4 Contents of isolation directory
-rw-r--r-- 1 xxxxxx xxxxxxx 2368 Oct 28 09:35 DFHIsoUtil
-rw-r--r-- 1 xxxxxx xxxxxxx 22655 Oct 28 09:35 dfhjaiu.jar
The file DFHIsoUtil is a shell script for running the utility. The file dfhjaiu.jar contains the compiled Java classes for the application. To run the DFHIsoUtil script, the CICS_HOME environment variable needs to be set to where CICS directory resides on UNIX System Services, Example 2-5 shows how to do this.
Example 2-5 Setting the CICS_HOME environment variable
export CICS_HOME=/usr/lpp/cicsts/cicsts32
When running the DFHIsoUtil, you make sure that it has the appropriate execution permissions. The directory listing in Example 2-4 lists the permissions of both files as -rw-r--r--. This means that they can both be read by everyone (user, group, and others), and modified by the user, but they cannot be executed. Because DFHIsoUtil is a script that we want to execute, update its permissions to look like -rwxr-xr-x. In Example 2-6, we show what happens when you try to run the script without execute permission, and then what happens after it is set.
Example 2-6 Setting execution permissions for DFHIsoUtil
./DFHIsoUtil: FSUM9209 cannot execute: reason code = ef076015: EDC5111I Permission denied.
 
# Now set the permissions using chmod:
chmod +x DFHIsoUtil //(1)
 
# List the permissions of the updated file:
ls -l DFHIsoUtil
 
-rwxr-xr-x 1 xxxxxx xxxxxxx 2368 Oct 28 09:35 DFHIsoUtil // (2)
 
# Now it can be run without error:
./DFHIsoUtil
CicsIsoUtil: CICS JVM Application Isolation Utility
 
Copyright (C) IBM Corp. 2007
 
Usage: java -cp dfhjaiu.jar CicsIsoUtil [-options] filename [filename... filename]
Where filename is the name of a Java class or jar file
to be inspected. Multiple files may be specified, or
wildcard (glob) characters may be used.
Options may be:
-v -verbose enable verbose output
-? -help display this help text
•chmod is a UNIX utility for modifying the permissions of files. Type man chmod in UNIX Systems Services to see more information about this command.
•The value x signifies that execute permissions were added to DFHIsoUtil.
 
 
Running CICS Java Application Isolation Utility program on your development platform: Because the CICS Java Application Isolation Utility is a Java program, you can run it on your development platform (Linux, Windows, and so on):
1. Take a copy of dfhaiu.jar from UNIX Systems Services, and place it on your workstation using ftp binary mode transfer.
2. Making sure that Java is installed on your machine, bring up a command line window, and from the directory where the jar file now resides, type java -classpath dfhjaiu.jar CicsIsoUtil
2.4.2 Generating reports on static updates
With the utility configured and ready to run, you can now use it to generate reports on the updating of statics within Java programs. As we discussed earlier, you can run the program against an individual .class file or a collection of .class files that are inside a .jar file.
 
.jar file: A .jar file is simply a compressed file (.zip file) with a different extension. See this for yourself by changing the extension to .zip and viewing its contents.
Reporting updates to static variables
The easiest mistake to make is to rely on the static initialization of variables. Example 2-7 shows some code where the value of the count variable is set to 0 on static initialization of the class. In a single use JVM, this initialization occurs on every invocation of the program. However, when using a continuous JVM, static initialization happens only when the JVM is created, which means that multiple invocations of the program cause the value to continually increase. Without understanding this behavior, you might experience unexpected behavior during program execution.
Example 2-7 Updating a static variable in a program
public class HelloWorldStaticVariables {
private static int count = 0; // (1)
 
public static void main(String args[]) {
count++;
}
}
Notes on Example 2-7:
•Count gets set to 0 as part of the static initialization of the class, this only happens once, at the point the JVM is created.
Example 2-8 shows that report that running the CICS JVM Application Isolation Utility against this class produces.
Example 2-8 Report generated from the code in Example 2-7 on page 25
./DFHIsoUtil examples/HelloWorld/HelloWorldStaticVariables.class
CicsIsoUtil: CICS JVM Application Isolation Utility
 
Copyright (C) IBM Corp. 2007
 
Reading class file: examples/HelloWorld/HelloWorldStaticVariables.class
 
Method: public static void main(java.lang.String[]) // (1)
Static fields written in this method:
private static int count
 
Method: <clinit> (Class Initialization) // (2)
Static fields written in this method:
private static int count
 
Number of methods inspected : 3
Total static writes for this class: 2
 
Number of jar files inspected : 0
Number of class files inspected : 1
The report in Example 2-8 shows that there are two places where updates are made to static variables. In case (1) the static variable count is updated inside the main() method, in case (2) the static variable is set on class initialization. Having found these instances of static updates, the code must be analyzed to determine if the behavior is problematic in a continuous JVM.
In the case of Example 2-7 on page 25, the static variable count is set to 0 only at the point when the JVM (and class) is created. On each invocation of the program within the same continuous JVM, the value of count is remembered from the last run and is incremented by 1. If this behavior is undesirable, a work around is to set count = 0 at the beginning of the main() method. However, this still causes the same report to be generated, as shown in Example 2-8.
Reporting updates to the contents of static final Objects
A safe way to use static values in a program is to make them final, which means that the static variable instance cannot be changed in the program. Adding the final modifier to static instances of primitive Java types, and immutable objects, such as instances of String, make them safe for use in a continuous JVM and so they are not reported, as shown in Example 2-8. However, this does not apply for all Java objects, for instance, even though the value of a static final object cannot be changed, this does not stop the contents of that object that is modified.
Example 2-9 on page 27 demonstrates this scenario using a Hashtable from the Java collections library. The Hashtable is created on static initialization of the class and is declared as final, which means that for the lifetime of this JVM the myHashtable variable will only ever point to that instance of Hashtable, that is, it is fixed and can never be changed. However, this does not stop the contents of this Hashtable being updated. Therefore this type of behavior is recognized by the CICS JVM Application Isolation Utility and reported accordingly.
Example 2-9 Updating the contents of static final objects in a program
public class HelloWorldStaticObjects {
private static final Hashtable myHashtable = new Hashtable();
 
public static void main(String args[]) {
myHashtable.put("key", "value");
}
}
Example 2-10 shows the report that is produced when you run the CICS JVM Application Isolation Utility against this class.
Example 2-10 Using utility with a class that updates static final Object
./DFHIsoUtil examples/HelloWorld/HelloWorldStaticObjects.class
CicsIsoUtil: CICS JVM Application Isolation Utility
 
Copyright (C) IBM Corp. 2007
 
Reading class file: examples/HelloWorld/HelloWorldStaticObjects.class
 
Method: <clinit> (Class Initialization) // (1)
Static fields written in this method:
private static final java.util.Hashtable myHashtable
 
Number of methods inspected : 3
Total static writes for this class: 1
 
Number of jar files inspected : 0
Number of class files inspected : 1
The report in Example 2-10 shows that a static object is created during class initialization. Even though the object is declared as final, its contents can still be updated and cached between subsequent program invocations. As discussed in 2.3.2, “Continuous JVM” on page 21, if used correctly, this caching of information can be beneficial for retrieving reference information. However if done unintentionally, these updates to static objects can generate unpredictable program behavior.
2.5 The shared class cache
As previously discussed in 2.1, “Overview” on page 18, another potential benefit of having long-lived JVMs, other than removing JVM startup cost, is the possibility to share classes across multiple JVMs, which further cuts down the cost that is associated with loading the class files from the file system and initializing them.
The Java 5 JVM from IBM brings with it a simplified class cache mechanism over that which was supplied with Java 1.4.2, which means that you no longer have the concept of master and worker JVMs; instead, you have a single class cache that all JVMs can share. Because CICS TS 3.2 supports both Java 5 and Java 1.4.2 (though not simultaneously in the same CICS region), we discuss both class cache mechanisms in the next section.
 
Important: There can be, at most, one active shared class cache per CICS region.
2.5.1 Benefits of the shared class cache
The benefits of having a shared class cache are:
•JVMs start up more quickly.
A large proportion of JVM startup time is spent loading classes and JIT-compiling methods. With a shared class cache, classes are loaded only once.
•JVMs that use the shared class cache have lower storage requirements than standard JVMs, which means that you can have more JVMs in a single CICS region.
•The result is improved total system throughput (especially if combined with running in continuous mode).
 
Important: The shared class cache is no more and no less than what the name says — a cache for classes, that is, for bytecode. It is not a cache for data, for example, static member variables reside in one of each JVM’s own heaps, not in the shared class cache.
Do not confuse this with JVMs that run in continuous mode. A continuous JVM allows sharing data across program invocations, and the shared class cache, on the other hand, does not allow, or render possible, sharing data across several JVMs.
2.5.2 Java 5 shared class cache
With Java 5 comes a simplified class cache mechanism. Unlike Java 1.4.2 where CICS solely managed the shared class cache, it now exists as an entity in itself, which means that it persists across CICS restarts. There are also a collection of UNIX System Services utilities for managing the Java 5 shared class cache, which we discussed in 2.5.8, “The -Xshareclasses utilities” on page 33.
 
Attention: Unlike the Java 1.4.2 shared class cache, the Java 5 JIT'd classes are not cached due to the new JIT optimization mechanism that is applied per JVM.
2.5.3 Java 1.4.2 shared class cache
To support the shared class cache, Java 1.4.2 introduced the concept of a JVMSet, which is comprised of one master JVM and a set of multiple (one or more) worker JVMs.
Master JVM
The sole purpose of the master JVM is to initialize and to own the shared class cache. It does not participate in any work after created; in other words, it cannot be used to run Java applications.
The JVM profile for the master JVM defines the trusted middleware classes and the shareable application classes for the shared class cache.
The name of the JVM profile for the master JVM is set up in the JVMCCPROFILE system initialization parameter.
 
Important: There is at most one active shared class cache, and therefore at most one master JVM per CICS region.
Worker JVMs
The worker JVMs perform the actual Java workload (Java and CORBA applications, and EJBs). For classes that are shared across JVMs, a worker JVM uses the classes that are loaded in the shared class cache instead of having to load them from the file system.
A worker JVM owns the working data for the applications that run in it (to maintain isolation between Java applications), and it also owns classes that are defined as non-shareable. These classes are loaded into each individual worker JVM as they are needed.
The JVM profile for a worker JVM specifies the classpath for non-shareable classes. All other classpath settings are ignored for worker JVMs — they are inherited from the master JVM.
Important: The worker JVMs also inherit their JVM mode from the master JVM.
2.5.4 Starting the shared class cache
The JVMCCSTART system initialization parameter configures how the shared class cache is to start. Its behavior depends on the level of Java that is used.
The various settings are:
JVMCCSTART=AUTO The shared class cache is started automatically, as soon as a JVM starts up. Also, if you stop the shared class cache manually, it is restarted as soon as a JVM needs it.
JVMCCSTART=YES On a warm or emergency start, if a Java 1.4.2 shared class cache was active when the system shut down, CICS starts a new one during initialization. For any other scenario, the parameter behaves the same as AUTO.
JVMCCSTART=NO You must start the shared class cache manually, using the CEMT PERFORM CLASSCACHE START command. Also, there are no automatic restarts after stopping it, which means that all attempts to create a new JVM that use the shared class cache fail until you perform the restart.
The final step to configure a JVM to use the shared class cache is to add CLASSCACHE=YES to the JVM profile.
2.5.5 Inquiring the status of the shared class cache
To show the current status of the shared class cache, use the CEMT INQUIRE CLASSCACHE command. Figure 2-2 shows the summary display that is returned from this command. To view detailed information about a class cache, press Tab on the first line of the summary, and then press Enter to go to the view shown in Figure 2-3 on page 30.
I CLASSCACHE
STATUS: RESULTS - OVERTYPE TO MODIFY
Cla Ena Sta Pro(DFHJVMCC) Dat(10/28/08) Tim(11:55:15)
Tot(0001) Old(0000) Pha(0000) Reu Caches(24M )
 
SYSID=MV2C APPLID=IY0398C
RESPONSE: NORMAL TIME: 11.55.39 DATE: 10.28.08
PF 1 HELP 3 END 5 VAR 7 SBH 8 SFH 9 MSG 10 SB 11 SF
Figure 2-2 CEMT INQUIRE CLASSCACHE panel, short form
I CLASSCACHE
RESULT - OVERTYPE TO MODIFY
Classcache
Autostartst( Enabled )
Status(Started)
Profile(DFHJVMCC)
Datestarted(10/28/08)
Timestarted(11:55:15)
Totaljvms(0001)
Oldcaches(0000)
Phasingout(0000)
Reusest(Reuse)
Cachesize(24M )
Cachefree(18389160 )
 
SYSID=MV2C APPLID=IY0398C
TIME: 11.56.16 DATE: 10.28.08
PF 1 HELP 2 HEX 3 END 5 VAR 7 SBH 8 SFH 10 SB 11 SF
Figure 2-3 CEMT INQUIRE CLASSCACHE panel, long form
The following fields are displayed:
Autostartst Displays the status of autostart for the shared class cache (see 2.5.4, “Starting the shared class cache” on page 29).
Status Displays the status of the current shared class cache. The values are:
Started
The shared class cache is ready, and JVMs can use it. This value in the CEMT display includes both the status STARTED and the transient status RELOADING, which occurs when a CEMT PERFORM CLASSCACHE RELOAD command is issued and a new shared class cache is loaded to replace the existing shared class cache. While the shared class cache is reloading, JVMs (both those that were already allocated to tasks and those that were allocated to tasks after the command was issued) continue to use the existing shared class cache until the new shared class cache is ready.
Stopped
The shared class cache is either not yet initialized on this CICS execution or it was stopped manually. If autostart is disabled, requests for JVMs fail. If autostart is enabled, a new shared class cache is initialized when CICS receives a request to run a Java application in a JVM whose profile requires the use of the shared class cache. This value in the CEMT display includes both the status STOPPED and the transient status STARTING, which occurs when the shared class cache is initialized, either through the autostart facility or because an explicit CEMT PERFORM CLASSCACHE START command was issued. While the shared class cache is starting, JVMs that require the use of the shared class cache wait until the startup process is complete and the shared class cache is ready. If initialization of the shared class cache is unsuccessful, any waiting requests for JVMs fail.
Cachefree(value) Displays the amount of free space in the shared class cache, in bytes.
Cachesize(value) Displays the size of the shared class cache, in bytes, kilobytes (K), megabytes (M), or gigabytes (G). If the status of the shared class cache is STOPPED, this is the size that is used by default when the shared class cache is started. If the status of the shared class cache is STARTING or STARTED, this is the size of the current shared class cache. If the status of the shared class cache is RELOADING, this is the size of the new shared class cache that is loaded.
Datestarted Displays the date on which the current shared class cache was started. The format of the date depends on the value that you selected for the DATFORM system initialization parameter for your CICS region.
Oldcaches(value) Displays the number of old shared class caches that are still present in the region because they are waiting for worker JVMs that are dependent on them to be phased out. If the status of the current shared class cache is STOPPED, and worker JVMs are still dependent on it, then that shared class cache is included in the number of old shared class caches.
Phasingout(value) Displays the number of worker JVMs that are dependent on an old shared class cache, and are being phased out. If the status of the current shared class cache is STOPPED, then any worker JVMs that are still dependent on it are included in the number of worker JVMs being phased out.
Profile(value) Java 5 does not use worker JVMs, so this value remains empty in all cases. For Java 1.4.2, if the status of the shared class cache is STOPPED, this displays the eight-character name of the JVM profile that will be used for a master JVM to start the shared class cache. If the status of the shared class cache is STARTED, STARTING, or RELOADING, this displays the eight-character name of the JVM profile that was used for the last valid request to start or reload the shared class cache. This name is displayed even if the shared class cache fails to start or reload. The displayed JVM profile is used the next time that you issue the command to start or reload the shared class cache, unless you specify a different JVM profile using the Profile option.
Reusest Displays the level of reusability for the JVM that initializes the shared class cache. Recall from “Master JVM” on page 28, that all of the worker JVMs in a CICS region inherit their level of JVM mode from the master JVM. The values are:

Reuse
The JVMs are running in continuous mode.

Unknown
The JVM mode is not known because the shared class cache is not started.
Timestarted Displays the time as an absolute value measured from midnight, that the current shared class cache was started. The time is in the format hh:mm:ss.
Totaljvms(value) Displays the number of JVMs in the CICS region that are dependent on a shared class cache, which includes both the JVMs that are dependent on the current shared class cache and any JVMs that are dependent on an old shared class cache and are being phased out.
2.5.6 Changing the size of the shared class cache
When the JVM initializes the shared class cache, its size is set to the value that is specified in the JVMCCSIZE SIT parameter. To inquire the size of a running shared class cache, use the CEMT INQUIRE CLASSCACHE command, as explained in 2.5.5, “Inquiring the status of the shared class cache” on page 29.
When you find the shared class cache is too small, you can change its size by using the following commands. (Use START if the class cache is not currently started, or RELOAD if it is).
CEMT PERFORM CLASSCACHE [ START | RELOAD ] CACHESIZE(number)
The CACHESIZE parameter gives the new size of the class cache in bytes, kilobytes, megabytes, or gigabytes (use a suffix of K, M, or G, respectively).
As usual, subsequent CICS restarts use the new value for the cache size unless you performed a COLD or INITIAL start of the CICS region.
2.5.7 Updating classes in the shared class cache
There will be occasions when you want to install a new version of an application in a running CICS region. The process for performing this update differs depending on which level of Java you are using.
In Java 5, if a class is updated on the file system, the class cache becomes automatically aware of this and loads the new instance. However, a JVM does not pick this up until it is phased out to pick up the new class changes in the cache.
In Java 1.4.2, the shared class cache will not pick up the new copy automatically, so you must tell CICS about it using the CEMT PERFORM CLASSCACHE RELOAD command.
There are three levels of “gentleness” with this command:
•CEMT PERFORM CLASSCACHE RELOAD PHASEOUT
A new shared class cache is created, but until it is ready, both currently running worker JVMs and newly created worker JVMs use the old cache. When the new cache is ready, the currently running worker JVMs are allowed to finish their work, but are then terminated. Newly created worker JVMs then use the new shared class cache.
This is the default option for the RELOAD command.
•CEMT PERFORM CLASSCACHE RELOAD PURGE
All tasks using the shared class cache are terminated using the PURGE mechanism, and then the cache is deleted.
•CEMT PERFORM CLASSCACHE RELOAD FORCEPURGE
All tasks using the shared class cache are terminated using the FORCEPURGE mechanism, and then the cache is deleted.
 
Tip: During development (that is, when your application is updated very frequently), it might be a good idea not to use the shared class cache at all, as suggested in 2.3.1, “Single use JVM” on page 20. Sooner or later, you will forget to reload the shared class cache and will be scratching your head wondering why the bug you spent all day finding still does not seem to be fixed. So, for development or debugging purposes, you must set up a JVM profile for a single use JVM, which does not use the shared class cache at all. Any new bytecode that is deployed to CICS is picked up by a single use JVM when it starts up.
2.5.8 The -Xshareclasses utilities
Supplied with the Java 5 JVM are a collection of utilities for managing the shared class cache. They are available from the java command in the UNIX System Services environment.
To see the status of a shared class cache for a running CICS region, log in to UNIX System Services (through SSH, Telnet, or rlogin) using the same ID that the CICS job is running under. Example 2-11 shows the job information for a running CICS region, which is using a shared class cache. Notice that it is running under the user ID CICSUSER.
Example 2-11 Job information for the CICS region
JOBNAME JobID Owner
IY0398C JOB29376 CICSUSER
After logging into UNIX System Services using the CICSUSER ID, you can then use the -Xshareclasses to view the shared class cache information. Example 2-12 shows how to use the listAllCaches utility to view all of the shared class caches that are running under the CICSUSER ID. Notice that the utility is run using the java command while passing the -Xshareclasses parameter.
Example 2-12 Querying the list of shared caches
java -Xshareclasses:listAllCaches
 
Shared Cache OS shmid in use Last detach time
CICS_sharedcc_IY0016C_0 598031 0 Tue Oct 28 11:38:18 2008
 
CICS_sharedcc_IY0084C_0 139280 0 Tue Oct 28 12:08:19 2008
 
CICS_sharedcc_IY0398C_0 8210 1 Tue Oct 28 15:05:41 2008
Example 2-12 shows that CICSUSER has three shared class caches in existence, though right now only one of them is in use (the others might persist between CICS restarts). CICS automatically generates the name of each shared class cache using the pattern CICS_sharedcc_<applid>_<generation number>. The <generation number> is incremented each time CICS recycles the shared class cache.
After recognizing the shared class cache that is in use by your CICS region you can query it for statistical information using the printStats option shown in Example 2-13.
Example 2-13 Querying a the summary statistics for a shared class cache
java -Xshareclasses:name=CICS_sharedcc_IY0398C_0,printStats
 
Current statistics for cache "CICS_sharedcc_IY0398C_0":
 
base address = 0x22500058
end address = 0x234FFFF8
allocation pointer = 0x226D2198
 
cache size = 16777128
free bytes = 14842164
ROMClass bytes = 1909056
Metadata bytes = 25908
Metadata % used = 1%
 
# ROMClasses = 493
# Classpaths = 5
# URLs = 0
# Tokens = 0
# Stale classes = 0
% Stale classes = 0%
 
Cache is 11% full
 
Could not create the Java virtual machine.
The result from the printStats command in Example 2-13 on page 33 shows the amount of storage in use by the cache and counts on the items that are held in it.
The ‘Could not create the Java virtual machine’ message is an extraneous internal JVM message that you can ignore.
 
Tip: Additional utilities are available for listing the contents of a cache, destroying a cache, and expiring unused caches. They are discussed in the developerWorks® article:
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset