送信データ

このセクションでは、ローカル ノードからアプリケーションへの送信データ フローについて説明します。 説明するプロトコルの全体的な構造はシステム サービス制御ポイント (SSCP) とプライマリ論理ユニット (PLU) 接続に当てはまりますが、一部の機能 (遅延要求モードの使用など) は PLU 接続にのみ当てはまります。

ローカル ノードからアプリケーションに対して、次のようなデータ フローの SNA セッションに応じて異なる接続で、送信元がホストであるデータが提示されます。

  • 送信元がホスト SSCP であり、宛先が Host Integration Server 論理ユニット (LU) である関数管理データ ネットワーク サービス (FMD NS) (セッション サービス) データと関数管理データ (FMD) は、SSCP 接続でアプリケーションに送信されます。

  • 送信元がホスト PLU であり、宛先が SNA サーバー LU である FMD データは、PLU 接続でアプリケーションに送信されます。

    すべての接続について、FMD 要求のみが Data メッセージ (message-type = DATAFMI) としてアプリケーションに提示されます。 DFC 要求とセッション制御要求は Status-Control メッセージの生成に使用されます (詳細については「Status-Control メッセージ」を参照してください)。

    ローカル ノードにより、Data メッセージがアプリケーションに送信される前に、要求の応答ヘッダー (RH) インジケーターに必要なデータ フロー制御の状態変更が実行されます。

    SNA 要求の送信ヘッダー (TH) と RH インジケーターは、送信の Data メッセージでは、アプリケーションから使用できません。 その代わりに、ローカル ノードからアプリケーションに対して Data メッセージ ヘッダー内でフラグが提供されます。これは、RH インジケーターのサブセットの設定を反映していますが、ローカル ノードによって解釈され、チェーンやブラケットの使用に関するさらに不明瞭な側面からアプリケーションを保護するものです。 使用できるフラグとローカル ノードによりそれらが送信データに使用される方法については、「アプリケーションのフラグ」を参照してください。

    送信データの場合、最初のバイトは、標準的な関数管理インターフェイス (FMI) の場合は RU[0]、FMI の論理ユニット アプリケーション (LUA) バリアントの場合は TH[0] です。

    ローカル ノードからアプリケーションへのすべての Data メッセージには、メッセージ キーが含まれています。 アプリケーションへの送信データ フローごとに、ローカル ノードには一意のメッセージ キー シーケンスが保持されます。 ローカル ノードからアプリケーションに対して特定の接続で Data メッセージが送信されるときに、送信シーケンスの次のメッセージ キーがメッセージ ヘッダーに配置され、アプリケーション フラグが設定され、メッセージがアプリケーションに送信されます。 つまり、メッセージ キーにより、ローカル ノードとアプリケーション間の特定の接続で Data メッセージが一意に識別されます。 また、ローカル ノードにより、送信 Status-Control 要求メッセージにもメッセージ キーが配置されます。

    Host Integration Server によって強制される確認応答プロトコルは、次のように、SNA セッションで使用されているチェーン応答プロトコルと要求モードを反映しています。

  • 送信 RQD 要求により、メッセージ ヘッダーに ACKRQD が設定された Data メッセージが生成されます。

  • 送信 RQE 要求により、ACKRQD が設定されていない Data メッセージが生成されます。

  • 送信 RQN 要求により、ACKRQD が設定されていない Data メッセージが生成されます。

  • セッションにプライマリ即時要求モードが使用されている場合、以降の Data メッセージを受信するには、ACKRQD が設定された Data メッセージがアプリケーションによって確認応答される必要があります。

  • セッションにプライマリ遅延要求モードが使用されている場合、ACKRQD が設定された Data メッセージがアプリケーションによって直ちに確認応答される必要はありません。 Data メッセージは引き続き受信されます。

    Host Integration Server により、すべての接続に対して、送信データ確認応答プロトコルの即時応答モードと同等のものが強制されることに注意してください。 アプリケーションからは確認応答を順番に送信する必要があります。

    ローカル ノードにより、アプリケーションに対する Data メッセージのメッセージ ヘッダーに ACKRQD フィールドが設定されている場合、この Data メッセージに対する確認応答が必要であることを示しています。 アプリケーションから送信 Data メッセージを確認応答するには、同じ接続で Data メッセージと同じメッセージ キーとシーケンス場合のフィールドを含む Status-Acknowledge メッセージをローカル ノードに送信します。

    Status-Acknowledge(Ack) を受信すると、ローカル ノードにより、メッセージ キーと未処理の送信メッセージが関連付けられ、適切な SNA 要求に対する SNA 肯定応答が生成されます。

    否定確認応答の場合、アプリケーション側で Status-Acknowledge(Nack-1) メッセージを使用するようにします。 Status-Acknowledge(Nack-1) を受信すると、ローカル ノードにより、メッセージと未処理の送信メッセージが関連付けられ、適切な SNA 要求に対する SNA 否定応答とセンス データが生成されます。 アプリケーションにより、Status-Acknowledge(Nack-1) メッセージの一部として否定応答に付随すべきセンス データが提供されます。また、これが否定確認応答である Data メッセージと同じメッセージ キー、アプリケーション フラグ、シーケンス番号のフィールドが含まれている必要があります。

    優先フロー要求によって発生した Status-Control メッセージは、いつでも送信することができます。また、通常のフローの送信 Data メッセージに対する肯定または否定の確認応答の送信には影響しません。 送信 Data メッセージと、それに一致する Status-Acknowledge メッセージの間で発生することは、まったくの偶然です。 どの Status-Control メッセージが SNA 要求に対応するかの詳細については、「Status-Control メッセージ」を参照してください。

    ホストからの通常のフロー要求の形式にエラーが検出された場合や、要求がセッションの状態に適していない場合、ローカル ノードにより、次のような特徴を持つアプリケーションのエラー Data メッセージが生成されます。

  • SDI と ECI のアプリケーション フラグが設定されている。

  • エラーに関連付けられているセンス コードが Data メッセージの最初の 4 バイトを占めている (詳細については「Status-Control メッセージ」を参照してください)。

  • ACKRQD が設定されている。

    アプリケーションから Status-Acknowledge(Ack) が返される必要があります。また、ローカル ノードにより、検出されたエラーに応じたセンス コードを含む否定応答が生成されます。 このメカニズムにより、以下が実行されます。

  • 検出されたエラーをアプリケーションに通知する。

  • ローカル ノードからこの Data メッセージに対する否定応答が送信される前に、以前に受信したデータに応答することをアプリケーションに許可する。

    アプリケーション側が一連の RQE チェーンを受信しているセッションでは、ローカル ノードに各チェーンの相関情報が保持されます (アプリケーションからいずれかのチェーンに対して否定応答が送信される場合に備えて)。 ローカル ノード側で相関テーブルのエントリ数が不足した場合、追加のエントリを割り当てようとしますが (これに失敗した場合)、セッションは強制的に終了されします。 これを回避するには、このような場合に拒否したくない RQE データに対してアプリケーションから Status-Acknowledge(Ack) メッセージを送信するようにします。 RQE チェーンが 5 回連続した後の応答で十分です。 このようなメッセージは、儀礼的な確認応答と呼ばれ、ホストへの応答は生じず、単に内部の相関データが解放されます。

    次の 6 つの図は、ローカル ノードとアプリケーション間で実行されるデータ確認応答プロトコルを示しており、アプリケーションから肯定と否定の Status-Acknowledge メッセージが生成された場合の影響を示しています。

    各図の内容は次のとおりです。

  • SNA 要求または応答の関連する RH フラグ。

  • SNA 要求または応答のシーケンス番号。

  • SNA 要求または応答と Status-Acknowledge メッセージのセンス データ ("SENSE=..." と表示されます)。

  • Data メッセージの ACKRQD フィールド。

  • Data メッセージのメッセージ キー フィールド。

    わかりやすくするために、すべてのメッセージが同じ PLU セッション上の FM データ フローになると仮定します。

    次の図では、アプリケーションが確定応答 RU に対応する Data メッセージを受け入れています。

    明確な応答 RU に対応するデータ メッセージをアプリケーションが送信する方法を示す画像。
    アプリケーションから確定応答 RU に対応する Data メッセージが送信される

    次の図では、アプリケーションが複数の RU 確定応答チェーンに対応する Data メッセージを受け入れています。

    アプリケーションが複数 RU 確定応答チェーンに対応するデータ メッセージを受け入れる方法を示す画像。
    アプリケーションが複数 RU 確定応答チェーンに対応する Data メッセージを受け入れる

    次の図では、アプリケーションが確定応答チェーンに対応する Data メッセージを拒否しています。

    明確な応答チェーンに対応するデータ メッセージをアプリケーションが拒否する方法を示す画像。
    アプリケーションから確定応答チェーンに対応する Data メッセージが拒否される

    次の図では、アプリケーションが複数の RU 確定応答チェーンに対応する Data メッセージを拒否しています。

    アプリケーションが複数 RU 確定応答チェーンに対応するデータ メッセージを拒否する方法を示す画像。
    アプリケーションから複数の RU 確定応答チェーンに対応する Data メッセージが拒否される

    次の図では、ローカル ノードにより、即時応答モードが強制されています。 応答は順番に送信される必要があります。 アプリケーションにより、2 つ目の例外応答チェーンが拒否され、確定応答チェーンは受け入れられます。これは 3 つ目の例外応答チェーンの受け入れを意味します。

    ローカル ノードを示す画像では、即時応答モードが適用されます。
    ローカル ノードにより即時応答モードが強制されている

    次の図では、ローカル ノードにより、アプリケーション宛てのデータにチェーン エラー (RQD ではなく EC) が検出されています (この例では、受信チェック 0x4007を強制的に実行する必要があります。詳細については、「SSCP 接続を開く」を参照してください)。

    アプリケーション宛てのデータで、ローカル ノードがチェーン エラーを検出する方法を示す画像。
    ローカル ノードによりアプリケーション宛てのデータのチェーン エラーが検出される

関連項目

受信データ
LUA アプリケーションからの受信データ