DE4414171A1 - Verfahren und System zur Steuerung von Prozessen in einem Computer-Netzwerk - Google Patents

Description

Die Erfindung betrifft ein Verfahren und ein System zur Steuerung von Prozessen in einem Computer-Netzwerk, das eine Vielzahl von Rechnern mit jeweils einem Prozessor aufweist, die miteinander verbunden sind, ein Betriebssystem aufweisen und denen vorbestimmte Resourcen (Betriebsmittel) zugeordnet sind, wobei ein Prozeß auf einem gerade verfügbaren Rechner (Ausgangsrechner) abgearbeitet und im Laufe der Abarbeitung auf einen anderen Rechner (Zielrechner) verlagert werden bzw. migrieren kann.

Heutige Computer-Netzwerke oder vernetzte Rechnersysteme werden immer komplexer und sind in unterschiedlichster Art aufgebaut. So kann ein Netzwerk eine Vielzahl von Einrichtungen aufweisen, wie etwa viele Rechner oder Rechner- Systeme, Terminals, Peripheriegeräte usw., die alle miteinander verbunden sind, um Informationen auszutauschen und verschiedene Betriebsmittel, im folgenden kurz "Resourcen" genannt, miteinander zu teilen.

Dabei können sich die einzelnen Rechner sowohl im Aufbau als auch im Betriebs­ system, im Code bzw. den Programmen, bezüglich der Peripheriegeräte und/oder in den lokal verfügbaren Daten unterscheiden. Je nachdem, ob gleiche Rechner und/oder gleiche Betriebssysteme bzw. unterschiedliche Rechner und/oder Be­ triebssysteme vorhanden sind, spricht man von homogenen bzw. heterogenen Sy­ stemen.

Bei homogenen Systemen ist aus A. Goscinski "Distributed Operating Systems And The Logical Design", Addison Wesley 1991, S. 399 bis 404 bekannt, einen auf einem Rechner (Ausgangsrechner) ablaufenden Prozeß im Laufe der Abarbeitung auf einen anderen Rechner (Zielrechner) zu verlagern bzw. zu migrieren. Dabei macht man sich die Tatsache zunutze, daß das Netzwerk unterschiedliche, insbe­ sonders unterschiedlich schnelle oder mit unterschiedlich großen Arbeitsspeichern versehene Rechner aufweist und jeder Rechner mit bestimmten Resourcen ver­ bunden ist, auf die nur dieser Rechner zugreifen kann. Die bei der Prozeß-Migra­ tion verwendeten Techniken sollen im nachfolgenden kurz beschrieben werden.

In zentralen Mehrprozessor-Systemen kann mit der Prozeß-Migration ein gerade verfügbarer Prozessor einem zu aktivierenden Prozeß zugeteilt werden. Wechselt ein Prozeß im Verlauf seines Lebenszyklus den Prozessor, so handelt es sich um eine Prozeß-Migration innerhalb eines Mehrprozessor-Systems, die innerhalb ein und derselben Betriebssystem-Umgebung stattfindet. Als Kommunikationsmedium zum Austausch des den Prozeß beschreibenden Prozeß-Status dient im Falle zentraler Mehrprozessor-Systeme der Hauptspeicher. Im Falle lose gekoppelter Rechner wird das zugrundeliegende Netzwerk zur Kommunikation zwischen den Rechnern benutzt.

In lose gekoppelten Mehrprozessor-Systemen werden im Falle der Prozeß-Migra­ tion nicht notwendigerweise alle dem Prozeß zugeordneten Datenbereiche zum Zielprozessor oder Zielrechner transportiert. Statt dessen werden in diesem die Daten, die nicht am Ort des Rechners verfügbar sind, referenziert. Zur Anforderung der fehlenden Datenbereiche wird dann der Prozeß unterbrochen.

Die Technik des Lastausgleiches in verteilten Rechnerarchitekturen mit homoge­ nen Betriebssystem-Umgebungen wird eingesetzt, um den Gesamtdurchsatz eines Systems zu erhöhen. Dazu zählen die Lastverteilung rechenintensiver paralleli­ sierbarer Prozesse auf mehrere Rechner wie auch die Aufteilung einer großen An­ zahl von Prozessen auf verschiedene Rechner. Diese Technik wird auch einge­ setzt, um jedem Prozeß den Zugriff auf Resourcen, die speziellen Rechnern fest zugeteilt sind, zu ermöglichen. Beispiele für die physikalische Anbindung von Re­ sourcen an spezielle Rechner sind im Bereich spezieller Peripherie-Geräte wie Magnetbandgeräte oder Druckwerke zu finden. Eine feste Zuordnung logischer Resourcen wird zur Realisierung der Prozeßverwaltung eingesetzt, um die Kom­ plexität der Systemimplementation zu dämpfen. So wird die Überprüfung von Zu­ griffsrechten bzw. die Funktionalität der Serialisierung von Resourcen-Zuteilungen fest an ein Rechenwerk gebunden.

Die Realisierung solcher verteilter Betriebssysteme ist jedoch, wie bereits oben ausgeführt wurde, auf gleichartige Rechner und homogene Betriebssystemkerne beschränkt. Dabei unterscheidet sich die Betriebssystem-Generierung je nach an­ geschlossenen Peripherie-Geräten. Der Betriebssystemkern mit den Funktionen zur Prozeßverwaltung wie auch der Kommunikation über das Netzwerk ist jedoch homogen ausgeführt.

In herkömmlichen Client/Server-Architekturen greift der Client auf fest eingerich­ tete und damit statische RPC (Remote Procedure Call)-Dienste des Servers zu. Hierbei handelt es sich um Aufrufe zur Aktivierung von Unterprogrammen des Ser­ vers.

Ein Client kann RPC-Dienste auch aufrufen, deren Adresse er erst zur Laufzeit ermittelt. In diesem Fall stellt z. B. ein Name-Server Informationen über verfügbare Versionen und Adressen von RPC-Servern bereit.

RPC-Dienste werden heute überwiegend systemnah in den Sprachen C oder As­ sembler erstellt. Für höhere Programmiersprachen bestehen zwei Arten von Schnittstellen, und zwar Unterprogramme und/oder dynamische Verbindungs- Schnittstellen zum Aufruf von RPC-Diensten oder Programmrahmen zum Aufruf von Unterprogrammen, die in einer höheren Programmiersprache erstellt sind, die jedoch als RPC-Dienst aufrufbar sein sollen.

Die herkömmliche Programmierung zentraler Datenverarbeitungssysteme (Großrechner-Anwendungen mit Bildschirmgeräten ohne Programmierbarkeit) kennt keine Aufgliederung von Zugriffen auf Resourcen (Peripherie-Geräte, Daten, Systemdienste usw.) auf verschiedenen Rechnern, die in der Anwendungspro­ grammierung zu steuern sind; d. h. alle Resourcen werden, ggf. virtuell, vom zen­ tralen Rechner bereitgestellt. Hierauf sind die folgenden Programmiertechniken ausgerichtet:

