How CICS allocates JVMs to applications

When an application requests execution of a Java™ program, CICS® first tries to find a suitable JVM that is available for reuse in the JVM pool. An application can reuse an available JVM if the JVM was created using the JVM profile and the execution key (USER or CICS) that are specified in the Java program's PROGRAM resource definition. If a suitable JVM is available, CICS assigns the JVM to the request.

If a suitable JVM, with the correct JVM profile and execution key, is not available, and the limit set by the MAXJVMTCBS system initialization parameter has not yet been reached, and MVS storage is not severely constrained, CICS creates a new JVM for the Java program. The new JVM has the correct profile and execution key for the program.

If CICS cannot find a suitable JVM, and a new JVM cannot be created because the MAXJVMTCBS limit has been reached, or because MVS storage is severely constrained and CICS is acting as though the MAXJVMTCBS limit had been reached, then CICS must decide on the best way to provide the application with a JVM. This involves assessing the need of the application for a JVM, against the need for different types of JVM in the CICS region. CICS can fulfil an application's request for a JVM by: Both a mismatch and a steal are expensive, so before taking one of these courses of action, CICS tries to decide if it is worthwhile. In terms of the need for different types of JVM in the CICS region, it might be more economical for overall system performance for CICS to make the application wait until a suitable JVM is available, and to keep the free JVMs for requests that can benefit more from them. CICS has a selection mechanism to make this decision.

Figure 1 shows this process happening. Our example JVM pool is in the state shown above in Figure 1, with a MAXJVMTCBS limit of 5, and 5 JVMs in the pool. CICS receives two of the requests described above in Figure 1.

Request B specifies the PROGRAM resource definition for the default request processor program DFJIIRP, which names the JVM profile DFHJVMCD, and the execution key USER. CICS checks the JVM pool, and finds that JVM 3 has the correct JVM profile and execution key to match the request, and it is available for reuse. CICS assigns JVM 3 to Request B.

Request D specifies the PROGRAM resource definition for PROG1, which names the JVM profile USERJVM2, and the execution key CICS. CICS checks the JVM pool. There is a free JVM, JVM 2, but it has the wrong profile and execution key for Request D. As the MAXJVMTCBS limit has been reached, CICS cannot create a new JVM for Request D. So CICS must use the selection mechanism to decide if it should destroy JVM 2 and its TCB, and replace it with a JVM and TCB that matches Request D; or if it should make Request D wait, and keep JVM 2 for a request that can benefit more from it. If Request D is made to wait, it is queued along with any other requests that are waiting for a JVM.

Figure 1. Dealing with requests for JVMs: example
The text in the previous three paragraphs explains this figure.
Now let's look in more detail at the whole process. CICS makes its decision to assign a JVM to an application in two stages: