Find out whether all client requests are suffering from lack of response from the enterprise server, or just one type of request.
Try dynamically increasing the number of service execution processes by clicking Details in the Current status column, then on the Enterprise Server Details page, specifying the new number in Requested Service Execution Processes and clicking Update. The new processes should appear in the list after a short delay. Success shows that shared memory is not locked and that the enterprise server is still functioning correctly at some level, even though the external symptoms of the problem might still be present.
Check the number of active service execution processes (cassi processes), using the dump X dataset. Inspect the despatch control blocks, one for each service execution process. Are all service execution processes currently occupied with a transaction? Is the occupying transaction the same for each cassi process or was the last command executed by each cassi process the same? If either of these is true, consider the following possibilities:
Another possibility is that the server's shared memory is locked. The best way to check for this is to compare the date and time of the last trace entry in the dump X dataset to the date and time of the dump. The larger the gap between the two times, the more likely it is that shared memory is locked. If shared memory is not locked, try to determine what the server is waiting for. If shared memory is locked, try to determine which process left shared memory in this condition.
Another possibility is that rather than the failure being the result of some problem with the application or the enterprise server, it is instead the result of the enterprise server running up against the operating system's process limits. This is discussed at length in the section Process Limits.