DE19637883A1 - Verfahren zum Erstellen und Betreiben großer Programmsysteme auf einer Datenverarbeitungsanlage - Google Patents

Description

Die Erfindung betrifft ein Verfahren zum Betreiben einer Da­ tenverarbeitungsanlage, die mindestens einen Prozessor ent­ hält, der Befehle eines Programmsystems ausführt.

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 verstan­ den. Ein Programmsystem ist zum Beispiel ein Betriebssystem für die Steuerung der Grundfunktionen der Datenverarbeitungs­ anlage, 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 Spei­ chersubsystem 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 Ar­ beiten 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 unter­ teilt. Die Befehle zum Ausführen einer Funktion oder zum Aus­ führen einer Teilfunktion sind zu einem Softwarebaustein zu­ sammengefaßt. Ein Softwarebaustein ist zum Beispiel eine Be­ fehlsfolge, auch Prozedur genannt, die an einer Startadresse beginnt und an einer Endadresse endet. Üblich ist das Bereit­ stellen 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 Bei­ spiel, nämlich das Anlegen einer Datei, kann z. B. eine Teil­ funktion für die Vorbereitung des Anlegens der Datei als Softwarebaustein im Dateisubsystem sowie eine andere Teil­ funktion, nämlich das Bereitstellen von Speicherplatz zum An­ legen der Datei im Speicher der DV-Anlage, als weiterer Soft­ warebaustein im Speichersubsystem definiert sein. Wenn nun Änderungen am Softwarebaustein im Speichersubsystem vorgenom­ men werden, so können sich diese Änderungen auch auf den Softwarebaustein im Dateisubsystem auswirken, z. B. im Hin­ blick 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 Pa­ rameter und durch die verwendeten Entwicklungstechniken für die Softwarebausteine bestimmt. Weitere Abhängigkeiten ent­ stehen, wenn auf eine Datenstruktur aus verschiedenen Subsy­ stemen heraus zugegriffen wird, da bei Änderungen der Daten­ struktur der Zugriff in allen Subsystemen geändert werden muß, die auf diese Datenstruktur zugreifen. Die Verschieden­ artigkeit und die Vielzahl der Abhängigkeiten im Programmsy­ stem 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 wer­ den und sich dabei aufgrund der zunehmenden Zahl von Funktio­ nen in der Regel vergrößern, steigt aufgrund der genannten Abhängigkeiten der Aufwand für Neuentwicklungen und Änderun­ gen 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ön­ nen. Über die Zeit betrachtet steigt der Aufwand für Änderun­ gen bei dem Betriebssystem in etwa exponentiell an.

Aufgabe der Erfindung ist es, ein Verfahren zum Betreiben ei­ ner Datenverarbeitungsanlage anzugeben, das bei der Abarbei­ tung der Befehle eines Programmsystems mit einer Vielzahl von Subsystemen einen fehlerfreien Betrieb gewährleistet und Än­ derungen im Programmsystem auf einfache Art und Weise gestat­ tet. Diese Änderungen sollen unter Zuhilfenahme modernster Entwicklungstechniken und Programmiersprachen durchgeführt werden können.

Diese Aufgabe wird gelöst durch ein Verfahren zum Betreiben einer DV-Anlage, die mindestens einen Prozessor enthält, der Befehle eines Programmsystems ausführt, wobei das Programmsy­ stem mehrere Subsysteme enthält, die im wesentlichen vonein­ ander unabhängig erstellbar sind und die vorgegebene Funktio­ nen der DV-Anlage definieren. Ein Softwarebaustein für minde­ stens eine Funktion eines ersten Subsystems ist Bestandteil eines zweiten Subsystems.

