Definition for T09303E
Article ID: 49695
Updated On:
Products
Issue/Introduction
Description:
Message T09303E is missing from the CPT Messages manual. Message is described here.
Environment
Release:
Component: CPT
Resolution
Solution:
T09303E mod_name Accept calls being delayed for port ppppp MSOCK ssss
Reason:
Module mod_name is having problems with Accept calls for port ppppp with an MSOCK value of ssss. This message is generated an errno = 24 (EMFILE) condition was received on an Accept Socket call. This errno states per IBM documentation that "The socket descriptor table is full. Check the maximum sockets specified in MAXDESC()." ". If CPT detects this condition has occurred two(2) or more times for a CPT listener then CPT will issue a "EXEC CICS DELAY FOR SECONDS(1)" to allow existing connections to terminate and free up a socket in the socket descriptor table.
The MSOCK parameters on the T09MCICS and T09MLSTN statements limits the number of sessions which can be active concurrently for a server.
The MSOCK parameter on the T09MCICS statement is a maximum for a region (between 50 and 2000). The MSOCK parameter on the T09MLSTN statement is the maximum for the server (between 50 and 2000). Make sure that you set the MSOCK parameter on the T09MCICS statement to be equal or larger than the MSOCK parameter on the T09MLSTN statements for the servers.
CICS has task limits, MXT can be up to 999. When CICS has some kind of condition which restricts work flow (SOS, maximum task, file contention, ETC) sessions back up and cannot run through the CICS system in a prompt fashion. If you overrun these task limits with server sessions then CICS will not run some of the sessions. These sessions stall out and then timeout when passing the API session from the server to the daughter task. The MSOCK limits for a server are much higher than the current CICS task or transaction limits which will cause CICS to lose CPT sessions at CICS task limit events.
This is a CICS limit which CPT cannot work around. When a site gets to a CICS limit (be it a task, storage or etc.) CICS will throttle back work that prevents the normal work flow of a CPT server.
TCPIP has a limit of concurrent sessions which can be allocated to a single server. When the CPT CICS servers cannot pass sessions in a timely fashion the CICS server will eventually fall into an accept() error condition when a site reaches this maximum session condition. The accept() error condition will occur over and over and will look like a large loop eating up all available CPU on the CICS QR task.
As a workaround to prevent the accept() error loop, CPT will terminate a CPT server should it get the same accept() error condition 20 times in a row. Terminating a CPT server when its new sessions are blocked is a better choice than letting a server fall into a high CPU usage loop. We don't want to accept new server sessions when they cannot be processed inside the CICS region.
Action:
Check the MSOCK parameter on the T09MLSTN configuration macro for the CPT Listen Tool or the ACMMSOCK field in the ACM to determine if the expected number of concurrent connections (MSOCK) for port ppppp has been set too low. If the value ssss is too low, then increase the value, and recycle the CPT listener.
Should a CPT server experience a resource problem under CICS (out of storage, CICS at maximum tasks, the transaction class is at maximum task for the server transaction, file contention, etc) then the site needs to correct the resource problem inside the CICS address space. The site may have to restart the server had the server task associated with port ppppp previously terminated.
Feedback
