Ausgehende Daten
In diesem Abschnitt werden die ausgehenden Datenflows vom lokalen Knoten zur Anwendung beschrieben. Die allgemeine Struktur der beschriebenen Protokolle gilt für die Verbindungen des Systemdienststeuerungspunkts (System Services Control Point, SSCP) und der primären logischen Einheit (Primary Logical Unit, PLU). Bestimmte Features (z. B. die Verwendung des verzögerten Anforderungsmodus) gelten jedoch nur für die PLU-Verbindung.
Der lokale Knoten stellt der Anwendung die vom Host stammenden Daten über unterschiedliche Verbindungen in Abhängigkeit von der SNA-Sitzung, in der die Daten fließen, wie folgt dar:
FMD NS-Daten (Function Management Data Network Services) (Sitzungsdienste) und FMD-Daten (Function Management Data) die vom Host-SSCP stammen und an die logische Host Integration Server-Einheit (Logical Unit, LU) geleitet werden, werden über die SSCP-Verbindung an die Anwendung gesendet.
FMD-Daten, die von der Host-PLU stammen und an eine SNA-Server-LU geleitet werden, werden über die PLU-Verbindung an die Anwendung gesendet.
Für alle Verbindungen werden der Anwendung nur FMD-Anforderungen als Data-Nachrichten (mit „message-type = DATAFMI“) präsentiert. DFC- und Sitzungssteuerungsanforderungen werden verwendet, um Status-Control-Nachrichten zu generieren. (Weitere Informationen finden Sie unter Status-Control-Nachricht.)
Der lokale Knoten führt die Statusänderungen für die Datenflowsteuerung aus, die von den RH-Indikatoren (Response Header, Anforderungsheader) in der Anforderung angefordert werden, bevor eine Data- -Nachricht an die Anwendung gesendet wird.
Die Indikatoren für SNA-Anforderungs-TH (Transmission Header, Übertragungsheader) und RH sind für die Anwendung für ausgehende Data-Nachrichten nicht verfügbar. Stattdessen stellt der lokale Knoten Anwendungsflags im Data-Nachrichtenheader bereit, die die Einstellungen einer Teilmenge der RH-Indikatoren widerspiegeln, aber vom lokalen Knoten interpretiert werden, um die Anwendung von den komplexeren Aspekten der Verkettung und Klammerverwendung abzuschirmen. Eine Beschreibung der verfügbaren Flags und der Art und Weise, wie der lokale Knoten diese für ausgehende Daten verwendet, finden Sie unter Anwendungsflags.
Bei ausgehenden Daten ist das erste Byte „RU[0]“ für die Standardfunktionsverwaltungsschnittstelle (Function Management Interface, FMI) und „TH[0]“ für die LUA-Variante (Logical Unit Application) von FMI.
Alle Data-Nachrichten vom lokalen Knoten an eine Anwendung enthalten einen Nachrichtenschlüssel. Der lokale Knoten verwaltet eine eindeutige Nachrichtenschlüsselsequenz für jeden ausgehenden Datenflow zu einer Anwendung. Wenn der lokale Knoten eine Data-Nachricht über eine bestimmte Verbindung an eine Anwendung sendet, platziert er den nächsten Nachrichtenschlüssel in der ausgehenden Sequenz in den Nachrichtenheader, legt die Anwendungsflags fest und sendet die Nachricht an die Anwendung. Dies bedeutet, dass der Nachrichtenschlüssel eine Data-Nachricht in einer bestimmten Verbindung zwischen dem lokalen Knoten und der Anwendung eindeutig identifiziert. Beachten Sie, dass der lokale Knoten auch Nachrichtenschlüssel für ausgehende Status-Control Request-Nachrichten platziert.
Das Bestätigungsprotokoll, das von Host Integration Server erzwungen wird, spiegelt das in der SNA-Sitzung verwendete Kettenantwortprotokoll und den Anforderungsmodus folgendermaßen wider:
Ausgehende RQD-Anforderungen generieren Data-Nachrichten mit im Nachrichtenheader festgelegtem ACKRQD-Feld.
Ausgehende RQE-Anforderungen generieren Data-Nachrichten ohne festgelegtes ACKRQD-Feld.
Ausgehende RQN-Anforderungen generieren Data-Nachrichten ohne festgelegtes ACKRQD-Feld.
Wenn die Sitzung den primären unmittelbaren Anforderungsmodus verwendet, muss eine Data-Nachricht mit festgelegtem ACKRQD-Feld von der Anwendung bestätigt werden, bevor weitere Data-Nachrichten empfangen werden.
Wenn die Sitzung den primären verzögerten Anforderungsmodus verwendet, muss eine Data-Nachricht mit festgelegtem ACKRQD-Feld nicht sofort von der Anwendung bestätigt werden. Data-Nachrichten werden weiterhin empfangen.
Beachten Sie, dass Host Integration Server das Äquivalent des unmittelbaren Antwortmodus für das Protokoll zur Bestätigung ausgehender Daten für alle Verbindungen erzwingt. Die Anwendung muss Bestätigungen in der angegebenen Reihenfolge senden.
Wenn der lokale Knoten das ACKRQD-Feld im Nachrichtenheader einer Data-Nachricht an die Anwendung festlegt, gibt dieses an, dass eine Bestätigung für diese Data-Nachricht erforderlich ist. Die Anwendung bestätigt eine ausgehende Data-Nachricht, indem sie eine Status-Acknowledge-Nachricht in derselben Verbindung an den lokalen Knoten sendet, die den gleichen Nachrichtenschlüssel und die gleichen Sequenznummernfelder wie die Data-Nachricht enthält.
Beim Empfang einer Status-Acknowledge(Ack)-Nachricht korreliert der lokale Knoten den Nachrichtenschlüssel mit ausstehenden ausgehenden Nachrichten und generiert eine positive SNA-Antwort auf die entsprechende SNA-Anforderung.
Die Anwendung sollte die Status-Acknowledge(Nack-1)-Nachricht als negative Bestätigung verwenden. Beim Empfang einer Status-Acknowledge(Nack-1) -Nachricht korreliert der lokale Knoten die Nachricht mit ausstehenden ausgehenden Nachrichten und generiert eine negative SNA-Antwort plus Erkennungsdaten an die entsprechende SNA-Anforderung. Die Anwendung liefert die Erkennungsdaten, die die negative Antwort als Teil der Status-Acknowledge(Nack-1) -Nachricht begleiten sollen, und muss den gleichen Nachrichtenschlüssel, die gleichen Anwendungsflags und die gleichen Sequenznummernfelder wie die Data-Nachricht enthalten, für die es sich um eine negative Bestätigung handelt.
Status-Control-Nachrichten, die durch Anforderungen im beschleunigten Flow verursacht werden, können jederzeit gesendet werden und wirken sich nicht auf das Senden einer positiven oder negativen Bestätigung an ausgehende Data-Nachrichten im normalen Flow aus. Die Tatsache, dass sie zwischen einer ausgehenden Data-Nachricht und der entsprechenden Status-Acknowledge-Nachricht auftreten können, ist rein zufällig. Weitere Informationen dazu, welche Status-Control-Nachrichten SNA-Anforderungen entsprechen, finden Sie unter Status-Control-Nachricht.
Wenn der Host Fehler im Format einer normalen Flowanforderung erkennt oder die Anforderung für den Sitzungszustand ungeeignet ist, generiert der lokale Knoten eine Data-Fehlernachricht mit den folgenden Merkmalen für die Anwendung:
Die SDI- und ECI-Anwendungsflags sind festgelegt.
Der dem Fehler zugeordnete Erkennungscode belegt die ersten vier Bytes der Data-Nachricht. (Weitere Informationen finden Sie unter Status-Control-Nachricht.)
ACKRQD ist festgelegt.
Die Anwendung sollte eine Status-Acknowledge(Ack)-Nachricht zurückgeben, und der lokale Knoten generiert eine negative Antwort, die den für den erkannten Fehler geeigneten Erkennungscode enthält. Dieser Mechanismus führt Folgendes aus:
Er informiert die Anwendung über den erkannten Fehler.
Er ermöglicht der Anwendung, auf alle zuvor empfangenen Daten zu antworten, bevor der lokale Knoten die negative Antwort auf diese Data-Nachricht sendet.
In Sitzungen, in denen die Anwendung eine Reihe von RQE-Ketten empfängt, behält der lokale Knoten Korrelationsinformationen für jede Kette bei (falls die Anwendung negative Antworten an eine der Ketten senden soll). Wenn dem lokalen Knoten keine Einträge in der Korrelationstabelle mehr zur Verfügung stehen, versucht er, weitere Einträge zuzuordnen. Falls dies nicht möglich ist, muss er Sitzungen beenden. Um dies zu verhindern, sollte die Anwendung Status-Acknowledge(Ack) -Nachrichten für RQE-Daten bereitstellen, die in diesem Fall nicht abgelehnt werden sollen. Eine Antwort nach fünf aufeinanderfolgenden RQE-Ketten sollte ausreichen. Solche Nachrichten werden als optionale Empfangsbestätigungen bezeichnet und führen nicht zu einer Antwort an den Host, sondern geben lediglich interne Korrelationsdaten frei.
Die folgenden sechs Abbildungen veranschaulichen das zwischen dem lokalen Knoten und der Anwendung erzwungene Datenbestätigungsprotokoll und zeigen die Auswirkungen der Generierung von positiven und negativen Status-Acknowledge-Nachrichten durch die Anwendung.
Die Abbildungen zeigen Folgendes:
Die relevanten RH-Flags in SNA-Anforderungen/-Antworten.
Die Sequenznummer von SNA-Anforderungen/-Antworten.
Alle Erkennungsdaten (angezeigt als „SENSE=...“) für SNA-Anforderungen/-Antworten und Status-Acknowledge-Nachrichten.
Das ACKRQD-Feld in Data-Nachrichten.
Das Nachrichtenschlüsselfeld in Data-Nachrichten.
Der Einfachheit halber wird davon ausgegangen, dass es sich bei allen Nachrichten um FM-Daten in ein und derselben PLU-Sitzung handelt.
In der folgenden Abbildung akzeptiert die Anwendung eine Data-Nachricht, die einer RU mit eindeutiger Antwort entspricht.
Anwendung, die eine Data-Nachricht sendet, die einer RU mit eindeutiger Antwort entsprichtIn der folgenden Abbildung akzeptiert die Anwendung eine Data-Nachricht, die einer Multi-RU-Kette mit eindeutiger Antwort entspricht.
Anwendung, die eine Data-Nachricht akzeptiert, die einer Multi-RU-Kette mit eindeutiger Antwort entsprichtIn der folgenden Abbildung lehnt die Anwendung eine Data-Nachricht ab, die einer Kette mit eindeutiger Antwort entspricht.
Anwendung, die eine Data-Nachricht ablehnt, die einer Kette mit eindeutiger Antwort entsprichtIn der folgenden Abbildung lehnt die Anwendung eine Data-Nachricht ab, die einer Multi-RU-Kette mit eindeutiger Antwort entspricht.
Anwendung, die eine Data-Nachricht ablehnt, die einer Multi-RU-Kette mit eindeutiger Antwort entsprichtIn der folgenden Abbildung erzwingt der lokale Knoten den unmittelbaren Antwortmodus. Antworten müssen in der vorgegebenen Reihenfolge gesendet werden. Die Anwendung lehnt die zweite Ausnahmeantwortkette ab und akzeptiert die Kette mit eindeutiger Antwort, was die Akzeptanz der dritten Ausnahmeantwortkette impliziert.
Lokaler Knoten erzwingt unmittelbaren AntwortmodusIn der folgenden Abbildung erkennt der lokale Knoten einen Verkettungsfehler (RQD, aber nicht EC) in Daten, die für die Anwendung bestimmt sind. (In diesem Beispiel muss die Empfangsüberprüfung 0x4007 in Kraft sein. Weitere Informationen finden Sie unter Öffnen der SSCP-Verbindung.)
Lokaler Knoten, der einen Verkettungsfehler in Daten erkennt, die für die Anwendung bestimmt sind