This blog entry provides some internals, how a CICS Transaction Gateway request is processed by the CICS server.
The CICS Transaction Gateway for multiplatforms (CTG) provides an API, that may be used in Java applications for multi-user access to CICS servers such as CICS Transaction Server for VSE/ESA 1.1.1 (CICS TS). You may communicate from CTG to CICS TS via ECI (External Call Interface) calls over TCP/IP or SNA. The CTG directly connects to the CICS TS for VSE/ESA server.
The CTG web page is here.
The reference I will provide points to topics in the CICS TS for z/OS info center. However, they are also relevant for CICS TS for VSE/ESA.
For more information on ECI and CTG please search in the CICS info center here. (I tried to use links, but that did not work).
An ECI request is processed as follows:
Multiple CTGs can all connect to the same CICS using a single CICS TCPIPSERVICE. There is only a single listener task (CSOL) for the whole CICS so adding more TCPIPSERVICEs does not change that or help with processing work in parallel. A benefit that using one TCPIPSERVICE per CTG gives you is the ability to stop all work coming in to CICS from a particular CTG as the TCPIPSERVICE can be closed and will only affect that CTG connection.
Even though there is only a single listener task, that task does very little processing so does not cause a problem. When data is received from the CTG, the listener task will attach a CIEP task to analyze the data and attach a mirror. More information on CIEP is here.
That CIEP will read all the data available from the CTG at the time and attach a mirror task for each application request. CIEP terminates when there is no more data to receive and leaves an outstanding async receive, so CICS is notified when more data arrives. There can be 1 CIEP task per CTG running in parallel receiving request.
The mirror tasks all run as standard mirrors. So they will be restricted due to availability of the QR TCB (quasi-reentrant task control block), TCLASS (transaction class) and any other mechanisms used to affect a normal non-terminal task running. When the mirror tasks need to send their response back to the CTG, then all the mirrors for a specific CTG will be serialized using a lock so only one is sending at a time (this is required otherwise the CTG could receive data in a random order). Also all the mirror tasks actually sending data will be serialized on the SO TCB (socket TCB) so only one mirror will actually be doing its TCPIP send at a time. As long as the CTGs (and intermediate networks) are responsive then this serialization of sending responses would not be noticed.
Thanks to a CICS colleague, who described the internals.