次の方法で共有


受信データの確認と拒否

要求例外 (RQE) または確定応答が必要 (RQD) など、応答が未処理の SNA チェーン データを送受信するたびに、ローカル ノードには相関テーブル エントリが保持されます。 テーブル エントリが使い果たされると、ローカル ノードにより、最も多くのテーブル エントリを使用しているセッションが終了されます。 アプリケーションには Status-Error メッセージ (コード 0x46) と Close(PLU) 要求が送信され、ホストには TERM-SELF メッセージが送信されます。 テーブル エントリの不足 (受信) を回避するには、方向変更 (CD) (半二重の場合) データ、または ACKRQD、または任意の Status-Control(CHASE) 、または Status-Control(LUSTAT)ACKRQD を送信します。 送信の不足を回避するには、「PLU 接続を開く」で説明されているように、儀礼的な確認応答メッセージを送信します。

ローカル ノードからホストに対して、次のようにチェーン応答モードを指定してデータのチェーンが送信されます。

  1. 確定

    アプリケーションからローカル ノードに対して、ACKRQD フィールドが設定された Data メッセージと、セカンダリに確定または確定/例外応答モードが使用されるように指定された BIND パラメーターが送信されます。

  2. 例外

    アプリケーションからローカル ノードに対して、ACKRQD フィールドが設定されていない Data メッセージと、セカンダリに例外または確定/例外応答モードが使用されるように指定された BIND パラメーターが送信されます。

  3. 応答なし

    アプリケーションからローカル ノードに対して、ACKRQD フィールドが設定されていない Data メッセージと、セカンダリに応答なしモードが使用されるように指定された BIND パラメーターが送信されます。

    アプリケーションからの Data メッセージに設定された ACKRQD に、BIND パラメーターに指定されたチェーン応答モードが反映されていない場合、ローカル ノードからは、重大ではないエラー コードを示す Status-Acknowledge(Nack-2) が返されます。 たとえば、アプリケーションによって ACKRQD が指定されているのに、BIND パラメーターでローカル ノードの確定応答チェーンの送信が許可されていない場合などです。

    ケース 1 の場合、アプリケーションは、ローカル ノードに送信されたすべての関数管理データ (FMD) チェーンに対して確認応答を受け取ります。

  • ホストからの肯定応答は、Status-Acknowledge(Ack) メッセージとしてアプリケーションに返されます。

  • ホストからの否定応答は、SNA センス コードを含む Status-Acknowledge(Nack-1) メッセージとして返されます。

  • ローカル ノードによってメッセージの送信が試行されたときに検出されたエラーは、同等のエラー コードを含む Status-Acknowledge(Nack-2) メッセージとして返されます。

    ケース 2 の場合、アプリケーションは、ローカル ノードに送信された FMD チェーンの確認応答のみを受け取ります。

  • ホストからの否定応答は、SNA センス コードを含む Status-Acknowledge(Nack-1) メッセージとして返されます。

  • ローカル ノードによってメッセージの送信が試行されたときに検出されたエラーは、同等のエラー コードを含む Status-Acknowledge(Nack-2) メッセージとして返されます。

    ケース 3 の場合、ノードによってメッセージのエラーが検出され、アプリケーションに Status-Acknowledge(Nack-2) を送信されるときに、アプリケーションは、ローカル ノードに送信された FMD チェーンの確認応答のみを受け取ります。 ホストが行うことができる唯一の反論は、センス修飾子フィールドに要求のシーケンス番号を指定して後続の LUSTAT 0x400A (サポートされていない応答) を送信することです。 これは、通常どおり Status-Control(LUSTAT) としてアプリケーションに提示されます。

    アプリケーションが Status-Acknowledge(Ack) または Status-Acknowledge(Nack-1) を受け取るたびに、以前に送信されたすべてのチェーンのホスト内のパートナー ハーフセッションが受け取ったことが暗黙的に確認されます。

    ケース 2 の場合、通常、アプリケーションは自身から送信されたチェーンに対してホストからそのような応答を受け取ることはありません。ケース 3 の場合、アプリケーションがそのような応答を受け取ることはありません。 そのため、以前に送信されたすべてのチェーンの受信をホストに確認させるには、アプリケーションから ACKRQD を設定した Status-Control(CHASE) 要求を発行する必要があります。 その結果、ローカル ノードからホストに対して SNA CHASE 要求が生成されます。 この CHASE に対する応答の受信により、この CHASE 要求と、アプリケーションから送信されたそれ以前のすべてのチェーンがホストによって受信されたことが確認されます。 ローカル ノードから Status-Control(CHASE) 確認応答が発行され、その旨がアプリケーションに通知されます。

    次の 3 つの図は、ローカル ノードとアプリケーション間の受信データの確認と拒否プロトコルと、それらのプロトコルが基になる SNA プロトコルとどのように関係するかを示しています。

    最初の図では、アプリケーションによって受信データ チェーンに ACKRQD フィールドが設定され、そのチェーンと以前に送信されたすべてのチェーンの受信をホストに確認させています。

    アプリケーションが ACKRQD フィールドを設定する方法を示す画像。
    アプリケーションにより ACKRQD フィールドが設定される

    次の図では、Status-Acknowledge(Nack-1) によって最後のチェーンが拒否されていますが、以前に送信されたすべてのデータ チェーンのホストによる受信は確認されています。

    Status-Acknowledge(Nack-1) が最後のチェーンを拒否し、受信を確認する方法を示す画像。
    Status-Acknowledge(Nack-1) によって最後のチェーンが拒否され、受信が確認される

    次の図では、アプリケーションにより、Status-Control(CHASE) が使用され、対応する CHASE 要求と以前に送信されたすべてのチェーンの受信をホストに確認させています。

    Status-Control(CHASE) を使用してホストを取得し、対応する CHASE 要求の受信を確認する方法を示す画像。
    Status-Control(CHASE) を使用して、対応する CHASE 要求の受信をホストに確認させる処理を

関連項目

PLU 接続を開く
PLU セッション
送信チェーン
受信チェーン
セグメントの配信
Brackets
方向
ペーシングとチャンキング
データの確認と拒否]
シャットダウンと休止
回復
アプリケーションが開始する終了
LUSTAT]
応答時間モニターのデータ