EP1261917A2 - Verfahren zur sicherstellung der kompatibilität und verfahren zur datensicherung innerhalb eines mehrere teilrechnersysteme aufweisenden verteilten rechnersystems - Google Patents

Verfahren zur sicherstellung der kompatibilität und verfahren zur datensicherung innerhalb eines mehrere teilrechnersysteme aufweisenden verteilten rechnersystems

Info

Publication number
EP1261917A2
EP1261917A2 EP01913625A EP01913625A EP1261917A2 EP 1261917 A2 EP1261917 A2 EP 1261917A2 EP 01913625 A EP01913625 A EP 01913625A EP 01913625 A EP01913625 A EP 01913625A EP 1261917 A2 EP1261917 A2 EP 1261917A2
Authority
EP
European Patent Office
Prior art keywords
computer system
data
sub
activated
software
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP01913625A
Other languages
English (en)
French (fr)
Inventor
Giovanni Laghi
Johannes SCHÖPF
Georg Zöller
Wolfgang Burke
Claus-Andreas Frank
Dirk Hahnefeld
Bernhard Stryczek
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Publication of EP1261917A2 publication Critical patent/EP1261917A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/177—Initialisation or configuration control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4405—Initialisation of multiprocessor systems

Definitions

  • the invention relates to a method for ensuring compatibility between software units activated in sub-computer systems belonging to a distributed computer system, each of which has a version status of software code and / or
  • Data include, as well as a method for data backup within a distributed computer system having several sub-computer systems.
  • Distributed computer systems preferably play a special role in today's telecommunications systems, which are generally multiprocessor systems.
  • a distributed computer system is characterized in particular by the fact that processes can each be assigned to different processors, the processors possibly being located on spatially separate platforms in the distributed computer system.
  • FIG. 2 essentially shows the EWSD architecture, which on page 14 of a customer brochure from Siemens AG “More Power for Higher Performance EWSD PowerNode *, published in 1999, with the order number A50001-N2-P86-2-7600, Information and Communication Networks, Hofmannstr. 51, D-81359 Kunststoff.
  • a further computer system (not explicitly shown in FIG. 2) is integrated in the system components SSNC, which takes over some tasks of the main computer system.
  • Operating software and application software for executing the tasks assigned to the computer systems are activated both on the main computer system CP and on the computer system of the SSNC, hereinafter referred to as the SSNC computer system.
  • the software units activated on the main computer system which generally comprise several software modules, are loosely coupled to the software units activated on the SSNC computer system, i.e. :
  • the software units of both computer systems do not access any shared memory, but required common data to run application software.
  • the software units activated on the sub-computer systems each of which comprises a version of the software code and data, must also be compatible with one another.
  • the object of the invention is to develop a method for ensuring data consistency and compatibility between software units activated on partial computer systems, which meets the requirements placed on a distributed computer system.
  • An essential aspect of the invention is that the following steps are carried out during system initialization of at least one such sub-computer system in order to ensure the compatibility between the software units activated in m sub-computer systems belonging to a distributed computer system:
  • the method according to the invention fulfills the requirement placed on a distributed computer system with regard to ensuring compatibility.
  • this procedure has the advantage that if a partial computer system reverts to a software unit with an older update version, ie that an "older * software unit must be activated or loaded, the other partial computer system also automatically to a compatible one Software unit falls behind.
  • the method according to the invention is preferably used in a switching system having at least two computer systems.
  • the system initialization mentioned can be carried out especially when the system is restarted or when the system is restarted.
  • version numbers of the software units present on a partial computer system are entered in a list in accordance with a further embodiment of the invention.
  • the version number of a software unit activated on the partial computer system is stored at the top of the list.
  • Such a list is preferably administered on each sub-computer system.
  • the individual lists are therefore searched for compatible software units. This means that the corresponding compatible software units are activated on the respective sub-computer systems.
  • each list element has one or more attributes.
  • the version number of a software unit is determined by setting a version attribute. tes in the list.
  • the list elements in a list are conveniently organized in such a way that the version numbers of the software units stored in the list from the second position onwards are sorted in ascending order according to their update age. In this way, the runtime of the search for compatible software units is optimized.
  • a further advantageous embodiment of the invention provides that when a non-activated software unit compatible with a first partial computer system has been found in a second partial computer system or vice versa, the software unit that has the latest version of is always selected to activate the compatible non-activated software unit the compatible non-activated software units of the second sub-computer system. This ensures that the system retains as many features as possible in the applications that are normally not made available by software units with an older update version.
  • Another essential aspect of the invention is that a data backup is initiated within a distributed computer system after a software change and is synchronized in the respective sub-computer systems of the distributed computer system, the following steps being carried out depending on the current status of the data backup process: a) Data is backed up in each sub-computer system, which other sub-computer systems cannot access. b) Data access blocking is activated in each sub-computer system, c) In each sub-computer system, data is backed up to which other sub-computer systems can also access. d) The previously activated data access blocks are deactivated again.
  • Another advantage of this method according to the invention can also be seen in the fact that it creates, among other things, an ideal prerequisite for guaranteed data consistency for the method according to the invention described above for ensuring compatibility.
  • the synchronization of the data backup preferably takes place in the following manner: the sub-computer systems agree on the synchronization parts mentioned that the data backup initiated in each sub-computer system has reached a status defined for the continuation of the data backup.
  • Such a data backup method is used in a switching system having at least two computer systems.
  • a variant for defining the synchronization points in the Data backup process consists of determining time intervals, for example by means of a timekeeper, at which the sub-computer systems must agree.
  • the synchronization points are implemented in the form of points defined in the software code.
  • a further development of the invention provides that after the data backup the version of the saved data is stored in the respective sub-computer system. This makes it easier to check the data consistency for later computing operations using the data. Ideally, this creates a possibility of using the stored version for compatibility testing in accordance with the above-described method according to the invention for ensuring compatibility.
  • the version status of the backed up data is stored by setting a version attribute stored in the respective sub-computer system.
  • a further embodiment of the invention proves to be particularly advantageous in that the data backups running on the respective sub-computer systems are controlled from a central point by means of control software. It is thus possible to initiate the data backup process from an operating system connected to the distributed computer system and to monitor and control it during its course.
  • FIG. 1 shows the exemplary architecture of a classic switching system mentioned at the beginning
  • FIG. 2 shows an exemplary architecture mentioned at the outset of a further development of the classic switching system
  • FIG. 3 shows an exemplary sequence of the data backup method according to the invention
  • 4a and 4b show an example of a flow chart for comparing the compatibility in the method according to the invention.
  • Figure 3 shows a system A sub-computer system, e.g. the main computer system and a further sub-computer system B, e.g. the SSNC computer system.
  • a sub-computer system e.g. the main computer system
  • a further sub-computer system B e.g. the SSNC computer system.
  • further process steps are marked with numbers surrounded by circles.
  • the previously mentioned synchronization points specified in the data backup process are shown in the figure with SYNC
  • step 1 a data backup is initiated on the subsystem system A and the subsystem system B using a so-called network manager software NM installed on an operating system connected to the overall system.
  • step 2 each sub-computer system has reached a synchronization point in the data backup run
  • step 3 the sub-computer systems System A and System B agree that both have reached the synchronization point SYNC 1.
  • step 4 data access blocks are initiated on both sub-computer systems. From this point on, no changes can be made to the data to be backed up in the following.
  • Step 5 both sub-computer systems have reached the synchronization point SYNC 2, in step 6 common data are saved on each sub-computer system.
  • Requests to change the common data to be backed up are rejected.
  • Information about rejected changes can be temporarily stored in a log file.
  • step 8 the data access blocks on each sub-system are removed again. After the data access block has been removed, changes can be made to the data again. In particular, previously rejected requests for changes are made to the data based on the information recorded in the log file.
  • the mentioned synchronization points SYNC 1 to SYNC 3 can be implemented in different variants.
  • a timekeeper can determine a point in time at which a message about the status of the data backup process that has been reached is reported to the other sub-computer system.
  • the synchronization points can be implemented in the software code, for example in such a way that a message is sent to the other sub-computer system at certain points in the software code.
  • EWSD_JOB_REG.DECISION ROGC_EWSD_FALLB_REQ
  • EWSD_JOB_REG.EWSD_FB_TO_NEXT_GEN FALSE
  • EWSD JOB REG.COLDST SYNC FALSE
  • a version attribute GCS (Generation Compatibility Sign) is used to identify the version status of a software unit, on the basis of which the compatibility check e.g. according to the figures 4a and 4b explained below.
  • FIGS. 4a and 4b show the compatibility test that takes place in the method according to the invention between the
  • Subcomputer systems System A and System B existing software units and the response to the compatibility check shown.
  • the numbers marked with circles mark entry points to the compatibility check, which result from searching the lists mentioned for compatible software units. This method is used in particular during system initialization e.g. carried out after a software update or change.
  • the version number of the version attribute GCS_A of the software unit with the number 1 activated on the partial computer system A matches the version number, e.g. 6831 of the version attribute GCS_B of the software unit activated on the partial computer system B with the number 1. In this case, it is permitted that a connection is established between the subsystem system A and the subsystem system B during the system initialization of the overall system.
  • the version attributes GCS_A and GCS_B do not match, the lists mentioned are further examined for compatible software units, with entry point 2 or entry point being used to check the compatibility 3 comes into question.
  • the version attributes GCS_A of the software unit with the number 1 activated on the sub-computer system A and the version attribute GCS_B of a software unit with the number 2 not activated on the sub-system B are compared.
  • the software unit with the latest update version is preferably used by the conceivable, compatible, non-activated software units.
  • a return to the software unit with the number 2 is initiated in the partial computer system System B.
  • a relapse means: The currently activated software unit on the partial computer system System B is deactivated and instead the previously not activated software unit with the number 2 is activated on this system. If the version attributes GCS_A and GCS_B do not match, further searching of the lists mentioned leads to entry point 4.
  • the compatibility check runs analogously to entry point 2.
  • the comparison of the version attributes GCS_A and GCS_B if they match, results in a relapse to the "older * not activated software unit with the number 2 in the sub-computer system Systems A. If the version attributes do not match, it is possible to get to entry point 4.
  • two version attributes GCS_A and GCS_B of two software units that are not activated on the respective sub-computer system System A or System B are compared with one another. If the two version attributes match, the non-activated software units are activated on the sub-computer system System A and on the sub-computer system B and the previously activated software units are deactivated. In the event of a mismatch between the two Version attributes result in an error message and no connection is established between the two sub-computer systems System A and System B during system initialization.
  • the exemplary embodiment of the method according to the invention can of course be applied analogously to distributed computer systems with several sub-computer systems. For this purpose, there is a list on each sub-computer system that contains all software units of a sub-computer system. In this way, all existing lists are searched for compatible software units with the help of the version attribute. All version attachments are compared with each other. Corresponding reactions on the sub-computer systems are drawn according to the comparison result.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Hardware Redundancy (AREA)
  • Multi Processors (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Sicherstellung der Kompatibilität zwischen in zu einem verteilten Rechnersystem gehörenden Teilrechnersystemen (System A, System B) aktivierten Softwareeinheiten, die jeweils einen Versionsstand von Softwarecode- und/oder Daten umfassen, wobei bei einer sich aus einer Kompatibilitätsprüfung ergebenden Kompatibilität eine kompatible nicht aktivierte Softwareeinheit auf ihrem Teilrechnersystem aktiviert sowie die entsprechende zuvor aktivierte Softwareeinheit deaktiviert wird. Die Erfindung schließt weiter ein Verfahren zur Datensicherung innerhalb eines mehrere Teilrechnersysteme aufweisenden verteilten Rechnersystems ein, wobei die Datensicherung synchronisiert wird und in Abhängigkeit vom aktuellen Status derselben Schritte zur Datensicherung von eigenen Daten der jeweiligen Teilsysteme, zur Datenzugriffsblockierung, zur Datensicherung von gemeinsamen Daten sowie zur Deaktivierung der Datenzugriffsblockierung ausgeführt werden.

Description

Beschreibung
Verfahren zur Sicherstellung der Kompatibilität und Verfahren zur Datensicherung innerhalb eines mehrere Teilrechnersysteme aufweisenden verteilten Rechnersystems
Die Erfindung betrifft ein Verfahren zur Sicherstellung der Kompatibilität zwischen in zu einem verteilten Rechnersystem gehörenden Teilrechnersystemen aktivierten Softwareeinheiten, die jeweils einen Versionsstand von Softwarecode- und/oder
Daten umfassen, sowie ein Verfahren zur Datensicherung innerhalb eines mehrere Teilrechnersysteme aufweisenden verteilten Rechnersystems .
Verteilte Rechnersysteme spielen vorzugsweise in heutigen Te- lekommunikationssystemen, die in der Regel Multiprozessorsy- steme sind, eine besondere Rolle. Ein verteiltes Rechnersystem ist insbesondere dadurch charakterisiert, daß Prozesse jeweils unterschiedlichen Prozessoren zugeteilt werden kön- nen, wobei sich die Prozessoren gegebenenfalls auf örtlich getrennten Plattformen im Verteilten Rechnersystem befinden können.
Im Zusammenhang mit Telekommunikationssystemen kommen ver- teilte Rechnersysteme zunehmend in Vermittlungssystemen zum Einsatz. Bekannte klassische Vermittlungssysteme wie z.B. das Produkt EWSD (elektronisches Wählsystem digital) der Firma Siemens AG, dessen Architektur beispielhaft in Figur 1 abgebildet ist, weisen bisher nur ein Hauptrechnersystem, nämlich einen Koordinationsprozessor auf, der die Steuerung der Systemkomponenten (z.B. die Anschlußeinheiten LTG, das Koppelnetz SN sowie die Signalisierungskontrolleinheit CCNC) vornimmt und koordiniert. Eine Weiterentwicklung des Produktes EWSD sieht unter anderem vor, daß die Signalisierungseinheit CCNC durch die Signalisierungseinheit SSNC, die in Figur 2 gezeigt wird, ersetzt wird. Die Figur 2 gibt im wesentlichen die EWSD-Architektur wieder, die auf Seite 14 einer Kunden- broschure der Siemens AG „ More Power for Higher Performance EWSD PowerNode* , herausgegeben im Jahre 1999, mit der Bestellnummer A50001-N2-P86-2-7600, Information and Communica- tion Networks, Hofmannstr. 51, D-81359 München abgebildet ist. Neben einer ATM-basierten (Asynchronous Transfer Mode) Plattform ist m der Systemkomponenten SSNC ein weiteres m der Figur 2 nicht explizit dargestelltes Rechnersystem integrier!:, das einige Aufgaben des Hauptrechnersystems übernimmt .
Sowohl auf dem Hauptrechnersystem CP als auch auf dem Rechnersystem des SSNC, im folgenden SSNC-Rechnersystem genannt, ist jeweils eine Betriebssoftware und Anwendungssoftware zur Ausfuhrung der den Rechnersystemen zugeordneten Aufgaben ak- tiviert. Die auf dem Hauptrechnersystem aktivierten Softwareeinheiten, die m der Regel jeweils mehrere Softwaremodule umfassen, sind hierbei mit den auf dem SSNC-Rechnersystem aktivierten Softwareeinheiten lose gekoppelt, d.h. : die Softwareeinheiten beider Rechnersysteme greifen auf keinen gemem- samen Speicher zu, benotigten jedoch zur Ausfuhrung von Anwendungssoftware gemeinsame Daten. Um die korrekte Funktionsweise des gesamten Vermittlungssystems zu gewahrleisten, muß die Konsistenz der gemeinsamen Daten auf jedem Teilrechnersy- stem (Hauptrechnersystem und SSNC-Rechnersystem) sicherge- stellt werden. Auch müssen die auf den Teilrechnersystemen aktivierten Softwareeinheiten, die jeweils einen Versionsstand von Softwarecode und Daten umfassen, zueinander kompatibel sein.
Hierfür ist erforderlich, daß eine Datensicherung durchgeführt wird, die über alle Teilrechnersysteme hinweg abgestimmt wird. Eine solche Datensicherung sollte insbesondere nach einer Softwareanderung, z.B. verursacht durch ein umfangreiches sogenanntes Software-Update, veranlaßt werden. Damit steht diese Datensicherung einer erneuten Systeminitia- lisierung, z.B. eines Systemneustarts oder -Wiederanlaufs, zur Verfugung. Wahrend der Syste mitialisierung müssen dann mögliche Inkonsistenzen und Inkompatibilitaten festgestellt werden, um diese wahrend der Systeminitialisierung beseitigen zu können.
Da die Entwicklungstendenzen bei Telekommunikationssystemen von einem zentralen Hauptrechnersystem wegfuhren und zu mehrere Teilrechnersysteme aufweisende verteilten Rechnersystemen hinfuhren werden, werden zunehmend höhere Anforderungen an derartige Datensicherungen und Systeminitialisierungen ge- stellt, die einen maßgeblichen Anteil zur Konsistenz- und Kompatibititatssicherstellung beitragen.
Die Aufgabe der Erfindung besteht darin, ein Verfahren zur Sicherstellung der Datenkonsistenz und der Kompatibilität zwischen auf Teilrechnersystemen aktivierten Softwareeinheiten zu entwickeln, das den an ein verteiltes Rechnersystem gestellten Anforderungen gerecht wird.
Diese Aufgabe wird durch die m den unabhängigen Ansprüchen angegebenen Merkmale gelost. Weitere Ausgestaltungen der Erfindung sind in den abhangigen Ansprüchen gekennzeichnet.
Ein wesentlicher Aspekt der Erfindung besteht darin, daß zur Sicherstellung der Kompatibilität zwischen m zu einem ver- teilten Rechnersystem gehörenden Teilrechnersystemen aktivierten Softwareeinheiten wahrend einer Systeminitialisierung mindestens eines solchen Teilrechnersystems folgende Schritte ausgeführt werden:
a) Nach Feststellung einer Inkompatibilitat zwischen einer auf einem ersten Teilrechnersystem aktivierten Softwareeinheit und wenigstens einer auf einem weiteren Teilrechnersystem aktivierten Softwareeinheit werden weitere auf den jeweiligen Teilrechnersystemen vorhandene nicht akti- vierte Softwareeinheiten auf Kompatibilität geprüft. b) Im Falle einer sich aus der Prüfung ergebenden Kompatibilität wird eine kompatible nicht aktivierte Softwareein- heit auf ihrem Teilrechnersystem aktiviert sowie die entsprechende zuvor aktivierte Softwareeinheit deaktiviert.
Auf diese Weise erfüllt das erfindungsgemäße Verfahren die an ein verteiltes Rechnersystem gestellte Anforderung hinsichtlich einer Kompatibilitätssicherstellung. Neben dieser bringt diese Vorgehensweise den Vorteil mit sich, daß dann, wenn ein Teilrechnersystem auf eine Softwareeinheit mit einem älteren Aktualisierungsversionstand zurückfällt, d.h., daß eine „äl- tere* Softwareeinheit aktiviert bzw. geladen werden muß, das andere Teilrechnersystem ebenfalls automatisch auf eine kompatible Softwareeinheit zurückfällt.
Vorzugsweise wird das erfindungsgemäße Verfahren in einem mindestens zwei Rechnersysteme aufweisenden Vermittlungssystem angewendet.
Die genannte Systeminitialisierung kann vor allem bei einem Systemneustart bzw. bei einem Wiederanlauf des Systems durch- geführt werden.
Um den Kompatibilitätsvergleich zu erleichtern, sind gemäß einer weiteren Ausführungsform der Erfindung Versionsnummern der auf einem Teilrechnersystem vorhandenen Softwareeinheiten in einer Liste eingetragen. Dabei ist die Versionsnummer einer auf dem Teilrechnersystem aktivierten Softwareeinheit an erster Stelle der Liste gespeichert. Vorzugsweise wird auf jedem Teilrechnersystem eine solche Liste verwaltet. Die einzelnen Listen werden also nach kompatiblen Softwareeinheiten durchsucht. Dies führt dazu, daß die entsprechenden kompatiblen Softwareeinheiten auf den jeweiligen Teilrechnersystemen aktiviert werden.
Zweckmäßigerweise sind die Listen derart ausgestaltet, daß jedes Listenelement ein oder mehrere Attribute aufweist. So wird gemäß einer Weiterbildung der Erfindung die Versionsnummer einer Softwareeinheit durch Setzen eines Versionsattribu- tes in der Liste abgelegt.
Smnvollerweise sind die Listenelemente in einer Liste derart organisiert, daß die m der Liste ab der zweiten Stelle abge- legten Versionsnummern der Softwareeinheiten gemäß ihres Ak- tualisierungsalters in der Liste aufsteigend sortiert sind. Auf diese Weise wird die Laufzeit der Suche nach kompatiblen Softwareeinheiten optimiert.
Eine weitere vorteilhafte Ausgestaltung der Erfindung sieht vor, daß dann, wenn in einem zweiten Teilrechnersystem eine zu einem ersten Teilrechnersystem kompatible nicht aktivierte Softwareeinheit gefunden worden ist oder umgekehrt, zur Aktivierung der kompatiblen nicht aktivierten Softwareeinheit stets diejenige Softwareeinheit ausgewählt wird, die den jüngsten Versionsstand von den kompatiblen nicht aktivierten Softwareeinheiten des zweiten Teilrechnersystems aufweist. Auf diese Weise wird gewährleistet, daß dem System möglichst viele Leistungsmerkmale in den Anwendungen erhalten bleiben, die normalerweise von Softwareeinheiten mit einem alteren Ak- tualisierungsversionsstand nicht zur Verfugung gestellt werden.
Zweckmaßigerweise wird die Sicherstellung der Kompatibilität zwischen auf Teilrechnersystemen aktivierten Softwareeinheiten automatisch wahrend einer Systeminitialisierung mindestens eines solchen Teilrechnersystems durchgeführt. Ein eventuell manueller Anstoß von außen kann, sollte aber dazu nicht erforderlich sein.
Ein weiterer wesentlicher Aspekt der Erfindung besteht darin, daß innerhalb eines verteilten Rechnersystems nach einer Softwareanderung eine Datensicherung angestoßen wird, die m den jeweiligen Teilrechnersystemen des verteilten Rechnersy- stems synchronisiert wird, wobei folgende Schritte m Abhängigkeit vom aktuellen Status des Datensicherungsablaufes ausgef hrt werden: a) In jedem Teilrechnersystem wird eine Datensicherung von Daten durchgeführt, auf die andere Teilrechnersysteme nicht zugreifen können. b) In jedem Teilrechnersystem wird eine Datenzugriffsblockie- rung aktiviert, c) In jedem Teilrechnersystem wird eine Datensicherung von Daten durchgeführt, auf die auch andere Teilrechnersysteme zugreifen können. d) Die zuvor aktivierten Datenzugriffsblockierungen werden wieder deaktiviert.
Auf diese Weise wird sichergestellt, daß m jedem Teilrechnersystem die gleichen Daten gesichert werden. Durch die ak- tivierten Datenzugriffsblockierungen werden Anderungswunsche an den zu sichernden Daten wahrend der Phase abgewiesen, m der der vorstehend beschriebene Schritt c) ausgeführt wird. Dadurch werden Inkonsistenzen der Daten über das Gesamtsystem hinweg vermieden. Ein weiterer Vorteil dieses erfmdungsgema- ßen Verfahrens ist auch darin zu sehen, daß dieses unter anderem eine ideale Voraussetzung hinsichtlich einer garantierten Datenkonsistenz für das vorstehend beschriebene erfin- dungsgemaße Verfahren zur Kompatibilitatssicherstellung schafft .
Die Synchronisierung der Datensicherung lauft vorzugsweise in folgender Weise ab: Die Teilrechnersysteme verstandigen sich an den genannten Synchronisationssteilen darüber, daß die m einem Teilrechnersystem jeweils angestoßene Datensicherung einen zur Weiterfuhrung der Datensicherung definierten Status erreicht hat.
Insbesondere wird ein solches Datensicherungsverfahren m einem mindestens zwei Rechnersysteme aufweisenden Vermittlungs- system angewendet.
Eine Variante zur Festlegung der Synchromsationsstellen im Datensicherungsablauf besteht darin, zeitliche Abstände beispielsweise mittels eines Zeitnehmers zu bestimmen, zu denen sich die Teilrechnersysteme verstandigen müssen.
Als weitere Variante des erfmdungsgemaßen Verfahrens ist vorgesehen, daß die Synchronisationsstellen m Form von im Softwarecode festgelegten Stellen implementiert sind.
Eine Weiterbildung der Erfindung sieht vor, daß nach der Da- tensicherung der Versionsstand der gesicherten Daten im jeweiligen Teilrechnersystem hinterlegt wird. Damit wird das Überprüfen der Datenkonsistenz für spatere die Daten benutzende Rechenoperationen erleichtert. Idealerweise wird hierdurch eine Möglichkeit geschaffen, den gespeicherten Ver- sionsstand zur Kompatibilitatsprufung gemäß des vorstehend beschriebenen erfmdungsgemaßen Verfahrens zur Sicherstellung der Kompatibilität heranzuziehen.
Gemäß einer weiteren Ausfuhrungsform wird der Versionsstand der gesicherten Daten durch Setzen eines im jeweiligen Teilrechnersystem gespeicherten Versionsattributes hinterlegt.
Als besonders vorteilhaft erweist sich eine weitere Ausgestaltung der Erfindung, dadurch, daß die auf den jeweiligen Teilrechnersystemen ablaufenden Datensicherungen von einer zentralen Stelle aus mittels einer Steuerungssoftware gesteuert werden. So ist es möglich, von einem mit dem verteilten Rechnersystem verbundenen Bediensystem aus das Datensicherungsverfahren anzustoßen und dieses wahrend seines Ablaufes zu kontrollieren und zu steuern.
Um Anderungswunsche an den Daten wahrend der Datensicherung nachvollziehen zu können und eventuell nach Abschluß der Datensicherung an den betroffenen Daten vornehmen zu können, werden gemäß einer Weiterbildung der Erfindung Informationen über abgewiesene Änderungen an den zu sichernden Daten wahrend der Datenzugriffsblockierung temporar m einer Proto- kolldatei festgehalten. Nach dem Aufheben der Datenzugriffsblockierung endet in der Regel die Datensicherung.
Nachstehend wird ein Ausführungsbeispiel der Erfindung unter Bezugnahme auf eine Zeichnung näher beschrieben.
In der Zeichnung zeigen:
Figur 1 die beispielhafte eingangs erwähnte Architektur eines klassischen Vermittlungssystems,
Figur 2 eine beispielhafte eingangs genannte Architektur einer Weiterentwicklung des klassischen Vermittlungssystems,
Figur 3 einen beispielhaften Ablauf des erfindungsgemäßen Datensicherungsverfahrens,
Figur 4a und 4b ein Beispiel eines Ablaufdiagrammes zum Kompatibilitätsvergleich im erfindungsgemäßen Verfahren.
Figur 3 zeigt ein Teilrechnersystem System A, z.B. das Hauptrechnersystem und ein weiteres Teilrechnersystem System B, z.B. das SSNC-Rechnersystem. In der Figur sind des weiteren Verfahrensschritte mit Kreisen umgebenen Ziffern gekenn- zeichnet. Die zuvor erwähnten im Datensicherungsablauf festgelegten Synchronisationsstellen werden in der Figur mit SYNC
1 bis SYNC 3 bezeichnet.
Insbesondere nach einer Softwareänderung bzw. -aktualisierung wird in Schritt 1 mit Hilfe einer auf einem mit dem Gesamtsystem verbundenen Bediensystem installierten sogenannten Netzmanagersoftware NM jeweils eine Datensicherung auf dem Teilrechnersystem System A und dem Teilrechnersystem System B angestoßen. Bis jedes Teilrechnersystem eine Synchronisations- stelle im Datensicherungslauf erreicht hat, werden in Schritt
2 die eigenen Daten in jedem Teilrechnersystem gesichert. Hierbei kann das Teilrechnersystem System A nicht auf die zu sichernden Daten des Teilrechnersystems System B und das Teilrechnersystem System B nicht auf die zu sichernden Daten des Teilrechnersystems System A zugreifen.
In Schritt 3 verstandigen sich die Teilrechnersysteme System A und System B darüber, daß beide die Synchronisationsstelle SYNC 1 erreicht haben. Im folgenden Schritt 4 werden auf beiden Teilrechnersystemen Datenzugriffsblockierungen veranlaßt. Ab diesem Zeitpunkt können keine Änderungen an den im folgen- den zu sichernden Daten vorgenommen werden. Nachdem im
Schritt 5 beide Teilrechnersysteme die Synchronisationsstelle SYNC 2 erreicht haben, werden in Schritt 6 auf jedem Teilrechnersystem gemeinsame Daten gesichert.
Diese gemeinsamen Daten zeichnen sich dadurch aus, daß diese beiden Teilrechnersystemen zur Verfugung stehen. Bei solchen zu sichernden Daten ist es besonders vorteilhaft, wenn der Versionsstand dieser im jeweiligen Teilrechnersystem hinterlegt wird. Dies geschieht normalerweise durch Setzen eines im jeweiligen Teilrechnersystem gespeicherten Versionsattributs, das vor allem im zu den Figuren 4a und 4b erläuterten Verfahren nutzbringend verwendet wird.
Anderungswunsche an den nun zu sichernden gemeinsamen Daten werden abgewiesen. Informationen über abgewiesene Änderungen können temporar in einer Protokolldatei festgehalten werden. Nachdem beide Teilrechnersysteme die Synchronisationsstelle SYNC 3 in Schritt 7 erreicht haben, werden m Schritt 8 die Datenzugriffsblockierungen auf jedem Teilsystem wieder aufge- hoben. Nach Aufheben der Datenzugriffsblockierung können wieder Änderungen an den Daten vorgenommen werden. Insbesondere werden vorherige abgewiesene Anderungswunsche anhand der m der Protokolldatei festgehaltenen Informationen an den Daten nachgezogen.
Nach erfolgreicher Durchfuhrung der Datensicherung erfolgt in Schritt 9 eine positive Meldung an die Netzmanagersoftware NM auf dem Bediensystem.
Die angesprochenen Synchronisationsstellen SYNC 1 bis SYNC 3 können in verschiedenen Varianten implementiert sein. Zum einen kann auf jedem Teilrechnersystem ein Zeitnehmer einen Zeitpunkt bestimmen, an dem dem anderen Teilrechnersystem eine Meldung über den erreichten Status des Datensicherungsablaufs gemeldet wird. Zum anderen können die Synchronisationsstellen im Softwarecode implementiert sein, beispielsweise in der Art, daß an bestimmten Stellen im Softwarecode eine Meldung an das andere Teilrechnersystem abgegeben wird.
Im folgenden werden Beispiele der für das erfindungsgemäße Verfahren zur Kompatibilitätssicherstellung verwendeten Li- sten gezeigt, in denen die Versionsstände der Softwareeinheiten in den Teilrechnersystemen (z.B. das Hauptrechnersystem CP und das SSNC-Rechnersystem) gespeichert sind:
Liste des CP:
' —EWSD (CP) Generationslist— '
I 1
EWSD_JOB_REG . EWSD_GENLIST
( 1 )
. GEN ( 1 . . 8 ) = ' 23680101 '
. GCS=4567 aktivierte Softwareeinheit
. STATE=ROGC_VALID (2)
.GEN(1..8)= '23680105'
.GCS=6831 Versionsattribut (GCS: Gene¬
. STATE=ROGC_VALID ration Compatibility Sign) (3)
. GEN ( 1..8 ) = ' '
.GCS-9999
. STATE=ROGC_EMPTY ( 4..31 ) EQUAL ABOVE ELEMENT Liste des SSNC:
' —SSNC GENERATIONLIST— '
C00MTC5A.KCGCPD0A.CGCHKD0S.SVH331P_HANDLE_SWM_PRG_RPT.SWM_ PRG_RPT_INFO. GEN_LIST
(1)
. GEN_NAME ( 1..8 ) = ' DBPXEO0V'
.GCS=6831 aktivierte Software¬
.BAP=0 einheit
. STATE=KSFM604_VALID (2)
.GEN_NAME(1..8)= 'BACKUP01'
.GCS=1234 nicht aktivierte
.BAP=1 Softwareeinheit
. STATE=KSFM604_VALID (3)
. GEN_NAME ( 1..8 ) = '
.GCS=9999
.BAP=5
. STATE=KSFM604_EMPTY (4)
. GEN_NAME ( 1..8 ) = ' '
.GCS=9999
.BAP-5
. STATE=KSFM604_UNDEFINED (5) EQUAL ABOVE ELEMENT
Beispiel einer Reaktion auf die Kompatibilitätsprüfung, bei dem die beiden vorstehenden Listen miteinander verglichen werden:
' I I I I I I I I 1 I I I ! I I I I I I I I ! I I 1 '
'--GENERATION CHECK DECISION— ' i ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! — '
EWSD_JOB_REG.DECISION=ROGC_EWSD_FALLB_REQ | Rückfall auf
EWSD_JOB_REG.COMMON_GCS=6831 ] „ältere* Soft-
EWSD_JOB_REG.EWSD_FB_TO_NEXT_GEN=FALSE | Wareeinheit EWSD JOB REG.COLDST SYNC=FALSE | im CP
Zur Kennzeichnung des Versionsstandes einer Softwareeinheit dient in der vorstehend gezeigten Beispielliste ein Ver- sionsattribut, GCS (Generation Compatibility Sign) , anhand dessen die Kompatibilitätsprüfung z.B. gemäß der im folgenden erläuterten Figuren 4a und 4b durchgeführt wird.
In den Figuren 4a und 4b wird die im erfindungsgemäßen Ver- fahren ablaufende Kompatibilitätsprüfung zwischen auf den
Teilrechnersystemen System A und System B vorhandenen Softwareeinheiten sowie die Reaktion auf die Kompatibilitätsprüfung gezeigt. Die mit Kreisen gekennzeichneten Nummern markieren Einstiegspunkte in die Kompatibilitätsprüfung, die sich aus dem Durchsuchen der genannten Listen nach kompatiblen Softwareeinheiten ergeben. Dieses Verfahren wird insbesondere während einer Systeminitialisierung z.B. nach einer Softwareaktualisierung oder -änderung durchgeführt.
Beim Einstiegspunkt 1 wird folgendes untersucht: Die Versionsnummer des Versionsattributes GCS_A der auf dem Teilrechnersystem System A aktivierten Softwareeinheit mit der Nummer 1 stimmt mit der Versionsnummer z.B. 6831 des Versionsattributes GCS_B der auf dem Teilrechnersystem System B aktivierten Softwareeinheit mit der Nummer 1 überein. In diesem Fall wird zugelassen, daß bei der Systeminitialisierung des Gesamtsystems eine Verbindung zwischen dem Teilrechnersystem System A und dem Teilrechnersystem System B hergestellt wird. Für den Fall, daß die Versionsattribute GCS_A und GCS_B nicht übereinstimmen, werden die genannten Listen weiter nach kompatiblen Softwareeinheiten untersucht, wobei zur Kompatibilitätsprüfung der Einstiegspunkt 2 oder der Einstiegspunkt 3 in Frage kommt.
Beim Einstiegspunkt 2 werden die Versionsattribute GCS_A der auf dem Teilrechnersystem System A aktivierten Softwareem- heit mit der Nummer 1 und das Versionsattribut GCS_B einer auf dem Teilrechnersystem System B nicht aktivierten Softwareeinheit mit der Nummer 2 miteinander verglichen. Vorzugsweise wird im Teilrechnersystem System B die Softwareeinheit mit dem jüngsten Aktualisierungsversionstand von den denkba- ren kompatiblen nicht aktivierten Softwareeinheiten herangezogen. Für den Fall, daß die Versionsattribute GCS_A und GCS_B übereinstimmen, wird im Teilrechnersystem System B ein Ruckfall auf die Softwareeinheit mit der Nummer 2 veranlaßt. Ein Ruckfall bedeutet: Die derzeit aktivierte Softwareeinheit auf dem Teilrechnersystem System B wird deaktiviert und stattdessen wird die zuvor nicht aktivierte Softwareeinheit mit der Nummer 2 auf diesem System aktiviert. Im Falle des Nichtubereinstimmens der Versionsattribute GCS_A und GCS_B fuhrt das weitere Durchsuchen der genannten Listen zum Em- stiegspunkt 4.
Beim Einstiegspunkt 3 lauft die Kompatibilitatsprufung analog zu Einstiegspunkt 2 ab. Der Vergleich der Versionsattribute GCS_A und GCS_B ergibt jedoch bei Übereinstimmung derselben einen Ruckfall auf die „altere* nicht aktivierte Softwareeinheit mit der Nummer 2 im Teilrechnersystem Systems A. Bei Nichtübereinstimmung der Versionsattribute ist es möglich, zu Einstiegspunkt 4 zu gelangen.
Beim Einstiegspunkt 4 werden zwei Versionsattribute GCS_A und GCS_B zweier nicht auf dem jeweiligen Teilrechnersystem System A oder System B aktivierten Softwareeinheiten miteinander verglichen. Bei Übereinstimmung der beiden Versionsattri- bute werden die nicht aktivierten Softwareeinheiten auf dem Teilrechnersystem System A und auf dem Teilrechnersystem System B aktiviert und die zuvor aktivierten Softwareeinheiten deaktiviert. Im Falle des Nichtubereinstimmens der beiden Versionsattribute erfolgt eine Fehlermeldung und es wird bei der Systeminitialisierung keine Verbindung zwischen beiden Teilrechnersystemen System A und System B hergestellt.
Das Ausfuhrungsbeispiel des erfmdungsgemaßen Verfahrens kann selbstverständlich analog auf verteilte Rechnersysteme mit mehreren Teilrechnersystemen angewendet werden. Hierzu gibt es auf jedem Teilrechnersystem eine Liste, die samtliche Softwareeinheiten eines Teilrechnersystems enthalt. So werden alle vorhandenen Listen nach kompatiblen Softwareeinheiten mit Hilfe des Versionsattributes durchsucht. Samtliche Ver- sionsattπbute werden miteinander verglichen. Gemäß dem Vergleichsergebnis werden entsprechende Reaktionen auf den Teilrechnersystemen ausgelost.

