DE68919976T2

DE68919976T2 - Verfahren zur Herstellung von aktuellen Terminaladressen für Systemanwender die verteilte Anwendungsprogramme in einer SNA LU 6.2-Netzwerkumbegung verarbeiten.

Info

Publication number: DE68919976T2
Application number: DE68919976T
Authority: DE
Inventors: David Uel Shorter
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1988-09-30
Filing date: 1989-08-01
Publication date: 1995-07-13
Anticipated expiration: 2009-08-02
Also published as: DE68919976D1; JPH02116955A; US4991089A; EP0362108A3; USRE35448E; EP0362108B1; EP0362108A2; BR8904955A

Description

Gebiet der Erfindung:

Diese Erfindung bezieht sich im allgemeinen auf LU-6.2-Methoden zur Interprogrammkommunikation in SNA-Datenverarbeitungsnetzwerken, bei denen Datenstationen im System nicht von vornherein bestimmten Endanwendern zugewiesen sind, und insbesondere auf ein Verfahren, mit dem ein Endanwender eine aktuelle Datenstationsadresse herstellen kann, die lediglich solange gültig ist, wie die Datenstation aktiv ist, oder bis sie vom Endanwender wieder aufgehoben wird.

Allgemeiner Stand der Technik:

Der Stand der Technik offenbart eine Vielzahl von Computernetzwerken. Das IBM System Journal, Band 22, Nummer 4, 1983 enthält eine Reihe von Artikeln, die sich mit einer Besprechung der IBM Systemnetzwerkarchitektur SNA befassen. Auf Seite 345 dieser Publikation wird ein Netzwerk als "eine Konfiguration von Datenstationen, Steuereinheiten und Prozessoren sowie Verbindungen, die sie miteinander verbinden beschrieben. Wenn eine solche Konfiguration Benutzeranwendungen unterstützt, die Datenverarbeitung und Datenaustausch umfassen, und wenn sie den Spezifikationen der System Network Architecture entspricht, wird sie als SNA-Netzwerk bezeichnet. SNA definiert prinzipiell logische Netzeinheiten, die mit den physischen Netzeinheiten in einem Netzwerk in Verbindung stehen, und legt die Regeln für Interaktionen zwischen diesen logischen Netzeinheiten fest.
Die logischen Netzeinheiten eines SNA-Netzwerkes umfassen adressierbare Netzeinheiten und das Pfadsteuerungsnetz, das sie verbindet. Die Datenübertragung zwischen den verschiedenen adressierbaren Netzeinheiten erfolgt über logische Verbindungen, die als "Sitzungen" bezeichnet werden. Die drei Arten von adressierbaren Netzeinheiten (Network Addressable Units, NAUs) sind die Logische Netzeinheit (Logical Unit, LU), die Physische Netzeinheit (Physical Unit, PU) und der Steuerpunkt für Systemdienste (System Services Control Point, SSCP); sie werden folgendermaßen definiert:
Logische Netzeinheit (LU). Eine LU ist ein Anschluß, über den Endanwender Zugriff auf ein SNA-Netzwerk haben. Ein Endanwender verwendet eine LU für die Datenübertragung mit einem anderen Endanwender und zur Anforderung von Diensten von einem Steuerpunkt für Systemdienste (SSCP).
Physische Netzeinheit (PU). Eine PU ist eine Komponente, die zusammen mit einem SCCP die Ressourcen eines Knotens verwaltet.
Steuerpunkt für Systemdienste (SSCP). Hierbei handelt es sich um einen zentralen Punkt für die Konfigurationsverwaltung, die Fehlerbestimmung und Verzeichnisdienste für Endanwender. SSCPs können Sitzungen mit LUs und PUs haben. Im Falle einer solchen Sitzung befindet sich die LU oder PU in der Domäne des SSCPs. Zusätzlich zu Sitzungen mit LUs und PUs können SSCPs auch untereinander Daten übertragen, um Beginn und Ende von Sitzungen zwischen Logischen Netzeinheiten und in verschiedenen Domänen zu koordinieren.
Im Hinblick auf die Hardware umfaßt ein einfaches Netzwerk ein Host-System mit einer Verarbeitungseinheit und eine Mehrzahl von fernen Datenstationen, die einzelnen Anwendern zugewiesen sind. Die fernen Datenstationen können selektiv über eine oder mehrere Kommunikationsverbindungen mit dem Host-System verbunden werden. Diese Verbindungen können aus lediglich einem Koaxialkabel, einer dedizierten Telefonleitung oder, in manchen Fällen, aus einer Satellitenübertragungsleitung bestehen.
Die Host-Verarbeitungseinheit beinhaltet beinahe immer ein Betriebssystem, das die Erzeugung einer großen Anzahl von virtuellen Maschinen oder deren funktionaler Entsprechungen unterstützt, von denen eine jede auf Anforderung einem Endanwender zugewiesen wird. Eine virtuelle Maschine verarbeitet durch gleichzeitige Nutzung der Host-Hardware des Host-Systems Rechenprozesse für den zugewiesenen Endanwender. Einige Host-Systeme können mehrere Hardwareprozessoren umfassen, so daß beim Host- System eine echte Simultanverarbeitung stattfindet, da eine Mehrzahl von Prozessoren parallel arbeitet. Häufiger gibt es jedoch lediglich einen Hardwareprozessor, der mit einem Time Sharing-Verfahren "gleichzeitig" Datenverarbeitungsprozesse für die virtuellen Maschinen ausführt. Dieser Vorgang ist für die Endanwender an den Datenstationen transparent.
Bei Netzwerksystemen nach dem Stand der Technik wird einem Anwender des Systemes vom Systemadministrator eine USERID (Anwenderkennung) zugewiesen, wenn der Anwender zum ersten Mal die Berechtigung für die Benutzung des Systems erhält. Dem Anwender wird zu diesem Zeitpunkt außerdem ein Kennwort zugewiesen, das jedesmal in das System eingegeben werden muß, wenn sich der Anwender in dem System anmeldet. Der Systemadministrator hat die USERID und das Kennwort des Anwenders in das System eingegeben. Wenn die beim Anmelden eingegebenen Informationen nicht mit den Informationen übereinstimmen, die vom Administrator in das System eingegeben wurden, erhält der Anwender keinen Zugriff auf das System. Sind die Informationen korrekt, gestattet das System den Zugriff. Als Teil des Anmeldevorganges wird dem Anwender solange die exklusive Nutzung einer virtuellen Maschine zugewiesen, bis ein Abmeldevorgang abgeschlossen wurde. Der Name, der der zugewiesenen virtuellen Maschine zugeordnet wird, ist die USERID des jeweiligen Anwenders, der sich anmeldet. Die Systemadresse der Datenstation, der vom Anwender für die Anmeldung verwendet wird, wird ebenfalls an die zugewiesene virtuelle Maschine übertragen und als Teil des Anmeldevorganges gespeichert. Für etwaige spätere Datenübertragungen, die der Anwender beabsichtigt, ist nur die USERID des Anwenders als Teil der Nachrichtenadresse erforderlich. Die Nachricht wird an die zugewiesene virtuelle Maschine übertragen, von dieser verarbeitet und an den Anwender an der Datenstationsadresse gesendet, die von der dedizierten virtuellen Maschine zum Zeitpunkt der Anmeldung gespeichert wurde.
Mit dieser Methode, bei der die USERID eines Anwenders derjenigen virtuellen Maschine als Name zugeordnet wird, die diesem Anwender zugewiesen wurde, und bei dem die aktuelle Datenstationsadresse des Anwenders in der zugewiesenen virtuellen Maschine gespeichert wird, kann das Problem der Adressenübersetzung vermieden werden, bei dem die USERIDs in Datenstationsadressen übersetzt werden müssen, um eine Nachricht an eine bestimmte USERID senden zu können. Bei diesem herkömmlichen Ansatz benötigt das System nur die USERID des beabsichtigten Empfängers, um eine Nachricht senden zu können. Wenn eine Nachricht für einen Anwender empfangen wird, wird sie gespeichert, und es wird überprüft, ob die Nachricht sofort weitergegeben werden kann. Wenn der Anwender zu dem Zeitpunkt, an dem das System die Nachricht empfängt, online ist, zeigt das System den Empfang an, nachdem es eine verhältnismäßig kurze Liste mit virtuellen Maschinen durchsucht hat, die beim Anmelden bestimmten Anwendern zugewiesen wurden; anschließend führt das System die entsprechenden Schritte zur Weitergabe der Nachricht aus, indem eine dedizierte virtuelle Maschine mit dem Namen USERID veranlaßt wird, die Nachricht an die aktuelle Datenstationsadresse des Anwenders zu übertragen, die von dieser dedizierten virtuellen Maschine gespeichert wird. Andernfalls überprüft das System als Teil des Anmeldevorganges die Liste der nicht übertragbaren Nachrichten auf Nachrichten, die an den Anwender adressiert sind, und informiert den neu angemeldeten Anwender davon, daß in seinem System eine Nachricht gespeichert ist und abgerufen werden kann.
In Datenverarbeitungsnetzwerken werden prinzipiell zwei Arten von Datenstationen verwendet. Die erste wird als "nichtintelligente Datenstation" bezeichnet, da sie lediglich eine Tastatur und eine Anzeigevorrichtung hat und wenig oder keine Datenverarbeitungsfunktionen aufweist, die über diejenigen hinausgehen, die für eine Herstellung einer Verbindung mit dem Host-System erforderlich sind. Die zweite Art von Datenstationen wird als Intelligente Benutzerstation (Intelligent Work Station, IWS) bezeichnet und verfügt über eine eigene Prozessoreinheit, ein Betriebssystem und unterstützende Peripheriegeräte. Die Begriffe IWS und Personal Computer (PC) werden häufig synomyn verwendet. Aufgrund der problemlosen Verfügbarkeit von PCs mit sehr günstigem Kosten/Nutzen-Verhältnis werden die meisten neuen Netzwerke mit IWS-Datenstationen implementiert und viele ältere Netzwerke modifiziert, wobei nichtintelligente Datenstationen durch Damenstationen vom Typ IWS ersetzt werden.
Indem jeder Endanwender im Netzwerk über eigene Verarbeitungsfähigkeiten verfügt, wird die Zentraleinheit des Host-Systems von vielen der Datenverarbeitungstasks entlastet, die bis dahin Vom Host-System durchgeführt wurden. Die Art der Tasks, die von der zentralen Verarbeitungseinheit des Host-Systems verarbeitet werden, hat sich daher geändert, und es werden nun komplexere Anwendungen wie elektronische Post und elektronische Terminkalenderführung im Netzwerk unter der Steuerung des Host-Systems durchgeführt. Die beiden aufgeführten Anwendungen erfordern sogenannte verteilte Anwendungsprogramme, bei denen ein Teil des Programms im Host-System und der andere Teil in der IWS-Datenstation resident ist.
Viele der aktuellen Datenverarbeitungsnetzwerke wurden in Übereinstimmung mit der SNA-Architektur von IBM konzipiert, die zuerst 1974 beschrieben wurde. Seit damals wurden verschiedene neue Funktionen und Dienste hinzugefügt. Wie bereits oben erwähnt, können SNA-Netzwerke als eine Mehrzahl von Knoten betrachtet werden, die über Kommunikationsverbindungen miteinander verbunden sind. An jedem dieser Knoten senden Pfadsteuerungselemente zwischen den für die Ressourcenverwaltung zuständigen Logischen Einheiten Informationspakete, die als Pfadinformationseinheiten (Path Information Unit, PIU) bezeichnet werden. Die logischen Verbindungen dieser Pfade werden als Sitzungen bezeichnet. Ein Datenübertragungsnetzwerk ist daher durch die Pfadsteuerungselemente und die Elemente für die Kommunikationsverbindungen definiert.
Knoten können mit einer Mehrzahl von Verbindungen miteinander verbunden werden und umfassen eine Mehrzahl von LUs. Im Rahmen der SNA-Architektur wurden verschiedene Arten von LU-Sitzungen und -Protokollen erstellt. Es gibt prinzipiell drei Klassen von Sitzungen. Die erste Klasse wird von der SNA-Architektur nicht spezifiziert. Die zweite Klasse umfaßt Datenstationen, und die dritte Klasse beinhaltet die Datenübertragung zwischen Programmen. So stellt LU 6 z.B. SNA-definierte Protokolle für die Datenübertragung zwischen Programmen zur Verfügung, die die Beschränkungen von Datenstations-LU-Arten wie LU 2 und LU 7 vermeiden. LU-6.2-Protokolle werden als Erweiterte Protokolle für die Programm-zu-Programm-Datenübertragung oder als APPC-Protokolle bezeichnet.
Logische Einheiten sind mehr als bloße Nachrichtenanschlüsse. Sie stellen Betriebssystemdienste wie die Datenübertragung zwischen Programmen bereit, bei denen ein oder mehrere lokale Programme beteiligt sind. Jedes Anwendungsprogramm interpretiert die LUs als ein lokales Betriebssystem und das Netzwerk von locker verknüpften LUs, die durch Sitzungen miteinander verbunden sind, als ein verteiltes Betriebssystem.
Die LU weist, abhängig von der jeweiligen Hardware und deren Konfiguration, ihren Programmen eine Mehrzahl von Ressourcen zu. Manche der zur Verfügung gestellten Ressourcen sind entfernte Ressourcen, andere sind lokal, d.h. sie sind derselben LU zugewiesen wie das Anwendungsprogramm. Die Sitzungen werden bei jeder LU als lokale Ressourcen interpretiert, sie werden jedoch von verschiedenen LUs gemeinsam genutzt.
Die Steuerfunktion einer LU besteht in der Ressourcenzuordnung. Programme fordern Zuordnungen für den Zugriff auf eine Ressource an. Sitzungen, die Nachrichten zwischen LUs übertragen oder Programme, die auf LUs laufen, werden als gemeinsam benutzte Ressourcen interpretiert. Eine Sitzung wird aufgeteilt, so daß eine Mehrzahl von Datenübertragungen seriell durchgeführt werden kann.
Zwei durch eine Sitzung verbundene LUs sind gemeinsam für die Zuordnung von Sitzungen an Anwendungsprogramme zuständig, die als "Dialoge" verwendet werden sollen. Die Anwendungsprogramme werden daher mitunter auch als "Transaktionsprogramme" bezeichnet.
Die erfolgreiche Verbindung von LUs ist das Ergebnis eines gemeinsamen Satzes von Protokollen, die erstens eine Sitzung zwischen zwei LUs aktivieren und zweitens den Austausch der Nachrichtendaten erleichtern.
Das von der IBM Corporation veröffentlichte Referenzhandbuch SC30-3112 zum SNA-Format und -Protokoll beschreibt die SNA, indem in Form von Programmiersprachenanweisungen z.B. das Format von Nachrichten, die zwischen Netzwerkeinheiten übertragen werden, und die Programme, die Nachrichten erzeugen, modifizieren, übersetzen, senden und rückübertragen, erläutert werden.
Das von der IBM Corporation veröffentlichte Referenzhandbuch GC30-3084 für LU 6.2 zum SNA-Transaktionsprogramm legt die Verben fest, die durch die ausführenden Programme zur Verfügung gestellt werden.
Intelligente Benutzerstationen, die mit einem SNA-Netzwerk verbunden sind und ein LU-6.2-Protokoll zur Verarbeitung eines Anwendungsprogrammes verwenden, das auf die IWS und das Host-System verteilt ist, arbeiten effizient, solange das Betriebssystem der IWS nicht mehrere Anwendungen gleichzeitig auf der Datenstation ausführt. Läuft die IWS jedoch unter einem Betriebssystem wie OS/2, mit dem eine IWS wie z.B. ein IBM PS/2 Personal Computer gleichzeitig verteilte Anwendungsprogramme ausführen kann, geht der Vorteil der gleichzeitigen Ausführung mehrerer Anwendungen auf dem PS/2 verloren. Dies ist der Fall, da die einzelnen Transaktionen, die gleichzeitig auf der Datenstation ausgeführt werden, serialisiert werden. Diese Serialisierung der Transaktion ergibt sich, weil das Host-System nur eine einzige virtuelle Maschine erzeugt, die der Anwenderkennung und der betreffenden Datenstation permanent zugewiesen ist, solange die Sitzung dauert.
Um die Serialisierung des Host-Systems zu vermeiden, muß die zweite Anwendung, die auf der Datenstation läuft, unter einer anderen Anwenderkennung ausgeführt werden, um so auf dem Host-System eine getrennte virtuelle Maschine zu erzeugen, die ausschließlich der zweiten Anwendung zugeordnet ist.
Die in einer gleichzeitig anhängigen Patentanmeldung 89480116.6 (EP-A-0366581) beschriebene Anwendung bezieht sich auf ein Verfahren, das ermöglicht, daß zwei oder mehr verteilte Anwendungsprogramme, die auf einer intelligenten Benutzerstation eines Datenverarbeitungsnetzwerkes laufen, auf getrennten, vom Host- System erzeugten virtuellen Maschinen ausgeführt werden, um so zu vermeiden, daß die Anwendungen auf dem Host-System serialisiert werden, und um zu ermöglichen, daß die Anwendungen sowohl auf dem Host-System als auch auf der Datenstation gleichzeitig ausgeführt werden können.
Bei dem Verfahren der Patentanmeldung, auf die Bezug genommen wird, anhängigen Erfindung erzeugt das Host-System eine Mehrzahl an virtuellen Maschinen (VMs), die in einen Bereitschaftszustand gebracht werden, bevor und damit sie einem verteilten Anwendungsprogramm zugewiesen werden können, um einen Task zu verarbeiten, der in dem verteilten Anwendungsprogramm definiert wurde, wobei ein Teil des Anwendungsprogrammes im Host-System und der andere Teil in einer der IWS-Datenstationen der Endanwender resident ist. Die zur Verfügung stehenden operationsbereiten VMs werden vorzugsweise bei der Initialisierung des Host-Systems unter der Steuerung eines Poolmanagers erzeugt, wobei es sich um ein hostresidentes Programm handelt, dessen andere Hauptaufgabe darin besteht, eine der VMs im Kuhezustand als Reaktion auf eine Anforderung durch den Endanwender zuzuweisen, die ein verteiltes Anwendungsprogramm, einen Namen einer zuvor geordneten Logischen Einheit und eine USERID spezifiziert. Die VM wird nur für die Dauer zugewiesen, die für einen vollständigen LU-6.2-Dialog erforderlich ist. Nach Beendigung des Dialoges wird die VM wieder dem Pool der VMs im Ruhezustand zugeordnet und steht dann für einen weiteren, möglicherweise anderen, Endanwender eines Anwendungsprogrammes zur Verfügung. Mit diesem Verfahren können zwei gleichzeitig ausgeführte verteilte Anwendungsprogramme auch dann gleichzeitig auf dem Host-System in zwei getrennten virtuellen Maschinen laufen, wenn die Dialoganforderungen dieselbe USERID beinhalten.
Das oben beschriebene System verbessert zwar die Verarbeitung von verteilten Anwendungsprogrammen, erfordert jedoch ein neues Verfahren zur Ermittlung der aktuellen Datenstationsposition eines online befindlichen Anwenders. Wie bereits beschrieben, wurde bei herkömmlichen Verfahren die mit der USERID des aktuellen Anwenders benannte dedizierte virtuelle Maschine für die Speicherung der aktuellen Datenstationsadresse des Anwenders verwendet. Diese dedizierte Maschine konnte wirkungsvoll eliminiert und durch einen Pool an virtuellen Maschinen ersetzt werden, die weder einem einzigen Anwender noch einer einzigen Datenstationsadresse permanent zugewiesen werden. Da die virtuellen Maschinen des Pools dynamisch zugeordnet werden, um verhältnismäßig kurze Dialoge des Typs LU 6.2 zwischen dem Host-System und den Datenstationen zu verarbeiten, und anschließend wieder in den Pool der VMs zurückgestellt werden, empfiehlt es sich nicht, das herkömmliche Verfahren zur Ermittlung der aktuellen Datenstationsadresse eines aktiven Anwenders zu verwenden, bei dem eine zugewiesene virtuelle Maschine aus dem Pool die USERID des Anwenders erhält und die aktuelle Datenstationsadresse des Anwenders in dieser virtuellen Maschine gespeichert wird. Mit dem Verfahren der vorliegenden Erfindung kann die aktuelle Datenstationsadresse eines bestimmten Anwenders in einem SNA- System mit einer Anzahl von virtuellen Maschinen, die gemäß den hier erwähnten Patentanmeldungen organisiert sind, erst ermittelt werden, nachdem der Anwender der Datenstation der intelligenten Benutzerstation festgelegt hat, ob das Host-System oder andere Systemanwender mit der intelligenten Benutzerstation des Anwenders Daten austauschen können.
EP-A-0 248 403 mit dem Titel "Distributive Interactive Processing Method in Complex System Including Plural Work Stations and Plural Host Computers and Apparatus using the Same" beschreibt ein Verfahren für ein verteiltes Datenverarbeitungssystem, das dadurch gekennzeichnet ist, daß Verarbeitungsanforderungen durch den Host von den intelligenten Benutzerstationen ausgehen und von diesen analysiert werden. Danach wird eine Verbindung zwischen der betreffenden Benutzerstation und einem bestimmten Hostrechner hergestellt, wodurch sich ein geeigneter Serverprozeß zur Verarbeitung der Anforderung ergibt. Der Serverprozeß kann eine große Anzahl an ähnlichen Anforderungen verarbeiten, wobei die Serververarbeitung (ähnlich einer virtuellen Maschine) in einem eigenen Verarbeitungsraum erfolgt. Die hier beschriebene vorliegende Erfindung stellt eine vorübergehende Verknüpfung zwischen einer virtuellen Maschine in einem Host und einem bestimmten Programm und Anwender an einer bestimmten Benutzerstation her. Dies erfolgt durch die Bereitstellung einer Datenstruktur, die sich auf die Identifizierung eines Anwenders und auf die Identifizierung der Datenstation bezieht, mit dem der Anwender zu diesem Zeitpunkt eine Interaktion mit einer bestimmten virtuellen Maschine im Host durchführt. Wenn es für einen Anwender wünschenswert ist, eine beliebige Datenstation frei auszuwählen, um über das Netzwerk auf den Host zuzugreifen, läßt sich mit diesem Verfahren der Verarbeitungsaufwand durch den Host auf ein Mindestmaß reduzieren, indem die Position eines Anwenders durch einfaches Durchsuchen einer kurzen Liste von Datenblöcken ermittelt wird.

