DE69220093T2

DE69220093T2 - Verarbeitungsnetzwerk für verteilte anwendungsprogramme.

Info

Publication number: DE69220093T2
Application number: DE69220093T
Authority: DE
Inventors: Reinhard Duscher; Tony Gargya; Gerold Kurth
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1992-06-18
Filing date: 1992-06-18
Publication date: 1997-12-04
Anticipated expiration: 2012-06-19
Also published as: US5606493A; WO1993025962A1; DE69220093D1; CA2098418C; JPH08502841A; JP3612652B2; EP0646260B1; IL105568A; EP0646260A1; IL105568A0; CA2098418A1

Description

Gebiet der Erfindung

Die Erfindung betrifft ein System zum Ausführen einer Ferntask auf einem Fernrechner, die von einer lokalen Task angefordert wird, die auf einem lokalen Rechner abläuft, wobei die Fernrechner in einem Netzwerk mit dem lokalen Rechner verbunden sind, wobei der lokale Rechner eine lokale Benutzerarbeitseinheit zur Datenübertragung enthält, wobei die lokale Benutzerarbeitseinheit zur Datenübertragung Anforderungen an den Fernrechner überträgt, die Ausführung der Ferntask einzuleiten und während des Ausführens der Ferntask Daten zu senden und zu empfangen, und wobei der Fernrechner eine Benutzerarbeitseinheit zur Datenfernübertragung enthält, wobei die Benutzerarbeitseinheit zur Datenfernübertragung Anforderungen vom lokalen Rechner erhält, die Ausführung der Ferntask einzuleiten und während des Ausführens der Ferntask Daten zu senden und zu empfangen.

Stand der Technik

Der Stand der Technik beschreibt eine Vielfalt von Rechnernetzwerken. Das IBM System Journal, Bd. 22, Nr. 4 von 1983 enthält eine Artikelserie, die einem Überblick über die IBM System- Netzwerk-Architektur (SNA) gewidmet ist. Auf Seite 345 dieser Veröffentlichung wird ein Netzwerk als "eine Konfiguration von Datenstationen, Steuerungen und Prozessoren und den Verbindungselementen, die sie verbinden" definiert. Wenn eine derartige Konfiguration Benutzeranwendungen mit Datenverarbeitung und Informationsaustausch unterstützt die mit den Spezifikationen der IBM-Systemnetzwerkarchitektur übereinstimmen, wird sie als SNA- Netzwerk bezeichnet. SNA definiert im wesentlichen logische Dateneinheiten, die sich auf die physischen Dateneinheiten in einem Netzwerk beziehen, und gibt die Regeln für Interaktionen zwischen diesen logischen Dateneinheiten vor.
Die logischen Dateneinheiten eines SNA-Netzwerkes enthalten netzwerkadressierbare Einheiten und das Pfadsteuernetzwerk, das sie verbindet. Netzwerkadressierbare Einheiten kommunizieren unter Verwendung logischer Verbindungen miteinander, die "Sitzungen" genannt werden. Die drei Arten von netzwerkadressierbaren Einheiten (NAUs) sind die logische Einheit (LU), die physische Einheit (PU) und die Steuerzentrale (SSCP), die wie folgt definiert sind:
Logische Einheit (LU): Eine LU ist ein Anschluß, über den Endbenutzer auf das SNA-Netzwerk zugreifen können. Ein Endbenutzer verwendet eine LU, um mit einem anderen Endbenutzer zu kommunizieren und Dienste einer Steuerzentrale SSCP anzufordern.
Physische Einheit (PU) : Eine PU ist eine Komponente, welche die Betriebsmittel eines Knotens in Zusammenarbeit mit einer SSCP verwaltet.
Steuerzentrale (SSCP) : Dies ist ein Brennpunkt für Konfigurationsverwaltung, Problembestimmung und Verzeichnisdienste für Endbenutzer. SSCPs können mit LUs und PUs Sitzungen haben. Wenn eine derartige Sitzung stattfindet, befindet sich die LU oder PU in der Domäne der SSCP. Zusätzlich zu Sitzungen mit LUs und PUs können SSCPs auch miteinander kommunizieren, um die Einleitung und den Abschluß von Sitzungen zwischen logischen Einheiten und in unterschiedlichen Domänen zu koordinieren.
Aus der Sicht der Hardware umfaßt ein einfaches Netzwerk ein Hauptrechner-System das einer Verarbeitungseinheit und einer Vielzahl von lokalen Datenstationen, die einzelnen Benutzern zugeordnet sind. Die lokalen Datenstationen sind wahlweise über eine oder mehrere Datenübertragungsverbindungen an das Hauptrechnersystem anschließbar. Diese Verbindungen können nur ein Koaxialkabel, eine zugeteilte Telefonleitung oder in einigen Fällen eine Satellitenübertragungsstrecke umfassen.
Die Hauptrechnerverarbeitungseinheit hat meist ein Betriebssystem, das die Erzeugung einer großen Anzahl von virtuellen Maschinen unterstützt, voh denen jede auf Anforderung einem Endbenutzer zugeordnet wird. Eine virtuelle Maschine verarbeitet Tasks für den zugeordneten Endbenutzer, indem die Hardware des Hauptrechnerprozessors des Hauptrechnersystems gemeinsam benutzt wird. Einige Hauptrechnersysteme können mehr als einen Hardwareprozessor enthalten, so daß am Hauptrechner wirkliche Simultanverarbeitung erfolgt, da eine Vielzahl von Prozessoren parallel laufen. Noch öfter gibt es nur einen Hardwareprozessor, der "gleichlaufend" Datenverarbeitungstasks für die virtuellen Maschinen mit Hilfe einer Dialogbetriebstechnik ausführt. Dies ist für die Endbenutzer an den Datenstationen transparent.
In Datenverarbeitungsnetzwerken werden zwei allgemeine Arten von Datenstationen benutzt. Die erste wird als "dumme Datenstation" bezeichnet, weil sie nur eine Tastatur und eine Anzeigeeinrichtung und wenig oder keine Verarbeitungsfähigkeit außer der umfaßt, die zur Herstellung einer Verbindung mit dem Hauptrechnersystem erforderlich ist. Die zweite Art von Datenstation wird als Intelligente Arbeitsstation (IWS) bezeichnet und ist mit ihrer eigenen Prozessoreinheit und unterstützenden peripheren Geräten ausgerüstet. Die Bezeichnungen IWS und Arbeitsplatzrechner (PC) werden oft austauschbar benutzt. Mit der einfachen Verfügbarkeit von PCs, die sehr attraktive Preisleistungsverhältnisse haben, werden die meisten neuen Netzwerke mit Datenstationen vom IWS-Typ eingerichtet, und viele der älteren Netzwerken werden modifiziert, indem dumme Datenstationen durch Datenstationen vom IWS-Typ ersetzt werden.
Dadurch, daß jeder Endbenutzer im Netzwerk mit seiner eigenen Verarbeitungsfähigkeit ausgerüstet wird, bleibt die Hauptrechner-CPU von vielen Datenverarbeitungstasks verschont, die früher am Hauptrechner ausgeführt wurden. Die Art der Tasks, die durch die Hauptrechner-CPU verarbeitet werden, hat sich daher verändert, und anspruchsvollere Anwendungen, wie etwa elektronische Postübermittlung und elektronische Terminplanung, werden nun auf dem Netzwerk unter der Steuerung des Hauptrechnersystems realisiert. Diese beiden Anwendungen enthalten das, was als verteilte Anwendungsprogramme bezeichnet wird, die darin bestehen, daß ein Teil des Anwendungsprogrammes sich im Hauptrechnersystem befindet und ein weiterer in der IWS- Datenstation.
Ein Überblick über die Produkte, die zum Betreiben von verteilten Anwendungsprogrammen verfügbar sind, ist in dem Artikel "Typing micro-mainframe knot" von V. Rawzino enthalten, der in Datamation, Bd. 30, Nr. 11 vom 15. Juli 1984 auf den Seiten 82 bis 90 veröffentlicht wurde.
Viele der derzeitigen Datenverarbeitungsnetzwerke sind entsprechend der IBM SNA-Architektur konstruiert, die das erste Mal 1974 beschrieben wurde. Seit damals sind verschiedene neue Funktionen und Dienste hinzugefügt worden. Wie früher vorgeschlagen, können SNA-Netzwerke als eine Vielzahl von Knoten angesehen werden, die durch Datenverbindungsstrecken miteinander verbunden sind. An jedem dieser Knoten senden Pfadsteuerelemente Informationspakete, die als Pfadinformationseinheiten (Plus) bezeichnet werden, zwischen Betriebsmittelverwaltern, die logische Einheiten (LUs) genannt werden. Diese logischen Verbindungen der Pfade werden als Sitzungen bezeichnet. Ein Transportnetzwerk für Daten wird daher durch die Pfadsteuerelemente und die Steuerelemente der Datenverbindungsstrecke definiert.
Knoten können durch eine Vielzahl von Verbindungsstrecken verbunden werden und umfassen eine Vielzahl von LUs. Verschiedene Arten von Sitzungen und Protokollen von LUs sind innerhalb des Rahmens der SNA-Architektur eingerichtet worden. Es gibt drei allgemeine Klassen von Sitzungen. Die erste Klasse wird von SNA nicht vorgegeben. Die zweite Klasse betrifft Datenstationen, und die dritte betrifft Übertragungen von Programm zu Programm. Beispielsweise stellt LU 6 SNA-definierte Übertragungsprotokolle zwischen Programmen bereit, was die Einschränkungen von LU- Typen von Datenstationen wie LU 2 und LU 7 vermeidet. LU 6.2 wird als erweiterte Datenübertragung von Programm zu Programm oder APPC-Protokolle bezeichnet.
Logische Einheiten sind mehr als Nachrichtenanschlüsse. LUs stellen Betriebssystemdienste bereit, wie etwa Übertragungen von Programm zu Programm, die ein oder mehrere lokale Programme einschließen. Jedes Anwendungsprogramm sieht die LUs als logisches Betriebssystem und das Netzwerk von lose gekoppelten LUs, die durch Sitzungen verbunden sind, als ein verteiltes Betriebssystem an.
Die LU ordnet ihren Programmen eine Vielzahl von Betriebsmitteln zu, die von der speziellen Hardware und ihrer Konfiguration abhängen. Einige der Betriebsmittel, die zur Verfügung gestellt werden, sind entfernt, während andere lokal sind, d.h. mit der gleichen LU wie das Anwendungsprogramm verbunden sind. Die Sitzungen werden an jeder LU als logische Betriebsmittel betrachtet, sie werden aber von einzelnen LUs gemeinsam genutzt.
Die Steuerfunktion einer LU besteht in der Betriebsmittelzuordnung. Programme bitten um Zugriff zu einem Betriebsmittel. Sitzungen, die Nachrichten zwischen LUs oder Programmen übermitteln, die an LUs laufen, werden als gemeinsam genutzte Betriebsmittel betrachtet. Eine Sitzung wird in eine Vielzahl von seriell ausgeführten Dialogen unterteilt.
Zwei LUs, die durch eine Sitzung verbunden sind, haben eine gemeinsame Verantwortlichkeit, Sitzungen zur Anwendungsprogrammen zur Verwendung als "Dialoge" zuzuordnen. Die Anwendungsprogramme werden daher manchmal als "Transaktionsprogramme" bezeichnet.
Die erfolgreiche Verbindung zwischen LUs erfolgt als Ergebnis einer gemeinsamen Gruppe von Protokollen, die erstens so funktionieren, daß sie eine Sitzung zwischen zwei LUs aktivieren und zweitens den Austausch von Nachrichtendaten ermöglichen.
Das Handbuch zum SNA-Format und für Protokollhinweise mit der Bezeichnung SC30-3112, veröffentlicht von IBM Corporation, beschreibt SNA dadurch, daß es beispielsweise mit Programmiersprachenerklärungen das Format von Nachrichten, die zwischen Netzwerkeinheiten fließen, und die Programme definiert, die Nachrichten erzeugen, manipulieren, übersetzen, senden und zurückschicken.
Das SNA-Transaktionsprogrammverweis-Handbuch für LU 6.2 mit der Bezeichnung GC30-3084, veröffentlicht von IBM Corporation, definiert die Verben, welche die durch die ausführenden Produkte bereitgestellten Funktionen beschreibt.
Es sind zwei Artikel bekannt, die SNA und ihre Beziehung zur Datenübertragung zwischen intelligenten Arbeitsstationen betrachten. Dies sind "Peer-to-peer network management in an IBM SNA network" von S. Simon in IEEE Network, Bd. 5, Nr. 2 vom März 1991, S. 30 bis 34 und "Comming: a new SNA" von L.D. Passmore in Datamation, Bd. 31, Nr. 22 vom 15. November 1985, S. 102 bis 112.
Es sind zwei Europäische Patentanmeldungen bekannt, in denen verschiedene Aspekte der gemeinsamen Nutzung von Anwendungsprogrammen zwischen Rechnern beschrieben werden. Dies sind EP-A 371 229 (Hewlett-Packard) und EP-A 0 424 715 (IBM).
Es ist eine US-Patentschrift bekannt, in der gemeinsames Nutzen von Anwendungen zwischen Rechnern beschrieben wird. Dies ist US-Patentschrift 4 274 139.
Die Japanische Patentanmeldung JP-A 63-209248 (Fujitsu) (Englischsprachige Zusammenfassung in Patent Abstracts of Japan, Bd. 12, Nr. 498, S. 110 veröffentlicht) beschreibt einen Datenübertragungssteuerungsabschnitt innerhalb eines Hauptrechners, der Daten an eine Arbeitsstation überträgt.
In der Veröffentlichung "Message Passing Holds The Key To Distributed Computing", Computer Technology Review, Bd. 11, Nr. 6 vom Mai 1991, Los Angeles, CA, USA, beschreibt P. Tait ein Verfahren zum Ausführen einer Ferntask an einem Fernrechner, die durch eine lokale Task aufgerufen wurde, die an einem lokalen Rechner läuft.
Im ersten Schritt des Verfahrens wird ein Dialog zwischen einem Klienten im lokalen Rechner und einem Server in dem Fernrechner eröffnet, wobei der Server und der Klient zusammen ein Transaktionsverarbeitungsnetzwerk bilden.
In einem zweiten Schritt werden ein Funktionsname, der eine Ferntask kennzeichnet, die in der Transaktionsverarbeitungsumgebung ausgeführt werden soll, und ein erster Datenblock, der von der Ferntask als Eingabe geforderte Daten enthält, vom lokalen Rechner an den Fernrechner geschickt.
In einem dritten Schritt wird ein zweiter Datenblock, der die Ausgabe aus der Ferntask, die am Fernrechner ausgeführt wurde, am lokalen Rechner empfangen.
In einem vierten Schritt wird der Dialog zwischen dem Fernrechner und dem lokalen Rechner geschlossen.

