DE19810807A1

DE19810807A1 - Gerät und Verfahren zum Umsetzen von Meldungen

Info

Publication number: DE19810807A1
Application number: DE19810807A
Authority: DE
Inventors: Bengt Erik Ingemar Gard; Lars-Oerjan Kling; Sten Edvard Johnsson
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 1998-03-12
Filing date: 1998-03-12
Publication date: 1999-09-23
Also published as: JP2002507024A; WO1999046678A3; AU3033799A; CN1143208C; EP1062579B1; EP1062579A2; WO1999046678A2; US6438748B1; BR9908703A; CA2322965A1; KR20010041773A; CA2322965C; CN1300389A

Abstract

Zum Erzielen einer hochwirksamen Aktualisierung einer Software in einem computerbasierten System wird ein Meldungsumsetzungsgerät (34) vorgeschlagen, und zwar mit einer Schnittstelleneinheit (36) für Meldungsumsetzinformation (MCI) zum Beschreiben mindestens einer in einem Software-Bearbeitungssystem übertragenen Meldung vor und nach einer Aktualisierung des Software-Bearbeitungssystems. Zudem dient eine Meldungsumsetzvorrichtung (38, 40) zum Umsetzen der Meldung zwischen einer alten und neuen Darstellung für das aktualisierte Software-Bearbeitungssystem in Übereinstimmung mit den bei der Meldungsumsetzinformation (MCI) angegebenen Spezifikationen. Demnach ist es möglich, eine störungsfreie Aktualisierung von Software in computerbasierten Systemen mit minimierter Systemunterbrechungszeit zu erzielen.

Description

GEBIET DER ERFINDUNG

Die vorliegende Erfindung betrifft ein Meldungsumsetzgerät. Ferner betrifft die vorliegende Erfindung ein Software- Bearbeitungsgerät und ein Verfahren zum Umsetzen von Meldungen.

HINTERGRUND DER ERFINDUNG

Beim Durchführen der Aktualisierung von Software entsteht üblicherweise eine gewisse Störung des Betriebs bei dem zu aktualisierenden System. Diese Störung kann in dem Bereich einer vollständigen Unterbrechung des Systems während mehrerer Stunden oder möglicherweise Tagen bis zu einer kurzen Unterbrechung bei möglicherweise lediglich einen begrenzten Teil der gesamten Funktionalität des Systems während einiger Sekunden liegen. Gegebenenfalls wird keine Störung wahrgenommen, obgleich dies typischer Weise bei tatsächlich existierenden Systemen nicht der Fall ist. Jedoch ist es für Systeme wie Kommunikationsvermittlungsstationen von großer Wichtigkeit, daß jede Störung so gering und so kurz wie möglich ist.

Zum Erzielen einer störungsfreien Aktualisierung von Software selbst bei Softwaremoduln, die fortlaufend lange ausgeführt werden, besteht eine Anforderung, daß die neue Software mit den gesamten Daten von der alten Software aktualisiert wird, während die alte Software fortlaufend ausgeführt wird. Haben die Daten der neuen Software den selben Zustand wie die Daten der alten Software erreicht, so wird die neue Software in Betrieb genommen.

Das einfachste Verfahren zum Aktualisieren von Software besteht im Unterbrechen der Ausführung der alten Software, im Laden der neuen Software und schließlich im Starten der neuen Software. Bei Einsatz dieses Verfahrens werden keine Daten zwischen der alten Software und der neuen Software übertragen. Weiter gehen alle eingerichteten Softwareprozesse verloren, und die Ausführung der Software wird während dem Laden und dem Starten der neuen Software gestoppt. Üblicherweise wird dieses Verfahren beispielsweise bei Workstations und Personal-Computern benützt.

Eine verbesserte Vorgehensweise für ein Kommunikationssystem wurde beschrieben in "Fernhochstufung und Aktualisierung von AXE 10 Software", Seite 66, 67 Ericsson Review Nr. 2, 1996. Hier wird neue Software geladen, während die alte Software immer noch die Einrichtung von Diensten für Teilnehmer handhabt. Daten werden zwischen der alten Software und der neuen Software übertragen. Datenvariable mit zu übertragenden Daten werden in einer sogenannten Datenveränderungsinformation identifiziert, und sie können entweder vom Typ Kopieren oder Umsetzen sein. Für jede Umsetzdatenvariable ist in der Datenveränderungsinformation ein Umsetzprogramm spezifiziert, und es wird zum Erzielen der erforderlichen Transformation und zum Übertragen des Umsetzergebnisses an die neue Software ausgeführt. Jedoch wird während der Übertragung von Daten für bereits eingerichtete Dienste von der alten Software zu der neuen Software das Einrichten zusätzlicher Dienste gestoppt.

Demnach ergibt sich bei Durchführung einer Softwareaktualisierung immer in einem gewissen Umfang eine Störung des zu aktualisierenden Systems. Diese Störung liegt, wie oben dargestellt, zwischen einer vollständigen Unterbrechung des Systems während mehrerer Stunden oder möglicherweise Tage bis zu einer kurzen Unterbrechung von möglicherweise lediglich eines begrenzten Teils der gesamten Funktionalität des Systems, z. B. während einiger Sekunden. Jedoch ist es für bestimmte Systeme wie Telekommunikationsvermittlungen von großer Wichtigkeit, daß jede Störung so kurz wie möglich ist, da erhöhte Systemunterbrechungszeiten zu einem Verlust an Einnahmen für den Dienstanbieter führen.

Ferner sollten in Systeme mit einer großen Zahl von Softwaremoduln Meldungen eine Systemaktualisierung überstehen, obgleich dies momentan nicht unterstützt wird. Demnach führt die Unterbrechung und Beendigung von Meldungen zu einer erhöhten Störung des Systems während der Aktualisierung. Insbesondere können Dienste während einer Softwareaktualisierung abgebrochen oder gestört werden, was für bestimmte Dienste im Zusammenhang beispielsweise mit der Gesundheitsvorsorge oder mit Sicherheitsdiensten nicht zulässig ist.

ZUSAMMENFASSUNG DER ERFINDUNG

Demnach besteht die Aufgabe der vorliegenden Erfindung in der Erzielung einer wirksamen Aktualisierung von Software in computerbasierten Systemen.

Gemäß einem ersten Aspekt der Erfindung wird diese Aufgabe gelöst durch ein Meldungsumsetzgerät, enthaltend eine Schnittstellenvorrichtung für Meldungsumsetzinformation zum Beschreiben zumindest einer in dem Software- Bearbeitungssystem übertragenen Meldung vor und nach einer Aktualisierung des Software-Bearbeitungssystems, und eine Meldungsumsetzvorrichtung zum Umsetzen der Meldung in die neue Darstellung für das aktualisierte Software- Bearbeitungssystem in Übereinstimmung mit den in der Meldungsumsetzinformation angegebenen Spezifikationen.

Demnach ist es gemäß der vorliegenden Erfindung möglich, Meldungen gemäß einem aktualisierten System umzusetzen. Dies bedeutet, daß ebenfalls Meldungen und nicht nur interne Daten der Softwareeinheiten in dem System bei einer Systemaktualisierung angepaßt werden, damit die Störung des Systems reduziert und minimiert ist. Da weiterhin Meldungsveränderungsinformation über eine zugeordnete Schnittstellenvorrichtung empfangen wird, läßt sich die Funktionalität des Meldungsumsetzungsgeräts einfach gemäß den vorliegenden Anforderungen umsetzen.

Gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung wird die Meldungsumsetzvorrichtung bei einem Umschalten zu dem aktualisierten Software-Bearbeitungssystem aktiviert. Werden Meldungen bereits beim Umschalten umgesetzt, so ist die gesamte Anlaufzeit der aktualisierten Softwareeinheiten später reduziert.

Gemäß einer anderen bevorzugten Ausführungsform der vorliegenden Erfindung wird die Meldungsumsetzungsvorrichtung bei einem Start der neuen Software in dem aktualisierten Software-Bearbeitungssystem aktiviert. Diese Vorgehensweise vereinfacht das stufenweise Aktualisieren des Software- Bearbeitungssystems, da sie eine bidirektionale Kommunikation zwischen alten und neuen Softwaremodulen ermöglicht, derart, daß Meldungen auf Anforderung umgesetzt werden.

Gemäß einer anderen bevorzugten Ausführungsform der vorliegenden Erfindung setzt eine Meldungssteuerinformations- Bearbeitungsvorrichtung eine Meldungssteuerinformation mit zumindest einer Meldungsreferenz, einer Meldungsquellsoftwareeinheit, einer Meldungszielsoftwareeinheit und einer Meldungsklasse um, und eine Meldungsdaten-Bearbeitungsvorrichtung setzt zumindest ein Datenelement eines Meldungsdatenabschnitts um. Ferner führen vorzugsweise die Meldungssteuerinformations- Bearbeitungsvorrichtung und die Meldungsdaten- Bearbeitungsvorrichtung die Umsetzung der empfangenen Daten unter Einsatz funktionaler Beziehungen durch.

Werden Meldungen in einen Steuerinformationsteil und einen Datenteil unterteilt, so ist es möglich, die erforderlichen Rechenressourcen für die Meldungsumsetzung weiter zu reduzieren, da im Fall der Umsetzung der Elemente des Steuerinformationsteils lediglich sehr wenige Daten handzuhaben sind. Zudem unterstützt diese Meldungsstruktur eine einfache und wirksame Umsetzung von Datenelementen unter Einsatz funktionaler Beziehungen.

Weiterhin wird gemäß einem zweiten Aspekt der vorliegenden Erfindung die oben dargestellte Aufgabe gelöst durch ein Software-Bearbeitungssystem vom Typ mit Aktualisierungsfunktionalität, enthaltend: zumindest einen Meldungspuffer zum Speichern von Meldungen, die von einem Software-Bearbeitungssystem zu bearbeiten sind, zumindest eine Anwendungseinheit zum Bearbeiten von Meldungen, die in mindestens einem Meldungspuffer gespeichert sind, und ein Meldungsumsetzgerät zum Umsetzen von Meldungen in eine neue Darstellung nach einer Aktualisierung der zumindest einen Aktualisierungseinheit gemäß dem ersten Aspekt der vorliegenden Erfindung.