Jedes Subsystem hat bei der Erfindung mindestens eine im we­ sentlichen gleichartig aufgebaute Vermittlungseinheit, die für das betreffende Subsystem oder einen Teil davon ein Ver­ zeichnis enthält, welches auf im jeweiligen Subsystem enthal­ tene 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 Funk­ tion zugeordneten Softwarebaustein auf. Die Vermittlungsein­ heit übernimmt dabei auch nötigenfalls die Aufgabe, die Ver­ knüpfung zu einer anderen Entwicklungstechnik und Program­ miersprache herzustellen. Nach dem Ausführen der Befehle dieses Softwarebausteins wird zum ersten Subsystem zurückge­ kehrt.

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 über­ sichtlich realisiert, so können die oben beschriebenen Nach­ teile verhindert werden. Zu diesem Zweck hat bei der Erfin­ dung jedes Subsystem mindestens eine im wesentlichen gleich­ artig aufgebaute Vermittlungseinheit. Die Aufrufe von Soft­ warebausteinen zwischen den Subsystemen erfolgen bei der Er­ findung prinzipiell nur noch über die Vermittlungseinheiten. Damit stellen die Vermittlungseinheiten die hauptsächliche Schnittstelle zwischen den Subsystemen dar. Die Abhängigkei­ ten der Subsysteme sind somit gebündelt und überschaubar. Au­ ßerdem werden die Aufrufe zwischen Subsystemen vereinheit­ licht und erfolgen bei der Erfindung bezüglich jeder Vermitt­ lungseinheit 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 Subsy­ stems ausgeführt. Nach außen hin kann dadurch die konkrete Realisierung einer bestimmten Funktion innerhalb des Subsy­ stems 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äch­ liche Realisierung des betreffenden Subsystems ist somit ge­ genüber der Umgebung, d. h. gegenüber den anderen Subsystemen verborgen. Innerhalb eines Subsystems können deshalb die Da­ tenstrukturen frei gewählt und auch frei geändert werden, oh­ ne daß aufrufende 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 Entwicklungstech­ niken übergegangen wird. So kann zum Beispiel innerhalb eines Subsystems schrittweise von einer prozeduralen Technik zu ei­ ner 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 enthal­ tene 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 ausge­ fü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 Vermittlungsein­ heit enthaltenen Befehlsfolge begonnen wird. Beim Ausführen dieser Befehlsfolge wird mit Hilfe des jeweiligen Subsystem­ verzeichnisses der für die Ausführung der Funktion benötigte Softwarebaustein ermittelt. Anschließend werden dessen Be­ fehle ausgeführt. Der Zugriff ist somit einfach zu realisie­ ren. Insbesondere wird die Vermittlungseinheit des rufenden Subsystems nicht benötigt, so daß Kommunikationsprozesse zwi­ schen Vermittlungseinheiten entfallen.

Nach dem Ausführen der Befehle des Softwarebausteins wird in der Regel zum rufenden Subsystem zurückgekehrt. Das Zurück­ kehren kann mit oder ohne Verwenden der Vermittlungseinheit des gerufenen Systems und ohne Verwenden der Vermittlungsein­ heit des rufenden Systems erfolgen. Damit ist das Zurückkeh­ ren 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 Aus­ wahl und der Aufruf der jeweiligen Vermittlungseinheit über ihren konventionierten Namen. Diese Namen sind Teil der Schnittstellenspezifikation und werden beim Binden des Pro­ grammsystems zu Adreßwerten aufgelöst, welche dann in Sprung­ befehlen verwendet werden.

In einem weiteren Ausführungsbeispiel der Erfindung erfolgt der Aufruf der Vermittlungseinheit unter Verwenden eines Übergabespeicherbereichs, der an einer Startadresse beginnt, die vorzugsweise an diese Vermittlungseinheit in einem Regi­ ster des Prozessors übermittelt wird. In diesem Übergabespei­ cherbereich 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 Programmsy­ stems für den Ablauf in den Vermittlungseinheiten denselben Binärcode zu verwenden. Wird eine Vermittlungseinheit paral­ lel bzw. gleichzeitig mehrfach aufgerufen, so werden unter­ schiedliche Startadressen verwendet um ein überschreiben der Übergabespeicherbereiche zu verhindern. Somit ist ein soge­ nannter Mehrfacheintritt in die Vermittlungseinheiten mög­ lich.

Die Übergabe der Parameter an die aufzurufende Funktion er­ folgt mit Hilfe des Übergabespeicherbereichs, welcher eine von den im ersten Subsystem und im zweiten Subsystem verwen­ deten Entwicklungstechniken und Programmiersprachen unabhän­ gigen 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 speziel­ len 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 Soft­ warebaustein 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 ausge­ lieferte 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 Na­ mensdatum 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 Da­ ten standardisiert, immer an der selben Stelle relativ zur Startadresse gespeichert sind, braucht die Vermittlungsein­ heit nur diese Startadresse, um durch Addition eines vorgege­ benen 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 ver­ wendete 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 ver­ wendbar sein. Deshalb wird bei diesem Ausführungsbeispiel das Artkennzeichen gespeichert. In diesem Artkennzeichen ist festgelegt, mit welcher Programmiertechnik und welcher Spra­ che inklusive Compilerversion die Befehle eines Softwarebau­ steins erstellt wurden.

Mit Hilfe des Artkennzeichens und des sprachunabhängigen Auf­ baus 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 Ko­ piervorgänge von Übergabeparametern des Übergabespeicherbe­ reichs oder eine Übergabe einer Vielzahl von Übergabeparame­ tern in Registern des Prozessors entfallen. Als Entwick­ lungstechnik 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 Vermitt­ lungseinheiten eine einheitliche Befehlsfolge zu verwenden. Abhängig vom Artkennzeichen wird beim Abarbeiten dieser Be­ fehlsfolgen je nach Softwarebaustein unterschiedlich ver­ zweigt.

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 aufge­ rufen wird. Durch diese Maßnahme läßt sich der meist be­ grenzte Arbeitsspeicher gut ausnutzen.

