受信データ
このセクションでは、アプリケーションからローカル ノードへの受信データ フローについて説明します。 説明するプロトコルの全体的な構造はシステム サービス制御ポイント (SSCP) とプライマリ論理ユニット (PLU) 接続に当てはまりますが、より複雑な側面 (遅延要求モードの使用など) は PLU 接続にのみ当てはまります。
アプリケーションでは、次のように、任意の接続で受信データを送信できます。
ホスト SSCP を対象とした機能管理データ ネットワーク サービス (FMD NS) (セッション サービス) および機能管理データ (FMD) 文字コードのデータを、SSCP 接続上のローカル ノードに送信する必要があります。
ホスト PLU を対象とする FMD データを、PLU 接続上のローカル ノードに送信する必要があります。
アプリケーションでは、Data メッセージを使用して、データ フロー制御 (DFC) またはセッション制御要求メッセージをホストに送信することはできません。 代わりに、Status-Control メッセージを使用する必要があります。 (詳細については、「Status-Control メッセージ」を参照してください。)
すべての接続について、アプリケーションでは Data メッセージのヘッダーに特定のキー フィールドを入力する必要があります。 特に、以下を行う必要があります。
メッセージの種類を DATAFMI に設定します。
この接続の受信 Data メッセージに新しいメッセージ キーを割り当てます。
必要に応じて ACKRQD フィールドを設定します。
アプリケーション フラグを設定します。 (詳細については、「アプリケーション フラグ」を参照してください。)
メッセージ ヘッダーの nxtqptr、hdreptr、numelts フィールドと、メッセージ要素の elteptr、startd フィールドは、Host Integration Server のバッファー管理ルーチンによって設定されます。 (詳細については、「DL-BASE/DMOD インターフェイス」を参照してください。) アプリケーションでは、endd フィールドを設定する必要があります。
アプリケーションでこれらのルーチンにアクセスできない場合 (たとえば、運用環境でタスク間のプロシージャ呼び出しと共有メモリがサポートされていない場合) は、ヘッダー内のすべてのフィールドをアプリケーションで設定する必要があります。
送信ヘッダー (TH) および応答ヘッダー (RH) インジケーターは、受信 Data メッセージに対してはアプリケーションで使用できません。 アプリケーションでは、メッセージ ヘッダーに適切なアプリケーション フラグを設定して、チェーンや方向などを制御する必要があります。 受信データに使用できるアプリケーション フラグの説明と、受信データ フローを制御するためにフラグを使用する方法の説明に関するこのセクション後半のトピックについては、「アプリケーション フラグ」を参照してください。
受信データについて、標準の機能管理インターフェイス (FMI) の場合、最初のバイトは RU[0] です。
受信 Data メッセージ ヘッダーにアプリケーションによって提供されるメッセージ キーは、送信 Status-Acknowledge によって参照されるこの接続上の Data メッセージを示すために、ローカル ノードによって使用されます。 アプリケーションでは、ローカル ノードとの接続ごとに受信データ フロー用に一意のメッセージ キー シーケンスを保持する必要があります。これにより、アプリケーションではメッセージ キーを使用して、接続上の受信 Data メッセージと送信 Status-Acknowledge メッセージを関連付けることができます。 アプリケーションでは、複数の RQE LUSTAT メッセージを区別するために、Status-Control 要求メッセージのメッセージ キーも指定する必要があることに注意してください。
受信データの受信確認プロトコルには、次のように、セッションで使用されるセカンダリ チェーン応答プロトコルと要求モードが反映されます。
ヘッダーに ACKRQD が設定された受信 Data メッセージでは、RQD 要求が生成されます。
ヘッダーに ACKRQD が設定されていない受信 Data メッセージでは、チェーン応答プロトコルに応じて RQE または RQN 要求が生成されます。
アプリケーションでは、エンド チェーン インジケーター (ECI) アプリケーション フラグが設定されている Data メッセージでのみ ACKRQD を設定する必要があります。
セカンダリで即時要求モードを使用することがセッションで指定されている場合、アプリケーションでは、ACKRQD を設定してデータを送信した後、その Data メッセージの Status-Acknowledge メッセージを受信していなくても、さらに Data メッセージを送信できます。 メッセージはローカル ノード内でキューに格納され、肯定応答を受信すると段階的に送信されます。
セカンダリで遅延要求モードを使用することがセッションで指定されている場合、ACKRQD を設定して Data メッセージを送信した後に、アプリケーションでは引き続き Data メッセージを送信できます。
アプリケーションによって Data メッセージのメッセージ ヘッダーに ACKRQD フィールドが設定されている場合は、この Data メッセージに対する受信確認が必要であることを示します。 ローカル ノードでは、受信 Data メッセージの受信確認を行うために、同じ接続上のアプリケーションに Status-Acknowledge メッセージを送信し、その Data メッセージと同じメッセージ キーを使用します。 (例については、このトピックの末尾にある最初の図を参照してください。)
ローカル ノードでは、その内部状態コンピューターを通じてアプリケーションからの受信 Data メッセージが処理され、正しい SNA シーケンス番号または識別子がこのフローに割り当てられ、要求のデータがホストに送信されます。 要求のチェーン応答の種類は、Data メッセージとセッション パラメーターで ACKRQD が設定されていたかどうかによって異なります。
ローカル ノードでは、ホストから Status-Acknowledge(Ack) に対する肯定応答がアプリケーションにマップされます。 アプリケーションでは、Status-Acknowledge 内のメッセージ キーを使用して、受信確認を元の Data メッセージと関連付けることができます。 したがって、特定の Data メッセージに対する Status-Acknowledge(Ack) を受信したことは、ローカル ノードがホストから受信 SNA 要求に対して肯定の SNA 応答を受信したことを意味します。 (例については、このトピックの末尾にある 2 番目の図を参照してください。)
応答は SSCP-PU セッションで吸収されることに注意してください。
送信 Status-Acknowledge(Ack) メッセージにアプリケーション フラグとシーケンス番号が含まれていることに注意してください。 このアプリケーション フラグには、応答の RH インジケーターが反映されています。 このシーケンス番号は応答からの SNA シーケンス番号です。これによって、転送サービス プロファイル (TS プロファイル) 4 を使用するアプリケーションで作業単位に対応する SNA セカンダリ シーケンス番号を追跡するためのメカニズムが提供されます。
ローカル ノードでは、ホストから Status-Acknowledge(Nack-1) メッセージに対する否定応答がアプリケーションにマップされます。 アプリケーションでは、Status-Acknowledge 内のメッセージ キーを使用して、否定の受信確認を元の Data メッセージと関連付けることができます。 送信 Status-Acknowledge(Nack-1) メッセージには、否定応答からの SNA センス コードとシーケンス番号が含まれています。 (例については、このトピックの末尾にある 3 番目と 4 番目の図を参照してください。)
ローカル ノードで受信 Data メッセージの形式にエラーが検出された場合、または Data メッセージがセッションの現在の状態に対して適切でない場合は、エラー コードを含む Status-Acknowledge(Nack-2) がアプリケーションに送信されます。 (エラー コードの一覧については、「エラー コードおよびセンス コード」を参照してください。) ローカル ノードでは、エラーの Data メッセージに対応してホストに要求が送信されることはなく、セッションの SNA シーケンス番号が先に進むこともありません。 アプリケーションでは、次の受信 Data メッセージで任意のメッセージ キーを使用できます (エラーによってクリティカルな障害が発生していない場合)。
このトピックの末尾の最後の図には、重大なチェーン エラーの例として、ACKRQD を使用するがアプリケーション フラグに ECI がない Data メッセージがアプリケーションから送信されるケースが示されています。 この特定のエラーを検出すると、ローカル ノードではアプリケーションの接続がクリティカルな障害が発生したとしてマークされ、接続が閉じられ、TERM-SELF 要求が SSCP に送信されて UNBIND が引き起こされることに注意してください。 (詳細については、「回復」を参照してください。)
優先フロー要求の生成を引き起こす受信 Status-Control メッセージは、いつでも送信することができ、受信 Data メッセージに対する肯定または否定の受信確認の送信には影響しません。 どの Status-Control メッセージが SNA 優先フロー要求に対応するかについて詳しくは、「Status-Control メッセージ」を参照してください。
以下の 5 つの図には、さまざまなチェーン応答の種類とセカンダリ セッション要求モードについての、受信データの受信確認プロトコル (および基になる SNA プロトコル) の例が示されています。
各図では次が表示されています。
Data メッセージの ACKRQD フィールド。
Data メッセージのメッセージ キー。
Data メッセージの関連するアプリケーション フラグ。
Data メッセージのエラー コード ("ERROR=..." と表示)。
SNA 要求または応答の関連する RH フラグ。
SNA 要求または応答のシーケンス番号。
SNA 要求または応答のセンス コード ("SENSE=...." と表示)。
わかりやすくするために、すべてのメッセージが同じ PLU セッションでフローすると仮定します。
次の図では、アプリケーションで正常に Data メッセージが送信されます。
アプリケーションで正常に Data メッセージが送信される次の図では、アプリケーションで正常に Data メッセージのチェーンが送信されます。
アプリケーションで正常に Data メッセージのチェーンが送信される次の図では、ホストで Data メッセージのチェーンが拒否されます。
ホストで Data メッセージのチェーンが拒否される次の図では、ホストで最初の明確な応答チェーンが拒否され、遅延要求セッションで 3 番目の例外応答チェーンが拒否されます。 3 番目のチェーンに対する否定応答は、2 番目のチェーンに対する肯定応答を意味することに注意してください。
ホストで最初の明確な応答チェーンが拒否される次の図では、ローカル ノードで、アプリケーションによる Data メッセージの ECI アプリケーション フラグのない ACKRQD の無効な使用が検出されます。 ホストにはデータが送信されないことに注意してください。 ただし、このエラーはクリティカルであるため、ローカル ノードから SSCP に TERM-SELF メッセージが送信されます。
ローカル ノードで、アプリケーションによる Data メッセージの ECI アプリケーション フラグのない ACKRDQ の無効な使用が検出される