Freigeben über


Stilllegen

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.

Abbildung, die zeigt, wie eine Anwendung den Host stillsetzt und die Stilllegung freigibt.
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.

Abbildung, die zeigt, wie eine Anwendung versucht, den Host zu stilllegen, aber der Host lehnt 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.

Abbildung, die zeigt, wie ein Host QEC sendet, während die Anwendung eine Kette sendet.
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