System properties for JVMs

"Setting up JVM profiles and JVM properties files" in Java™ Applications in CICS® tells you how to set up suitable JVM profiles and JVM properties files to meet the needs of your applications.

System properties are key name and value pairs that contain basic information about the JVM and its environment, such as the operating system in which the application is running. The system properties are initialized when the JVM is first created. Some are set by the JVM automatically when it is initialized, and others you can specify in a JVM properties file, which is referenced by the JVMPROPS option in the JVM profile (see Options in JVM profiles).

CICS passes all the system properties in a JVM properties file to the JVM unchanged. However, you should bear in mind that only the system properties described in the CICS documentation are supported by CICS, although the JVM can support a much wider range of system properties. This topic documents the system properties that are particularly relevant for JVMs in a CICS environment, including some which are defined by CICS. Persistent Reusable Java Virtual Machine User's Guide, SC34-6201, lists command-line options, JVM options and system properties that are used in a persistent reusable JVM in a z/OS® environment, some of which are provided in a different format by options in the JVM profile in CICS. The IBM® Developer Kit and Runtime Environment, Java 2 Technology Edition, Version 1.4.2 Diagnostics Guide, SC34-6358, which is available to download from www.ibm.com/developerworks/java/jdk/diagnosis/, documents further system properties that are used for JVM trace and problem determination. The Java class libraries include other system properties, and applications might have their own system properties. There is no central repository of all system properties for the JVM.

Specify each system property according to the coding rules described in Rules for coding JVM profiles and JVM properties files. Remember that all parameter keywords and operands specified in a JVM profile or JVM properties file are case-sensitive, and must be specified exactly as shown in the following sections.

Property values are passed to the JVM for the construction of system properties as if specified by a -D option in a java command. For example, the JVM properties file could set the java.security.policy property by specifying:

java.security.policy=
file:/usr/lpp/cicsts/cicsts31/lib/security/dfjejbpl.policy

(where cicsts31 is a user-defined value that you specify during the installation of CICS TS). CICS uses this information to create a Java launcher option as follows:

-Djava.security.policy=
file:/usr/lpp/cicsts/cicsts31/lib/security/dfjejbpl.policy
JVM properties files for worker JVMs (referenced by JVM profiles that specify CLASSCACHE=YES)

As described in Options in JVM profiles, if you specify CLASSCACHE=YES in a JVM profile, making the JVM a worker JVM that uses the shared class cache, certain system properties in the JVM properties file referenced by the JVMPROPS option on the JVM profile are treated differently. The affected system properties are ibm.jvm.shareable.application.class.path and java.compiler. The descriptions for these system properties tell you how to handle them for worker JVMs.

JVM properties file for the master JVM that initializes the shared class cache

As described in Options in JVM profiles, the master JVM that initializes the shared class cache is not used to run Java applications. Because of this, most of the system properties that would normally be specified for a JVM are not needed for the master JVM. The CICS-supplied sample JVM profile for the master JVM is DFHJVMCC, and the JVM properties file that it references is dfjjvmcc.props.

In the JVM properties file for the master JVM, the only system property that needs to be specified is ibm.jvm.shareable.application.class.path, which should specify the paths to the shareable application classes for all the applications that will run in worker JVMs that use the shared class cache.

The java.compiler system property can be included in the JVM properties file for the master JVM, or allowed to default to jitc. Also, if you want to activate tracing for the master JVM, you can specify the ibm.dg.trc.external system property, which should only be used with care. These system properties are not specified in the CICS-supplied sample JVM properties file dfjjvmcc.props.

The remaining system properties, other than those that are set automatically by the IBM JVM, are irrelevant for a master JVM. They do not cause an error if they are specified in the JVM properties file for the master JVM, but you should not include any of them unless you do so under the direction of Level 2 support.

Customizing dfjjvmcd.props

As described in Options in JVM profiles, the JVM profile DFHJVMCD, and its associated JVM properties file, dfjjvmcd.props, are reserved for use by CICS-supplied system programs, in particular the default request processor program DFJIIRP (used by the CICS-supplied CIRP request processor transaction).

Only make the changes to dfjjvmcd.props that are necessary to run applications, as follows:

Do not make any other changes to dfjjvmcd.props.

Security caution

You should ensure that the JVM properties files are secure, with update authority restricted to system administrators. This is because the JVM properties files are typically used to define sensitive JVM configuration options, such as the security policy file and the trusted middleware class path.