Gemäß einer anderen bevorzugten Ausführungsform der vorliegenden Erfindung ist das Software-Bearbeitungsgerät vom Typ mit mehreren Anwendungseinheiten, die jeweils mit dem Umsetzgerät verbunden sind. Alternativ ist das Software- Bearbeitungsgerät vom Typ mit mehreren Anwendungseinheiten, die mit einem einzigen Umsetzgerät verbunden sind, oder das Software-Bearbeitungsgerät enthält zwei Logikpartitionen, die mit dem Umsetzgerät verbunden sind.

Demnach ermöglicht die vorliegende Erfindung die Realisierung einer Vielzahl von Software-Bearbeitungsgeräten gemäß spezifischen Anforderungen. Dies ermöglicht insbesondere im Fall mehrerer Anwendungseinheiten in dem Software- Bearbeitungsgerät die parallele Ausführung der alten Software und der Systemaktualisierung. Zudem können in Abhängigkeit von dem Umfang der umzusetzenden Meldungen lediglich eine oder mehrere Meldungsumsetzgeräte in dem Software- Bearbeitungsgerät vorgesehen sein.

Schließlich wird gemäß einem dritten Aspekt der vorliegenden Erfindung die oben dargestellte Aufgabe gelöst durch ein Systemaktualisierungsverfahren für ein Rechnungssystem mit zumindest zwei Partitionen, enthaltend die Schritte Aktualisierung eines Zustands einer neuen Software in einer Standby/Bereitschafts-Partitionsvorrichtung gemäß dem Zustand einer alten Software in einer Betriebspartitionsvorrichtung bei Fortführung der Ausführung der alten Software, Umschalten zu der Ausführung der neuen Software, soweit derselbe Zustand bei der Standby-Partitionsvorrichtung und der Betriebs- Partitionsvorrichtung erzielt ist, und Umsetzen von Meldungen, die zwischen unterschiedlichen Softwaremoduln in dem Rechensystem übertragen werden, in ein Format, das sich für die empfangende Software eignet, und zwar entweder beim Umschalten zu der Ausführung der empfangenden Software oder auf Anforderung beim Start der empfangenden Software.

Hierbei werden nicht nur die alte Software und die hiermit im Zusammenhang stehenden Daten aktualisiert, sondern auch Meldungen, die zwischen diesen Softwareeinheiten vermittelt werden. Sämtliche Schritte werden durchgeführt, während das System den Betrieb der alten Software parallel und mit minimierter Störung der Systemleistung fortsetzt.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Bevorzugte Ausführungsformen der vorliegenden Erfindung werden unter Bezug auf die beiliegende Zeichnung beschrieben; es zeigen:

Fig. 1 eine Darstellung von Softwareeinheiten auf einer Maschinenebene gemäß der vorliegenden Erfindung;

Fig. 2 die Spezifikation von Meldungsklassen gemäß der vorliegenden Erfindung;

Fig. 3 die Darstellung von Meldungen auf einer Maschinenebene gemäß der vorliegenden Erfindung;

Fig. 4 die Spezifikation des Systembetriebs auf einer funktionalen Ebene;

Fig. 5 die Abbildung der Systemspezifikation auf einer funktionalen Ebene gemäß Fig. 4 auf eine existierende Systemarchitektur;

Fig. 6 die Modifikation von Meldungsdaten bei der Aktualisierung einer Systemspezifikation gemäß der vorliegenden Erfindung;

Fig. 7 die Modifikation von Meldungsdaten aufgrund der Aktualisierung der Systemspezifikation gemäß der vorliegenden Erfindung;

Fig. 8 ein Blockschaltbild einer Meldungsumsetzeinheit gemäß der vorliegenden Erfindung;

Fig. 9 eine Tabellenspeichereinheit für die bei der Meldungsumsetzung einbezogene Meldungssteuerinformation;

Fig. 10 eine Tabelle zum Zusammenfassen der unterschiedlichen Fälle der Meldungsumsetzung gemäß der vorliegenden Erfindung;

Fig. 11 ein Blockschaltbild der Meldungssteuerinformations- Bearbeitungseinheit gemäß der vorliegenden Erfindung;

Fig. 12 die Anwendung der Meldungsumsetzeinheit auf unterschiedliche Systemanwendungseinheiten in fester Zuordnung gemäß der vorliegenden Erfindung;

Fig. 13 die Anwendung der Meldungsumsetzeinheit gemäß der vorliegenden Erfindung auf mehrere Anwendungseinheiten eines Systems in verteilter Weise;

Fig. 14 die Anwendung der Meldungsumsetzeinheit gemäß der vorliegenden Erfindung auf ein System mit redundanter Struktur mit zwei Betriebspartitionen;

Fig. 15 ein Flußdiagramm gemäß dem erfindungsgemäßen Verfahren für die Umsetzung von Daten und Meldungen während der Aktualisierung eines Systems gemäß der vorliegenden Erfindung;

Fig. 16 die Struktur einer mit einem Meldungspuffer verbundenen Zentralprozessoreinheit einer Vermittlung eines Kommunikationssystems als typisches Beispiel für die Anwendung der vorliegenden Erfindung;

Fig. 17 die Implementierung eines Fernnetzes bzw. WAN- Netzwerkes als weiteres typisches Beispiel für die Anwendung der vorliegenden Erfindung.

BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN

Nachfolgend werden bevorzugte Ausführungsformen der vorliegenden Erfindung unter Bezug auf die oben beschriebene Zeichnung und die nachfolgend angegebene Terminologie beschrieben:
SU Softwareeinheit
MCI Meldungsumsetzungsinformation; eine durch den Entwerfer bereitgestellte Spezifikation zum Spezifizieren, wie in einer oder mehrerer alten Softwareeinheiten SU empfangenen Meldungen im Zusammenhang mit Meldungen stehen, die in einer oder mehreren neuen Softwareeinheiten empfangen werden, einschließlich der übermittelten Daten
SUID Softwareeinheitsidentität, die vom Entwerfer zum Spezifizieren einer bestimmten Softwareeinheit benützt wird
SU_Reference Eine Maschinenebenendarstellung von SUID
MESSAGEx Eine eindeutige Identität zum Spezifizieren einer bestimmten Meldungsklasse x; MESSAGEx könnte global eindeutig sein (beispielsweise mit einem Namensplan für Meldungen, die für sämtliche SUs gemeinsam ist (oder lokal) (eindeutige Namen innerhalb der Softwareeinheiten SU). Im letzteren Fall muß eine eindeutige vollständige Spezifikation einer Meldungsklasse sowohl eine SUID als auch eine MESSAGEx enthalten
message_ref Maschinenebenendarstellung von MESSAGEx, beispielsweise eine Zahl oder eine Maschinenebenenadresse, die global sein kann (beispielsweise eine Numerierung von Meldungen, die für alle SU-Einheiten einheitlich ist) oder lokal (beispielsweise ein Numerierung pro Softwareeinheit SU). Im letzteren Fall könnte eine Meldung einer bestimmten Meldungsklasse in dem Meldungspuffer als target_SU_reference. target_message_reference.source_SU_ reference.source_message_reference. data_1.data_2. . . . gespeichert sein.
Nachfolgend wird davon ausgegangen, daß Meldungen pro Softwareeinheit SU eindeutig sind, und zwar sowohl in der abstrakten als auch in der Maschinenebenendarstellung
DATAm Datenzahl m; eingesetzt mit MESSAGEx zum Spezifizieren von Datennummern m, die mittels MESSAGEx übermittelt werden
data_m Maschinenebenendarstellung von DATAm.

Gemäß der vorliegenden Erfindung wird jede Softwareeinheit SU durch eine Softwareeinheit-Identifizierung SUID identifiziert, die beispielsweise aus einer Folge von Buchstaben und Zahlen besteht. Wie in Fig. 1 gezeigt, sind typische Beispiele für eine SUID-Angabe Prog_a, Prog_b und Prog_c. Wie in Fig. 1 gezeigt, erfolgt während des tatsächlichen Systembetriebs ein Bezug auf eine Darstellung der Softwareeinheiten auf Maschinenebene mit SU_Reference, beispielsweise als Programm- oder Modulzahl oder Adresse für den Zugriff auf einen Speicher, der die Softwareeinheit auf Maschinenebene speichert.

Wie in Fig. 2 gezeigt, ist für die Spezifikation eines Systembetriebs nicht nur der Bezug auf die Softwareeinheiten SU erforderlich, sondern auch ein Bezug auf Meldungen MESSAGEx, die zwischen unterschiedlichen Softwareeinheiten während des Systembetriebs vermittelt werden. Hier spezifiziert MESSAGEx eine bestimmte Meldungsklasse. Wie in Fig. 2 gezeigt, ist jede Meldungsklasse in einen Steuerinformationsteil und einen Datenteil unterteilt, derart, daß DATAm zusammen mit MESSAGEx zum Spezifizieren der durch MESSAGEx geführten Zahl von Daten eingesetzt wird. Entsprechend wird die Steuerinformation zum Spezifizieren eines durch MESSAGEx geführten Steuerinformationsteils eingesetzt. Der Steuerinformationsteil kann in Unterteile aufgeteilt sein, beispielsweise einen Headerteil und einen Ergänzungs- bzw. Trailerteil.

Fig. 3 zeigt eine Darstellung unterschiedlicher Meldungen auf einer Maschinenebene, die unterschiedlichen in Fig. 2 gezeigten Meldungsklassen zuzuordnen sind. Hier kann jeder Steuerinformationsteil für eine Meldung z. B. aus einer Meldungsreferenz einer Angabe der Quelle der Meldung und einer Angabe des Ziels der Meldung bestehen. Er kann auch weitere Information zum Steuern und Gewährleisten des Meldungsflusses enthalten, z. B. Sequenznummern, eine Prüfsumme usw.

Schließlich folgen Datenelemente, die einer bestimmten Meldung zugeordnet sind, als Folge der einzelnen Datenelemente. Somit ermöglicht eine Darstellung von Meldungen nach der Fig. 3 einen Zugriff auf die gesamte für eine bestimmte Meldung relevante Information.

Die Fig. 4 zeigt den Einsatz der Darstellung der Softwareeinheiten und Meldungen, die in Fig. 1 und 3 gezeigt sind, für die Beschreibung des Systembetriebs auf einer funktionalen Ebene mit Hilfe eines gerichteten Graphens. Wie in Fig. 4 gezeigt, ist jedem Knoten eine Softwareeinheitidentifizierung SUID oder in äquivalenter Weise eine Maschinenebenenreferenz SU_Reference zugeordnet. Die jeweilige Wahl hängt von der Tatsache ab, ob der Systembetrieb auf einer abstrakten Ebene oder auf einer Maschinenebene beschrieben wird. Wie oben beschrieben, interagieren die unterschiedlichen Softwareeinheiten, die im Graphen als Knoten dargestellt sind, miteinander durch den Austausch von Meldungen, die in der Darstellung durch gerichtete Kanten modelliert sind. Wie in der Fig. 4 gezeigt, ist jeder Kante in dem Graphen eine message_reference (bzw. meldungs_referenz) zugeordnet. Demnach wird die Meldung 1 zwischen der Quellsoftwareeinheit Prog_a und der Zielsoftwarteeinheit Prog_b ausgetauscht. Ferner wird die Meldung 2 zwischen der Quellsoftwareeinheit Prog_a und der Zielsoftwareeinheit Prog_c ausgetauscht, usw.

Während die Fig. 4 die Erläuterung des Systembetriebs auf einer funktionalen Ebene zeigt, entspricht die Fig. 5 der Beschreibung auf einer strukturellen Ebene.

Wie in Fig. 5 gezeigt, unterteilt sich ein System üblicherweise in mehrere Systemkomponenten 10, 12, 14. Jede Systemkomponente enthält eine Anwendungseinheit 16, 18, 20, die die Ausführung der Softwareeinheiten ermöglicht. Wie in Fig. 5 gezeigt, ist die Softwareeinheit Prog_a mit SU_ref = 1 der Anwendungseinheit 1 zugeordnet, die Softwareeinheit Prog_c, d mit SU_ref = 3, 4 ist der Anwendungseinheit 18 zugeordnet, und eine Softwareeinheit Prog_b mit SU_ref = 2 ist der Anwendungseinheit 20 zugeordnet.

Zum Implementieren des Austausches von Meldungen enthält jede Systemkomponente 10, 12, 14 auch einen Meldungspuffer 22, 24, 26, in dem Meldungen gespeichert sind, bevor sie jeweils in der zugeordneten Anwendungseinheit 16, 18, 20 bearbeitet werden. Für den tatsächlichen Austausch von Meldungen zwischen dem Systemkomponenten 10, 12, 14 sind Verbindungen 28, 30, 32 zum Verbinden der unterschiedlichen Systemkomponenten vorgesehen.

Wie in Fig. 5 gezeigt, übermitteln diese Verbindungen die unterschiedlichen und in Fig. 4 als Kanten eines gerichteten Graphen dargestellten Meldungen entlang der angezeigten Richtungen. Es ist zu erkennen, daß Fig. 4 lediglich ein Beispiel für die Abbildung einer Systemspezifikation auf einer funktionalen Ebene auf eine existierende Hardwarestruktur darstellt und daß Modifikationen und Veränderungen in Abhängigkeit von tatsächlichen Anforderungen und anderen Systemkonfigurationen innerhalb des Umfangs der vorliegenden Erfindung liegen.

Wie oben dargelegt, werden während der Systemaktualisierung die Softwareeinheiten unterschiedlicher Anwendungseinheiten zusammen mit Daten gemäß dem momentanen internen Status der eingesetzten Softwareeinheiten aktualisiert. Wie in Fig. 5 gezeigt, verbleibt jedoch unabhängig von dem Wirkungsgrad dieser Aktualisierung der Softwareeinheiten die Aufgabe, die Meldungen in den unterschiedlichen Meldungspuffern 22, 24, 26 zu berücksichtigen, die vor der Aktualisierung in Übereinstimmung mit der Systemspezifikation gespeichert wurden.

Demnach besteht ein wichtiger Aspekt der vorliegenden Erfindung in der Bereitstellung einer wirksamen Vorgehensweise auch für die Aktualisierung dieser Meldungen zusätzlich zu der Aktualisierung von Software und zugeordneten internen Daten. Wie im folgenden gezeigt, ermöglicht dies eine insgesamt reduzierte Gesamtsystemunterbrechung während dem Aktualisierungsprozeß und eine erhöhte Systemverfügbarkeit und -sicherheit.

Die Fig. 6 zeigt den Einfluß der Systemaktualisierung auf die Darstellung von Meldungen auf der Maschinenebene. Insbesondere zeigt die linke Seite der Fig. 6 die funktionale Darstellung des Systembetriebs und die zugehörige Maschinenebenen-Darstellung von Meldungen vor einer Aktualisierung, während die rechte Seite der Fig. 6 den Einfluß des Aktualisierungsprozesses hierauf darstellt.

Wie in Fig. 6 gezeigt, kann die Umsetzung von Meldungen entweder aufgrund einer Veränderung des Sourcecodes einer sendenden Softwareeinheit oder des Sourcecodes einer empfangenden Softwareeinheit zurückzuführen sein.

Ein erstes Beispiel für die Veränderung einer Softwareeinheit wäre die Zuordnung einer neuen Meldungsklasse zu einer Meldung, z. B. aufgrund einer Protokollveränderung. Das nächste Beispiel gemäß der zweiten Linie der in Fig. 6 gezeigten Tabelle betrifft die Veränderung der Zielsoftwareeinheit. Hier ist die Kante mit der message_reference (bzw. meldungs_referenz) 2, die ursprünglich von dem oberen linken Knoten zu dem unteren linken Knoten gerichtet ist, neu ausgerichtet, und zwar ausgehend von dem oberen linken Knoten zu dem oberen rechten Knoten. Wie sich anhand der zugeordneten Maschinenebenendarstellung zeigt, insbesondere anhand der dritten Spalte der zweiten Zeile, wird der zugeordnete Eintrag des Steuerinformationsteils von 3 zu 2 geändert. Wie in Fig. 6 gezeigt, werden Meldungen auch unverändert übernommen, gemäß der dritten und vierten Zeile der in Fig. 6 gezeigten Tabellen.

Die nächste Art von Meldungsumsetzungen aufgrund von Systemaktualisierung betrifft eine Veränderung des Zielcodes (übersetzter Sourcecode) einer Softwareeinheit gemäß der fünften Zeile der in Fig. 6 gezeigten Tabellen.

Ein typisches Beispiel besteht darin, daß die Meldung dieselbe Identität aufweist und durch dieselbe Softwareeinheit nach der Systemaktualisierung empfangen wird, jedoch eine andere meldungs_reference und/oder Referenzen für Quell/Ziel-Softwareeinheit. Demnach wird bei Veränderung des unteren Knotens von SU_Ref = 4 zu SU_Ref = 10 ein zugeordneter Eintrag in der zweiten Spalte der Zeile 5 von 4 zu 10 geändert. Zudem wird bei einer Veränderung der Referenz auf die Meldung zu 9 entsprechend der erste Eintrag von 8 zu 9 geändert.

Es ist zu erkennen, daß gemäß der vorliegenden Erfindung die für die Umsetzung von Meldungen erforderliche Information, die soeben beispielhaft erläutert wurde, in Form von einer Meldungsumsetzinformation zusammengefaßt wird, die entweder durch den Entwickler bereitgestellt wird, der für die Aktualisierung des Systems verantwortlich ist, und zwar im Fall der Veränderung des Quellcodes von Softwareeinheiten, oder die sogar automatisch durch Entwurfswerkzeuge bereitgestellt wird, falls Veränderungen des Zielcodes von Softwareeinheiten vorgenommen werden. Zudem sind bei der Umsetzung von Meldungen die empfangenen Meldungen besonders zu berücksichtigen, da lediglich dann eine Umsetzung vor der weiteren Bearbeitung erforderlich ist.

Wie in Fig. 7 gezeigt, betrifft eine Umsetzung von Meldungen nicht nur die Umsetzung der Steuerinformation, sondern auch die Umsetzung zugeordneter Datenelemente.

Die Beziehung zwischen den alten und neuen Datenelementen wird erfindungsgemäß unter Einsatz einer funktionellen Beziehung als expr ( ) ausgedrückt, die einen Teil der Systemspezifikation für die Aktualisierung darstellt und beispielsweise über das Entwurfssystem für die Systemaktualisierung verfügbar ist.

Zudem erfordert eine Abbildung alter Datenelemente auf neue Datenelemente keine Eins-zu-Eins-Beziehung zwischen alten Datenelementen und neuen Datenelementen, sondern alte Datenelemente können weggelassen werden oder neue Datenelement können hinzugefügt werden. Weitere Optionen bestehen in der Umkehr der Abfolge der Datenelemente und im Verändern der Datentypen, die für die unterschiedlichen Datenelemente eingesetzt werden.

All die unterschiedlichen Schritte, die oben unter Bezug auf ein bestimmtes Beispiel erläutert wurden, werden im allgemeinen in einem in Fig. 8 gezeigen Meldungsumsetzgerät 34 durchgeführt. Dieses Meldungsumsetzgerät 34 enthält eine Meldungsumsetzinformations-Schnittstelleneinheit 36 und eine Meldungsumsetzeinheit. Die Meldungsumsetzeinheit unterteilt sich in eine Meldungssteuerinformations-Bearbeitungseinheit 38 und eine Meldungsdaten-Bearbeitungseinheit 40.

Wie in Fig. 8 gezeigt, empfängt die Meldungsumsetzinformations-Schnittstelleneinheit 36 Meldungsumsetzinformation MCI (message conversion information) zum Beschreiben zumindest einer Meldungsumsetzung, die aufgrund einer Aktualisierung des Software-Bearbeitungssystems erforderlich ist. Zudem werden Meldungen in Form der Maschinenebenendarstellung vor der Aktualierung des Systems sowohl der Meldungssteuerinformation-Bearbeitungseinheit 38 als auch der Meldungsdaten-Bearbeitungseinheit 40 zugeführt. Wie nachfolgend detaillierter dargestellt, kann eine Aktualisierung des Systems auch zu der Einfügung und Generierung neuer Meldungen führen, so daß die Gesamtausgabe des Meldungsumsetzungsgeräts 34 nicht nur aus umgesetzten Meldungen, sondern auch aus neu initialisierten Meldungen besteht, wie in Fig. 8 gezeigt.

Die Meldungssteuerinformations-Bearbeitungseinheit 38 setzt die Meldungssteuerinformation, wie oben beschrieben, um. Demnach modifiziert sie zum Beispiel eine meldungs_referenz, eine Quellsoftwareeinheit einer Meldung, eine Zielsoftwareeinheit einer Meldung und eine Meldungsklasse. Zudem setzt die Meldungsdaten-Bearbeitungseinheit 40 zumindest ein umzusetzendes Datenelement eines Meldungsdatenabschnitts um.

Für die Aktivierung der Meldungsumsetzeinheit 34 besteht eine Option darin, den Zeitpunkt des Umschaltens zu der aktualisierten Software zu wählen. Wird dann später eine entsprechende Softwareeinheit in dem aktualisierten System gestartet, so geht keine Zeit verloren, da die Meldungen bereits umgesetzt sind. Zudem besteht eine weitere Option in der Aktivierung des Meldungsumsetzgerätes 34 gemäß der vorliegenden Erfindung darin, diese lediglich auf Anforderung im Startzeitpunkt der empfangenden oder Zielsoftwareeinheiten durchzuführen, so daß die Meldungsumsetzung lediglich bei Bedarf durchgeführt wird, d. h., wenn die Meldung an die empfangende Softwareeinheit abzugeben ist.

Gemäß der vorliegenden Erfindung wird der Gesamtablauf der Umsetzung für unterschiedliche Meldungen beispielsweise unter Einsatz von Umsetzungsinformation auf einer Maschinenebenendarstellung durchgeführt, wie im folgenden dargestellt. Eine mögliche Implementierung gemäß der vorliegenden Erfindung kann auf einer Tabelle zum Speichern desjenigen Teils der Meldungssteuerinformation beruhen, die umzusetzende Meldungen betrifft, und die den Meldungstyp, die SU-Referenz oder die meldungs_referenz identifiziert, zusammen mit Informationen im Zusammenhang mit alten und neuen Softwareeinheiten. Eine solche Tabelle kann zum Übersetzen des Meldungssteuerinformationsteils gemäß Meldungen eingesetzt werden, die von alten Softwareeinheiten zu neuen Softwareeinheiten oder umgekehrt übertragen werden, und folgendermaßen aufgebaut sein:

Gemäß der vorliegenden Erfindung werden die Inhalte dieser Tabelle entweder durch den Entwerfer des Systems oder automatisch durch eine Compiler- und Linker-Funktionalität zum Verarbeiten von Information auf einer höheren Abstraktionsebene spezifiziert. Weiterhin müssen gemäß der vorliegenden Erfindung Einträge in der Tabelle lediglich in einem Fall vorliegen, in dem eine Umsetzung bei einer Systemaktualisierung tatsächlich erforderlich ist.

Hier ist zu erwähnen, daß die beiden Spalten in der Tabelle so identifiziert werden können, daß sie die linke und rechte Seite einer Gleichung gemäß

L.H.S. (new) = R.H.S(old) (1)

darstellen. Im folgenden ist das Zeichen "=" als "ist äquivalent zu" oder "entspricht" zu interpretieren.

Demnach entspricht gemäß der vorliegenden Erfindung eine Zuweisung L.H.S. = R.H.S. im Hinblick auf eine Zeile der Tabelle einer Maschinenebenendarstellung eines Umsetzungsfalls.

Üblicherweise wird im Fall einer schrittweisen Softwareaktualisierung eine Liste von aktualisierten und noch nicht aktualisierten Softwareeinheiten SU unterhalten, um für jede Meldung zu bestimmen, ob eine Umsetzung von einem alten zu einem neuen Format oder von einem neuen zu einem alten Format erforderlich ist oder nicht.

Ohne Eingrenzung des Schutzbereichs der Erfindung wird davon ausgegangen, daß die gleiche Kombination "SU_reference.message reference" nicht sowohl auf der neuen als auch auf der alten Seite auftreten kann. Der Grund hierfür besteht darin, daß für jede ggf. umzusetzende Meldung lediglich ein einziger Eintrag in der Tabelle vorliegen sollte, insbesondere wenn alte und neue Softwareeinheiten gleichzeitig ausgeführt werden. Ferner ist es möglich, eine "Version" als zusätzliche Information der Meldungsumsetzung hinzuzufügen. Diese Ergänzung ist in dem Fall nicht erforderlich, bei dem ein Umschalten zu neuen Softwareeinheiten während der Softwareaktualisierung in einem einzigen Schritt durchgeführt wird, da die Umsetzung von Meldungen in diesem Fall lediglich in eine Richtung durchgeführt wird, d. h. von alt zu neu.

Ein typisches Beispiel für eine Umsetzaufgabe besteht darin, daß eine Meldung von einer alten Softwareeinheit für eine neue Softwareeinheit vorliegt, derart, daß die Meldung in den Meldungspuffer als Ergebnis eines Absendens einer Meldung von einer noch nicht aktualisierten Softwareeinheit in dem Meldungspuffer gespeichert wurde, und die empfangende Softwareeinheit bei Meldungsabgabe bereits aktualisiert ist. Ferner könnte eine Meldung ausgehend von einer neuen Softwareeinheit zu einer alten Softwareeinheit vorliegen. In diesem Fall wurde die Meldung in dem Meldungspuffer als Ergebnis eines Absendens einer Meldung von einer bereits aktualisierten Softwareeinheit zu der empfangenen, im Zeitpunkt der Meldungsabgabe noch nicht aktualisierten Softwareeinheit gespeichert. Gemäß der vorliegenden Erfindung wird beispielsweise bei einem Jobstart die Meldung in dem Meldungspuffer untersucht. Existiert ein Abgleich zwischen der Steuerinformation der Meldung und den Inhalten eines Eintrags in der oben dargestellten Tabelle, d. h. auf der geeigneten Seite in Abhängigkeit von der Tatsache, ob die gepufferte Meldung vom neuen oder alten Format ist, so bedeutet dies, daß die Meldung möglicherweise umzusetzen ist.

In einem solchen Fall wird gemäß der vorliegenden Erfindung die Größe target_SU_reference bestimmt, und anschließend wird geprüft, ob diese Softwareeinheit aktualisiert und neu oder noch nicht aktualisiert und alt ist. Das Ergebnis dieser Abfrage bestimmt, ob bei Abgabe der Meldung an die empfangende oder Zielsoftwareeinheit das Format in Übereinstimmung mit der oben dargestellten Tabelle das neue oder alte Format sein sollte.

Ferner wird bei Bestimmung von source_SU_reference bestimmt, ob die zugeordnete Softwareeinheit vom selben Typ wie die Zielsoftwareeinheit ist, d. h. vom neuen oder alten Typ. In einem solchen Fall wäre keine Umsetzung erforderlich. Weisen jedoch die Quell- und Zielsoftwareeinheit einen unterschiedlichen Typ auf, so sollte die hierzwischen ausgetauschte Meldung umgesetzt werden. Hierbei hängt die Richtung der Umsetzung, d. h. von neu zu alt oder alt zu neu, von der Tatsache ab, welcher der Softwareeinheiten alt und welche neu ist.

Die Fig. 9 stellt die oben dargestellten allgemeinen Prinzipien unter Einsatz des in Fig. 6 gezeigten Beispiels dar, bei dem die Meldung mit message_reference 2 von der ursprünglichen Zielsoftwareeinheit 3 zu der neuen Zielsoftwareeinheit 2 neu ausgerichtet wurde. Unter der Annahme, daß die weitere, umsetzungsbezogene Steuerinformation unverändert ist, ergeben sich die Einträge in der Tabelle zum Darstellen dieser Meldungssteuerinformation, wie in Fig. 9 gezeigt. Deshalb würde in dem Fall, in dem die Meldung entweder vor oder nach einer Aktualisierung des Softwarebearbeitungssystems gehandhabt würde, der betreffende Eintrag entweder auf der linken oder rechten Seite dieser Tabelle gefunden, und anschließend würde er zum Ausführen der bestimmten Meldungsumsetzung eingesetzt werden, d. h. der Änderung von target_SU_reference in diesem bestimmten Fall.

Ferner lassen sich die unterschiedlichen Situationen, bei denen eine Umsetzung zwischen alten und neuen Quell- und Zielsoftwareeinheiten - wie oben diskutiert - erfolgt, wie in Fig. 10 gezeigt, zusammenfassen. Hierbei ist zu erkennen, daß keine Umsetzung erforderlich ist, wenn sowohl die Quell- als auch die Zielsoftwareeinheit denselben Typ alt oder neu aufweisen. Andernfalls erfolgt eine Meldungsumsetzung im oben dargelegten Sinne.

Ferner besteht eine Option gemäß der vorliegenden Erfindung, die aus Fig. 10 ableitbar ist, zum Durchführen der oben erläuterten Schritte beim Umschalten, woraufhin es nur noch möglich ist, eine Umsetzung, ausgehend von dem alten Format zu dem neuen Format, durchzuführen. Hierbei führt die neu eingekoppelte Software keine Bearbeitung von Meldungen gemäß dem alten Format durch. Demnach sollte im Fall des Einkoppelns der gesamten neuen Softwareeinheiten im selben Zeitpunkt keine Umsetzung, ausgehend von dem neuen zu dem alten Format, üblicherweise erforderlich sein, da keine Softwareeinheiten zurückbleiben, die Meldungen gemäß dem alten Format bearbeiten. In einem solchen Fall ist es möglich, sämtliche Meldungen in den Meldungspuffern in einer Folge umzusetzen.

Ferner wird diese Vorgehensweise auch mit sog. Mehrfachzeichen bzw. wild cards eingesetzt, und zwar für den Abgleich zwischen Meldungen in den Meldungspuffer und der Umsetztabelle. Beispielsweise ist an der Unterseite der Tabelle angegeben, daß "target_SU_reference7.target_message_reference7" immer "target_SU_reference8.target_message_reference8" entspricht, und daß "source_SU_reference9.source_message_reference9" immer "source_SU_reference10.source_message_reference10" entspricht, unabhängig von der anderen Information, die dann unverändert bleibt. Dieses Prinzip zum Beschreiben von Umsetzungen läßt sich auf jede Information verallgemeinern, die einen Teil der Meldung darstellt.

Komplexere Umsetzungen, beispielsweise unter Miteinbeziehung arithmetischer und logischer Ausdrücke, sollten vorzugsweise nicht in der Tabelle gespeichert werden. Anstelle hiervon kann die Tabelle durch eine Referenz auf irgendeine andere Information ergänzt werden, beispielsweise ein Umsetzprogramm zum Beschreiben der komplexen Umsetzung.

Nachfolgend wird die abstrakte Darstellung der Meldungsformate erläutert. Bei der abstrakten Darstellung auf einem hohen Niveau sind Unterschiede bei den Formaten und den Inhalten in einer Weise spezifiziert, die zu der Art ähnlich ist, wie Meldungen in dem Quellcode der Anwendungsprogramme der Anwendungssoftwareeinheiten zum Bearbeiten der Meldungen spezifiziert sind.

Ein Beispiel gemäß der vorliegenden Erfindung besteht darin, daß eine Meldung durch eine eindeutige Identität spezifiziert ist, beispielsweise die Meldungsnamen in dem Fall, in dem der Name über das gesamte System hinweg eindeutig ist, oder eine Kombination von Meldungsnamen und einem Namen der Softwareeinheit zum Bearbeiten derselben. Nachfolgend wird ohne irgendeine Einschränkung davon ausgegangen, daß eine eindeutige Identität zum Spezifizieren einer Meldung gegeben ist durch

SUID.MESSAGEx (2).

Hier ist SUID eine eindeutige Identität eines Programms und MESSAGEx eine lokal eindeutige (innerhalb des Programms) Identität einer Meldung, die durch das Programm gehandhabt wird. SUID und MESSAGEx bestehen typischerweise, jedoch nicht notwendigerweise, aus einer Zeichenkette.

Gemäß der vorliegenden Erfindung übersetzt eine Compiler- und Linker-Funktion diese Darstellung, die z. B. aus Zeichenketten besteht, in eine Darstellung, die für eine Bearbeitung durch die Umsetzfunktion in dem Zielsystem besser geeignet ist. Typischerweise kann SUID in eine eindeutige Programmnummer oder eine andere geeignete Adresse übersetzt werden. Entsprechend kann ein Meldungsname MESSAGEx in eine Meldungsnummer oder eine maschinenabhängige Adresse übersetzt werden.

Hierbei werden diese Maschinenebenen-Darstellungen bezeichnet als

SU_reference

und

message_reference.

Es ist zu erkennen, daß der Compiler und der Linker in einigen Fällen auch Information erzeugen können, die nicht explizit in der abstrakten Darstellung anzugeben sind. Beispielsweise in dem Fall, in dem eine Meldung immer durch ein spezifisches Programm gesendet und durch ein anderes spezifisches Programm empfangen wird, ist die Information auf hoher Ebene

Target_SUID.MESSAGEx (3a)

zum Erzeugen der vollständigen Information auf niedriger Ebene

target_SU_reference.target_message_reference.
source_SU_reference.source_message_reference (3b)

ausreichend. Demnach kann in einem solchen Fall eine Anweisung auf hoher Abstraktionsebene

New_Target_SUID.MESSAGEx = Old_Target_SUID.MESSAGEy (4a)

zur Erzeugung der vollständigen Maschinenebenendarstellung führen:

new_target_SU_reference.new_target_message_reference. new_source_SU_reference.new_source_message_reference= old_target_SU_reference.old_target_message_reference. old_source_SU_reference.old_source_message_reference (4b).

Demnach ist es gemäß der vorliegenden Erfindung möglich, Meldungen auch in Fällen durchzuführen, in denen Veränderungen des Systems oder der jeweiligen Softwareeinheiten zu Veränderungen der Softwarereferenzen und Meldungsreferenzen führen, d. h. durch Hinzufügen einer neuen Softwareeinheit in dem System oder einer neuen Meldung in einem Programm, wodurch sich die Numerierung auf Maschinenebene entweder der Softwareeinheiten oder der Meldungen ändert. Hierbei sind derartige Veränderungen nicht explizit durch den Entwerfer anhand einer Beschreibung auf hoher Abstraktionsebene darzustellen, da die Compiler- und Linker-Funktion die erforderliche Information sowieso erzeugt.

Ferner besteht bei Übereinstimmung der Identitäten MESSAGEx und MESSAGEy kein Unterschied auf Source-Code-Ebene im Hinblick auf diese Meldungsklasse aus Sicht des Source-Codes der zugeordneten Softwareeinheiten. Demnach kann die Compiler- und Linker-Funktion jede erforderliche Maschinenebeneninformation erzeugen, und zwar ohne explizite Information auf hoher Abstraktionsebene mit Ausnahme der Identitäten der Software ID SUID der neuen und alten Softwareeinheiten. Hierbei besteht gemäß der vorliegenden Erfindung eine Vorgabe darin, daß im Hinblick auf eine Darstellung auf hoher Abstraktionsebene nicht zu verändernde Meldungen nicht durch den Entwerfer zu beschreiben sind, und daß die Compiler- und Linker-Funktion in derartigen Fällen jedwede Änderungen der Darstellung auf Maschinenebene handhaben.

Wie in Fig. 11 gezeigt, resultiert hieraus, daß die Meldungssteuerinformations-Bearbeitungseinheit 38 des in Fig. 8 gezeigten Meldungsumsetzungsgeräts 34 im wesentlichen in drei Funktionseinheiten unterteilt ist. Die erste Einheit ist eine Tabellenspeichereinheit 32 zum Speichern der umsetzrelevanten Teile der Meldungssteuerinformation unterschiedlicher Meldungen. Zweitens ist eine Informationszugriffseinheit 44 vorgesehen, die den Zugriff auf die Tabellenspeichereinheit 42 in Übereinstimmung mit einer speziellen Information ermöglicht, die im Zusammenhang mit einer Meldung bereitgestellt ist, beispielsweise einer Meldungsreferenz gemäß dem alten und neuen Format. Drittens implementiert eine Umsetzhandhabungseinheit 46 die unterschiedlichen Arten der in Fig. 10 gezeigten Umsetzungen gemäß der in der Tabellenspeichereinheit 42 gespeicherten und durch die Informationszugriffseinheit 44 bereitgestellten Information.

Nachfolgend werden typische Beispiele derartiger Meldungsumsetzungen, die durch die unterschiedlichen Einheiten in der Meldungsumsetzeinheit 34 durchgeführt werden, erläutert. In den nachfolgenden Beispielen wird davon ausgegangen, daß die Aktualisierungsprozedur so verläuft, daß lediglich Umsetzungen, ausgehend von dem alten zu dem neuen Format, durchgeführt werden, d. h. daß keine gleichzeitige Ausführung alter und neuer Softwarebearbeitungseinheiten erfolgt, die den Austausch umzusetzender Meldungen erfordern.

Jedoch ist zu erkennen, daß es gemäß der vorliegenden Erfindung eindeutig möglich ist, auch die Richtung, ausgehend von dem neuen zu dem alten Format, unter Einsatz der oben dargelegten Prinzipien abzudecken. Ferner wird im folgenden davon ausgegangen, daß die Maschinenebenen- Meldungssteuerinformation folgende Teile enthält.

target_SU_reference.target_message_reference. source_SU_reference.source_message_reference (5).

Jedoch können alternative Implementierungen mit mehr oder weniger Information ebenfalls eingesetzt werden, beispielsweise mit lediglich

target_SU_reference.target_message_reference (6).

Zusätzlich sind die Veränderungen gemäß den Beispielen auch miteinander kombinierbar, z. B. gemäß der Veränderung sowohl des Meldungsnamens als auch der Meldungsdaten, was in den folgenden Beispielen zum Vermeiden längerer Wiederholungen nicht explizit ausgeführt ist.

Das erste Beispiel betrifft eine Veränderung eines Meldungsnamens, das anhand eines Ausdrucks auf hoher Ebene dargestellt ist als

New_SUID.MESSAGEx = Old_SUID.MESSAGEy (7a).

Demnach wird die Meldung mit der Bezeichnung MESSAGEy in der alten Softwareeinheit in der neuen aktualisierten Softwareeinheit als MESSAGEx bezeichnet. Jede alte MESSAGEy in dem Meldungspuffer sollte demnach in die neue Bezeichnung MESSAGEx umgesetzt werden. Jedoch können new_SUID und old_SUID entweder target_SUID-Werte oder source_SUID-Werte sein. Ferner lautet die durch die Compiler- und Linker- Funktion anhand dieser Darstellung (7a) auf hoher Abstraktionsebene abgeleitete Maschinenebenendarstellung

new_SU_reference.new_message_reference = old_SU_reference.old_message_reference (7b).

Hier können new_SU_reference und old_SU_reference entweder vom Typ Ziel oder Quelle sein, jedoch übereinstimmend mit der Beschreibung auf hoher Abstraktionsebene. In einigen Fällen, z. B. mit eindeutigem Sender oder Empfänger, ist es möglich, sowohl Ziel- als auch Quellparameter anhand lediglich eines Typs zu erzeugen.

Der nächste Fall betrifft die Veränderung einer Softwareeinheits-Referenz, die bei Beschreibung auf hoher Abstraktionsebene ausgedrückt ist, durch

New_SUID = Old_SUID (8a).

Hier wird die neue Version der alten SU mit der Identität old_SUID der neuen Identität new_SUID zugeordnet. Demnach muß bei allen Altmeldungen in dem Meldungspuffer, die von den alten Softwareeinheit mit der Identität old_SUID gesendet oder empfangen werden, eine source_SU_reference oder target_SU_reference von old_. . . zu new_. . . geändert werden.

Ferner kann die durch den Compiler und Linker anhand der Beschreibung auf hoher Abstraktionsebene erzeugte Maschinenebenendarstellung aus zwei Anweisungen bestehen, gemäß

new_source_SU_reference = old_source_SU_reference new_target_SU_reference = old_target_SU_reference (8b).

Das nächste Beispiel betrifft die Veränderung einer Meldungsreferenz, die bei Darstellung auf einer hohen Abstrationsebene ausgedrückt wird durch

New SUID = Old_SUID (9a).

Bei diesem Beispiel erkennt dann, wenn die Meldungsidentitäten (z. B. Namen) in der alten und neuen Softwareeinheit übereinstimmen, der Compiler, welche alte Meldung welcher neuen Meldung entspricht, und es besteht keine Anforderung zum Abbilden dieser Darstellung auf hoher Abstraktionsebene auf eine Maschinenebene. Im Gegensatz hierzu kann sich die Referenz der Meldungen unabhängig von der Tatsache ändern, daß die Identität unverändert bleibt, da die Übersetzung Identität zu Referenz immer auch von anderen Änderungen abhängt. Eine durch den Compiler und Linker anhand der Beschreibung auf hoher Abstraktionsebene erzeugte Maschinenebenendarstellung kann durch die beiden folgenden Anweisungen für jede Meldungsklasse dargestellt werden:

new_source_SU_reference.new_source_message_reference = old_source_SU_reference.old_source_message_reference
new_target_SU_reference.new_target_message_reference = old_target_SU_reference.old_target_message_reference (9b).

Ferner ist im Hinblick auf die Änderung einer Meldungsreferenz gemäß der vorliegenden Erfindung zu erwähnen, daß die Information gemäß Gleichung (9b) nur in einem Fall zu erzeugen ist, in dem irgendwelche Veränderungen bei den Meldungsreferenzen auftreten. Jedoch ist dies auch ein allgemeines Prinzip, d. h. liegen keine Unterschiede zwischen alten und neuen Parametern bei der Maschinenebenendarstellung vor, so kann die Information weggelassen werden, da keine Anforderung für eine Umsetzung besteht. Dies gilt selbst in einem Fall, in dem zuvor ein Unterschied bei der Darstellung auf hoher Abstraktionsebene vorlag, beispielsweise bei einem veränderten Meldungsidentitäten.

Das vierte Beispiel betrifft das Terminieren einer Meldung, das sich bei einer Darstellung auf hoher Abstraktionsebene darstellen läßt als

TERMINATE Old_SUID.MESSAGEx (10a).

Üblicherweise sollten alle Meldungen vom Typ abgerufene MESSAGEx in den alten Software-Bearbeitungseinheiten mit der Identität old_SUID von dem Meldungspuffer entfernt werden, da beispielsweise kein Empfänger in den neuen Software- Bearbeitungseinheiten vorliegt. Ferner kann old_SUID entweder vom Typ Quelle oder Ziel sein. Eine durch den Compiler und Linker anhand der Darstellung auf hohem Abstraktionsniveau gemäß der Gleichung (10a) erzeugte Maschinenebenendarstellung lautet:

terminate old_SU_reference.old_message_reference (10b).

Hierbei kann old_SU_reference entweder vom Typ Quelle oder Ziel sein, jedoch muß sie konsistent mit der Darstellung auf hoher Abstraktionsebene sein.

Der nächste Fall betrifft das Gegenteil einer Terminierung einer Meldung, d. h. die Initialisierung einer Meldung. Hier lautet die Darstellung auf hoher Abstraktionsebene:

INITIATE New_SUID.MESSAGEx[WITH data1, data2, . . .] (11a).

Ferner sollte eine Meldung vom Typ, die durch die neue Software-Bearbeitungseinheit als MESSAGEx abgerufen wird, mit der Identität new_SUID an die neue Software- Bearbeitungseinheit abgegeben werden. Die Meldung kann optional - wie definiert - Daten enthalten. Weist MESSAGEx mehrere Sender oder Empfänger auf, so sind sowohl die Ziel- als auch die Quell-SUID zu spezifizieren (nicht gezeigt). Die durch den Compiler und Linker anhand der Darstellung (11a) auf hoher Abstraktionsebene erzeugte Maschinenebenendarstellung lautet:

initiate new_SU_reference.new_message_reference [with data_1, data_2, . . .] (11b).

Schließlich betrifft ein weiteres Beispiel eine Veränderung von Meldungsdaten gemäß der Darstellung auf hoher Abstraktionsebene

New_SUID.MESSAGEx.DATAm = Old_SUID.MESSAGEx. DATAi + Old_SUID.MESSAGEx.DATAk (12a).

Hier entspricht DATAm, geführt von der Meldung nach neuem Format mit der Bezeichnung MESSAGEx in der neuen Software- Bearbeitungseinheit mit der Identität new_SUID der, Summe von DATAi und DATAk, beide geführt gemäß dem alten Format MESSAGEx bei der alten Software-Bearbeitungseinheit mit der Identität old_SUID. Allgemein können die Ausdrücke auf der rechten Seite der Gleichung (12a), z. B. einen oder mehreren Datenwert (e) einschließen, die von den Meldungen nach altem Format geführt werden, sowie weiterhin Konstanten und arithmetische und logische Ausdrücke, d. h.

SUIDx.MESSAGEy.DATAm = expression(SUIDz.MESSAGEu.DATAi, SUIDv.MESSAGEw.DATAk, . . ., constant1, . . .) (12b).

Ferner können die SUID-Werte entweder vom Typ Quelle oder Ziel sein.

Die ausgehend von dieser Darstellung auf hoher Abstrationsebene durch den Compiler und Linker erzeugte Maschinenebenendarstellung lautet:

new_SU_reference.new_message_reference.data m = old_SU_reference.old_message_reference.data_i + old_SU_reference.old_message_reference.data_k (12c).

Weiterhin können die Werte für SU_reference entweder vom Typ Quelle oder Ziel sein, jedoch müssen sie in Übereinstimmung zu der Darstellung auf hoher Abstraktionsebene stehen.

Wie oben dargelegt, basieren sämtliche Umsetzschritte auf funktionalen Beziehungen unabhängig von dem Zeitpunkt der Durchführung.

Während vorangehend die spezifische Struktur und die Funktionalität des Meldungsumsetzgeräts gemäß der vorliegenden Erfindung beschrieben ist, folgt nun die Beschreibung typischer Beispiele für deren Anwendung unter Bezug auf die Fig. 12 bis 17.

Wie in Fig. 12 gezeigt, besteht eine erste Option in der Zuordnung eines ausgewiesenen Meldungsumsetzungsgerätes zu jeder Komponente eines Software-Bearbeitungssystems, so daß die Umsetzung von Meldungen jeweils in jeder einzelnen Komponente 10, 12, 14 möglich ist.

Die Fig. 13 zeigt eine weitere Option, wo die Systemkomponenten wiederum wie in Bezug auf die Fig. 5 erläutert vorgesehen sind, jedoch nicht jeweils ein eigenes Meldungsumsetzgerät enthalten. Vielmehr teilen sie ein gemeinsames Systemaktualisierungsgerät 48. Dieses Systemaktualisierungsgerät 48 enthält eine Softwareaktualisierungseinheit 50 zum Installieren der neuen Softwareeinheiten in den unterschiedlichen Systemkomponenten 10, 12, 14. Eine Datenaktualisierungseinheit 52 dient zum Modifizieren von Daten, die in internen Datenstrukturen der Softwareeinheiten gespeichert sind, und zwar während dem Prozeß der Softwareinstallation. Sobald neue Softwareeinheiten in den Systemkomponenten 10, 12, 14 in Betrieb genommen werden, kann das Meldungsumsetzgerät 34 aktiviert werden, um auch die in den Meldungspuffern 22, 24, 26 gespeicherten Meldungen an die neue Systemumgebung anzupassen.

Die Fig. 14 zeigt eine weitere Systemstruktur, die als partitionierte Systemarchitektur einzuordnen ist, bei der jede Komponente redundant mit zwei symmetrischen Implementierungen vorgesehen ist 10-a, 10-b, 12-1, 12-b, 14-a, 14-b. In dieser besonderen Systemumgebung wird das Aktualisierungsgerät 48 zwischen der ersten Partition A und der zweiten Partition B vorgesehen, und es enthält im Vergleich zu der Fig. 13 identische Elemente.

Jedoch ist es auch möglich, das Aktualisierungsgerät 48 redundant zu implementieren, mit einer Aktualisierungsfunktionalität sowohl für die Seite A als auch die Seite B, und zwar im Sinne der Fig. 12 oder 13. Üblicherweise würde bei jeder Partition der Seite A und der Seite B eine Struktur nach Fig. 13 vorgesehen sein, und somit wäre jede Seite während der Aktualisierung der anderen Seite vollständig betriebsbereit. Deshalb ist es gemäß der vorliegenden Erfindung möglich, die Verfügbarkeit und Sicherheit des Gesamtsystems eindeutig zu verbessern und die Leistungsfähigkeit während der Systemaktualisierung zu erhöhen.

Diese spezielle Architektur eignet sich besonders für das erfindungsgemäße Aktualisierungsverfahren für die Aktualisierung von Software und zugeordneten Daten sowie entsprechender Meldungen, wie dies nachfolgend unter Bezug auf die Fig. 15 beschrieben wird.

Wie in Fig. 15 gezeigt, beginnt das erfindungsgemäße Verfahren mit einem Vorbereitungsschritt S1 zum Laden neuer Software, und es führt die Initialisierung hierfür durch. Ferner wird gemäß dem Schritt S2 die Ausführung der alten Software während dem vollständigen Aktualisieren der Software und zugeordneter Daten fortgeführt. Gleichzeitig mit der Ausführung der alten Software im Schritt S2 erfolgt die Aktualisierung der neuen Software und zugeordneter Daten im Schritt S3. Diese parallele Ausführung der unterschiedlichen Schritte S2 und S3 ermöglicht eine signifikante Besserung des gesamten Systemwirkungsgrads während dem erfindungsgemäßen Aktualisierungsprozeß.

Wie in Fig. 15 gezeigt, erfolgt unmittelbar dann, wenn der Zustand der alten Software und der neuen Software im Schritt S4 als konsistent bewertet wird, ein Umschalten zu der neuen Software im Schritt S5. Dieser Schritt S5 kann gruppenweise für neue und alte Softwareeinheiten durchgeführt werden, oder für alle Softwareeinheiten in einer Gruppe zusammen.

Ferner können während dem Schritt S5 Meldungen, die in den Fig. 5 sowie 12 bis 14 gezeigten Meldungspuffern 22, 24, 26 gespeichert sind, ebenfalls gemäß der oben dargestellten Prozedur umgesetzt werden. Werden diese Meldungen unmittelbar während dem Umschalten umgesetzt, so ergibt sich keine weitere Verzögerung bei dem späteren Start neuer Softwareeinheiten.

Nach jedem Umschaltschritt S5 folgt ein Schritt S6 zum Bewerten der Frage, ob noch zu aktualisierende Software oder Daten in dem System vorliegen. Ist dies der Fall, so geht der Aktualisierungsprozeß zu dem Schritt S2 über, um mit der Aktualisierung zusätzlicher Softwareeinheiten und zugeordneter Daten solange fortzufahren, bis der vollständige Aktualisierungsprozeß beendet ist. In diesem Fall kann eine Situation auftreten, bei der alte und neue Softwaremodule gleichzeitig in demselben System ausgeführt werden. Demnach kann es erforderlich sein, Meldungen umzusetzen, die zwischen der neuen und alten Software ausgetauscht werden, wie oben erläutert und im Schritt S2 wiedergegeben. Diese Umsetzung kann vorzugsweise auf Anforderung bei dem Jobstart aktiviert werden, unmittelbar vor dem Beginn der Bearbeitung einer individuellen Meldung bei der empfangenen Softwarebearbeitungseinheit.

Andernfalls geht der Systembetrieb zu dem Schritt S7 über, bei dem die neuen Softwareeinheiten den Betrieb in dem aktualisierten System fortführen. Hierbei kann eine Situation auftreten, daß bei einem Start einer neuen Softwareeinheit durch diese zu empfangende Meldungen nicht umgesetzt sind, was in dem Schritt S8 beurteilt wird. In einem solchen Fall wird das erfindungsgemäße Meldungsumsetzgerät gemäß dem Schritt S9 bedarfsgemäß aktiviert. Anschließend wird die Ausführung der neuen Software nach einem Durchlauf durch die Schleife im Schritt S7 fortgesetzt.

Die Fig. 16 zeigt eine Kommunikationssystemvermittlung als erstes Beispiel für die Anwendung der vorliegenden Erfindung. Eine Beschreibung der Kommunikationssystemvermittlung findet sich beispielsweise in Ericsson Review Nr. 3, 1995. Ein Zentralprozessor 54 handhabt anrufbezogene Ereignisse und andere Datenkommunikationsprozesse in dem Kommunikationssystem. Ferner handhaben fern gelegen Ortsprozessoren 56, 58, 60 die Signalgebung zu und von den Endteilnehmern in dem Kommunikationssystem. Wie in Fig. 13 gezeigt, koordiniert ein Ortsprozessorkoordinator 62 den Austausch der Signale zwischen den Ortsprozessoren 56, 58, 60 und dem Zentralprozessor 54. Zum Handhaben zeitkritischer Ereignisse ermöglicht den Jobpuffer 52 die Pufferung von Meldungen, die in dem oben genannten Sinne ausgetauscht werden.

Bei einem derartigen Kommunikationssystem würde die Aktualisierung in dem Zentralprozessor 54 erfolgen, der beispielsweise vom Typ mit zwei Partitionen sein kann, damit der Aktualisierungsprozeß unterstützt wird. Eine besondere Auswirkung der vorliegenden Erfindung bei einer solchen Anwendung besteht darin, daß die Gesamtsystemunterbrechung während einer Systemaktualisierung minimiert ist, damit jeder Verlust an Einnahmen für den Systembetreiber vermieden wird. Demnach ist es möglich, das Kommunikationssystem im Vergleich zu dem üblichen Softwareaktualisierungsprozeß, der eine vollständige Unterbrechung des Systems erfordert, öfter in flexibler Weise zu aktualisieren.

Die Fig. 17 zeigt ein verteiltes Kommunikationssystem als zweites Beispiel für die Anwendung der vorliegenden Erfindung. Die Komponenten des verteilten Kommunikationssystems in das Zugangsnetz, das Ortsnetz und das Fernnetz. Das Ortsnetz und das Fernnetz bilden das Transportnetz für Trägerdienste.

Knoten in diesem Kommunikationsnetz sind entweder Netzknoten oder Zugangsknoten. Das Fernnetz nutzt Vielfachleitungen für den Austausch von Meldungen. Ferner sind auch Verbindungsleitungen in dem Kommunikationsnetz für den Austausch von Meldungen vorgesehen.

Aus dieser Darstellung folgt unmittelbar, daß jede Softwareeinheit in einem Netzknoten, einem Zugangsknoten oder dem Endgerät unter Einsatz der erfindungsgemäßen Vorgehensweise aktualisierbar ist, bei gleichzeitiger Minimierung der Störung des Kommunikationsnetzes.

Typische Beispiele für derartige Kommunikationsnetze sind einem ATM-Netz, bei dem die Meldungen der einzelnen ATM- Paketen entsprechen, Strukturen für Anrufzentren, Internet- Anwendungen, FDDI-Anwendungen oder Framerelay-Anwendungen. Weiterhin läßt sich die vorliegende Erfindung auch bei der GSM-Infrastruktur oder im Internet anwenden, indem die Software durch Internet-Dienstanbieter betrieben wird.

Ferner kann neben der Software-Aktualisierung im Netzwerkknoten die vorliegende Erfindung auch im Fall der Aktualisierung des Protokolls für die Vermittlung von Daten und Signalen in derartigen Netzen angewandt werden.

Bezugszeichenliste

10

Systemkomponente

12

Systemkomponente

14

Systemkomponente

16

Anwendungseinheit

18

Anwendungseinheit

20

Anwendungseinheit

22

Meldungspuffer

24

Meldungspuffer

26

Meldungspuffer

28

Verbindung

30

Verbindung

32

Verbindung

34

Meldungsumsetzgerät

36

Meldungsumsetzinformations-Schnittstelleneinheit

38

Meldungssteuerinformations-Bearbeitungseinheit

40

Meldungsdatenbearbeitungseinheit

42

Tabellenspeichereinheit

44

Informationszugriffseinheit

46

Umsetzhandhabungseinheit

48

Systemaktualisierungsgerät

50

Software-Aktualisierungseinheit

52

Datenaktualisierungseinheit

54

Zentralprozessor

56

Ortsprozessor

58

Ortsprozessor

60

Ortsprozessor

62

Ortsprozessorkoordinator

64

Job Puffer

Claims

1. Meldungsumsetzgerät (37), enthaltend:

a) eine Schnittstellenvorrichtung (36) für Meldungsumsetzinformation (MCI) zum Beschreiben zumindest einer in dem Software-Bearbeitungssystem übertragenen Meldung vor und nach einer Aktualisierung des Software-Bearbeitungssystems, und
b) eine Meldungsumsetzvorrichtung (38, 40) zum Umsetzen der Meldung in die neue Darstellung für das aktualisierte Software-Bearbeitungssystem in Übereinstimmung mit den in der Meldungsumsetzinformation (MCI) angegebenen Spezifikationen.

