DE68916853T2

DE68916853T2 - Unabhängige Programmlader für virtuelle Maschinenarchitektur.

Info

Publication number: DE68916853T2
Application number: DE68916853T
Authority: DE
Inventors: Richard Leroy Diefendorf; Joel Alan Farrell; George Nicholas Kustas; Iii George Victor Madl; Frank Michael Nesgoda
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1988-05-20
Filing date: 1989-04-15
Publication date: 1995-03-09
Anticipated expiration: 2009-04-16
Also published as: EP0342362A2; EP0342362B1; JPH0217543A; EP0342362A3; US4970639A; DE68916853D1; JPH0577100B2

Description

Die vorliegende Erfindung betrifft allgemein Betriebssysteme (OS) für virtuelle Maschinen (VM) für Computer und Datenverarbeitungssysteme und insbesondere ein verbessertes Subsystem für das Betriebssystem für virtuelle Maschinen mit Befehlssprachen- und Dateiverwaltungsfunktionen, das es gestattet, Programme über eine direkte Verzweigungsverbindung im Adressiermodus des Zielprogramms aufzurufen, den Adressiermodus und Residenzmodus an einem beliebigen Punkt des Ladeprozesses dynamisch und interaktiv zu überschreiben, das weiterhin steuert, ob zuvor geladene Programme zusammen mit dem gerade geladenen Programm im Speicher bleiben und schließlich das Laden und Ausführen von architekturabhängigen Programmen sowie Programmen ohne Architekturabhängigkeit ermöglicht.
Das grundlegende Konzept einer virtuellen Maschine ist die Bereitstellung einer Basis, auf der verschiedene Betriebssysteme einen Computer oder ein Datenverarbeitungssystem gemeinsam benutzen können und sich logisch so verhalten, als sei jedes das einzige auf dem Computer oder Datenverarbeitungssystem ausgeführte Betriebssystem. Das am häufigsten eingesetzte virtuelle Maschinensystem (VM) ist VM/SP, das eine Rechnerfamilie des Typs IBM System /370 verwaltet.
Damit eine Vielzahl von Benutzern eines Betriebssystems für virtuelle Maschinen unterstützt werden kann, wird üblicherweise ein Subsystem mit Befehlssprachen- und Dateiverwaltungsfunktionen bereitgestellt. Ein solches Subsystem ist das IBM Conversational Monitor System (CMS) für VM/SP. CMS ist ein plattenorientiertes Betriebssystem, das dem Benutzer uneingeschränkten Zugriff auf eine augenscheinlich dedizierte reale Maschine gewährt. Während ein CMS-Benutzer eine dedizierte virtuelle Maschine sieht, stellt VM/SP eine Timesharing-Umgebung für mehrere Benutzer durch Unterstützung vieler separater virtueller CMS-Maschinen zur Verfügung. Eine allgemeine Beschreibung von VM/SP und CMS findet der interessierte Leser in Kapitel 16, "Virtual Machines", veröffentlicht von H. Lorin und H.M. Deitel in "Operating Systems", Addison-Wesley (1981), und in Kapitel 22, "VM: A Virtual Machine Operating System", veröffentlicht von H.M. Deitel in "An Introduction to Operating Systems", Addison-Wesley (1984).
Die Architektur des IBM Systems /370 bietet einem einzelnen Benutzer 24-Bit-Adressierung und begrenzten virtuellen Speicher bis 16 MB. Vor kurzem wurde mit dem IBM System /370-XA die erweiterte Architektur eingeführt, die eine 31-Bit-Adressierung gestattet, wodurch der für einen einzelnen Benutzer verfügbare virtuelle Speicher beträchtlich vergrößert wurde. Die beiden Umgebungen, IBM System /370 und IBM System /370- XA, sind jedoch nicht voll kompatibel. Konkreter ausgedrückt bedeutet dies, daß der Programmlader, der vor dieser Erfindung dem Stand der Technik entsprach, nur für eine Architektur gültig ist und von der Annahme ausgeht, daß alle Programme ausführbar sind, nachdem sie einmal geladen wurden. Da es sich bei der einzigen von diesem Programmlader unterstützten Architektur um die Architektur des IBM Systems /370 handelt, in der nicht die Konzepte der mehrfachen Adressierund Residenzmodi implementiert sind, bietet sie keine Adressier- oder Residenzmodusverarbeitung. Programme werden in feste, nicht verschiebbare Adressen geladen und werden ohne Adressiermodusumschaltung ausgeführt.
Die Patentschrift EP-A-0 195823 offenbart ein Verfahren zum Laden eines Programms, das sich aus Modulen zusammensetzt, die im externen Speicher abgelegt sind. Ein Modul wird weiterhin je nach den Speicheranforderungen in die Speicher geladen.
Angesichts dessen besteht eine Aufgabe der vorliegenden Erfindung darin, einen neuen Programmlader bereitzustellen, der Computerarchitekturen nutzt, die Unterstützung für mehrere Adressier- und Residenzmodi bieten.
Eine weitere Aufgabe der Erfindung ist es, einen Programmlader bereitzustellen, der in der Lage ist, sowohl architekturabhängige Programme als auch Programme ohne Architekturabhängigkeit zu laden und auszuführen.
Eine zusätzliche Aufgabe der Erfindung besteht darin, einen Programmlader bereitzustellen, der die Fähigkeit zur dynamischen und interaktiven Außerkraftsetzung des Adressiermodus und Residenzmodus eines Programms zu einem beliebigen Zeitpunkt des Ladeprozesses besitzt.
Schließlich ist es eine Aufgabe der Erfindung, den Programmlader mit der Fähigkeit zu versehen, zu steuern, ob zuvor geladene Programme zusammen mit einem Programm, das gerade geladen wird, im Speicher bleiben sollen.
Gemäß der in den Patentansprüchen niedergelegten Erfindung stellt ein architekturunabhängiger Programmlader Bereiche für Adressier- und Residenzmodusverarbeitung, residenzmodusgestützte Programmverschiebung und Computerarchitektursensiti vität bereit. Der architekturunabhängige Programmlader validiert Adressier- und Residenzmodi, verschiebt das Programm während des Ladens entsprechend dem Residenzmodus und gewährleistet, daß das zu ladende Programm in der virtuellen Maschinenarchitektur, innerhalb derer es geladen wird, ausführbar ist. Darüber hinaus bietet es Einrichtungen, die Programmen mit verschiedenen Adressiermodi eine Zusammenarbeit gestattet.
Zum besseren Verständnis der vorstehenden Ausführungen sowie der weiteren Aufgaben, Aspekte und Vorteile der Erfindung ist die folgende ausführliche Beschreibung eines bevorzugten Ausführungsbeispiels der Erfindung unter Bezugnahme auf die Zeichnungen heranzuziehen, in denen:
Fig. 1 ein Blockdiagramm darstellt, aus dem der Prozeß hervorgeht, mit dessen Hilfe ein Benutzer die Befehlsstruktur des architekturunabhängigen Programmladers gemäß der Erfindung einsetzt;
Fig. 2 ein Flußdiagramm zeigt, aus dem hervorgeht, wie der CMS-Befehl LOAD Attribute des Residenzmodus (RMODE) und des Adressiermodus (AMODE) für eine TEXT-Datei, die in den virtuellen Speicher geladen werden soll, verarbeitet und zuordnet;
Fig. 3 ein Flußdiagramm zeigt, aus dem hervorgeht, wie der CMS-Befehl LOAD als nächstes bestimmt, ob zuvor geladene Programme aus dem Speicher gelöscht werden sollen und an welche Stelle des virtuellen Speichers die TEXT-Datei(en) des Benutzers geladen werden soll(en).
Fig. 4 ein Flußdiagramm zeigt, aus dem hervorgeht, wie der CMS-Befehl GENMOD die Attribute des AMODE und/oder RMODE der TEXT-Datei(en), die gerade in den virtuellen Speicher geladen wird/werden, außer Kraft setzen kann;
Fig. 5 ein Flußdiagramm zeigt, aus dem hervorgeht, daß der Benutzer, der den CMS-Befehl GENMOD ausgegeben hat, Architekturabhängigkeit oder Architekturunabhängigkeit für eine erstellte MODUL-Datei angeben kann.
Fig. 6 ein Flußdiagramm mit der Logik zeigt, ob eine CMS MODUL-Datei auf der Basis ihres beim Aufruf des GENCOM- Befehls angegebenen Architekturattributs in den virtuellen Speicher geladen werden kann oder nicht, wie das MODUL basierend auf dem Attribut RMODE in den virtuellen Speicher geladen wird, und ob zuvor geladene Programme aus dem virtuellen Speicher gelöscht werden sollen;
Fig. 7 ein Flußdiagramm zeigt, aus dem hervorgeht, wie eine MODUL-Datei die Steuerung in dem angeforderten Adressiermodus erhält; und
Fig. 8 eine Speicherkarte zeigt, das die möglichen Kombinationen der Programmresidenz- (RMODE) und Adressiermodi (AMODE) und die verschiedenen Verfahren veranschaulicht, die vom Programm zum Aufrufen eines anderen Programms mit dem gleichen oder einem anderen Adressier-/Residenzmodus verwendet werden können.
Die Erfindung wird anhand eines bevorzugten Ausführungsbeispiels beschrieben, das die beste Ausführungsform für die Umsetzung der Erfindung darstellt. In dem bevorzugten Ausführungsbeispiel wird der Einsatz der IBM Programmprodukte Conversational Monitor System (CMS) und Virtual Machine/System Product (VM/SP) erläutert, die auf den IBM Systemen /370 und /370-XA ausgeführt werden. Es wird jedoch darauf hingewiesen, daß die beschriebenen Konzepte ein breiteres Anwendungs-Spektrum besitzen und in anderen Systemprodukten, die in anderen Umgebungen eingesetzt werden, auf gleichermaßen vorteilhafte Weise zum Einsatz kommen können.
Die Architektur des IBM Systems /370 gestattet nur eine 24- Bit-Adressierung und beschränkt den Adreßraum auf 16 MB (Megabyte). Die neuere Architektur des IBM Systems /370-XA ermöglicht eine 31-Bit-Adressierung und bietet einen potentiellen Adreßraum von 2 GB (Gigabyte), wobei jedoch das VM/XA SP-Steuerprogramm den Adreßraum auf 999 MB beschränkt. Dies ist z.B. für Benutzer äußerst vorteilhaft, deren technische und wissenschaftliche Anwendungen eine 31-Bit-Adressierung und virtuelle Maschinen mit großer Kapazität erfordern. Innerhalb der Architektur des IBM Systems /370-XA kann ein Programm sowohl die 24-Bit- als auch die 31-Bit-Adressierung verwenden. Aufgrund dieses Funktionsmerkmals kann ein Programm auf die neue Architektur umgestellt werden und nach wie vor ohne Modifikation unter Verwendung der 24-Bit-Adressierung ausgeführt werden. Programme können dieses duale Adressierungsmerkmal durch Angabe von zwei neuen Optionen in einigen CMS-Befehlen verwenden, um die Programmattribute zu setzen. Diese Optionen sind Adressiermodus (AMODE) und Residenzmodus (RMODE). Mit AMODE gibt der Benutzer an, ob während der Ausführung des Programms eine 24-Bit- oder eine 31-Bit-Adressierung verwendet werden soll. Ein AMODE von 24 gibt an, daß eine 24-Bit-Adressierung während der Ausführung verwendet werden muß. Ein AMODE von 31 gibt an, daß eine 31-Bit-Adressierung verwendet werden soll. Ein AMODE, der ANY lautet, gibt an, daß ein Programm entweder im 24-Bit- oder 31-Bit- Adressiermodus aufgerufen werden kann. RMODE (Residenzmodus) gibt die Stelle an, an der das Programm im Adreßraum der virtuellen Maschine geladen werden kann. Ein RMODE von 24 gibt an, daß das Programm unterhalb der 16-MB-Grenze geladen werden muß. Ein RMODE, der ANY lautet, gibt an, daß das Programm entweder oberhalb oder unterhalb der 16-MB-Grenze geladen werden kann.
Die folgenden Erläuterungen beziehen sich auf die Zeichnungen, und insbesondere auf Fig. 1, in der der Prozeß, den ein Benutzer bei der Umsetzung der vorliegenden Erfindung durchläuft, als Blockdiagramm dargestellt ist. Wie Funktionsblock 1 zeigt, gibt der Benutzer zuerst den Befehl LOAD aus. Der Lader lädt das Programm (eine TEXT-Datei) in den Speicher und überprüft dabei den Adressiermodus (AMODE) und den Residenzmodus (RMODE). In Funktionsblock 2 führt der Benutzer das Programm mit Hilfe des Befehls START aus. Der Adressiermodus wird eingestellt, bevor das Programm mit der Ausführung beginnt. In Funktionsblock 3 führt der Benutzer einen oder mehrere INCLUDE-Befehle aus. Der Lader liest jede angegebene TEXT-Datei in den Speicher, wodurch ein einzelnes Verbundprogramm mit validiertem AMODE und RMODE gebildet wird. Wie aus Funktionsblock 4 hervorgeht, führt der Benutzer das Programm mit Hilfe des Befehls START aus. In Funktionsblock 5 gibt der Benutzer den Befehl GENMOD (Generate Module) aus, um ein MODUL-Programm aus dem Verbundprogramm zu erstellen, das im Speicher durch die in den Funktionsblöcken 1 und 3 durchgeführten Schritte gebildet wurde. Das Programm einschließlich des AMODE, RMODE und der Architekturanforderungen werden auf einem Datenträger gespeichert. Der Benutzer gibt den Befehl LOADMOD in Funktionsblock 6 aus, um das in Funktionsblock 5 erstellte MODUL in den Speicher einzulesen. Der Lader lädt das (verschiebbare) MODUL an einer von dem RMODE des MODULs bestimmten Adresse in den Speicher. Kann das Programm aufgrund einer architekturbedingten Inkompatibilität nicht in der virtuellen Maschine ausgeführt werden, wird der Ladevorgang zurückgewiesen. In Funktionsblock 7 führt der Benutzer das Programm über den Befehl START aus. Dabei wird der AMODE eingestellt, bevor das Programm mit der Ausführung beginnt. In Funktionsblock 8 ruft der Benutzer das in Funktionsblock 5 erstellte MODUL über seinen Namen auf. Das Programm wird wie in Funktionsblock 6 geladen und wie in Funktionsblock 7 automatisch ausgeführt.
Aus der Logik des in Fig. 2 gezeigten Flußdiagramms geht hervor, wie der CMS-Befehl LOAD Attribute des Residenzmodus (RMODE) und Adressiermodus (AMODE) einer TEXT-Datei, die in den virtuellen Speicher geladen werden soll, zuordnet bzw. diese Attribute verarbeitet. Beginnend in Funktionsblock 10 enthält die Eingabespeichereinheit die TEXT-Datei(en), die von dem Befehl LOAD verarbeitet werden soll(en). Die Entscheidungsfunktionsblöcke 20 und 50 legen fest, ob der RMODE und/oder AMODE als OPTIONEN im LOAD-Befehl angegeben wurden. Wurde(n) RMODE und/oder ANODE angegeben, werden die ihnen zugeordneten Werte in den Entscheidungsblöcken 30 bzw. 60 auf Gültigkeit überprüft. Die gültigen Werte für AMODE sind 24, 31 oder ANY, und die gültigen Werte für RMODE sind 24 und ANY.
Wenn einer dieser Werte ungültig ist, signalisieren die Funktionsblöcke 40 und/oder 70, daß eine Fehlermeldung generiert wird. Wurden sowohl für AMODE als auch für RMODE gültige Werte angegeben, muß ein Test in Entscheidungsblock 90 durchgeführt werden, um zu ermitteln, ob ihre Kombination gültig ist; ist dies nicht der Fall, wird eine Fehlermeldung in Funktionsblock 100 generiert. Die einzig ungültige Kombination ist AMODE 24 in Verbindung mit RMODE ANY.
Wurde AMODE nicht angegeben, wird in Entscheidungsblock 55 geprüft, ob RMODE angegeben wurde. Wurde RMODE ebenfalls nicht angegeben, werden die Werte für AMODE und RMODE aus der Textdatei in Funktionsblock 80 abgerufen. Wurde(n) RMODE und/oder AMODE im Befehl LOAD angegeben (getestet von den Funktionsblöcken 20 und 50), erreicht jeder logische Pfad den Funktionsblock 110, in dem RMODE und AMODE wie angegeben oder gemäß einem Standardwert eingestellt werden.
Nachdem eine gültige Kombination ermittelt und eingestellt wurde, wird ein Test in Entscheidungsblock 120 durchgeführt, um zu bestimmen, ob die Option PRES (PRESERVE - Erhalten) im Befehl LOAD angegeben wurde. Ist dies nicht der Fall, wird das zuvor geladene Programm in Funktionsblock 140 von Fig. 3 aus dem Speicher gelöscht; ansonsten wird ein weiterer Test in Entscheidungsblock 130 durchgeführt, um zu bestimmen, ob die LOAD-Adresse mit der des zuvor geladenen Programms identisch ist. Sind die beiden Adressen identisch, wird das zuvor geladene Programm in Funktionsblock 140 von Fig. 3 aus dem Speicher gelöscht; ansonsten wird die Steuerung an Funktionsblock 150 in Fig. 3 übergeben.
Die Logik des in Fig. 3 gezeigten Flußdiagramms zeigt, wie der CMS-Befehl LOAD als nächstes ermittelt, ob zuvor geladene Programme aus dem Speicher gelöscht werden sollen und an welche Stelle des virtuellen Speichers die TEXT-Datei(en) des Benutzers geladen werden sollen. In Entscheidungsblock 150 wird ein Test durchgeführt, um zu bestimmen, ob RMODE auf 24 eingestellt wurde; ist dies der Fall, wird die Textdatei in Funktionsblock 180 unterhalb der 16-MB-Grenze geladen. Ergibt der Test in Entscheidungsblock 150 ein negatives Ergebnis, wird für RMODE in Funktionsblock 160 ein Wert von ANY festgelegt; und in Entscheidungsblock 170 wird ein Test durchgeführt, um zu ermitteln, ob für AMODE der Wert 24 vorliegt. Ist dies der Fall, wird die Textdatei in Funktionsblock 180 unterhalb der 16-MB-Grenze geladen; ansonsten wird in Funktionsblock 190 für AMODE ein Wert von 31 oder ANY festgelegt. In diesem Fall wird ein Test in Entscheidungsblock 200 durchgeführt, um zu ermitteln, ob die virtuelle Maschine einen Speicher von mehr als 16 MB besitzt. Ist die benötigte Speichermenge oberhalb von 16 MB nicht verfügbar, wird die TEXT- Datei des Programms unterhalb der 16-MB-Grenze in Funktionsblock 210 geladen; ist diese Speichermenge jedoch verfügbar, wird die TEXT-Datei in Funktionsblock 220 oberhalb der 16 MB- Grenze geladen. In beiden Fällen wird der Ladevorgang an Funktionsblock 230 beendet.
Der Befehl GENMOD (Generate Module) wird erweitert, um verschiebbare Module in einer Umgebung mit 24-Bit- oder 31-Bit- Adressierung zu unterstützen. Er speichert die Option AMODE oder RMODE (oder beide), sofern angegeben, und setzt den bei der Erstellung der Assembler-Quelle oder beim Laden (LOAD) angegebenen Wert für AMODE oder RMODE außer Kraft. Programme, die in beiden (24-Bit- und 31-Bit-) Umgebungen ausgeführt werden müssen, sollten mit den Optionen AMODE ANY oder 31 und RMODE ANY generiert werden. Als zusätzliche Option, die weiter unten ausführlicher beschrieben wird, kann eine der beiden Optionen, IBM System /370 oder IBM System /370-XA, angegeben werden. Wird die Option IBM System /370 angegeben, kann das Programm nur auf einer virtuellen Maschine des IBM Systems /370 ausgeführt werden. Wird keine Option angegeben, kann das Modul auf einer Maschine im S/370- oder im S/370-XA- Modus ausgeführt werden. Soll z.B. ein Modul generiert werden, das in beiden Umgebungen eingesetzt werden kann und verschiebbar ist, würden die folgenden CMS-Befehle verwendet werden:
LOAD PROG ( RLDSAVE
GENMOD PROG ( AMODE ANY RMODE ANY
Die Logik des in Fig. 4 dargestellten Flußdiagramms zeigt, daß der Benutzer, der den CMS-Befehl GENMOD aufgerufen hat, die AMODE- und/oder RMODE-Attribute der gerade in den virtuellen Speicher geladenen Textdatei/en außer Kraft setzen kann. Der CMS-Befehl GENMOD wird zur Erstellung eines Programms im MODUL-Dateiformat aus der/den gerade in den virtuellen Speicher geladenen Textdatei/en verwendet. Diese MODUL- Datei wird auf einem Datenträger gespeichert und kann danach jederzeit wieder ausgeführt werden. Der CMS-Befehl GENMOD ordnet der MODUL-Datei die AMODE- und RMODE-Attribute zu bzw. verarbeitet diese.
Bei der Ausgabe des GENMOD-Befehls in Funktionsblock 310 von Fig. 4 können Optionen angegeben werden, die bewirken, daß das betreffende Attribut der MODUL-Datei zugeordnet wird. Ist die AMODE-Option (d.h. der AMODE-Wert) in Entscheidungsblock 320 angegeben, muß ein Test in Entscheidungsblock 330 durchgeführt werden, um zu ermitteln, ob ein gültiger Wert vorliegt. Ist dies nicht der Fall, wird die Verarbeitung unterbrochen, und eine Fehlermeldung wird in Funktionsblock 340 ausgegeben; ansonsten wird der Wert in Funktionsblock 350 für eine mögliche spätere Prüfung der AMODE/RMODE-Kombination gespeichert, und die Steuerung geht zum Entscheidungsblock 360, in dem ein Test durchgeführt wird, um festzustellen, ob die RMODE-Option angegeben ist. Trifft dies zu, muß ein Test in Entscheidungsblock 370 durchgeführt werden, um festzustellen, ob der für die RMODE-Option angegebene Wert gültig ist. Ist dies nicht der Fall, wird die Verarbeitung gestoppt, und eine Fehlermeldung wird in Funktionsblock 380 ausgegeben; ansonsten wird der Wert in Funktionsblock 390 für eine mögliche spätere Prüfung der AMODE/RMODE-Kombination gespeichert.
Für den Fall, daß RMODE nicht angegeben wurde, muß eine Prüfung in Entscheidungsblock 400 durchgeführt werden, um zu ermitteln, ob weder AMODE noch RMODE angegeben wurden. Wird zunächst angenommen, daß der AMODE-Wert angegeben wurde, wird in Funktionsblock 410 der angegebene AMODE-Wert dem MODUL zugeordnet, und der aus der Textverarbeitung gespeicherte RMODE-Wert wird dem MODUL zugeordnet. Wurde hingegen keiner der beiden Werte angegeben, werden sowohl der AMODE-Wert als auch der RMODE-Wert, die während der Textverarbeitung gespeichert wurden, dem MODUL in Funktionsblock 420 zugeordnet.
Für die folgende Beschreibung ist wieder Funktionsblock 390 heranzuziehen: Wird ein gültiger RMODE-Wert gefunden und gespeichert, muß eine Prüfung in Entscheidungsblock 430 durchgeführt werden, um zu ermitteln, ob auch ein Wert für AMODE angegeben wurde. Ist dies nicht der Fall, wird der angegebene RMODE-Wert dem MODUL zugeordnet, und der während der Textverarbeitung gespeicherte AMODE-Wert wird dem MODUL in Funktionsblock 460 zugeordnet. Wenn gültige Werte für AMODE und RMODE in den Funktionsblöcken 350 und 390 gespeichert wurden, wird in Entscheidungsblock 440 eine Prüfung durchgeführt, um zu ermitteln, ob die Wertekombination gültig ist. Die einzig ungültige AMODE/RMODE-Kombination ist AMODE 24 und RMODE ANY. Wurde diese Kombination angegeben, wird der Befehl GENMOD beendet, und eine Fehlermeldung wird in Funktionsblock 450 ausgegeben. Wurde dagegen eine gültige Kombination angegeben, werden die angegebenen Werte für AMODE und RMODE dem MODUL in Funktionsblock 470 zugewiesen.
Die Logik des in Fig. 5 dargestellten Flußdiagramms veranschaulicht den Prozeß, durch den der Benutzer, der den CMS- Befehl GENMOD gegeben hat, der erstellten MODUL-Datei Architekturabhängigkeit oder Architekturunabhängigkeit zuordnen kann. Der CMS-Befehl GENMOD ordnet der MODUL-Datei ein Architekturattribut zu und verarbeitet dieses.
Nach Zuordnung der AMODE- und RMODE-Attribute ist das Architekturattribut des IBM Systems /370 und/oder des IBM Systems /370-XA das nächste MODUL-Attribut, das zugeordnet werden muß. Das Architekturattribut gibt an, ob das MODUL von der einen oder anderen Architektur abhängig sein soll oder ob das Modul architekturunabhängig sein soll. Werden für ein MODUL keine Architekturabhängigkeiten angegeben, kann dieses Programm auf einer virtuellen Maschine entweder im IBM System /370-Modus oder im IBM System /370-XA-Modus ausgeführt werden. Ist für ein Modul S/370 als Architekturattribut angegeben, kann es nur auf einer virtuellen Maschine im IBM System /370-Modus ausgeführt werden. Ebenso kann ein MODUL, für das S/370-XA als Attribut angegeben ist, nur auf einer virtuellen Maschine im IBM System /370-XA-Modus ausgeführt werden.
Bezugnehmend auf Fig. 5 wird zuerst eine Prüfung in Entscheidungsblock 480 durchgeführt, um zu bestimmen, ob eine der beiden Optionen (S/370 oder S/370-XA) im Befehl GENMOD angegeben wurde. Wurde keine der beiden Optionen angegeben, wird Architekturunabhängigkeit in Funktionsblock 490 als MODUL-Attribut zugewiesen. Das gleiche Ergebnis erhält man, wenn beide Attribute (S/370 und S/370-XA) angegeben werden, wie durch die Prüfung in Entscheidungsblock 500 ermittelt wird; d.h. dem MODUL wird ein Attribut für Architekturunabhängigkeit in Funktionsblock 510 zugeordnet. Wird in den Entscheidungsblöcken 480 und 500 ermittelt, daß nur eine der Optionen S/370 oder S/370-XA angegeben wurde, muß ein Test in Entscheidungsblock 520 durchgeführt werden, um zu ermitteln, ob es sich bei dem angegebenen Attribut um das S/370-Attribut handelt. Ist dies der Fall, wird das Attribut für S/370-Abhängigkeit dem MODUL in Funktionsblock 530 zugeordnet; ansonsten wird das Attribut für S/370-XA-Abhängigkeit dem MODUL in Funktionsblock 540 zugeordnet. Nachdem ein Architekturattribut dem MODUL zugeordnet wurde, wird die MODUL-Datei in Funktionsblock 550 auf den Datenträger geschrieben.
Die Logik des Flußdiagramms in Fig. 6 veranschaulicht, ob eine CMS MODUL-Datei auf der Basis ihres beim Aufrufen des Befehls GENMOD angegebenen Architekturattributs in den virtuellen Speicher geladen werden kann oder nicht. Sie zeigt ferner, wie das MODUL auf der Basis des Attributs RMODE, das bei der Verarbeitung des GENMOD-Befehls zugewiesen wurde, in den virtuellen Speicher geladen wird, und ob zuvor geladene Programme aus dem virtuellen Speicher gelöscht werden oder im virtuellen Speicher resident bleiben sollen.
In der folgenden Beschreibung wird auf Fig. 6 Bezug genommen. Wird der LOADMOD-Befehl bei Funktionsblock 610 entweder extern oder innerhalb des Programms CMS ausgegeben, müssen bestimmte Modulattribute geprüft werden, um zu ermitteln, ob das MODUL geladen werden kann, wohin das MODUL geladen werden kann und ob zuvor geladene Programme im Speicher bleiben können oder aus dem Speicher gelöscht werden müssen. Beim ersten in Entscheidungsblock 620 durchgeführten Test wird ermittelt, ob sich die Maschine gerade im S/370-XA-Modus befindet. Ist der S/370-XA-Modus aktiv, wird ein Test im Entscheidungsblock 630 durchgeführt, um zu ermitteln, ob das zu ladende MODUL eine S/370-Architekturabhängigkeit aufweist. Wird beim Test der zu ladenden MODUL-Datei ein S/370-Architekturattribut ermittelt, wird der Befehl LOADMOD beendet, und eine Fehlermeldung wird in Funktionsblock 640 ausgegeben. Ist die virtuelle Maschine nicht im S/370-XA-Modus, sondern im S/370-Modus, wird MODUL in Entscheidungsblock 650 getestet, um zu bestimmen, ob es ein S/370-XA-Architekturattribut besitzt. Trifft dies zu, wird der Befehl LOADMOD beendet, und eine Fehlermeldung wird in Funktionsblock 660 ausgegeben.
Nachdem das Architekturattribut ohne Fehler verarbeitet wurde, besteht der nächste Schritt darin, die (verschiebbare) MODUL-Datei entsprechend dem RMODE-Attribut in den virtuellen Speicher zu laden. In Enscheidungsblock 670 wird ein Test durchgeführt, um zu bestimmen, ob dem MODUL ein Attribut des Typs RMODE 24 zugeordnet ist: trifft dies zu, wird Speicher des entsprechenden Typs angefordert, und der ausführbare Teil der MODUL-Datei wird in Funktionsblock 680 unterhalb der 16 MB-Adresse geladen. Lautet das RMODE-Attribut dagegen ANY, kann das MODUL an einer beliebigen Stelle im Adreßraum des virtuellen Speichers geladen werden, d.h. entweder oberhalb oder unterhalb der 16 MB-Adresse. In Entscheidungsblock 690 muß ein Test durchgeführt werden, um zu ermitteln, ob Speicher oberhalb der 16 MB-Adresse verfügbar ist. Dies ist nur in einer virtuellen Maschine im S/370-XA-Modus mit mindestens 17 MB (oder mehr) an definiertem Speicher möglich. Ist das Ergebnis des Tests in Entscheidungsblock 690 negativ, wie dies bei einer virtuellen Maschine im S/370-Modus immer der Fall ist, wird das MODUL unterhalb der 16 MB-Adresse in Funktionsblock 700 geladen; ist das Ergebnis positiv, wird das MODUL in Funktionsblock 710 oberhalb der 16 MB-Adresse geladen.
Nachdem die MODUL-Datei in den Speicher geladen wurde, wird ein Test in Entscheidungsblock 720 durchgeführt, um zu ermitteln, ob zuvor geladene Programme (TEXT und MODULE) im Speicher verbleiben oder aus ihm gelöscht werden sollen. Mögliche Eingaben für diesen Test sind PRES'NOPRES (Preserve (Erhalten) oder No Preserve (Nicht erhalten)) für LOADMOD und MAP'NOMAP (Zuordnen oder Nicht zuordnen) und/oder STR'NOSTR (Speicher initialisieren oder Speicher nicht initialisieren) als MODUL-Attribute. Wurde die Option NOPRES angegeben oder als Standardwert im Befehl LOADMOD verwendet, und ist dem MODUL eines der Attribute MAP oder STR zugeordnet, werden alle zuvor geladenen Programme in Funktionsblock 730 aus dem virtuellen Speicher gelöscht. In jedem Fall wird in Fig. 7 die Steuerung dann an Funktionsblock 740 übergeben.
Nachdem das Modul in den Speicher geladen und eine Entscheidung für zuvor geladene Programme getroffen wurde (d.h. im Speicher erhalten oder aus dem Speicher löschen), kann das MODUL-Programm ausgeführt werden. Wurde der LOADMOD-Befehl extern ausgegeben, kann die MODUL-Datei über den CMS-Befehl START ausgeführt werden. Wurde der Befehl LOADMOD intern vom CMS SVC-Handler (DMSITS) ausgegeben, bedeutet dies, daß das MODUL über seinen Dateinamen aufgerufen wurde und in den Speicher geladen und dort ausgeführt wird.
Fig. 7 veranschaulicht die Logik, die bei der Bestimmung durchlaufen wird, in welchem Adressiermodus (24 oder 31) das aufgerufene MODUL die Steuerung erhalten soll. Beim Aufrufen des MODULS über seinen Dateinamen werden verschiedene vorbereitende Funktionen, wie z.B. das Speichern von Registern und Anfordern eines Programmsicherungsbereichs, in Funktionsblock 740 durchgeführt. Nach den vorbereitenden Funktionen wird in Entscheidungsblock 750 ein Test auf das Vorhandensein des AMODE ANY-Attributs durchgeführt. Besitzt das MODUL ein AMODE ANY-Attribut, dann muß das MODUL die Steuerung in demselben Adressiermodus wie das Programm, das seine Ausführung angefordert hat (d.h. das aufrufende Programm), erhalten. Das AMODE-Attribut des aufrufenden Programms wird in Entscheidungsblock 760 getestet, und liegt nicht der Adressiermodus 31 vor, erhält das aufgerufene MODUL in Funktionsblock 770 die Steuerung im Adressiermodus 24; ansonsten wird in Funktionsblock 780 die Steuerung an das MODUL im Adressiermodus 31 übergeben.
Wird in Entscheidungsblock 750 ermittelt, daß AMODE nicht ANY ist, wird ein Test in Entscheidungsblock 790 durchgeführt, um zu ermitteln, ob das AMODE-Attribut 31 ist. Trifft dies zu, wird in Funktionsblock 800 die Steuerung an das MODUL im Adressiermodus 31 übergeben; ansonsten wird in Funktionsblock 810 die Steuerung im Adressiermodus 24 übergeben.
Fig. 8 veranschaulicht die möglichen Kombinationen aus Programmresidenzmodus (RMODE) und Adressiermodus (AMODE) sowie die verschiedenen Verfahren, die das Programm zum Aufrufen eines anderen Programms mit demselben oder einem anderen Adressier-/Residenzmodus verwenden kann. Bei der virtuellen Maschine I sind die Programme A und B beide an Adressen unterhalb von 16 MB in der Maschine geladen. Der Adressiermodus (AMODE) von Programm A ist 24, und der Adressiermodus (AMODE) von Programm B ist 31. Programm A ruft Programm B entweder durch Ausgabe des Makros AMODESW CALL auf, um den Adressiermodus für Programm B auf 31 zu setzen, oder durch Ausgabe des Makros AMODESW CALL an Programm B, woraufhin Programm B dann den Makro AMODESW SET ausgibt, um AMODE inline auf 31 zu setzen. Programm B kann zu Programm A über den Makro AMODESW RETURN zurückkehren.
In der virtuellen Maschine II ist Programm A in der Maschine an einer Adresse unterhalb von 16 MB geladen, und Programm B ist in der Maschine an einer Adresse oberhalb von 16 MB geladen. Der Adressiermodus (AMODE) von Programm A ist 24, und der Adressiermodus (AMODE) von Programm Bist 31. Programm B ruft Programm A entweder durch Ausgabe des Makros AMODESW CALL auf, um den Adressiermodus für Programm A auf 24 zu setzen, oder durch Ausgabe des Makros AMODESW CALL an Programm A, woraufhin Programm A den Makro AMODESW SET ausgibt, um den AMODE inline auf 24 zu setzen. Programm B kann über den Makro AMODESW RETURN zu Programm A zurückkehren.
In der virtuellen Maschine III sind die Programme A, B und C in der Maschine an einer Adresse oberhalb von 16 MB geladen, und Programm D ist in der Maschine an einer Adresse unter 16 MB geladen. Alle Programme A, B, C und D können jeweils voneinander in einer beliebigen Reihenfolge mit dem Makro AMODESW CALL aufgerufen werden, wobei keine Umschaltung des AMODE erforderlich sind, da alle Programme mit einem AMODE von 31 Bits erstellt wurden.
In der virtuellen Maschine IV sind die Programme A und B in einer Maschine geladen, die nur über einen Adreßraum von 16 MB verfügt. Da diese Maschine nur 16 MB Speicher besitzt, verwendet Programm B zum Aufrufen von Programm A den Makro AMODESW CALL, und es findet keine Umschaltung statt.
Die Konzepte, die in der Großrechnerumgebung, vertreten durch die Rechnerfamilie IBM System /370- und IBM System /370-XA, implementiert wurden, können auch in anderen Umgebungen implementiert werden, um Vorteile der Kompatibilität zwischen Systemen zu verwirklichen. Beispielsweise stellen die Mikroprozessorenfamilie 68000/68020 von Motorola und die Mikroprozessorenfamilie 8086/80286/80386 von Intel Umgebungen bereit, die der Umgebung des IBM Systems /370 und IBM Systems /370-XA nicht unähnlich sind. Der Mikroprozessor 68000 von Motorola verfügt über einen 16-Bit-Adreßbus, während der Mikroprozessor 68020 mit einem 32-Bit-Adreßbus ausgestattet ist. Der erstgenannte Prozessortyp wird in einer Reihe häufig eingesetzter Mikrocomputer wie z.B. den Apple Macintosh(TM) eingesetzt, während der zuletzt genannte Prozessor der Defacto- Standard in UNIX(TM)-gestützten Minicomputern von Firmen wie Sun Microsystems und Apollo Computers ist. Die 8086- und 80286-Mikroprozessoren von Intel besitzen 16-Bit-Adreßbusse, während der 80386-Prozessor einen 32-Bit-Adreßbus aufweist. Die Intel-Mikroprozessorenfamilie kommt in der Familie der IBM PS/2-Systeme (IBM Personal System 2) zum Einsatz. Ein virtueller Maschinenbetrieb ist auf allen Systemen außer solchen mit einem Intel 8086-Mikroprozessor möglich.
Somit stellt die Anwendung der Konzepte der vorliegenden Erfindung auf andere und unterschiedliche Umgebungen als die bevorzugte IBM System /370- und IBM System /370-XA-Großrechnerumgebung lediglich eine Erweiterung der Grundlagen dieser Erfindung dar. Allgemein ausgedrückt bedeutet dies, daß ein Programmlader mit Optionen versehen werden würde, die in der Lage wären, mehrere Adressier- und Residenzmodi und Architekturabhängigkeiten in den zu ladenden und auszuführenden Programmen zu erkennen. Der größte Vorteil wird erzielt, wenn verschiedene Adressiermodi in demselben Programm untergebracht werden.

Claims

1. In einem Betriebssystem für virtuelle Maschinen, das auf einem Rechner ausgeführt wird, der einer Rechnerfamilie mit verschiedenen Architekturen angehört, ein Verfahren zum Laden eines Programms, das erste oder zweite Adressierbreiten in einer auf dem Rechner laufenden virtuellen Maschine haben kann, welches die folgenden Schritte umfaßt:

Prüfen eines Ladebefehls auf ein Residenzmodus-Attribut, das entweder der ersten Adressierbreite oder einer beliebigen Adressierbreite (150) entspricht;

Prüfen des Ladebefehls auf ein Adressiermodus-Attribut, das der ersten oder zweiten Adressierbreite oder einer beliebigen Adressierbreite (170) entspricht; und

sofern der Residenzmodus ein Attribut besitzt, das der ersten Adressierbreite entspricht, Laden des Programms in einen Adreßraum unterhalb einer vorbestimmten Adreßgrenze (180); oder

sofern der Residenzmodus ein Attribut besitzt, das einer beliebigen Adressierbreite entspricht, und der Adressiermodus ein Attribut besitzt, das der ersten Adressierbreite entspricht, Laden des Programms in einen Adreßraum unterhalb der vorbestimmten Adreßgrenze (280); doch

sofern der Residenzmodus ein Attribut besitzt, das einer beliebigen Adressierbreite entspricht, und der Adressiermodus ein Attribut besitzt, das der zweiten Adressierbreite oder einer beliebigen Adressierbreite entspricht, Laden des Programms in einen Adreßraum oberhalb der vorbestimmten Adreßgrenze, sofern genügend Speicher verfügbar ist (220).

2. Das Verfahren wie in Anspruch 1 offenbart, das weiterhin die folgenden Schritte umfaßt, wenn Attribute für den Residenzmodus und/oder Adressiermodus nicht in dem Ladebefehl angegeben sind:

Lesen einer dieses Programm umfassenden Textdatei, um die Residenz- und Adressiermodi (80) zu ermitteln; und

Einstellen der Residenz- und Adressiermodi wie in der Textdatei angegeben (110).

3. Das Verfahren wie in den Ansprüchen 1 oder 2 offenbart, mit einem Verfahren zum Generieren eines Programmmoduls in Antwort auf einen Befehl zum Generieren eines Moduls (GENMOD), für den ggf. Optionen für die erste oder zweite Adressierbreite angegeben wurden, welches die folgenden Schritte umfaßt:

Testen, ob der Befehl zum Generieren eines Moduls ein Adressiermodusattribut für die erste, zweite oder eine beliebige Adressierbreite enthält (320);

Testen, ob der Befehl zum Generieren eines Moduls ein Residenzmodusattribut für die erste oder eine beliebige Adressierbreite enthält (360);

Zuordnen der angegebenen Attribute für den Adressierund Residenzmodus zu dem Programmodul (470); und

Schreiben dieses Programmoduls in den Speicher mit den zugeordneten Attributen für den Adressier- und Residenzmodus (550).

4. Das Verfahren wie in Anspruch 3 offenbart, das - wenn einer der Adressier- und Residenzmodi nicht angegeben ist - weiterhin den Schritt des Zuordnens eines Standardattributs für den Adressier- und/oder Residenzmodus zu dem Programmodul umfaßt, bevor in den externen Speicher (410, 420, 460) geschrieben wird.

5. Das Verfahren wie in Anspruch 3 oder 4 offenbart, das weiterhin die folgenden Schritte umfaßt:

Prüfen des Modulgenerierbefehls auf eine Angabe für Architekturabhängigkeit (480, 500, 520); und

Zuordnen eines angegebenen Attributs für Architekturabhängigkeit zu dem Programmodul, oder wenn keine Architekturabhängigkeit angegeben ist, Zuordnen eines Attributs für Architekturunabhängigkeit zu dem Programmodul, bevor das Programmodul in den externen Speicher geschrieben wird (490, 510, 530, 540).

6. Das Verfahren wie in mindestens einem der Ansprüche 1 bis 5 offenbart, das weiterhin die folgenden Schritte umfaßt

Ermitteln, ob ein angegebener Adressiermodus gültig ist (60, 330);

Ermitteln, ob ein angegebener Residenzmodus gültig ist (30, 370);

Ermitteln, ob eine Kombination der angegebenen Adressier- und Residenzmodi gültig ist (90, 440); und

wenn irgendeiner der angegebenen Adressier- und Residenzmodi oder die Kombination aus diesen Modi nicht gültig ist, Ausgeben einer Fehlermeldung in Antwort auf den Ladebefehl oder den Modulgenerierungsbefehl (40, 70, 100, 340, 380, 450).

7. Das Verfahren wie in mindestens einem der Ansprüche 1 bis 6 offenbart, mit einem Verfahren zum Laden eines Programmoduls, das Bestandteil eines Computerprogramms ist, welches sich aus mehreren Programmodulen zusammensetzt, wobei jedes dieser Module erste oder zweite Adressierbreiten besitzt, und das die folgenden Schritte umfaßt:

Prüfen des Architekturtyps der virtuellen Maschine in Antwort auf einen Befehl zum Laden eines Moduls (620);

Prüfen des Programmoduls auf Vorhandensein eines Attributs für Architekturabhängigkeit (630, 650);

Prüfen des Befehls zum Laden eines Moduls auf Vorhandensein eines Residenzmodusattributs, das der ersten Adressierbreite (670) entspricht; und

sofern die Architektur der virtuellen Maschine und die Architekturabhängigkeit des Programmoduls kompatibel sind und sofern das Residenzmodusattribut des Programmoduls der ersten Adressierbreite entspricht, Laden des Programmoduls in einen Adreßraum, der unter einer vorbestimmten Adreßgrenze liegt (680); jedoch

wenn die Architektur der virtuellen Maschine und die Architekturabhängigkeit des Programmoduls kompatibel sind und wenn das Residenzmodusattribut des Programm-Moduls der zweiten Adressierbreite entspricht, Laden des Programmoduls in einen Adreßraum oberhalb der vorbestimmten Adreßgrenze, wenn genügend Speicher verfügbar ist (710).

8. Das Verfahren wie in Anspruch 7 offenbart, das weiterhin die folgenden Schritte umfaßt:

Einrichten der virtuellen Maschine, um die Steuerung an das im Speicher geladene Programmodul zu übergeben, wenn das Programmodul von einem Ausführungsbefehl (740) aufgerufen wird;

Prüfen des Programmoduls auf Vorhandensein eines Adressiermodusattributs, das der zweiten Adressierbreite oder einer beliebigen Adressierbreite in Antwort auf den Ausführungsbefehl (750) entspricht; und

wenn das Attribut für den Adressiermodus weder der zweiten Adressierbreite noch einer beliebigen Adressierbreite entspricht, Übergabe der Steuerung an das Programmodul in einem Adressiermodus, der der ersten Adressierbreite entspricht (810).

9. Das Verfahren wie in Anspruch 7 oder 8 offenbart, das weiterhin die folgenden Schritte umfaßt:

Ermitteln, ob die Architektur der virtuellen Maschine und die Architekturabhängigkeit des Programmoduls inkompatibel sind (630, 650); und

sofern sie inkompatibel sind, Ausgeben einer Fehlermeldung in Antwort auf den Befehl zum Laden des Moduls (640, 660).

10. Das Verfahren wie in mindestens einem der Ansprüche 7 bis 9 offenbart, das weiterhin die folgenden Schritte umfaßt:

Laden einer Vielzahl von Programmodulen mit verschiedenen Architekturabhängigkeiten und Residenzmodi; und Ausführen eines aus diesen Programmodulen bestehenden Programms durch Aufrufen der Programmodule über eine direkte Verzweigungsverbindung im Adressiermodus eines Z ielprogrammoduls.

11. Das Verfahren wie in mindestens einem der Ansprüche 7 bis 10 offenbart, das weiterhin den Schritt des dynamischen und interaktiven Außerkraftsetzens des Adressiermodus und Residenzmodus des Programmoduls an einem beliebigen Punkt des Ladevorgangs umfaßt.

12. Das Verfahren wie in mindestens einem der Ansprüche 1 bis 11 offenbart, das weiterhin die folgenden Schritte umfaßt:

Prüfen auf das Vorhandensein eines Attributs für die Option "Im Speicher erhalten" in Antwort auf den Ladebefehl oder auf den Modulladebefehl (120, 720); und

ist das Attribut für die Option "Im Speicher erhalten" nicht vorhanden, Löschen der zuvor in den Speicher geladenen Programme (140, 730).

13. Das Verfahren wie in mindestens einem der Ansprüche 1 bis 12 offenbart, das weiterhin die folgenden Schritte umfaßt:

Prüfen des Ladebefehls oder Modulladebefehls, um zu bestimmen, ob das zu ladende Programm oder Programmodul an einer Adresse im Speicher geladen werden soll, an der sich bereits ein zuvor geladener Programmtext oder ein nicht verschiebbares Programmodul befindet; und

sofern das zu ladende Programm oder Programmodul an dieser Adresse geladen werden muß, Löschen des zuvor geladenen Programmtextes oder des nicht verschiebbaren Programmoduls.