DE3688191T2

DE3688191T2 - Editor für virtuelle Maschinen.

Info

Publication number: DE3688191T2
Application number: DE86116727T
Authority: DE
Inventors: Marc Mordekhai Eshel
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1985-12-30
Filing date: 1986-12-02
Publication date: 1993-10-07
Anticipated expiration: 2006-12-03
Also published as: EP0231472A3; DE3688191D1; EP0231472B1; US4831541A; JPS62159239A; EP0231472A2

Description

Die vorliegende Erfindung bezieht sich auf ein Verfahren zur Editierung von Daten im virtuellen Speicher in einem System, das ein Steuerprogramm, ein Betriebssystem und eine Anzeigeeinheit enthält
In Computersystemen werden numerische und alphanumerische Informationen häufig gespeichert und später zum Anzeigen, Drucken, Ändern, Kopieren oder zu anderen Zwecken abgerufen. Da Computersysteme immer komplexer werden, wird es immer schwieriger, nur auf ausgewählte gespeicherte Informationen zuzugreifen und solche Daten zu ändern, ohne daß andere auf demselben Datenträger gespeicherte Informationen betroffen sind.
Editoren sind entwickelt worden, die dem Benutzer ermöglichen, auf einen relativ kleinen Teil der gespeicherten Informationen zuzugreifen und diese wie gewünscht zu ändern. Ein Editor für Realspeicher und virtuellen Speicher wird z. B. im IBM Technical Disclosure Bulletin, Band 21, Nr. 12, Seite 4946 (Mai 1979), von N. Inaba und Mitarbeitern unter dem Titel "Programmer Aid for the Alter/Display Facility" beschrieben.
Aus Communications of the ACM, Band 23, Nr. 3, März 1980, Seite 154 bis 158, ist aus einem Artikel von C. W. Fraser mit dem Titel "A generalised text editor" ein anderer Editortyp bekannt. Dieser Editor wurde als einheitliche Benutzerschnittstelle für alle durchzuführenden Arten von Editierungsvorgängen entwickelt, wie z. B. das Ändern von Dateien, Textverarbeitung usw. In dem Dokument wird die Benutzerschnittstelle für einen solchen allgemein anwendbaren Editor beschrieben. Außerdem enthält es eine Beschreibung der grundlegenden Kenntnisse, die für die Verwendung der Befehle des Editors erforderlich sind.
In einem Artikel von R. A. MacKinnon im IBM Systems Journal, Band 18, Nr. 1, 1979, Seite 18 bis 46, mit dem Titel "The changing virtual machine environment: Interfaces to real hardware, virtual hardware, and other virtual machines" werden auf den Seiten 34 bis 39 die Prinzipien der Kommunikation zwischen virtuellen Maschinen beschrieben. Es wird beschrieben, daß virtuelle Maschinen Anforderungen von anderen interaktiven virtuellen Maschinen akzeptieren können, um sie mit Einrichtungen wie einem Verwaltungssystem für relationale Datenbanken zu verbinden. Die Herstellung der Verbindung ist dem Benutzer der verbindenden Maschine nicht bekannt und wird nicht von ihm gesteuert. Andere Benutzer der verbundenen Maschine spüren keine Auswirkungen dieser Verbindung, da der Benutzer der verbindenden Maschine den Betrieb der verbundenen Maschine nicht direkt steuern kann.
Computersysteme verfügen normalerweise über sogenannten Realspeicher. Der Realspeicher ist der hauptsächliche, physische Speicher jedes Computersystems. Er kann aus Speichereinheiten wie z. B. Arbeitsspeicher (Random Access Memory - RAM) bestehen, in die Informationen geschrieben werden können. Der Realspeicher kann in Mehrplatzsystemumgebungen und Time-Sharing-Umgebungen für jede durchzuführende Task erneut benutzt werden. Auf diese Weise hat jeder am betreffenden Computersystem arbeitende Benutzer während der Verarbeitung seiner Task Zugriff auf den gesamten Realspeicher.
Aus einer Menge von Benutzern hat somit jeder Benutzer zu einem gegebenen, vorbestimmten Zeitpunkt Zugriff auf den gesamten Realspeicher, da Informationen aus dem Realspeicherbereich auf einen permanenten oder halbpermanenten Datenträger, wie z. B. eine Magnetplatte, aus- und dann wieder eingelagert werden. Auf diese Weise sind beim Zugreifen eines Benutzers auf Informationen die Daten, die für andere Benutzer auf Datenträgern gespeichert sind, für den aktuellen Benutzer nicht sichtbar und verringern nicht den Speicherplatz des aktuellen Benutzers.
Ein anderes Konzept, das sich in Computersystemen, besonders in Mehrplatzsystemumgebungen, als nützlich erwiesen hat, wird allgemein als virtueller Speicher bezeichnet. Ein virtueller Speicher ermöglicht zwei oder mehr Benutzern den Zugriff auf den Realspeicher des Computersystems; jedoch werden die adressierbaren Positionen automatisch in die Originaladressen umgesetzt. Dadurch kann aus einer Menge von Benutzern jeder Benutzer denken, er greife auf Informationen in denselben Speicherpositionen zu, beginnend am unteren Ende des Realspeichers. Die Größe des virtuellen Speichers wird durch das Adressierungsschema des Computersystems und die Größe des verfügbaren Zusatzspeichers beschränkt, nicht durch die tatsächliche Anzahl an Hauptspeicherpositionen.
Eine sogenannte virtuelle Maschine ist eine funktionelle Simulation eines Computers und seiner zugehörigen peripheren Einheiten. Somit wird eine virtuelle Maschine durch ein geeignetes Betriebssystem gesteuert. Es ist festzuhalten, daß bei virtuellen Maschinen insofern ähnliche Konzepte verwendet werden wie beim virtuellen Speicher, als alle peripheren Einheiten des Systems im Hinblick auf jeden einzelnen Benutzer ausschließlich vom Betriebssystem VM gesteuert werden. Einzelheiten zum VM-Konzept können den folgenden Veröffentlichungen der IBM entnommen werden: "Virtual Machine/System Product General Information", "Virtual Machine/System Product Introduction", "Virtual Machine/System Product System Logic and Problem Determination Guide Volume 1 (CP)" und "Virtual Machine/System Product CMS User's Guide".
Da es sich bei den gespeicherten Informationen um vertrauliche Daten handeln kann, ist es häufig schwierig, den Speicher ganz oder teilweise zu editieren, ohne einen besonderen Sicherheitscode oder eine Entsperrungseinheit zu verwenden.
Bisher verwendete ein Benutzer oder Programmierer, wenn er den Speicher einer virtuellen Maschine anzeigen wollte, einen Befehl des Steuerprogramms, z. B. den Befehl DISPLAY, gefolgt von einer Adresse, um den Inhalt des angeforderten Speicherbereichs anzuzeigen. Wollte der Benutzer einige der angeforderten Daten ändern, gab er dann den Befehl STORE ein, gefolgt von der zu ändernden Position und den neuen Daten. Dieser Vorgang war häufig sehr zeitaufwendig, wenn der Programmierer mehrere verschiedene Speicherpositionen ändern wollte. Darüber hinaus gab es die Möglichkeit, daß die falsche Adresse eingegeben und die Speicheroperation mit der falschen Position durchgeführt wurde, so daß sich bei beiden Adressen falsche Daten befanden: bei der eigentlich zu ändernden und bei der fälschlicherweise geänderten Adresse. Die Editoren erforderten also bei der Verwendung eine große Sorgfalt, denn wenn beim Editieren ein Fehler gemacht wurde, waren die betroffenen Dateien eventuell unwiderruflich beschädigt oder verloren.
Ein Editor, der die Informationen in einem Datenblock analysiert, bevor dem Benutzer das Ändern der Daten erlaubt wird, ist nicht sinnvoll. Wenn z. B. bei einem Datenblock, der Verzeichnisinformationen mit Zeigern und Adressen enthält, eine der Adressen falsch gespeichert wird, greift das System auf die falsche Position zu, so daß der Datenfluß in die falsche Richtung erfolgt, was zu abnormalen und unvorhersehbaren Operationen führt.

