ZIETrans 画面確定の調整

ZIETrans 画面確定の信頼性とパフォーマンスの両方を向上させるために、ZIETrans 画面確定をさまざまな方法で調整できます。その場合、以下のような事項を決定する必要があります。
パフォーマンスと信頼性の向上に、コンテンション解消を使用するかどうか。
ZIETrans でコンテンション解消の折衝に成功した場合、より効率的な通信を実現でき、ホスト・システムとの対話の遅延が減少します。詳しくは、コンテンション解消 (TN3270E のみ)を参照してください。
計画の遅延を調整するかどうか。
default.delayInterval を変更して、応答時間が長いアプリケーションや環境での応答時間の向上や、信頼できるパフォーマンスの確保などを実現する必要がある場合があります。ホスト・システムによっては、特定の画面を送信するまでに長い応答時間の遅延が繰り返し発生することがあります。遅延は、大量の処理が必要なホストのステップで発生することがあります。また、ときどき要求が多くなるネットワーク・リソースが遅延に関係することもあります。これらのケースでは、delayInterval の値を大きくすると、画面確定の信頼性が向上することがあります。ホストの平均応答時間だけでなく、典型的な最長変動も考慮する必要があります。典型的な操作条件に適した値を選択してください。同様に、default.delayStart、default.appletDelayInterval、 fast3270E.minimumWait、および fast5250.minimumWait 設定でも、さまざまな場合の遅延を制御できます。表 2 で設定の説明を参照してください。
default.delayInterval のような遅延値の設定が小さすぎる場合にどうなるか。
ZIETrans ランタイムで、画面の完成とホストからのデータ送信の完了を判断できます。これらの徴候の例は、以下のとおりです。
  • ZIETrans 画面がブランクの場合に「Refresh」をクリックすると、正しい画面が表示される。
  • 画面が部分的に (不完全に) レンダリングされているように見える場合に、「Refresh」をクリックすると、正しい画面が表示される。
  • 誤った画面カスタマイズ・イベントが呼び出される。この場合、画面認識基準で不完全な画面を正しく検査できないため、誤ったカスタム変換が表示されることがある。
遅延値の設定が大きすぎる場合にどうなるか。
ユーザーに対する応答時間が長くなり、最悪の場合は、画面を取得するための待機が終了します。アプリケーション・チューニングでは、アプリケーションとそのアプリケーションが使用されるネットワーク環境について運用面の判断を行い、バランスを保つ必要があります。
他の問題があるシナリオを修正できるかどうか。
計画の遅延を調整することによって解決される状況に似ていても、ソリューションが異なる場合があります。
  • アプリケーションで使用禁止画面を処理できるようにします。この場合、 OIA フラグの取得待機に関するカスタマイズ設定 keyboardInhibitedWaitoiaLockMaxWait を使用します。
  • 5250 接続の ZIETrans での画面更新は、計画の遅延を調整した後でも失敗することがあります。nextScreenClass 設定を使用して、Fast5250 計画をオフにする必要が生じることがあります。
自動最新表示を使用するかどうか。
ご使用のネットワーク環境と要件に基づいて、自動最新表示を使用すると応答時間の向上に役立つことがあります。詳しくは、自動最新表示を参照してください。