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 instance 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 (SEPs) using the dump X dataset. Inspect the despatch control blocks, one for each service execution process. Are all SEPs currently occupied with a transaction? Is the occupying transaction the same for each SEP or was the last command executed by each process the same? If either of these is true, consider the following possibilities:
That enough requests of the problem type have arrived to block all the available processes, such that it appears that the whole enterprise server instance has failed. This might indicate a customer application issue.
That enough normal long running requests have arrived to occupy all available processes, such that it appears that the whole enterprise server instance has failed. If this seems likely, you might be able to fix the problem by increasing the number of service execution processes.
Another possibility is that the enterprise server instance'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 enterprise server instance is waiting for. If shared memory is locked, try to determine which process left shared memory in this condition.