Zusammenfassung der Erfindung

Die Aufgabe der Erfindung ist daher die Bereitstellung eines Systems, in dem ein erster Benutzer auf den virtuellen Speicher eines zweiten Benutzers zugreifen kann.
Gemäß der vorliegenden Erfindung handelt es sich um ein System, in dem ein erstes Betriebssystem mit virtuellem Speicher einen im Speicher geladenen Editor enthält, wobei der Editor eine Routine SCIF aufruft, um auf Daten im virtuellen Speicher eines zweiten Betriebssystems zuzugreifen, die Daten an einer Anzeigeeinheit anzeigt, es dem Benutzer des ersten Betriebssystems ermöglicht, die Daten zu verändern, und die veränderten Daten mittels eines an sich bekannten Befehls CP SEND in den virtuellen Speicher des zweiten Betriebssystems zurückgibt, wobei der Benutzer des zweiten Betriebssystems von den beschriebenen Vorgängen nichts merkt.
Bei der Anzeigeeinheit kann es sich um eine Datenstation oder einen Drucker handeln.
In einem Ausführungsbeispiel der Erfindung sind zwei virtuelle Maschinen, die einander entsprechende virtuelle Speicherbereiche haben, logisch miteinander verbunden. Der Editor erlaubt dem ersten Betriebssystem das Drucken, Anzeigen, Ändern und sonstige Steuern und Verarbeiten von Informationen, die im virtuellen Speicherbereich eines zweiten Betriebssystems gespeichert sind. Auf Datenblöcke wird unabhängig davon zugegriffen, ob sie Fehler oder andere Informationen enthalten. Dieses Konzept ist besonders vorteilhaft bei sekundären Speichermedien wie z. B. Platten.
Neben der Verarbeitung von Daten in einem virtuellen Speicherbereich ist außerdem die Ausführung eines Programms möglich, das von einem Benutzer mit einer anderen Benutzer-ID gesteuert wird. Das hier beschriebene System kann von einer aus einer Datenstationfamilie benutzt werden.
Zum vollständigen Verständnis der vorliegenden Erfindung können die beiliegenden Zeichnungen in Verbindung mit deren genauer Beschreibung beitragen:
Fig. 1 ist eine schematische Darstellung der Editorumgebung gemäß der vorliegenden Erfindung;
Fig. 2 ist ein Ablaufdiagramm, in dem die gemäß der vorliegenden Erfindung durchgeführten Schritte dargestellt werden;
Fig. 3 ist die Bildschirmanzeige eines virtuellen Speicherbereichs, wie sie ein Benutzer bei der Anwendung der vorliegenden Erfindung sieht;
Fig. 4-7 sind Blockdiagramme der Datenstruktur einer CMS- Miniplatte.
Fig. 1 zeigt eine Umgebung, in der der Editor der vorliegenden Erfindung benutzt werden kann. Hintergrundinformationen zu der Umgebung, für die die vorliegende Erfindung gedacht ist, können außerdem den oben aufgeführten IBM Veröffentlichungen entnommen werden.
Ein Virtual Machine/System Product (VM/SP) hat die Bezugsnummer 100. Das VM/SP-System umfaßt im bevorzugten Ausführungsbeispiel drei oder mehr Betriebssysteme. Das Betriebssystem CMS wird von einem Benutzer als virtuelle Maschine verwendet, der die Bezugsnummer 102 zugeordnet ist. Der Editor der vorliegenden Erfindung
- in Fig. 1 als "Editor" bezeichnet - ist für die Ausführung in einer solchen virtuellen Maschine 102 eingerichtet.
Neben der virtuellen Maschine 102 befindet sich ein zweites Betriebssystem CMS 104. Neben dem zweiten Betriebssystem CMS können sich ein oder mehrere andere Betriebssysteme befinden. Diese anderen Betriebssysteme sind in Fig. 1 allgemein mit der Bezugsnummer 106 bezeichnet.
Unter den Betriebssystemen 102, 104 und 106 befindet sich ein Steuerprogramm (Control Program - CP) 108. Die Betriebssysteme werden also oberhalb des Steuerprogramms 108 ausgeführt.
Ein Übertragungsweg 110 ist zwischen dem Steuerprogramm 108 und dem Betriebssystem 102 des Benutzers eingerichtet. Er wird als Übertragungsweg zwischen Benutzern (Inter-User Communication Vehicle - IUCV) bezeichnet. Der IUCV 110 verbindet die virtuelle Maschine 102, 104 oder 106 mit einem DASD-BLOCK-E/A-Service 112. Der DASD-BLOCK-E/A-Service 112 ist wiederum für das Lesen und Schreiben von Blöcken auf eine sekundäre Speichereinrichtung, wie z. B. eine Miniplatte 114, eingerichtet.
Der Befehl CP SEND 116 kann von der primären virtuellen Maschine 102, d. h. der Maschine des Benutzers, gestartet und an jede der anderen, sekundären virtuellen Maschinen 104, 106 übertragen werden, die unter anderen Betriebssystemen laufen können. Signale können mit Hilfe einer Single Console Image Facility (SCIF) 118 von den sekundären virtuellen Maschinen 104, 106 generiert und an die primäre virtuelle Maschine 102 zurückgegeben werden. Alle von den sekundären virtuellen Maschinen 104, 106 kommenden Antworten, Nachrichten oder Signale, die normalerweise an der Datenstation eines Benutzers angezeigt würden, werden statt dessen als Antwort auf den zuvor von der primären virtuellen Maschine 102 gestarteten Befehl CP SEND an die primäre virtuelle Maschine 102 übertragen.
An dieser Stelle wäre es hilfreich, den Betrieb des Editors gemäß der vorliegenden Erfindung allgemein unter Bezug auf Fig. 1 zu beschreiben. Ein menschlicher Benutzer, nicht dargestellt, einer virtuellen Maschine 102 möchte auf Daten zugreifen und diese ändern, die im Speicherbereich einer sekundären virtuellen Maschine 104 oder 106 gespeichert sind. Entsprechend startet der Benutzer den Editor, der den Befehl CP SEND 116 benutzt, um auf die gewünschten Daten in einer sekundären virtuellen Maschine 104 oder 106 zuzugreifen. Auf jeden Speicherbereich einer sekundären virtuellen Maschine kann zugegriffen werden, jedoch nicht auf mehrere Speicherbereiche gleichzeitig.
Die erste virtuelle Maschine 102 greift auf Daten im Speicherbereich der sekundären virtuellen Maschine 104, 106 zu, ohne daß ein zweiter Benutzer dies bemerkt oder wissen muß. Die Daten aus dem Speicher der zweiten virtuellen Maschine 104, 106 werden über SCIF 118 an die erste virtuelle Maschine 102 gesendet. Nachdem der Benutzer der ersten virtuellen Maschine 102 die Daten geändert hat, sendet der Editor die aktualisierten Daten über den Befehl CP SEND 116 zurück an den Speicherbereich der sekundären virtuellen Maschine 104, 106.
Auf ähnliche Weise kann der Benutzer der ersten virtuellen Maschine 102 auf Daten zugreifen, die sich auf einem sekundären Speichermedium, wie z. B. einer Miniplatte 114, befinden. Dazu greift der Editor mit Hilfe des DASD-BLOCK-E/A-Service 112 über den IUCV 110 auf die Miniplatte 114 zu. Dieser DASD-BLOCK-E/A- Service 112 arbeitet in beiden Richtungen, d. h. Antworten von der Miniplatte 114 werden über denselben Übertragungsweg gesendet wie Anforderungen von der ersten virtuellen Maschine 102.
Damit der Editor in einer virtuellen Maschine benutzt werden und mit dem Speicherbereich einer zweiten virtuellen Maschine arbeiten kann, muß die zweite Benutzer-ID definiert und der ersten als solche bekannt sein.
Eine Unterroutine PROFILE ermöglicht dem Benutzer das Festlegen der Funktionstasten und Farben für verschiedene Felder in der Bildschirmanzeige. Eine Beschreibung einer Anzeige befindet sich nachfolgend unter Bezug auf Fig. 3.
Der Editor der vorliegenden Erfindung läuft unter einem Betriebssystem wie z. B. VM/SP CMS und bietet dem Benutzer die Möglichkeit, Realspeicher oder virtuellen Speicher und sekundäre Speichermedien, wie z. B. Magnetplatten, im Gesamtanzeigemodus anzuzeigen und zu ändern. Der bei dieser Erfindung benutzte Anzeigenmanager wird IOS3270 genannt und ermöglicht die Verwendung des Editors an jeder Datenstation IBM 327X.
Bei der virtuellen Maschine, deren Speicherbereich editiert wird, kann es sich um die virtuelle Maschine des Benutzers oder eine andere virtuelle Maschine handeln. Der Benutzer kann bestimmte Daten im Speicher suchen und darin blättern sowie Speicher ändern, indem er den Cursor entweder in die Felder mit den Hexadezimaldaten oder die umgesetzten EBCDIC-Felder bewegt und die angezeigten Daten überschreibt. Der Benutzer kann jeden CP-, CMS- oder EXEC-Befehl in die Befehlszeile des Editors eingeben, ohne daß das Editorprogramm dadurch beeinflußt wird. Der Editor kann sogar vom Steuerprogramm CP gestartet werden, falls dieses zuvor vom Betriebssystem CMS initialisiert wurde; dies gilt selbst dann, wenn ein Benutzer gerade einen Trace für ein Programm durchführt.
Alle oben aufgeführten Operationen können mit sekundären CMS- Speichermedien, wie z. B. Platten, durchgeführt werden, ohne daß der Datenträger zugeordnet werden muß. Dies kann bei der Ablaufverfolgung für Dateizeiger und deren Wiederherstellung nützlich sein. Falls gewünscht, kann auch der Datenträgerkennsatz selbst geändert werden. Im bevorzugten Ausführungsbeispiel wird eine Miniplatte als sekundäres Speichermedium benutzt. Miniplattendatenblöcke werden gemäß der weiter unten beschriebenen Struktur gelesen und geschrieben.
Fig. 2 enthält unter Bezugsnummer 200 ein Ablaufdiagramm, in dem die Funktionsweise des Editors gemäß der vorliegenden Erfindung dargestellt wird. Das Programm wird als Nukleuserweiterung geladen, Schritt 210, und die Steuerung wird an das Programm übergeben.
Das Programm richtet dann die Adressierung ein, initialisiert Markierungen und Variable, setzt verschiedene Programmstatuswörter, überprüft den Datenstationstyp und die Bildschirmgröße, ordnet freien Speicher zu und liest das Profil zum Setzen der Funktionstasten und Farben, Schritt 212.
Dann wird der nächste Befehl festgestellt, Schritt 214. Abhängig vom empfangenen Befehl wird dann eine Befehlsverarbeitungsprozedur, allgemein dargestellt unter 215, gestartet. Es kann sich um einen für die Ausführung durch CMS geeigneten Befehl handeln, Schritt 216; in diesem Fall übergibt das System den Befehl an das Betriebssystem CMS.
Wird durch den in Schritt 214 empfangenen Befehl das Drucken eines Anzeigenabbilds angefordert, Schritt 218, wird er vom Editor bearbeitet.
Eventuell fordert der in Schritt 214 empfangene Befehl auch das Schreiben eines Blocks auf die Platte an, Schritt 220. In diesem Fall wird eine Unterroutine BLOCKIO aufgerufen. BLOCKIO kann gestartet werden, um entweder blockweise von der Platte zu lesen oder blockweise auf sie zu schreiben.
Schließlich kann auch jeder andere in Schritt 214 empfangene Befehl vom System in geeigneter Weise verarbeitet werden, Schritt 222.
Dann wird die Speicherart festgestellt, Schritt 224, und abhängig davon wird eine Speicherverarbeitungsprozedur, allgemein dargestellt unter 225, gestartet. Eine der Speicherarten ist der Realspeicher, Schritt 226. Die CP-Diagnoseprozedur DIAG 4 wird gestartet, um Daten aus dem Realspeicher zu abzurufen.
Eine weitere Speicherart, die in Schritt 224 empfangen werden kann, ist der virtuelle Speicher, Schritt 228. Die Assemblerinstruktion MVCL wird zum Aufrufen von Daten aus dem virtuellen Speicher benutzt.
Eine weitere Speicherart, die in Schritt 224 empfangen werden kann, bezieht sich auf einen Block, auf den auf der Platte zugegriffen werden soll, Schritt 230. Der DASD-BLOCKIO-E/A-Service 112 (Fig. 1) wird zum Übertragen eines Datenblocks auf oder von der Platte 114 benutzt.
Schließlich kann mit Hilfe des Befehls CP SEND und des Programms SCIF auf einen anderen VM-Speicherbereich zugegriffen werden, Schritt 232.
Dann wird der Puffer verarbeitet, damit die darin enthaltenen Daten angezeigt werden können, Schritt 234. Danach wird das Programm IOS3270 aufgerufen und ausgeführt, um die Daten anzuzeigen.
Schließlich wird die Befehlszeile gelesen, Schritt 236 und werden Anzeigenänderungen durchgeführt. Zu diesem Zeitpunkt wird der nächste Befehl zur weiteren Verarbeitung gemäß der oben beschriebenen Prozedur empfangen, Schritt 214.
Die Struktur des Dateisystems auf einer CMS-Miniplatte gemäß der vorliegenden Erfindung wird im folgenden, vom Verzeichnis bis zum Datenblock, beschrieben. Bei Kenntnis der folgenden Dateistruktur kann der Editor der vorliegenden Erfindung zum Ändern oder zum Korrigieren von Fehlern der in diesem Dateisystem gespeicherten Daten benutzt werden.
Das Hauptdateiverzeichnis enthält zwei Gruppen von Informationen: Zeiger für Steuerblöcke, die alle vorhandenen Dateien beschreiben - genannt Dateistatustabellenblöcke -, und Zeiger für ein Bitabbild, das den Status aller CMS-Blöcke beschreibt.
Die eigentlichen Daten einer Datei befinden sich in Blöcken von 512, 1024, 2048 oder 4096 Byte, den sogenannten Datenblöcken. Dateien bestehen aus Datenblöcken und aus Zeigerblöcken, die die Datenblöcke miteinander verketten. Alle Blöcke haben, entsprechend dem Plattenformat, dieselbe Größe. Abhängig von der Größe einer Datei (d. h. der Anzahl der zu verkettenden Datenblöcke) werden mehrere Ebenen von Zeigerblöcken erstellt. Der Dateistatustabelleneintrag enthält einen Zeiger für einen Steuerblock, in dem beschrieben ist, wie die Datenblöcke einer Datei miteinander verkettet sind.
Der CMS-Befehl FORMAT erlaubt es dem Benutzer beim Formatieren der Miniplatte eine dieser Blockgrößen auszuwählen. Die Blockgröße ist ein Merkmal der CMS-Platte, nicht der eigentlichen Datei. Eine CMS-Platte kann nicht mehrere Blockgrößen enthalten. Die Standardblockgröße ist 1024 Byte.
Eine CMS-Platte enthält in einem ihrer ersten CMS-Blöcke einen CMS-Kennsatz. Dieser Kennsatz enthält die CMS-Blockgröße, den Plattenursprungszeiger (Disk Origin Pointer - DOP) und ein Plattenerstellungsdatum.
Eine Datei wird durch eine Dateistatustabelle beschrieben. Die Dateistatustabelle ist 64 Byte lang. Sie benutzt Maschinenwortfelder für den Dateiursprungszeiger (File Origin Pointer - FOP), den CMS-Blockzähler und den Elementezähler. Das Feld für das Datum der letzten Änderung enthält Datumsangaben, Stunden, Minuten und Sekunden. Der Elementezähler ist ein Maschinenwort mit einer Kapazität von 2³¹ - 1 adressierbaren Elementen.
Unter Bezugnahme auf Fig. 4 kann die Zeigerblockstruktur am besten am Beispiel einer kleinen Datei erläutert werden, die fortlaufend größer wird. Passen alle Daten in einen Datenblock 400, verweist der Dateiursprungszeiger (File Origin Pointer - FOP) in der Dateistatustabelle nur auf diesen Block 400.
Gemäß Fig. 5 wird ein Zeigerblock erster Ebene 500 erstellt, wenn nicht alle Daten in denselben Datenblock 502 passen. Dieser Zeigerblock 500 enthält so viele Maschinenwortzeigerfelder 504 wie in einen Block passen, d. h. er kann, abhängig von der Blockgröße der Platte, auf 256, 512 oder 1024 Datenblöcke verweisen. Der Dateiursprungszeiger verweist jetzt auf den Zeigerblock erster Ebene.
Gemäß Fig. 6 wird ein Zeigerblock zweiter Ebene 600 erstellt, wenn die Anzahl der für die Daten benötigten Datenblöcke größer ist als die Anzahl von Datenblöcken, auf die ein Zeigerblock verweisen kann.
Ein Zeigerblock zweiter Ebene 600 hat dieselbe Struktur wie der Zeigerblock erster Ebene 602 (Bezugsnummer 500 in Fig. 5). Seine Zeiger verweisen jedoch, abhängig von der Blockgröße der Platte, auf 256, 512 oder 1024 Zeigerblöcke erster Ebene 602. Diese Zeiger werden im Gegensatz zu direkten Zeigern, die direkt auf Datenblöcke verweisen, indirekte Zeiger genannt.
Ist die Datei auch für eine Struktur aus Zeigerblöcken zweiter Ebene zu groß, wird ein Zeigerblock dritter Ebene, nicht dargestellt, erstellt. Dieser kann, abhängig von der Blockgröße der Platte, auf 256, 512 oder 1024 Zeigerblockstrukturen zweiter Ebene verweisen.
Auf dieselbe Weise können höhere Ebenen von Zeigerblöcken erstellt werden, wenn die Datei größer wird. Dieser Aufbau führt zu einer Baumstruktur, die nur durch den Adressierungshöchstwert der Zeiger begrenzt wird. Zeigerblöcke enthalten relative Blocknummern. Sie können die Maschinenwortkapazität (2³¹ - 1) nicht überschreiten. Die Gesamtzahl der Blöcke - Daten und Zeiger - pro Datei ist dadurch auf 2³¹ - 1 beschränkt.
Das Dateiverzeichnis auf einer Platte enthält die Dateistatustabellen aller auf der Platte befindlichen Dateien. Es hat Datenblöcke und Zeigerblöcke. Es wird deshalb als Verzeichnisdatei bezeichnet. Es hat den Dateityp "DIRECTOR", und sein Dateiname, der nicht gedruckt werden kann, ist X'0000000100000000'.
Der Benutzer kann die Verzeichnisdatei nicht sehen und folglich auch nicht ändern. Die Größe der Verzeichnisdatei hängt von der Anzahl der darin beschriebenen Dateien ab.
Fig. 7 enthält ein Beispiel für eine Verzeichnisdatei; dieser ist darin die Bezugsnummer 700 zugeordnet. Die erste Dateistatustabelle 702 in der Verzeichnisdatei beschreibt die Verzeichnisdatei selbst. Der erste Zeiger im ersten Zeigerblock verweist auf den ersten Datenblock 704. Dies ist derselbe Block, auf den der Plattenursprungszeiger (Disk Origin Pointer - DOP) verweist.
Als zweite Datei wird in der Verzeichnisdatei immer die Zuordnungsübersicht 706 beschrieben. Der Zeiger in der Zuordnungsübersicht verweist auf die Datenblöcke 708 in der Zuordnungsübersichtdatei.
Die erste Dateistatustabelle 710 für eine Benutzerdatei ist die dritte im Dateiverzeichnis.
Es gibt keinen Höchstwert für die Anzahl der Dateien pro CMS- Platte. Es sollte jedoch bedacht werden, daß ein CMS-Block die Mindestgröße jeder Datei ist und daß CMS-Blöcke für die Verzeichnisdatei und die Zuordnungsübersicht benötigt werden.
Wird auf die CMS-Platte im Schreib-/Lesemodus zugegriffen, wird eine Kopie der Verzeichnisdatei in den virtuellen Speicher des Benutzers gestellt. Die Verzeichnisdatei wird mindestens am Ende der Ausführung jedes CMS-Befehls aktualisiert, falls Daten geändert wurden. Dieses Aktualisieren wird im bevorzugten Ausführungsbeispiel selektiv durchgeführt. Es werden also nur die geänderten CMS-Blöcke auf die Platte geschrieben.
Alle Blöcke werden an eine andere Position geschrieben; dies gilt auch für den ersten Datenblock, der sich entweder in CMS- Block 4 oder 5 befindet. Diese Maßnahme soll das Wiederherstellen der vorherigen Verzeichnisdatei in Notfällen ermöglichen.
Die Zuordnung von CMS-Blöcken wird in der Zuordnungsübersicht 708 beschrieben. Diese enthält eine Bitstelle für jeden CMS- Block der CMS-Platte. Ist ein Bit auf 1 gesetzt, ist der zugehörige Block zur Zeit zugeordnet.
Der Dateityp der Zuordnungsübersicht ist ALLOCMAP. Ihr Dateiname, der für den Benutzer nicht sichtbar ist, ist '0000000200000000'. Die Größe dieser Datei hängt von der Größe der CMS-Platte ab.
Wird auf eine CMS-Platte im Schreib-/Lesemodus zugegriffen, befindet sich eine Kopie ihrer Zuordnungsübersicht im virtuellen Speicher der des Benutzers. Wenn nötig, wird die Kopie auf der Platte aktualisiert. Anders als bei der Verzeichnisdatei geschieht dies nicht selektiv.
Ein Programmierer gibt über die Tastatur oder ein anderes Eingabemedium die Buchstaben VMV ein, gefolgt von einer Adresse. Gibt der Programmierer nur die Buchstaben VMV ein, wird eine Gesamtanzeige mit Daten aufgerufen.
Fig. 3 enthält eine Gesamtanzeige, wie sie der Programmierer sieht; ihr ist darin die Bezugsnummer 300 zugeordnet. Die zweite Zeile ist die Befehlszeile 302, gefolgt von Zeilen mit Daten 304. Die untere Titelzeile 306 enthält die Einstellungen der Funktionstasten. Das Format der Datenzeilen 304 ist ähnlich dem, das sie bei Ausführung des Befehls CP DISPLAY mit der Option TRANSLATE haben; der hier beschriebene Editor setzt jedoch zusätzlich Kleinbuchstaben um.
Der Cursor 308 kann entweder in die Felder mit den Hexadezimaldaten oder die umgesetzten EBCDIC-Felder bewegt werden, und der Benutzer kann die angezeigten Daten überschreiben. Wenn die Eingabetaste einer Tastatur, nicht dargestellt, gedrückt wird, wird der Speicher geändert.
Durch Verwendung von Editorunterbefehlen kann der Benutzer sowohl weitere Speicherpositionen suchen oder zu ihnen blättern als auch die Editorsitzung beenden. Der Editor ermöglicht es dem Benutzer außerdem, sekundäre Speichermedien, wie z. B. Miniplatten, direkt anzuzeigen und zu ändern, ohne daß die virtuelle Maschine den Datenträger zuordnen muß.
Unter dem Betriebssystem CMS werden Miniplatten, wie oben beschrieben, in Blöcke von 512, 800, 1024, 2048 oder 4096 Byte formatiert. Blöcke werden in der Reihenfolge gekennzeichnet, in der sie auftreten. Mit dem Editor können einzelne Miniplattenblöcke in den Speicher gelesen werden, um sie dort zu ändern und danach wieder auf die Platte zurückzuschreiben. Diese Fähigkeit ist nützlich bei einem Trace für Dateizeiger und deren Wiederherstellung oder zum Spiegeln der Verzeichnisse, um verlorene Dateien zu sichern, bevor das zweite Verzeichnis aktualisiert wird. Falls gewünscht, kann der Kennsatz der Miniplatte überschrieben werden.
Das Editor-Modul MODUL wird im Benutzerprogrammbereich ausgeführt. Es wird als Nukleuserweiterung mit dem Namen VMV geladen.
Die Nukleuserweiterungsfunktion ermöglicht dem Benutzer das Festlegen von Befehlseingangspunkten in Programmen, die im freien Speicher eingerichtet sind, so daß sie über eine Schnittstelle so aufgerufen werden können wie Nukleusbefehle. Diese Struktur ermöglicht dem Benutzer das Eingeben jedes gültigen CP- ,CMS- oder EXEC-Befehls innerhalb des Editors, ohne daß das Programm überlagert wird.
Wenn der Editor zum ersten Mal benutzt und während er geladen wird, wird das externe neue Programmstatuswort durch ein Programmstatuswort ersetzt, das auf die VMV-Adresse in der Nukleuserweiterung verweist. Nachdem VMV als Nukleuserweiterung eingerichtet wurde, kann es vom Steuerprogramm unter Verwendung des Befehls "EXT 15" aufgerufen werden, ohne daß das aktive Programm überlagert wird. Der Befehl EXTERNAL simuliert eine externe Unterbrechung der virtuellen Maschine und gibt die Steuerung unter Verwendung der Adresse im externen neuen Programmstatuswort an diese Maschine zurück. Bei Beendigung des Editors fügt er im Programm, für das der Trace durchgeführt wurde, der nächsten Instruktion, die vor der Unterbrechung des Editors hätte ausgeführt werden sollen, ein ADSTOP hinzu. Alle anderen externen Unterbrechungen greifen auf das ursprüngliche externe neue Programmstatuswort zu.
Der IUCV 110 (Fig. 1) und das SCIF 118 werden wie oben beschrieben vom Editor benutzt. Wie oben beschrieben, handelt es sich beim IUCV 110 um einen Übertragungsweg, der Benutzern die Übertragung jeder beliebigen Menge von Informationen ermöglicht. Er ermöglicht einem Programm, das in der virtuellen Maschine 102 ausgeführt wird, die Kommunikation mit anderen virtuellen Maschinen 104, 106, mit einem CP-Systemservice oder mit sich selbst.
SCIF 118 ermöglicht einem Benutzer, der an einer einzelnen virtuellen Maschine 102 angemeldet ist, die Steuerung mehrerer unabhängiger virtueller Maschinen 104, 106. Das Steuerprogramm CP fügt vor jeder Ausgabe, die direkt von oder im Namen der ursprünglichen virtuellen Maschine 102 zur gesteuerten oder sekundären virtuellen Maschine 104, 106 kommt, ein Präfix ein. Bei dem Präfix handelt es sich um die Benutzer-ID der ursprünglichen virtuellen Maschine. Die steuernde oder primäre virtuelle Maschine 102 kommuniziert mit der/den virtuellen Maschine(n) 104, 106, die sie steuert, über den Befehl CP SEND.
Soll der Editor in einer virtuellen Maschine ausgeführt werden und mit dem Speicher einer zweiten virtuellen Maschine arbeiten, muß die zweite virtuelle Maschine für die erste virtuelle Maschine unter Verwendung der Steueranweisung CONSOLE im Verzeichnis als sekundäre Benutzer-ID definiert sein. Nachdem die beiden virtuellen Maschinen auf diese Weise verbunden sind, wird der Editor in der ersten virtuellen Maschine ausgeführt und zeigt den Speicher der unabhängigen zweiten virtuellen Maschine an.
Der Befehl CP SEND überträgt alle Befehle und Speicheränderungen an die zweite Maschine. Zum Anzeigen des Speichers wird der Befehl CP DISPLAY an die zweite Maschine übergeben. IUCV ist mit den *MSG-Systemservices verbunden und fängt die Antworten ab. Diese Antworten kommen über SCIF an und enthalten den mit dem Befehl CP DISPLAY angezeigten Speicher. Die Anzahl der Nachrichten hängt von der Größe der Anzeige ab. Nachdem alle Nachrichten abgefangen wurden, werden sie zu einer Gesamtanzeige des Speichers verarbeitet.
Das Editieren von Miniplatten erfolgt durch das Modul DIO unter Verwendung des DASD-BLOCK-E/A-Systemservice zum Lesen und Schreiben der Miniplattenblöcke. IUCV verbindet den Editor mit DASD-BLOCK-E/A durch Verbindung mit dem *BLOCKIO-Systemservice.
Eine Adressierungsausnahmebedingung wird vom Editor abgefangen, falls der Benutzer versucht, Speicher anzuzeigen, der größer als die Größe der virtuellen Maschine ist. Diese Einrichtung ist nützlich, wenn versucht wird, Segmente anzuzeigen, die sich oberhalb des Bereichs der virtuellen Maschine befinden, oder wenn ein Fehler auftritt, wie z. B. das Eingeben einer Adresse im nicht adressierbaren Speicher. Die Adressierungsausnahmebedingung wird dadurch abgefangen, daß die Adresse der nächsten Instruktion im Programm durch einen Eingangspunkt im Editor ersetzt wird.
Der Gesamtanzeigemanager IOS3270 wurde geschrieben, damit die Funktionen genutzt werden können, die die Datensichtgerätefamilie IBM 3270 bietet. Im bevorzugten Ausführungsbeispiel arbeitet der Editor unter Verwendung einer Datenstation IBM 327x. Der Manager IOS3270 zeigt Datenerfassungsanzeigen, auch Auswahlmenüs genannt, an. Anzeigen können dazu benutzt werden, Erläuterungen zu geben oder den Bediener dazu aufzufordern, Parameter anzugeben, die für das Ausführen einer Funktion erforderlich sind.

