Provide CICS Stats to show peak Threads used for JVM

Support is provided in CICS TS 6.2 which has been announced and will GA June 14th 2024.
The Liberty active threads value is now reported in the CICS statistics.

See Announcement letter https://www.ibm.com/docs/en/announcements/AD24-0164

It is not possible for us to provide the required tuning information. See earlier comments.

The JVMSERVER already provides a current thread-count and a peak thread-count in statistics.

However, in a CICS Liberty environment this reflects the number of CICS enabled threads (up to a maximum of the RDO 'thread-limit') that Liberty has requested from CICS and pulled into its managed thread-pool. Unlike in an OSGi JVM server, this value does not directly reflect how many application/task threads are running in Liberty, rather how many threads are in the pool for Liberty's use. Liberty will use those threads for both internal processing as well as web-application or Link-to-Liberty requests, and it attaches/detaches CICS tasks as necessary.

Threads in the Liberty thread-pool will appear 'dispatched' to CICS, but they are typically in a wait-state. When needed, Liberty takes them, uses them, and returns them back to its pool to be repurposed. Liberty uses complex algorithms to self-tune the number of threads in the thread-pool and is constantly re-assessing its needs. The thread-pool will therefore grow when higher throughputs are required, and shrink when workload can be more efficiency served by fewer threads running at a higher cadence. Therefore, the current thread-count that CICS sees will also grow and shrink over time too. It is not directly related to application work, rather the entire Liberty server (and JVM) operating dynamically.

If you wish to see how many threads are running CICS applications, then TASK and Java PROGRAM statistics might provide clearer insight. If however, your goal is to understand whether you need to tune the JVMSERVER thread-limit then the 'peak Threads' will not help - that is because any stats related to Liberty's thread-pool will always be within the constraints of the thread-limit that CICS places upon Liberty. Or to put it another way, beacuse Liberty dynamically tunes itself within the constraints you place on it, those stats cannot help you understand the effects of changing the constraints.

The best advice that I can give regarding thread-limit is to consider it more of a throttle on the number of T8 TCBs in a JVMSERVER. If you wish the Liberty server to run unconstrained, then set the limit high (it will only use them if it needs them). If you have multiple JVMSERVERs in a region, or share storage with traditional workloads, then setting a lower thread-limit might be more appropriate. Good capacity planning here is key.

Another consideration is that at higher throughputs and higher thread-limit values, both CPU use and thread-contention come into play. Too many concurrent threads causes additional overheads due to contention, too many concurrent threads might also 'max out' the available CPU in which case setting the thread-limit higher will not achieve anything.

I don't think it is particularly useful to attempt to tune the JVMSERVER thread-limit (compared to reviewing many other JVM/CICS settings).
A simpe heuristic is to set the thread-limit to 100 (The JVMSERVER default of 15 is probably too low for a high volume Liberty server). If you don't get the desired throughput, increase it to 200, beyond that it might be better to scale-out with more JVMSERVERS or more CICS regions. There is no one single value or CICS advice we can give for this capacity planning it is different for every customer, for different machine hardware, for different application patterns, and for different workload patterns.

I'll put this requirement into 'need more information' to allow for further feedback (or maybe the info provided is enough). If you had a specific use-case in mind, giving those details might help us determine if there are actions we can take. Thanks.