私のセットアップは次のとおりです。Java クライアントは、Java ソケットを使用して、CICS 5.2 アプリケーションにダイヤルします (プログラムは COBOL で記述されています)。Java クライアントは不注意です。CICS のジョブがある場合、トランザクション要求を送信します。
問題は、送信する要求が多すぎると、CICS ハードウェアが要求を十分な速度で処理できないことです。
何が起こるかというと、CICS Sockets リスナーは、CICS が一般的にどの程度過負荷になっているかを気にしません。そのため、すべての着信トランザクション要求に対して並行サーバーを作成しようとします。ただし、CICS は既存のものでビジーであるため、新しい並行サーバー用のスペースはありません (以下の * の追加情報を参照)。したがって、これらの試みはしばらくそこにとどまり、その後 GIVESOCKET TIMEOUT を報告します。
Windows 7 で Micro Focus Enterprise Server 2.2 を使用する。
プロの実装はこれをどのように処理しますか? ハードウェアが十分に高速であることはわかっていますが、キューを処理する適切な方法がないだけです。
すでにキューがある場合にリスナーにリクエストを送信しないようにクライアントに示すために、おそらくセマフォを考えていましたか？GIVESOKET に非常に大きなタイムアウトを許可することはできますか?
ところで、同時サーバーは CICS 5.2 で公平に処理されますか? つまり、処理を拒否されてキューに入れられた最初の並行サーバーが、空きがあるときに最初に実行されるということですか?
ありがとう。
- Micro Focus ES には、SEP と呼ばれるものがあります。それらはコアのようなものです。たとえば、CICS アプリケーションごとに 10 個の SEP を定義し、そのアプリケーションで並行して実行されるすべてのプログラムは、それが完了するまで SEP を保持します。10 個の SEP と 10 個の実行中のプログラムがある場合、11 番目のプログラムは、SEP が解放されるまで待機状態になります。CICS TCP/IP 並行サーバーには、それぞれに独自の SEP が必要です。したがって、「余裕がない」とは、すべての SEP に並行サーバーのインスタンスがロードされ、EZASOKET リスナー (CSKL) によって新しい並行サーバーを作成できず、GIVESOKET タイムアウト (リスナーがサーバー上で行う最初の呼び出し) を生成できないことを意味します。新しく作成された同時サーバーですが、そのようなものがないため-タイムアウトします）