この章では、アクションの処理に関係するタイミングの問題についていくつか説明し、 これらの問題に対処するために使用できるリソースについて説明します。
ここでは、前のアクションに未完了の副次作用があるために、 アクションが期待どおりに実行されないシナリオについて説明します。
次の 2 つの設定値を使用して、実行時にアクション後の休止を追加できます。
マクロ・ランタイムは人間のユーザーよりはるかに迅速にアクションを 実行するので、マクロの再生中に予測しない問題が発生し、 アクションが予想通りに実行されない可能性があります。 この原因は、前のアクションへの依存関係が生じることです。
アプリケーション画面を切り替えるキー・ストロークを例に取ります。 アプリケーション画面がすでに切り替わっていることを 後続のアクションが予期しているにもかかわらず、実際には アプリケーション画面がまだ更新の途中である場合、後続のアクションは失敗します。
他の状況でも、マクロ・ランタイムがそれぞれのアクションを前のアクションの直後に 実行すると、アクション間のタイミングに依存するエラーが発生する場合があります。
「マクロ (Macro)」タブの「アクション間の休止 (Pause Between Actions)」フィールド によって、次のような場合でのマクロ・ランタイムの待ち時間を指定します。
当初、「アクション間の休止 (Pause Between Actions)」は、 入力およびプロンプト・アクションの後だけでなく、すべて のタイプのアクションの後の 休止として実装されていました。現在では、次のように実装されています。
デフォルトでは、「アクション間の休止 (Pause Between Actions)」チェック・ボックスは 使用可能になっており、タイムアウト値は 300 ミリ秒に設定されています。 したがって、マクロ・ランタイムは、デフォルトで次の処理を行います。
「アクション間の休止 (Pause Between Actions)」はすべてのマクロ画面に影響する ことに注意してください。つまり、この 1 項目を設定することで、問題がある 可能性のあるマクロ画面を個別に変更しなくても、マクロ全体のタイミング・エラーを 回避できます。
特定のマクロ画面の「アクション間の休止 (Pause Between Actions)」を延長または短縮 したい場合、または「アクション間の休止 (Pause Between Actions)」が重要な意味を持つ マクロ画面が少ししかない場合には、「画面 (Screens)」タブの「一般」 タブにある「休止時間の設定 (Set Pause Time)」設定値を使用できます。
デフォルトでは、このチェック・ボックスは使用不可になっています。
マクロ画面でこの設定値を使用可能にすると、マクロ・ランタイムはこの特定の マクロ画面内で、指定されたミリ秒数を「アクション間の休止 (Pause Between Actions)」に 使用します。
例えば、ScreenA の「休止時間の設定 (Set Pause Time)」チェック・ボックス を選択し、値を 500 ミリ秒に設定した場合、マクロ・ランタイムは ScreenA の最後の 入力またはプロンプト・アクション以外の各入力またはプロンプト・アクションの 後に 250 ミリ秒間待ち、ScreenA 内の最後のアクションの後に 500 ミリ秒間待ちます。
「休止時間の設定 (Set Pause Time)」を使用可能にしたマクロ画面を マクロ・ランタイムが処理する際には、「マクロ (Macro)」タブの 「アクション間の休止 (Pause Between Actions)」オプションの設定値は 無視し、「休止時間の設定 (Set Pause Time)」の設定値のみを使用します。
マクロ画面内で特定のアクションの後に追加の休止が必要な場合は、 そのアクションの後に休止アクションを追加できます。 休止アクションに指定した待ちは、アクション間の休止または 休止時間の設定によって発生する待ちに追加されます。
ホストが新しいアプリケーション画面の表示を完全に終了する前に、 マクロ・ランタイムが ScreenB のアクションの処理を開始するという バグが、マクロ画面 ScreenB にあるとします。 このタイミングの異常が問題になる状況はほとんどないかも しれませんが、例えば ScreenB の最初のアクションが抽出アクションであり、 マクロ・ランタイムがこのアクションによって アプリケーション画面の行 15 と 16 からデータを読み取るとします。 ホストが新規データを行 15 から 16 にすべて書き込む時間を待たず、マクロ・ランタイムがこのアクションを実行したとします。
この問題を分析すると、次のことが確認されます。
要約すれば、このタイミングの問題が起こった結果、 ホストが行 15 と 16 の更新を完了する前に、 マクロ・ランタイムが新しいアプリケーション画面の行 15 と 16 を読み取りました。
この問題が発生した理由は、拡張されていない TN3270 プロトコル に、ホスト・アプリケーションの画面が完了したことを、ホストがクライアントに 通知する手段が組み込まれていないことです (TN3270 は、文字指向の接続で ある Telnet を基礎として、画面指向のプロトコルである 3270 データ・ストリーム をインプリメントしたものです)。このため、ホストはいくつかのデータ・ブロックをクライアントに送ることができなくても、「OK、アプリケーション画面は完了したので、ユーザーがデータを入力できるようになりました」と通知します。 しかし、それぞれのブロックが着信するとき、 このアプリケーション画面の最後のブロックであるかどうかの指示はありません。 クライアントの視点から見ると、次のようなイベントが発生します。
ホストが新しいホスト・アプリケーション・データ画面を完全に 表示するまで、このプロセスは継続します。 クライアントは、ホスト・アプリケーションの画面が完了したかどうか 分からない状態で待機し続けます (詳しくは、マクロ・ランタイムによるマクロ画面の処理方法を参照してください)。
このプロセスが、人間のオペレーターにとって問題になることはありません。 その理由はさまざまですが、ここでは重要ではありません。
ただしこのプロセスは、マクロ・ランタイムにとっては画面認識中に 問題になります。マクロ・ランタイムが、画面認識中に画面が更新されるたび、 および OIA イベントが発生するたびに (評価のやり直しを参照)、 アプリケーション画面と一致する有効な次のマクロ画面を検索することを 思い出してください。 このため、マクロ・ランタイムは画面が完全に更新される前に一致を検出する 可能性があります。例えば、アプリケーション画面の行 3 に "ISPF Primary Option Menu" という文字が あるときに認識が発生するように、ストリング・ディスクリプターが指示しているとします。 ホストが行 3 を更新してこれらの文字を表示したときに、 マクロ・ランタイムは一致が発生したと判断しますが、ホストが アプリケーション画面の残りの更新を完了したかどうかは考慮しません。
この問題の解決法は 3 つあります。
これらの解決策について、以下のサブセクションで説明します。
この方法は場合によっては機能しますが、込み入っていて信頼性がありません。 ScreenB の記述部分に十分なディスクリプターを追加することにより、 アプリケーション画面の重要な部分が更新されるまで、マクロ・ランタイム が ScreenB を認識しないようにします。
セッションが通常の TN3270 セッションである場合、 またはコンテンション解消機能を使用しない TN3270E セッションである 場合には、遅延の挿入が最適な解決策です。 つまり、入力アクション (この例では ScreenA) によって ホストが新しいアプリケーション画面を送信した後、 数百ミリ秒以上の休止を挿入します。 この遅延により、マクロ・ランタイムが次のマクロ画面 (ScreenB) の アクションの処理を開始する前に、ホストがアプリケーション画面を更新する ための十分な時間を取ることができます。
このシナリオで、入力アクションの後に休止を挿入する 方法はいくつかあります。
通常の TN3270 セッションと、コンテンション解消機能を使用可能に した TN3270E セッションの両方でマクロを実行する必要がある場合は、XML マクロ言語 に備わっているいくつかの属性が役立ちます。画面の完了に関係する属性を参照してください。
TN3270E (拡張) は、セッションが接続する LU または LU プールを ユーザーが指定できるようにした TN3270 プロトコルの拡張形式です。 また、サーバーに ASCII モードで接続するため (例えば、ファイアウォールに ログオンするため) のネットワーク仮想端末装置 (NVT) プロトコル もサポートしています。
コンテンション解消モードは TN3270E のオプショナル機能で、TN3270E サーバー のすべてではなく一部がこの機能をサポートしています。 この機能は、ホストがアプリケーション画面の更新を完了したかどうか クライアントが認識できないという問題を解決します。 クライアントが TN3270E セッションを実行していて、 コンテンション解消をサポートするサーバーに接続している場合は、 ホストがアプリケーション画面の更新を完了するまで、 マクロ・ランタイムは新しいマクロ画面を認識しません。
Host On-Demand では、TN3270 でなく TN3270E を使用するように 3270 ディスプレイ・セッションを設定できます。このためには、3270 ディスプレイ・セッション構成パネル の「接続構成 (Connection configuration)」ウィンドウで、 該当するラジオ・ボタンをクリックします。
サーバーがコンテンション解消をサポートしている場合には、通常、Host On-Demand は TN3270E サーバーと自動的にコンテンション解消モードで通信します。ただし、 HTML パラメーターによって、コンテンション解消モードを使用不可に設定することもできます (オンライン・ヘルプの『NegotiateCResolution』を参照)。
Host On-Demand は、以下の両方の環境でマクロの単一バージョンを サポートする際にマクロ開発者が経験する問題に対処するために、3 つの エレメント属性を備えています。
これらの属性は、コード・エディターを使用して追加する必要があります。
<HAScript> エレメントの ignorepauseforenhancedtn パラメーター を true に設定すると、コンテンションを解決する環境でセッションが 実行されている場合、マクロの再生中に マクロ・ランタイムは休止アクション (<pause> エレメント) を スキップします。 コンテンションを解決しない環境で実行するためのマクロを開発し (休止アクション を挿入)、コンテンションを解決する環境でもそのマクロを不要な遅延を 入れずに (休止アクションを無視して) 実行する必要が生じた場合には、 この属性を使用できます。
この属性を true に設定すると、マクロ・ランタイムは コンテンションを解決しない環境では休止アクションを処理 しますが (指定されたミリ秒数だけ待つ)、コンテンションを解決する環境では 休止アクションを無視します。
ただし、この属性を true に設定すると、マクロ・ランタイムは マクロ内の休止アクション (<pause> エレメント) をすべてスキップ します (アプリケーション画面を更新する時間を取るために挿入された 休止だけでなく)。 次のサブセクションでは、この 2 次的な問題について説明します。
<pause> エレメントの ignorepauseoverride パラメーター を、特定の <pause> エレメント内で true に設定すると、<HAScript> エレメント内で ignorepauseforenhancedtn 属性が true に設定されていても、マクロ・ランタイムはその <pause> エレメントを処理します (指定された ミリ秒数だけ待つ)。
コンテンションを解決する環境で <HAScript> エレメントの ignorepauseforenhancedtn 属性を true に設定した場合で も、<pause> エレメントをスキップせずに 常に実行したい場合は、<pause> エレメント内でこの属性を true に 設定します。
<HAScript> エレメントの delayifnotenhancedtn パラメーター をゼロ以外の値に設定すると、OIA (オペレーター情報域) が変更されたという通知を マクロ・ランタイムが受け取ったときに、マクロ・ランタイムは指定された ミリ秒数だけ自動的に休止します。
コンテンションを解決する環境 (休止アクションを 挿入する必要がない) でマクロを開発し、コンテンションを解決しない環境 (アプリケーション画面 を完了する時間を取るために、マクロ画面に休止アクションが必要になる場合が ある) でもそのマクロを実行する必要が生じた場合には、この属性を使用できます。
この属性を true に設定した場合、コンテンションを解決しない環境で マクロを実行すると、OIA が変更されたという通知を受け取るたびに、 マクロ・ランタイムは指定されたミリ秒数だけ休止を挿入します。 例えば、200 ミリ秒の休止を指定すると、マクロ・ランタイムは OIA が 変更されるたびに 200 ミリ秒間待ちます。
OIA に対する変更の通知があるたびにマクロ・ランタイムが休止することを、要約的に累積する効果により、マクロ・ランタイムが新しいマクロ画面のアクションの 処理を開始する前に、アプリケーション画面が完了します。 マクロ・ランタイムは、コンテンションを解決しない環境でセッションが 実行されていることを検出したときにのみ、これらの余分の休止を挿入します。
この属性の制限は、マクロ・ランタイムがこれらの余分の休止をすべての 画面の処理中に追加することです (画面の更新が問題になっている画面の 処理中だけでなく)。 ただし、余分に費やされる待ち時間は少しです。 また、より重要な点として、この属性を使用すれば コンテンションを解決しない環境にマクロを迅速に適応させることが できます。個々の画面をテストして、画面更新の問題があるそれぞれの 画面に休止アクションを挿入する必要はありません。