Claims

Patentansprüche
1. Verfahren zur Sicherstellung der Kompatibilität zwischen in zu einem verteilten Rechnersystem gehörenden Teilrech- nersystemen (System A, System B) aktivierten Softwareeinheiten, die jeweils einen Versionsstand von Softwarecode und Daten umfassen, während einer Systeminitialisierung mindestens eines solchen Teilrechnersystems, wobei folgende Schritte ausgeführt werden: a) nach Feststellung einer Inkompatibilitat zwischen einer auf einem ersten Teilrechnersystem aktivierten Softwareeinheit und wenigstens einer auf einem weiteren Teilrechnersystem aktivierten Softwareeinheit werden weitere auf den jeweiligen Teilrechnersystemen vorhandene nicht akti- vierte Softwareeinheiten auf Kompatibilität miteinander verglichen, b) im Falle einer sich aus dem Vergleich ergebenden Kompatibilität wird eine kompatible nicht aktivierte Softwareeinheit auf ihrem Teilrechnersystem aktiviert sowie die ent- sprechende zuvor aktivierte Softwareeinheit deaktiviert.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Systeminitialisierung bei einem Systemneustart und/oder bei einem Wiederanlauf des Systems durchgeführt wird.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß Versionsnummern der auf einem Teilrechnersystem vorhandenen Softwareeinheiten in einer Liste eingetragen sind, wobei die Versionsnummer einer aktivierten Softwareeinheit an erster Stelle der Liste gespeichert ist.
4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß die Versionsnummer einer Softwareeinheit durch Setzen eines Versionsattributes (GCS) in die Liste eingetragen wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die in der Liste ab der zweiten Stelle eingetragenen Versionsnummern von Soft- wareeinheiten gemäß ihres Aktualisierungsalters in der Liste aufsteigend sortiert sind.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß zur Aktivierung einer kompatiblen nicht aktivierten Softwareeinheit stets diejenige Softwareeinheit ausgewählt wird, die den jüngsten Versionsstand von den kompatiblen nicht aktivierten Softwareeinheiten aufweist.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Sicherstellung der Kompatibilität zwischen auf Teilrechnersystemen aktivierten Softwareeinheiten automatisch während der Systeminitialisierung mindestens eines solchen Teilrechnersystems durchgeführt wird.
8. Verfahren zur Datensicherung innerhalb eines mehrere Teilrechnersysteme (System A, System B) aufweisenden verteilten Rechnersystems, innerhalb dessen in jedem Teilrechner- system nach einer Softwareänderung eine Datensicherung angestoßen wird, die in den jeweiligen Teilrechnersystemen an im Datensicherungsablauf festgelegten Synchronisationsstellen synchronisiert wird, wobei in Abhängigkeit vom aktuellen Status des Datensicherungsablaufs die folgenden Schritte ausgeführt werden: a) in jedem Teilrechnersystem wird eine Datensicherung von Daten durchgeführt, auf die andere Teilrechnersysteme nicht zugreifen können, b) in jedem Teilrechnersystem wird eine Datenzugriffsblockie- rung aktiviert, c) in jedem Teilrechnersystem wird eine Datensicherung von Daten durchgeführt, auf die auch andere Teilrechnersystemen zugreifen können, d) die Datenzugriffsblockierungen werden deaktiviert.
9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, daß zur Synchronisierung der Datensicherung sich die Teilrechnersysteme an den Synchronisationsstellen darüber verständigen, daß die in einem Teilrechnersystem jeweils angestoßene Datensicherung einen zur Weiterführung der Datensicherung definierten Status erreicht hat.
10. Verfahren nach Anspruch 8 oder 9, dadurch gekennzeichnet, daß die Synchronisationsstellen durch zeit- liehe Abstände festgelegt werden.
11. Verfahren nach Anspruch 8 oder 9, dadurch gekennzeichnet, daß die Synchronisationsstellen in Form von im Softwarecode festgelegten Stellen implementiert sind.
12. Verfahren nach einem der Ansprüche 8 bis 11, dadurch gekennzeichnet, daß nach der Datensicherung der Versionsstand der gesicherten Daten im jeweiligen Teilrechnersystem hinterlegt wird.
13. Verfahren nach einem der Ansprüche 8 bis 12, dadurch gekennzeichnet, daß der Versionsstand der gesicherten Daten durch Setzen eines im jeweiligen Teilrechnersystem gespeicherten Versionsattributes (GCS) gespeichert wird.
14. Verfahren nach einem der Ansprüche 8 bis 13, dadurch gekennzeichnet, daß die auf den jeweiligen Teilrechnersystemen ablaufenden Datensicherungen von einer zentralen Stelle aus mittels einer Steuerungssoftware gesteuert werden.
15. Verfahren nach einem der Ansprüche 8 bis 14, dadurch gekennzeichnet, daß Informationen über abgewiesene Änderungen an den zu sichernden Daten wahrend der Datenzugriffsblockierung temporar einer Protokolldatei festge- halten werden, um die Änderungen an den Daten nach dem
Aufheben der Datenzugriffsblockierung vornehmen zu können.
16. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß es in einem Vermitt- lungssystem, das mindestens zwei Rechnersysteme (CP, SSNC) aufweist, angewendet wird.
EP01913625A 2000-02-23 2001-02-13 Verfahren zur sicherstellung der kompatibilität und verfahren zur datensicherung innerhalb eines mehrere teilrechnersysteme aufweisenden verteilten rechnersystems Withdrawn EP1261917A2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10008245 2000-02-23
DE10008245A DE10008245A1 (de) 2000-02-23 2000-02-23 Verfahren zur Sicherstellung der Kompatibilität und Verfahren zur Datensicherung innerhalb eines mehrere Teilrechnersysteme aufweisenden verteilten Rechnersystems
PCT/DE2001/000546 WO2001063408A2 (de) 2000-02-23 2001-02-13 Verfahren zur sicherstellung der kompatibilität und verfahren zur datensicherung innerhalb eines verteilten rechnersystems

