Classes and class paths in JVMs
A JVM running under CICS can use different types of class or library files: primordial classes (system and standard extension classes), native C® DLL library files, and application classes.
The JVM recognizes the purpose of each of these components, determines how to load them, and determines where to store them. The class paths for a JVM are defined by options in the JVM profile, and (optionally) are referenced in JVM properties files.
- Primordial classes are the z/OS JVM code that provide the base services in the JVM. Primordial classes can be categorized as system classes and standard extension classes.
- Native C dynamic link library (DLL) files have the extension .so in z/OS UNIX. Some libraries are required for the JVM to run, and additional native libraries can be loaded by application code or services. For example, the additional native libraries might include the DLL files to use the Db2® JDBC drivers.
- Application classes are the classes for applications that run in the JVM, and include classes that belong to user-written applications. Java™ application classes also include those supplied by IBM or by other vendors, to provide services that access resources, such as the JCICS interfaces classes, JDBC and JNDI, which are not included in the standard JVM setup for CICS. When Java application classes are loaded into the class cache the are kept and can be reused by other applications running in the same JVM.
- The Library path specifies the native C dynamic link library (DLL) files that are used by the JVM, including the files required to run the JVM and additional native libraries loaded by application code or services. Only one copy of each DLL file is loaded, and all the JVMs share it, but each JVM has its own copy of the static data area for the DLL.
The base library path for the JVM is built automatically using the directories specified by the USSHOME system initialization parameter and the JAVA_HOME option in the JVM profile. The base library path is not visible in the JVM profile. It includes all the DLL files required to run the JVM and the native libraries used by CICS. You can extend the library path using the LIBPATH_SUFFIX option or the LIBPATH_PREFIX option. LIBPATH_SUFFIX adds items to the end of the library path, after the IBM-supplied libraries. LIBPATH_PREFIX adds items to the beginning, which are loaded in place of the IBM-supplied libraries if they have the same name. You might have to do this for problem determination purposes.
Compile and link with the LP64 option any DLL files that you include on the library path . The DLL files supplied on the base library path and the DLL files used by services such as the Db2 JDBC drivers are built with the LP64 option.
- The Standard class path must not be used for OSGi enabled
JVM servers because the OSGi framework automatically determines the
class path for an application from information in the OSGi bundle
that contains the application. The standard class path is retained
for use by JVM servers that are not configured for OSGi (for example
the Axis2 environment in CICS).
For exceptional scenarios, such as Axis2, in which the standard class
path is used, you can use a wildcard suffix on the class path entries
to specify all JAR files in a particular directory.
CICS also builds a base class path automatically for the JVM using the /lib subdirectories of the directories specified by the USSHOME system initialization parameter. This class path contains the JAR files supplied by CICS and by the JVM. It is not visible in the JVM profile.
You do not have to include the system classes and standard extension classes (the primordial classes) on a class path, because they are already included on the boot class path in the JVM.