Vor dem Ausführen der Befehle eines gerufenen Softwarebau­ steins werden in einem weiteren Ausführungsbeispiel der Er­ findung die im folgenden genannten Prüfschritte ausgeführt. Erstens wird geprüft, ob das zweite Subsystem momentan im Ar­ beitsspeicher 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 Software­ baustein ordnungsgemäß initialisiert ist. Initialisiert be­ deutet dabei, daß der Softwarebaustein in einem Anfangszu­ stand ist, aus dem heraus er sofort ausgeführt werden kann. Zweckmäßigerweise wird der Anfangszustand nur dann herge­ stellt, wenn sich der Softwarebaustein noch nicht im Anfangs­ zustand 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üf­ schritte wird außerdem erreicht, daß bereits durchgeführte Schritte nicht unnötig wiederholt werden, so daß sich das Verfahren zum Betreiben der Datenverarbeitungsanlage verein­ facht und beschleunigt.

Die Erfindung betrifft außerdem eine DV-Anlage zum Ausführen eines Programmsystems, mit den Merkmalen des Patentanspruchs 21. Die weiter oben beschriebenen vorteilhaften Wirkungen gelten auch für diesen Aspekt der Erfindung.

Das Verfahren nach der Erfindung ermöglicht es, Abhängigkei­ ten in bereits bestehenden Programmsystemen zu verringern oder aber Abhängigkeiten, welche eine spätere Weiterentwick­ lung 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 rea­ lisiert sind, denen jeweils mindestens eine Vermittlungsein­ heit zugeordnet ist.

In einem weiteren Ausführungsbeispiel der Erfindung werden die Vermittlungseinheiten bzw. die Schnittstellen des Pro­ grammsystems klassifiziert nach Vermittlungseinheiten bzw. Schnittstellen, die von jedem Subsystem, von einigen Sub­ systemen oder nur von dem zugehörigen Subsystems aus aufruf­ bar 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:

Fig. 1 wesentliche elektronische Funktionseinheiten ei­ ner DV-Anlage mit mehreren Prozessoren,

Fig. 2 eine schematische Darstellung der Reihenfolge des Ausführens von Befehlen verschiedener Subsysteme,

Fig. 3 eine schematische Darstellung der in zwei Subsy­ stemen enthaltenen Softwarebausteine,

Fig. 4 eine schematische Darstellung eines Übergabespei­ cherbereichs und einer Vermittlungseinheit,

Fig. 5 eine Darstellung einer Befehlsfolge, bei deren Abarbeiten die Vermittlungseinheit aufgerufen wird, und

Fig. 6A und 6B Flußdiagramme für die Schritte, die in der Ver­ mittlungseinheit ausgeführt werden.

Fig. 1 zeigt wesentliche elektronische Funktionseinheiten einer Datenverarbeitungsanlage 10, im folgenden kurz DV-Anla­ ge genannt. Diese DV-Anlage 10 enthält zwei Zentralprozesso­ ren 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öri­ ger Steuerung verbunden, in dem das Betriebssystem BS der DV-An­ lage 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 Fest­ plattenspeicher 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 peri­ phere Geräte angeschlossen werden, wie z. B. weitere Festplat­ ten, Bänder zum Speichern digitaler Daten oder Drucker. In der Fig. 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 Anwen­ dungsprogramme sowie zum Einrichten und zur Pflege des Betriebssystems BS verwendet.

Als Betriebssystem BS wird das Betriebssystem BS2000/OSD Ver­ sion 1.0 der Firma SIEMENS NIXDORF INFORMATIONSSYSTEME AG verwendet. Dieses Betriebssystem BS enthält mehr als fünf Millionen Befehle, und seine ältesten Softwarebausteine wur­ den bereits vor etwa 20 Jahren erstellt. Das Betriebssystem BS ist in mehrere Subsysteme unterteilt, denen jeweils be­ stimmte 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.

Fig. 2 zeigt eine schematische Darstellung der Reihenfolge der Ausführung von Befehlen verschiedener Subsysteme. Im Ar­ beitsspeicher 20 sind drei Subsysteme 50 bis 54 des Betriebs­ systems BS gespeichert. Das Subsystem 50 definiert Funktionen der DV-Anlage 10, die beim Zugriff auf Dateien verwendet wer­ den. 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 Vermittlungsbau­ stein 60, 62 bzw. 64. Der Vermittlungsbaustein 60 enthält ei­ ne Befehlsfolge, die Vermittlungseinheit VE1 genannt wird. Außerdem enthält der Vermittlungsbaustein 60 ein Verzeichnis VZ1, das anhand der Fig. 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 Vermitt­ lungsbaustein 64 ein Verzeichnis VZ2 bzw. ein Verzeichnis VZ3, mit dem anhand der Fig. 4 weiter unten erläuterten Auf­ bau.