In particular, if you specify that a secure LDAP server is to be used, by coding java.naming.security.authentication in the JVM properties files, you also need to specify java.naming.security.principal and java.naming.security.credentials. These properties hold the UserID and password that CICS requires to access the secure LDAP service, so you need to give particular attention to the access controls in force at your installation for the JVM properties files, and any other copies of this information that you have.

Standard system properties

The standard Java system properties, common to all JVMs, are as follows:

file.separator=
The file separator character. By default, this is set by the JVM as the / symbol. Do not change this value.
java.class.path=
The standard class path, for nonshareable application classes. Do not use this system property in a JVM properties file for CICS. In CICS, the standard class path is specified instead by the CLASSPATH option in the JVM profile.
java.class.version=
The Java class version number. This is set by the IBM JVM as 048. Do not change this value.
java.compiler={jitc | NONE }
The Java just-in-time (JIT) compiler. This is set by default as java.compiler=jitc, which means that after a pre-determined number of invocations of a Java method, the JIT compiler is invoked to compile the bytecode into z/OS machine code.

This system property can be specified in the JVM properties file for a master JVM.

In JVM properties files referenced by JVM profiles where you have specified CLASSCACHE=YES (that is, the JVM properties files for worker JVMs), this system property must either:

The activities of the Java just-in-time (JIT) compiler can interfere with the logging of unresettable events, reset trace events and cross-heap events. During the development process, specify java.compiler=NONE to turn off the JIT compiler for the JVM. Remember to turn the JIT compiler back on when you have finished investigating unresettable events, reset trace events and cross-heap events in your application.

java.home=
The Java installation directory. Do not change this value.
java.naming.provider.url=
Identifies a COS Naming Service. This property continues to be supported only for compatibility with CICS TS 2.1. You are recommended to use the com.ibm.cics.ejs.nameserver property (see com.ibm.cics.ejs.nameserver) instead.

If you do use the java.naming.provider.url property, this sets the protocol, host name, and port number of the COS Naming Service that CICS is to use. For example,

java.naming.provider.url=IIOP://servername.hursley.ibm.com:900

For special considerations that apply if you are using the COS Naming Directory Server supplied with WebSphere Application Server Version 5 or later, see com.ibm.cics.ejs.nameserver.

You are strongly recommended to avoid using both the java.naming.provider.url and the com.ibm.cics.ejs.nameserver property in the same JVM properties file, because:

java.naming.security.authentication=
specifies the type of security authentication in use for naming operations. This property may be required if you are using an LDAP name server.

CICS needs to have write access into the LDAP namespace. If the LDAP service is set up securely, these three properties--authentication, credentials and principal--are required. If the LDAP service is set up so that any user can write to it, these three are not needed. Your LDAP administrator can tell you whether or not you need to include these properties in your JVM properties file.

Simple is the only value for this property that is supported by CICS. Specifying java.naming.security.authentication=simple indicates that the LDAP name server is running in secure mode.

Important

If you do specify this property, you have also to specify java.naming.security.principal and java.naming.security.credentials.

Because these properties specify the user ID and password that CICS requires to access the secure LDAP service, you need to give particular attention to the file permissions controlling access to the JVM properties file and any other copies of this information that you have.

java.naming.security.credentials=
specifies the password required for the principal (see java.naming.security.principal) to access to the LDAP name server.

This property is required if you specified java.naming.security.authentication=simple. Your LDAP administrator provides the value that you should specify, for example, java.naming.security.credentials=secret.

java.naming.security.principal=
specifies the principal required for access to the LDAP name server.

This property is required if you specified java.naming.security.authentication=simple. Your LDAP administrator provides the value that you should specify, for example, java.naming.security.principal=cn=CICSUser,c=uk .

Notes:
  1. The principal/credentials of cn=CICSAdmin,c=uk/secret is the default which applies if the administrator makes no changes to the CICS scripts used when building the system namespace.
  2. For more information about principals, see Java Applications in CICS. You may find it helpful to think of credentials as ‘passwords’ , and principals as ‘userIDs’.
java.security.manager={default | "" |  |other_security_manager}
This system property indicates the Java security manager to be enabled for the JVM. To enable the default Java 2 security manager, include this system property in one of the following formats:

    java.security.manager=default
or
    java.security.manager=""
or
    java.security.manager= 
