CICS task and thread management

CICS® uses the open transaction environment (OTE) to run JVM server work. Each task runs as a thread in the JVM server and is attached by using a T8 TCB. A major benefit of using OSGi is that applications in an OSGi framework can use an ExecutorService to create threads that run extra tasks in CICS asynchronously. CICS takes special measures to deal with runaway tasks.

When CICS enables a JVM server, the JVM server runs on a Language Environment® process thread. This thread is a child of the TP TCB. Every CICS task is attached to a thread in the JVM by using a T8 TCB. You can control how many T8 TCBs are available to the JVM server by setting the THREADLIMIT attribute on the JVMSERVER resource.

The T8 TCBs that are created for the JVM server exist in a virtual pool and cannot be reused by another JVM server that is running in the same CICS region. The maximum number of T8 TCBs that can exist in a CICS region across all JVM servers is 2000 and the maximum for a specific JVM server is 256.

Multithreaded applications

Java™ applications that are running in an OSGi framework can also start CICS tasks asynchronously by using an ExecutorService OSGi service. The JVM server registers the ExecutorService as an OSGi service on startup. The ExecutorService automatically uses an implementation that is supplied by CICS that creates threads that can use the JCICS API to access CICS services. This approach means the application does not have to use specific JCICS API methods to create threads. However, an application can also use the CICSExecutorService to run work on a separate CICS capable thread.

When the JVM server is enabled, it starts the CJSL transaction to create a long-running task that is called the JVM server listener. This listener waits for new thread requests from the application and runs the CJSA transaction to create CICS tasks that are dispatched on a T8 TCB. This process is shown in the following diagram:

Diagram showing an application request that is coming into a CICS region, being received by a Java application that is running in an OSGi framework. The application creates a thread, the thread listener starts a new task on a T8 TCB and runs JCICS to access VSAM.

In advanced scenarios, an application can use the OSGi service to run many threads asynchronously. These threads all have access to CICS services through JCICS and run under T8 TCBs.

Execution keys for JVM servers

A Java program must use a JVM that is running in the correct execution key. JVM servers run in CICS key. To use a JVM server, the PROGRAM resource for the Java program must have the EXECKEY attribute set to CICS. CICS uses a T8 TCB to run the JVM and obtains MVS™ storage in CICS key.

Runaway tasks

The CICS JVM server infrastructure supports use of the task runaway detection mechanism. Unlike traditional CICS tasks, a task running Java on a T8 TCB cannot be terminated without consequences to other workload in the same JVM. Language Environment and the JVM server run in a POSIX-compliant environment, which mandates that if a TCB/Thread is terminated, the parent process is also terminated. In turn, all child processes are terminated abruptly - and cause all tasks in the JVM to fail immediately.

A task running in a JVM server that exceeds the modified RUNAWAY interval experiences a more controlled termination process. This differs from the traditional CICS behavior and you should evaluate whether you want runaway intervals to apply to your Java tasks, or what value to set.

JVMSERVER controlled runaway processing

When a task running Java experiences a runaway interval condition, the JVMSERVER intercepts the condition and triggers a DISABLE PHASEOUT. New work is prevented from entering the JVM and existing work is left to drain. Subsequently, should the task complete its processing, the JVMSERVER re-enables and becomes available for new requests. In many cases if a task running Java exceeds the runaway interval value, it is likely to be a bad application, such as a tightly looping application and prevents successful PHASEOUT/RECYCLE of the JVMSERVER. When an application is detected, the runaway timer triggers again after another interval and the JVMSERVER DISABLE PHASEOUT is escalated to a JVMSERVER DISABLE PURGE. Remaining tasks are subject to PURGE processing and in most cases are terminated. If further runaway intervals are exceeded, the JVMSERVER DISABLE escalates to FORCEPURGE and ultimately KILL - until all running tasks are forcefully terminated. The JVMSERVER recycles back to the ENABLED state ready for new requests. If the JVMSERVER had to escalate as far as a DISABLE KILL request, it is prudent to recycle CICS at the earliest opportunity.

Modified runaway interval value

A runaway condition for a task that is running in a JVM server can cause temporary availability problems for the whole JVM server. For this reason, CICS modifies the runaway interval value that was configured, by multiplying it by a factor of 10 (up to a maximum value of 45 minutes). This new value is the effective runaway interval. This higher runaway interval reduces the possibility of a runaway condition being detected for an inefficient (but otherwise working) application. For example, if the transaction definition specifies RUNAWAY=SYSTEM, and the ICVR system initialization parameter indicates a default limit of 5000 milliseconds, then the effective runaway interval for that task when it runs in a JVM server is 50000 milliseconds.

Setting the runaway interval value

By default the CJSA transaction definition that is used for Liberty JVM servers and for work in an OSGi JVM server started from the CICSExecutorService has runaway detection active and set to the system interval. If you do not want runaway intervals to apply to these tasks, you can run work under your own transaction definitions with the runaway interval set to 0, or another value of your choice. Liberty workload is typically controlled by URIMAPs, while the CICSExecutorService provides the CICSTransactionRunnable and CICSTransactionCallable interfaces to allow customized transaction definitions to be used.