Zusammenfassung der Erfindung:

Gemäß dem Verfahren der vorliegenden Erfindung wie hier beschrieben, entscheidet ein bestimmter Anwender einer intelligenten Benutzetstation, wie z.B. einem IBM PS/2 Personal Computer auf der ein Multitasking-Betriebssystem wie das IBM OS/2 Betriebssystem ausgeführt wird, und die mit einem SNA-Netzwerk verbunden ist, das ein Hostdatenverarbeitungssystem mit LU 6.2- Protokollen zur Datenübertragung zwischen Programmen verwendet, wann das Host-System oder andere Anwender im System Nachrichten an die USERID des bestimmten Anwenders senden können, bei denen diese Protokolle verwendet werden. Das Verfahren erstellt ein verteiltes Anmeldeanwendungsprogramm im System, wobei ein Teil des Programmes in der jeweiligen IWS und der andere Teil im Host resident ist. Wenn der IWS-Anwender sich für eine Verbindung mit dem Host und den anderen Anwendern entschließt, wird das verteilte Anmeldeanwendungsprogramm auf der IWS aufgerufen. Das Anmeldeprogramm zeigt dem Anwender eine Anzeige, die zur Eingabe der USERID des Anwenders und des Kennwortes auffordert, das dem Anwender bei der Berechtigung für den Zugriff auf das System zugeteilt wurde. Die Benutzetstation gibt dann ein LU-6.2-Verb ALLOCATE heraus, das einen Dialog mit dem in ALLOCATE angegebenen Partnerprogramm anfordert. Teil B des Anmeldeprogrammes mit dem Namen "BEGIN", wird auf dem Host ausgeführt und verarbeitet den von ALLOCATE angeforderten Dialog. Das Programm BEGIN ruft ein Programm mit dem Namen VMPPMID auf, das eine Komponente des Poolmanagers für virtuelle Maschinen ist (Virtual Machine Pool Manager, VMPM). Diese Komponente erzeugt einen Identifizierungssteuerblock-Eintrag (Identification Control Block Entry, ICBE) und speichert die USERID und die Datenstationskennung mit einem Zeiger auf einen eventuell folgenden ICBE in den betreffenden Feldern. Anschließend wird durch das Partnerprogramm BEGIN ein Verb DEALLOCATE ausgegeben, der Dialog wird beendet, und eine Meldung zeigt dem Anwender einen erfolgreichen Abschluß an. Bei dem Verfahren wird außerdem die ICBE-Kette im Host gespeichert, auf die mit jedem Programm zugegriffen werden kann, das auf einer virtuellen Maschine ausgeführt wird, die zu dem Pool an virtuellen Maschinen gehört. Bei dem Verfahren muß ein verteiltes Anwendungsprogramm, das vom Host ausgeht und ein Verb ALLOCATE ausgibt, um einen Dialog mit einem bestimmten Anwender zu beginnen, zunächst die ICBE-Kette dutchsuchen, um zu ermitteln, ob der Anwender Nachrichten entgegennimmt, und, wenn dies der Fall ist, die aktuelle Systemadresse ermitteln, an die diese Nachrichten gemäß den LU-6.2-Protokollen gesendet werden sollen.
Der Anwender kann die anfänglich erteilte Erlaubnis wieder zurücknehmen, indem er das Anmeldeprogramm erneut auftuft und die Option für die Beendigung wählt. Daraufhin wird ein Verb ALLOCATE von der Datenstation ausgegeben, das einen Dialog mit einem Partneranwendungsprogramm "END" anfordert, bei dem es sich um eine weitere Programmkomponente des VMPM-Programmes handelt. ALLOCATE überträgt genügend Daten, daß die Programmkomponente END den entsprechenden ICBE in der ICBE-Kette lokalisieren und seine Löschung veranlassen kann. Das END-Programm gibt anschließend ein Verb DEALLOCATE an die Datenstation zurück, die dem Anwender in einer Meldung anzeigt, daß der Rechenprozeß zur Rücknahme der Erlaubnis erfolgreich beendet wurde.
Eine Aufgabe der vorliegenden Erfindung besteht daher darin, ein verbessertes Verfahren zur Ausführung von verteilten Anwendungen in einem Datenverarbeitungsnetzwerk zur Verfügung zu stellen.
Eine weitere Aufgabe der vorliegenden Erfindung besteht darin, ein verbessertes Verfahren für die Verarbeitung von verteilten Anwendungsprogrammen in einem SNA-Datenverarbeitungsnetzwerk bereitzustellen, in dem in den Hosts ein Pool an virtuellen Maschinen erzeugt wird.
Eine weitere Aufgabe der vorliegenden Erfindung besteht darin, ein verbessertes Verfahren für die Verarbeitung von verteilten Anwendungsprogrammen in einem SNA-Datenverarbeitungsnetzwerk mit LU-6.2-Protokollen bereitzustellen, wobei ein Endanwender den Zeitpunkt bestimmt, zu dem Nachrichten von anderen Systemanwendern, die an die USERID des Anwenders adressiert sind, an den Anwender weitergeleitet werden können.
Noch eine weitere Aufgabe der vorliegenden Erfindung besteht darin, ein verbessertes Verfahren für die Identifizierung der aktuellen Datenstationsadresse eines Endanwenders in einem SNA- Netzwerk bereitzustellen, das LU-6.2-Protokolle verwendet, und in dem der Host keine virtuelle Maschine erzeugt, die einem einzigen Anwender an einer einzigen Datenstation zugewiesen ist.
Noch eine weitere Aufgabe der vorliegenden Erfindung besteht darin, ein Verfahren für die Identifizierung der aktuellen Adresse einer intelligenten Benutzerstation bereitzustellen, die von einem bestimmten Anwender eines SNA-Netzwerkes mit LU-6.2- Protokollen bedient wird, in dem der bestimmte Anwender keine herkömmlichen Anmeldeschritte ausführen muß, um die Benutzerstation benutzen zu können.