Zusammenfassung der Erfindung

Die Aufgabe dieser Erfindung besteht darin, an einem Rechner ein verbessertes System zum Ausführen von Tasks bereitzustellen, die von Tasks an einem anderen Rechner angefordert worden sind.
Diese Aufgabe wird gemäß der Erfindung, wie in Anspruch 1 definiert, dadurch gelöst, daß mit einer Anweisung Anschluß an die Transaktionsverarbeitungsumgebung gewonnen wird, in der die Ferntask ausgeführt wird, wobei die Anweisung im lokalen Rechner gespeichert und durch die lokale Task dafür verwendet wird, auf die Ferntask zuzugreifen, wobei im lokalen Rechner ein lokaler gemeinsam genutzter Zwischenspeicher bereitgestellt wird, auf den durch die lokale Task und die lokale Benutzerarbeitseinheit zur Datenübertragung zugegriffen werden kann, und wobei im Fernrechner ein entfernter gemeinsam genutzter Zwischenspeicher zur Verfügung gestellt wird, auf den durch die Ferntask und die Benutzerarbeitseinheit zur Datenfernübertragung zugegriffen werden kann.
In einer Ausführungsform der Erfindung wird der lokale gemeinsam genutzte Zwischenspeicher durch die lokale Task bereitgestellt, und der entfernte gemeinsame Zwischenspeicher wird durch die Benutzerarbeitseinheit zur Datenfernübertragung bereitgestellt. Die lokale Task kann entweder ein Funktionsprogramm oder ein Anwendungsnavigator oder eine Umgebungsroutine sein.
Das Verfahren der Erfindung, wie es in Anspruch 5 definiert ist, umfaßt die folgenden Schritte: Eröffnen eines Dialoges zwischen dem Fernrechner und dem lokalen Rechner und Zuordnen einer Anweisung zur Darstellung einer Transaktionsverarbeitungsumgebung, in der die Ferntask ausgeführt werden soll; Senden eines Funktionsnamens, der eine Ferntask kennzeichnet, die in der Transaktionsverarbeitungsumgebung ausgeführt werden soll, und eines ersten Datenblockes, der die von der Ferntask vom lokalen Rechner als Eingabe an den Fernrechner geforderten Daten enthält; am lokalen Rechner Empfangen eines zweiten Datenblockes, der die Ausgabe aus der Ferntask enthält, die am Fernrechner ausgeführt würde; und Schließen des Dialoges zwischen dem Fernrechner und dem lokalen Rechner.
In einer Ausführungsform des Verfahrens der Erfindung wird der Dialog zwischen dem lokalen Rechner und dem Fernrechner durch eine erste der lokalen Tasks eröffnet, und eine zweite der lokalen Tasks sendet den Namen der Ferntask an die Transaktionsverarbeitungsumgebung und vom lokalen Rechner einen ersten Datenblock an den Fernrechner, indem die Anweisung benutzt wird, die durch die erste der Tasks zurückgeschickt wurde.
In einer anderen Ausführungsform des Verfahrens der Erfindung wird der Dialog zwischen dem lokalen Rechner und dem Fernrechner durch eine erste der lokalen Tasks eröffnet, und der Dialog zwischen dem lokalen Rechner und dem Fernrechner wird durch eine dritte der lokalen Tasks geschlossen, wobei die von der ersten der Tasks zurückgeschickte Anweisung benutzt wird.

Beschreibung der Figuren