In jedem der Subsysteme 50 bis 54 sind eine Vielzahl von Softwarebausteinen enthalten. Davon sind in Fig. 2 ein Soft­ warebaustein 70 des Subsystems 50, ein Softwarebaustein 72 des Subsystem 52 und zwei Softwarebausteine 74 und 76 des Subsystems 54 dargestellt. Als Softwarebaustein wird eine Be­ fehlsfolge 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 proze­ duralen Entwicklungstechnik in C erstellt. Alternativ können auch andere Programmiersprachen verwendet werden, z. B. Assembler.

Soll zum Beispiel durch das Betriebssystem BS eine Datei er­ stellt 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 Speicher­ platz 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 Softwarebau­ stein 70 (Pfeil 84). Die Ausführung des Sprungbefehls be­ wirkt, daß der Zentralprozessor 12, 13 zum Vermittlungsbau­ stein 64 verzweigt und dort mit der Ausführung der Befehls­ folge 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 Fig. 6A und 6B erläutert.

Hat die Vermittlungseinheit VE3 den Aufruf des Softwarebau­ steins 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 er­ stellende Datei bereitgestellt wird (Pfeil 90). Anschließend erfolgt ein Rücksprung zu einer Rücksprungadresse im Soft­ warebaustein 70 (Pfeil 92). Diese Rücksprungadresse befindet sich unmittelbar hinter dem Sprungbefehl, mit dem zur Ver­ mittlungseinheit VE3 verzweigt wurde. Durch Ausführen weite­ rer 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 Softwarebau­ stein 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 Subsy­ stems 50 durch das Subsystem 54 beim Ausführen des Software­ bausteins 76. Anhand der Fig. 2 wird somit deutlich, daß durch die Erfindung die Aufrufe zwischen den Subsystemen 50 bis 54 an den Vermittlungsbausteinen 60 bis 64 gebündelt wer­ den (z. B. Pfeile 84 und 96), d. h., daß die Aufrufe zwischen den Subsystemen 50 bis 54 prinzipiell nur über die Vermitt­ lungsbausteine 60 bis 64 erfolgen. Dies gilt auch für Zugrif­ fe auf Datenstrukturen. Die jeweilige Vermittlungseinheit VE1, VE2 bzw. VE3 verteilt die Aufrufe dann innerhalb des ge­ rufenen Subsystems 50, 52 bzw. 54. Wie diese Verteilung rea­ lisiert 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 wer­ den, wenn bestimmte Vorgaben bzw. Standards bezüglich der Vermittlungsbausteine 60 bis 64 eingehalten werden. Ein Bei­ spiel 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 übergabespeicherberei­ che 97 und 99 verwendet, die bei jedem Aufruf an verschiede­ nen Adressen im Arbeitsspeicher 20 beginnen können. Der Über­ gabespeicherbereich 97 beginnt z. B. an einer Adresse ADR0. Sein Aufbau wird unten anhand des Teiles a der Fig. 4 erläu­ tert.

Fig. 3 zeigt eine detailliertere schematische Darstellung der Subsysteme 50 und 54. Im Subsystem 50 sind neben dem ge­ nannten Softwarebaustein 70 weitere Softwarebausteine 100 und 102 enthalten, die jedoch in der objektorientierten Entwick­ lungstechnik in der Sprache C++ erstellt wurden, deren compi­ lierte Befehle im Arbeitsspeicher 20 abgelegt sind. Die Ver­ wendung der objektorientierten Entwicklungstechnik hat meh­ rere Vorzüge. Zu diesen Vorzügen gehören zum Beispiel Daten­ kapselung, Vererbung und Überladen von Operatoren. Außerdem sind im Subsystem 50 Softwarebausteine enthalten, z. B. der Softwarebaustein 70, die in der prozeduralen Entwicklungs­ technik 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 ver­ wendet werden. Die Softwarebausteine, von denen nur der Soft­ warebaustein 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 Softwarebau­ stein 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 auf­ gerufen, d. h. innerhalb des Subsystems 50 (Pfeile 152). Auch der Softwarebaustein 102 ruft intern weitere Softwarebau­ steine 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 Softwarebau­ steinen 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 Auf­ rufe zum Softwarebaustein 106 (Pfeil 126), zum Softwarebau­ stein 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 Softwarebaustei­ nen 74, 76 werden auch Softwarebausteine des Subsystems 50 aufgerufen. Zwei dieser externen Aufrufe sind durch Pfeile 98 und 156 in der Fig. 3 angedeutet. Außerdem können beim Aus­ führen der Befehle des Softwarebausteins 106 weitere Soft­ warebausteine des Subsystems 54 intern aufgerufen werden (Pfeile 158). Auch der Softwarebaustein 108 ruft intern wei­ tere Softwarebausteine des Subsystems 54 auf (Pfeile 160). Beim Ausführen der Befehle des Softwarebausteins 108 erfolgt ein weiterer interner Aufruf zu einem der prozeduralen Soft­ warebausteine 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 Subsy­ stems 54 aufruft. Bei diesem Aufruf wird die Transformatorei­ genschaft bzgl. verschiedener Entwicklungstechniken des Ver­ mittlungsbausteins 64 des Subsystems 54 verwendet. Die Transformatoreigenschaft wird dabei über ein weiter unten an­ hand der Fig. 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üh­ rungsbeispiel der Erfindung ist dies jedoch möglich.