Beschreibung der Zeichnungen:

Fig. 1 ist eine schematische Darstellung eines Datenverarbeitungsnetzwerkes.
Fig. 2 ist eine schematische Darstellung eine der IWS-Datenstationen aus Fig. 1.
Fig. 3 zeigt die Organisation der verschiedenen Programmierschichten, aus denen das SNA-Netzwerk aus Fig. 1 aufgebaut ist.
Fig. 4A und 4B zeigen das Verhältnis zwischen Teilen eines verteilten Anwendungsprogrammes und eines Netzwerkprogrammes.
Fig. 5 ist eine schematische Darstellung des Pools an operationsbereiten virtuellen Maschinen, die im Host erzeugt werden.
Fig. 6 zeigt die Einzelheiten der Datenstruktur des Pools an virtuellen Maschinen, die vom Verwaltungsprogramm für den Pool an verfügbaren virtuellen Maschinen aus Fig. 5 verwendet wird.
Fig. 7 ist ein Flußdiagramm mit den Schritten, die bei der Erzeugung des Pools an virtuellen Maschinen aus Fig. 5 durchgeführt werden.
Fig. 8 ist ein Flußdiagramm mit den Schritten, die vom VMPM gemäß dem neuen Verfahren bei der Ausführung eines verteilten Anwendungsprogrammes durchgeführt werden.
Fig. 9 ist ein Flußdiagramm mit den Schritten, die durchgeführt werden, um dem Host die aktuelle Datenstationsadresse eines Systemanwenders mitzuteilen.
Fig. 10 zeigt die Datenstruktur des Identifizierungssteuerblock- Eintrages (ICBE), die zur Speicherung der aktuellen Datenstationsadresse eines online befindlichen Systemanwenders erzeugt wird.
Fig. 11 ist ein Flußdiagramm mit den Schritten, die durchgeführt werden, wenn der Host versucht, einen LU-6.2-Dialog mit einem Systemanwender zu beginnen.
Fig. 12 ist ein Flußdiagramm mit den Schritten, die durchgeführt werden, wenn ein online befindlicher Anwender entscheidet, keinen weiteren Dialog mit dem Host herzustellen.

