CICS® uses the open transaction environment (OTE) to run JVMs. Each JVM runs on an MVS™ TCB, which is allocated from a pool of J8- and J9-mode open TCBs, managed by CICS in the CICS address space. This pool of open TCBs is called the JVM pool. The priority of the J8- and J9-mode open TCBs in the JVM pool is set lower than that of the main CICS QR TCB, to ensure that J8- and J9-mode activity does not affect the main CICS workload that is being processed on the CICS QR TCB.
When the CICS dispatcher allocates a TCB for a new JVM to run on, it associates the name of the JVM profile with the TCB, so the TCB and the JVM are linked together. However, this linkage only lasts for the lifetime of the JVM. If CICS destroys the JVM (perhaps because an unresettable event has occurred in a resettable JVM, or because CICS needs the space to create a different type of JVM), then the TCB remains in the JVM pool, and it can be reallocated for a different JVM to run on.
CICS creates JVMs and TCBs as they are needed. The CEMT INQUIRE JVMPOOL command (or the equivalent EXEC CICS command) tells you how many JVMs CICS currently has.
The total number of TCBs that CICS can create for JVMs is limited by the MAXJVMTCBS system initialization parameter. This parameter therefore limits the number of JVMs that you can have in the JVM pool in your CICS region. The default value for MAXJVMTCBS is 5. The minimum permitted value is 1, meaning that CICS is always able to create at least 1 TCB in the JVM pool. (JM TCBs, used for the master JVM that initializes the shared class cache, do not count towards the MAXJVMTCBS limit. The shared class cache explains more about JM TCBs.) The CICS System Definition Guide describes MAXJVMTCBS.
The JVMs that CICS creates can be in one of two execution keys: user key or CICS key. You can use the CEMT INQUIRE JVM command (or the equivalent EXEC CICS command) to find out the protection key in which a JVM has been created. JVMs that are in user key—that is, JVMs intended for programs that specify EXECKEY(USER) on their PROGRAM resource definition—need to run on a J9 TCB. JVMs that are in CICS key—that is, JVMs intended for programs that specify EXECKEY(CICS) on their PROGRAM resource definition—need to run on a J8 TCB. You cannot specify the proportions of J8 and J9 TCBs that are in the JVM pool. The MAXJVMTCBS system initialization parameter specifies the maximum total number of J8 and J9-mode TCBs in the JVM pool, and CICS decides how many of them should be J8 TCBs and how many should be J9 TCBs, according to the number of requests that specify each execution key. Statistics are collected separately for each of the modes, so you can see what proportions of each mode are in the JVM pool.
CICS has a storage monitor for MVS storage, which notifies it when MVS storage is constrained or severely constrained, so that it can take short-term action to reduce the number of JVMs in the JVM pool. (The storage monitor uses exits in Language Environment routines; it is not a monitoring transaction.) However, the action that CICS takes when MVS storage is constrained only solves the problem on a temporary basis. When you receive operator messages relating to MVS storage constraints, to provide a long-term solution, you need to work out an appropriate MAXJVMTCBS limit that will prevent the problem from recurring. The CICS Performance Guide explains more about the action CICS takes to deal with MVS storage constraints, and tells you how to work out an appropriate setting for the MAXJVMTCBS system initialization parameter.
In the JVM pool, at any one time, some JVMs and their TCBs might be currently allocated to tasks—that is, transactions are using them to run Java programs. When a JVM has finished running a Java program, CICS does not discard it immediately, unless it is a single-use JVM. Instead, CICS keeps the JVM in the pool in case it can be reused to run another Java program. The JVM is either reset (if it is defined as a resettable JVM), or simply kept in the pool without a reset (if it is defined as a continuous JVM). How JVMs are reused explains the difference between these levels of reusability. So the JVM pool might also contain some JVMs and their TCBs that are not currently allocated to tasks, but are waiting to be reused.
CICS reduces the number of active JVMs automatically if the workload does not require them. If a JVM is inactive for 30 minutes, it is discarded. You can also terminate all the JVMs in the JVM pool (by using the CEMT SET JVMPOOL Phaseout, Purge or Forcepurge command, or the equivalent EXEC CICS command), or disable the JVM pool so that it cannot service new requests (by using the CEMT SET JVMPOOL DISABLED command, or the equivalent EXEC CICS command).
When an application requests execution of a Java™ program, CICS first sees if the Java program can reuse one of the existing JVMs in the JVM pool that is not currently allocated to a task. If the application can reuse an existing JVM, CICS has saved the cost of creating a new JVM. If a suitable JVM is not available, and the limit set by the MAXJVMTCBS system initialization parameter has not yet been reached, CICS allocates a new open TCB in the correct mode (J8 or J9), and creates a new JVM. When the limit set by the MAXJVMTCBS system initialization parameter has been reached, and no more JVMs can be created, CICS decides how best to allocate the JVMs in the pool to the applications that request them. How CICS allocates JVMs to applications explains how CICS decides whether an application can reuse an available JVM, and how it allocates JVMs to applications when it cannot create any more JVMs.