Con-nect SNADS besteht aus Datenstrukturen in der Con-nect-Spooldatei und aus Programmen, die SNADS-Funktionen implementieren und die Schnittstelle zwischen SNADS und der Sendefunktion von Con-nect liefern. Dieser Abschnitt gibt Ihnen einen Überblick über die Implementierung von Con-nect SNADS.
Dieses Dokument behandelt die folgenden Themen:
Con-nect SNADS ist einer (von möglicherweise mehreren) externen Knotentypen, die eine Con-nect-Spooldatei gemeinsam nutzen. Eine einzelne Spooldatei oder ein externes Con-nect-Knotensystem kann mehrere Con-nect-Systeme bedienen. Jedes Con-nect-System kann sich wie mehrere SNADS-DSUs verhalten.
Das folgende Diagramm zeigt eine mögliche Konfiguration zur Veranschaulichung dieser Beziehungen.
Con-nect SNADS verwaltet drei Typen von Warteschlangen (Queues), in denen SNADS-DIUs zwischen den einzelnen Verarbeitungsphasen gespeichert werden.
Diese Warteschlange wird erstellt, wenn Con-nect SNADS mit einem System initialisiert wird, das EntireX Broker Services (LU6.2 API) der Software AG benutzt.
Es gibt nur eine Dummy Queue. Sie dient dazu, den Dämon-Prozess zu überwachen. Der Dämon-Prozess wartet ständig auf Konversationsanforderungen der benachbarten SNADS-Knoten und führt das Programm DS_RECEIVE aus, sobald er eine Anforderung erhält.
Warteschlange für eingehende DIUs.
Die Inbound Queue wird erstellt, wenn Con-nect SNADS initialisiert wird. Es gibt nur eine Inbound Queue. Alle SNADS-DIUs, die von anderen Knoten empfangen oder von lokalen Con-nect-Teilnehmern versendet werden, werden in die Inbound Queue gestellt. Dort verbleiben sie bis zur späteren Verarbeitung durch den DS_ROUTER_DIRECTOR. Dieser leitet die DIUs entweder an lokale Con-nect-Teilnehmer oder an die entsprechende Outbound Queue weiter.
Warteschlange für ausgehende DIUs.
Die Outbound Queues werden vom Administrator beim Konfigurieren von Con-nect SNADS erstellt. Die Anzahl der Outbound Queues hängt von der Konfiguration des jeweiligen SNADS-Netzwerkes ab. Für jeden Nachbarknoten im SNADS-Netzwerk, mit dem (oder über den) Con-nect SNADS kommuniziert, muss mindestens eine Outbound Queue erstellt werden.
SNADS-DIUs, die mit Con-nect SNADS versendet oder an andere Knoten weitergeleitet werden, werden in die entsprechenden Outbound Queues gestellt. Dort verbleiben sie, bis sie mittels DS_SEND an den jeweiligen Nachbarknoten weitergeleitet werden.
SNADS-DIUs werden in den Warteschlangen verarbeitet, die im vorhergehenden Abschnitt beschrieben wurden. Die DIUs werden von Queue Servern und anderen Server-Prozessen verarbeitet.
Die Queue Server von Con-nect SNADS heißen DS_ROUTER_DIRECTOR und DS_SEND.
DS_RECEIVE ist ein weiterer Server-Prozess, der jedoch die zu bearbeitenden DIUs nicht einer Warteschlange entnimmt, sondern sie vom DS_SEND-Prozess eines benachbarten SNADS-Knotens übernimmt. Dies geschieht im Rahmen einer APPC-Konversation auf Basis des SNA-Protokolls LU6.2
In jeder der drei möglichen SNADS-Umgebungen funktionieren die Server-Prozesse anders. Daher finden Sie anschließend drei verschiedene Beschreibungen:
- DS_RECEIVE (Ausführung wird vom benachbarten Knoten angestoßen)
Dieses Programm verarbeitet die von einem Nachbarknoten hereinkommenden DIUs und stellt sie in die Inbound Queue. Ein Dämon-Prozess von Con-nect SNADS wartet ständig auf Konversationsanforderungen der benachbarten SNADS-Knoten und führt DS_RECEIVE als internes Unterprogramm aus, sobald er eine Anforderung erhält.
Der Dämon-Prozess selbst läuft als "Attached Task" in der Com-plete-Umgebung und benutzt zum Zweck der Prozesssteuerung eine eigene Warteschlange, die Dummy Queue.
Die Startroutine von Con-nect SNADS, CPSEND, veranlasst die Ausführung der entsprechenden Programme in Natural.
- DS_ROUTER_DIRECTOR (Ausführung wird lokal angestoßen)
Wenn sich der Empfänger einer DIU auf einem anderen SNADS-Knoten befindet, leitet die "Router"-Komponente dieses Programms die DIU von der Inbound Queue an die entsprechende Outbound Queue weiter.
Wenn der Empfänger einer DIU ein lokaler Con-nect-Teilnehmer ist, leitet die "Director"-Komponente dieses Programms die DIU von der Inbound Queue an die entsprechende Multi-node-Routine weiter. Diese Routine stellt die DIU in das Posteingangsfach des Empfängers.
Con-nect SNADS ruft DS_ROUTER_DIRECTOR mit der Com-plete-Funktion ATTACH auf. Die Startroutine von Con-nect SNADS, CPSEND, veranlasst die Ausführung der entsprechenden Programme in Natural.
- DS_SEND (Ausführung wird lokal angestoßen)
Dieses Programm leitet die DIUs aus einer Outbound Queue an das Programm DS_RECEIVE des entsprechenden Nachbarknotens weiter.
Con-nect SNADS ruft DS_SEND mit der Com-plete-Funktion ATTACH auf. Die Startroutine von Con-nect SNADS, CPSEND, veranlasst die Ausführung der entsprechenden Programme in Natural.
- DS_RECEIVE
Dieses Programm verarbeitet die von einem Nachbarknoten hereinkommenden DIUs und stellt sie in die Inbound Queue. Ein Dämon-Prozess von Con-nect SNADS wartet ständig auf Konversationsanforderungen von benachbarten SNADS-Knoten und führt DS_RECEIVE als internes Unterprogramm aus, sobald er eine Anforderung erhält.
Der Dämon-Prozess selbst läuft im Batch-Betrieb und belegt exklusiv einen ständig aktiven Natural-Prozess, den so genannten "Input Handler". Zur Prozesssteuerung benutzt er eine eigene Warteschlange, die Dummy Queue.
- DS_ROUTER_DIRECTOR
Wenn sich der Empfänger einer DIU auf einem anderen SNADS-Knoten befindet, leitet die "Router"-Komponente dieses Programms die DIU von der Inbound Queue an die entsprechende Outbound Queue weiter.
Wenn der Empfänger einer DIU ein lokaler Con-nect-Teilnehmer ist, leitet die "Director"-Komponente dieses Programms die DIU von der Inbound Queue an die entsprechende Multi-node-Routine weiter. Diese Routine stellt die DIU in das Posteingangsfach des Empfängers.
Con-nect SNADS führt DS_ROUTER_DIRECTOR in einem ständig aktiven Natural-Prozess, dem so genannten "Queue Server", aus. DS_ROUTER_DIRECTOR kann diesen Batch-Prozess gemeinsam mit dem Programm DS_SEND einer oder mehrerer Outbound Queues benutzen, jedoch nicht mit dem Dämon-Prozess.
- DS_SEND
Dieses Programm leitet die DIUs aus einer Outbound Queue an das Programm DS_RECEIVE des entsprechenden Nachbarknotens weiter.
Con-nect SNADS führt DS_SEND in einem ständig aktiven Natural-Prozess, dem so genannten "Queue Server", aus. DS_SEND kann diesen Batch-Prozess gemeinsam mit dem Programm DS_ROUTER_DIRECTOR einer oder mehrerer Outbound Queues benutzen, jedoch nicht mit dem Dämon-Prozess.
- DS_RECEIVE (Ausführung wird vom benachbarten Knoten angestoßen)
Dieses Programm verarbeitet die von einem Nachbarknoten hereinkommenden DIUs und stellt sie in die Inbound Queue. Bei einer Konversationsanforderung von einem Nachbarknoten ruft CICS das Programm DS_RECEIVE auf. Die Startroutine von Con-nect SNADS, CSRECV, veranlasst die Ausführung der entsprechenden Programme in Natural.
- DS_ROUTER_DIRECTOR (Ausführung wird lokal angestoßen)
Wenn sich der Empfänger einer DIU auf einem anderen SNADS-Knoten befindet, leitet die "Router"-Komponente dieses Programms die DIU von der Inbound Queue an die entsprechende Outbound Queue weiter.
Wenn der Empfänger einer DIU ein lokaler Con-nect-Teilnehmer ist, leitet die "Director"-Komponente dieses Programms die DIU von der Inbound Queue an die entsprechende Multi-node-Routine weiter. Diese Routine stellt die DIU in das Posteingangsfach des Empfängers.
Con-nect SNADS ruft das Programm DS_ROUTER_DIRECTOR mit dem CICS-Kommando START auf. Die Startroutine von Con-nect SNADS, CSSEND, veranlasst die Ausführung der entsprechenden Programme in Natural.
- DS_SEND (Ausführung wird lokal angestoßen)
Dieses Programm leitet die DIUs aus einer Outbound Queue an das Programm DS_RECEIVE des entsprechenden Nachbarknotens weiter.
Con-nect SNADS ruft DS_SEND mit dem CICS-Kommando START auf. Die Startroutine von Con-nect SNADS, CSSEND, veranlasst die Ausführung der entsprechenden Programme in Natural.
Bestimmte Informationen über das SNADS-Netzwerk müssen Con-nect in Form einer "Routing-Tabelle" zur Verfügung stehen. Die Routing-Tabelle befindet sich in der Con-nect-Spooldatei.
Die Routing-Tabelle enthält Zuordnungsinformationen, mit deren Hilfe der DS_ROUTER_DIRECTOR bestimmt, an welchen Nachbarknoten eine DIU weitergeleitet werden muss (d.h. in welche der Con-nect SNADS-Warteschlangen die DIU gestellt werden muss). Falls kein entsprechender Knoten existiert, kann der DS_ROUTER_DIRECTOR eine weitere SNADS-DIU erstellen, um den DIU-Absender über den Zuordnungsfehler zu informieren. Dies ist von den Rückmeldeoptionen abhängig, die für die DIU angegeben wurden.
Das folgende Diagramm zeigt die Beziehung der Warteschlangen, Routing-Einträge und Queue Server:
Die Queue Server können folgendermaßen gestartet werden:
- Ereignisgesteuert
Der Server wird gestartet, sobald eine Nachricht in der Warteschlange ankommt.
- Intervallgesteuert
Der Server wird in den vom Administrator festgelegten Intervallen gestartet.
Die Queue Server werden über den Status einer Warteschlange gesteuert (siehe unten). Der Con-nect SNADS-Administrator ist dafür verantwortlich, dass der richtige Mechanismus für die Queue Server definiert und aktiviert wurde. Welcher Mechanismus jeweils anzuwenden ist, hängt vom Ausgabe-Status (oder Reset-Status) der jeweiligen Warteschlange ab.
Anmerkung:
In einer EntireX Broker Services (LU6.2 API)-Batch-Konfiguration kann
Con-nect SNADS keine Prozesssteuerung durchführen.
Zur Überwachung des Systems sollte der Con-nect SNADS-Administrator den Status der Warteschlangen sowie die Anzahl der Einträge in den Warteschlangen und deren Zeitstempel gelegentlich überprüfen.