Beschreibung der bevorzugten Ausführungsform:

Fig. 1 zeigt ein Datenverarbeitungssystem, das ein SNA-Netzwerk 20 mit interaktiven Datenstationen oder intelligenten Benutzerstationen (IWS) 21 der in Fig. 2 abgebildeten Art umfaßt. Wie oben beschrieben, beinhaltet das Netzwerk eine Mehrzahl von Datenstationen 21, die mit einem zentralen Host-Verarbeitungssystem 23 verbunden sind. Wie in Fig. 1 dargestellt, ist das Host- System 23 wiederum über eine Datenübertragungsleitung 24 mit einem Hostverarbeitungssystem 25 verbunden, das ebenfalls mit einem anderen SNA-Netzwetk 26 der interaktiven Datenstationen 21 verbunden ist. Die Funktionsweise des Systems ist dadurch gekennzeichnet, daß sie jeder Datenstation oder jedem Endanwender die Datenübertragung mit dem Host-System oder einer oder mehreren anderen Datenstationen oder Anwendern gestattet, wobei vorhandene SNA-Datenübertragungsprotokolle verwendet werden, so daß die verschiedenen seriell miteinander verbundenen Kommunikationsverbindungen für die Anwender transparent sind.
Das Host-System umfaßt eine Host-Verarbeitungseinheit, die z.B. ein IBM 370 System sein kann. Die Beschreibung der vorzuziehenden Ausführungsform geht von einem Betriebssystem aus, das virtuelle Maschinen unterstützt, wie z.B. das IBM VM-Bettiebssystem.
Es soll davon ausgegangen werden, daß das SNA-Netzwerk aus Fig. 1 zwei verteilte Anwendungen unterstützt, die als "MAIL" und "KALENDER" bezeichnet sind, und die jedem Datenstationsanwender zur Verfügung stehen. Mit dem Anwendungsprogramm MAIL kann ein Anwender an einer Datenstation ein Dokument wie beispielsweise einen Brief erstellen und diesen Brief dann an einen oder mehrere andere Anwender an festgelegten Knoten im Netzwerk senden. Der Sender kann das Dokument im Host-System an einer logisch zentralen Systemposition speichern. Jeder Adressat des Briefes kann das Dokument zu einem späteren Zeitpunkt mit dem Anwendungsprogramm MAIL von seiner eigenen Datenstation aus abrufen. Mit der KALENDER-Anwendung kann jeder Datenstationsanwender einen elektronischen Kalender führen. Die KALENDER-Anwendung ermöglicht es einem Endanwender beispielsweise, vor der Anberaumung einer Besprechung den Kalender eines anderen Endanwenders einzusehen, um so die Zeiten zu ermitteln, an denen die eingeladenen Teilnehmer freie Termine haben. Solche Systeme sind in der Technik gut bekannt und werden kommerziell bereits in großem Stil eingesetzt. Da die allgemeine Organisation und der Betrieb solcher verteilter Anwendungen hinreichend bekannt ist, werden im folgenden lediglich diejenigen Einzelheiten beschrieben, die für ein Verständnis des Verfahrens der vorliegenden Erfindung zur Datenverarbeitung in verteilten Anwendungsprogrammen erforderlich sind.
In der folgenden Beschreibung soll daher davon ausgegangen werden, daß jede Benutzetstation im Netzwerk eine Intelligente Benutzerstation wie z.B. ein IBM PS 2 Personal Computer mit einem Multitasking-Betriebssystem wie z.B. dem IBM OS/2 Betriebssystem ist. Ferner soll angenommen werden, daß das System herkömmliche SNA-Dienste bereitstellt, die die Logische Einheit des Typs LU 6.2 für verteilte Anwendungen unterstützen. Die in Fig. 1 abgebildete Datenstation kann daher zwei verteilte Anwendungsprogramme wie MAIL und KALENDER gleichzeitig verarbeiten.
Fig. 2 stellt die funktionalen Komponenten einer der interaktiven Datenverarbeitungstationen 21 aus Fig. 1 dar. Die Datenstation umfaßt eine Verarbeitungseinheit 31, die einen Mikroprozessorblock 32 enthält, der z.B. aus einem Intel 80386 Mikroprozessor besteht, einen Halbleiterspeicher 33 und einen Steuerblock 34, der die Steuerung von Ein-/Ausgabeoperationen und die Interaktion zwischen dem Mikroprozessorblock 32 und der Speichereinheit 33 übernimmt.
Die Datenstation umfaßt des weiteren eine Gruppe von herkömmlichen Peripheriegeräten, die eine Anzeigevorrichtung 36, eine Tastatur 37, einen Drucker 38, eine Speichereinheit 39 und einen Modem 40 enthalten. Da die Einzelheiten der oben beschriebenen funktionalen Blöcke nicht Bestandteil der vorliegenden Erfindung sind und in der herkömmlichen Technik bereits angewendet werden, wird lediglich eine kurze funktionale Beschreibung der einzelnen Blöcke sowie eine Beschreibung ihrer Interaktionen gegeben, die ausreicht, um einen Fachmann mit hinreichender Kenntnis der betreffenden Technik mit den grundlegenden Fakten zu versehen, die für ein Verständnis des verbesserten Verfahrens des Anmelders zur gleichzeitigen Verarbeitung von verteilten Anwendungsprogrammen erforderlich sind.
Die Verarbeitungseinheit 31 entspricht beispielsweise der Systemeinheit eines IBM Personal Computers wie dem IBM PS/2 Modell 80. Die Einheit 31 verfügt über ein Betriebssystemprogramm, das z.B. das multitaskingfähige IBM Betriebssystem OS/2 sein kann, das üblicherweise bei den PS/2 Modell 80 Systemen eingesetzt wird. Das Betriebssystemprogramm wird zusammen mit den Anwendungsprogrammen, die der Anwender aufgerufen hat, im Speicher 33 gespeichert. Wenn das System ein verteiltes Anwendungsprogramm wie MAIL oder KALENDER untetstützt, wird nur ein Teil, z.B. Teil A, des verteilten Anwendungsprogrammes in der Datenstation gespeichert, während der andere Teil, Teil B, im Host-System gespeichert wird. Je nach der Kapazität des Speichers 33 und der Größe des Anwendungsprogrammes, können Teilbereiche dieser Programme nach Bedarf von der Plattenspeichereinheit 39 in den Speicher 33 übertragen werden, wobei erstere z.B. ein 40 Megabyte Festplattenlaufwerk und ein Diskettenlaufwerk umfassen kann. Die grundlegende Aufgabe der Speichereinheit 39 besteht im Speichern von Programmen und Daten, die vom System verwendet werden, und die bei Bedarf an die Speichereinheit 33 übertragen werden können. Die Aufgabe des Diskettenlaufwetkes besteht darin, eine entfernbare Speichermöglichkeit für die Eingabe von Programmen und Daten in das System sowie für die Datenspeicherung in einer Form bereitzustellen, die problemlos auf andere Datenstationen oder Systeme übertragen werden kann.
Anzeige 36 und Tastatur 37 stellen die interaktiven Funktionen der Datenstation bereit, die darin bestehen, daß das System bei Normalbetrieb einen bestimmten Tastenanschlag des Anwenders in nahezu allen Situationen in Abhängigkeit von der Anzeige interpretiert, die dem Anwender zu diesem Zeitpunkt angezeigt wird.
In manchen Situationen veranlaßt der Anwender durch die Eingabe von Befehlen in das System, daß dieses eine bestimmte Funktion ausführt. In anderen Situationen fordert das System prinzipiell durch die Anzeige einer Menü/Meldungsanzeige, die die Funktion einer Eingabeaufforderung hat, die Eingabe bestimmter Daten an. Das Ausmaß der Interaktion zwischen dem Anwender und dem System ist abhängig von der Art des Bettiebssystems und des Anwendungsprogrammes; sie ist jedoch ein notwendiges Merkmal von Datenstationen, auf die das Verfahren der vorliegenden Erfindung angewendet werden kann.
Die in Fig. 2 abgebildete Datenstation umfaßt des weiteren einen Drucker 38, der Ausdrucke der Daten zur Verfügung stellt. Der Modem 40 hat schließlich die Aufgabe, Daten von Datenstation 21 aus Fig. 2 über eine oder mehrere SNA-Kommunikationsverbindungen zu einem Host-System zu übertragen.
Fig. 3 zeigt die verschiedenen Programmierschichten, die in einem SNA-Netzwerk verwendet werden. Die SNA-Programmierumgebung umfaßt im allgemeinen sieben Schichten wie abgebildet. Die oberste hier abgebildete Schicht ist die Endanwenderschicht und besteht aus den Endanwenderprogrammen. Die zweite Schicht wird als Dienstfunktion für adressierbare Netzeinheiten bezeichnet. Diese Dienste umfassen z.B. Darstellungsdienste, Datenstationsdienste und Formatierungsdaten für bestimmte Anwendungen. Die dritte Schicht wird als Datenflußsteuerung bezeichnet. Sie dient der Aufrechterhaltung von Betriebsarten für das Senden/Empfangen von und führt höhere Fehlerkorrekturen durch. Die vierte Schicht dient der Datenübertragungssteuerung und übernimmt die Verschlüsselung und Entschlüsselung sowie die Mengendosierung der Sitzungsschicht. Die fünfte Schicht ist die Pfadsteuerung, die für die Leitwegführung, die Segmentierung von Dateneinheiten und die Mengendosierung des virtuellen Leitweges zuständig ist. Die sechste Schicht ist die Datenübertragungsleitung. Sie übernimmt die Schichtenadressierung, Folgesteuerung und Fehlerkontrolle für die Kommunikationsverbindungen. Die siebte und letzte Schicht ist die Physische Schicht, die z.B. die Anschlußbelegung der Stecker für die verschiedenen Signale festlegt.
APPC legt die Dienstfunktion für adressietbare Netzeinheiten, die Datenflußsteuerung und die Übertragungssteuerung fest. Wie auf Seite 306 des weiter oben erwähnten IBM System Journal beschrieben, erfolgt die Definition der LU-6.2-Dialogfunktionen in Form von programmiersprachenähnlichen, "Verben" genannten Anweisungen. Die Dokumentation anhand von Verben, die vollständig durch die Prozeßlogik definiert sind, die die Sitzungsabläufe erzeugt, ermöglicht eine erhebliche größere Präzision als dies in normaler Schriftsprache möglich wäre. Figur 4A zeigt, wie die Verben die Interaktion zwischen den Transaktionsprogrammen, d.h. Teil A oder Teil B der verteilten Anwendung, und den Logischen Einheiten für Dialogressourcen festlegen. Ein Satz von Verben wird eher als eine Protokolleingrenzung denn als eine Anwendungsprogrammschnittstelle bezeichnet.
Wie in Fig. 4A gezeigt, interpretiert die Darstellungsdienstekomponente Verben und kann so aufgefaßt werden, als enthielte sie eine Unterroutine für jedes Verb. Der LU-Ressourcenmanager teilt die Dialogressourcen zu und ordnet die Dialoge den Sitzungen zu, wobei es Warteschlangen von freien Sitzungen und anstehenden Zuordnungsanforderungen bildet. Seine äquivalente Produktkomponente weist ebenfalls auf produktspezifische Art und Weise lokale Ressourcen zu. Die Funktionsweise der folgenden LU- 6.2-Verben wird auf Seite 307 des oben erwähnten IBM System Journal erläutert. Die beschriebenen 6.2-Verben sind SEND_DATA, RECEIVE_AND_WAIT, PREPARE_TO_RECEIVE, FLUSH, REQUEST_TO_SEND, SEND_ERROR, CONFIRM, ALLOCATE AND DEALLOCATE.
Das Verb ALLOCATE beginnt eine neue Aktivität in einer anderen LU, indem es einen Dialog mit einem benannten Partnerprogramm herstellt. Das benannte Partnerprogramm wird ausgeführt und kann vom Dialog, der es aufgerufen hat, adressiert werden. Das Verb ALLOCATE enthält mehrere Parameter, u.a.
1. LU_NAME. Dies ist der Name der LU, an der das Partnerprogramm sich befindet.
2. TPN. TPN ist der Transaktionsprogrammname des Partnerprogrammes, mit dem ein Dialog hergestellt werden soll.
3. MODUS_NAME. MODUS_NAME gibt die Art des Übertragungsdienstes an, den der Dialog bereitstellen soll.
So kann als Dialogart beispielsweise SECURE, BULK oder DELAY gewählt werden. Die LU verwendet eine Sitzung mit dem geeigneten MODUS_NAMEN, um den Dialog durchzuführen.
Ziel des Dialoges ist die Neuerzeugung eines Prozesses oder eines Tasks; dies bedeutet, daß die verteilte Verarbeitung im Netzwerk zu jedem beliebigen Zeitpunkt aus einer Anzahl von unabhängigen verteilten Transaktionen besteht, von denen jede einzelne zwei oder mehrere Transaktionsprogramme umfaßt, die durch einen Dialog verbunden sind. Das Verb DEALLOCATE beendet den Dialog. Da jeder Partner ein Verb DEALLOCATE ausgeben kann, kann ein Dialog von einer einzelnen kurzen Nachricht bis zu einer Vielzahl von ausgetauschten langen oder kurzen Nachrichten dauern. Ein Dialog könnte unbegrenzt lange weitergeführt und lediglich durch einen Fehler der Logischen Einheit oder durch die ausführende Sitzung beendet werden. Transaktionsprogramme werden nicht durch DEALLOCATE beendet, sondern so lange weitergeführt, bis sie entweder selbst ihre Ausführung beenden, fehlerbedingt oder durch den Anwender beendet werden.
Sowohl Netzwerkanwendungsprogramme als auch Diensttransaktionsprogramme verwenden die Ausführungsdienste, die von den Logischen Einheiten bereitgestellt werden. Diensttransaktionsprogramme werden in Logischen Einheiten auf dieselbe Weise ausgeführt wie andere Transaktionsprogramme. Sie interagieren mit dem Anwender oder können als reiner programmierter Operator ausgeführt werden. Viele Diensttransaktionsprogramme wirken sich lediglich auf die lokale Logische Einheit aus. Ein Beispiel ist ein Befehl, mit dem der aktuelle Satz an aktiven Transaktionsprogrammen angezeigt werden kann.
Andere Steuettransaktionen, insbesondere diejenigen, die sich auf Sitzungen beziehen, können sich auf andere Logische Einheiten oder auf Anwendungen in anderen Logischen Einheiten auswirken. So veranlaßt ein lokaler Befehl zur vorzeitigen Beendigung einer Transaktion, die einen Dialog verwendet, daß der Dialog fehlerbedingt beendet wird; dies ist eine Statusänderung, die an die Logische Partnereinheit übertragen und dem Transaktionsprogramm angegeben werden muß, das den Dialog ebenfalls nutzt. Oder ein LU-Bedienet kann entscheiden, eine oder mehrere der von den zwei LUs gemeinsam genutzten Sitzungen zu aktivieren, wobei diese Entscheidung der anderen Logischen Einheit mitgeteilt werden muß. Die erweiterte Datenübertragung zwischen Programmen für eine SNA-Architektur umfaßt mehrere Operatorverben, die insbesondere für die Aktivierung und Deaktivierung von Sitzungen die Steuerung und Koordination zwischen den einzelnen LUs übernehmen. Wenn ein verteiltes Diensttransaktionsprogramm an einer LU beginnt, stellt es einen Dialog mit einem Partnertransaktionsprogramm in einer Partner-LU her. Die beiden Transaktionsprogramme arbeiten dann zusammen, um die gewünschte Steueraktivität auszuführen.
Das IBM VM-Hostbetriebssystem umfaßt eine als APPC/VTAM-Dienste (AVS) bezeichnete Komponente, die für die Unterstützung der APPC-Protokolleingrenzung im Betriebssystem zuständig ist. AVS definierte eine oder mehrere LU-6.2-Logische-Einheiten nach IBMs Virtual Telecommunications Access Method (VTAM). VTAM ist die IBM Komponente, die die Datenübertragungsschicht zwischen dem Host-System und den verschiedenen Datenstationen des Netzwerkes verwaltet. AVS fungiert im Rahmen des Betriebssystems als Brücke für die APPC-Datenübertragung zu den virtuellen Maschinen. Wenn z.B. ein APPC-Verb ALLOCATE empfangen wird, das von außerhalb des VM-Betriebssystems stammt, ermittelt VTAM, ob eine Logische Einheit aktiv ist, die dem in ALLOCATE angegebenen LU-Namen entspricht. Zuvor hat die AVS-Komponente VTAM mitgeteilt, daß sie den gesamten Datenverkeht für bestimmte LU-Namen übernimmt. VTAM stellt fest, daß die AVS eine LU festgelegt hat, die dem in dem Verb ALLOCATE genannten Namen entspricht, und leitet das Verb ALLOCATE weiter an die AVS.
Mit dem in diesem Prozeß verwendeten Verb ALLOCATE werden weitere Daten bereitgestellt. ALLOCATE enthält eine Anwenderkennung, die Identifizierung des Anwenders, für den ALLOCATE ausgegeben wurde sowie einen Transaktionsprogrammnamen (TPN). Der TPN steht für das Anwendungsprogramm, das aufgerufen werden soll, d.h. den Teil B der verteilten Anwendung wie z.B. MAIL. Wenn die AVS das Verb ALLOCATE empfängt, erzeugt sie eine virtuelle Maschine und leitet das in ALLOCATE angegebene Transaktionsprogramm an eine Betriebssystemkomponente weiter, die in der virtuellen Maschine resident ist. Die Betriebssystemkomponente in der virtuellen Maschine aktiviert die genannte Anwendung, und zwischen Teil A und Teil B der Anwendung kann eine Interaktion stattfinden.
Fig. 4A und 4B haben Ahnlichkeit mit der Darstellung der SNA- Programmierumgebung aus Fig. 3 und zeigen die SNA/APPC-Programmierumgebung, in der das Verfahren der vorliegenden Erfindung vorteilhaft eingesetzt werden kann.
Die IWS verfügt über eine Programmierorganisation, mit der die Datenstation zwei Anwendungsprogramme gleichzeitig ausführen kann. Die Multitasking-Funktionen von IBM OS/2 werden aus führlich in dem Artikel "Multiple Tasks", S. 90ff, Band 5, Nummer 11 des PC Tech Journal vom November 1987 erläutert.
Wenn im vorhergehenden Beispiel dieselbe Datenstation ein zweites verteiltes Anwendungsprogramm aufruft, wird dieses derselben virtuellen Maschine zugeordnet wie das erste verteilte Anwendungsprogramm. Als Ergebnis werden die beiden Anwendungsprogramme auf der virtuellen Maschine des Host-Systems serialisiert, wodurch sich das Gesamtziel der Bereitstellung eines Multitasking-Betriebssystems für die Datenstation nicht mehr realisieren läßt.
Gemäß dem Verfahren der vorliegenden Erfindung wurde mit einem in Fig. 4B schematisch dargestellten VM-Poolmanaget (VMPM) den Protokollbegrenzungsdiensten mit dem Stand der Technik eine weitere Funktion hinzugefügt. Der VMPM arbeitet in derselben virtuellen Maschine wie die Protokollbegrenzungsdienste; im Rahmen des IBM VM-Betriebssystems wird diese Maschine als AVS-Modul bezeichnet. Wenn der VMPM aktiviert wird, liest er einen Satz von bei der Installation bereitgestellten Parametern und erzeugt eine Mehrzahl von virtuellen Maschinen (Fig. 5), die in Bereitschaftszustand gesetzt werden. Diese Parameter enthalten generische Namen der virtuellen Maschinen, die im Pool erzeugt werden sollen. Die Namen oder Kennungen der virtuellen Maschinen wurden zuvor im Betriebssystemverzeichnis der virtuellen Maschinen definiert. Der VMPM gibt für jede einzelne Maschine ein Makro für die automatische Anmeldung aus. Das Makro für die automatische Anmeldung ist eine Funktion, die im Zusammenhang mit dem VM-Betriebssystem bekannt ist. Wenn es für eine bestimmte virtuelle Maschine ausgegeben wird, wird diese Maschine erzeugt und in einen Bereitschaftszustand gesetzt, wobei die Maschine in diesem Fall bereit ist, ein APPC-Verb ALLOCATE von der AVS zu empfangen.
Während die einzelnen Maschinen durch das Makro für die automatische Anmeldung erfolgreich erzeugt werden, erstellt der VMPM einen Eintrag in einer in Fig. 6 abgebildeten VMPM-Datenstruktur, die die betreffende virtuelle Maschine und ihren Betriebszustand darstellt, wobei der Eintrag aus VMPM-Steuerblöcken besteht. Wenn alle virtuellen Maschinen in der Liste erzeugt wurden, überträgt der VMPM die Steuerung wieder an die AVS. Nachdem alle virtuellen Maschinen erzeugt wurden und der Poolmanager die Steuerung wieder an die AVS übertragen hat, werden folgende Schritte durchgeführt.
Der Datenstationsbediener gibt interaktiv Daten in seine Datenstation ein, um das verteilte Anwendungsprogramm MAIL aufzurufen. Als Ergebnis gibt der Teil "A" der verteilten Anwendung MAIL das Verb ALLOCATE aus, das aus den folgenden Parametern besteht
LU-NAME = LU 1
TPN = MAIL
USERID = DICKC.
Wenn die VTAM das Verb ALLOCATE empfängt, stellt sie fest, daß eine LU1 bezeichnete LU durch die AVS definiert wurde und leitet das Verb ALLOCATE weitet an die AVS. Die AVS stellt fest, daß LU1 dem Poolmanager zugeordnet ist, indem sie die Datenstruktur des Poolmanagers durchsucht. Aus diesem Grund aktiviert sie die Poolmanager-Komponente der AVS und gibt das Verb ALLOCATE an sie weiter. Die zweite Aufgabe des Poolmanagers besteht darin, seine Steuerblockeinträge, die für die virtuellen Maschinen im VM-Pool stehen, zu durchsuchen, und eine verfügbare Maschine zu ermitteln. Wenn es eine verfügbare virtuelle Maschine ermittelt hat, ändert es die Parameter von ALLOCATE folgendermaßen:
LU-NAME = VM01
TPN = MAIL
USERID = DICKC.
Der Poolmanager ändert den LU-Namen in den Namen der virtuellen Maschine im Pool. Er aktualisiert ferner den Steuerblockeintrag, der für die virtuelle Maschine steht, um anzuzeigen, daß sie nicht länger verfügbar ist. Der Poolmanager schreibt anschließend Daten in den Steuerblockeintrag, die das aktuelle Verb der virtuellen Maschine beschreiben. Daraufhin gibt er das Verb ALLOCATE mit dem geänderten LU-Namen wieder aus.
Das VM-Betriebssystem leitet dann das Verb ALLOCATE weitet an den Betriebssystemcode, der in der ausgewählten virtuellen Maschine resident ist. Dieser Code aktiviert den in MAIL genannten Anwendungsteil B und ändert die Kennung der virtuellen Maschine zu der in dem Verb ALLOCATE angegebenen Kennung, die im obigen Beispiel DICKC war. Daraufhin wird zwischen Teil A und Teil B des verteilten Anwendungsprogrammes MAIL ein Dialog durchgeführt. Ahnliche Interaktionen wie die oben beschriebenen können gleichzeitig auf einem einzelnen multitaskingfähigen PC oder von mehreren PCs durchgeführt werden. Wenn Teil A und Teil B ihre Interaktion beendet haben, kann ein beliebiger der beiden Teile ein APPC-Verb DEALLOCATE zur Beendigung des Dialoges ausgeben. Wenn ein Verb DEALLOCATE empfangen wird, ruft die AVS den Poolmanager auf und ändert den Steuerblockeintrag, der für die betreffende virtuelle Maschine steht. Der Poolmanager ändert danach den Status der virtuellen Maschine auf "verfügbar".
Es ist ersichtlich, daß gemäß dem obigen Verfahren ein einzelner Dialog, der durch ALLOCATE und DEALLOCATE definiert ist, mit einer zugewiesenen virtuellen Maschine aus dem Pool an virtuellen Maschinen durchgeführt wird, der vom Poolmanager gesteuert wird. Der nächste Dialog würde zweifellos einer anderen virtuellen Maschine aus dem Pool zugewiesen werden. Als Ergebnis werden daher zwei verteilte Anwendungsprogramme, die von einer einzigen Datenstation aus mit einer einzigen Anwenderkennung gleichzeitig ausgeführt werden, vom VMPM gemäß dem neuen Verfahren verschiedenen VMs zugewiesen, die zuvor durch den Poolmanager für virtuelle Maschinen erzeugt worden sind.
Das oben beschriebene neue Verfahren vermeidet zwar das Problem herkömmlicher Systeme, bei dem zwei verteilte Anwendungsprogramme von derselben Datenstation mit derselben Anwenderkennung innerhalb einer einzelnen virtuelle Maschine im Host-System serialisiert werden, es erfordert jedoch die Entwicklung eines neuen Verfahrens, mit dem die aktuelle Datenstationsadresse eines Systemanwenders ermittelt werden kann, da einem Anwender nun nicht mehr beim Anmeldeprozeß eine dedizierte virtuelle Maschine zugeordnet wird. Vor der Beschreibung des neuen Verfahrens werden nun die Schritte, die bei der Erzeugung des Pools an virtuellen Maschinen im Host durchgeführt werden, wenn das Host-System wie oben beschrieben erstmalig geladen wird, im Hinblick auf das Flußdiagramm aus Fig. 7 erläutert, wobei das Flußdiagramm eine Zusammenfassung dieser Schritte darstellt. Entsprechend sollen auch die Schritte, die beim oben beschriebenen Datenübertragungsprozeß zwischen den Programmen durchgeführt werden, im Hinblick auf das Flußdiagramm aus Fig. 8, das eine Zusammenfassung dieser Schritte darstellt, kurz erläutert werden.
Der Begriff "verteiltes Anwendungsprogramm" wurde in der obigen Beschreibung für zwei Programme verwendet, die so codiert wurden, daß sie mittels APPC-Verben Daten miteinander austauschen können. Dabei wird ein Programm auf einer Datenstation und das andere auf dem Host ausgeführt. Das Programm, das als erstes ein Verb ALLOCATE ausgibt, um eine Dialoganforderung auszulösen, wird mitunter als Teil A des verteilten Anwendungsprogrammes bezeichnet, während das Programm, das in der Anforderung adressiert wird, als Teil B des verteilten Anwendungsprogrammes bezeichnet wird. Der Begriff "Transaktionsprogramm" wurde sowohl für Teil A als auch für Teil B eines verteilten Anwendungsprogrammes verwendet.
Gemäß dem neuen Verfahren hat der Systemanwender die Option, die aktuelle Datenstationsadtesse festzulegen, an der eine Datenübertragung mit dem Anwender möglicherweise stattfindet, da die Datenstationen im Netzwerk aus intelligenten Benutzerstationen, wie z.B. Personal Computern (PCs) bestehen, die nützliche Rechenprozesse für den Anwender ausführen können, ohne daß ein Datenaustausch mit dem Host erforderlich ist. Zu dem Zeitpunkt, an dem der Anwender eine Datenübertragung mit dem Host-System durchführen möchte, ruft er ein verteiltes PC-Anwendungsprogramm auf. Teil A des Programmes ist im PC resident und stellt einen LU-6.2-Dialog mit seinem Gegenstück Teil B her, der im Host resident ist. Nachdem das Programm aufgerufen wurde, zeigt Teil A dem Anwender auf dem Bildschirm der Anzeigevorrichtung ein Anzeigefeld an, das den Anwender zur Eingabe von vorgegebenen Informationen zur Anwenderidentität auffordert, und erzeugt dann die Daten, die für das Verb ALLOCATE erforderlich sind, die gemeinsam mit dem Kennwort des Anwenders eingegeben wurde. Die USERID des Anwenders wird zusammen mit dem Anwenderkennwort eingegeben. Teil A des Programmes gibt ein Verb ALLOCATE aus, um einen Dialog mit Teil B herzustellen. Teil B soll dabei mit BEGIN und das Host-System mit LU1 bezeichnet werden. In diesem Fall hätte das Verb ALLOCATE die folgende Form:
ALLOCATE TPN = BEGIN
USERID = DICKC
Password = ABCD0001
LUNAME LU1
Wenn ALLOCATE vom Host-System LU1 empfangen wird, leitet die AVS-Komponente der VTAM-Dienste das Verb weiter an das Verwaltungsprogramm für den Pool an virtuellen Maschinen, da sie "weiß", daß der VMPM das Transaktionsprogramm BEGIN steuert. Der VMPM verfügt über ein Unterkomponentenprogramm BEGIN, das die Datenstruktur des Identifizierungssteuerblock-Eintrages aus Fig. 19 erzeugt und anschließend die USERID aus ALLOCATE und die Datenstationskennung, PCID, aus den Funktionsverwaltungs-Kennsätzen 5 (Function Management Header, FMH) speichert, bei denen es sich um einen Satz von Steuerdaten handelt, die zu den einzelnen ALLOCATE-Verben gehören. Das Programm BEGIN stellt den ICBE dann in eine Kette von ICBEs, die sich in einem Bereich des Host-Speichers befinden, der für alle Programme, die unter dem VMPM laufen, zugänglich ist. Das Hinweismarkenfeld des vorhergehenden ICBEs wird aktualisiert, so daß es auf den neu erstellten ICBE zeigt; danach wird ein Verb DEALLOCATE ausgegeben, um den Dialog zu beenden. Der Host "versteht" nun die aktuelle Datenstationsadresse des Anwenders, da der ICBE die USERID mit der PCID verknüpft. Die Schritte des oben beschriebenen Anmeldeprozesses haben insofern eine äußerliche Ähnlichkeit mit dem Anmeldeprozeß der herkömmlichen Technik, als der Anwender eine USERID und ein Kennwort eingibt. In Bezug auf die Interaktionen im Host-System unterscheiden sich die beiden Verfahren in nahezu jeder anderen Hinsicht voneinander. Fig. 9 zeigt ein Flußdiagramm, das die beim Anmeldeprozeß durchgeführten Schritte zusammenfaßt.
Eine beliebige verteilte Anwendung, die eine Anforderung für einen Dialog mit der USERID stellt, wird vom VMPM verarbeitet. Da das Verb ALLOCATE, das diese Anforderung darstellt, die USERID des Adressaten enthält, durchsucht der VMPM zunächst die gespeicherte ICBE-Kette auf eine USERID, die mit derjenigen von ALLOCATE übereinstimmt. Wird eine übereinstimmende USERID gefunden, wird ALLOCATE mit der betreffenden PCID an die korrekte Datenstation weitergeleitet, wo das Verb auf die übliche Art und Weise angenommen und verarbeitet wird. Fig. 10 ist eine Zusammenfassung der Schritte, die bei dem oben beschriebenen Prozeß durchgeführt werden.
Wenn die USERID bestimmt, daß eine Datenübertragung mit dem Host und anderen Datenstationsanwendern nicht mehr notwendig oder gewünscht ist, ruft der Anwender ein PC-Anwendungsprogramm auf. Das Anwendungsprogramm zeigt dem Anwender einen Bildschirm an, auf dem er aufgefordert wird, die Schritte durchzuführen und Daten einzugeben, die für ein Löschen der aktuellen Datenstationsadresse erforderlich sind. Das Anwendungsprogramm gibt dann ein Verb ALLOCATE für einen Dialog mit dem anderen, mit END bezeichneten Teil des Transaktionsprogrammes (Teil B) an den Host LU1 aus. Beim Empfang im Host-System bestimmt die AVS-Komponente des VTAM-Dienstptogrammes, daß der TPN END unter dem VMPM ausgeführt wird, und leitet das Verb ALLOCATE weiter an den VMPM, wo ein Unterkomponentenprogramm den ICBE mit der USERID in ALLOCATE löscht. Nachdem der ICBE mit der USERID aus der ICBE-Kette entfernt worden ist, gibt das Programm END ein Verb DEALLOCATE aus, um den Dialog zu beenden. Die aktuelle Datenstationsadresse der USERID ist dem System danach nicht mehr bekannt. USERID kann auch dann noch Programme auf dem PC ausführen, für die keine Intetaktion mit dem Host-System erforderlich ist. Fig. 12 ist eine Zusammenfassung der Schritte, die durchgeführt werden, um die aktuelle Datenstationsadresse der USERID aus dem System zu entfernen.

