-
Die
Erfindung betrifft eine Datenverarbeitungsanlage gemäß dem Oberbegriff
des Patentanspruchs 1.
-
Unter
einem Programmsystem wird im allgemeinen ein Programm mit mehreren
Teilen und einer sehr großen
Anzahl von Befehlen zur Lösung
einer gemeinsamen übergeordneten
Aufgabe verstanden. Ein Programmsystem ist zum Beispiel ein Betriebssystem
für die
Steuerung der Grundfunktionen der Datenverarbeitungsanlage, kurz
DV-Anlage. Solche Betriebssysteme sind oft in einer Entwicklungszeit von
vielen Jahren, z.B. 10 oder 20 Jahren, entstanden und enthalten
mehrere Millionen Befehle. Ein Programmsystem kann auch ein Anwendungsprogramm
sein, wie zum Beispiel ein Buchungsprogramm für eine Großbank oder eine Versicherungsgesellschaft.
In DV-Anlagen mit mehreren gleichartigen Prozessoren ist auch ein
paralleles Abarbeiten von Befehlen eines einzigen oder mehrerer
Programmsysteme möglich.
-
Programmsysteme
enthalten gewöhnlich mehrere
Subsysteme, die vorgegebene Funktionen der DV-Anlage definieren.
Ein Speichersubsystem z.B. übernimmt
bei einem Betriebssystem alle Funktionen, die mit Speichervorgängen in
Verbindung stehen. Ein Dateisubsystem führt die Funktionen aus, die
für das
Arbeiten mit den Dateien auf der DV-Anlage benötigt werden. In einer Mehrprozessoranlage hat
ein Mehrprozessor-Subsystem die Aufgabe, den parallelen Betrieb
der Prozessoren zu steuern.
-
Jedes
Subsystem bietet in der Regel mehrere Funktionen an. Eine Funktion
im Dateisubsystem ist z.B. das Anlegen einer neuen Datei im Speicher der
DV-Anlage. Zum Ausführen
einer Funktion sind häufig
mehrere tausend Befehle notwendig. Oft werden demzufolge die Funktionen
in Teilfunktionen unterteilt. Die Befehle zum Ausführen einer
Funktion oder zum Ausführen
einer Teilfunktion sind zu einem Softwarebaustein zusammengefaßt. Ein
Softwarebaustein ist zum Beispiel eine Befehlsfolge, auch Prozedur
genannt, die an einer Startadresse beginnt und an einer Endadresse
endet. Üblich
ist das Bereitstellen von Parametern vor dem Ausführen der
Prozedur bzw. des Softwarebausteins. Außerdem können beim Ausführen der
Prozedur Ergebnisparameter erzeugt werden, die zur weiteren Bearbeitung
gespeichert werden.
-
Bekannte
Verfahren zum Betreiben einer DV-Anlage haben den Nachteil, daß zwischen
den Subsystemen eine sehr große
Anzahl von verschiedenartigen Abhängigkeiten sowohl beim Erstellen der
Softwarebausteine als auch beim Ausführen der Funktionen bestehen.
So können
Softwarebausteine für
die Ausführung
von Teilfunktionen einer übergeordneten
Funktion in verschiedenen Subsystemen enthalten sein. Für das bereits
genannte Beispiel, nämlich
das Anlegen einer Datei, kann z.B. eine Teilfunktion für die Vorbereitung
des Anlegens der Datei als Softwarebaustein im Dateisubsystem sowie
eine andere Teilfunktion, nämlich
das Bereitstellen von Speicherplatz zum Anlegen der Datei im Speicher der
DV-Anlage, als weiterer Softwarebaustein im Speichersubsystem definiert
sein. Wenn nun Änderungen
am Softwarebaustein im Speichersubsystem vorgenommen werden, so
können
sich diese Änderungen
auch auf den Softwarebaustein im Dateisubsystem auswirken, z.B.
im Hinblick auf die Parameterübergabe.
Das Dateisubsystem ist also vom Speichersubsystem abhängig. Diese
Abhängigkeit
wird unter anderem durch die Anzahl und die Formate zu übergebender
Parameter und durch die verwendeten Entwicklungstechniken für die Softwarebausteine
bestimmt. Weitere Abhängigkeiten
entstehen, wenn auf eine Datenstruktur aus verschiedenen Subsystemen heraus
zugegriffen wird, da bei Änderungen
der Datenstruktur der Zugriff in allen Subsystemen geändert werden
muß, die
auf diese Datenstruktur zugreifen. Die Verschieden artigkeit und
die Vielzahl der Abhängigkeiten
im Programmsystem erschweren die Weiterentwicklung des Programmsystems
und sind oft eine Fehlerursache, da das tatsächliche Ausmaß von Änderungen
in einem oder mehreren der Subsysteme kaum zu überschauen ist. Durch die verschiedenartigen
Abhängigkeiten
der Subsysteme untereinander entsteht außerdem ein erhöhter Aufwand
bei der Dokumentation, der Fehlersuche und der Pflege des Programmsystems.
-
Da
Programmsysteme in der Regel ständig weiterentwickelt
werden und sich dabei aufgrund der zunehmenden Zahl von Funktionen
in der Regel vergrößern, steigt
aufgrund der genannten Abhängigkeiten
der Aufwand für
Neuentwicklungen und Änderungen
im Programmsystem überproportional
an. In der Praxis hat sich gezeigt, daß bei einem Betriebssystem
z.B. durch Abänderungen
und Modifikation etwa eine Million Befehle innerhalb von zwei Jahren
zum Programmsystem hinzukommen können. Über die Zeit
betrachtet steigt der Aufwand für Änderungen
bei dem Betriebssystem in etwa exponentiell an.
-
Aus
der
DE 42 11 678 A1 ist
eine Betriebssystemarchitektur für
Betriebssysteme mit objektorientierter grafischer Benutzeroberfläche bekannt.
Dabei ist eine allgemeine Komponente mit Funktionsmodulen zur Durchführung allgemeiner
Operationen und spezielle Komponenten mit weiteren Funktionsmodulen
vorgesehen. Dadurch ist ein modularer Aufbau gegeben, wobei später einzelne
Funktionsmodule entfernt oder hinzugefügt werden können.
-
Die
EP 0 474 340 A2 offenbart
ein Verfahren zur Zusammenwirkung von verschiedenen Computeranwendungen
in einem heterogenen Datenverarbeitungsnetzwerk.
-
Aus
der WO 95/03575 A1 ist ein System bekannt, bei dem Anwendungsprogramme über Schnittstellenschichten,
sogenannte Wrapper, an ein Betriebssystem angebunden sind. Durch
die Wrapper ist es möglich,
ein prozedurales Betriebssystem nach Außen als objektorientiert erscheinen
zu lassen, so dass objektorientierte Anwendungsprogramme so auf
Funktionen des Betriebssystems zugreifen können, als ob es objektorientiert
programmierte Schnittstellen anbieten würde.
-
Die
EP 0 558 945 A2 offenbart
ein Verfahren zum Zugriff auf einen Speicher, der in mehrere Unterspeichergruppen
aufgeteilt ist. Innerhalb einer Unterspeichergruppe ist eine Aufteilung
in verschiedener Unterspeicherbereiche vorgesehen, wobei auf einen der
Bereiche von Außerhalb
der Unterspeichergruppe zugegriffen werden kann, während auf
die anderen Unterspeicherbereiche nur innerhalb der Unterspeichergruppe
zugegriffen werden kann.
-
Aus
der
EP 0 381 167 A2 ist
ein Verfahren zum Verwalten virtueller Speicherbereiche bekannt, die
in Familien aufgeteilt sind.
-
Aufgabe
der Erfindung ist es, eine Datenverarbeitungsanlage anzugeben, die
bei der Abarbeitung der Befehle eines Programmsystems mit einer Vielzahl
von Subsystemen einen fehlerfreien Betrieb gewährleistet und Änderungen
im Programmsystem auf einfache Art und Weise gestattet. Diese Änderungen
sollen unter Zuhilfenahme modernster Entwicklungstechniken und Programmiersprachen
durchgeführt
werden können.
-
Diese
Aufgabe wird durch eine Datenverarbeitungsanlage gemäß Patentanspruch
1 gelöst.
-
Jedes
Subsystem hat bei der Erfindung mindestens eine im wesentlichen
gleichartig aufgebaute Vermittlungseinheit, die für das betreffende
Subsystem oder einen Teil davon ein Verzeichnis enthält, welches
auf im jeweiligen Subsystem enthaltene Softwarebausteine verweist.
Zum Ausführen
der besagten Funktion ruft das erste Subsystem die Vermittlungseinheit
im zweiten Subsystem auf, und diese Vermittlungseinheit ruft mit
Hilfe des in ihr enthaltenen Verzeichnisses den dieser Funktion
zugeordneten Softwarebaustein auf. Die Vermittlungseinheit übernimmt
dabei auch nötigenfalls
die Aufgabe, die Verknüpfung
zu einer anderen Entwicklungstechnik und Programmiersprache herzustellen.
Nach dem Ausführen
der Befehle dieses Softwarebausteins wird zum ersten Subsystem zurückgekehrt.
-
Die
Erfindung geht von der Erkenntnis aus, daß Abhängigkeiten zwischen den Subsystemen
unvermeidbar sind. So sind für
eine Funktion eines ersten Subsystems auch Softwarebausteine, die
Bestandteile anderer Subsysteme sind, aufzurufen und deren Befehle
auszuführen.
Werden die Abhängigkeiten
aber übersichtlich
realisiert, so können
die oben beschriebenen Nachteile verhindert werden. Zu diesem Zweck
hat bei der Erfindung jedes Subsystem mindestens eine im wesentlichen
gleichartig aufgebaute Vermittlungseinheit. Die Aufrufe von Softwarebausteinen
zwischen den Subsystemen erfolgen bei der Erfindung prinzipiell
nur noch über
die Vermittlungseinheiten. Damit stellen die Vermittlungseinheiten
die hauptsächliche
Schnittstelle zwischen den Subsystemen dar. Die Abhängigkeiten
der Subsysteme sind somit gebündelt
und überschaubar. Außerdem werden
die Aufrufe zwischen Subsystemen vereinheitlicht und erfolgen bei
der Erfindung bezüglich
jeder Vermittlungseinheit auf gleiche Art und Weise. Dies ist möglich, da
die Vermittlungseinheiten gleichartig aufgebaut sind.
-
Aufrufe
der Softwarebausteine eines Subsystems von außen, d.h. von anderen Subsystemen oder über Benutzerschnittstellen werden über die Vermittlungseinheit
dieses gerufenen Subsystems ausgeführt. Nach außen hin
kann dadurch die konkrete Realisierung einer bestimmten Funktion
innerhalb des Subsystems verborgen bleiben. Damit kann das gerufene
Subsystem geändert
werden, ohne daß die Änderung
nach außen,
d.h. für
rufende Subsysteme sichtbar werden muß. Insbesondere werden bei der
Erfindung keine direkten Datenzugriffe von einem Subsystem in ein
anderes Subsystem durchgeführt. Lesende
und modifizierende Zugriffe auf Datenstukturen werden vielmehr durch
Zugriffsfunktionen ersetzt, deren Befehle ebenfalls über die
Vermittlungseinheit angesteuert werden. Die tatsächliche Realisierung des betreffenden
Subsystems ist somit gegenüber
der Umgebung, d.h. gegenüber
den anderen Subsystemen verborgen. Innerhalb eines Subsystems können deshalb
die Datenstrukturen frei gewählt
und auch frei geändert
werden, ohne daß auf rufende
Subsysteme Rücksicht
genommen werden muß.
Diese Eigenschaft der Erfindung ist von besonderer Bedeutung, wenn
innerhalb des Programmsystems oder innerhalb eines Subsystems im
Laufe der Zeit zu moderneren Entwicklungstechniken übergegangen
wird. So kann zum Beispiel innerhalb eines Subsystems schrittweise
von einer prozeduralen Technik zu einer objektorientierten Technik übergegangen
werden, wie sie z.B. mit der Sprache C++ möglich ist, ohne daß sogleich
im gesamten Programmsystem Änderungen
durchzuführen
sind.
-
Jede
Vermittlungseinheit greift bei der Erfindung auf ein Verzeichnis
zu, welches auf im jeweiligen Subsystem enthaltene Softwarebausteine
verweist. Dieses Verzeichnis hat bei der Erfindung die Aufgabe,
einen einheitlichen Zugriff auf die verzeichneten Softwarebausteine
zu gestatten. Während
die Vermittlungseinheit, die ebenfalls als Befehlsfolge ausgeführt ist,
gleichartig für
alle Subsysteme aufgebaut ist, sind die konkreten Inhalte der jeweiligen
Verzeichnisse von den konkreten verzeichneten Softwarebausteinen
abhängig.
Die Struktur der Verzeichnisse ist gleich, so daß gleichartig aufgebaute Befehlsfolgen
der Vermittlungseinheiten verwendet werden können und in gleicher Weise
auf das jeweilige Subsy stemverzeichnis zugreifen können. Durch
diese Maßnahme
wird erreicht, daß bei
Erweiterungen oder Änderungen
der über
die Vermittlungseinheiten aufrufbaren Softwarebausteine zwar die
Subsystemverzeichnisse zu ändern
sind, die Befehlsfolgen der Vermittlungseinheiten jedoch nicht geändert werden müssen.
-
Zum
Ausführen
einer Funktion greift ein rufendes Subsystem auf die Vermittlungseinheit
eines gerufenen Subsystems in der Weise zu, daß mit dem Ausführen der
in der Vermittlungseinheit enthaltenen Befehlsfolge begonnen wird.
Beim Ausführen
dieser Befehlsfolge wird mit Hilfe des jeweiligen Subsystemverzeichnisses
der für
die Ausführung
der Funktion benötigte
Softwarebaustein ermittelt. Anschließend werden dessen Befehle
ausgeführt.
Der Zugriff ist somit einfach zu realisieren. Insbesondere wird
die Vermittlungseinheit des rufenden Subsystems nicht benötigt, so
daß Kommunikationsprozesse
zwischen Vermittlungseinheiten entfallen.
-
Nach
dem Ausführen
der Befehle des Softwarebausteins wird in der Regel zum rufenden
Subsystem zurückgekehrt.
Das Zurückkehren
kann mit oder ohne Verwenden der Vermittlungseinheit des gerufenen
Systems und ohne Verwenden der Vermittlungseinheit des rufenden
Systems erfolgen. Damit ist das Zurückkehren einfach und schnell.
-
Bei
der Entwicklung, Dokumentation und Fehlerkorrektur können durch
die Erfindung Entwicklungszeit, Rechenzeit und damit auch Kosten
gespart werden, da eine Technik verwendet wird, bei der die Subsysteme
im wesentlichen unabhängig
voneinander erstellbar sind.
-
In
einem Ausführungsbeispiel
der Erfindung erfolgen die Auswahl und der Aufruf der jeweiligen Vermittlungseinheit über ihren
konventionierten Namen. Diese Namen sind Teil der Schnittstellenspezifikation
und werden beim Binden des Programmsystems zu Adreßwerten
aufgelöst,
welche dann in Sprungbefehlen verwendet werden.
-
Gemäß der Erfindung
erfolgt der Aufruf der Vermittlungseinheit unter Verwenden eines Übergabespeicherbereichs,
der an einer Startadresse beginnt, die vorzugsweise an diese Vermittlungseinheit in
einem Register des Prozessors übermittelt
wird. In diesem Übergabespeicherbereich
werden beim Aufruf einer Vermittlungseinheit Daten gespeichert,
die es ermöglichen,
auch bei Verwendung unterschiedlicher Versionen oder verschiedener
Arten von Entwicklungstechniken nach einer Veränderung des Programmsystems
für den
Ablauf in den Vermittlungseinheiten denselben Binärcode zu
verwenden. Wird eine Vermittlungseinheit parallel bzw. gleichzeitig
mehrfach aufgerufen, so werden unterschiedliche Startadressen verwendet
um ein Überschreiben
der Übergabespeicherbereiche
zu verhindern. Somit ist ein sogenannter Mehrfacheintritt in die
Vermittlungseinheiten möglich.
-
Die Übergabe
der Parameter an die aufzurufende Funktion erfolgt mit Hilfe des Übergabespeicherbereichs,
welcher eine von den im ersten Subsystem und im zweiten Subsystem
verwendeten Entwicklungstechniken und Programmiersprachen unabhängigen Aufbau
besitzt.
-
In
einem weiteren Ausführungsbeispiel
der Erfindung wird die Struktur des Übergabebereichs standardisiert.
Sie besteht aus einem allgemeinen Teil, welcher zumindest teilweise
von den Vermittlungseinheiten interpretiert wird, und einem speziellen
Teil, welcher für
die gerufene Funktion spezifisch ist und der nur vom Softwarebaustein
interpretiert wird. Um die Abhängigkeiten
in den Vermittlungseinheiten von Änderungen in den nachgelagerten
Software-Bausteinen zu minimieren, sollte der allgemeine Teil möglichst
klein gehalten werden. Falls es für eine Funktion mehrere Versionen
des speziellen Teils gibt, kann dies über eine Versionsnummer aufgezeigt werden.
Abhängig
von dieser Versionsnummer kann der gerufene Softwarebaustein verschiedene
Werte zur Startadresse addieren, um auf die Daten des Übergabespeicherbereichs
zuzugreifen. Die Vermittlungseinheit soll Versionsabhängigkeiten
nicht zur Kenntnis nehmen. Für
den allgemeinen Teil gibt es nur eine Version. Die Versionsnummer
gestattet es auch, bereits ausgelieferte Subsysteme ohne neues Compilieren
und Linken über
einen längeren
Zeitraum zu verwenden, auch wenn es bereits neuere Versionen gibt.
Dadurch kann der Nutzer der Subsysteme entscheiden, wann er für ein jeweiliges
Subsystem eine neue Version verwenden möchte.
-
Im
allgemeinen Teil des Übergabespeicherbereich
wird ein Namensdatum gespeichert, das den aufzurufenden Softwarebaustein
nach Art eines Namens eindeutig kennzeichnet. Die, jeweilige Vermittlungseinheit
kann anhand des Namensdatums feststellen, welcher Softwarebaustein
aufgerufen werden soll. Da diese Daten standardisiert, immer an
der selben Stelle relativ zur Startadresse gespeichert sind, braucht
die Vermittlungseinheit nur diese Startadresse, um durch Addition
eines vorgegebenen Werts auf die Namensdaten zuzugreifen.
-
In
einem weiteren Ausführungsbeispiel
der Erfindung wird im Subsystemverzeichnis ein Artkennzeichen gespeichert,
dessen Wert die zum Erstellen des jeweiligen Softwarebausteins verwendete Entwicklungstechnik
kennzeichnet. Der Zugriff auf den jeweiligen aufzurufenden Softwarebaustein
erfolgt in einer durch die Befehlsfolge der Vermittlungseinheit
definierten Art, abhängig
vom Wert des Artkennzeichens. Die Erfindung berücksichtigt die Erkenntnis,
daß es
vorteilhaft ist, für
die Entwicklung großer
Programmsysteme je nach konkreter Funktion eines Softwarebausteins
die jeweils zweckmäßigste Entwicklungstechnik
zu verwenden. Insbesondere sollen im Laufe der Zeit entstehende
neuere Entwicklungstechniken verwendbar sein. Deshalb wird bei diesem
Ausführungsbeispiel
das Artkennzeichen gespeichert. In diesem Artkennzeichen ist festgelegt,
mit welcher Programmiertechnik und welcher Sprache inklusive Compilerversion
die Befehle eines Softwarebausteins erstellt wurden.
-
Mit
Hilfe des Artkennzeichens und des sprachunabhängigen Aufbaus des Übergabespeicherbereichs
ist es auf einfache Art und Weise möglich zwischen verschiedenen
Entwicklungstechniken und Programmiersprachen umzuschalten. Damit übernimmt
die Vermittlungseinheit eine Transformationsfunktion zwischen verschiedenen
Entwicklungstechniken und Programmiersprachen in einem Programmsystem
oder auch in einem Subsystem. Durch die Transformationsfunktion
können
z.B. bisher notwendige Kopiervorgänge von Übergabeparametern des Übergabespeicherbereichs
oder eine Übergabe
einer Vielzahl von Übergabeparametern
in Registern des Prozessors entfallen. Als Entwicklungstechnik für die Softwarebausteine
kann zum Beispiel eine prozedurale Programmiertechnik in der Sprache
C und/oder eine objektorientierte Programmiertechnik in der Sprache
C++ verwendet werden.
-
Durch
das Artkennzeichen ist es möglich,
in den Vermittlungseinheiten eine einheitliche Befehlsfolge zu verwenden.
Abhängig
vom Artkennzeichen wird beim Abarbeiten dieser Befehlsfolgen je
nach Softwarebaustein unterschiedlich verzweigt.
-
Werden
beim Betreiben der DV-Anlage die Vermittlungseinheiten in einem
Arbeitsspeicher ständig
vorrätig
gehalten, so müssen
die Softwarebausteine eines gerufenen Subsystems erst dann in den Arbeitsspeicher
kopiert werden, wenn das Subsystem aufgerufen wird. Durch diese
Maßnahme
läßt sich
der meist begrenzte Arbeitsspeicher gut ausnutzen.
-
Vor
dem Ausführen
der Befehle eines gerufenen Softwarebausteins werden in einem weiteren Ausführungsbeispiel
der Erfindung die im folgenden genannten Prüfschritte ausgeführt. Erstens
wird geprüft,
ob das zweite Subsystem momentan im Arbeitsspeicher der DV-Anlage
gespeichert ist. Ist dies nicht der Fall, so wird das Subsystem
z.B. von einer Festplatte in den Arbeitsspeicher kopiert. Das Kopieren
kann entfallen, wenn das Subsystem bereits im Arbeitsspeicher gespeichert
ist. In einem zweiten Prüfschritt
beim Ausführen
der Befehlsfolge der Vermittlungseinheit wird geprüft, ob der
rufende Prozeß eine
Kommunikationsverbindung zum gerufenen Subsystem hat. Diese Kommunikationsverbindung ist
z.B. als Tabelle realisiert, mit deren Hilfe das betreffende Subsystem
aus einem Prozeß aufgerufen werden
kann. Wird im zweiten Prüfschritt
festgestellt, daß eine
Kommunikationsverbindung noch nicht besteht, so wird diese aufgebaut,
so daß später die
Befehle des gerufenen Softwarebausteins ausgeführt werden können. Ist
eine Kommunikationsverbindung zum gerufenen Subsystem bereits vorhanden,
so wird diese genutzt, womit ein zweiter Aufbau der Kommunikationsverbindung
entfällt.
-
In
einem dritten Prüfschritt
wird geprüft,
ob das gerufene Subsystem die gewünschte Funktionalität überhaupt
anbietet, d.h., ob der über
einen Namen bezeichnete Softwarebaustein im Verzeichnis der betreffenden
Vermittlungseinheit verzeichnet ist. Ist dies nicht der Fall, so
wird der Aufruf durch die Vermittlungseinheit mit einer entsprechenden
Fehlermeldung zurückgewiesen.
-
In
einem vierten Prüfschritt
wird geprüft,
ob der Softwarebaustein ordnungsgemäß initialisiert ist. Initialisiert
bedeutet dabei, daß der
Softwarebaustein in einem Anfangszustand ist, aus dem heraus er
sofort ausgeführt
werden kann. Zweckmäßigerweise wird
der Anfangszustand nur dann hergestellt, wenn sich der Softwarebaustein
noch nicht im Anfangszustand befindet, da so eine überflüssige Initialisierung vermieden
wird.
-
Die
genannten Prüfschritte
ermöglichen
es, Fehler frühzeitig
zu erkennen und gegebenenfalls zu beseitigen. Somit ist ein sicheres
Betreiben der DV-Anlage möglich.
Durch die Prüfschritte
wird außerdem
erreicht, daß bereits
durchgeführte
Schritte nicht unnötig
wiederholt werden.
-
Die
Erfindung ermöglicht
es, Abhängigkeiten in
bereits bestehenden Programmsystemen zu verringern oder aber Abhängigkeiten,
welche eine spätere
Weiterentwicklung behindern könnten,
beim Erstellen des Programmsystems von vorn herein zu vermeiden.
-
Die
beschriebenen Wirkungen der Erfindung treten um so mehr hervor,
je mehr Teile des Programmsystems in Subsystemen realisiert sind,
denen jeweils mindestens eine Vermittlungseinheit zugeordnet ist.
-
In
einem weiteren Ausführungsbeispiel
der Erfindung werden die Vermittlungseinheiten bzw. die Schnittstellen
des Programmsystems klassifiziert nach Vermittlungseinheiten bzw.
Schnittstellen, die von jedem Subsystem, von einigen Subsystemen oder
nur von dem zugehörigen
Subsystems aus aufrufbar sind. Mit Hilfe dieser Klassifizierung
ist es möglich,
die Abhängigkeiten
der Subsysteme voneinander je nach Klasse in einem vorgegebenen
Rahmen zu halten.
-
Ausführungsbeispiele
der Erfindung werden im folgenden anhand der Zeichnungen erläutert. Darin
zeigen:
-
1 wesentliche
elektronische Funktionseinheiten einer DV-Anlage mit mehreren Prozessoren,
-
2 eine
schematische Darstellung der Reihenfolge des Ausführens von
Befehlen verschiedener Subsysteme,
-
3 eine
schematische Darstellung der in zwei Subsystemen enthaltenen Softwarebausteine,
-
4 eine schematische Darstellung eines Übergabespeicherbereichs
und einer Vermittlungseinheit,
-
5 eine
Darstellung einer Befehlsfolge, bei deren Abarbeiten die Vermittlungseinheit
aufgerufen wird, und
-
6A und 6B Flußdiagramme
für die Schritte,
die in der Vermittlungseinheit ausgeführt werden.
-
1 zeigt
wesentliche elektronische Funktionseinheiten einer Datenverarbeitungsanlage 10, im
folgenden kurz DV-Anlage genannt. Diese DV-Anlage 10 enthält zwei
Zentralprozessoren 12 und 13, die über Leitungen 14 bzw 15 mit
einem Ein-/Ausgabeprozessor 16 verbunden
sind. Die Zentralprozessoren 12, 13 sind gleichartig
aufgebaut und jeweils über
Leitungen 17 bzw. 18 mit einem Arbeitsspeicher 20 verbunden.
Der Ein-/Ausgabeprozessor 16 ist
mit dem Arbeitsspeicher 20 über Leitungen 19 verbunden. Über Leitungen 22 ist
mit dem Ein-/Ausgabeprozessor 16 ein
Festplattenspeicher 24 mit zugehöriger Steuerung verbunden,
in dem das Betriebssystem BS der DV-Anlage 10 gespeichert ist.
Das Betriebssystem BS hat u.a. die Aufgabe, das Ausführen von Anwendungsprogrammen
auf den Zentralprozessoren 12, 13 zu verwalten.
Bei Bedarf werden vom Festplattenspeicher 24 Teile des
Betriebssystems BS in den Arbeitsspeicher 20 kopiert, um
dort von einem oder mehreren Zentralprozessoren 12, 13 ausgeführt zu werden.
Im Festplattenspeicher 24 sind auch Anwendungsprogramme
und -daten gespeichert.
-
Der
Ein-/Ausgabeprozessor 16 ist über Leitungen 25 mit
einer Schnittstelle 26 verbunden. An die Schnittstelle
könnte
periphere Geräte
angeschlossen werden, wie z.B. weitere Festplat ten, Bänder zum
Speichern digitaler Daten oder Drucker. In der 1 sind
an die Schnittstelle 26 über Leitungen 28 Ein-/Ausgabegeräte 30 bis 34 angeschlossen.
Jedes der Ein-/Ausgabegeräte 30 bis 34 hat
einen Bildschirm zum Anzeigen von Daten und eine Tastatur zum Eingeben
von Daten. Die Ein-/Ausgabegeräte 30 bis 34 werden
u.a. zum Ausführen
der Anwendungsprogramme sowie zum Einrichten und zur Pflege des
Betriebssystems BS verwendet.
-
Als
Betriebssystem BS wird das Betriebssystem BS2000/OSD Version 1.0
der Firma SIEMENS NIXDORF INFORMATIONSSYSTEME AG verwendet. Dieses
Betriebssystem BS enthält
mehr als fünf Millionen
Befehle, und seine ältesten
Softwarebausteine wurden bereits vor etwa 20 Jahren erstellt. Das
Betriebssystem BS ist in mehrere Subsysteme unterteilt, denen jeweils
bestimmte Funktionen zugeordnet sind. Diese Funktionen sind u.a.
die Verwaltung des Arbeitspeichers 20, die Verwaltung der
Zentralprozessoren 12, 13; die Verwaltung der
Ein- und Ausgaben sowie die Dateiverarbeitung in der DV-Anlage 10.
-
2 zeigt
eine schematische Darstellung der Reihenfolge der Ausführung von
Befehlen verschiedener Subsysteme. Im Arbeitsspeicher 20 sind drei
Subsysteme 50 bis 54 des Betriebssystems BS gespeichert.
Das Subsystem 50 definiert Funktionen der DV-Anlage 10,
die beim Zugriff auf Dateien verwendet werden. Das Subsystem 52 definiert
Funktionen zum Starten und Beenden von Befehlsfolgen auf den Zentralprozessoren 12, 13.
Das Subsystem 54 definiert Funktionen, die für das Verwalten
des Festplattenspeichers 24 benötigt werden.
-
Jedes
Subsystem 50, 52 bzw. 54 enthält einen
Vermittlungsbaustein 60, 62 bzw. 64.
Der Vermittlungsbaustein 60 enthält eine Befehlsfolge, die Vermittlungseinheit
VE1 genannt wird. Außerdem enthält der Vermittlungsbaustein 60 ein
Verzeichnis VZ1, das anhand der 4 weiter
unten näher
erläutert
wird. Die Vermittlungsbausteine 62 bzw. 64 enthalten
jeweils eine Befehlsfolge, die Vermittlungseinheit VE2 bzw. Vermitt lungseinheit
VE3 genannt wird. Die Vermittlungseinheiten VE1, VE2 und VE3 sind identisch
aufgebaut bzw. strukturiert. Außerdem
enthält
der Vermittlungsbaustein 62 bzw. der Vermittlungsbaustein 64 ein
Verzeichnis VZ2 bzw. ein Verzeichnis VZ3, mit dem anhand der 4 weiter unten erläuterten Aufbau.
-
In
jedem der Subsysteme 50 bis 54 sind eine Vielzahl
von Softwarebausteinen enthalten. Davon sind in 2 ein
Softwarebaustein 70 des Subsystems 50, ein Softwarebaustein 72 des
Subsystem 52 und zwei Softwarebausteine 74 und 76 des
Subsystems 54 dargestellt. Als Softwarebaustein wird eine Befehlsfolge
bezeichnet, die eine bestimmte Funktion realisiert in einer bestimmten
Entwicklungstechnik erstellt wurde und die im jeweiligen Verzeichnis
VZ1, VZ2 bzw. VZ3 eingetragen ist. Die Softwarebausteine 70 bis 76 wurden
mit einer prozeduralen Entwicklungstechnik in C erstellt. Alternativ
können
auch andere Programmiersprachen verwendet werden, z.B. Assembler.
-
Soll
zum Beispiel durch das Betriebssystem BS eine Datei erstellt werden,
so müssen
die Befehle des Softwarebausteins 70 ausgeführt werden.
Beginnend mit einem Startbefehl (Pfeil 80) werden die Befehle
des Softwarebausteins 70 durch einen der Zentralprozessoren 12, 13 ausgeführt – dargestellt
durch Pfeile 80 und 82. Da zum Erstellen der Datei
auch Speicherplatz im Festplattenspeicher 24 bereitgestellt
werden muß,
diese Funktion aber im Subsystem 54 definiert ist, ist
ein Verzweigen vom Subsystem 50 zum Subsystem 54 notwendig.
Diese Verzweigung erfolgt durch einen Sprungbefehl im Softwarebaustein 70 (Pfeil 84).
Die Ausführung
des Sprungbefehls bewirkt, daß der
Zentralprozessor 12, 13 zum Vermittlungsbaustein 64 verzweigt
und dort mit der Ausführung
der Befehlsfolge der Vermittlungseinheit VE3 beginnt. Beim Ausführen der
Befehle der Vermittlungseinheit VE3 bereitet diese den Aufruf des
benötigten
Softwarebausteins 74 unter Verwendung des Verzeichnisses
VZ3 vor (Pfeil 86). Die Verfahrensschritte in der Vermittlungseinheit
VE3 werden weiter unten anhand der 6A und 6B erläutert.
-
Hat
die Vermittlungseinheit VE3 den Aufruf des Softwarebausteins 74 vorbereitet,
so erfolgt ein Sprung zum Start des Softwarebausteins 74 (Pfeil 88).
Der Zentralprozessor 12, 13 beginnt mit dem Ausführen der
Befehle des Softwarebausteins 74 und arbeitet diese ab,
wobei Speicherplatz für
die zu erstellende Datei bereitgestellt wird (Pfeil 90).
Anschließend
erfolgt ein Rücksprung
zu einer Rücksprungadresse
im Softwarebaustein 70 (Pfeil 92). Diese Rücksprungadresse
befindet sich unmittelbar hinter dem Sprungbefehl, mit dem zur Vermittlungseinheit
VE3 verzweigt wurde. Durch Ausführen
weiterer Befehle des Softwarebausteins 70 wird das Erstellen
der Datei anschließend
beendet (Pfeil 94).
-
Die
Befehlsfolge der Vermittlungseinheit VE3 wird immer dann ausgeführt, wenn
das Subsystem 54 ein gerufenes Subsystem ist, d.h. wenn
auf Anforderung eines der Subsysteme 50 oder 52 ein
Softwarebaustein 74, 76 des Subsystems 54 auszuführen ist.
Zum Beispiel ist beim Ausführen
des Softwarebausteins 72 im Subsystem 52 eine
Funktion notwendig, die im Softwarebaustein 76 des Subsystems 54 definiert
ist. Folglich wird beim Ausführen des
Subsystems 72 die Vermittlungseinheit VE3 aufgerufen (Strichlinienpfeil 96).
-
Auch
vom Subsystem 54 aus können
Softwarebausteine 70, 72 im Subsystem 50 bzw. 52 aufgerufen
werden. Ein Strichlinienpfeil 98 zeigt einen Aufruf der
Vermittlungseinheit VE1 des Subsystems 50 durch das Subsystem 54 beim
Ausführen
des Softwarebausteins 76. Anhand der 2 wird
somit deutlich, daß durch
die Erfindung die Aufrufe zwischen den Subsystemen 50 bis 54 an
den Vermittlungsbausteinen 60 bis 64 gebündelt werden
(z.B. Pfeile 84 und 96), d.h., daß die Aufrufe
zwischen den Subsystemen 50 bis 54 prinzipiell
nur über
die Vermittlungsbausteine 60 bis 64 erfolgen.
Dies gilt auch für
Zugriffe auf Datenstrukturen. Die jeweilige Vermittlungseinheit VE1,
VE2 bzw. VE3 verteilt die Aufrufe dann innerhalb des gerufenen Subsystems 50, 52 bzw. 54.
Wie diese Verteilung realisiert wird, ist für das rufende Subsystem 50 bis 54 nicht
sichtbar. Jedes Subsystem 50 bis 54 kann somit
unabhängig
von den anderen Subsystemen 50 bis 54 erstellt
und verändert
werden, wenn bestimmte Vorgaben bzw. Standards bezüglich der
Vermittlungsbausteine 60 bis 64 eingehalten werden.
Ein Beispiel für
eine solche Vorgabe ist der folgenden Beschreibung zu entnehmen.
Die jeweilige Vorgabe hängt
vom konkreten Zweck des betreffenden Programmsystems ab und wird
vorzugsweise so gewählt,
daß später Erweiterungen
leicht durchgeführt
werden können.
-
Beim
Aufruf von Softwarebausteinen 70 bis 76 mit Hilfe
der Vermittlungsbausteine 60 bis 64 werden Übergabespeicherbereiche 97 und 99 verwendet,
die bei jedem Aufruf an verschiedenen Adressen im Arbeitsspeicher 20 beginnen
können.
Der Übergabespeicherbereich 97 beginnt
z.B. an einer Adresse ADR0. Sein Aufbau wird unten anhand des Teiles
a der 4 erläutert.
-
3 zeigt
eine detailliertere schematische Darstellung der Subsysteme 50 und 54.
Im Subsystem 50 sind neben dem genannten Softwarebaustein 70 weitere
Softwarebausteine 100 und 102 enthalten, die jedoch
in der objektorientierten Entwicklungstechnik in der Sprache C++
erstellt wurden, deren compilierte Befehle im Arbeitsspeicher 20 abgelegt
sind. Die Verwendung der objektorientierten Entwicklungstechnik
hat mehrere Vorzüge.
Zu diesen Vorzügen
gehören
zum Beispiel Datenkapselung, Vererbung und Überladen von Operatoren. Außerdem sind
im Subsystem 50 Softwarebausteine enthalten, z.B. der Softwarebaustein 70,
die in der prozeduralen Entwicklungstechnik erstellt wurden. Hierfür können z.B.
Compiler für
die Sprachen C, C++, SPL (Derivat von PL/I der SIEMENS NIXDORF INFORMATIONSSYSTEME
AG), Assembler oder auch Interpreter verwendet werden. Die Softwarebausteine,
von denen nur der Softwarebaustein 70 eingezeichnet ist,
die in der prozeduralen Entwicklungstechnik erstellt wurden, sind
in einem Block 104 zusammengefaßt. Durch den Vermittlungsbaustein 60 werden
durch einen Pfeil 120 angedeutete Aufrufe zum Softwarebaustein 100,
Aufrufe (Pfeil 122) zum Softwarebaustein 102 und
Aufrufe (Pfeil 124) zu den im Block 104 zusammengefaßten Softwarebausteinen 70 vermittelt.
-
Beim
Ausführen
der Befehle des Softwarebausteins 100 wird mindestens ein
Softwarebaustein des Subsystems 54 aufgerufen (Pfeil 150).
Ein solcher Aufruf zwischen zwei Subsystemen 50, 54 wird im
folgenden auch als externer Aufruf bezeichnet. Außerdem werden
durch den Softwarebaustein 100 weitere nicht dargestellte
Softwarebausteine des Subsystems 50 intern aufgerufen,
d.h. innerhalb des Subsystems 50 (Pfeile 152)
. Auch der Softwarebaustein 102 ruft intern weitere Softwarebausteine
des Subsystems 50 auf (Pfeile 154). Beim Abarbeiten
eines Softwarebausteins des Blocks 104 wird mindestens
ein Softwarebaustein des Subsystems 54 extern aufgerufen
(Pfeil 84).
-
Im
Subsystem 54 sind neben den bereits genannten Softwarebausteinen 74 und 76 Softwarebausteine 106 und 108 enthalten,
die in der objektorientierten Entwicklungstechnik erstellt wurden.
In einem Block 110 sind die Softwarebausteine, z.B. 74, 76 enthalten,
die in der prozeduralen Entwicklungstechnik erstellt wurden. Der
Vermittlungsbaustein 64 vermittelt Aufrufe zum Softwarebaustein 106 (Pfeil 126),
zum Softwarebaustein 108 (Pfeil 128) und zu den
im Block 110 zusammengefaßten Softwarebausteinen 74 und 76 (Pfeil 130).
-
Beim
Ausführen
der Befehle des Softwarebausteins 106 bzw. beim Ausführen von
im Block 110 enthaltenen Softwarebausteinen 74, 76 werden
auch Softwarebausteine des Subsystems 50 aufgerufen. Zwei
dieser externen Aufrufe sind durch Pfeile 98 und 156 in
der 3 angedeutet. Außerdem können beim Ausführen der
Befehle des Softwarebausteins 106 weitere Softwarebausteine
des Subsystems 54 intern aufgerufen werden (Pfeile 158).
Auch der Softwarebaustein 108 ruft intern weitere Softwarebausteine
des Subsystems 54 auf (Pfeile 160). Beim Ausführen der
Befehle des Softwarebausteins 108 erfolgt ein weiterer
interner Aufruf zu einem der prozeduralen Softwarebausteine 74, 76 (Pfeil 162).
-
Ein
Pfeil 164 symbolisiert einen internen Aufruf im Subsystem 54,
bei dem ein prozeduraler Softwarebaustein 74, 76 einen
objektorientierten Softwarebaustein 106, 108 desselben
Subsystems 54 aufruft. Bei diesem Aufruf wird die Transformatoreigenschaft
bzgl. verschiedener Entwicklungstechniken des Vermittlungsbausteins 64 des
Subsystems 54 verwendet. Die Transformatoreigenschaft wird
dabei über
ein weiter unten anhand der 4 erläutertes
Artkennzeichen realisiert. Das bedeutet letztlich, daß der interne
Aufruf wie ein externer Aufruf behandelt wird. Normalerweise ist
es nicht möglich,
abgesehen von hybriden Programmiersprachen wie C++, daß ein prozeduraler
Software-Baustein einen objektorientierten Software-Baustein aufruft.
Bei dem hier erläuterten
Ausführungsbeispiel
der Erfindung ist dies jedoch möglich.
-
Ein
Adreßwert
ADR1 kennzeichnet in der 3 die Anfangsadresse des Vermittlungsbausteins 64 im
Arbeitsspeicher 20. Außerdem
beginnt am Adreßwert
ADR1 die Befehlsfolge für
die Vermittlungseinheit VE3, die unten anhand der 6A und 6B weiter
beschrieben wird.
-
4 zeigt in einem Teil a eine schematische
Darstellung des Übergabespeicherbereichs 97 und
in einem Teil b eine schematische Darstellung des Vermittlungsbausteins 64.
Der Übergabespeicherbereich 99 gemäß 2 ist
ebenfalls wie der Übergabespeicherbereich 97 strukturiert,
beginnt jedoch an einer anderen Adresse im Arbeitsspeicher 20 und
enthält
andere Daten. Der Übergabespeicherbereich 97 hat
einen allgemeinen Teil 200 auf den die Vermittlungseinheit
VE1 bis VE3 zugreift. Der allgemeine Teil 200 wird immer
in der gleichen Weise unabhängig
vom gerufenen Softwarebaustein interpre tiert. Außerdem enthält der Übergabespeicherbereich 97 einen
spezifischen Teil 201, auf den beim Ausführen des
gerufenen Softwarebausteins zugegriffen wird. Der spezifische Teil 201 kann
dabei abhängig
vom jeweils gerufenen Softwarebaustein und von einer weiter unten
noch erläuterten
Versionsnummer 204 auf unterschiedliche Weise interpretiert werden.
Der Übergabespeicherbereich 97 beginnt
im Arbeitsspeicher 20 an der Adresse ADR0, an der ein Softwarebausteinname 202 gespeichert
wird, der den aufzurufenden Softwarebaustein nach Art eines Namens
eindeutig kennzeichnet.
-
In
einer auf die Speicherzelle mit der Adresse ADR0 folgenden Speicherzelle
mit der Adresse ADR0+1 ist die Versionsnummer 204 gespeichert, die
den Aufbau des spezifischen Teils des Übergabespeicherbereichs 97 eindeutig
kennzeichnet. In einer darauf folgenden Speicherzelle mit einer
Adresse ADR0+2 wird ein Fehlername 206 gespeichert; falls der
Aufruf des jeweils gerufenen Softwarebausteins nicht fehlerfrei
abläuft
oder die Vermittlungseinheit einen Fehler erkannt hat (vgl. 6), kennzeichnet der Fehlername 206 die
Art des aufgetretenen Fehlers.
-
In
einer weiteren Speicherzelle mit der Adresse ADR0+3, die drei Speicherplätze von
der Adresse ADR0 entfernt ist, wird ein Prozeßname 208 gespeichert,
welcher den Prozeß kennzeichnet,
in dem das gerufene Subsystem ablaufen soll. Der Softwarebausteinname 202,
die Versionsnummer 204, der Fehlername 206 und
der Prozeßname 208 gehören zum
allgemeinen Teil 200 des Übergabespeicherbereichs 97.
-
Beginnend
mit der folgenden Speicherzelle an einer Adresse ADR0+4 werden spezifische Übergabewerte 210 gespeichert,
die beim Ausführen
des jeweils gerufenen Softwarebausteins benötigt werden. Außerdem können beginnend
ab der Speicherzelle mit der Adresse ADR0+4 Ergebniswerte gespeichert
werden, die beim Ausführen
des gerufenen Softwarebausteins berechnet wur den. Die Nutzung des Übergabespeicherbereichs 97 wird
anhand der 5 weiter unten an einem Beispiel
erläutert.
-
Teil
b der 4 zeigt den Vermittlungsbaustein 64.
Beginnend ab der Startadresse ADR1 sind die Befehle der Vermittlungseinheit
VE3 gespeichert. Das durch diese Befehle definierte Verfahren wird wie
bereits erwähnt,
unten anhand der 6A und 6B erläutert.
-
Beginnend
an einer Adresse ADR2 des Arbeitsspeichers 20 liegt das
Verzeichnis VZ3. Das Verzeichnis VZ3 wird im Anschluß an das
Laden des Subsystems 54 in den Arbeitsspeicher 20 mit
konkreten Werten belegt (vgl. Schritt 402 der 6A).
Im Teil b der 4 sind drei Verzeichniseinträge 220, 250 und 270 mit
gleicher Struktur dargestellt. Als erstes ist jeweils ein Eintragsname 222, 252 bzw. 272 gespeichert,
welcher den jeweils verzeichneten Softwarebaustein nach Art eines
Namens kennzeichnet. Danach wird jeweils ein Prozeßname 224, 254 bzw. 274 gespeichert,
der durch das Betriebssystem BS spezifiziert wird und einen Prozeß bezeichnet,
in dem der jeweilige Softwarebaustein ablaufen soll. In einem weiteren
Feld der Verzeichniseinträge 220, 250 bzw. 270 werden
Artkennzeichen 226, 256 bzw. 276 zum
Kennzeichen des jeweiligen Softwarebausteins bezüglich Entwicklungstechnik und
Programmiersprache gespeichert. In den sich daran anschließenden Feldern
des jeweiligen Verzeichnisses 220, 250, 270 werden
je nach Artkennzeichen 226, 256 bzw. 276 sogenannte
artspezifische Daten 228, 258 bzw. 278 sowie
artspezifische Daten 230, 260 bzw. 280 gespeichert.
-
Der
Verzeichniseintrag 220 betrifft beispielsweise einen Teil
des Softwarebausteins 106, der durch den Eintragsnamen 222 mit
dem numerischen Wert "1" gekennzeichnet ist.
Der Prozeßname 224 ist im
Teil b der 4 nicht spezifiziert, da
er gleich dem Prozeß des
Aufrufers sein soll. Im Artkennzeichen 226 des Softwarebausteins 106 ist
mit Hilfe eines Zahlenwertes die objektorientierte Entwicklungstechnik
in der Sprache C++ verschlüsselt.
Das artspezifische Datum 228 definiert eine Adresse ADR5,
an der der Softwarebaustein 106 im Arbeitsspeicher 20 beginnt
und das artspezifische Datum 230 definiert eine Adresse
ADR6, an der die Befehle beginnen, die im Softwarebaustein 106 enthalten
sind. Die Adressen ADR5 und ADR6 unterscheiden sich, da der Softwarebaustein 106 in
objektorientierter Entwicklungstechnik erstellt wurde und seinerseits
mehrere Unter-Softwarebausteine enthält. Die Befehlsfolgen der Unter-Softwarebausteine
werden unter dem Namen "Mitgliedsfunktionen" (member functions)
des durch den jeweiligen übergeordneten
Softwarebaustein spezifizierten Objekts zusammengefaßt. Die
Adresse ADR6 ist die Startadresse des im Verzeichniseintrag 220 spezifizierten
Unter-Softwarebausteins des Softwarebausteins 106.
-
Der
Verzeichniseintrag 250 verweist auf den Softwarebaustein 74.
Der Eintragsname 252 hat den numerischen Wert "2". Der Prozeßname 254 ist aus den
bereits genannten Gründen
nicht spezifiziert. Da der Softwarebaustein 74 mit der
Programmiersprache C erstellt wurde, wird das Artkennzeichen 256 so festgelegt,
daß die
prozedurale Programmiersprache C im konkreten Zahlenwert für das Artkennzeichen 256 verschlüsselt ist.
Das artspezifische Datum 258 enthält einen Adreßwert ADR7,
der die Startadresse der Befehle des Softwarebausteins 74 nennt,
und das artspezifische Datum 230 ist nicht spezifiziert,
da zum Ausführen
des Softwarebausteins 74 nur die Adresse ADR7 bekannt sein
muß.
-
Der
Verzeichniseintrag 270 verweist auf den Softwarebaustein 76.
Dieser Softwarebaustein hat den Eintragsnamen 272 mit dem
numerischen Wert "3" und einen in 4 unspezifizierten Prozeßnamen 274.
Das Artkennzeichen 276 des Softwarebausteins 76 enthält einen
Zahlenwert für
die prozedurale Programmiersprache ASSEMBLER. Das artspezifische Datum 278 enthält einen
Adreßwert
ADR8, der auf den Beginn der Befehle des Softwarebausteins 76 verweist
und das artspezifische Datum 280 ist nicht spezifiziert,
da es beim Zugriff auf den Softwarebaustein 76 nicht notwendig
ist.
-
5 zeigt
eine schematische Darstellung von Befehlen 300 bis 318 für den Softwarebaustein 70,
welche in der prozeduralen Programmiersprache C geschrieben sind.
Die vor dem Befehl 308 liegenden Befehle 300 bis 306 dienen
der Vorbereitung des Anlegens der Datei. Der Befehl 308 dient
dem Bereitstellen von Speicherplatz auf der Festplatte 24 für das Anlegen
der Datei. Dazu müssen
die compilierten Befehle des Softwarebausteins 74 im Subsystem 54 ausgeführt werden.
Für den
C-Compiler wird durch ein Rautenzeichen 320 gefolgt von
dem Schlüsselwort "include" signalisiert, daß beim Compilieren
eine weiter unten erläuterte
Befehlsfolge aus Maschinenbefehlen 330 bis 340 anstelle
des Befehls 308 einzufügen
ist, angedeutet durch einen Pfeil 350. Die Maschinenbefehle 330 bis 340 werden
beim Ausführen
des Softwarebausteins 70 direkt von einem der Zentralprozessoren 12, 13 abgearbeitet.
Die nach dem Befehl 308 folgenden Befehle 310 bis 318 beziehen
sich auf Funktionen nach dem Erstellen einer Datei. Es kann z.B.
hierbei überprüft werden,
ob das Erstellen der jeweiligen Datei erfolgreich war.
-
Im
Befehl 308 wird durch das Rautenzeichen 320 gefolgt
von dem Schlüsselwort "include" und der Bezeichnung "Dateispeicher" der Compiler angewiesen,
die Maschinenbefehle 330 bis 340 so zu generieren,
daß der
Softwarebaustein 74 unter Einbeziehung der Vermittlungseinheit 64 des
Subsystems 54 ausgeführt
wird. Dazu verarbeitet der Compiler den im Befehl 308 angegebenen
Dateinamen der zu erstellenden Datei und die angegebene Zugriffsart.
Die Zugriffsart kann z.B. so festgelegt werden, daß auf die
erstellte Datei sowohl lesend als auch schreibend zugegriffen werden
kann.
-
Der
Maschinenbefehl 330 bewirkt, daß der Softwarebausteinname
(SB-Name) 202 (vgl. Teil a 4)
im Übergabespeicherbereich
(ÜSB) einen Wert
erhält,
z.B. im Fall des Softwarebausteins 74 den numerischen Wert "2", und damit den zur Ausführung des
jeweiligen Befehls, z.B. "Dateispeicher", benötigten Softwarebaustein
kennzeichnet.
-
Die
Maschinenbefehle 332 und 334 bewirken, daß der konkrete
Dateiname der anzulegenden Datei in den jeweiligen Übergabespeicherbereich (ÜSB), z.B. 97 gemäß Teila 4, als erster Übergabewert 210 und
die Zugriffsart als zweiter Übergabewert 210 gespeichert
werden. Durch den Befehl 336 wird die Adresse, z.B. ADR0,
an der der Übergabespeicherbereich 97 beginnt,
in ein Register R1 des Zentralprozessors 12, 13 geladen.
Durch den Befehl 338 wird die Adresse ADR1 in ein Register
R15 des Zentralprozessors 12, 13 geladen. Das
Ermitteln der Adresse ADR1 erfolgt dabei in zwei Schritten. Anbieter
und Nutzer einer Schnittstelle arbeiten mit Namen der Vermittlungseinheiten,
die in einer Spezifikation hinterlegt sind. Erst beim Linken wird
der Name einer jeweiligen Vermittlungseinheit durch die konkrete Adresse
ersetzt. Die Adresse ADR1 stimmt mit der Anfangsadresse der Vermittlungseinheit
VE3 des Vermittlungsbausteins 64 überein. Durch den Befehl 340 erfolgt
anschließend
ein Sprung zur Adresse, die im Register R15 enthalten ist, nämlich zur
Adresse ADR1. Somit wird nach Ausführen des Sprunges mit dem Abarbeiten
der Befehle der Vermittlungseinheit VE3 begonnen. In diesem Ausführungsbeispiel
ist die Verwendung der Register R1 und R15 konventioniert.
-
Die 6A und 6B zeigen
ein Flußdiagramm
für die
Verfahrensschritte, die beim Abarbeiten der Befehle der Vermittlungseinheit
VE3 ausgeführt
werden. Im Schritt 400 beginnen die Verfahrensschritte
der Vermittlungseinheit VE3 an der oben bezeichneten Adresse ADR1.
Zu diesem Zeitpunkt sind im Übergabespeicherbereich 97 gemäß Teil a 4 der Softwarebausteinname 202 und
gegebenenfalls ein oder mehrere Übergabewerte 210 festgelegt.
-
Im
Schritt 402 wird geprüft,
ob sich das zur Vermittlungseinheit VE3 gehörende Subsystem 54 bereits
im Arbeitsspeicher 20 befindet und ausgeführt werden
kann. Ist dies nicht der Fall, so wird im Schritt 403 das
Laden des Subsystems 54 in den Arbeitsspeicher 20 veranlaßt. Im Schritt 404 wird
geprüft,
ob das Laden des Subsystems 54 (vgl. 2) erfolgreich
war. Ist dies nicht der Fall, so wird im Schritt 404 der
Fehlername 206 (vgl. Teil a 4)
mit einem ersten Fehlerwert belegt. Nach dem Schritt 405 wird
zu einem weiter unten erläuterten
Schritt 444 verzweigt. Wird im Schritt 402 bzw.
im Schritt 404 jedoch festgestellt, daß das Subsystem 54 im
Arbeitsspeicher 20 ausgeführt werden kann, so wird unmittelbar
nach dem Schritt 402 bzw. nach dem Schritt 404 der
Verfahrensschritt 406 ausgeführt.
-
Im
Schritt 406 wird geprüft,
ob das gerufene Subsystem 54 mit dem rufenden Prozeß verbunden ist,
d.h. es wird geprüft,
ob eine Kommunikationsverbindung zwischen dem rufenden Prozeß und dem Subsystem 50 existiert.
Ist dies nicht der Fall, so wird in Schritt 407 das Herstellen
dieser Kommunikationsverbindung veranlaßt. In einem sich daran anschließenden Schritt 408 wird
geprüft,
ob die Kommunikationsverbindung erfolgreich hergestellt werden konnte.
Ist dies nicht der Fall, so wird in Schritt 409 der Fehlername 206 (vgl.
Teil a 4) mit einem zweiten Fehlerwert
spezifiziert. Anschließend
wird das Verfahren im Schritt 444 fortgesetzt. Wird im
Schritt 406 bzw. im Schritt 408 jedoch festgestellt,
daß das
gerufene Subsystem 54 mit dem rufenden Prozeß verbunden
ist, so wird unmittelbar auf den Schritt 406 folgend der
Schritt 410 ausgeführt.
-
Im
Schritt 410 wird geprüft,
ob der durch den Softwarebausteinnamen 202 (vgl. Teil a 4) spezifizierte Softwarebaustein im zugehörigen Subsystem 54 (vgl. 2)
vorhanden ist, indem die Verzeichniseinträge 222, 252 und 272 (vgl.
Teil b 4) mit dem Softwarebausteinnamen 202 verglichen werden.
Der Softwarebausteinname 202 kann durch die Vermitt lungseinheit
VE3 ermittelt werden, da die Adresse ADR0, an der der Übergabespeicherbereich beginnt,
konventionsgemäß im Register
R1 des Zentralprozessors 12, 13 verfügbar ist.
Wird der gerufene Softwarebaustein nicht im Verzeichnis VZ3 gefunden,
so wird der Fehlername 206 (vgl. Teil a 4) mit
einem dritten Fehlerwert belegt (Schritt 412). Anschließend wird
das Verfahren im Schritt 444 fortgesetzt. Wird im Schritt 410 jedoch
festgestellt, daß der Softwarebaustein
im gerufenen Subsystem vorhanden ist, so wird unmittelbar nach dem
Schritt 410 der Verfahrensschritt 414 ausgeführt. Der
Softwarebaustein "Dateispeicher", dessen Eintragsname
den numerischen Wert "2" hat wird beispielsweise
als zweiter Verzeichniseintrag 250 (vgl. Teil b der 4) lokalisiert.
-
Im
Schritt 414 wird geprüft,
ob der gerufene Softwarebaustein in einem anderen Prozeß ablaufen soll,
indem die Prozeßnamen 208 und 254 (vgl.
Teil b der 4) mit dem der Vermittlungseinheit
VE3 momentan zugeordneten Prozeßnamen
verglichen werden. Wird im Schritt 414 festgestellt, daß der Softwarebaustein
in einem anderen Prozeß ablaufen
soll, so wird im Schritt 418 zu diesem anderen Prozeß umgeschaltet.
Anschließend
wird der Schritt 420 ausgeführt. Wird jedoch im Schritt 414 festgestellt,
daß der Softwarebaustein
im gleichen Prozeß zur
Verfügung steht,
so entfällt
das Umschalten im Schritt 418 und unmittelbar nach dem
Schritt 414 wird der Schritt 420 ausgeführt.
-
Im
Schritt 420 wird geprüft,
ob der jeweilige Softwarebaustein, z.B. 74 (vgl. 2),
bereits initialisiert ist. Die Initialisierung umfaßt z.B.
das Anlegen und Versorgen von Verwaltungstabellen mit konkreten
Werten, welche für
den gerufenen Softwarebaustein spezifisch sind. Gegebenenfalls erfolgt
im Schritt 422 die Initialisierung des Softwarebausteins und
in einem anschließenden
Schritt 424 wird überprüft, ob die
Initialisierung erfolgreich durchgeführt wurde. Wird im Schritt 424 festgestellt,
daß die
Initialisierung nicht oder nicht vollständig durchgeführt werden
konnte, so wird im Schritt 426 der Fehlername 206 (vgl.
Teil a 4) durch einen vierten Fehlerwert
spezifiziert und das Verfahren im Schritt 444 fortgesetzt.
-
Wird
im Schritt 424 festgestellt, daß die Initialisierung erfolgreich
durchgeführt
wurde, so wird das Verfahren im Schritt 428 fortgesetzt.
Der Schritt 428 folgt jedoch unmittelbar auf den Schritt 420, wenn
in diesem Schritt 420 festgestellt wird, daß der gerufene
Softwarebaustein bereits initialisiert ist.
-
Im
Schritt 428 wird die Art des Softwarebausteins bestimmt,
indem das Artkennzeichen, z.B. 256 (vgl. Teil b 4) gelesen wird. Im Fall des Softwarebausteins 74 wird
ermittelt, daß der
Softwarebaustein 74 in der Sprache C erstellt wurde. Anschließend wird
in einem Schritt 430 gefragt, ob der gerufene Softwarebaustein
mit der Sprache C erstellt wurde. Ist dies der Fall, so werden im
Schritt 432 die im Softwarebaustein enthaltenen Befehle
aufgerufen. Damit ist das Verfahren in einem Schritt 441 beendet.
Wird im Schritt 430 jedoch festgestellt, daß der Softwarebaustein
nicht in der Sprache C erstellt wurde, so folgt unmittelbar nach
dem Schritt 430 der Schritt 434.
-
Im
Schritt 434 wird geprüft,
ob der gerufene Softwarebaustein mit der Sprache C++ erstellt wurde.
Ist dies der Fall, so wird im Schritt 436 der Softwarebaustein
aufgerufen. Zum Aufrufen des Softwarebausteins wird u.a. das artspezifische
zweite Datum, z.B. 230 (vgl. Teil b 4),
gelesen, um den Anfang des auszuführenden Softwarebausteins zu ermitteln.
Damit ist das Verfahren im Schritt 441 beendet. Wird im
Schritt 434 jedoch festgestellt, daß der Softwarebaustein nicht
mit der Sprache C++ erstellt worden ist, so wird unmittelbar nach
dem Schritt 434 der Schritt 438 ausgeführt.
-
Im
Schritt 438 wird geprüft,
ob der jeweils gerufene Softwarebaustein mit der Programmiersprache
ASSEMBLER erstellt wurde. Ist dies der Fall, so wird im Schritt 440 der
gerufene Softwarebaustein aufgerufen, womit das Verfahren im Schritt 441 beendet
ist.
-
Wird
im Schritt 438 jedoch festgestellt, daß der jeweils gerufene Softwarebaustein
auch nicht mit der Programmiersprache ASSEMBLER erstellt wurde,
so erfolgt unmittelbar nach dem Schritt 438 der Schritt 442,
in dem der Fehlername 206 (vgl. Teil a 4)
mit einem fünften
Fehlerwert belegt wird. Anschließend erfolgt das Ausführen des
bereits mehrfach erwähnten
Schrittes 444.
-
Das
beschriebene Verfahren ist auf einfache Art und Weise auf andere
als die genannten Entwicklungstechniken und Programmiersprachen
erweiterbar, indem zwischen den Schritten 438 und 442 zusätzliche
Schritte eingefügt
werden.
-
Im
Schritt 444 wird das durch die Befehle der Vermittlungseinheit
VE3 vorgegebene Verfahren für Fehlerfälle beendet.
In einem der Schritte 405, 409, 412, 426 oder 442 wurde
der Fehlername 206 (vgl. Teil a 4)
spezifiziert. Im Schritt 444 erfolgt ein Rücksprung
in das rufende Subsystem, z.B. 50. Dort wird anhand der
Werte im Übergabespeicherbereich 97 (vgl.
Teil a 4) festgestellt, ob der Softwarebaustein
erfolgreich ausgeführt
werden konnte. In diesem Falle ist der Fehlername 206 (vgl.
Teil a 4) ein Standardwert, z.B. Null.
Hat der Fehlername 206 jedoch einen vom Standardwert abweichenden
Wert, so kann anhand dieses Wertes festgestellt werden, welcher
Fehler aufgetreten ist. Dieser Fehler kann anschließend durch
den Aufrufer behoben werden, und es kann ein nochmaliger Aufruf
der Vermittlungseinheit erfolgen.
-
Beim
Ausführen
des jeweils gerufenen Softwarebausteins im Schritt 432, 436 oder 440 kann
der Rücksprung
direkt vom Softwarebaustein zum rufenden Subsystem. oder indirekt über die
Vermittlungseinheit des gerufenen Subsystems erfolgen. Schritt 444 wird
in diesem Fall nicht ausgeführt.
Gegebenen falls sind auch Ergebniswerte als Übergabewerte 210 (vgl.
Teil a 4) spezifiziert worden, die
im rufenden Subsystem weiterverwendet werden können.