All these statements have the effect of enabling the default security manager. If you do not include the java.security.manager system property in your JVM properties file, then the JVM runs without Java 2 security enabled. If you need to disable Java 2 security for a JVM, comment out this system property.
java.security.policy=
This system property describes the location of additional policy files that you want the security manager to use to determine the security policy for the JVM. A default policy file is provided with the JVM in /usr/lpp/java142/J1.4/lib/security/java.policy, where the java142/J1.4 subdirectory names are the default values when you install the IBM Developer Kit for OS/390®, Java 2 Technology Edition. The default security manager always uses this default policy file to determine the security policy for the JVM, and you can use the java.security.policy system property to specify any additional policy files that you want the security manager to take into account as well as the default policy file.

To enable CICS Java applications and enterprise beans to run successfully when Java 2 security is active, you need to specify, as a minimum, an additional policy file that gives CICS the permissions it needs to run the enterprise beans container, and gives applications the permissions outlined in the Enterprise JavaBeans specification, Version 1. The CICS-supplied enterprise beans policy file, dfjejbpl.policy, contains the permissions that you need for this purpose. To specify this policy file, include the system property:

java.security.policy=/usr/lpp/cicsts/cicsts31/lib/security/dfjejbpl.policy

where cicsts31 is your chosen value for the USSDIR installation parameter that you defined when you installed CICS TS.

"Managing security for enterprise beans" in Java Applications in CICS has more information about specifying security policy files, and about dfjejbpl.policy.

java.vendor=
Java vendor-specific string. The is set by the IBM JVM as "IBM Corporation".
java.vendor.url=
The Web address of the vendor's home page. Set by the IBM JVM as "http://www.ibm.com/"
java.version=
The Java version number of the Java run-time environment. This is set by the IBM JVM as "1.4.2".
jdbc.drivers=
Specifies one or more JDBC drivers. Setting the driver names as a system property is an alternative to the Java application itself loading the drivers using the Class.forName("driver_name"); command. Separate each driver name in a list by a : (colon). An example of this system property is included within comments in the CICS-supplied system property file dfjjvmpr.props.

To specify the DB2-supplied JDBC drivers, set the system property as:

jdbc.drivers=COM.ibm.db2os390.sqlj.jdbc.DB2SQLJDriver

This is a common name that works for all levels of JDBC driver supplied by DB2®, including the DB2 Universal JDBC Driver.

"Using JDBC and SQLJ to access DB2 data from Java programs and enterprise beans written for CICS" in the CICS DB2 Guide has more information about using JDBC.

line.separator=
The line separator character. This is set by default as \n .
os.arch=
The operating system architecture. This is set by the IBM JVM as "390"
os.name=
The operating system name. This is set by the IBM JVM as "z/OS".Do not change this value.
path.separator=
The character used to separate paths in a multipart class path. By default, this is set as a : (colon). Do not change this value.
user.dir=
The user’s current working directory. In this case, the user is identified by the CICS region’s userid. Do not change this value.
user.home=
The user’s home directory. In this case, the user is identified by the CICS region’s userid. Do not change this value.
user.name=
The user’s account name. In this case, this is set by the JVM to the account name under which the CICS job is running. Do not change this value.

System properties specific to the IBM persistent reusable JVM

In addition to the basic system properties, shown in Standard system properties, which are common to all JVMs, there are some that are unique to the IBM persistent reusable JVM. These are listed below.

com.ibm.cics.datasource.path=
specifies the name and subContext of a CICS-compatible DataSource that you have deployed to generate JDBC connections for Java applications in CICS that access DB2. The CICS DB2 Guide has more information about this.
com.ibm.cics.ejs.nameserver=
specifies the URL and TCP/IP port number of the name server that you use for JNDI references. For example: An example of this statement is included in the CICS-supplied sample JVM properties file, dfjjvmpr.props.
Note:
If you are using a COS naming service, and you have chosen to specify it in java.naming.provider.url, do not specify it again here.
com.ibm.cics.ejs.loadjndiproperties=
You can set up a file called jndi.properties to contain JNDI nameserver configuration properties that are common across a set of CICS regions.By default, CICS does not attempt to locate a jndi.properties file. Include the following system property to cause CICS to load jndi.properties for this JVM:
com.ibm.cics.ejs.loadjndiproperties=true
Place the directory containing the jndi.properties file on either the shareable application class path (in the JVM properties file) or the trusted middleware class path (in the JVM profile), in all the relevant JVM profiles or JVM properties files, for all the regions that you want to share the same nameserver settings.
Start of changecom.ibm.cics.soap.validation.local.CCSID=End of change
Start of changespecifies the local code page to use when validating SOAP messages if validation is enabled for a CICS WEBSERVICE resource. If a local CCSID is not specified then the default USS code page for your installation is assumed when validating the SOAP message.End of change
com.ibm.websphere.naming.jndicache.cacheobject={populated |none}
Turns the JNDI cache on or off. The JNDI cache stores the results of JNDI lookups in local storage, so that, if an application does the same lookup twice (perhaps in different tasks), the results are already available. Note that the cache:
populated
The JNDI cache is active.
none
The JNDI cache is not used.
com.ibm.websphere.naming.jndicache.maxcachelife={20 |mins}
Specifies, in minutes, the "time to live" of the JNDI cache. If the cache is accessed after this time is exceeded the entire cache is flushed of its contents.

