Information
Feedback
Last updated: Wednesday, 27 August 2014The CICS® Transaction Gateway statistics provide information to help you avoid out-of-memory conditions.
You can use the statistics that are generated by CICS Transaction Gateway to establish whether the amount of available virtual storage being used by CICS Transaction Gateway might exceed the amount that is available to the CICS Transaction Gateway address space.
The numbers quoted are based upon observations with 31-bit SDK for z/OS®, Java™ Technology Edition, V7 (SR1), running with the default operating system thread stack size 256K.
If a Gateway daemon attempts to create a new thread and the additional stack storage needed requires more virtual storage than is available to the address space, an out-of-memory condition is produced. This condition is likely to cause the Gateway daemon to shut down. Use the following calculation to avoid these out-of-memory conditions; it estimates the potential maximum virtual storage requirements of the Gateway daemon. The calculation gives a result in kilobytes.
70000 + (SE_SHEAPMAX / 1024) + (128 * CM_SMAX ) + (1200 * WT_SMAX )70000 + (SE_SHEAPMAX / 1024) + (128 * CM_SMAX ) + (650 * WT_SMAX )When an application requires the use of very large numbers of connection manager and worker threads, and demands on memory usage are high, consider splitting the application across a number of LPARs, or across several machines. Servicing very large numbers of Java threads within a single JVM imposes significant performance overheads.
If you increase the JVM maximum heap size, ensure that you also increase the address space limit by the same amount. Increasing the JVM maximum heap size reduces the amount of memory that is available for the creation of worker threads and connection manager threads, and an out-of-memory condition might occur unless you have increased the address space limit by the same amount.
A small saving per thread can be made by using the minimum operating system thread stack size of 128k (-j-Xmso=128K via CTGSTART_OPTS).
The Gateway daemon memory requirements when running under 64-bit SDK for z/OS, Java Technology Edition, V7 are very different from 31-bit. For more information, see Benefits of using a 64-bit Gateway.
In this case, statistic SE_C31MAX provides a dynamic indication of the limit of the available 31-bit storage. Therefore, you can use SE_C31MAX as a guide for increasing REGION size, and it represents the largest size that REGION can achieve. However, SE_C31MAX is a dynamic value, and is at a lowest value during peak workload. You should adopt this lowest value as guidance if your goal is to maximize the 31-bit storage usage in a single Gateway daemon.
SE_CELOAL < SE_SELIM < SE_C31MAXRunning a Gateway daemon with no upper limit on 31-bit storage set, for example; REGION=0M, the amount of 31-bit storage that is currently used by the Gateway daemon, statistic SE_CELOAL, must not approach the limit of 31-bit storage, SE_C31MAX. When these two statistics become too near in value, OutOfMemoryExceptions might occur that cause the Gateway daemon to fail.
In this case, statistic SE_C31MAX provides the only accurate upper limit of the amount of 31-bit storage that is currently used by the Gateway daemon, statistic SE_CELOAL. This is because when REGION=0M is used, the SE_SELIM value does not account for ELSQA storage, which varies dynamically in relation to workload.
SE_CELOAL < SE_C31MAX < SE_SELIM