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.
In diesem Abschnitt werden eingehende Datenflüsse von der Anwendung zum lokalen Knoten beschrieben. Die Gesamtstruktur der beschriebenen Protokolle gilt für den System Services Control Point (SSCP) und die primäre logische Einheit (PLU)-Verbindungen, aber komplexere Aspekte, wie der Einsatz des verzögerten Anforderungsmodus, gelten ausschließlich für die PLU-Verbindung.
Die Anwendung kann eingehende Daten zu beliebigen Verbindungen senden, wie folgt:
Funktionsverwaltungsdatennetzwerkdienste (FMD NS) (Sitzungsdienste) und zeichenkodierte Funktionsverwaltungsdaten (FMD), die für den Host-SSCP vorgesehen sind, sollten an den lokalen Knoten innerhalb der SSCP-Verbindung gesendet werden.
FMD-Daten, die für den Host-PLU vorgesehen sind, sollten an den lokalen Knoten in der PLU-Verbindung gesendet werden.
Die Anwendung kann datennachrichten nicht verwenden, um Datenflusssteuerungsnachrichten (Data Flow Control, DFC) oder Sitzungssteuerungsanforderungsnachrichten an den Host zu senden. Stattdessen müssen Statussteuerungsmeldungen verwendet werden. (Ausführliche Informationen finden Sie unter Status-Control Nachricht.)
Für alle Verbindungen muss die Anwendung bestimmte Schlüsselfelder im Header der Datennachricht ausfüllen. Insbesondere muss sie:
Legen Sie den Nachrichtentyp auf DATAFMI fest.
Weisen Sie einen neuen Nachrichtenschlüssel für eingehende Datennachrichten für diese Verbindung zu.
Legen Sie das ACKRQD-Feld bei Bedarf fest.
Legen Sie die Anwendungskennzeichnungen fest. (Weitere Informationen finden Sie unter Anwendungskennzeichnungen.)
Die Felder "nxtqptr", "hdreptr " und " numelts " im Nachrichtenkopf sowie die Felder "elteptr " und " startd " in den Nachrichtenelementen werden von den Host Integration Server-Pufferverwaltungsroutinen 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 (z. B. wenn die Betriebssystemumgebung keine Intertaskprozeduraufrufe und freigegebenen Speicher unterstützt), müssen alle Felder im Header von der Anwendung festgelegt werden.
Die Indikatoren für Übertragungskopf (TH) und Antwortkopf (RH) stehen der Anwendung für eingehende Datennachrichten nicht zur Verfügung. Die Anwendung sollte die entsprechenden Anwendungskennzeichnungen im Nachrichtenkopf festlegen, um die Verkettung, Richtung usw. zu steuern. Für eine Beschreibung der verfügbaren Anwendungskennzeichnungen für eingehende Daten und Informationen darüber, wie die Flags zur Steuerung von eingehenden Datenflüssen verwendet werden, sowie für spätere Themen in diesem Abschnitt, siehe Anwendungskennzeichnungen.
Bei eingehenden Daten ist das erste Byte RU[0] für die Standardfunktionsverwaltungsschnittstelle (Standard Function Management Interface, FMI).
Der von der Anwendung im eingehenden Daten-Nachrichtenkopf bereitgestellte Nachrichtenschlüssel wird vom lokalen Knoten verwendet, um anzugeben, auf welche Datenmeldung in dieser Verbindung eine ausgehende Status-Acknowledge-Bestätigung verweist. Die Anwendung sollte eine eindeutige Nachrichtenschlüsselsequenz für den eingehenden Datenfluss für jede Verbindung beibehalten, die sie mit dem lokalen Knoten hat, damit die Anwendung den Nachrichtenschlüssel verwenden kann, um eingehende Datennachrichten und ausgehende Status-Bestätigen-Nachrichten in der Verbindung zu korrelieren. Es ist zu beachten, dass die Anwendung auch einen Nachrichtenschlüssel für Status-Kontrollanforderung-Nachrichten bereitstellen sollte, um zwischen mehreren RQE LUSTAT-Nachrichten zu unterscheiden.
Das Bestätigungsprotokoll für eingehende Daten spiegelt das sekundäre Kettenantwortprotokoll und den Anforderungsmodus wider, der in der Sitzung verwendet wird, wie folgt:
Eingehende Datennachrichten mit ACKRQD-Satz im Header generieren RQD-Anforderungen .
Eingehende Datennachrichten ohne ACKRQD-Satz im Header generieren RQE- oder RQN-Anforderungen abhängig vom Kettenantwortprotokoll.
Die Anwendung sollte nur ACKRQD für Datenmeldungen festlegen, für die das ECI-Anwendungsflag (End Chain Indicator) festgelegt ist.
Wenn die Sitzung angibt, dass der sekundäre Modus den sofortigen Anforderungsmodus verwendet, kann die Anwendung weiterhin Daten senden, nachdem sie Daten mit ACKRQD gesetzt gesendet hat, obwohl sie keine Status-Bestätigungsnachricht für diese Daten erhalten hat. Die Nachrichten werden innerhalb des lokalen Knotens in die Warteschlange gestellt und werden schrittweise gesendet, wenn positive Antworten empfangen werden.
Wenn die Sitzung angibt, dass die sekundäre Option verzögerten Anforderungsmodus verwendet, nachdem eine Datennachricht mit ACKRQD-Satz gesendet wurde, kann die Anwendung weiterhin Datennachrichten senden.
Wenn die Anwendung das ACKRQD-Feld im Nachrichtenkopf einer Datennachricht festlegt, gibt sie an, dass eine Bestätigung für diese Datennachricht erforderlich ist. Der lokale Knoten erkennt eine eingehende Datennachricht an, indem eine Status-Bestätigen-Nachricht an die Anwendung in derselben Verbindung gesendet und derselbe Nachrichtenschlüssel wie die Datennachricht verwendet wird. (Eine Abbildung finden Sie in der ersten Abbildung am Ende dieses Themas.)
Der lokale Knoten verarbeitet eingehende Datennachrichten von der Anwendung über seine internen Zustandscomputer, weist die richtige SNA-Sequenznummer oder einen Bezeichner für diesen Fluss zu und sendet die Daten in einer Anforderung an den Host. Der Kettenantworttyp der Anforderung hängt davon ab, ob ACKRQD in der Datennachricht und den Sitzungsparametern festgelegt wurde.
Der lokale Knoten ordnet einer positiven Antwort vom Host ein Status-Acknowledge(Ack) zu, das an die Anwendung gesandt wird. Die Anwendung kann den Nachrichtenschlüssel in der Status-Bestätigung verwenden, um die Bestätigung mit der ursprünglichen Datennachricht zu korrelieren. Daher bedeutet der Empfang einer Status-Acknowledge (Ack) für eine bestimmte Datennachricht, dass der lokale Knoten eine positive SNA-Antwort vom Host auf die eingehende SNA-Anforderung erhalten hat. (Eine Abbildung finden Sie in der zweiten Abbildung am Ende dieses Themas.)
Beachten Sie, dass Antworten in der SSCP-PU-Sitzung erfasst werden.
Beachten Sie, dass ausgehende Status-Acknowledge(Ack)- Nachrichten Anwendungskennzeichen und eine Sequenznummer enthalten. Die Anwendungskennzeichnungen 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 (TS-Profil) 4 verwenden, um die sekundäre SNA-Sequenznummer zu verfolgen, die einer Arbeitseinheit entspricht.
Der lokale Knoten ordnet der Anwendung eine negative Antwort vom Host einer Status-Acknowledge(Nack-1) -Nachricht zu. Die Anwendung kann den Nachrichtenschlüssel in der Status-Bestätigung verwenden, um die negative Bestätigung mit der ursprünglichen Datennachricht zu korrelieren. Die ausgehende Status-Acknowledge(Nack-1)-Nachricht enthält die SNA-Sense-Codes und die Sequenznummer aus der negativen Antwort. (Eine Abbildung finden Sie in den dritten und vierten Zahlen am Ende dieses Themas.)
Wenn der lokale Knoten einen Fehler im Format einer eingehenden Datennachricht erkennt oder die Datennachricht nicht für den aktuellen Zustand der Sitzung geeignet ist, sendet er eine Status-Acknowledge(Nack-2) an die Anwendung, die einen Fehlercode enthält. (Eine Liste der Fehlercodes finden Sie unter Fehler- und Sense-Codes.) Der lokale Knoten sendet keine Anforderung an den Host, der der Fehlermeldung "Daten " entspricht, und setzt die SNA-Sequenznummer für die Sitzung nicht voraus. Die Anwendung kann einen beliebigen Nachrichtenschlüssel in der nächsten eingehenden Datennachricht verwenden (vorausgesetzt, der Fehler verursacht keinen kritischen Fehler).
Ein Beispiel für einen schwerwiegenden Verkettungsfehler, bei dem die Anwendung eine Datennachricht mit ACKRQD , aber ohne ECI in den Anwendungskennzeichnungen sendet, wird in der letzten Abbildung am Ende dieses Themas gezeigt. Beachten Sie, dass der lokale Knoten nach dem Erkennen dieses bestimmten Fehlers die Verbindung der Anwendung als kritisch fehlerhaft markiert, die Verbindung schließt und eine TERM-SELF-Anforderung an den SSCP sendet, um eine UNBIND anzufordern. (Weitere Informationen finden Sie unter "Wiederherstellung".)
Eingehende Statussteuerungsnachrichten , die die Generierung beschleunigter Flussanforderungen verursachen, können jederzeit gesendet werden und wirken sich nicht auf das Senden einer positiven oder negativen Bestätigung an eingehende Datennachrichten aus. Ausführliche Informationen dazu, welche Statussteuerungsmeldungen den SNA-Anforderungen für schnellen Fluss entsprechen, finden Sie unter Statussteuerungsnachricht.
Die folgenden fünf Abbildungen veranschaulichen Beispiele für eingehende Datenbestätigungsprotokolle (und die zugrunde liegenden SNA-Protokolle) für verschiedene Kettenantworttypen und sekundäre Sitzungsanforderungsmodi.
Die Zahlen zeigen:
Das ACKRQD-Feld in Datennachrichten.
Der Nachrichtenschlüssel für Datennachrichten .
Alle relevanten Anwendungskennzeichnungen für Datennachrichten .
Fehlercodes (angezeigt als "ERROR=...") bei Datenmeldungen.
Relevante RH-Kennzeichnungen für SNA-Anforderungen/Antworten.
Sequenznummern für SNA-Anforderungen/-Antworten.
Sense-Codes (angezeigt als "SENSE=....") bei SNA-Anfragen/-Antworten.
Aus Gründen der Einfachheit wird davon ausgegangen, dass alle Nachrichten in derselben PLU-Sitzung fließen.
In der folgenden Abbildung sendet die Anwendung erfolgreich eine Datennachricht .
Die Anwendung sendet erfolgreich eine Datennachricht.In der folgenden Abbildung sendet die Anwendung erfolgreich eine Kette von Datennachrichten .
Die Anwendung sendet erfolgreich eine Kette von Datennachrichten.In der folgenden Abbildung lehnt der Host eine Kette von Datennachrichten ab.
Host lehnt eine Kette von Datennachrichten abIn der folgenden Abbildung lehnt der Host die erste definitive Antwortkette ab und lehnt die dritte Ausnahmeantwortkette für eine verzögerte Anforderungssitzung ab. Beachten Sie, dass die negative Reaktion auf die dritte Kette eine positive Reaktion auf die zweite Kette impliziert.
Host lehnt die erste eindeutige Antwortkette ab.In der folgenden Abbildung erkennt der lokale Knoten die ungültige Verwendung von ACKRQD ohne die ECI-Anwendungskennzeichnung in einer Daten-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 ACKRDQ ohne das ECI-Anwendungsflagge bei einer Datennachricht.