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:
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.