Eingehende Daten
In diesem Abschnitt werden von der Anwendung zum lokalen Knoten eingehende Datenflows 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). Komplexere Aspekte (z. B. die Verwendung des verzögerten Anforderungsmodus) gelten jedoch nur für die PLU-Verbindung.
Die Anwendung kann eingehende Daten wie folgt über eine der Verbindungen senden:
Für den Host-SSCP vorgesehene FMD-NS-Zeichencodedaten (Function Management Data Network Services (Sitzungsdienste)) und Funktionsverwaltungsdaten (Function Management Data, FMD) sollten an den lokalen Knoten der SSCP-Verbindung gesendet werden.
FMD-Daten, die für die Host-PLU vorgesehen sind, sollten an den lokalen Knoten der PLU-Verbindung gesendet werden.
Die Anwendung kann keine Data-Nachrichten verwenden, um DFC-Nachrichten (Data Flow Control) oder Anforderungsmeldungen zur Sitzungssteuerung an den Host zu senden. Stattdessen müssen Status-Control-Nachrichten verwendet werden. (Weitere Informationen finden Sie unter Status-Control-Nachricht.)
Für alle Verbindungen muss die Anwendung bestimmte Schlüsselfelder im Header der Data-Nachricht ausfüllen. Insbesondere muss sie:
Den Nachrichtentyp auf DATAFMI festlegen.
Einen neuen Nachrichtenschlüssel für auf dieser Verbindung eingehende Data-Nachricht zuordnen.
Ggf. das Feld ACKRQD festlegen.
Die Anwendungsflags festlegen. (Weitere Informationen finden Sie unter Anwendungsflags.)
Die Felder nxtqptr, hdreptr und numelts im Nachrichtenheader sowie die Felder elteptr und startd in den Nachrichtenelementen werden von den Pufferverwaltungsroutinen von Host Integration Server eingerichtet. (Weitere Informationen finden Sie unter DL-BASE/DMOD-Schnittstelle.) Die Anwendung ist für das Festlegen des endd-Felds verantwortlich.
Wenn die Anwendung keinen Zugriff auf diese Routinen hat (wenn die Betriebsumgebung z. B. keine Intertaskprozeduraufrufe und freigegebenen Arbeitsspeicher unterstützt), müssen alle Felder im Header von der Anwendung festgelegt werden.
Die Indikatoren für TH (Transmission Header, Übertragungsheader) und RH (Response Header, Antwortheader) sind für die Anwendung für eingehende Data-Nachricht nicht verfügbar. Die Anwendung sollte die entsprechenden Anwendungsflags im Nachrichtenheader festlegen, um die Verkettung, Richtung usw. zu steuern. Eine Beschreibung der verfügbaren Anwendungsflags für eingehende Daten und spätere Themen in diesem Abschnitt mit einer Beschreibung, wie die Flags zum Steuern eingehender Datenflüsse verwendet werden, finden Sie unter Anwendungsflags.
Bei eingehenden Daten ist das erste Byte RU[0] für die Standardfunktionsverwaltungsschnittstelle (FMI) vorgesehen.
Der von der Anwendung im Header für eingehende Data-Nachricht bereitgestellte Nachrichtenschlüssel wird vom lokalen Knoten verwendet, um anzugeben, auf welche Data-Nachricht in dieser Verbindung eine ausgehende Status-Acknowledge-Nachricht verweist. Die Anwendung sollte eine eindeutige Nachrichtenschlüsselsequenz für den eingehenden Datenfluss bei jeder Verbindung mit dem lokalen Knoten verwalten, damit die Anwendung den Nachrichtenschlüssel verwenden kann, um eingehende Data-Nachrichten und ausgehende Status-Acknowledge-Nachrichten für die Verbindung zu korrelieren. Beachten Sie, dass die Anwendung auch einen Nachrichtenschlüssel für Status-Control Request-Nachrichten bereitstellen muss, um zwischen mehreren RQE LUSTAT-Nachrichten zu unterscheiden.
Das Protokoll zur Bestätigung eingehender Daten spiegelt wie folgt das sekundäre Kettenantwortprotokoll und den Anforderungsmodus wider, der in der Sitzung verwendet wird:
Eingehende Data-Nachrichten, für die ACKRQD im Header festgelegt ist, generieren RQD-Anforderungen.
Eingehende Data-Nachrichten, für die ACKRQD nicht im Header festgelegt ist, generieren abhängig vom Kettenantwortprotokoll RQE- oder RQN-Anforderungen.
Die Anwendung sollte ACKRQD nur für Data-Nachrichten festlegen, für die das ECI-Anwendungsflag (End Chain Indicator, Kettenendeindikator) festgelegt ist.
Wenn die Sitzung angibt, dass sekundär der unmittelbare Anforderungsmodus verwendet wird, kann die Anwendung nach dem Senden von Daten mit festgelegtem ACKRQD auch dann weiterhin Data-Nachrichten senden, wenn für diese Data-Nachricht keine Status-Acknowledge-Nachricht empfangen wurde. Die Nachrichten werden innerhalb des lokalen Knotens in die Warteschlange eingereiht und nacheinander gesendet, wenn positive Antworten empfangen werden.
Wenn die Sitzung angibt, dass sekundär der verzögerte Anforderungsmodus verwendet wird, kann die Anwendung nach dem Senden einer Data-Nachricht mit festgelegtem ACKRQD weiterhin Data-Nachrichten senden.
Wenn die Anwendung das ACKRQD-Feld im Nachrichtenheader einer Data-Nachricht festlegt, gibt dieses an, dass eine Bestätigung für diese Data-Nachricht erforderlich ist. Der lokale Knoten bestätigt eine eingehende Data-Nachricht, indem er eine Status-Acknowledge-Nachricht über dieselbe Verbindung an die Anwendung sendet und denselben Nachrichtenschlüssel wie die Data-Nachricht verwendet. (Eine Veranschaulichung finden Sie in der ersten Abbildung am Ende dieses Themas.)
Der lokale Knoten verarbeitet eingehende Data-Nachrichten von der Anwendung über die internen Zustandscomputer, weist die richtige SNA-Sequenznummer oder einen Bezeichner für diesen Flow zu und sendet die Daten in einer Anforderung an den Host. Der Kettenantworttyp der Anforderung hängt davon ab, ob ACKRQD in der Data-Nachricht und den Sitzungsparametern festgelegt wurde.
Der lokale Knoten ordnet eine positive Antwort des Hosts auf eine Status-Acknowledge(Ack)-Nachricht der Anwendung zu. Die Anwendung kann den Nachrichtenschlüssel in der Status-Acknowledge-Nachricht verwenden, um die Bestätigung mit der ursprünglichen Data-Nachricht zu korrelieren. Daher beinhaltet der Empfang einer Status-Acknowledge(Ack) -Nachricht für eine bestimmte Data-Nachricht, dass der lokale Knoten eine positive SNA-Antwort vom Host auf die eingehende SNA-Anforderung empfangen hat. (Eine Veranschaulichung finden Sie in der zweiten Abbildung am Ende dieses Themas.)
Beachten Sie, dass Antworten in der SSCP-PU-Sitzung aufgenommen werden.
Beachten Sie, dass ausgehende Status-Acknowledge(Ack)-Nachrichten Anwendungsflags und eine Sequenznummer enthalten. Die Anwendungsflags spiegeln die RH-Indikatoren in der Antwort wider. Die Sequenznummer ist die SNA-Sequenznummer aus der Antwort und stellt einen Mechanismus für Anwendungen bereit, die das Übertragungsdienstprofil 4 (Transmission Service Profile, TS-Profil) verwenden, um die sekundäre SNA-Sequenznummer zu verfolgen, die einer Arbeitseinheit entspricht.
Der lokale Knoten ordnet eine negative Antwort des Hosts auf eine Status-Acknowledge(Nack-1)-Nachricht der Anwendung zu. Die Anwendung kann den Nachrichtenschlüssel in der Status-Acknowledge-Nachricht verwenden, um die negative Bestätigung mit der ursprünglichen Data-Nachricht zu korrelieren. Die ausgehende Status-Acknowledge(Nack-1) -Nachricht enthält die SNA-Erkennungscodes und die Sequenznummer aus der negativen Antwort. (Eine Veranschaulichung finden Sie in der dritten und vierten Abbildung am Ende dieses Themas.)
Wenn der lokale Knoten einen Fehler im Format einer eingehenden Data-Nachricht erkennt oder die Data-Nachricht nicht für den aktuellen Zustand der Sitzung geeignet ist, sendet er eine Status-Acknowledge(Nack-2)-Nachricht an die Anwendung, die einen Fehlercode enthält. (Eine Liste der Fehlercodes finden Sie unter Fehler- und Erkennungscodes.) Der lokale Knoten sendet entsprechend der fehlerhaften Data-Nachricht keine Anforderung an den Host und setzt die SNA-Sequenznummer für die Sitzung nicht herauf. Die Anwendung kann einen beliebigen Nachrichtenschlüssel in der nächsten eingehenden Data-Nachricht verwenden (vorausgesetzt, aus dem Fehler resultiert kein kritischer Fehler).
Ein Beispiel für einen schwerwiegenden Verkettungsfehler, bei dem die Anwendung eine Data-Nachricht mit ACKRQD, aber ohne ECI in den Anwendungsflags sendet, ist in der letzten Abbildung am Ende dieses Themas dargestellt. Beachten Sie, dass der lokale Knoten nach der Erkennung dieses bestimmten Fehlers die Verbindung der Anwendung als schwerwiegend fehlerhaft markiert, die Verbindung schließt und eine TERM-SELF-Anforderung an den SSCP sendet, um eine UNBIND-Anforderung auszulösen. (Weitere Informationen finden Sie unter Wiederherstellung.)
Eingehende Status-Control-Nachrichten, die die Generierung von Anforderungen im beschleunigten Flow verursachen, können jederzeit gesendet werden und wirken sich nicht auf das Senden einer positiven oder negativen Bestätigung an ausgehende Data-Nachrichten aus. Weitere Informationen dazu, welche Status-Control-Nachrichten SNA-Anforderungen im beschleunigten Flow entsprechen, finden Sie unter Status-Control-Nachricht.
Die folgenden fünf Abbildungen veranschaulichen Beispiele für eingehende Datenbestätigungsprotokolle (und die zugrunde liegenden SNA-Protokolle) für verschiedene Typen von Kettenantworten und sekundäre Sitzungsanforderungsmodi.
Die Abbildungen zeigen Folgendes:
Das ACKRQD-Feld in Data-Nachrichten.
Der Nachrichtenschlüssel für Data-Nachrichten.
Alle relevanten Anwendungsflags für Data-Nachrichten.
Fehlercodes (angezeigt als "ERROR=...") für Data-Nachrichten.
Die relevanten RH-Flags in SNA-Anforderungen/-Antworten.
Sequenznummern für SNA-Anforderungen/-Antworten.
Erkennungscodes (angezeigt als "SENSE=....") für SNA-Anforderungen/-Antworten.
Der Einfachheit halber wird davon ausgegangen, dass alle Nachrichten in derselben PLU-Sitzung fließen.
In der folgenden Abbildung sendet die Anwendung erfolgreich eine Data-Nachricht.
Anwendung sendet erfolgreich eine Data-NachrichtIn der folgenden Abbildung sendet die Anwendung erfolgreich eine Kette von Data-Nachrichten.
Anwendung sendet erfolgreich eine Kette von Data-NachrichtenIn der folgenden Abbildung lehnt der Host eine Kette von Data-Nachrichten ab.
Host lehnt eine Kette von Data-Nachrichten abIn der folgenden Abbildung lehnt der Host die erste Kette mit eindeutiger Antwort und die dritte Ausnahmeantwortkette für eine verzögerte Anforderungssitzung ab. Beachten Sie, dass die negative Antwort auf die dritte Kette eine positive Antwort auf die zweite Kette beinhaltet.
Host lehnt die erste Kette mit eindeutiger Antwort abIn der folgenden Abbildung erkennt der lokale Knoten die ungültige Verwendung von ACKRQD durch die Anwendung ohne ECI-Anwendungsflag in einer Data-Nachricht. Beachten Sie, dass keine Daten an den Host gesendet werden. Da der Fehler jedoch kritisch ist, sendet der lokale Knoten eine TERM-SELF-Nachricht an den SSCP.
Lokaler Knoten erkennt die ungültige Verwendung von ACKRQD ohne ECI-Anwendungsflag in einer Data-Nachricht