See also the com.ibm.websphere.naming.jndicache.cacheobject property.

com.ibm.ws.naming.ldap.containerdn=
specifies the Container Distinguished Name for the LDAP name server. For example:
com.ibm.ws.naming.ldap.containerdn=ibm-wsnTree=t1,o=WASNaming,c=us
An example of this statement is included in the CICS-supplied sample JVM properties file, dfjjvmpr.props. Your LDAP administrator can supply the correct value for your installation.

The Container Distinguished Name is the root of the system name space.

This property is not required if you specify a COS naming service.

com.ibm.ws.naming.ldap.noderootrdn=
specifies the Noderoot Relative Distinguished Name for the LDAP name server. For example:
com.ibm.ws.naming.ldap.noderootrdn=ibm-wsnName=legacyroot,
ibm-wsnName=PLEX2,ibm-wsnName=domainRoots
Your LDAP administrator can supply the correct value.

An example of this statement is included in the CICS-supplied sample JVM properties file, dfjjvmpr.props.

This property is not required if you specify a COS naming service.

ibm.dg.trc.external=
Setting this system property sets trace options and enables tracing for the JVM. This enables you to trace a JVM during its whole lifetime, including start-up and reset as well as the periods when it is being used by a transaction. This system property has to be used with care, as JVM tracing can produce large amounts of output in a very short time. If you only want to activate JVM trace for particular transactions that use the JVM, use the CICS-supplied transaction CETR, rather than this system property. "Controlling tracing for JVMs" in Java Applications in CICS has more information about this. "Defining tracing for JVMs" in the CICS Problem Determination Guide has information about the JVM trace options that you can set using this system property. There is further information about JVM trace and about problem determination for JVMs in the IBM Developer Kit and Runtime Environment, Java 2 Technology Edition, Version 1.4.2 Diagnostics Guide, SC34-6358, which is available to download from www.ibm.com/developerworks/java/jdk/diagnosis/.

This system property can be specified in the JVM properties file for a master JVM.

When CICS starts to use or re-use a JVM, it ensures that any trace options that you have set and activated using CETR are applied. Activating or deactivating a trace option using CETR overrides any setting for that trace option in the ibm.dg.trc.external system property. For example, a trace option that is activated in the system property, but deactivated using CETR, will be deactivated when CICS starts to use or re-use the JVM. If you use CETR to activate any trace options that are not referred to in the ibm.dg.trc.external system property, the trace options that you have specified in CETR are added to any trace options that you have set using the ibm.dg.trc.external system property. The trace output will then reflect all the trace options that you requested in both CETR and the system property.

When you activate JVM trace, the JVM trace appears as CICS trace point SJ 4D01. If the JVM trace facility fails, CICS issues the trace point SJ 4D00.

ibm.jvm.crossheap.events={on}
Setting this system property enables the logging of cross-heap references in a resettable JVM (that is, a JVM with the option REUSE=RESET specified in its JVM profile). To see this information, you also need to set the ibm.jvm.events.output system property to enable event logging.

This system property is not set in the CICS-supplied JVM properties files, so by default the function is not enabled. Note that when you include this system property in the JVM properties file with any value ("on" is one possibility), the function is enabled. To disable the function, you need to comment out or remove the system property; there is no value you can specify for the system property that disables the function.

