サービス実行プロセスの数を動的に増やしてみてください。これを行うには、[Current status] 列で [Details] をクリックし、次に [Enterprise Server Details] ページの [Requested Service Execution Processes] で新しい数を指定して、[Update] をクリックします。短い遅延後に新しいプロセスがリストに表示されます。この操作の成功は、たとえ問題の外部症状がまだ存在していても、共有メモリがロックされていないこと、およびエンタープライズ・サーバ・インスタンスが引き続き特定のレベルで正しく機能していることを意味します。
ダンプ X データセットを使用して、アクティブなサービス実行プロセス (cassi プロセス) の数をチェックしてください。次に、ディスパッチ制御ブロック (サービス実行プロセスごとに 1 つ) を調べます。現在、サービス実行プロセスはトランザクションで占有されていますか?その占有トランザクションは各 cassi プロセスで同じですか、あるいは各 cassi プロセスによって実行された最後のコマンドは同じですか?これらのいずれかに当てはまる場合は、次の可能性について検討してください。
その問題タイプの十分な要求が到着して、使用可能な cassi プロセスをすべてブロックしたため、エンタープライズ・サーバ・インスタンス全体が障害を起こしているように見えます。これは、顧客アプリケーションの問題を示している可能性があります。
十分な通常の長期実行要求が到着して、使用可能な cassi プロセスをすべて占有したため、エンタープライズ・サーバ・インスタンス全体が障害を起こしているように見えます。この可能性が高い場合は、サービス実行プロセスの数を減らすことで問題を修正できる場合があります。
もう 1 つの可能性として、エンタープライズ・サーバ・インスタンスの共有メモリがロックされていることが考えられます。これをチェックするための最良の方法は、ダンプ X データセット内の最後のトレース・エントリの日時をダンプの日時と比較することです。2 つの時間の間のギャップが大きいほど、共有メモリがロックされている可能性は高くなります。共有メモリがロックされていない場合は、エンタープライズ・サーバ・インスタンスが何を待っているのかを確認してみてください。共有メモリがロックされている場合は、どのプロセスが共有メモリをこの状態のままにしたのかを確認してみてください。