2. Meldungsumsetzgerät nach Anspruch 1, dadurch gekennzeichnet, daß die Meldungsumsetzvorrichtung (38, 40) bei Umschalten zu dem aktualisierten Softwarebearbeitungssystem aktiviert ist.

3. Meldungsumsetzgerät nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die Meldungsumsetzvorrichtung (38, 40) auf Anforderung bei Jobstart einer meldungsempfangenden neuen Software in dem Software-Bearbeitungssystem aktiviert ist.

4. Meldungsumsetzgerät nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß die Meldungsumsetzvorrichtung (38, 40) auf Anforderung bei Jobstart einer meldungsempfangenden alten Software in dem Software-Bearbeitungssystem aktiviert ist.

5. Meldungsumsetzgerät nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß die Meldungsumsetzvorrichtung (38, 40) enthält:

a) eine Meldungssteuerinformations- Bearbeitungsvorrichtung (38) zum Umsetzen eines Meldungssteuerinformationsteils mit zumindest einer Meldungsreferenz, der Angabe der Quellsoftwareeinheit der Meldung, der Angabe der Zielsoftwareeinheit der Meldung und einer Meldungsklasse, und
b) eine Meldungsdaten-Bearbeitungsvorrichtung (40) zum Umsetzen zumindest eines Datenelements eines Meldungsdatenabschnitts.