Cross-heap references are references between the middleware heap and the transient heap in the JVM. When you set up the JVM as described here, cross-heap references are logged to the event output destination at the time that each reference is created. The log entry includes a full stack trace to identify the line of code that created the cross-heap reference.

Most of the cross-heap references that are logged will be removed before the JVM is reset, through the normal actions of the CICS and JVM code, and through any actions that your application takes for this purpose. However, if any cross-heap references are not removed before the JVM is reset, they cause the JVM to perform a trace-for-unresettability check. Any references that are found to be in live objects trigger unresettable events, which cause the JVM to be marked as unresettable and destroyed. Any references that are found to be in unreferenced middleware heap objects (garbage) are reported as reset trace events, which do not cause the JVM to be destroyed, but have still wasted processor time by causing the trace-for-unresettability check. You should therefore ensure that all cross-heap references created by your applications are removed from the JVM before it is reset.

You can use the memory location listed for an unresettable event or a reset trace event to identify the cross-heap reference recorded in the event log which is responsible for triggering the event. You can then use the stack trace associated with the cross-heap reference to help you to fix the problem. You might have to perform compensatory actions in application code to cause a cross-heap reference to be removed, which could include closing files or streams, emptying collections, or other kinds of clean-up activity. If you cannot remove the cross-heap reference in application code, consider contacting your IBM support representative for further advice.

The activities of the Java just-in-time (JIT) compiler can interfere with the logging of cross-heap references. During the development process, specify the system property java.compiler=NONE in the JVM properties file to turn off the JIT compiler for the JVM. (The word NONE must be in upper case.) When you have finished investigating cross-heap references in your application, remember to turn the JIT compiler back on.

ibm.jvm.events.output={event.log | path/file_name | stderr | stdout}
Setting this system property enables event logging in a resettable JVM (that is, a JVM with the option REUSE=RESET specified in its JVM profile). You can store the text records describing the events in a HFS file, or in the stderr or stdout files for the JVM. You can specify only the name for the HFS file, in which case the file is created in the directory specified by the WORK_DIR option in the JVM profile. Alternatively, you can specify a full HFS path and file name to place the file in a HFS directory of your choice. (Make sure the CICS region has write permission for the directory.) The CICS-supplied sample JVM properties file, dfjjvmpr.props, specifies this system property as:
ibm.jvm.events.output=event.log
which creates a file called event.log in the directory specified by the WORK_DIR option.

If you use this system property to name a specific HFS file as the destination for the unresettable events information, then the information goes to that file, and is not intercepted by any class named on the USEROUTPUTCLASS option in the JVM profile. If the system property names the destination as stdout or stderr, then the information is intercepted by any class named on the USEROUTPUTCLASS option. If the system property is null, then this output is not produced at all.

ibm.jvm.reset.events={on}
Setting this system property to "on" suppresses JVM reset messages in a resettable JVM (that is, a JVM with the option REUSE=RESET specified in its JVM profile). These messages are normally written to the event log whenever a JVM is successfully reset.

This system property is not set in the CICS-supplied JVM properties files, so by default the function is not enabled. Note that when you include this system property in the JVM properties file with any value ("on" is one possibility), the function is enabled. To disable the function, you need to comment out or remove the system property; there is no value you can specify for the system property that disables the function.

ibm.jvm.resettrace.events={on}
Setting this system property enables the logging of reset trace events in a resettable JVM (that is, a JVM with the option REUSE=RESET specified in its JVM profile). To see these events, you also need to set the ibm.jvm.events.output system property to enable event logging.

This system property is not set in the CICS-supplied JVM properties files, so by default the function is not enabled. Note that when you include this system property in the JVM properties file with any value ("on" is one possibility), the function is enabled. To disable the function, you need to comment out or remove the system property; there is no value you can specify for the system property that disables the function.

Reset trace events are caused by cross-heap references that are still present in out-of-scope JVM objects (garbage) in the JVM at reset time. (If the cross-heap reference is still in scope, it causes an unresettable event.) Reset trace events do not cause the JVM to be marked as unresettable and destroyed, but you should still eliminate the cross-heap references that caused them, because the trace-for-unresettability check that is required for these cross-heap references reduces the performance of the JVM. Specify the ibm.jvm.crossheap.events system property to log the lines of code in an application that are responsible for cross-heap references.

The activities of the Java just-in-time (JIT) compiler can interfere with the logging of reset trace events. During the development process, specify the system property java.compiler=NONE in the JVM properties file to turn off the JIT compiler for the JVM. (The word NONE must be in upper case.) Remember to turn the JIT compiler back on when you have finished investigating reset trace events in your application.

