このセクションでは、ローカル ノードからアプリケーションへの送信データ フローについて説明します。 説明されているプロトコルの全体的な構造は、システム サービス制御ポイント (SSCP) とプライマリ論理ユニット (PLU) 接続に適用されますが、特定の機能 (遅延要求モードの使用など) は PLU 接続にのみ適用されます。
ローカル ノードは、次のように、データがフローする SNA セッションに応じて、ホストからアプリケーションに送信されるデータを異なる接続で表示します。
ホスト SSCP から送信され、Host Integration Server 論理ユニット (LU) に送信される機能管理データ ネットワーク サービス (FMD NS) (セッション サービス) データと関数管理データ (FMD) は、SSCP 接続上のアプリケーションに送信されます。
ホスト PLU で生成され、SNA サーバー LU に送信された FMD データは、PLU 接続上のアプリケーションに送信されます。
すべての接続に対して、FMD 要求のみが データ メッセージとしてアプリケーションに表示されます (メッセージの種類は DATAFMI です)。 DFC およびセッション制御要求は、 Status-Control メッセージを生成するために使用されます。 (詳細については、「 Status-Control メッセージ」を参照してください。
ローカル ノードは、アプリケーションにデータ メッセージを送信する前に、要求の応答ヘッダー (RH) インジケーターに必要な データ フロー制御状態の変更を実行します。
SNA 要求伝送ヘッダー (TH) および RH 標識は、アウトバウンドデータメッセージでアプリケーションで利用できません。 代わりに、ローカル ノードは、RH インジケーターのサブセットの設定を反映する Data メッセージ ヘッダーにアプリケーション フラグを提供しますが、ローカル ノードによって解釈され、チェーンとブラケットの使用のよりあいまいな側面からアプリケーションを保護します。 使用可能なフラグと、ローカル ノードが送信データで使用する方法の詳細については、「 アプリケーション フラグ」を参照してください。
送信データの場合、最初のバイトは標準関数管理インターフェイス (FMI) の場合は RU[0]、FMI の論理ユニット アプリケーション (LUA) バリアントの場合は TH[0] です。
ローカル ノードからアプリケーションへの すべてのデータ メッセージには、メッセージ キーが含まれています。 ローカル ノードは、アプリケーションへの送信データ フローごとに一意のメッセージ キー シーケンスを保持します。 ローカル ノードは、特定の接続上のアプリケーションに データ メッセージを送信すると、送信シーケンス内の次のメッセージ キーをメッセージ ヘッダーに配置し、アプリケーション フラグを設定して、メッセージをアプリケーションに送信します。 つまり、メッセージ キーは、ローカル ノードとアプリケーションの間の特定の接続で データ メッセージを一意に識別します。 ローカル ノードでは、送信 Status-Control 要求 メッセージにもメッセージ キーが配置されることに注意してください。
Host Integration Server によって適用される受信確認プロトコルには、次のように、SNA セッションで使用されているチェーン応答プロトコルと要求モードが反映されます。
送信 RQD 要求では、メッセージ ヘッダーに ACKRQD が設定されたデータ メッセージが生成されます。
送信 RQE 要求では、ACKRQD が設定されていないデータ メッセージが生成されます。
送信 RQN 要求では、ACKRQD が設定されていないデータ メッセージが生成されます。
セッションでプライマリ即時要求モードを使用する場合は、ACKRQD が設定されたデータ メッセージをアプリケーションで確認してから、さらにデータ メッセージを受信する必要があります。
セッションでプライマリ遅延要求モードを使用する場合、ACKRQD が設定されたデータ メッセージをアプリケーションですぐに確認する必要はありません。 データ メッセージは引き続き受信されます。
Host Integration Server では、すべての接続に対して送信データ受信確認プロトコルに同等の即時応答モードが適用されることに注意してください。 アプリケーションは、受信確認を順番に送信する必要があります。
ローカル ノードがデータ メッセージのメッセージ ヘッダーの ACKRQD フィールドをアプリケーションに設定する場合は、このデータ メッセージに対する受信確認が必要であることを示します。 アプリケーションは、 データ メッセージと 同じメッセージ キーフィールドとシーケンス番号フィールドを含む、同じ接続上のローカル ノードに Status-Acknowledge メッセージを送信することで、送信 データ メッセージを確認します。
Status-Acknowledge(Ack) を受信すると、ローカル ノードはメッセージ キーを未処理の送信メッセージと関連付け、適切な SNA 要求に対する SNA 肯定応答を生成します。
アプリケーションでは、 否定受信確認として Status-Acknowledge(Nack-1) メッセージを使用する必要があります。 Status-Acknowledge(Nack-1) の受信時に、ローカル ノードはメッセージを未処理の送信メッセージと関連付け、SNA 否定応答と適切な SNA 要求に対するセンス データを生成します。 アプリケーションは 、Status-Acknowledge(Nack-1) メッセージの一部として否定応答に付随するセンス データを提供し、これが否定受信確認である データ メッセージと同じメッセージ キー、アプリケーション フラグ、シーケンス番号フィールドを含める必要があります。
迅速フロー要求によって発生する状態制御メッセージはいつでも送信でき、通常のフロー送信データ メッセージへの肯定受信確認または否定受信確認の送信には影響しません。 送信 データ メッセージと一致する Status-Acknowledge メッセージの間で発生する可能性があるという事実は、まったく偶然です。 SNA 要求に対応する Status-Control メッセージの詳細については、「 Status-Control メッセージ」を参照してください。
ホストからの通常のフロー要求の形式でエラーが検出された場合、または要求がセッションの状態に不適切な場合、ローカル ノードは、次の特性を持つアプリケーションのエラー データ メッセージを生成します。
SDI および ECI アプリケーション フラグが設定されます。
エラーに関連付けられているセンス コードは、 データ メッセージの最初の 4 バイトを占めます。 (詳細については、「 Status-Control メッセージ」を参照してください。
ACKRQD が設定されています。
アプリケーションは Status-Acknowledge(Ack) を返す必要があり、ローカル ノードは検出されたエラーに適したセンス コードを伝達する負の応答を生成します。 このメカニズムでは、次の処理が行われます。
検出されたエラーをアプリケーションに通知します。
ローカル ノードがこのデータ メッセージに否定応答を送信する前に、アプリケーションが以前に受信したデータに応答できるようにします。
アプリケーションが一連の RQE チェーンを受信しているセッションでは、ローカル ノードは各チェーンの相関関係情報を保持します (アプリケーションがいずれかのチェーンに否定的な応答を送信する場合)。 ローカル ノードが関連付けテーブルのエントリを使い切った場合、より多くのエントリの割り当てを試み、(これが失敗した場合)、セッションの終了が強制されます。 これを回避するには、アプリケーションは、この場合に拒否したくない RQE データの Status-Acknowledge(Ack) メッセージを提供する必要があります。 5 つの連続する RQE チェーンの後の応答で十分です。 このようなメッセージは、表敬の確認と呼ばれ、ホストへの応答を生み出すのではなく、内部相関データを解放するだけです。
次の 6 つの図は、ローカル ノードとアプリケーションの間で適用されるデータ受信確認プロトコルを示し、アプリケーションが肯定的および否定的な Status-Acknowledgee メッセージを生成する効果を示しています。
次の図を示します。
SNA 要求/応答における RH フラグの関連性。
SNA 要求/応答のシーケンス番号。
SNA 要求/応答および Status-Acknowledge メッセージのセンス データ ("SENSE=...." と表示されます)。
データ メッセージの ACKRQD フィールド。
データ メッセージのメッセージ キー フィールド。
わかりやすくするために、すべてのメッセージは同じ PLU セッションで流れる FM データであると見なされます。
次の図では、アプリケーションは明確な応答 RU に対応する データ メッセージを受け入れます。
アプリケーションが明確な応答 RU に対応するデータ メッセージを送信する次の図では、アプリケーションは、複数 RU の確定応答チェーンに対応する データ メッセージを受け入れます。
アプリケーションは、複数 RU 確定応答チェーンに対応するデータ メッセージを受け入れます次の図では、アプリケーションは明確な応答チェーンに対応する データ メッセージを拒否します。
アプリケーションが明確な応答チェーンに対応するデータ メッセージを拒否する次の図では、アプリケーションは、複数 RU の明確な応答チェーンに対応する データ メッセージを拒否します。
アプリケーションが、複数 RU 確定応答チェーンに対応するデータ メッセージを拒否する次の図では、ローカル ノードによって即時応答モードが適用されます。 応答は順番に送信する必要があります。 アプリケーションは、2 番目の例外応答チェーンを拒否し、明確な応答チェーンを受け入れます。これは、3 番目の例外応答チェーンの受け入れを意味します。
ローカル ノードで即時応答モードが適用される次の図では、ローカル ノードは、アプリケーション宛てのデータでチェーン エラー (RQD ではなく EC) を検出します。 (この例では、受信チェック0x4007が有効である必要があります。詳細については、「 SSCP 接続を開く」を参照してください)。
ローカル ノードは、アプリケーション宛てのデータでチェーン エラーを検出します