Threading model

A multithreaded model provides threads that are used for handling network connections. Threads are also assigned to the requests made by remote clients and the replies received from CICS.

The threading model uses the following objects:

You can set both the initial and maximum sizes of the resource pools for these objects; see Gateway daemon resources for information on setting configuration parameters.

You can also specify these limits when you start CICS Transaction Gateway. For more information see Starting from a command line.

Consider these thread limits when setting the number of connection manager and worker threads:
System-wide limit of the maximum number of threads Process limit of the number of threads
This might be restricted by the total number of MVS™ Task Control Blocks (one is created for each UNIX System Services thread.) This limit is governed by the UNIX System Services parameters MAXTHREADS and MAXTHREADTASKS.

The total number of threads in use by the Gateway daemon can be displayed using the MVS system command /D OMVS,L,PID=nnnn , where nnnn is the process ID of the JVM running the Gateway daemon, as displayed using the SDSF PS menu option. You can also determine what values are set for the UNIX System Services parameters MAXTHREADS and MAXTHREADSTASK by examining the appropriate BPXPRMxx member of SYS1.PARMLIB. For more information about these parameters, see the z/OS UNIX System Services Planning.

The threading model is illustrated in the following figure:
Figure 1. CICS Transaction Gateway Threading model for TCP/IP and SSL protocols using a persistent socket
This figure shows the threading model used for TCP and SSL. Two paths are shown from the application to the gateway and back. The application and gateway on two different computers. The first path starts with an open call from the application which then passes to the gateways protocol handlers, continuing to the gateway connection managers, from where it returns to the application. The part of the communication path which is between the two machines is labelled handshake. The second path starts with a 'JG.flow(ECIRequest)' from the application, which passes to the Gateway's connection managers where 'ready for new work' is labeled as a requirement for continuing. The path then continues to the workers section of the gateway. Here ECI communication is used to forward data to the CICS server, via the client component of the gateway. The path then is marked wait, while the reply comes back over ECI. After the reply is received the path returns to the application. While the path is traveling between the machines on the network it is marked as TCP and SSL.

For information on how EXCI pipes constrain the maximum number of threads, see Maximum number of worker threads.


Information Information

Feedback


Timestamp icon Last updated: Tuesday, 19 November 2013


https://ut-ilnx-r4.hursley.ibm.com/tgzos_latest/help/topic/com.ibm.cics.tg.zos.doc//ctgzos/ctgthred.html