Claims

1. Ein Verfahren zur Steuerung der Verarbeitung von vom Host ausgehenden Dialoganforderungen für bekannte Anwender eines SNA -Netzwerkes, das verteilte Anwendungsprogramme gemäß LU-6.2-Protokollen verarbeitet, in dem ein Dialog selektiv zwischen den Teilen eines ersten verteilten Anwendungsprogrammes hergestellt wird, wobei ein Teil auf einer Intelligenten Benutzerstation einer Mehrzahl von Intelligenten Benutzerstationen IWSs, die selektiv mit dem Netzwerk verbunden werden kann, gespeichert und ausgeführt wird, und ein anderer Teil in einem Host gespeichert wird, und wobei der Prozessor über einen Poolmanager für virtuelle Maschinen VMPM verfügt, mit dem ein Pool an virtuellen Maschinen erzeugt und die Zuordnung der einzelnen virtuellen Maschinen für die Verarbeitung des anderen Teiles verwaltet wird, wobei die Zuordnung zu dem Zeitpunkt aufgehoben und die zugeordnete virtuelle Maschine in den Pool zurückgestellt wird, zu dem ein verarbeiteter Dialog beendet wird; wobei das Verfahren verhindert, daß eine vom Host ausgehende Dialoganforderung, die an einen ersten Anwender mit einer bestimmten USERID adressiert ist, durch eine zugeordnete virtuelle Maschine verarbeitet wird, sofern diese nicht durch den ersten Anwender ausdrücklich betechtigt wurde, der die Kennung einer ersten IWS angibt, an die die vom Host ausgehenden Dialoganforderungen gesendet werden sollen, und wobei es gleichzeitig gestattet, daß eine Dialoganforderung durch den ersten Anwender von einer IWS durch eine virtuelle Maschine verarbeitet wird, die vom VMPM zugewiesen wurde,