Dialogsysteme mit hohem Verarbeitungsaufkommen werden in der Form der Transaktionsprogrammierung erstellt, die einen hohen Realisierungsaufwand nach sich zieht. Dialogsysteme mit niedrigem Verarbeitungsaufkommen werden proze­ dural bzw. sitzungsorientiert erstellt, wenn der durch die Implementation bedingte höhere Resourcen-Verbrauch an Rechenzeiten und Hauptspeicher durch den ge­ ringeren Entwicklungs- und Pflegeaufwand kompensiert wird. Die Programmierung für den Stapelbetrieb erfolgt in der Regel prozedural oder parametergesteuert. Beispiele sind hierfür die Erstellung von Berichten (Reports) oder Anwendungen zur Datenpflege. Der Ablauf erfolgt hier ohne Bedienereingriff, mit der Ausnahme manuell zuzuteilender Resourcen, wie etwa von Magnetbandgeräten.

Die Technik der Prozeß-Migration ist bislang ausschließlich für homogene Rech­ ner und Betriebssystemkerne realisiert. Dies mag seinen Grund in der Komplexität bei der Verwaltung des den Prozeß beschreibenden Prozeß-Status sowie der Übersetzung der Datenformate der jeweiligen Rechnertypen haben. Mit dem Ein­ zug der Client/Server-Architektur in die Bürokommunikation wurden nun große Netzwerke aufgebaut, die die Technik der Prozeß-Migration aufgrund ihrer inho­ mogenen Struktur nicht nutzen können.

Im herkömmlichen Client/Server-Modell bearbeitet ein Client Daten, die auf einem Server zur Verfügung stehen. Der Client richtet für benötigte Daten eine Anforde­ rung (Request) an den Server. Der Server stellt die Daten bereit und sendet sie über das Netzwerk zum Client, der sie dort verarbeitet. Soweit erforderlich, werden die Daten in bearbeiteter Form zurückgesendet.

Das herkömmliche Client/Server-Modell ist in hohem Maße ineffizient, wenn größe­ rer Datenmengen verarbeitet werden. Dies ist bei der Erstellung von Berichten (Reports) regelmäßig der Fall, wenn die Bearbeitung der Daten in einer statisti­ schen Verdichtung besteht und die Ergebnisse einen Bruchteil der ausgewerteten Datenmenge ausmachen. Das gleiche gilt für Anwendungen, die Konsistenzprü­ fungen über Datenbestände durchführen, bei denen nur eine geringe Anzahl von Datensätzen vom zu prüfenden Regelwerk abweicht und die größere Menge von einwandfreien Datensätzen auf dem Client ohne weitere Verarbeitung verworfen wird.

Demgegenüber besteht die Aufgabe der Erfindung darin, das Verfahren bzw. das System zur Steuerung von Prozessen in einem Computer-Netzwerk so zu verbes­ sern, daß die Verteilung der Prozesse im Netzwerk optimal ist, insbesondere daß die Migration von Prozessen auch bei heterogenen Rechnern und/oder Betriebs­ systemen durchgeführt werden kann.

Dabei soll der Datenverkehr im Netzwerk, der zwischen kooperierenden Rechnern während der Ausführung eines Prozesses anfällt, verringert werden.

Außerdem soll die Komplexität in der Erstellung verteilter Systeme verringert wer­ den, indem die Mechanismen der Steuerung der verteilten Verarbeitung für den Anwendungsprogrammierer verborgen werden können.

Das erfindungsgemäße Verfahren ist dadurch gekennzeichnet, daß es die folgen­ den Verfahrensschritte aufweist: Vorsehen eines Compilers auf mindestens einem Rechner, Überführen des dem Prozeß zugrundeliegenden, in einer interpretierba­ ren Sprache geschriebenen Programms (I-Code) durch den Compiler in eine ab­ strakte Repräsentation, Vorsehen eines Interpreters sowie einer Resource-Bro­ kereinrichtung (Betriebsmittel-Vermittlungseinrichtung) auf allen Rechnern, Abar­ beiten der abstrakten Repräsentation mittels des Interpreters so lange, bis auf eine Resource zugegriffen werden soll, Feststellen mittels der Resource-Brokereinrich­ tung, ob der Ausgangsrechner auf die Resource zugreifen kann, und, je nach Er­ gebnis dieser Feststellung, Fortsetzung der Abarbeitung des Prozesses durch den Interpreter, wenn der Ausgangsrechner auf die Resource zugreifen kann, oder Durchführen der folgenden Verfahrensschritte, wenn die Resource einem anderen Rechner (Zielrechner) zugeordnet ist, Abarbeiten der abstrakten Repräsentation durch den Interpreter auf dem Ausgangsrechner, Migration des gesamten Prozes­ ses auf den Zielrechner und Fortsetzung des Prozesses auf dem Zielrechner.

Weitere vorteilhafte Ausführungsformen der Erfindung sind in den Unteransprüche 2 bis 11 beschrieben.

Das erfindungsgemäße System zur Steuerung von Prozessen in einem Computer- Netzwerk ist in den Ansprüchen 12 und 13 beschrieben.

Die Motivation zur Verwendung der Prozeß-Migration anstelle herkömmlicher Client/Server-basierter RPC′s erfolgt aus der Betrachtung der Datenmengen, die über das Netzwerk transportiert werden müssen. Ist die Datenmenge des den Prozeß beschreibenden Prozeß-Status im Vergleich zu den über das Netzwerk zu transportierenden Daten verhältnismäßig klein, läßt sich das Verkehrsaufkommen im Netzwerk dadurch verringern, daß anstelle der Daten der Prozeß verlagert wird.

Ein wesentlicher Bestandteil der Erfindung ist das Vorsehen eines Interpreters, der eine transparente Prozeß-Migration mit dem Ziel unterstützt, das Netzwerk-Ver­ kehrsaufkommen zu minimieren.

Als Nebeneffekt bewirkt das Verfahren die Vermeidung des hohen Verwaltungs­ aufwands bei der Erstellung und Pflege verteilter Anwendungen.

Ein Vorteil des hier beschriebenen Verfahrens bzw. des Systems besteht in der Bereitstellung eines einfachen Interfaces für verteilte Daten und Resourcen, bei gleichzeitiger Minimierung des anfallenden Datenverkehrs in Client/Server-Anwen­ dungen bzw. des Zugriffs auf Daten bei verteilter Datenhaltung.

Die Verwendung eines portierbaren Codes erlaubt eine plattformübergreifende Definition des den Prozeß beschreibenden Prozessor-Status sowie der Ausfüh­ rungsalgorithmen des Interpreters, der als Finite State Machine (endlicher Auto­ mat, FSM) ausgeführt ist. Mit dieser Voraussetzung kann der Status eines Prozes­ ses zwischen den Interpretern verschiedener Rechner übertragen werden. Die De­ finition der Struktur des Prozessor-Status erfolgt unabhängig vom verwendeten Rechner. Dadurch kann jeder Interpreter im System einen unterbrochenen Prozeß aufgreifen und unter der Voraussetzung fortführen, die angeforderten Resourcen bereitstellen zu können.