Ein Adreßwert ADR1 kennzeichnet in der Fig. 3 die Anfangs­ adresse des Vermittlungsbausteins 64 im Arbeitsspeicher 20. Außerdem beginnt am Adreßwert ADR1 die Befehlsfolge für die Vermittlungseinheit VE3, die unten anhand der Fig. 6A und 6B weiter beschrieben wird.

Fig. 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äß Fig. 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 allge­ meinen 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 gespei­ chert 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 ADRO+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 ADRO+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. Fig. 6), kennzeichnet der Fehlername 206 die Art des aufgetretenen Fehlers.

In einer weiteren Speicherzelle mit der Adresse ADRO+3, die drei Speicherplätze von der Adresse ADR0 entfernt ist, wird ein Prozeßname 208 gespeichert, welcher den Prozeß kennzeich­ net, in dem das gerufene Subsystem ablaufen soll. Der Soft­ warebausteinname 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 ADRO+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 ADRO+4 Ergebniswerte gespeichert werden, die beim Ausführen des gerufenen Softwarebausteins berechnet wur­ den. Die Nutzung des Übergabespeicherbereichs 97 wird anhand der Fig. 5 weiter unten an einem Beispiel erläutert.

Teil b der Fig. 4 zeigt den Vermittlungsbaustein 64. Begin­ nend ab der Startadresse ADR1 sind die Befehle der Vermitt­ lungseinheit VE3 gespeichert. Das durch diese Befehle defi­ nierte Verfahren wird wie bereits erwähnt, unten anhand der Fig. 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 Fig. 6A). Im Teil b der Fig. 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 spezi­ fiziert wird und einen Prozeß bezeichnet, in dem der jewei­ lige Softwarebaustein ablaufen soll. In einem weiteren Feld der Verzeichniseinträge 220, 250 bzw. 270 werden Artkennzei­ chen 226, 256 bzw. 276 zum Kennzeichen des jeweiligen Soft­ warebausteins bezüglich Entwicklungstechnik und Programmier­ sprache 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 Fig. 4 nicht spezifiziert, da er gleich dem Prozeß des Aufrufers sein soll. Im Artkennzeichen 226 des Softwarebausteins 106 ist mit Hilfe eines Zahlenwer­ tes die objektorientierte Entwicklungstechnik in der Sprache C++ verschlüsselt. Das artspezifische Datum 228 definiert ei­ ne Adresse ADR5, an der der Softwarebaustein 106 im Arbeits­ speicher 20 beginnt und das artspezifische Datum 230 defi­ niert 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 ob­ jektorientierter Entwicklungstechnik erstellt wurde und sei­ nerseits mehrere Unter-Softwarebausteine enthält. Die Be­ fehlsfolgen der Unter-Softwarebausteine werden unter dem Na­ men "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-Software­ bausteins 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 Programmier­ sprache C erstellt wurde, wird das Artkennzeichen 256 so festgelegt, daß die prozedurale Programmiersprache C im kon­ kreten 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 spezifi­ ziert, 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 Fig. 4 unspezifizierten Prozeßnamen 274. Das Artkennzeichen 276 des Softwarebausteins 76 enthält einen Zahlenwert für die prozedurale Programmier­ sprache ASSEMBLER. Das artspezifische Datum 278 enthält einen Adreßwert ADR8, der auf den Beginn der Befehle des Software­ bausteins 76 verweist und das artspezifische Datum 280 ist nicht spezifiziert, da es beim Zugriff auf den Softwarebau­ stein 76 nicht notwendig ist.

