通常の TN3270 プロトコル
この問題が発生した理由は、非拡張 TN3270 プロトコル に、ホスト・アプリケーションの画面が完了したことを、ホストがクライアントに 通知する手段が組み込まれていないことです(TN3270 は、文字指向の接続で ある Telnet を基礎として、画面指向のプロトコルである 3270 データ・ストリーム をインプリメントしたものです)。このため、ホストはいくつかのデータ・ブロックをクライアントに送ることができなくても、「OK、アプリケーション画面は完了したので、ユーザーがデータを入力できるようになりました」と通知します。しかし、それぞれのブロックが着信するとき、 このアプリケーション画面の最後のブロックであるかどうかの指示はありません。クライアントの視点から見ると、次のようなイベントが発生します。
- コマンドとデータのブロックが着信する。クライアントは、 入力禁止標識を設定し、ブロックを処理して、 新しいデータをセッション・ウィンドウの指定部分に表示する。その後、クライアントは入力禁止標識をクリアし、待機する。
- 30 ミリ秒が経過する。
- 別のコマンドとデータのブロックが着信する。クライアントは、前の ステップ 1 と同じようにブロックを処理する。このブロックにより、画面の別の部分が更新される。クライアントは待機する。
- 30 ミリ秒が経過する。
このプロセスが、人間のオペレーターにとって問題になることはありません。 その理由はさまざまですが、ここでは重要ではありません。
ただし、このプロセスは、マクロ・ランタイムにとっては画面認識中に 問題になります。マクロ・ランタイムが、画面認識中に画面が更新されるたび、 および OIA イベントが発生するたびに (評価のやり直しを参照)、 アプリケーション画面と一致する有効な次のマクロ画面を検索することを 思い出してください。このため、マクロ・ランタイムは画面が完全に更新される前に一致を検出する 可能性があります。例えば、アプリケーション画面の行 3 に "ISPF Primary Option Menu" という文字が あるときに認識が発生するように、ストリング・ディスクリプターが指示しているとします。ホストが行 3 を更新してこれらの文字を表示したときに、 マクロ・ランタイムは一致が発生したと判断しますが、ホストが アプリケーション画面の残りの更新を完了したかどうかは考慮しません。