Fig. 1
zeigt einen Überblick eines Informationsverarbeitungssystems
Fig. 2
zeigt eine intelligente Arbeitsstation
Fig. 3
zeigt einen Überblick eines SNA-Netzwerkes
Fig. 4
zeigt einen Überblick der aktuellen Erfindung
Fig. 5
zeigt die Struktur der Benutzerarbeitseinheit zur Datenübertragung
Fig. 6
zeigt die Struktur des Datenzwischenspeichers für die Routine BusOpenUICXmit
Fig. 7
zeigt die Struktur des Datenzwischenspeichers für die Routine Bus CloseUICXmit
Fig. 8
zeigt die Struktur des Datenzwischenspeichers für die Routine BusUICXmit
Fig. 9
zeigt ein Beispiel des Einsatzes der Erfindung
Fig. 10
zeigt ein weiteres Beispiel des Einsatzes der Erfindung

Ausführliche Beschreibung der Erfindung

Fig. 1 veranschaulicht ein Beispiel eines Informationsverarbeitungssystems, das ein Netzwerk 30, wie etwa ein SNA-Netzwerk, eines Hauptrechners 20 und Datenstationen vom Dialogtyp oder intelligente Arbeitsstationen (IWS) 10a bis 10f von einem Typ umfaßt, wie er ausführlicher in Fig. 2 gezeigt wird. Funktional arbeitet das System so, daß es jeder Arbeitsstation 10 gestattet, mit dem Hauptrechner 20 und über das Netzwerk 30 mit den anderen Arbeitsstationen 10 zu kommunizieren. Für die Übertragungsverbindungsstrecke kann jedes beliebige der verschiedenen Protokolle benutzt werden, in der bevorzugten Ausführungsform der Erfindung wird jedoch das SNA-Übertragungsprotokoll verwendet.
Der Hauptrechner 20 enthält eine Hauptrechnerverarbeitungseinheit, die beispielsweise ein IBM /370-, ein IBM /390-System, ein IBM PS/2, ein IBM AS/400 oder ein IBM RS/6000 sein kann. An der Hauptrechnerverarbeitungseinheit läuft ein Betriebssystem, wie etwa IBM VM, IBM MVS, IBM OS/2 oder IBM VSE.
Fig. 2 veranschaulicht die funktionellen Komponenten einer der Arbeitsstationen 10, wie sie in Fig. 1 gezeigt werden. Die Arbeitsstation 10 umfaßt eine Verarbeitungseinheit 110, die einen Mikroprozessor 130 enthält, der beispielsweise ein Intel 80386 Mikroprozessor ist, einen Halbleiterspeicher 120, einen Steuerblock 140, der dazu dient, zusätzlich zum Dialog zwischen dem Mikroprozessor 130 und dem Speicher 120 Eingabe-Ausgabe- Vorgänge zu steuern.
Die Arbeitsstation enthält weiterhin eine Gruppe von konventionellen peripheren Einheiten, die eine Anzeigeeinrichtung 150, Maus 165, Tastatur 160, Drucker 170, eine Speichereinheit 190 und Modem 180 enthält. Da die Einzelheiten der vorstehend beschriebenen funktionellen Blöcke als Stand der Technik zu finden sind, wird nur eine kurze funktionelle Beschreibung jedes Blockes zusammen mit der Beschreibung ihrer Wechselwirkung angeführt, was ausreichend ist, einer über einschlägiges Fachwissen verfügenden Person das grundlegende Verständnis der Erfindung des Anmelders zu vermitteln.
Verarbeitungseinheit 110 entspricht beispielsweise der Systemeinheit eines IBM Arbeitsplatzrechners, wie etwa dem System PS/2 Modell 80 von IBM. Verarbeitungseinheit 110 ist mit einem Betriebssystemprogramm versehen, welches des Multitasking- Betriebssystem OS/2 von IBM sein kann, das normalerweise zum Betrieb der PS/2 Modell 80 benutzt wird. Das Betriebssystemprogramm wird zusammen mit den Anwendungsprogrammen, die der Benutzer zur Durchführung ausgewählt hat, in Speicher 120 gespeichert. Wenn das System ein verteiltes Anwendungsprogramm unterstützt, wird nur ein Teil, z.B. Teil A, des verteilten Anwendungsprogramms in der Arbeitsstation 10 gespeichert, während der andere Teil, Teil B, im Hauptrechner 20 oder in einer anderen Arbeitsstation 10 gespeichert wird. In Abhängigkeit von der Kapazität des Speichers 120 und der Größe des Anwendungsprogrammes können je nach Notwendigkeit Teile dieser Programme aus der Speichereinheit 190, die beispielsweise ein 40-Megabyte- Festplattenlaufwerk und ein Diskettenlaufwerk enthalten kann, an Speicher 120 übertragen. Die grundlegende Funktion von Speichereinheit 190 besteht im Speichern von Programmen und Daten, die von der Arbeitsstation 10 verwendet werden und die im Bedarfsfall einfach an die Speichereinheit 120 übertragen werden können. Die Funktion des Diskettenlaufwerkes besteht darin, eine auswechselbare Speicherfunktion zur Eingabe von Programmen und Daten in die Arbeitsstation 10 und ein Hilfsmittel zum Speichern von Daten in einer Form bereitzustellen, die zur Verwendung in anderen Arbeitsstationen 10 oder dem Hauptrechner 20 einfach zu transportieren ist.
Anzeigeeinrichtung 150, Maus 165 und Tastatur 160 sorgen zusammen für das Dialogverhalten der Datenstation, und zwar so, daß im normalen Betrieb die Übersetzung, die das System einem bestimmten Mausbefehlstastenanschlag durch den Bediener gibt, in im wesentlichen allen Situationen davon abhängt, was dem Bediener an diesem Punkt gleichzeitig angezeigt wird.
In einigen Situationen veranlaßt der Bediener durch Anklicken mit der Maus 165 oder durch Eingabe von Befehlen in das System, das System zum Ausführen einer bestimmten Funktion. In anderen Situationen fordert das System die Eingabe von bestimmten Daten allgemein durch Anzeigen eines Menü/Nachrichtenbildschirms mit Eingabeaufforderung. Die Tiefe der Interaktion zwischen dem Bediener und dem System unterscheidet sich je nach der Art des Betriebssystems und Anwendungsprogrammes.
Die in Fig. 2 gezeigte Arbeitsstation kann auch einen Drucker 170 enthalten, der so funktioniert, daß er gedruckte Maschinenausgaben von Daten bereitstellt. Letztlich dient der Modem 180 dazu, Daten von der Arbeitsstation 10 von Fig. 2 an einen Hauptrechner 20 oder andere Arbeitsstationen 10 zu übertragen.
Fig. 3 zeigt die verschiedenen Programmierebenen, die in einem Netzwerk vom SNA-Typ benutzt werden. Die SNA- Programmierumgebung gemäß der vorliegenden Erfindung kann so betrachtet werden, daß sie wie gezeigt aus sieben Ebenen besteht. Die oberste Ebene 210 ist die Endbenutzerebene und besteht aus den Endbenutzerprogrammen und enthält die Datenfernübertragungsdienste 220 der vorliegenden Erfindung.
Die zweite Ebene 230 wird als Dienstfunktionen für adressierbare Netzwerkelemente bezeichnet. Diese Dienste enthalten beispielsweise Darstellungsdienste, Datenstationsdienste und Formatierdaten für spezielle Anwendungen. Ebene 240 wird als Datenflußsteuerung bezeichnet. Ihre Funktion besteht darin, Sende-/Empfangsmodi zu pflegen und leistungsfähige Fehlerkorrekturen auszuführen. Ebene 250 ist die Ebene der Datenübertragungssteuerung. Ihre Funktion betrifft solche Dinge wie Verschlüsselung und Entschlüsselung plus Sitzungsebenendosierung. Ebene 260 ist die Pfadsteuerung, die das Weiterleiten, das Segmentieren von Dateneinheiten und die Nachrichtenmengendosierung am virtuellen Leitweg erledigt. Die Datenverbindungsebene ist die Ebene 270. Sie funktioniert so, daß sie Übertragungsebenen adressiert, Reihenfolgen aufstellt und die Fehlersteuerung erledigt. Die letzte Ebene 280 ist die physische Ebene, welche beispielsweise die Stiftbelegung an Anschlüssen für die verschiedenen Signale definiert.
APPC definiert die Dienstfunktionen für adressierbare Netzwerkelemente, Datenflußsteuerung und Übertragungssteuerung. Wie auf Seite 306 des vorstehend als Quelle angegebenen IBM Systems Journal erklärt, besteht das Verfahren des Definierens der LU6.2-Dialogfunktionen aus Ausdrücken von programmiersprachenähnlichen Anweisungen, die als Verben bezeichnet werden. Dokumentation mit Verben, die vollständig durch die Verarbeitungslogik definiert werden, welche die Sitzungsabläufe erzeugt, bietet eine wesentlich höhere Genauigkeit als englischer Klartext. Eine Gruppe von Verben wird als Protokollgrenze statt als Schnittstelle des Anwendungsprogrammes bezeichnet.
Die Darstellungsdienstekomponente übersetzt Verben und ist so gedacht, daß sie für jedes Verb ein Unterprogramm enthält. Der LU-Betriebsmittelverwalter erledigt das Zuordnen von Dialogbetriebsmitteln und die Zuteilung von Dialogen zu den Sitzungen, indem er Warteschlangen von freien Sitzungen und anstehenden Zuordnungsanforderungen vorhält. Seine gleichwertige Komponente in Produkten ordnet ebenfalls auf produktspezifische Weise lokale Betriebsmittel zu. Die Funktion der folgenden LU6.2-Verben wird auf Seite 307 des vorstehend erwähnten IBM System Journal erläutert. Die erläuterten LU6.2-Verben sind: SEND_DATA, RECEIVE_AND_WAIT, PREPARE_TO_RECEIVE, FLUSH, REQUEST_TO_SEND, SEND_ERROR, CONFIRM, ALLOCATE AND DEALLOCATE.
Das Verb ALLOCATE initialisiert neue Aktivität an einer anderen LU, indem mit einem benannten Partnerprogramm ein Dialog aufgebaut wird. Der benannte Partner wird zur Ausführung gebracht und für den Dialog adressierbar gemacht, der ihn gestartet hat. Das Verb ALLOCATE transportiert mehrere Parameter einschließlich der folgenden.