Fig. 5 zeigt eine schematische Darstellung von Befehlen 300 bis 318 für den Softwarebaustein 70, welche in der prozedura­ len 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 Softwarebau­ steins 74 im Subsystem 54 ausgeführt werden. Für den C-Compi­ ler wird durch ein Rautenzeichen 320 gefolgt von dem Schlüs­ selwort "include" signalisiert, daß beim Compilieren eine weiter unten erläuterte Befehlsfolge aus Maschinenbefehlen 330 bis 340 anstelle des Befehls 308 einzufügen ist, angedeu­ tet 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 un­ ter 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 festge­ legt 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 Fig. 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 Übergabe­ speicherbereich (ÜSB), z. B. 97 gemäß Teila Fig. 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 ge­ laden. Durch den Befehl 338 wird die Adresse ADR1 in ein Re­ gister R15 des Zentralprozessors 12, 13 geladen. Das Ermit­ teln der Adresse ADR1 erfolgt dabei in zwei Schritten. An­ bieter und Nutzer einer Schnitt stelle 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 Vermittlungs­ einheit 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. So­ mit 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 Fig. 6A und 6B zeigen ein Flußdiagramm für die Verfah­ rensschritte, die beim Abarbeiten der Befehle der Vermitt­ lungseinheit 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 Fig. 4 der Software­ bausteinname 202 und gegebenenfalls ein oder mehrere Überga­ bewerte 210 festgelegt.

Im Schritt 402 wird geprüft, ob sich das zur Vermittlungsein­ heit 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 Ar­ beitsspeicher 20 veranlaßt. Im Schritt 404 wird geprüft, ob das Laden des Subsystems 54 (vgl. Fig. 2) erfolgreich war. Ist dies nicht der Fall, so wird im Schritt 404 der Fehler­ name 206 (vgl. Teil a Fig. 4) mit einem ersten Fehlerwert be­ legt. Nach dem Schritt 405 wird zu einem weiter unten erläu­ terten 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 unmit­ telbar 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 Kommunikationsver­ bindung 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 Fig. 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 aus­ geführt.

