Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Das Stilllegungsprotokoll wird nur für Sitzungen unterstützt, die das FM-Profil 4 (Function Management, Funktionsverwaltung) verwenden. Das Stilllegungsprotokoll kann von einer der beiden Sitzungshälften initiiert werden.
Wenn eine Anwendung ihre Partnersitzungshälfte stilllegen möchte, sendet sie einen Status-Control(QEC) Request an den lokalen Knoten. Der Knoten generiert eine an den Host gerichtete QEC-Anforderung, die den Host auffordert, sich nach Abschluss der aktuellen ausgehenden Kette stillzulegen.
Wenn der Host sich stilllegt, sendet er eine QC-Anforderung, die der lokale Knoten der Anwendung als Status-Control(QC) Request (mit ACKRQD) präsentiert. Der Host verbleibt in einem Stilllegungszustand, bis die Anwendung einen Status-Control(RELQ) Request sendet. Der lokale Knoten sendet die RELQ-Anforderung an den Host, und der Host setzt die Kommunikation in der primären Sitzung der logischen Einheit (PLU) fort.
Wenn bei dem Versuch, den Host stillzulegen, ein Fehler auftritt, antwortet der Host mit einer negativen QEC-Antwort, die der lokale Knoten der Anwendung als Status-Control (QEC) Negative-Acknowledge-1 präsentiert.
Umgekehrt wird der Anwendung ein Status-Control(QEC) Request (ohne ACKRQD) präsentiert, wenn eine QEC-Anforderung vom Host empfangen wird. In dieser Richtung kann QEC nicht abgelehnt werden. Der lokale Knoten erzwingt immer das Stilllegen der Anwendung, nachdem er ihr einen Status-Control(QEC) Request präsentiert hat, indem weitere Versuche zum Senden eingehender Daten abgelehnt werden. Wenn die Anwendung stillgelegt ist, sollte sie einen Status-Control(QC) Request an den lokalen Knoten senden, der eine QC-Anforderung an den Host sendet. Die Anwendung kann anschließend durch eine RELQ-Anforderung des Hosts freigegeben werden, die der lokale Knoten der Anwendung als Status-Control(RELQ) Request präsentiert.
Der Empfang einer CLEAR- oder UNBIND–BIND-Sequenz, Close(PLU)–Open(PLU) , bewirkt, dass der Stilllegungszustand aufgehoben wird.
Die folgenden drei Abbildungen veranschaulichen die Stilllegungsprotokolle zwischen dem lokalen Knoten und der Anwendung und die Beziehung dieser Protokolle zu den zugrunde liegenden SNA-Protokollen.
In der ersten Abbildung legt die Anwendung den Host still und hebt dann die Stilllegung auf.

Anwendung legt den Host still und hebt dann die Stilllegung auf
In der folgenden Abbildung versucht die Anwendung, den Host stillzulegen, aber der Host lehnt die Stilllegung ab und fährt mit der nächsten Kette fort.

Anwendung versucht, den Host stillzulegen, aber der Host lehnt ab und fährt mit der nächsten Kette fort
In der folgenden Abbildung sendet der Host QEC, während die Anwendung eine Kette sendet. Die Anwendung schließt die Kette ab und sendet einen Status-Control(QC) Request. Der Host hebt die Stilllegung durch Senden von RELQ auf, und der lokale Knoten sendet einen Status-Control(RELQ) Request an die Anwendung, die dann eine neue Kette initiiert.

Host sendet QEC, während die Anwendung eine Kette sendet
Weitere Informationen
Öffnen der PLU-Verbindung
PLU-Sitzung
Ausgehende Verkettung
Eingehende Verkettung
Segmentübermittlung
Brackets
Richtung
Geschwindigkeit und Segmentierung
Bestätigung und Ablehnung von Daten]
Herunterfahren und Stilllegen
Wiederherstellung
Von der Anwendung initiierte Beendigung
LUSTATs]
Daten des Monitors für Antwortzeiten