6. Meldungsumsetzgerät nach Anspruch 5, dadurch gekennzeichnet, daß die Meldungssteuerinformations-Bearbeitungseinheit (38) unterteilt ist in:

a) eine Tabellenspeichervorrichtung (42) zum Speichern umsetzungsrelevanter Teile im Hinblick auf die Meldungssteuerinformation,
b) eine Informationszugriffsvorrichtung (44) zum Ermöglichen eines Zugriffs auf die in der Tabellenspeichervorrichtung (42) gespeicherte Information, in Übereinstimmung mit im Hinblick auf eine umzusetzende Meldung zugeführte Information,
c) eine Umsetzungshandhabungsvorrichtung (46) zum Implementieren der Umsetzung von Meldungen gemäß der durch die Informationszugriffsvorrichtung (44) und der umzusetzenden Meldung zugeführten Information.

7. Meldungsumsetzgerät nach Anspruch 5 oder 6, dadurch gekennzeichnet, daß die Meldungssteuerinformations-Bearbeitungsvorrichtung (38) und die Meldungsdaten-Bearbeitungsvorrichtung (40) die Umsetzung empfangener Meldungen unter Einsatz funktioneller Beziehungen durchführen.

8. Meldungsumsetzgerät nach einem der Ansprüche 5 bis 7, dadurch gekennzeichnet, daß die Meldungssteuerinformations-Bearbeitungsvorrichtung (38) eine Meldungsidentität umsetzt gemäß
New_SUID.MESSAGEx = Old_SUID.MESSAGEy (7a).