wobei das Verfahren die folgenden Schritte umfaßt:

A) Bereitstellen eines zweiten verteilten Anwendungsprogrammes mit einem Teil, der in der ersten IWS resident ist und einem anderen, hostresidenten Teil, mit dem die zugeordnete virtuelle Maschine berechtigt wird, die vom Host ausgehenden Dialoganforderungen, die an den ersten Anwender adressiert sind, zu verarbeiten,

B) Aufrufen eines Teiles des zweiten Anwendungsprogrammes auf der ersten IWS, um ein Verb ALLOCATE zu übertragen, mit dem ein Dialog mit dem anderen Teil angefordert wird, wobei das Verb ALLOCATE die USERID und die Kennung der ersten IWS enthält, an der sich der erste Anwender zum gegenwärtigen Zeitpunkt befindet,

C) Verarbeiten des Verbs ALLOCATE im Host, die folgenden Schritte umfassend:

1) Erzeugen der Datenstruktur eines Identifizierungssteuerblock-Eintrags ICBE zur Speicherung der USERID des ersten Anwenders und der Kennung der ersten IWS sowie

2) Hinzufügen des ICBE zu einer Kette von ICBEs an einem Speicherplatz, auf den alle virtuelle Maschinen zugreifen können, um die Ermittlung der Kennung der ersten IWS und der USERID durch die einzelnen virtuellen Maschinen zu gestatten, die für die Verarbeitung einer vom Host ausgehenden Dialoganforderung mit der USERID zugewiesen wurden,

