RQR und CLEAR

Eine Anwendung, die das Übertragungsdienstprofil (TS-Profil) 4 verwendet, kann durch Senden von Status-Control(RQR) die Wiederherstellung der Sitzung anfordern. Der lokale Knoten legt dies dem Host als RQR-Anforderung vor. Hinweis: Wenn die Anwendung eine kritische Status-Acknowledge(Nack-2)-Nachricht empfangen hat, kann diese Option nicht verwendet werden, weil der lokale Knoten unmittelbar nach Status-Acknowledge(Nack-2) eine Close(PLU)-Anforderung an die Anwendung sendet und die Verbindung der primären logischen Einheit (PLU) nicht mehr gültig ist. Die RQR-Nachricht fordert den Host durch Senden einer CLEAR-Anforderung zum Zurücksetzen der Sitzung auf, wie in der folgenden Abbildung dargestellt.

Der Empfang von CLEAR bewirkt, dass die Anwendung ihren Sitzungszustand auf den Zustand zurücksetzt, der auf BIND folgt: Open(PLU) .

Eine weitere Möglichkeit für die Anwendung, Fehlerbedingungen zu behandeln, ist das Anfordern von UNBIND durch Senden von Status-Control (RSHUTD) . (Weitere Informationen finden Sie unter Von der Anwendung initiierte Beendigung.) Beachten Sie, dass der Host in diesem Fall je nach Hostkonfiguration keine neue BIND-Nachricht bereitstellen muss. Möglicherweise ist eine neue SSCP-Anforderung erforderlich (z. B. LOGON).

In der folgenden Abbildung fordert die Anwendung die Wiederherstellung durch Ausgabe von Status-Control(RQR) an. Der Host sendet CLEAR, und die Anwendung muss ihre Sitzung auf den Zustand zurücksetzen, der nach BIND (Open(PLU)) vorlag. In diesem Fall befindet sich die Anwendung jetzt zwischen eckigen Klammern und wartet auf den Start des Datenverkehrs (Start Data Traffic, SDT).

Wiederherstellung von Anwendungsanforderungen durch Ausgabe von „Status-Control(RQR)“

Weitere Informationen

Anwendung: CANCEL
Richtung nach dem Empfangen einer negativen Antwort
Richtung nach dem Senden einer negativen Antwort
Kritischer Fehler
STSN
Fehler bei einem Linkdienst
Fehler bei einem lokalen Knoten
Clientfehler