Bisherige Implementationen der Prozeß-Migration beschränken sich auf homo­ gene Architekturen vernetzter Rechner mit homogenem Betriebssystemkern. Das erfindungsgemäße Verfahren bzw. System erlaubt die Prozeß-Migration nicht nur zwischen unterschiedlichen Rechnern sondern auch zwischen unterschiedlichen Betriebssystemen. Neu gegenüber bestehenden Implementationen der Prozeß- Migration ist die Technik der Interpretation anstelle einer systemnahen Implemen­ tation der Prozesse zu verwenden, was durch den zwischen den Rechnern und/oder Betriebssystemen portierbaren I-Code erreicht wird. Alle Interpreter bzw. der/die endlichen Automaten (FSM), egal auf welchem Rechner oder unter wel­ chem Betriebssystem, verwenden zur Realisierung des Verfahrens den strukturell gleichen Code und haben eine gemeinsame Grundlage in der Struktur des Pro­ zeß-Status. In der Konstruktion ist die Ausführung des I-Codes unabhängig von jeglicher Maschinenarchitektur oder der auf einem Rechner ablaufenden Betriebs­ systeme. Die Prozesse können freizügig zwischen den heterogen zusammenge­ stellten Rechnern migrieren.

Im Gegensatz zu bestehenden Client/Server-Konzepten, die auf fest eingerichteten und somit statischen RPC-Diensten beruhen, ist die gemäß der Erfindung erfol­ gende Isolation ganzer Programmteile, die auf entfernt verfügbare Resourcen zu­ greifen, dynamisch. Da der I-Code auf allen beteiligten Rechnern zur Verfügung steht, wird anstelle einer vollständigen Prozeß-Migration der isolierte Programm­ teil portiert und vergleichbar einem RPC-Dienst aufgerufen.

Es handelt sich um einen dynamischen RPC-Dienst, der auf dem Server nicht ge­ sondert eingerichtet werden muß. So kann der Server jeden Auftrag ausführen, der vom Client als I-Code in der abstrakten Repräsentation oder als Source-Code be­ reitgestellt und zur Ausführung angefordert wird. Die Zugriffsrechte bleiben dabei in den Grenzen, die dem Anwendungsprozeß zugeteilt sind. In diesem Fall kann dann sogar auf eine Resource zugegriffen werden, für die kein fest eingerichteter RPC-Dienst vorgesehen ist.

In bestimmten Fällen kann das Netzwerk-Verkehrsaufkommen durch die Verzöge­ rung von Zugriffen auf Resourcen minimiert werden. Ein Beispiel sind Datenaus­ gaben auf dem Bildschirm des Clients, während der Prozeß auf dem Server ab­ läuft. Die Datenausgaben können in einem Puffer gesammelt und zum Client zu­ sammenhängend übertragen werden. Zwei Ereignisse lösen die Übertragung aus: Überlauf des Puffers oder explizite Anweisung durch den Prozeß. Der Interpreter kann in der Weise implementiert werden, daß die Optimierung zur Laufzeit des Prozessors vorgenommen werden kann.

Ein wesentlicher Vorteil der Prozeß-Migration besteht in der Optimierung des Netzwerk-Verkehrsaufkommens in Anwendungen mit umfangreichem Datenzugriff. Dabei kann der Fall auftreten, daß das Datenvolumen zur Prozeß-Migration höher ausfällt, als es für die Anforderung der Daten per RPC-Dienst im Client/Server-Mo­ dell erforderlich ist. Der Interpreter schätzt zur Laufzeit des Prozesses die erfor­ derlichen Datenmengen für beide Möglichkeiten ab und wählt in Abhängigkeit von vorbestimmten Optimierungskriterien das entsprechende Verfahren aus.

Eine weitere Eigenschaft des Verfahrens besteht in der Möglichkeit, den Zugriff auf Daten aufgrund ihrer Referenzierung auch zwischen heterogenen Rechnern bzw. Betriebssystemen zu erlauben. Alternativ wird die Prozeß-Migration zum Ort der Datenhaltung eingeleitet oder selektiv die Übertragung der referenzierten Daten zum Ort des Prozesses veranlaßt.

Eine Ausführungsform der Erfindung wird anhand der Zeichnungen näher be­ schrieben. Es zeigen:

Fig. 1 eine schematische Darstellung eines Computer-Netzwerks, das - der Über­ sichtlichkeit halber - nur die Ausgangs- und Zielrechner und die diesen zu­ geordneten Komponenten aufweist;

Fig. 2 eine schematische Darstellung zur Erläuterung der reinen Daten-Migration zu einem ortsfernen Rechner, wie sie beim Stand der Technik durchgeführt wird;

Fig. 3 eine schematische Darstellung zur Erläuterung, und zwar

Fig. 3(a) der Migration eines gesamten Prozesses zu einem ortsfernen Rechner gemäß der Erfindung und

Fig. 3(b) der Migration eines Teil-Prozesses zu einem ortsfernen Rechner gemäß der Erfindung und

Fig. 4 eine schematische Darstellung der Migration des gesamten Prozesses.

In Fig. 1 ist schematisch ein Computer-Netzwerk dargestellt, das - der Übersicht­ lichkeit halber - nur einen ersten Rechner (Ausgangsrechner) 1 und einen zweiten Rechner (Zielrechner) 2 aufweist, die jeweils einen Prozessor 3 bzw. 4 und ein Betriebssystem (nicht dargestellt) aufweisen.

Die Rechner 1 und 2 bzw. die Prozessoren 3 und 4 können entweder - wie in Fig. 1 dargestellt - direkt oder - etwa über einen Bus (nicht dargestellt) - als Knoten oder sonstwie miteinander verbunden sein. Dabei ist der Rechner 1 mit Betriebsmitteln oder Resourcen 5 und der Rechner 2 mit Betriebsmitteln oder Resourcen 6 ver­ bunden. Bei diesen Resourcen handelt es sich z. B. um Daten, Peripheriegeräte, Systemdienste usw. Diese Daten können auch in einer bestimmten Darstellungs­ form abgespeichert sein.

Weiterhin weist jeder Rechner eine sogenannte Resource-Brokereinrichtung 7 bzw. 8 auf. Hierbei handelt es sich um eine Betriebsmittel-Vermittlungseinrichtung, in der bezüglich aller im Netzwerk vorhandenen und verfügbaren Resourcen (Betriebsmittel) die Eigenschaften und der Ort, d. h. die Zieladresse, zugreifbar sind.

Weiterhin weist der Rechner einen Compiler (vgl. Fig. 4) und einen Interpreter auf, der insbesondere als Finite State Machine (endlicher Automat; FSM; vgl. Fig. 4) ausgeführt ist. Dabei muß sich nicht auf jedem Rechner ein Compiler befinden, sondern es muß lediglich ein Compiler im Netzwerk vorhanden sein.