Publications (1)

Publication Number Publication Date
EP1261917A2 true EP1261917A2 (de) 2002-12-04

Family

ID=7631966

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01913625A Withdrawn EP1261917A2 (de) 2000-02-23 2001-02-13 Verfahren zur sicherstellung der kompatibilität und verfahren zur datensicherung innerhalb eines mehrere teilrechnersysteme aufweisenden verteilten rechnersystems

Country Status (6)

Country Link
US (1) US20030163804A1 (de)
EP (1) EP1261917A2 (de)
CN (1) CN1426554A (de)
CA (1) CA2400810A1 (de)
DE (1) DE10008245A1 (de)
WO (1) WO2001063408A2 (de)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100718532B1 (ko) * 2005-08-13 2007-05-16 테크노세미켐 주식회사 반도체 제조용 감광성수지 제거제 조성물
US9471756B2 (en) * 2006-06-27 2016-10-18 Intuit Inc. Method and apparatus for authorizing a software product to be used on a computer system
JP2008243007A (ja) * 2007-03-28 2008-10-09 Fujitsu Ltd 情報処理装置、情報処理方法および情報処理プログラム
US9342298B2 (en) * 2013-03-14 2016-05-17 Microsoft Technology Licensing, Llc Application compatibility checking in a distributed computing environment
CN106201850B (zh) * 2015-04-29 2019-07-05 阿里巴巴集团控股有限公司 一种兼容性测试方法及装置
CN107977223B (zh) * 2017-11-20 2020-12-04 杭州迪普科技股份有限公司 一种配置兼容性检查方法及装置

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2251502B (en) * 1990-11-07 1995-06-14 Nonstop Networks Limited Data-loss prevention products
US5579509A (en) * 1991-02-08 1996-11-26 International Business Machines Corporation Apparatus and method for verifying compatibility of system components
US5410703A (en) * 1992-07-01 1995-04-25 Telefonaktiebolaget L M Ericsson System for changing software during computer operation
JP3343354B2 (ja) * 1993-05-05 2002-11-11 アップル コンピューター インコーポレーテッド コンピュータシステム中にある複数のモジュラーコンポーネント間に互換性如何を確認する方法ならびに装置
BR9402027A (pt) * 1993-05-28 1994-12-13 Xerox Corp Processo para gerenciar uma configuração e assegurar compatibilidade entre componentes num sistema de computação, e, processo para eliminar incompatibilidades entre software residente e software de migração num sistema de computador automatizado
US5761659A (en) * 1996-02-29 1998-06-02 Sun Microsystems, Inc. Method, product, and structure for flexible range locking of read and write requests using shared and exclusive locks, flags, sub-locks, and counters
US6175855B1 (en) * 1996-12-20 2001-01-16 Siemens Aktiengesellschaft Method for instantiating a class having different versions
US5970488A (en) * 1997-05-05 1999-10-19 Northrop Grumman Corporation Real-time distributed database system and method
US6195796B1 (en) * 1998-10-21 2001-02-27 Wildseed, Ltd. User centric source control
US6532588B1 (en) * 1998-10-21 2003-03-11 Xoucin, Inc. User centric program product distribution
US6601234B1 (en) * 1999-08-31 2003-07-29 Accenture Llp Attribute dictionary in a business logic services environment

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0163408A2 *