1.

LU_NAME. Dies ist der Name der LU, an der sich das Partnerprogramm befindet.

2.

TPN. TPN ist der Transanktionsprogrammname des Partnerprogrammes, mit dem der Dialog gewünscht wird.

3.

MODE_NAME. MODE_NAME gibt die Art des Transportdienstes vor, den der Dialog bereitstellen soll. Beispielsweise kann ein SECURE-, ein BULK- oder ein LOW_DELAY-Dialog angefordert werden. Die LU benutzt eine Sitzung mit dem geeigneten MODE_NAME, um den Dialog zu führen.
Das Ziel des Dialoges ist eine neu erzeugte Verarbeitung oder Task, was bedeutet, daß die verteilte Verarbeitung in dem Netzwerk zu jedem Zeitpunkt aus einer Anzahl von unabhängig verteilten Transaktionen besteht, von denen jede aus zwei oder mehr Transaktionsprogrammen besteht, die durch einen Dialog verbunden sind. Das Verb DEALLOCATE beendet den Dialog. In dem Maße, wie jeder Partner DEALLOCATE ausgeben kann, variiert ein Dialog zwischen einer einzelnen kurzen Nachricht und vielen Austauschvorgängen von kurzen oder langen Nachrichten. Ein Dialog könnte unendlich fortgesetzt werden, wobei er nur durch das Versagen einer logischen Einheit oder durch die Sitzung, die ihn führt, beendet werden könnte. Transaktionsprogramme werden durch DEALLOCATE nicht beendet, sondern laufen weiter-, bis sie ihre eigene Ausführung beenden, ein fehlerhaftes Programmende haben oder durch eine Steueraktion des Bedieners beendet werden.
Sowohl Netzwerkanwendungsprogramme als auch Diensttransaktionsprogramme benutzen die von logischen Einheiten bereitgestellten Ausführungsdienste. Diensttransaktionsprogramme laufen an logischen Einheiten auf die gleiche Weise wie andere Transaktionsprogramme. Sie befinden sich im Dialog mit dem menschlichen Bediener, oder sie können als reiner programmierter Bediener laufen. Viele Diensttransaktionsprogramme betreffen nur die lokale logische Einheit. Ein Beispiel ist ein Befehl, die aktuelle Gruppe von aktiven Transaktionsprogrammen anzuzeigen.
Andere Steuertransaktionen, insbesondere solche, die sich auf Sitzungen beziehen, können andere logische Einheiten ebenso wie Anwendungen an anderen logischen Einheiten betreffen. Beispielsweise verursacht ein lokaler Befehl, eine Transaktion vorzeitig zu beenden, die einen Dialog verwendet, daß der Dialog fehlerhaft beendet wird, eine Statusveränderung, die an die logische Partnereinheit zur Vorlage an das Transaktionsprogramm übertragen werden muß, das den Dialog gemeinsam nutzt. Oder eine Entscheidung, eine oder mehrere der Sitzungen zu aktivieren, die durch die zwei LUs gemeinsam genutzt werden, kann durch den Bediener der einen LU getroffen werden, muß aber an die andere logische Einheit übertragen werden. Erweiterte Übertragung von Programm zu Programm enthält bei SNA mehrere Steuerbedienerverben, die Steuerung und Koordination von LU zu LU bereitstellen, insbesondere zur Aktivierung und Deaktivierung von Sitzungen. Wenn ein verteiltes Diensttransaktionsprogramm an einer LU beginnt, erzeugt es einen Dialog mit einem Partnertransaktionsprogramm in einer Partner-LU. Die beiden Transaktionsprogramme kooperieren dann, um die gewünschte Steueraktivität durchzuführen.
Fig. 4 zeigt, wie die Datenfernübertragungsdienste der vorliegenden Erfindung arbeiten. Jede der Arbeitsstationen 10a bis f und der Hauptrechner 20 sind mit einer speziellen Komponente ausgerüstet, die als Benutzerarbeitseinheit zur Datenübertragung bezeichnet wird. In dem in Fig. 4 beschriebenen Beispiel werden zwei Arten von Benutzerarbeitseinheiten zur Datenübertragung gezeigt. In einem lokalen Rechner (oder einer logischen Einheit) 400 wird eine lokale Benutzerarbeitseinheit zur Datenübertragung 410 bereitgestellt, normalerweise eine Arbeitsstation 10, die eine Task ausführt. Eine Benutzerarbeitseinheit zur Datenfernübertragung 420 wird in einem Fernrechner (oder einer anderen logischen Einheit) 405 zur Verfügung gestellt, die entweder eine andere Arbeitsstation 10 oder der Hauptrechner 20 sein kann. Der Fernrechner 405 führt eine Task aus, die durch die Task eingeleitet sein könnte, die an dem lokalen Rechner 400 läuft. Die lokale Benutzerarbeitseinheit zur Datenübertragung 410 und die Benutzerarbeitseinheit zur Datenfernübertragung 420 werden durch ein Netzwerk 30 verbunden.
In dem gezeigten Beispiel werden drei Arten von Tasks, die gemeinsam als Anforderer von Datenübertragungsdienst 415 bekannt sind, am lokalen Rechner 400 bereitgestellt, der Tasks am Fernrechner 405 aufrufen kann. Diese sind Funktionsprogramme 440, Anwendungsnavigatoren 450 und Umgebungsroutinen 460. Funktionsprogramme 440 sind Programme, die für die auszuführende Anwendung wichtige Daten modifizieren können. Anwendungsnavigatoren 450 gestatten es dem Benutzer, durch die an der Arbeitsstation 10 und dem Hauptrechner 20 verfügbaren Anwendungen zu navigieren. Umgebungsroutinen 460 gestatten es dem Benutzer, die Umgebung zu modifizieren, in der er oder sie arbeiten. Jede dieser Tasks kann Aufrufe an Tasks vornehmen, die am Fernrechner 405 laufen, und kann Datenblöcke zu und/oder von diesen Tasks am Fernrechner 405 senden und/oder empfangen.
Der Fernrechner 405 hat in der beschriebenen Ausführungsform der Erfindung nur eine Art von Task. Die Fernfunktion 430 ist ein aufrufbares Modul, das durch eine Task aufgerufen werden kann, die am lokalen Rechner 400 abläuft, und das einen Datenblock von und/oder zu den Tasks auf dem lokalen Rechner 400 empfangen und/oder zurückschicken kann.
Die lokale Benutzerarbeitseinheit zur Datenübertragung 410 ist mit den Anforderern von Datenübertragungsdienst 415 verbunden. Ihre Funktion besteht darin, dem Fernsystem 405 einen Dialog zuzuordnen, einen Datenblock und einen Funktionsnamen an die Benutzerarbeitseinheit zur Datenfernübertragung 410 des Fernsystems 405 zu senden und von der Benutzerarbeitseinheit zur Datenfernübertragung 420 oder dem Fernsystem 405 einen Datenblock zu empfangen und schließlich die Zuordnung eines Dialoges zum Fernsystem 405 aufzuheben.
Die Benutzerarbeitseinheit zur Datenfernübertragung 420 hat die Fähigkeit, einen Datenblock und den Namen einer Fernfunktion von der lokalen Benutzerarbeitseinheit zur Datenübertragung 410 zu empfangen, die vorgegebene Fernfunktion 430 zu starten, den empfangenen Datenblock an die Fernfunktion 430 zu senden und den durch die vorgegebene Fernfunktion 430 zurückgeschickten Datenblock an die lokale Benutzerarbeitseinheit zur Datenübertragung 410 zurückzusenden, die den Namen der Fernfunktion 430 geschickt hatte.
Die Funktion der Benutzerarbeitseinheiten zur Datenübertragung 410 und 420 ist besser zu verstehen, wenn Fig. 5 betrachtet wird. Fig. 5 zeigt die Anforderer von Datenübertragungsdienst 415, die mit einer Reihe von Diensteinheiten 500 verbunden sind. Die Reihe von Diensteinheiten 500 ist ihrerseits mit einer Steuerung 505 verbunden. Die Steuerung 505 ist mit einer Reihe von Zielverarbeitungsumgebungen 510a bis d verbunden. Jede der Zielverarbeitungsumgebungen 510a bis d umfaßt jede einen Klienten 520a bis d und einen Server 530a bis d. Die Steuerung 505, die Reihe der Diensteinheiten 500 und die Klienten 520a bis d sind in der lokalen Benutzerarbeitseinheit zur Datenübertragung 410 von Fig. 4 enthalten. Die Server 530a bis b befinden sich in einem oder mehreren der in Fig. 4 gezeigten Fernrechner 405. Die Klienten 520a bis d und Server 530a bis d sind über das Netzwerk 30 und Modems 180 miteinander verbunden.
Eine an dem lokalen Rechner 400 laufende Anwendung kann vom Fernrechner 405 einen oder mehrere Dienste anfordern. Die Dienste werden dadurch angefordert, daß Anforderer für Datenübertragungsdienst 415 aufgerufen werden, die für jeden angeforderten Dienst eine Diensteinheit 500 erzeugen. Die Steuerung 505 schickt die von der Anwendung herausgegebenen verschiedenen Dienstanforderungen an die angeforderte Zielverarbeitungsumgebung 510. Die Steuerung 505 benutzt eine von der im lokalen Rechner laufenden Anwendung zur Verfügung gestellte Zeichenfolge, um die erforderliche Zielverarbeitungsumgebung 510 vorzugeben. Nach Abschluß des angeforderten Dienstes in der Zielverarbeitungsumgebung 510 wird das Ergebnis über die Steuerung 505 und die Diensteinheit 500 an die Anwendung zurückgeschickt.
Die Zielverarbeitungsumgebung 510 kann durch mehr als eine Diensteinheit 500 adressiert werden. Dies würde beispielsweise bedeuten, daß zwei Anwendungen, die am lokalen Rechner 400 laufen, beide den gleichen Dienst im Fernrechner 405 benutzen möchten oder daß zwei unterschiedliche Teile der gleichen Anwendung, die im lokalen Rechner 400 läuft, den gleichen Dienst benutzen möchten. In diesem Falle können im lokalen Rechner 400 zwei verschiedene Diensteinheiten 500 erzeugt werden. Die Dienstanforderungen werden in der Zielverarbeitungsumgebung 510 in eine Warteschlange eingereiht und werden nacheinander ausgeführt. Ein einzelnes Anwendungsprogramm kann ebenfalls asynchron mit zwei verschiedenen Zielverarbeitungsumgebungen 510 einen Dialog führen, indem zwei verschiedene Diensteinheiten 500 erzeugt werden.
Die Klienten 520 und Server 530 kommunizieren miteinander unter Verwendung dreier Elementarfunktionen: SRV_OPEN, SRV_CLOSE und SRV_RPC. Ehe eine Zielverarbeitungsumgebung 510 aufgerufen wird, muß die Elementarfunktion SRV_OPEN benutzt werden. Dies veranlaßt die Steuerung dazu, einen Klienten 520 zu erzeugen und unter Verwendung bekannter SNA-Verben (ALLOCATE, siehe vorstehend) und der vorstehend erwähnten Zeichenfolge am gewünschten Fernrechner 405 einen Dialog mit dem Server 530 einzurichten, in dem die Fernfunktion 430 ausgeführt werden soll. An die Steuerung 505 wird eine Anweisung zurückgeschickt, die den Dialog kennzeichnet. Das Aufrufen der Elementarfunktion SRV_CLOSE führt dazu, daß der Dialog zwischen dem Klienten 520 und Server 530 unterbrochen und die Anweisung gelöscht wird. Die Elementarfunktion SRV_CLOSE benutzt das SNA-Verb DEALLOCATE. Die Elementarfunktionen SRV_CLOSE und SRV_OPEN werden durch irgendeinen der Anforderer von Datenübertragungsdienst 415 aufgerufen. Diese können tatsächlich durch unterschiedliche Anforderer von Datenübertragungsdienst 415 herausgegeben werden, d.h., eine Verbindung kann durch einen Anforderer von Datenübertragungsdienst 415 eingerichtet und durch einen anderen Anforderer von Datenübertragungsdienst 415 unterbrochen werden. Die Verbindung zwischen dem Klienten 520 und Server 530 bleibt immer solange offen, bis sie geschlossen wird, sogar dann, wenn der Anforderer von Datenübertragungsdienst 415, der den Dialog eingerichtet hat, den Dialog wie nachstehend beschrieben nicht mehr benutzt.
Die Elementarfunktion SRV_RPC wird durch einen Anforderer von Datenübertragungsdienst 415 unter Verwendung der Anweisung aufgerufen und gestattet, daß eine willkürliche Länge von Daten vom Klienten 520 an den Server 530 und umgekehrt übertragen wird. Unter Verwendung der Elementarfunktion SRV_RPC veranlaßt ein Anwendungsprogramm, daß durch den Anforderer von Datenübertragungsdient 415 eine Diensteinheit 500 erzeugt wird. Durch unterschiedliche Anwendungen können unterschiedliche Diensteinheiten 500 erzeugt werden. Sollten zwei unterschiedliche Diensteinheiten 500 den Wunsch haben, gleichzeitig Daten an die Zielverarbeitungsumgebung 510 zu übertragen, werden die Anforderungen in den Diensteinheiten 500 in einer Warteschlange untergebracht.
Nimmt man an, daß ein Anwendungsprogramm, das am lokalen Rechner 400 läuft, eine Task aufrufen möchte (z.B. eine Fernfunktion 430), die am Fernrechner 405 läuft, dann muß ein Dialog zwischen dem lokalen Rechner 400 und dem Fernrechner 405 eingerichtet werden. Um dies zu bewerkstelligen, ruft der Anforderer von Datenübertragungsdienst 415, der die Task ausführt, eine Routine BusOpenUICXmit (OpendataStruct, r'c) auf, die durch die lokale Benutzerarbeitseinheit zur Datenübertragung 410 bereitgestellt wird. Diese Routine ist der vorstehend beschriebenen Elementarfunktion SRV_OPEN gleichwertig. Die Routine hat zwei Parameter, OpenDataStruct und rc. Der erste Parameter, OpenDataStruct, zeigt auf einen Datenzwischenspeicher, der alle Eingabe- und Ausgabedaten enthält, die notwendig sind, um den Dialog mit der Benutzerarbeitseinheit zur Datenfernübertragung 420 im Fernrechner 410 zu eröffnen. Der zweite Parameter, rc, ist der Rückmeldecode vom Aufruf dieser Routine; Er wird entweder anzeigen, daß der Dialog eingerichtet worden ist oder daß ein Problem aufgetreten ist, und wird möglicherweise eine Anzeige der Art des Problems geben.
Die Struktur des Datenzwischenspeichers wird in Fig. 6 gezeigt. SymDest bezieht sich auf den symbolischen Zielnamen, der den Fernrechner 405 mit dem Server 530 kennzeichnet, an dem die Fernfunktion 430 abläuft. Der symbolische Zielname wird den SNA-Netzwerkdiensten von IBM während der Installation und Kundenanpassung zur Verfügung gestellt. Er entspricht dem LU_NAME_, dem TPN_ und dem MODE_NAME-Parameter des Verbs ALLOCATE. Die Benutzer-ID ist für den Fernrechner die Anmelde- Benutzer-ID, und PassWd ist das Anmelde-Paßwort. Diese beiden Werte könnten null sein, wenn ein vorgegebenes Paßwort benutzt wird, das während des Kundenanpassungsvorganges definiert wurde. TimeoutValue ist ein Wert, der vorgibt, wie lange darauf gewartet wird, daß ein Dialog zwischen dem lokalen System 400 und dem Fernsystem 405 eingerichtet wird, ehe ein fehlerhafter Rückmeldecode rc zurückgeschickt wird. XmitHandle ist die Anweisung, die zurückgeschickt wird, um diesen Dialog darzustellen. Sie wird in allen nachfolgenden Datenübertragungen an die Fernfunktion 430 und auch zum Schließen des Dialoges verwendet. Abschließend enthält RemoteSys die Anzeige für die Art des Betriebssysstems. Diese Information ermöglicht es dem Aufrufer festzustellen, ob das Fernsystem den ASCII-, EBCDIC- oder andere Zeichenvorräte benutzt.
Das Schließen des Dialoges zwischen dem lokalen Rechner 400 und dem Fernrechner 405 erfolgt durch die Anforderer von Datenübertragungsdienst 415, indem die Routine BusCloseUICXmit (CloseDataStruct, rc) aufgerufen wird. Diese Routine ist der vorstehend beschriebenen Routine SRV-CLOSE gleichwertig. Der erste Parameter, CloseDataStruct, zeigt auf einen Datenzwischenspeicher, der alle Eingabe- und Ausgabedaten enthält, die für das Schließen des Dialoges zwischen der Benutzerarbeitseinheit zur Datenfernübertragung 420 im Fernrechner 410 notwendig sind. Der zweite Parameter, rc, ist der Rückmeldecode vom Aufruf dieser Routine. Er wird entweder anzeigen, daß der Dialog geschlossen wurde oder daß ein Problem aufgetreten ist, und wird möglicherweise eine Anzeige für die Art des Problems geben.
Die Struktur des Datenzwischenspeichers ist in Fig. 7 gezeigt. XmitHandle ist die Anweisung, die zur Darstellung des Dialoges verwendet wird. CloseParm ist eine Markierung zur Aufhebung der Zuordnung, die einen von zwei Werten enthalten kann. Ein Wert zeigt an, daß der Dialog sofort geschlossen werden soll, sogar dann, wenn von anderen Anforderern von Datenübertragungsdienst 415 Anforderungen anstehen und sich in den Diensteinheiten 500 in einer Warteschlange befinden. Unter Verwendung dieses Wertes wird ein fehlerhafter Rückmeldecode rc zurückgeschickt. Der zweite Wert zeigt an, daß der Dialog nur geschlossen wird, wenn keine weiteren Dienstanforderungen an den Diensteinheiten 500 anstehen. Falls notwendig, wird der Schließbefehl selbst in die Warteschlange eingereiht und verarbeitet, nachdem alle Dienstanforderungen in den Diensteinheiten 500 verarbeitet worden sind. Jegliche später ausgegebenen Anforderungen an die Fernfunktion 430 werden zurückgewiesen, und ein fehlerhafter Rückmeldecode wird zurückgeschickt.
Wenn der Dialog zwischen dem lokalen Rechner 400 und dem Fernrechner 405 eröffnet worden ist, können die Anforderer von Datenübertragungsdienst 415 von den Fernfunktionen 430 Gebrauch machen. Dies erfolgt durch Aufrufen der Routine BusUICXmit (XmitDataStuct, rc) . Diese Routine ist der vorstehend beschriebenen Routine SRV_RPC gleichwertig. Der erste Parameter, Xmit-DataStruct, zeigt auf einen Datenzwischenspeicher, der alle Eingabe- und Ausgabedaten enthält, die zur Übertragung von Daten von den Datendienstanforderern 415 zu den Fernfunktionen 430 erforderlich sind. Der zweite Parameter, rc, ist der Rückmeldecode vom Aufruf dieser Routine. Er wird entweder anzeigen, daß der Dialog eingerichtet worden ist oder daß ein Problem aufgetreten ist, und wird möglicherweise eine Anzeige der Art des Problems geben.
Fig. 8 zeigt die Struktur des Datenzwischenspeichers. XmitHandle ist die Anweisung, die den zu benutzenden Dialog anzeigt. XmitLib ist der Name der Bibliothek, in der die Fernfunktion 430 im Server 530 gefunden werden soll. Bei einigen Betriebssystemen, z.B. CMS oder MVS, ist dieser Wert nicht erforderlich. In OS/2 verweist er auf eine dynamische Verkettungsbibliothek. XmitServ ist der Name der Fernfunktion 430, die am Fernrechner 405 aufgerufen werden soll. InputBuf ist die Adresse des gemeinsam genutzten Speicherblockes, der die Daten enthält, die durch die Anforderer von Datenübertragungsdienst 415 zur Übertragung an die Fernfunktion 430 bereitgestellt werden. Auf sie muß sowohl durch den Anforderer von Datenübertragungsdienst 415 wie durch die Klienten 520 zugegriffen werden können. Die InputBufLen ist die Länge des durch InputBuf vorgegebenen Datenblockes. OutputBuf ist die Adresse des gemeinsam genutzten Speicherblockes, der die Daten enthält, die vom Anforderer von Datenübertragungsdienst 415 verwendet werden, die von der Fernfunktion 430 zurückgeschickt wird. Auf sie muß ebenfalls sowohl durch die Anforderer von Datenübertragungsdienst 415 als auch die Klienten 520 zugegriffen werden können. OutputBufLen ist die Länge des durch OutputBuf vorgegebenen Datenblockes. XmitServLinkage enthält die Verknüpfungsinformation für XmitServ.
Die TimeoutValue gibt die Länge der Zeit vor, die eine nicht in einer Warteschlange befindliche Anforderung auf Antwort vom Fernrechner 405 warten kann, ehe ein fehlerhafter Rückmeldecode rc an den Anforderer von Datenübertragungsdienst 415 zurückgeschickt wird. Als Folge des Zurückschickens eines fehlerhaften Rückmeldecodes rc werden alle folgenden BusUICXmit-Dienstaufrufe, die sich für diesen speziellen Dialog in den Diensteinheiten 500 in einer Warteschlange befinden, beendet und werden einen fehlerhaften Rückmeldecode rc zurückschicken, und der Dialog wird geschlossen werden. Abschließend ist XmitServRC der Rückmeldecode der Fernfunktion 430, der durch den Abschluß der am Fernsystem 405 laufenden Fernfunktion 430 an die Benutzerarbeitseinheit zur Datenfernübertragung 420 zurückgeschickt wird.
Wenn der Anforderer von Datenübertragungsdienst 415 die Routine BusUICXmit (XmitDataStuct, rc) aufruft, wird der Aufruf an die lokale Benutzerarbeitseinheit zur Datenübertragung 410 geschickt. Diese greift auf den gemeinsam genutzten Eingabezwischenspeicher zu und schickt die darin enthaltenen Daten an die Benutzerarbeitseinheit zur Datenfernübertragung 420. Diese Übertragung erfolgt unter Verwendung der bekannten SNA oder anderer Datenübertragungsverfahren. An der Benutzerarbeitseinheit für Datenfernübertragung 420 werden die ankommenden Daten an einen weiteren gemeinsam genutzten Speicher und eine andere aufgerufene Routine XmitServ (InputBufAdr, InputBufLen, Output-BufAdr, OutputBufLen, rc) geschickt. Die InputBufAdr ist die Adresse des gemeinsam genutzten Datenblockes, der durch die Benutzerarbeitseinheit zur Datenfernübertragung 420 bereitgestellt wird, wobei durch die Fernfunktion 430 geforderte Eingabedaten bereitgestellt werden. Dieser Datenblock enthält genau die Information, die von der lokalen Benutzerarbeitseinheit zur Datenübertragung 410 durch Aufrufen von BusUICXmit geschickt werden. In einer Ausführungsform der Erfindung wird dieser Datenblock als ein binärer Bytestrom erkannt, und es wird keine ASCII/EBCDIC-Umwandlung vorgenommen. In einer anderen Ausführungsform wird die Umwandlung vorgenommen. Die InputBufLen ist die Länge des durch InputBufAdr vorgegebenen Datenblockes. Die OutputBufAdr ist die Adresse eines gemeinsam genutzten Ausgabezwischenspeichers, der einen Datenblock enthält, der von der Benutzerarbeitseinheit zur Datenfernübertragung bereitgestellt wird, wobei die Fernfunktion 430 ihre Daten zurückschicken muß. Dieser Datenblock enthält genau die Information, die nach dem Abschluß des BusUICXmit-Aufrufes an die lokale Benutzerarbeitseinheit zur Datenübertragung 410 geschickt wird. Bei Eingabe speichert OutputBufLen die Länge des Ausgabedatenblockes, der durch den Aufrufer an den lokalen Rechner 400 übergeben und durch OutputBufAdr vorgegeben wird. Bei Ausgabe muß die Fernfunktion 430, die von der Benutzerarbeitseinheit zur Datenfernübertragung 420 aufgerufen wurde, die Länge des über OutputBufAdr tatsächlich zurückgeschickten Datenblockes im Parameter OutputBufLen speichern, falls der gemeinsam genutzte Ausgabezwischenspeicher groß genug ist, um die Daten festzuhalten. Falls der gemeinsam genutzte Ausgabezwischenspeicher nicht groß genug ist, um den durch die Fernfunktion 430 tatsächlich erzeugten Datenblock zu speichern, muß dieses Überlaufen dem Anforderer von Datenübertragungsdienst 415 signalisiert werden. Dies kann beispielsweise dadurch erfolgen, daß ein geeigneter Rückmeldecode rc erzeugt wird und daß in OutputBufLen die Länge gespeichert wird, die zum Festhalten der kompletten Daten erforderlich ist. Dieser Wert wird als OutputBufLen des BusUICXmit-Aufrufes an den Anforderer von Datenübertragungsdienst 415 zurückgeschickt. Der Anforderer von Datenübertragungsdienst 415 wird auch so viel wie möglich vom Ausgabedatenblock empfangen, d.h. die Byteanzahl, wie sie durch den Eingabewert von Output-BufLen vorgegeben ist. Der Anforderer von Datenübertragungsdienst 415 wird dann Korrekturvorgänge durchführen. Der Rückmeldecode rc für die XmitServ-Routine wird als XmitServRC- Parameter der BusUICXmit-Routine an den Anforderer von Datenübertragungsdienst 415 zurückgeschickt.
Um die Benutzerarbeitseinheit zur Datenfernübertragung 420 in die Lage zu versetzen, dynamisch die durch den Parameter XmitServ des Aufrufes BusUICXmit vorgegebenen Fernfunktionen 420 zu laden, zu verknüpfen und auszuführen, müssen die Fernfunktionen dann auf dem Fernrechner 405 entsprechend organisiert werden. Die Fernfunktionen 420 müssen, betriebssystemunabhängig ausgedrückt, Elemente von "dynamisch verknüpfbaren" Bibliotheken sein. Der Parameter XmitLib des Aufrufes--BusUICXmit gibt genau die Bibliothek vor, aus der die Fernfunktion 430 dynamisch verknüpft werden kann.
In MVS hat der Parameter XmitLib keine Bedeutung, da angenommen wird, daß die Fernfunktion 430 Glied einer LOAD-Bibliothek ist, die durch die bekannten MVS-Verfahren (Linklib, LPA, STEPLIB usw.) verkettet ist. Die Benutzerarbeitseinheit zur Datenfernübertragung 420 benutzt den Parameter XmitServ entweder dafür, die durch XmitServ vorgegebene Fernfunktion 430 zu laden, um ihren Einstiegspunkt zu erreichen, oder indem er die durch XmitServ vorgegebene Fernfunktion 430 aufruft.
In VM hat der Parameter XmitLib keine Bedeutung, da angenommen wird, daß die Fernfunktion 430 Glied einer LOAD-Bibliothek ist, auf die mit bekannten VM-Verfahren zugegriffen werden kann, d.h. die XmitServ muß in einer der LOADLIBs enthalten sein, auf die mit GLOBAL LOADLIB loadlib_1 loadlib_2 zugegriffen werden kann. Die Bibliotheken werden in der vorgegebenen Reihenfolge durchsucht. Diese Anweisung wird von der PROFILE EXEC der Benutzer-ID herausgegeben, die während der Kundenanpassung entsprechend eingerichtet werden mußte. Die Benutzerarbeitseinheit zur Datenfernübertragung 420 benutzt den Parameter XmitServ entweder zum Laden der durch XmitServ vorgegebenen Fernfunktion 430, um deren Einstiegspunkt zu erreichen, oder indem sie die durch XmitServ vorgegebene Fernfunktion 430 aufruft.
In OS/2 bezieht sich der Parameter XmitLib auf eine dynamische Link-Bibliothek (DDL). Die Benutzerarbeitseinheit zur Datenfernübertragung 420 benutzt die Parameter XmitLib und XmitServ auf folgende Weise. Zuerst lädt die Benutzerarbeitseinheit zur Datenfernübertragung 420 die vom Parameter XmitLib vorgegebene DDL unter Verwendung des bekannten DosLoadModuleCall. Sie gibt dann einen Aufruf DosFetProcAddr nach dem Parameter XmitServ heraus, um einen Einstiegspunkt der Fernfunktion 430 zu erreichen. Abschließend ruft die Benutzerarbeitseinheit zur Datenfernübertragung die Fernfunktion 430 auf.
Zwei Beispiele sollen zur Veranschaulichung dienen, wie der Datenfernübertragungsdienst arbeitet. Zuerst wird angenommen, daß der Benutzer eines lokalen Rechners 400 einen Anwendungsnavigator 450 benutzen möchte. Dieser Anwendungsnavigator 450 kann entweder eine generische Objekt- und Ansichtenbehandlungsroutine oder ein anwendungsspezifischer Anwendungsnavigator sein. Wie vorstehend erwähnt, ist der Anwendungsnavigator 450 ein Beispiel der Anforderer von Datenübertragungsdienst 415. Fig. 9 soll zur Veranschaulichung dieses Beispieles dienen.
Dem Benutzer des lokalen Rechners 400 wird eine Reihe von Nachrichtenübergabestationen 910a bis c vorgestellt, die auf einer Anzeigeeinrichtung 150 angezeigt wird. An der Nachrichtenübergabestation 910 wird eine Reihe von Ikonen dargestellt. Der Benutzer verwendet die Maus 165, um eine der Ikonen anzuklicken, die dann den Anwendungsnavigator 450 aufruft. Der Anwendungsnavigator 450 benutzt einen Benutzerschnittstellenleiter 920, um ein lokales Funktionsprogramm 930a (Schritt < 1> ) aufzurufen. Der Benutzerschnittstellenleiter 920 ruft das Funktionsprogramm 930a auf, das die ausgewählte Aktion darstellt.
Es wird angenommen, daß das lokale Funktionsprogramm 930a eine der Fernfunktionen 430 benutzen muß. Dies erfolgt durch Aufrufen der Routine BusOpenUICXmit der lokalen Benutzerarbeitseinheit zur Datenübertragung 410, um einen Dialog mit dem erforderlichen Fernrechner 405 (Schritt < 2> ) einzurichten. Der erforderliche Fernrechner 405 wird durch den Parameter SymDest auf dem Aufruf BusOpenUICXmit vorgegeben. Die lokale Benutzerarbeitseinheit zur Datenübertragung 410 richtet mit dem Fernrechner 405 einen LU6.2-Dialog ein, indem er im Fernrechner 405 die Benutzerarbeitseinheit zur Datenfernübertragung 420 aufruft. Nach Rückmeldung vom Aufruf BusOpenUICXmit ist ein Dialog mit einer Anweisung XmitHandle eingerichtet worden (Schritt < 3> ), die durch andere lokale Funktionsprogramme 930b und 930c gemeinsam genutzt werden kann, die ebenfalls durch den Anwendungsnavigator 450 aktiviert worden sind. Dieser Vorgang der gemeinsamen Nutzung wird in Fig. 9 nicht widergespiegelt.
Die lokale Funktion 930a ruft nun die Routine BusUICXmit der lokalen Benutzerarbeitseinheit zur Datenübertragung 410 auf, um Daten an die Fernfunktion 430a zu schicken und die Fernfunktion 430a aufzurufen (Schritt < 4> ). Der Name der Fernfunktion 430a und die Daten werden als Parameter des Aufrufes BusUICXmit wie vorstehend beschrieben vorgegeben. Die lokale Benutzerarbeitseinheit zur Datenübertragung 410 schickt diese Daten an die Benutzerarbeitseinheit zur Datenfernübertragung 420 am Fernrechner 405.
Die Benutzerarbeitseinheit zur Datenfernübertragung 420 ruft die Fernfunktion 430a (Schritt < 5> ) auf, und bei Rückmeldung von der Fernfunktion 430a (Schritt < 6> ) schickt sie die Daten vom Fernrechner 405 an den lokalen Rechner 400 zurück. Die Daten werden dann durch die lokale Benutzerarbeitseinheit zur Datenübertragung 410 an die aufrufende lokale Funktion 930a (Schritt < 7> ) zurückgeschickt. Das lokale Funktionsprogramm 930a entscheidet darüber, was mit den binären Daten aus dem Fernrechner 405 erfolgen soll, und auf die, falls vorhanden, andere lokale Funktionsprogramme 930b oder 930c zugreifen können. In diesem Beispiel werden sie dem Anwendungsnavigator 450 über einen gemeinsam genützten Speicherbereich 940 (Schritt < 8> ) zugänglich gemacht.
Der Anwendungsnavigator 450 kann, ausgelöst durch Benutzerinteraktion, andere lokale Funktionsprogramme 930a bis c aufrufen, die andere Fernfunktionen 43db aufrufen können. Da die lokalen Funktionsprogramme 930a bis c wissen, daß schon ein Dialog mit dem Fernrechner 405 besteht, können die Schritte < 4> bis < 7> wiederholt werden. Eine solche Situation wird in Schritten < 9> bis < 13> gezeigt, welche die Ausführung der anderen Fernfunktion 430b durch das lokale Funktionsprogramm 930b aufzeigen.
Abschließend entscheidet der Benutzer über das Ende der Task. Der Anwendungsnavigator 450 ruft das lokale Funktionsprogramm 930c auf, das alle Säuberungsaktivitäten aufruft und die Routine BusCloseUICXmit in der lokalen Benutzerarbeitseinheit zur Datenübertragung 410 aufruft. Diese schließt den Dialog (in Schritten < 14> bis < 16> gezeigt) und löscht alle lokalen Anwendungsdaten.
Das zweite Beispiel für die Benutzung der Datenfernübertragungsdienste wird in Fig. 10 gezeigt. In diesem Beispiel wird der Benutzerschnittstellenleiter 920 nicht benutzt, da der Anwendungsnavigator 450 keinerlei Modifikation der im Fernrechner 405 gespeicherten Daten vornimmt. Ein Beispiel für eine derartige Nutzung könnte die Abfrage einer im Fernrechner 405 gespeicherten Ferndatenbank sein.
Es wird aufgrund einer gewissen Benutzerinteraktion angenommen, daß der Anwendungsnavigator 450 gewisse im Fernrechner 405 gespeicherte Daten abfordert. In Schritt < 21> ruft er daher die Routine BusOpenUICXmit der lokalen Benutzerarbeitseinheit zur Datenübertragung 410 auf, um einen LU6.2-Dialog mit dem erforderlichen Fernrechner 405 dadurch einzurichten, daß er die Benutzerarbeitseinheit zur Datenfernübertragung 420 aufruft. Der erforderliche Fernrechner wird durch den Parameter SymDest im Aufruf BusOpenUICXmit vorgegeben. Nach Rückmeldung von der lokalen Benutzerarbeitseinheit zur Datenübertragung 410 wird ein Dialog eingerichtet (Schritt < 22> ).
Der Anwendungsnavigator 450 ruft dann die Routine BusUICXmit der lokalen Benutzerarbeitseinheit zur Datenübertragung 410 auf, Daten an eine Fernfunktion 430 zu schicken, wie in Schritt < 23> gezeigt. Der Name der Fernfunktion 430 und die Daten werden als Parameter des Aufrufes BusUICXmit vorgegeben und werden durch die lokale Benutzerarbeitseinheit zur Datenübertragung 410 an die Benutzerarbeitseinheit zur Datenfernübertragung 420 am Fernrechner 405 geschickt.
Die Benutzerarbeitseinheit zur Datenfernübertragung 420 ruft dann die Fernfunktion auf, wie in Schritt < 24> gezeigt. Bei Rückmeldung von der Fernfunktion 430 (Schritt < 25> ) schickt die Benutzerarbeitseinheit zur Datenfernübertragung 420 Daten vom Fernrechner 405 an den lokalen Rechner 400. Diese Daten werden ihrerseits durch die lokale Benutzerarbeitseinheit zur Datenübertragung 410 an den aufrufenden Anwendungsnavigator (Schritt < 26> ) geschickt, der sie in einem Speicherbereich 1000 speichert und sie zur Navigation benutzen kann.
Abschließend entscheidet der Benutzer über das Ende der Task. Der Anwendungsnavigator 450 ruft zu den anderen Säuberungsaktivitäten die Routine BusCloseUICXmit der lokalen Benutzerarbeitseinheit zur Datenübertragung auf, um die Zuordnung des Dialoges aufzulösen (Schritte < 27> und < 28> ) und löscht alle Daten.

Claims

1. System zum Ausführen einer entfernten Task (430) auf einem Fernrechner (20; 405), die von einer lokalen Task (415) angefordert wird, die auf einem lokalen Rechner (10; 400) abläuft, wobei die Fernrechner (20; 405) in einem Netzwerk (30) mit dem lokalen Rechner (10; 400) verbunden sind, wobei der lokale Rechner (10; 400) eine lokale Benutzerarbeitseinheit zur Datenübertragung (410) enthält, wobei die lokale Benutzerarbeitseinheit zur Datenübertragung (410) Anforderungen an den Fernrechner (20; 405) überträgt, das Ausführen der Ferntask (430) einzuleiten und während des Ausführens der Fernaufgabe (430) Daten zu senden und zu empfangen, und wobei der Fernrechner (20; 405) eine Benutzerarbeitseinheit zur Datenfernübertragung (420) enthält, wobei die Benutzerarbeitseinheit zur Datenfernübertragung (420) vom lokalen Rechner (10; 400) Anforderungen empfängt, das Ausführen der Ferntask (430) einzuleiten und während des Ausführens der Ferntask (430) Daten zu senden und zu empfangen,

dadurch gekennzeichnet, daß

mit der Transaktionsverarbeitungsumgebung (510), in der die Ferntask (430) ausgeführt wird, eine Anweisung (XmitHandle) verbunden ist, die im lokalen Rechner (10; 400) gespeichert ist und von der lokalen Task (415) benutzt wird, um auf die Ferntask (430) zuzugreifen;

im lokalen Rechner (10; 400) ein lokaler gemeinsam genutzter Zwischenspeicher zur Verfügung gestellt wird, auf den von der lokalen Task (415) und der lokalen Benutzerarbeitseinheit zur Datenübertragung (410) zugegriffen werden kann; und im Fernrechner (20; 405) ein gemeinsam genutzter Fernzwischenspeicher zur Verfügung steht, auf den von der Fernaufgabe (430) und der Benutzerarbeitseinheit zur Datenfernübertragung (420) zugegriffen werden kann.

2. System gemäß Anspruch 1, das weiterhin dadurch gekennzeichnet ist, daß

der lokale gemeinsam genutzte Zwischenspeicher von der lokalen Task (415) zur Verfügung gestellt wird; und

der gemeinsam genutzte Fernzwischenspeicher von der Benutzerarbeitseinheit zur Datenfernübertragung (420) zur Verfügung gestellt wird.

3. System gemäß einem beliebigen der vorstehenden Ansprüche, in dem die lokale Task (415)

ein Funktionsprogramm (440);

eine Anwendungssteuerung (450); oder

eine Umgebungsroutine (460) sein kann.

4. System gemäß einem beliebigen der vorstehenden Ansprüche, in dem der Fernrechner (20; 405) mit dem lokalen Rechner (10; 400) in einem SNA-Netzwerk (30) verbunden ist.

5. Verfahren zum Ausführen einer Ferntask (430) auf einem Fernrechner (20; 405), wobei diese von einer lokalen Task (415) aufgerufen wird, die auf einem lokalen Rechner (10; 400) abläuft, das die folgenden Schritte umfaßt Öffnen eines Dialogs zwischen dem Fernrechner (20; 405) und dem lokalen Rechner (10; 400) und Zuordnen einer Anweisung (XmitHandle), um eine Transaktionsverarbeitungsumgebung (510) darzustellen, in der die Ferntask (430) ablaufen soll;

Senden eines Funktionsnamens (XmitServ, XmitLib), der eine Ferntask (430), die in der Transaktionsverarbeitungsumgebung (510) ablaufen soll, und einen ersten Datenblock kennzeichnet, der die als Eingabe durch die Ferntask (430) in den Fernrechner (20; 405) erforderlichen Daten vom lokalen Rechner (10; 400) enthält;

Empfangen eines zweiten Datenblockes am lokalen Rechner (10; 400), der die Ausgabe von der Ferntask (430) enthält, die am Fernrechner (20; 405) abgelaufen ist; und

Schließen des Dialoges zwischen dem Fernrechner (10; 400) und dem lokalen Rechner (20; 405).

6. Verfahren gemäß Anspruch 5, in dem der Schritt des Öffnens eines Dialoges zwischen dem Fernrechner (20; 405) und dem lokalen Rechner (10; 400) umfaßt

Aufrufen einer Funktion (SRV_OPEN; BusOpenUICXmit), die im lokalen Rechner (10; 400) einen Mandanten (520) erzeugt und eine Verbindung zu einem Server (530) in einem Fernrechner (20; 405) einrichtet, wobei der Server (530) und der Mandant (520) zusammen die Transaktionsverarbeitungsumgebung (510) bilden, wobei die Funktion (SRV_OPEN; BusOpenUICXmit) zur lokalen Task (415) zurückkehrt, wobei die Anweisung (XmitHandle) den Dialog darstellt.

7. Verfahren gemäß Anspruch 5 oder Anspruch 6, wobei für jeden zwischen der Transaktionsverarbeitungsumgebung (510) und der lokalen Task (415) eingerichteten Dialog im lokalen Rechner (10; 400) eine getrennte Diensteinheit (500) eingerichtet wird, um den Dialog zu verwalten.

8. Verfahren gemäß Anspruch 5, wobei die Schritte des Sendens des Funktionsnamens (XmitServ, XmitLib), welcher die Ferntask (430), die in der Transaktionsverarbeitungsumgebung (510) betrieben werden soll, und den ersten Datenblock kennzeichnet, der Daten enthält, die als Eingabe durch die Ferntask (430) angefordert wurden, und des Empfangens des zweiten Datenblockes am lokalen Rechner (10; 400), der die Ausgabe aus der Ferntask (430) enthält, umfassen

Aufrufen einer Funktion (SRV_RPC; BusUICXmit), die einen Parameter enthält, der auf einen Datenzwischenspeicher (Fig. 8) zeigt, wobei der Datenzwischenspeicher (Fig. 8) die Anweisung (XmitHandle) enthält, die den zu benutzenden Dialog, die Speicheradresse (InputBuf) des ersten Datenblockes, die Speicheradresse (OutputBuf) des zweiten Datenblockes und den Namen (XmitServ, XmitLib) der Ferntask (430) anzeigt.

9. Verfahren gemäß Anspruch 5, wobei der Schritt des Schließens des Dialoges zwischen dem Fernrechner (10; 400) und dem lokalen Rechner (20; 405) umfaßt

Aufrufen einer Funktion (SRV_CLOSE; BusCloseUICXmit), die den Dialog zwischen dem lokalen Rechner (10; 400) und dem Fernrechner (20; 405) unterbricht; und

die Anweisung (XmitHandle) annulliert.

10. Verfahren gemäß einem beliebigen der Ansprüche 5 bis 9, bei dem

der Dialog zwischen dem lokalen Rechner (10; 400) und dem Fernrechner (20; 405) durch eine erste der lokalen Tasks (415) eröffnet wird; und

eine zweite der lokalen Tasks (415) den Namen der Ferntask (XmitServ, XmitLib) an die Transaktionsverarbeitungsumgebung (510) und einen ersten Datenblock vom lokalen Rechner (10; 400) unter Verwendung der von der ersten der Tasks (415) zurückgeschickten Anweisung (XmitHandle) an den Fernrechner (20; 405) sendet.

11. Verfahren gemäß einem beliebigen der Ansprüche 5 bis 10, wobei

der Dialog zwischen dem lokalen Rechner (10; 400) und dem Fernrechner (20; 405) durch eine dritte der lokalen Tasks (415) unter Verwendung der von der ersten der Tasks (415) zurückgeschickten Anweisung (XmitHandle) geschlossen wird.