Bei dem erfindungsgemäßen Verfahren zur Steuerung von Prozessen in einem Computer-Netzwerk wird ein Prozeß auf einem gerade verfügbaren Rechner, der gemäß Fig. 1 der Ausgangsrechner 1 sein soll, abgearbeitet. Dabei liegt dem Pro­ zeß ein in einer interpretierbaren Sprache geschriebenes Programm nach der Compilierung in der abstrakten Repräsentation zugrunde, das von dem Interpreter abgearbeitet werden kann.

Dieses Programm wird solange abgearbeitet, bis auf eine Resource zugegriffen werden soll. Wenn diese Resource sich auf dem Ausgangsrechner befindet, so wird der Prozeß fortgesetzt, ist dies nicht der Fall, so sind nach der Erfindung drei Möglichkeiten vorgesehen, die anhand der Zeichnungen 2 und 3 näher erläutert werden sollen.

Dabei soll das Computer-Netzwerk jeweils aus drei Rechnern A, B und C beste­ hen, die unter unterschiedlichen Betriebssystemen MS-DOS, MVS und UNIX lau­ fen. Allen schematischen Darstellungen liegt eine beispielhaft gewählte Aufgabe der Bürokommunikation zugrunde:

• - Lese Plan-Zahlen (Daten 1) aus der lokalen Resource "Tabellenkalkulation" (Spreadsheet) auf dem unter dem Betriebssystem MS-DOS laufenden Arbeits­ platzrechner (Rechner A).
• - Lese Ist-Zahlen (Daten 2) aus der Datenbank der Produktionssteuerung auf dem unter dem Betriebssystem MVS unter Verwendung der Programmsysteme CICS und ADABAS, wobei dieses in den Figuren mit "MVS" abgekürzt ist, ablaufenden Großrechner (Rechner B), und verdichte das Zahlenwerk auf die Darstel­ lungsebene der Planzahlen.
• - Verbinde Plan- und Ist-Zahlen (Daten 1 und Daten 2), errechne Abweichungen und markiere Überschreitungen kritischer Schwellwerte. Überführe die Ergeb­ nisse in Listenform.
• - Gebe die Liste auf einem Druckwerk aus, das einem unter dem Betriebssystem UNIX ablaufenden Abteilungsrechner (Rechner C) angeschlossen ist.

Fig. 2 zeigt die reine Daten-Migration zu einem ortsfernen Rechner, wie sie vom Client/Server-Modell her bekannt ist. Diese läuft wie folgt ab:

• 1. Der Anwender führt den Programmstart auf dem lokalen, unter dem Betriebssy­ stem MS-DOS laufenden Arbeitsplatzrechner (Rechner A) durch. Das Programm liest die Plan-Zahlen (Daten 1) der lokalen Tabellenkalkulation (Spreadsheet). Die Plan-Zahlen werden im Datenbereich des Prozesses abgelegt.
• 2. Das Programm liest die Ist-Zahlen (Daten 2) der Produktionssteuerung. Es han­ delt sich um einen Datenbestand auf dem unter dem Betriebssystem MVS lau­ fenden Großrechner (Rechner B), auf den über RPC-Dienste zugegriffen wer­ den kann.
• 3. Der RPC-Dienst liest die angeforderten Datensätze aus der Datenbank.
• 4. Die Daten werden dem Arbeitsplatzrechner (Rechner A) zur Verfügung gestellt.
• 5. Nach Abschluß der Verdichtung werden Plan-Zahlen und verdichtete Ist-Zahlen zusammengeführt. Weiterhin berechnet das Programm Abweichungen und markiert Überschreitungen von Schwellwerten. Die Ergebnisse sind jetzt voll­ ständig auf dem Arbeitsplatzrechner (Rechner A) als "Report" verfügbar.
• 6. Das Programm übergibt die Daten (Report) als Druckauftrag an den unter UNIX laufenden Abteilungsrechner (Rechner C), dem das Druckwerk in der Nähe des Arbeitsplatzrechners (Rechner A) zugeordnet ist. Die Übergabe eines Druckauf­ trags erfolgt über einen RPC-Dienst.
• 7. Der unter dem Betriebssystem UNIX laufende Abteilungsrechner (Rechner C) führt den Druckauftrag aus.
• 8. Der Arbeitsplatzrechner (Rechner A) erhält die Fertig-Meldung des Druckauf­ trags und beendet das Programm.

Fig. 3(a) zeigt die Migration des gesamten Prozesses gemäß der Erfindung zu einem ortsfernen Rechner. Diese läuft wie folgt ab:

• 1. Der Anwender führt den Programmstart auf dem lokalen Arbeitsplatzrechner (Rechner A) durch, der unter dem Betriebssystem MS-DOS läuft. Das Programm liest die Plan-Zahlen (Daten 1). Dazu stellt es über den Resource-Broker fest, daß die Resource "Plan-Zahlen" als Tabellenkalkulation (Spreadsheet) auf dem lokalen Rechner (Rechner A) vorhanden ist. Die Plan-Zahlen werden im Daten­ bereich des Prozesses abgelegt.
• 2. Das Programm liest die Ist-Zahlen (Daten 2) der Produktionssteuerung. Zur Re­ source "Ist-Zahlen" stellt der Interpreter über den Zugriff auf den Resource- Broker fest, daß es sich um einen Datenbestand auf dem unter dem Betriebssy­ stem MVS laufenden Großrechner (Rechner B) handelt, der von der Daten­ menge her sehr viel größer ist als die Datenmenge des Prozeß-Status. Die Prozeß-Migration wird entsprechend Fig. 4 eingeleitet, was später beschrieben wird.
• 3. Nach Übertragung des Prozeß-Status beginnt die Fortführung des Programms auf dem Großrechner (Rechner B). Nunmehr sind die Daten 2 eine lokale Re­ source, die ohne Unterbrechung in die Systematik der Plan-Zahlen (Daten 1) verdichtet wird.
• 4. Auf dem unter dem Betriebssystem MVS laufenden Großrechner (Rechner B) führt das Programm Plan-Zahlen (Daten 1) und verdichtete Ist-Zahlen (Daten 2) zusammen, errechnet Abweichungen und markiert Überschreitungen von Schwellwerten. Die Ergebnisse werden im Datenbereich des Prozesses als "Report" abgelegt, während die Ausgangszahlen und Zwischenergebnisse ver­ worfen werden.
• 5. Das Programm greift zur Ausgabe auf ein Druckwerk in der Nähe des startenden Arbeitsplatzrechners (Rechner A) zu. Über den Resource-Broker stellt das Pro­ gramm fest, daß das Druckwerk einem unter dem Betriebssystem UNIX laufen­ den Abteilungsrechner (Rechner C) zugeordnet ist. Die zweite Prozeß-Migra­ tion wird entsprechend Fig. 4 eingeleitet, was später beschrieben wird.
• 6. Auf dem unter dem Betriebssystem UNIX laufenden Abteilungsrechner (Rechner C) gibt das Programm die Daten (Report) auf das nunmehr lokal zugreifbare Druckwerk aus. Das Programm wird dann auf dem Abteilungsrechner (Rechner C) beendet.

Fig. 3(b) zeigt die Migration des Teil-Prozesses gemäß der Erfindung zu einem ortsfernen Rechner. Diese läuft wie folgt ab:

• 1. Der Anwender führt den Programmstart auf dem unter dem Betriebssystem MS- DOS laufenden lokalen Arbeitsplatzrechner (Rechner A) durch. Das Programm liest die Plan-Zahlen (Daten 1). Dazu stellt es über den Resource-Broker fest, daß die Resource "Plan-Zahlen" als Tabellenkalkulation (Spreadsheet) auf dem lokalen Arbeitsplatzrechner (Rechner A) vorhanden ist. Die Plan-Zahlen werden im Datenbereich des Prozesses abgelegt.
• 2. Das Programm liest die Ist-Zahlen (Daten 2) der Produktionssteuerung. Zur Re­ source "Ist-Zahlen" stellt der Interpreter über Zugriff auf den Resource-Broker fest, daß es sich um einen Datenbestand auf dem unter dem Betriebssystem MVS laufenden Großrechner (Rechner B) handelt, der von der Datenmenge her sehr viel größer ist als die Datenmenge des Prozeß-Status. Weiterhin stellt der Interpreter fest, daß der Zugriff zur Verdichtung der Produktionsdaten sich als Teilprogramm des I-Codes isolieren läßt. Weiterhin stellt der Interpreter fest, welche Daten zum isolierten Teilprogramm gehören; dazu gehört nicht der Be­ reich der Plan-Zahlen (Daten 1), sondern lediglich die Information über deren Systematik. Der Prozeß-Status wird für den Start des Teilprogramms an den unter dem Betriebssystem MVS laufenden Großrechner (Rechner B) übertragen. Der initiierende Arbeitsplatzrechner (Rechner A) geht in den Wartezustand.
• 3. Nach Übertragung des Prozeß-Status beginnt die Ausführung des isolierten Teilprogramms auf dem Großrechner (Rechner B). Nunmehr sind die Daten 2 eine lokale Resource, die ohne Unterbrechung in die Systematik der Plan-Zah­ len (Daten 1) verdichtet wird.
• 4. Das Teilprogramm ist beendet. Damit wird die Übertragung des Prozeß-Status an den initiierenden Arbeitsplatzrechner (Rechner A) eingeleitet.
• 5. Auf dem Arbeitsplatzrechner (Rechner A) wird die Ausführung des Programms wieder aufgenommen, indem Plan-Zahlen (Daten 1) und verdichtete Ist-Zahlen (Daten 2) zusammengeführt, Abweichungen errechnet und Überschreitungen von Schwellwerten markiert werden. Die Ergebnisse werden im Datenbereich des Prozesses als "Report" abgelegt, während die Ausgangszahlen und Zwi­ schenergebnisse verworfen werden.
• 6. Das Programm greift zur Ausgabe auf ein Druckwerk in der Nähe des startenden Arbeitsplatzrechners (Rechner A) zu. Über den Resource-Broker stellt das Pro­ gramm fest, daß das Druckwerk einem unter dem Betriebssystem UNIX laufen­ den Abteilungsrechner (Rechner C) zugeordnet ist. Aus Gründen der beispiel­ haften Darstellung sei vorgegeben, daß die Ausgabe über den Mechanismus der Code-Isolation zu erfolgen habe. Es wird daher ein zweites Mal ein entspre­ chender Code isoliert und der Prozeß-Status an den Abteilungsrechner (Rechner C) übertragen. Der Arbeitsplatzrechner (Rechner A) geht erneut in den Wartezustand.
• 7. Auf dem unter dem Betriebssystem UNIX laufenden Abteilungsrechner (Rechner C) wird die Ausführung des isolierten Teil-Codes aufgenommen. Darin greift das Programm auf das nunmehr lokal zugreifbare Druckwerk zu und gibt die Daten (Report) aus.
• 8. Das Teilprogramm ist auf dem Abteilungsrechner (Rechner C) beendet und leitet die Übertragung des Prozesses zum Arbeitsplatzrechner (Rechner A) ein. Dort wird die Ausführung des Programms wieder aufgenommen, die lediglich aus dem Abschluß des Programms besteht.

Die Migration des gesamten Prozesses wird nun anhand von Fig. 4 näher be­ schrieben.

Der Compiler 21 übersetzt den I-Code 20 und führt ihn in eine abstrakte Repräsen­ tation 22 über. Bei der abstrakten Repräsentation 22 handelt es sich um die inner­ halb des Rechners gehaltene interne Darstellung, einem Äquivalent zum I-Code. Der Compiler übersetzt jedoch nicht in eine Maschinensprache, sondern in die ab­ strakte Repräsentation.

Die abstrakte Repräsentation 22 wird dann von dem Interpreter, der insbesondere als Finite State Machine (endlicher Automat, FSM) ausgeführt ist, abgearbeitet, was anhand der vergrößerten Darstellung 24 der FSM 23 näher erläutert werden soll.

Die abstrakte Repräsentation 29 wird von einem Ausführungsalgorithmus 25 abge­ arbeitet, der in bekannter Weise auf einen Prozeß-Status-Stack (Traversal Stack) 26 und einen Arbeits-Stack (Execution Stack) 27 sowie einen Datenbereich 28 zu­ greifen kann und dort den Prozeß-Status und die Daten abspeichert.

Von einem Normalisierer 30 werden dann der im Prozeß-Status-Stack 26 und dem Arbeits-Stack 27 beschriebene Prozeß-Status und die im Datenbereich 28 ge­ speicherten Daten, sowie optional das Programm in seiner Darstellung als Quell- Code und/oder der abstrakten Repräsentation in der bekannten Weise in eine ex­ terne Darstellung 32 (mit Prozeß-Status-Stack 26′, Arbeits-Stack 27′, Datenbe­ reich 28′ sowie optional das Programm in seiner Darstellung als Quell-Code oder in der abstrakten Repräsentation 29′) übertragen. Dabei bewirkt ein Normalisierer die Übersetzung von spezifischen Datenformaten in ein einheitliches Datenformat und zurück, so daß für die zugreifenden Prozesse kein Informationsverlust ent­ steht.

Gleichzeitig wird der Weg des Prozesses in einer Log-Datei des Ausgangsrech­ ners gespeichert, um asynchrone Anfragen an den Prozeß weiterleiten zu können.

Mit dem Bezugszeichen 40 ist in vergrößerter Darstellung eine FSM des Zielrech­ ners bezeichnet. Die an die FSM 40 übertragene externe Darstellung 32 wird von einem Normalisierer 41 der FSM 40 in bekannter Weise wieder in die eigene in­ terne Darstellung übertragen, in der sie dann in bekannter Weise in dem Ver­ schiebe-Stack 26′′, dem Ablauf-Stack 27′′ und dem Datenbereich 28′′ entsprechend abgespeichert werden. Im Anschluß daran wird der Prozeß mit dem übertragenen Status aktiviert und ein Ausführungsalgorithmus 25′′ nimmt die Ausführung des Programms an der unterbrochenen Stelle wieder auf. Auf die auf dem Zielrechner nunmehr lokal verfügbare Resource kann nun zugegriffen werden.

