After upgrading to z/OS 2.5 seeing problems with the Gen Multi Sockets CICS Listener TISRVMSL and its error handling.
After some time since the TISRVMSL was started, these symptoms may start to appear:
1. The server-side CICS MSGUSR log will contain many messages of the form:
TISRVMSL TIML TASK=######## MM/DD/YYYY HH:MM:SS START TRANSACTION FAILED FOR TRAN Gen_Server_Trancode
TISRVMSL TIML TASK=######## MM/DD/YYYY HH:MM:SS CICS ERROR, RESPONSE=00000069, RESP2=00000008
TISRVMSL TIML TASK=######## MM/DD/YYYY HH:MM:SS LISTENER TAKESOCKET BACK FAILED FOR SERVER Gen_Server_Trancode
TISRVMSL TIML TASK=######## MM/DD/YYYY HH:MM:SS SOCKET ERROR, RETCODE=-0000001, ERRNO=00001002
TISRVMSL TIML TASK=######## MM/DD/YYYY HH:MM:SS ACCEPT CALL FAILED
TISRVMSL TIML TASK=######## MM/DD/YYYY HH:MM:SS SOCKET ERROR, RETCODE=-0000001, ERRNO=00001002
NOTE: RESPONSE=00000069 means USERIDERR and RESP2=00000008 means the USERID is unknown, thus the above error situation is for a security failure.
2. Client connections may hang/loop/spin when a security violation occurs instead of returning the expected message "TIRM621E: Error creating semaphore, can't access server"
Also, the MSGUSR log does not contain the expected message "GIVESOCKET NOT TAKEN".
(Gen EDGE Community post: Security violations behavior has changed in GUI client-server)
Gen 8.6 COBOL/CICS Distributed Process servers using TISRVMSL under z/OS 2.5
There is a known TISRVMSL problem that only seems to get exposed with TCP/IP changes under z/OS 2.5.
The TISRVMSL error handling of conditions like security violations/failures does not release the current socket and eventually, the available socket pool is exhausted.
Workaround: Recycle the TISRVMSL
Resolution: Apply Gen 8.6 PTF LU08295 ("TISRVMSL LOOPS/DOES NOT PROCESS SOCKETS WHEN HANDLING ERRORS")
NOTE: This PTF only affects TISRVMSL, as it fixes a problem with socket management handling when sending the error response. It does not impact the actual Gen servers so the PTF should be relatively easy to deploy.