9. Meldungsumsetzgerät nach einem der Ansprüche 5 bis 8, dadurch gekennzeichnet, daß die Meldungssteuerinformations-Bearbeitungsvorrichtung (38) eine SU_reference umsetzt gemäß
New_SUID = Old_SUID (8a).

10. Meldungsumsetzgerät nach einem der Ansprüche 5 bis 9, dadurch gekennzeichnet, daß die Meldungssteuerinformations-Bearbeitungsvorrichtung (38) eine Meldungsreferenz umsetzt gemäß
New_SUID = Old_SUID (9a).

11. Meldungsumsetzgerät nach einem der Ansprüche 5 bis 10, dadurch gekennzeichnet, daß die Meldungssteuerinformations-Bearbeitungsvorrichtung (38) eine Meldung terminiert gemäß
TERMINATE SUID.MESSAGEx (10a).

12. Meldungsumsetzgerät nach einem der Ansprüche 5 bis 11, dadurch gekennzeichnet, daß die Meldungssteuerinformations-Bearbeitungsvorrichtung (38) eine Meldung initialisiert gemäß
INITIATE SUID.MESSAGEx[WITH data1, data2, . . .] (11a).

13. Meldungsumsetzgerät nach einem der Ansprüche 5 bis 12, dadurch gekennzeichnet, daß die Meldungsdaten- Bearbeitungsvorrichtung (40) Meldungsdaten verändert gemäß
SUIDx.MESSAGEy.DATAm = expression (SUIDz.MESSAGEu.DATAi, SUIDv.MESSAGEw.DATAk, . . . constant1, constant2, . . .) (12a)
derart, daß der Ausdruck der rechten Seite Operatoren enthalten kann, insbesondere vom arithmetischen oder logischen Typ, zum Handhaben spezifizierter Datenvariabler und Konstanten.