In ähnlicher Weise läuft die Migration des Teilprozesses gemäß Fig. 3(b) ab, wo­ bei nachfolgend ein beispielhaftes Programm für einen isolierbaren Code wieder­ gegeben wird:

1 read parms from screen
2 sum (*) = 0
3 read rec from file
4 while(eof)
5 sum (*) = sum (*) + rec (*)
6 read rec from file
7 end
8 print sum (*).

Das Programm greift auf eine ortsentfernte Resource über das Runtime-System des Interpreters zu (Zeile 3 des Beispiel-Codes). Damit wird die Ausführung des Programms abgebrochen. Die Unterbrechungsstelle des Programms wird analy­ siert. Wenn sich die Unterbrechungsstelle innerhalb eines isolierbaren Programm­ teils befindet, so kann anstelle der Migration des gesamten Prozesses eine Migra­ tion lediglich des Teil-Prozesses stattfinden. Im Beispiel sind dies die Programm­ zeilen 2 bis 7.

Dabei wird der Prozeß-Status auf die Einsprungstelle des isolierbaren Codes zu­ rückgeführt, d. h. auf den Status zu Beginn der Zeile 2. Der Prozeß-Status und die Daten werden in bekannter Weise in eine externe Repräsentation überführt und an den Zielrechner übertragen. Der Zielrechner übernimmt die Daten und übersetzt sie in die eigene Darstellung. Im Anschluß daran aktiviert er den Prozeß mit dem Prolog "Teil-Migration" und dem übertragenen Status. Damit wird die Ausführung des Programms an der Einsprungstelle des isolierbaren Codes an Zeile 2 aufge­ nommen. Es kann dann auf die auf dem Zielrechner nunmehr lokal verfügbare Re­ source zugegriffen werden.

Mit Beendigung des isolierten Codes auf dem Zielrechner nach Zeile 7 wird ein Epilog durchlaufen, der die Rückübertragung der Daten an den Ausgangsrechner veranlaßt. Dazu werden die Daten von der internen Darstellung des Zielrechners wieder in die externe Darstellung übertragen. Der Ausgangsrechner nimmt die Be­ arbeitung mit dem Status am Ende des isolierbaren Codes als Zeile 8 wieder auf und führt weitere Schritte des Programms aus.

Die Verwendung eines portierbaren Codes erlaubt eine plattformübergreifende Definition des den Prozeß beschreibenden Prozessor-Status sowie des zugehöri­ gen Interpreters. Mit dieser Voraussetzung kann der Status eines Prozesses zwi­ schen den Interpretern verschiedener Rechner übertragen werden. Die Definition der Struktur des Prozessor-Status erfolgt unabhängig vom verwendeten Rechner. Dadurch kann jeder Interpreter im System einen unterbrochenen Prozeß aufgrei­ fen und unter der Voraussetzung fortführen, die angeforderten Resourcen bereit­ stellen zu können.

Bisherige Implementationen der Prozeß-Migration beschränken sich auf homo­ gene Architekturen vernetzter Rechner mit homogenem Betriebssystemkern. Das erfindungsgemäße Verfahren bzw. System erlaubt die Prozeß-Migration nicht nur zwischen unterschiedlichen Rechnern sondern auch zwischen unterschiedlichen Betriebssystemen. Neu gegenüber bestehenden Implementationen der Prozeß- Migration ist die Technik der Interpretation anstelle einer systemnahen Implementation der Prozesse zu verwenden, was durch den zwischen den Rechnern und/oder Betriebssystemen portierbaren I-Code erreicht wird. Alle Interpreter bzw. der/die endlichen Automaten (FSM), egal auf welchem Rechner oder unter wel­ chem Betriebssystem, verwenden zur Realisierung des Verfahrens den strukturell gleichen Code und haben eine gemeinsame Grundlage in der Struktur des Pro­ zeß-Status. In der Konstruktion ist die Ausführung des I-Codes in der übersetzten Form als abstrakte Repräsentation unabhängig von jeglicher Maschinenarchitektur oder der auf einem Rechner ablaufenden Betriebssysteme. Die Prozesse können freizügig zwischen den heterogen zusammengestellten Rechnern migrieren.

Im Gegensatz zu bestehenden Client/Server-Konzepten, die auf fest eingerichteten und somit statischen RPC-Diensten beruhen, ist die gemäß der Erfindung erfol­ gende Isolation ganzer Programmteile, die auf entfernt verfügbare Resourcen zu­ greifen, dynamisch. Da die abstrakte Repräsentation auf allen beteiligten Rech­ nern zur Verfügung steht, wird anstelle einer vollständigen Prozeß-Migration der isolierte Programmteil portiert und vergleichbar einem RPC-Dienst aufgerufen.

Es handelt sich um einen dynamischen RPC-Dienst, der auf dem Server nicht ge­ sondert eingerichtet werden muß. So kann der Server jeden Auftrag ausführen, der vom Client als I-Code bzw. abstrakte Repräsentation bereitgestellt und zur Ausfüh­ rung angefordert wird. Die Zugriffsrechte bleiben dabei in den Grenzen, die dem Anwendungsprozeß zugeteilt sind. In diesem Fall kann dann sogar auf eine Re­ source zugegriffen werden, für die kein fest eingerichteter RPC-Dienst vorgesehen ist.

In bestimmten Fällen kann das Netzwerk-Verkehrsaufkommen durch die Verzöge­ rung von Zugriffen auf Resourcen minimiert werden. Ein Beispiel sind Datenaus­ gaben auf dem Bildschirm des Clients, während der Prozeß auf dem Server ab­ läuft. Die Datenausgaben können in einem Puffer gesammelt und zum Client zu­ sammenhängend übertragen werden. Zwei Ereignisse lösen die Übertragung aus: Überlauf des Puffers oder explizite Anweisung durch den Prozeß. Der Interpreter ist in der Lage, die Optimierung zur Laufzeit des Prozessors vorzunehmen.

Ein wesentlicher Vorteil der Prozeß-Migration besteht in der Optimierung des Netzwerk-Verkehrsaufkommens in Anwendungen mit umfangreichem Datenzugriff. Dabei kann der Fall auftreten, daß das Datenvolumen zur Prozeß-Migration höher ausfällt, als es für die Anforderung der Daten per RPC-Dienst im Client/Server-Mo­ dell erforderlich ist. Der Interpreter schätzt zur Laufzeit des Prozesses die erfor­ derlichen Datenmengen für beide Möglichkeiten ab und wählt in Abhängigkeit von vorbestimmten Optimierungskriterien das entsprechende Verfahren aus.

Die Optimierung des Netzwerk-Verkehrsaufkommens kann durch eine weitere Maßnahme verbessert werden. Es ist nicht erforderlich, im Fall einer Prozeß-Mi­ gration alle Daten eines Prozesses zwischen den Rechnern zu migrieren. Vielmehr können alle oder Teile der Daten je nach Bedarf auf Anforderung an den Zielrech­ ner transportiert werden. In Fig. 4 ist die Verbindung 50 zwischen den Datenberei­ chen der Prozesse eingezeichnet, die über bekannte Techniken und im Fall hete­ rogener Plattformen unter Einschaltung der Normalisierer 30 und 41 realisiert wird.