ibm.jvm.shareable.application.class.path=
Specifies the directory paths to be searched by the JVM for shared application classes and JAR files that are to be loaded by the shareable application class loader (SAC). When you add an application class to this class path, it is cached, and is reinitialized, rather than reloaded, if the JVM is reset. Adding application classes to this class path, rather than to the standard class path specified by the CLASSPATH option in a JVM profile, produces the best performance. The shareable application class path should be your normal choice for loading application classes in a production environment.

For worker JVMs (those with CLASSCACHE=YES in their JVM profile), the shareable application class path is taken from the JVM properties file for the master JVM that initializes the shared class cache. If it is specified in the JVM properties file for a worker JVM, it is ignored. To specify the directory paths for application classes that run in a worker JVM, use the ibm.jvm.shareable.application.class.path system property in the JVM properties file for the master JVM. The CICS-supplied sample JVM profile for the master JVM is DFHJVMCC, and the JVM properties file that it references is dfjjvmcc.props.

ibm.jvm.trusted.middleware.class.path=
Specifies where the trusted middleware class loader (TMC) is to look for classes and JAR files. Do not use this system property in a JVM properties file for CICS. In CICS, the trusted middleware class path is built for you automatically, using the information you specify on the CICS_DIRECTORY option in the JVM profile. Any paths you specify on the optional parameters TMPREFIX and TMSUFFIX in the JVM profile are added either at the beginning or the end of the paths constructed by CICS. If you need information about the ibm.jvm.trusted.middleware.class.path system property, see Persistent Reusable Java Virtual Machine User's Guide, SC34-6201.
ibm.jvm.unresettable.events.level={min | max}
Setting this system property enables the logging of unresettable events in a resettable JVM (that is, a JVM with the option REUSE=RESET specified in its JVM profile), and sets the level of logging required. Specifying min produces a list of reason codes that define the unresettable events found, and specifying max produces the reason codes and also a stack trace where appropriate. To see these events, you also need to set the ibm.jvm.events.output system property to enable event logging. The CICS-supplied JVM properties file, dfjjvmpr.props specifies this system property as:
ibm.jvm.unresettable.events.level=max

A frequent cause of an unresettable event is that the Java program that just ran in the JVM has performed an unresettable action. An unresettable action is when a program uses Java interfaces that modify the state of a JVM in a way that cannot be properly reset, such as changing system properties or loading a native library. The document Persistent Reusable Java Virtual Machine User's Guide, SC34-6201, has more information about these unresettable actions. If one or more such actions are detected during the execution of a user's Java program, the JVM is marked unresettable, and CICS destroys the JVM when the Java program has finished using it. Another possible cause of an unresettable event is if a cross-heap reference in the JVM has been found, in the course of a trace-for-unresettability check, to be still in scope (rather than in garbage). Unresettable events can also occur if there is an error in the JVM code.

The activities of the Java just-in-time (JIT) compiler can interfere with the logging of unresettable events. During the development process, specify the system property java.compiler=NONE in the JVM properties file to turn off the JIT compiler for the JVM. (The word NONE must be in upper case.) Remember to turn the JIT compiler back on when you have finished investigating unresettable events in your application.

The CICS-supplied JVM properties files also specify some special system properties that are required only for tracing in the CICS Connector for CICS TS. The CICS Connector for CICS TS allows a Java program or enterprise bean running on CICS TS to link to a CICS server program, and uses the CICS Transaction Gateway (CTG) code. These CTG trace system properties are:

gateway.T=off       
gateway.T.entry=off 
gateway.T.lines=off 
gateway.T.exit=off  
gateway.T.stack=off 
gateway.T.trace=off 
gateway.T.timing=off

For more information about these CTG system properties, see Java Applications in CICS.

Related tasks

Setting up JVM profiles and JVM properties files
Setting up the shared class cache
Protecting Java applications in CICS by using the Java 2 security policy mechanism
Using JDBC and SQLJ to access DB2 data from Java programs and enterprise beans written for CICS
Related concepts

The structure of a JVM
How CICS creates JVMs
Related reference
Rules for coding JVM profiles and JVM properties files
Options in JVM profiles
The sample JVM profiles and JVM properties files
[[ Contents Previous Page | Next Page Index ]]