Im Schritt 410 wird geprüft, ob der durch den Softwarebau­ steinnamen 202 (vgl. Teil a Fig. 4) spezifizierte Software­ baustein im zugehörigen Subsystem 54 (vgl. Fig 2) vorhanden ist, indem die Verzeichniseinträge 222, 252 und 272 (vgl. Teil b Fig. 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 Fig. 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 Ver­ zeichniseintrag 250 (vgl. Teil b der Fig. 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 Fig. 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 glei­ chen 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 Softwarebau­ stein, z. B. 74 (vgl. Fig. 2), bereits initialisiert ist. Die Initialisierung umfaßt z. B. das Anlegen und Versorgen von Verwaltungstabellen mit konkreten Werten, welche für den ge­ rufenen Softwarebaustein spezifisch sind. Gegebenenfalls er­ folgt im Schritt 422 die Initialisierung des Softwarebau­ steins und in einem anschließenden Schritt 424 wird über­ prü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 Fig. 4) durch einen vierten Fehlerwert spezifiziert und das Verfahren im Schritt 444 fortgesetzt.

Wird im Schritt 424 festgestellt, daß die Initialisierung er­ folgreich durchgeführt wurde, so wird das Verfahren im Schritt 428 fortgesetzt. Der Schritt 428 folgt jedoch unmit­ telbar auf den Schritt 420, wenn in diesem Schritt 420 fest­ gestellt wird, daß der gerufene Softwarebaustein bereits ini­ tialisiert ist.

Im Schritt 428 wird die Art des Softwarebausteins bestimmt, indem das Artkennzeichen, z. B. 256 (vgl. Teil b Fig. 4) gele­ sen 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 geru­ fene Softwarebaustein mit der Sprache C erstellt wurde. Ist dies der Fall, so werden im Schritt 432 die im Softwarebau­ stein 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 Auf­ rufen des Softwarebausteins wird u. a. das artspezifische zweite Datum, z. B. 230 (vgl. Teil b Fig. 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 unmit­ telbar nach dem Schritt 434 der Schritt 438 ausgeführt.

Im Schritt 438 wird geprüft, ob der jeweils gerufene Soft­ warebaustein 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 ge­ rufene 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 Fig. 4) mit einem fünften Fehlerwert belegt wird. An­ schließend erfolgt das Ausführen des bereits mehrfach er­ wähnten Schrittes 444.

Das beschriebene Verfahren ist auf einfache Art und Weise auf andere als die genannten Entwicklungstechniken und Program­ miersprachen erweiterbar, indem zwischen den Schritten 438 und 442 zusätzliche Schritte eingefügt werden.

Im Schritt 444 wird das durch die Befehle der Vermittlungs­ einheit VE3 vorgegebene Verfahren für Fehlerfälle beendet. In einem der Schritte 405, 409, 412, 426 oder 442 wurde der Feh­ lername 206 (vgl. Teil a Fig. 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 Fig. 4) festgestellt, ob der Softwarebaustein erfolgreich ausgeführt werden konnte. In diesem Falle ist der Fehlername 206 (vgl. Teil a Fig. 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 Fig. 4) spezifiziert worden, die im rufenden Subsystem weiterverwendet werden können.

Claims (21)

1. Verfahren zum Betreiben einer Datenverarbeitungsanlage (10), die mindestens einen Prozessor (12, 13) enthält, der Befehle eines Programmsystems ausführt,
wobei das Programmsystem mehrere Subsysteme (50 bis 54) enthält, die vorgegebene Funktionen der Datenverarbei­ tungsanlage (10) definieren und im wesentlichen voneinan­ der unabhängig erstellbar sind,
ein Softwarebaustein (74) für mindestens eine Funktion eines ersten Subsystems (50) Bestandteil eines zweiten Subsystems (54) ist,
jedes Subsystem (50 bis 54) mindestens eine im wesentli­ chen gleichartig aufgebaute Vermittlungseinheit (60 bis 64) hat, die ein Verzeichnis (VZ1 bis VZ3) enthält, wel­ ches auf im jeweiligen Subsystem (50 bis 54) enthaltene Softwarebausteine (70 bis 76) verweist,
zum Ausführen der besagten Funktion das erste Subsystem (50) die Vermittlungseinheit (64) im zweiten Subsystem (54) aufruft (Pfeil 84) und diese Vermittlungseinheit (64) mit Hilfe des in ihr enthaltenen Verzeichnisses (VZ3) den dieser Funktion zugeordneten Softwarebaustein (74) aufruft (Pfeil 88)
und wobei nach dem Ausführen der Befehle dieses Software­ bausteins (74) zum ersten Subsystem (50) zurückgekehrt wird (Pfeil 92).

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Vermittlungseinheit (60 bis 64) einen eindeutigen Na­ men hat, der zur Auswahl und zum Aufruf der Vermittlungs­ einheit (60 bis 64) verwendet wird.

3. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß der Aufruf der Vermittlungsein­ heit (60 bis 64) unter Verwenden eines Übergabespeicher­ bereichs (97, 99) erfolgt, der an einer Startadresse (ADR0) beginnt, die vorzugsweise beim Aufruf der Ver­ mittlungseinheit (60 bis 64) an diese Vermittlungseinheit (60 bis 64) in einem vorgegebenen Register des Prozessors (12, 13) übermittelt wird.

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß der Übergabespeicherbereich (97, 99) einen allgemeinen Teil (200) enthält, welcher für jeden der Softwarebau­ steine (70 bis 76) gleichartig aufgebaut ist.

5. Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet, daß der Übergabespeicherbereich (97, 99) einen software­ baustein-spezifischen Teil (201) enthält, auf den beim Ausführen des Softwarebausteins (70 bis 76) zugegriffen wird, und auf den die Vermittlungseinheit (60 bis 64) nicht zugreift.

6. Verfahren nach Anspruch 3 bis 5, dadurch gekennzeichnet, daß der Aufbau des Übergabespeicherbereichs (97, 99) un­ abhängig von den im ersten Subsystem (50) und im zweiten Subsystem (54) verwendeten Entwicklungstechniken und Pro­ grammiersprachen ist.

7. Verfahren nach einem der Ansprüche 3 bis 6, dadurch ge­ kennzeichnet, daß an einer bezüglich der Startadresse (ADR0) fest vorgegebenen ersten Adresse (ADR0) ein Na­ mensdatum (202) gespeichert wird, das den Softwarebau­ stein (70 bis 74) nach Art eines Namens kennzeichnet.

8. Verfahren nach einem der Ansprüche 3 bis 7, dadurch ge­ kennzeichnet, daß an einer bezüglich der Startadresse (ADR0) fest vorgegebenen zweiten Adresse (ADR0+1) eine Versionsnummer (204) gespeichert wird, die die Aufteilung des Übergabespeicherbereichs (97, 98) kennzeichnet.

9. Verfahren nach einem der Ansprüche 3 bis 8, dadurch ge­ kennzeichnet, daß an einer bezüglich der Startadresse (ADR0) fest vorgegebenen dritten Adresse (ADR0+2) im Feh­ lerfalle ein Fehlerdatum (206) gespeichert wird.

10. Verfahren nach einem der Ansprüche 3 bis 9, dadurch ge­ kennzeichnet, daß an einer bezüglich der Startadresse (ADR0) fest vorgegebenen vierten Adresse (ADR0+3) ein Prozeßdatum (208) gespeichert wird, das einen prozess­ übergreifende Ausführung des Softwarebausteins (74) ge­ stattet.

11. Verfahren nach einem der Ansprüche 3 bis 10, dadurch ge­ kennzeichnet, daß im softwarebausteinspezifischen Teil beginnend an einer bezüglich der Startadresse (ADR0) fest vorgegebenen fünften Adresse (ADR0+4) mindestens ein Ein­ gabedatum (210) und/oder mindestens ein Ausgabedatum des Softwarebausteins (70 bis 76) in vorgegebener Reihenfolge gespeichert werden.

12. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß für den Softwarebaustein (70 bis 76) im Subsystemverzeichnis (VZ1 bis VZ3) ein Art­ kennzeichen (226, 256, 276) gespeichert ist, dessen Wert die zum Erstellen des Softwarebausteins (70 bis 76) ver­ wendete Entwicklungstechnik und Programmiersprache kenn­ zeichnet und daß der Zugriff auf den Softwarebaustein (70 bis 76) in einer durch die Vermittlungseinheit (60 bis 64) defi­ nierten Art abhängig vom Wert des Artkennzeichens (226, 256, 276) erfolgt.

13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, daß als Entwicklungstechnik eine prozedurale Technik einge­ setzt wird und/oder daß als Entwicklungstechnik eine objektorien­ tierte Technik eingesetzt wird.

14. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß die Vermittlungseinheit (60 bis 64) ständig in einem Arbeitsspeicher (20) der Datenverar­ beitungsanlage (10) gespeichert ist.

15. Verfahren nach einem der vorgehenden Ansprüche, dadurch gekennzeichnet, daß der Softwarebaustein (74) nur dann aufgerufen wird, wenn das zweite Subsystem (54) auf der Datenverarbeitungsanlage (10) momentan ausführbar ist (Schritt 402).

16. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß der Softwarebaustein (74) nur dann aufgerufen wird, wenn der rufende Prozeß eine Kom­ munikationsverbindung zum zweiten Subsystem (54) hat (Schritt 406).

17. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß der Softwarebaustein (74) nur dann aufgerufen wird, wenn der Softwarebaustein (74) im Verzeichnis (VZ3) der Vermittlungseinheit (64) des zwei­ ten Subsystems (54) verzeichnet ist (Schritt 410).

18. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß vor dem Aufrufen des Software­ bausteins (74) geprüft wird, ob der Softwarebaustein (74) ordnungsgemäß initialisiert ist (Schritt 420).

19. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß zumindest ein großer Teil des Programmsystems in Subsystemen (50 bis 54) mit zugehöri­ gen Vermittlungseinheiten (60 bis 64) realisiert ist.

20. Verfahren nach einem der vorhergehenden Ansprüche, da­ durch gekennzeichnet, daß die Vermittlungseinheit (60 bis 64) in einer ersten Klasse von Vermittlungseinheiten (60 bis 64) enthalten ist, wobei eine Vermittlungseinheit der ersten Klasse von allen Subsystemen (50 bis 54) aufrufbar ist,
oder daß die Vermittlungseinheit (60 bis 64) in einer zweiten Klasse von Vermittlungseinheiten (60 bis 64) ent­ halten ist, wobei eine Vermittlungseinheit (60 bis 64) der zweiten Klasse nur von einigen der Subsysteme (50 bis 54) aufrufbar ist,
oder daß die Vermittlungseinheit (60 bis 64) in einer dritten Klasse von Vermittlungseinheiten (60 bis 64) ent­ halten ist, wobei eine Vermittlungseinheit (60 bis 64) der dritten Klasse nur von ihrem zugehörigen Subsystem aus (50 bis 54) aufrufbar ist.

21. Datenverarbeitungsanlage (10) zum Ausführen eines Pro­ grammsystems, insbesondere nach einem der vorhergehenden Ansprüche,
mit mindestens einem Prozessor (12, 13), der Programmbe­ fehle des Programmsystems ausführt,
mindestens einem Speicher (20), in dem die Programmbefeh­ le gespeichert sind,
mehreren im wesentlichen unabhängig voneinander erstell­ baren Subsystemen (50 bis 54), die Bestandteile des Pro­ grammsystems sind und die vorgegebene Funktionen der Da­ tenverarbeitungsanlage (10) definieren,
im wesentlichen gleichartig aufgebauten Vermittlungsein­ heiten (60 bis 64), die jeweils einem Subsystem (50 bis 54) zugeordnet sind und auf die zum Ausführen von Funk­ tionen zugegriffen wird, die Softwarebausteine (70 bis 74, 100, 102, 106, 108)) mehrerer Subsysteme (50 bis 54) benötigen,
und mit in jeder Vermittlungseinheit (60 bis 62) enthal­ tenen Verzeichnissen (VZ1 bis VZ3), welche auf im jewei­ ligen Subsystem (50 bis 54) enthaltene Softwarebausteine (70 bis 74, 100 bis 108) verweisen, wobei der der besag­ ten Funktion zugeordnete Softwarebaustein (70 bis 74, 100 bis 108) mit Hilfe des zugeordneten Verzeichnisses (VZ1 bis VZ3) durch die jeweilige Vermittlungseinheit (60 bis 64) aufgerufen wird.