Im Fall umfangreicher Datenzugriffe ohne Isolierbarkeit des zugehörigen I-Codes erfolgt die Prozeß-Migration, während im Fall isolierbarer Programmteile oder kleinerer Datenmengen der Zugriff im Client/Server-Modell erfolgt. Im Unterschied zu herkömmlichen RPC-Diensten handelt es sich jedoch um einen dynamisch ein­ richtbaren Dienst, der als Teil der vorliegenden abstrakten Repräsentation ausge­ führt wird. Zudem kann dann, wenn kein RPC-Dienst verfügbar ist, eine Migration des gesamten oder des Teil-Prozesses durchgeführt werden.

Die vom Interpreter bearbeitbare Sprache erlaubt die Erstellung verteilter Anwen­ dungen einschließlich Prozeß-Migration und RPC-Diensten, ohne daß der Pro­ grammierer mit Einzelheiten des Client/Server-Modells oder anderen Feinheiten der verteilten Verarbeitung belastet wird. Die Optimierung des Netzwerk-Verkehr­ saufkommens kann dynamisch zur Laufzeit erfolgen.

Damit wird erreicht, daß bei den Programmierern keine Voraussetzungen zu Kenntnissen komplexer Konzepte der verteilten Verarbeitung gemacht werden müssen. Der Programmierer kann mit der einfacheren Sichtweise eines einzigen Rechners arbeiten, die von einem transparenten Zugriff auf alle notwendigen Re­ sourcen und Daten ausgeht.

Ein Programm in I-Code-Darstellung wird über den Compiler in die abstrakte Re­ präsentation übersetzt. Auf diese Repräsentation greift eine Finite State Machine (endlicher Automat, FSM) zu, der den bereits beschriebene Interpreter darstellt. Jeder an der verteilten Verarbeitung beteiligte Rechner muß über mindestens einen solchen Interpreter verfügen, um Anforderungen entfernter Rechner zu Aus­ führungen von Programmschritten als Änderung des Prozeß-Status auszuführen, oder aber der I-Code wird mittels eines auf einem Rechner befindlichen Compiler in die abstrakte Repräsentation übertragen und in dieser Form auf allen Rechnern abgelegt.

Das eine Migration auslösende Ereignis beruht auf dem Zugriff auf ortsferne Re­ sourcen. Greift ein laufender Prozeß auf eine Resource zu, fragt der Prozeß den Resource-Broker nach dem Ort der Resource. Ist die Resource auf dem lokalen Rechner verfügbar, wird der Prozeß ohne Unterbrechung fortgeführt. Ist die Re­ source ortsfern verfügbar, entscheidet der Interpreter anhand vorgegebener Opti­ mierungskriterien, in welcher Form auf die Resource zugegriffen werden soll:

• 1. Migration des gesamten Prozesses zum ortsfernen Rechner.
• 2. Isolation von Programmteilen und Migration des Teil-Prozesses in Form eines Aufrufs als dynamischer RPC-Dienst beim ortsfernen Rechner.
• 3. Zugriff auf die Resource als fest eingerichteter RPC-Dienst beim ortsfernen Rechner.

Die ortsferne Wiederaufnahme eines Prozesses an einer unterbrochenen Stelle erfordert besondere Vorkehrungen für die Interpretation des I-Codes. Bei einer bevorzugten Ausführungsform der Erfindung wird der Prozeß-Status des interpre­ tierten Programms über die Schnittstelle der externen Repräsentation zwischen unterschiedlichen Rechnern übermittelt, nicht jedoch der Prozessor-Status des Interpreters selbst. Die Konsequenz besteht darin, daß der Interpreter keine An­ nahmen über die Verarbeitungsfolge zwischen den Anweisungen der abstrakten Repräsentation machen kann, um an jeder Stelle des Codes die Ausführung des Programms aufnehmen zu können. So kann bei der bevorzugten Ausführungsform der Erfindung der Algorithmus zur Interpretation des I-Codes keine rekursiven Auf­ rufe in Abhängigkeit vom I-Code ausführen. Die Sprach- und Code-Implementation des zu interpretierenden Codes ist jedoch von dieser Einschränkung ausgenom­ men.

Wie bereits oben ausgeführt wurde, werden bei lose gekoppelten Mehrprozessor- Systemen im Falle der Prozeß-Migration nicht notwendig alle dem Prozeß zuge­ ordneten Datenbereiche zum Zielprozessor transportiert. Stattdessen löst die Re­ ferenzierung von Daten, die nicht am Ort des Rechners verfügbar sind, eine Unter­ brechung aus. Die Bearbeitung der Unterbrechung besteht in der Anforderung der fehlenden Datenbereiche.

Mit dem erfindungsgemäßen Verfahren ist es nun möglich, den Zugriff auf Daten aufgrund ihrer Referenzierung auch zwischen heterogenen Rechnern bzw. Be­ triebssystemen zu erlauben. Alternativ wird die Prozeß-Migration zum Ort der Datenhaltung eingeleitet oder selektiv die Übertragung der referenzierten Daten zum Ort des Prozesses veranlaßt.

Änderungen der beschriebenen Ausführungsform sind für den Fachmann ohne weiteres möglich und fallen in den Rahmen der Erfindung. Compiler und Interpreter können zu einer Einheit verschmolzen werden. Auch kann der Ausführungsalgo­ rithmus der FSM rekursive Aufrufe zulassen. In diesem Fall muß jedoch ein höhe­ rer Aufwand zur Vorbereitung des Prozesses vor der Übertragung auf den Ziel­ rechner betrieben werden, damit die FSM den Prozeß wieder aufgreifen und fort­ führen kann. Mit der Einschaltung eines Normalisierers und der dadurch gegebe­ nen Zwischenebene lassen sich auch Prozeß-Stack und weitere Stack (beispielsweise für Schleifen oder kontrollierte Speicher) migrieren. Der Normali­ sierer überbrückt die unterschiedlichen Architekturen in einer heterogenen Umge­ bung, seien es unterschiedliche Zahlenformate oder Zeichencodierungen.

Claims (13)

1. Verfahren zur Steuerung von Prozessen in einem Computer-Netzwerk, das eine Vielzahl von Rechnern mit jeweils einem Prozessor aufweist, die miteinander verbunden sind, ein Betriebssystem aufweisen und denen vorbestimmte Re­ sourcen (Betriebsmittel) zugeordnet sind, wobei ein Prozeß auf einem gerade ver­ fügbaren Rechner (Ausgangsrechner) abgearbeitet und im Laufe der Abarbeitung auf einen anderen Rechner (Zielrechner) verlagert werden bzw. migrieren kann, gekennzeichnet durch die folgenden Verfahrensschritte:

• - Vorsehen eines Compilers auf mindestens einem Rechner,
• - Überführen des dem Prozeß zugrundeliegenden, in einer interpretierbaren Spra­ che geschriebenen Programms (I-Code) durch den Compiler in eine abstrakte Repräsentation,
• - Vorsehen eines Interpreters sowie einer Resource-Brokereinrichtung (Betriebsmittel-Vermittlungseinrichtung) auf allen Rechnern,
• - Abarbeiten der abstrakten Repräsentation mittels des Interpreters so lange, bis auf eine Resource zugegriffen werden soll,
• - Feststellen mittels des Resource-Brokereinrichtung, ob der Ausgangsrechner auf die Resource zugreifen kann, und, je nach Ergebnis dieser Feststellung,
• - Fortsetzung der Abarbeitung des Prozesses durch den Interpreter, wenn der Ausgangsrechner auf die Resource zugreifen kann, oder
• - Durchführen der folgenden Verfahrensschritte, wenn die Resource einem ande­ ren Rechner (Zielrechner) zugeordnet ist,
• - Abarbeiten der abstrakten Repräsentation durch den Interpreter auf dem Aus­ gangsrechner,
• - Migration des gesamten Prozesses auf den Zielrechner und
• - Fortsetzung des Prozesses auf dem Zielrechner.

2. Verfahren nach Anspruch 1, bei dem der Interpreter eine Finite State Machine (endlicher Automat; FSM) ist.

3. Verfahren nach einem der Ansprüche 1 oder 2, bei dem beim Abarbeiten der abstrakten Repräsentation durch den Interpreter bzw. die FSM auf dem Ausgangs­ rechner die folgenden Verfahrensschritte durchgeführt werden:

• - Feststellen, ob der Zugriff auf die dem Zielrechner zugeordnete Resource als Teil-Prozeß oder -Programm isolierbar ist, und, je nach Ergebnis dieser Feststel­ lung,
• - Migration des gesamten Prozesses auf den Zielrechner, wenn der Zugriff nicht als Teil-Prozeß isolierbar ist, und Fortsetzung des Prozesses auf dem Zielrech­ ner, oder
• - Migration des Teil-Prozesses auf den Zielrechner, wenn der Zugriff als Teil-Prozeß isolierbar ist, Abarbeiten des Teil-Prozesses auf dem Zielrechner und Rück- Migration auf den Ausgangsrechner, wenn der Teil-Prozeß abgeschlossen ist.

4. Verfahren nach einem der Ansprüche 1 bis 3, bei dem auf allen Rechnern ein Interpreter vorgesehen ist.

5. Verfahren nach einem der Ansprüche 1 bis 4, bei dem die Interpreter bzw. die FSM′s einen unterbrochenen Prozeß aufgreifen und fortführen können, wenn der Rechner, auf dem sie sich befinden, Zugriff zu der angeforderten Resource hat.

6. Verfahren nach einem der Ansprüche 1 bis 5, bei dem die abstrakte Reprä­ sentation durch die FSM mit einem nicht-rekursiven Ausführungsalgorithmus ab­ gearbeitet wird.

7. Verfahren nach einem der Ansprüche 1 bis 6, bei dem vor der Migration des gesamten oder des Teil-Prozesses die folgenden Verfahrensschritte durchgeführt werden:

• - Feststellen, ob nach vorbestimmten Optimierungskriterien eine gesamte Migra­ tion oder eine Teilmigration durchzuführen ist, und, je nach Ergebnis dieser Feststellung,
• - gesamte Migration bzw. teilweise Migration des Prozesses, wenn die Optimie­ rungskriterien zutreffen, oder
• - Zugriff auf die dem Zielrechner zugeordnete Resource mittels eines im Netzwerk fest eingerichteten RPC(Remote Process Call)-Dienstes zur Aktivierung einer Prozedur auf dem Zielrechner.

8. Verfahren nach Anspruch 7, bei dem als Optimierungskriterium die Menge der zur Beschreibung des Prozeß-Status erforderlichen Daten mit der Menge der zu verarbeitenden Daten in Beziehung gesetzt wird.

9. Verfahren nach einem der Ansprüche 7 oder 8, bei dem vor dem Zugriff auf die dem Zielrechner zugeordnete Resource mittels eines im Netzwerk fest einge­ richteten RPC-Dienstes die folgenden Verfahrensschritte durchgeführt werden:

• - Feststellen, ob der RPC-Dienst verfügbar ist, und, je nach Ergebnis dieser Fest­ stellung,
• - gesamte bzw. teilweise Migration des Prozesses, wenn der RPC-Dienst nicht ver­ fügbar ist, oder
• - Zugriff auf die dem Zielrechner zugeordnete Resource mittels eines im Netzwerk fest eingerichteten RPC-Dienstes, wenn der RPC-Dienst verfügbar ist.

10. Verfahren nach einem der Ansprüche 1 bis 9, bei dem mittels des Verfahrens der Referenzierung von Daten auf Daten zugegriffen wird, die nicht am Ort des den Prozeß gerade abarbeitenden Rechners verfügbar sind.

11. Verfahren nach Anspruch 10, bei dem entweder eine Migration des Prozes­ ses auf den Rechner durchgeführt wird, der auf die gewünschten Daten Zugriff hat, oder eine Übertragung der referenzierten Daten mittels RPC-Dienst oder Migration eines Teil-Prozesses zu dem Rechner durchgeführt wird, auf dem der Prozeß ge­ rade abläuft.

12. System zur Steuerung von Prozessen in einem Computer-Netzwerk, das eine Vielzahl von Rechnern mit jeweils einem Prozessor aufweist, die miteinander ver­ bunden sind, ein Betriebssystem aufweisen und denen vorbestimmte Resourcen (Betriebsmittel) zugeordnet sind, wobei ein Prozeß auf einem gerade verfügbaren Rechner (Ausgangsrechner) abgearbeitet und im Laufe der Abarbeitung auf einen anderen Rechner (Zielrechner) verlagert werden bzw. migrieren kann, dadurch gekennzeichnet, daß

• - mindestens einer der Rechner einen Compiler aufweist, der das dem Prozeß zugrundeliegende, in einer interpretierbaren Sprache geschriebene Programm (I- Code) in eine abstrakte Repräsentation überführen kann,
• - alle Rechner einen Interpreter, der die abstrakte Repräsentation so lange abar­ beiten kann, bis auf eine Resource zugegriffen werden soll, sowie eine Resource- Brokereinrichtung (Betriebsmittel-Vermittlungseinrichtung) aufweisen,
• - eine Einrichtung zur Feststellung mittels der Resource-Brokereinrichtung, ob der Ausgangsrechner auf die Resource zugreifen kann,
• - und eine Einrichtung zur Migration des gesamten Prozesses auf den Zielrechner vorgesehen sind,
• - wobei, je nach Ergebnis dieser Feststellung, der Interpreter die Abarbeitung des Prozesses fortsetzen kann, wenn der Ausgangsrechner auf die Resource zugrei­ fen kann, oder der Prozeß auf den Zielrechner migriert und auf diesem fortge­ setzt wird, wenn der Ausgangsrechner nicht auf die Resource zugreifen kann.

13. System nach Anspruch 12, das zur Durchführung nach einem der Verfahren nach den Ansprüchen 1 bis 11 geeignet ist.