Also Published As

Publication number Publication date
CA2400810A1 (en) 2001-08-30
CN1426554A (zh) 2003-06-25
WO2001063408A3 (de) 2002-02-14
DE10008245A1 (de) 2001-09-06
US20030163804A1 (en) 2003-08-28
WO2001063408A2 (de) 2001-08-30

Similar Documents

Publication Publication Date Title
DE4235193C2 (de) Netzwerksystem und zugehöriges Softwareverwaltungsverfahren
DE69730449T2 (de) Erzeugung einer spiegeldatenkopie (bild) unter verwendung von referenzetiketten
DE60013658T2 (de) Fehlertolerante virtuelle Javamaschine
DE60306932T2 (de) Schnelle Datenbankreplikation
DE69907709T2 (de) Prozessüberwachung in einem rechnersystem
EP0807883B1 (de) Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen
DE4033336A1 (de) Verfahren zum erzeugen einer ausfallmeldung und mechanismus fuer ausfallmeldung
DE4216871A1 (de) Ausfuehrungsordnen zum sicherstellen der serienherstellbarkeit verteilter transaktionen
DE4305522C2 (de) Einrichtung zur rechnergestützten Diagnose eines aus Modulen bestehenden technischen Systems
DE69907852T2 (de) Hochverfügbare asynchrone Ein/Ausgabe für gruppierte Rechnersysteme
DE602004006224T2 (de) Verfahren und Vorrichtung zur Datensynchronisierung eines verteilten Datenbanksystems
DE69723500T2 (de) Datenqualitätsverwaltungssystem
DE69914568T2 (de) Vorrichtung, Verfahren und System zur Dateisynchronisierung in einem Fehlertoleranten Netzwerk
EP1701266A1 (de) Testvorrichtung zur Überprüfung einer Stapelverarbeitung
DE69927223T2 (de) Ausfallsicherheit eines Mehrrechnersystems
EP1261917A2 (de) Verfahren zur sicherstellung der kompatibilität und verfahren zur datensicherung innerhalb eines mehrere teilrechnersysteme aufweisenden verteilten rechnersystems
EP1080408B1 (de) Steuerungssystem zur steuerung der inbetriebnahme eines verteilten systems
EP4002098A1 (de) Verfahren zur bereitstellung der funktionalität von mehreren mikrodiensten und/oder der funktionalität von mehreren software-containern mittels einer cloud-infrastruktur, system, verwendungssystem, computerprogramm und computerlesbares medium
DE60108680T2 (de) Dynamische Regelsätze für erzeugte Logbücher in einem Netz
WO1999017192A1 (de) Konfigurierungsverfahren für datenverarbeitungsanlagen
DE602004012108T2 (de) Fernkonfigurationsmanagement eines Datanverarbeitungssystems
EP3705993B1 (de) System und verfahren zum auffinden und identifizieren von rechenknoten in einem netzwerk
EP0766488B1 (de) Verfahren zur Kopplung von Datenbearbeitungseinheiten, Verfahren zum Steuern einer Vermittlungsstelle, Datenbearbeitungseinheit, Steuerung und Vermittlungsstelle
EP1242852B1 (de) Vorrichtung und verfahren zur einbindung von automatisierungskomponenten
EP1376383A2 (de) Verfahren zur Verarbeitung von Ein- und Ausgaben für statistische Analysen und Verfahren zur Bereinigung von Redundanzen

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20020813

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20060711