14. Software-Bearbeitungssystem vom Typ mit Aktualisierungsfunktionalität, enthaltend:

a) zumindest einen Meldungspuffer (22, 24, 26) zum Speichern von Meldungen, die von einem Software- Bearbeitungssystem zu bearbeiten sind,
b) zumindest eine Anwendungseinheit (16, 18, 20) zum Bearbeiten von Meldungen, die in mindestens einem Meldungspuffer gespeichert sind, und
c) ein Meldungsumsetzgerät (34) zum Umsetzen von Meldungen in eine neue Darstellung nach einer Aktualisierung der zumindest einen Aktualisierungseinheit (16, 18, 20) gemäß einem der Ansprüche 1 bis 13.

15. Software-Bearbeitungssystem nach Anspruch 14, dadurch gekennzeichnet, daß es vom verteilten Typ mit mehreren Anwendungseinheiten (16, 18, 20) ist, die jeweils mit einem Umsetzgerät (34) verbunden sind.

16. Software-Bearbeitungssystem nach Anspruch 14, dadurch gekennzeichnet, daß es vom verteilten Typ mit mehreren Anwendungseinheiten (16, 18, 20) ist, die jeweils mit einem gemeinsamen Umsetzgerät (34) verbunden sind.

17. Software-Bearbeitungssystem nach Anspruch 14, dadurch gekennzeichnet, daß es zwei Logikpartitionen (10-a, 10-b, 12-a, 12-b, 14-a, 14-b) aufweist, die mit einem gemeinsamen Meldungsumsetzgerät (34) verbunden sind.