D) Verarbeiten einer vom Host ausgehenden Dialoganfordetung mit der USERID durch eine zugeordnete virtuelle Maschine, die folgenden Schritte umfassend:

1) Durchsuchen der ICBE-Kette, um die Kennung der IWS zu ermitteln, an der sich der angegebene Anwendet zum gegenwärtigen Zeitpunkt befindet, und

2) Übertragen der Anforderung ausschließlich dann, wenn die Kennung der IWS bei der Durchsuchung ermittelt werden konnte.

2. Das Verfahren gemäß Anspruch 1, das weiter den folgenden Schritt umfaßt:

Speichern der an den Host übertragenden ICBE-Daten mit dem Verb ALLOCATE, um die USERID und die Kennung der IWS, die das Verb ALLOCATE ausgegeben hat, miteinander zu verknüpfen.

3. Das Verfahren gemäß Anspruch 2, das weiter den folgenden Schritt umfaßt:

Ausgeben eines Verbs DEALLOCATE durch das Host-System an die Kennung der ersten IWS, um den Dialog zu beenden.

4. Das Verfahren gemäß Anspruch 3, bei dem der Verarbeitungsschritt weiter die folgenden Schritte umfaßt:

A) Ausgeben eine Verbs ALLOCATE durch den Host, mit der ein Dialog mit der USERID angefordert wird, und

B) Ermitteln, ob die USERID Dialoganforderungen annimmt, indem

1) die ICBE-Kette auf einen Eintrag mit der USERID durchsucht wird und

2) das Verb ALLOCATE an die Kennung der IWS übertragen wird, die in dem ISBE mit der ersten USERID gespeichert ist, wenn die USERID beim Durchsuchungsschritt gefunden wurde.

5. Das Verfahren gemäß Anspruch 4, das weiter den folgenden Schritt umfaßt:

Beenden des Verarbeitungsschrittes, wenn der Durchsuchungsschritt ergeben hat, daß die USERID nicht in dem durchsuchten ICBE gespeichert ist.