Claims

1. System zur Editierung von Daten im virtuellen Speicher, das

ein Steuerprogramm (108), ein Betriebssystem (102, 104, 106) mit virtuellem Speicher und eine Anzeigeeinheit enthält, dadurch gekennzeichnet, daß

ein erstes Betriebssystem (102) mit virtuellem Speicher einen im Speicher geladenen Editor enthält, wobei der Editor

eine an sich bekannte Routine SCIF aufruft, um auf Daten im virtuellen Speicher eines zweiten Betriebssystems (104) zuzugreifen,

die Daten an einer Anzeigeeinheit anzeigt, es dem Benutzer des ersten Betriebssystems (102) ermöglicht, die Daten zu verändern, und

die veränderten Daten mittels eines an sich bekannten Befehls CP SEND in den virtuellen Speicher des zweiten Betriebssystems (104) zurückgibt, wobei der Benutzer des zweiten Betriebssystems (104) von den beschriebenen Vorgängen nichts merkt.

2. System nach Anspruch 1, in dem die Anzeigeeinheit eine Datenstation ist.

3. System nach Anspruch 1, in dem die Anzeigeeinheit ein Drucker ist.

4. System nach einem der Ansprüche 1 bis 3, in dem die Veränderung und die Rückgabe der Daten es dem Benutzer des ersten Betriebssystems (102) ermöglichen, ein im virtuellen Speicher des zweiten Betriebssystems (104) ablaufendes Programm zu steuern.