18. Software-Bearbeitungssystem nach Anspruch 14, dadurch gekennzeichnet, daß es zwei Logikpartitionen (10-a, 10-b, 12-a, 12-b, 14-a, 14-b) aufweist, die mit einem jeder Logikpartition . . ..?? HIER FEHLT WAS AUF DEM BAND?? Meldungsumsetzgerät (34) versehen sind.

19. Systemaktualisierungsverfahren für ein Rechnungssystem mit zumindest zwei Partitionen, enthaltend die Schritte:

a) Aktualisierung eines Zustands einer neuen Software (S3) in einer Standby/Bereitschafts- Partitionsvorrichtung gemäß dem Zustand einer alten Software in einer Betriebspartitionsvorrichtung bei Fortführung der Ausführung der alten Software,
b) Umschalten zu der Ausführungsform der neuen Software (S5), soweit derselbe Zustand bei der Standby-Partitionsvorrichtung und der Betriebs- Partitionsvorrichtung erzielt ist, und
c) Umsetzen von Meldungen (S2, S5, S8), die zwischen unterschiedlichen Softwaremoduln in dem Rechensystem übertragen werden, in ein Format, das sich für die neue empfangende Software eignet, und zwar entweder beim Umschalten zu der Ausführung der neuen empfangenden Software oder beim Start der neuen empfangenden Software, oder
d) Umsetzen von Meldungen (S2, S5, S8), die zwischen unterschiedlichen Softwaremodulen in dem Rechensystem übertragen werden, in ein Format, das sich für alte empfangende Software eignet, entweder beim Umschalten zu der Durchführung der alten empfangenden Software oder auf Anforderung bei Jobstart der alten empfangenden Software.

20. Systemaktualisierungsverfahren nach Anspruch 18, dadurch gekennzeichnet, daß sich die Aktualisierungsschritte c), d) unterteilen in:

e) Lesen von Meldungsumsetzinformation (MCI) über eine zugeordnete Schnittstelle (36) in einem Meldungsumsetzgerät (34), und
f) Umsetzen der Meldung in die neue Darstellung für die neue Software in Übereinstimmung mit den Spezifikationen in der Meldungsumsetzinformation (MCI), oder
g) Umsetzen der Meldung in die alte Darstellung für die alte Software in Übereinstimmung mit den Spezifikationen in der Meldungsumsetzinformation (MCI).

21. Systemaktualisierungsverfahren nach Anspruch 19, dadurch gekennzeichnet, daß sich die Schritte f), g) unterteilen in:

h) unverändertes Übertragen von Meldungen, sofern keine Meldungsumsetzinformation (MCI) spezifiziert ist, und/oder
i) Umsetzen einer Meldungssteuerinformation mit mindestens einer Meldungsreferenz, einer Angabe einer Quellsoftwareeinheit einer Meldung, einer Angabe einer Zielsoftwareeinheit einer Meldung, sowie einer Meldungsklasse, und/oder
j) Umsetzen zumindest eines Datenelements eines Meldungsdatenabschnitts.

22. Systemaktualisierungsverfahren nach Anspruch 21, dadurch gekennzeichnet, daß die Umsetzung empfangener Meldungen unter Einsatz funktioneller Beziehungen durchgeführt wird.

23. Systemaktualisierungsverfahren nach einem der Ansprüche 19 bis 21, dadurch gekennzeichnet, daß die Umsetzschritte parallel zu und ohne Störung der in der Betriebspartitionsvorrichtung ablaufenden alten Software durchgeführt werden.

24. Systemaktualisierungsverfahren nach einem der Ansprüche 19 bis 23, dadurch gekennzeichnet, daß die Umsetzschritte wiederholt als Hintergrundprozeß solange durchgeführt werden, bis das Umschalten zu der neuen Software abgeschlossen ist, um den sich verändernden Zustand in der Betriebspartitionsvorrichtung zu berücksichtigen.

25. Systemaktualisierungsverfahren nach einem der Ansprüche 19 bis 24, dadurch gekennzeichnet, daß neben dem Umsetzschritt im Zusammenhang mit alten Meldungen ein spezieller Initialisierungsschritt für neue Meldungen/Datenelemente beim Umschalten oder beim Anlaufen der neuen Software durchgeführt wird.

26. Systemaktualisierungsverfahren nach einem der Ansprüche 19 bis 25, dadurch gekennzeichnet, daß bei Auftreten einer Fehlersituation vor dem Umschalten die Umsetzung beendet wird und die Durchführung der alten Software in der Betriebspartitioniervorrichtung weiter fortgeführt wird.

27. Systemaktualisierungsverfahren nach einem der Ansprüche 19 bis 26, dadurch gekennzeichnet, daß ein Rück- Umschalten so durchgeführt wird, daß die Betriebspartitionsvorrichtung mit der alten Software erneut die Betriebspartitionsvorrichtung wird, und zwar im Fall eines Fehlers während der Ausführung der neuen Software nach dem Umschalten.