シャットダウン プロトコルは、ホスト アプリケーションが通常のフロー要求をさらに送信しないようにする手段を提供します。 このプロトコルは、ホスト アプリケーションがセッションを順番に終了する必要があり、機能管理 (FM) プロファイル 3 または 4 を使用するセッションでのみ使用できる場合に使用されます。
ローカル ノードがホストから SHUTD 要求を受け取った場合は、 状態制御 (SHUTD) 要求 ( ACKRQD なし) を発行して、便利なタイミングで休止状態に入るようアプリケーションに要求します。 アプリケーションによって、便利なものが決まります。 たとえば、 Status-Session (BETB) を受信した後などです。
アプリケーションが休止の準備ができていると判断したら、この遷移を示す Status-Control(SHUTC) 要求 ( ACKRQD なしで再び) を発行する必要があります。 ローカル ノードは、 SHUTC 要求を送信することで、この変更をホストに通知します。 ホストは通常のフロー送信要求の送信を続行でき、その後、次のいずれかのアクションを実行できます。
ホストは 、UNBIND 要求を送信することによって、プライマリ論理ユニット (PLU) セッションを終了します。 ローカル ノードは、 Close(PLU) 要求 をアプリケーションに送信して PLU 接続を閉じます。 システム・サービス制御ポイント (SSCP) セッションはアクティブなままです。
ホストは 、RELQ 要求を送信してシャットダウン プロシージャを破棄します。 ローカル ノードは、(ACKRQDを使用して) Status-Control(RELQ) 要求をアプリケーションに送信し、PLU セッションでの送信を再開できることを示します。 RELQ は、FM プロファイル 4 を使用するセッションでのみサポートされます。
ホストは、伝送サービス プロファイル (TS プロファイル) 3 または 4 である CLEAR を送信してセッションをリセットします。 この影響の 1 つは、休止状態を解放することです。 (詳細については、「 回復」を参照してください)。
次の 2 つの図は、ローカル ノードとアプリケーションの間のシャットダウン プロトコルと、それらのプロトコルが基になる SNA プロトコルとどのように関連しているかを示しています。
次の図では、アプリケーションがブラケット内状態で送信している間、ホストは SHUTD を送信します。 アプリケーションはプロセスを完了し、Status-Control(SHUTC) 要求を送信します。ホストは UNBIND を送信して PLU セッションを終了します。 ローカル ノードが PLU 接続を閉じます。
アプリケーションがブラケット内状態で送信している間にホストが SHUTD を送信する次の図では、アプリケーションがブラケット内状態で送信している間、ホストは SHUTD を送信します。 アプリケーションはブラケットを完了し、 Status-Control(SHUTC) 要求を送信した後、ホストは RELQ を送信して休止状態からアプリケーションを解放します。 ローカルノードは Status-Control(RELQ) リクエスト をアプリケーションに送信し、新しいブロックを開始します。
アプリケーションがブラケット内状態で送信している間にホストが SHUTD を送信する
こちらもご覧ください
PLU 接続を開く
PLU セッション
送信チェーン
インバウンドチェイニング
セグメント配信
Brackets
方向
ペーシングとチャンク
データの確認と拒否]
シャットダウンと休止
回復
アプリケーションから開始された終了
LUSTATs]
応答時間モニター データ