If you are using enterprise beans in your CICS® system, this tuning information might help:
The EJB Object Store, DFHEJOS, is a file used to store stateful session beans that have been passivated. It can be a VSAM file or a coupling facility data table. CICS supplies sample JCL to help you create this file, in the DFHDEFDS member of the SDFHINST library.
The CICS-supplied settings for DFHEJOS are designed for storage of a low number of objects (passivated beans), with a maximum size of 8K, to minimize storage wastage. If you anticipate heavy usage of stateful enterprise beans, increase the space allocations and record sizes for this data set.
The CICS System Definition Guide describes how to create DFHEJOS. To work out appropriate settings for the record sizes, follow the procedure described in "Determining the object store space requirements".
The use of client-controlled OTS (object transaction service) transactions can affect your JVM requirements.
The typical enterprise bean workload in CICS begins with an incoming IIOP message, containing a GIOP request that is received by an IIOP listener task in CICS. The request is passed to a request receiver task, that examines the GIOP message and passes processing of the message to a request processor task. Finally, on completion of the request processor task, a response is sent back to the requesting client by the request receiver task.
If the GIOP request forms part of a client-controlled OTS transaction, then the request processor and request receiver tasks are not ended until the OTS transaction is committed or rolled back. Because the request processor task is executing in a JVM, that JVM is not available for any other task to use until the OTS transaction has ended. If this happens frequently, you might need to increase the number of JVMs in your JVM pool to avoid excessive waiting times for incoming requests.
If a single execution of an enterprise bean method requires more than one request processor, your application could experience deadlock problems. (A method can be said to "require more than one request processor" if it calls one or more other, typically remote, methods, each of which must execute in a different request processor.) Deadlocks can be caused by all the request processors required to satisfy the method being forced to wait for a JVM when no more JVMs are permitted. This can occur for two reasons:
Avoiding the simple case is easy; avoiding the complex case is more difficult. It is necessary to ensure there are always enough free JVMs to allow at least one method’s requirement of request processor instances to be satisfied.
The maximum number of concurrent JVMs available to a bean method is set by the MAXACTIVE attribute of the TRANCLASS definition that applies to the request processor transaction. The maximum number of concurrent JVMs available to CICS is set by the MAXJVMTCBS system initialization parameter.
To remove the possibility of deadlocks caused by bean methods that use multiple request processors:
MAXACTIVE <= ((MAXJVMTCBS - n) / (n - 1)) + 1
where n is the maximum number of request processors required
by your "worst case" method.
If the result of this calculation is a decimal value, round it down to the nearest (lower) whole number.