DE10048942A1 - Verfahren und System zur Wartung von Software über ein Netz - Google Patents

Abstract

Die vorliegende Erfindung bezieht sich auf ein Verfahren und ein System zur Wartung von Softwareprodukten, die über ein Netz auf Client-Systemen (12) installiert wurden. DOLLAR A Es läßt sich eine Hierarchie von Overlay-Datenspeichern (20, 22) vorzugsweise bereitstellen, beispielsweise auf "Länderebene" und auf "Systemebene". Datenspeicher auf Länderebene können eine Landessprache, Codeseitendefinitionen und andere gebräuchliche Anpassungen und Zusätze, die für die Mehrzahl an Clients in einem Land spezifisch sind, unterstützen. DOLLAR A An ein System oder eine Gruppe von Systemen wird ein eigener Befehl ausgegeben. Dieser Befehl durchläuft die Datenspeicherhierarchie, entweder von unten nach oben oder umgekehrt, wobei lokale Daten zentrale Daten überschreiben, und erstellt eine Dateiliste. Diese Liste enthält für jede Datei im Datenspeicher die Speicherstelle, von der sie später heruntergeladen wird.

Description

1. HINTERGRUND DER ERFINDUNG 1.1 ANWENDUNGSBEREICH DER VORLIEGENDEN ERFINDUNG

Die vorliegende Erfindung bezieht sich auf ein Verfahren und ein System zur Wartung von Softwareprodukten, die in mehreren dezentral installierten Client-Computersystemen in einem Netz, in dem sie miteinander verbunden sind, implementiert sind.

1.2 BESCHREIBUNG UND NACHTEILE DES STANDES DER TECHNIK

Zum Zweck einer eindeutigen Definition des Gegenstands der vorliegenden Erfindung umfaßt der Begriff 'Software-Wartung' alle Aufgaben, die zur Aufrechterhaltung einer Anwendungssoftware eines Benutzers oder einer Systemsoftware in einem für die herrschenden Anforderungen geeigneten Status, der vom Unternehmen oder einer Privatperson festgelegt wurde, um die jeweiligen (geschäftsbezogenen) Ziele zu erreichen, dienen. Diese Wartung umfaßt die Installation neuer Softwareprodukte auf einem Client-System, die Aktualisierung einer alten Version zu einer neuen Version des gleichen Softwareprodukts, die Durchführung von Aufgaben zur Anpassung der Software an das Client-System und die Integration beliebiger Client-spezifischer Zusatzprogramme wie Benutzerausgänge, die logisch mit dem Softwareprodukt verknüpft sind und die im Client-System gewartet werden müssen.

Auf dem Stand der Technik gibt es zahlreiche unterschiedliche Verfahren des oben genannten Verfahrens zur Software-Wartung. Ein spezieller Aspekt, der sich auf eine bestimmte Untergruppe der genannten Mehrzahl an Verfahren konzentriert, ist, daß sich das Verfahren und das System gemäß der vorliegenden Erfindung nur mit solchen Lösungen beschäftigt, die sich über ein Netz bereitstellen lassen, das die Vielzahl an Client-Systemen mit einem Server-System eines Anbieters eines zu wartenden Softwareproduktes verbindet.

Im allgemeinen ist es eine schwierige Aufgabe, ein bestehendes Softwareprodukt auf einem Client-System zu aktualisieren, wenn das Softwareprodukt Programme enthält, die im Computersystem mehrere Prozesse erzeugen, oder wenn die Prozesse sehr viele kundenspezifische logische oder physikalische Schnittstellen enthalten, die jedesmal neu konfiguriert werden müssen, wenn das Produkt aktualisiert werden soll.

Darüber hinaus steigt der Arbeitsaufwand, der erforderlich ist, um eine neue Version des Softwareprodukts an die Benutzeranforderungen auf dem Client-System anzupassen, wenn die Anpassung des Produkts schwierig ist oder wenn wichtige Programmänderungen wie beispielsweise Benutzerausgänge, die von den Client-Mitarbeitern manuell einprogrammiert und in die alte Version des Softwareprodukts integriert wurden, in einem Update eines bestimmten Softwareprodukts neu konfiguriert und integriert werden müssen.

Aus diesem Grund ist es eine allgemeine Herausforderung jeder Software-Installation oder Software-Wartung, den Wartungsaufwand so gering wie möglich zu halten. Zu beachten ist, daß normalerweise beide Parteien, der Kunde und der Software-Anbieter an dieser Wartung beteiligt sind.

Wenn ein Software-Anbieter sehr viele Kunden hat, die mit der Software des Anbieters arbeiten, ist die Verpflichtung, den Kunden bei der Installation einer neuen Version des Softwareprodukts und bei der Anpassung der Software an seine individuellen Bedürfnisse zu unterstützen, eine große Belastung für den Software-Anbieter. Im allgemeinen muß der Anbieter Mitarbeiter, beispielsweise Systemprogrammierer, bereitstellen, die das verkaufte Softwareprodukt gut kennen und in der Lage sind, die Software an die individuellen Bedürfnisse des Kunden anzupassen. Dieser Aufwand wird umso größer, je komplexer das Softwareprodukt ist und je wichtiger es für den Kunden ist, einen ungestörten Arbeitsfluß in seinem Unternehmen zu schaffen.

Das US-Patent 5,421,009 beschreibt ein Verfahren zur Ferninstallation von Software über ein Computernetzwerk. Dabei kann ein Benutzer interaktiv jedes entfernte Computersystem als Ziel für die Software-Installation auswählen oder eine Datei bereitstellen, die eine Liste aller entfernten Zielcomputersysteme enthält. Zuerst wird geprüft, ob das entfernte System für den Zugriff über das Netz verfügbar ist. Danach werden einige betriebssystemspezifische Standardprüfungen durchlaufen, die Hardware-Ressourcen, insbesondere der Speicherplatz, werden geprüft, und wenn alle Voraussetzungen erfüllt sind, werden alle entfernt installierten Dateien zu einem einzelnen Datenstrom kombiniert, der über das Netz an das entfernte Computersystem übertragen wird, wo der Datenstrom wieder in die ursprünglichen Einzeldateien zerlegt wird. Nach der Speicherung der Dateien muß die neue Programmversion jedoch noch an die kundenspezifische Umgebung angepaßt werden, wozu die oben angeführte Arbeit der Systemprogrammierer erforderlich ist. Sobald diese Arbeit abgeschlossen ist, kann die neue Programmversion zumindest zu Testzwecken ausgeführt werden.

Ein grobes Schema dieser Art von Software-Wartung nach dem Stand der Technik ist aus der Darstellung in Fig. 1A ersichtlich. Abgebildet ist die Datenbank 10 eines Software- Anbieters, in der zahlreiche Software-Produkte gespeichert sind. Wenn ein Endbenutzer eines Client-Systems 12 eine neue Version eines Software-Produkts X, das bereits in einer älteren Version auf dem Client-System existiert, installieren möchte, fordert das Client-System während der genannten Aktualisierung einen Download der dazu benötigten Dateien an.

Dieser Schritt des Anforderns ist in der Abbildung durch einen einzelnen Pfeil 14 dargestellt. Danach wird der Download selbst durchgeführt, der in der Abbildung durch mehrere Pfeile 16 dargestellt ist, und die neue Version wird auf dem Client-System installiert. Die Pfeile veranschaulichen den dazu erforderlichen Netzwerkverkehr. Wenn anstatt vollständiger Dateien Deltainformationen übertragen werden, reduziert sich der Netzwerkverkehr beträchtlich.

Das beschriebene Installationsverfahren verringert den Aufwand für Systemprogrammierer, da die Software installiert werden kann, ohne auf dem Client-Computersystem zuerst ein Download-Programm installieren zu müssen und weil ein Benutzer entweder jedes Client-Computersystem für die beabsichtigte Software-Installation interaktiv auswählen oder eine Stapeldatei bereitstellen kann, die eine Auflistung aller Zielcomputersysteme enthält.

Allerdings kann dieses Verfahren nicht den oben angeführten großen Aufwand 11 des Systemprogrammierers reduzieren, jedoch in der Umgebung des Produktanbieters zentralisieren und selektiv an die Zielsysteme aussenden. Dies würde jedoch zu einem umfangreichen Datenverkehr auf dem Netz führen, der für den 'Push'-Prozeß, durch den die individuell angepaßte Software an die zahlreichen Client-Systeme übertragen werden könnte, erforderlich ist.

1.3 ZIELE DER VORLIEGENDEN ERFINDUNG

Ein Ziel der vorliegenden Erfindung besteht darin, den erforderlichen Arbeitsaufwand zu reduzieren, um die Softwareprodukte an mehreren Client-Standorten eines Netzes verfügbar zu halten, ohne daß dadurch der Datenverkehr im Netz zunimmt.

2. ZUSAMMENFASSUNG UND VORTEILE DER VORLIEGENDEN ERFINDUNG

Dieses Ziel der vorliegenden Erfindung wird durch die in den beigefügten unabhängigen Ansprüchen beschriebenen Eigenschaften erreicht. Weitere vorteilhafte Anordnungen und Ausführungen der vorliegenden Erfindung werden in den jeweiligen Unteransprüchen beschrieben.

Wenn man das Grundprinzip der vorliegenden Erfindung zusammenfassen will, so läßt sich sagen, daß Softwareprodukte installiert und in Softwarespeichern, die über ein Netz an die Zielsysteme bereitgestellt werden, gewartet werden können. Diese Vorgehensweise ähnelt einer Gruppe von Handelsgeschäften, in denen die Softwareprodukte als Handelsware angeboten werden.

Das Verfahren und das System zur Softwarewartung gemäß der vorliegenden Erfindung läßt sich in einem einzelnen befehlsorientierten Prozeß realisieren. Dadurch wird der Arbeitsaufwand zur Softwarewartung, der normalerweise lokal entsteht, zentralisiert und automatisiert. Aus diesem Grund wird die Installation von Programmen zur Fehlerbehebung, Testprogrammen und einige Arbeiten zur individuellen Anpassung an zentrale Stellen übertragen, d. h. an die Anbieter der genannten Datenspeicher.

Individuelle Anpassungen auf lokaler Ebene, Programme zur Fehlerbehebung und Änderungen werden an sogenannte lokale Overlay-Speicher übertragen, die nachfolgend näher beschrieben werden. Aus der Perspektive eines Zielsystems werden die Aktivitäten zum Laden der Software, die Einbettung in die Produktionsaktivitäten, eventuelle Wiederholungsaktivitäten zum erneuten Ausführen der alten Programmversion im Fall von Produktionsstörungen, Aktivitäten im Zusammenhang mit dem Auslauf eines Produkts sowie weitere Aktivitäten auf einzelne Befehle reduziert. Diese Befehle können entweder an ein einzelnes System oder an eine Gruppe von Systemen gesendet werden. Entsprechend dem Grundprinzip der vorliegenden Erfindung wird eine Gruppe von Softwareprodukten in einem zentralen Speicher angeboten.

Dieses Produktangebot kann über eine zentrale Stelle, die Teil eines Unternehmens ist, oder über einen externen Anbieter erfolgen. Je nach Art der angebotenen Software und den zu bedienenden Kunden können solche zentralen Speicher Softwareprodukte enthalten, die aufeinander abgestimmt sind, eine sehr geringe Fehleranfälligkeit aufweisen und zusammen getestet werden. Jede Aktualisierung eines angebotenen. Produkts ist als eigenständiges und komplettes Neuprodukt vom Datenspeicher lieferbar. Die alten Versionen können weiterhin angeboten werden, um auch solche Kunden bedienen zu können, die die neuesten Programme zur Fehlerbehebung nicht verwenden können. Dabei sind Erkennungsverfahren möglich, die feststellen, ob identische Daten mehrmals im Datenspeicher vorhanden sind, und diese ggf. beseitigen. Die Verzeichnisstruktur, in der die Produkte im Datenspeicher organisiert sind, müssen vorzugsweise das Produkt und seinen Lieferstatus, d. h. seine Versionsnummer, kennzeichnen.

Mit diesem Erkennungsverfahren kann eine versionsspezifische Auswahl von Dateien oder Daten physikalisch an die verschiedenen Datenspeicher gesendet werden.

Wird darüber hinaus ein Softwareprodukt in zwei verschiedenen Versionen angeboten, beispielsweise 2.0 und 2.1, umfaßt es häufig eine Untergruppe von Dateien, die identisch bleiben, obwohl sich die Produktversionen unterscheiden. Diese identischen Daten stehen weiterhin für die Verwendung durch den Kunden zur Verfügung, wenn sie bereits auf dem Client- System existieren. Gemäß der vorliegenden Erfindung wird dies durch einen Vergleich bestehender Dateien auf einem Client- System mit bestehenden Dateien in einer Liste, die auf der Grundlage der Speicherhierarchie erstellt wurde, erreicht.

Um darüber hinaus die Belastung des Netzes sowie die Auswirkungen von technischen Störungen auf ein Mindestmaß zu beschränken, können zentrale Datenspeicher vollständig oder teilweise an dezentrale Stellen, sogenannte Schattenspeicher, kopiert werden. Produkte, die in Schattenspeichern gespeichert sind, müssen mit den im zentralen Speicher gespeicherten Produkten identisch sein. Individuelle Anpassungen, Programme zur Behebung lokaler Störungen und Änderungen eines Softwareprodukts werden in sogenannte Overlay-Speicher gestellt. Dabei läßt sich eine Hierarchie von Overlay-Speichern aufbauen, beispielsweise auf 'Landesebene' und 'Systemebene'. Datenspeicher auf Landesebene beispielsweise unterstützen einzelne Sprachen, bestimmen die geeignete Tastaturbelegung und definieren weitere Anpassungen, die für die Mehrzahl an Kunden in einem bestimmten Land von Bedeutung sind. Sie enthalten darüber hinaus auch einige spezifische Deltainformationen bezüglich der zentralen Datenspeicherinformation, beispielsweise sprach- oder landesspezifische Daten.

Datenspeicher auf Systemebene können lokale Konfigurationen sowie Anpassungen, die für ein spezielles Zielsystem oder eine Gruppe davon eingerichtet wurden, enthalten. Werden die Daten aus zentralen Datenspeichern nicht in die Zielsysteme verschoben, können Ausschließungslisten, auf denen diese Daten angegeben werden, angelegt und anderswo in der Datenspeicherhierarchie hinverschoben werden, beispielsweise in Overlay-Datenspeicher.

Unter Einsatz der oben beschriebenen Systemstruktur kann eine Produktinstallation als Bestandteil der Softwarewartung gemäß der vorliegenden Erfindung aussehen wie folgt:

Zuerst ist ein Vorbereitungsschritt erforderlich, um die Datenspeicher mit den betreffenden Daten zu 'füllen'. Dies ist mit einem Tool gemäß der vorliegenden Erfindung möglich, das die hierarchischen Overlay-Verzeichnisse anlegt und die Dateien auswählt, die die Konfigurations- und Anpassungsdaten enthalten, und sie in die hierarchische Overlay-Struktur einfügt. Diese Anpassungen und Änderungen können so erfolgen, daß sie entweder für alle Produktversionen oder nur für eine Entwicklungsstufe gültig sind.

Diese Arbeit muß unter Beteiligung der Systemprogrammierer erfolgen, die die Anpassung und Ländereinstellung gemäß dem Stand der Technik durchgeführt haben. Der große Vorteil der in diesem Dokument beschriebenen Softwarewartung ist, daß ein Großteil des Aufwands, der zur Anpassung jedes beliebigen Anwendungsprogramms erforderlich ist, nur einmal aufgebracht werden muß. Die Ergebnisse lassen sich im oben angeführten lokalen Datenspeicher 20 speichern und stehen mehreren Endbenutzern zur Verfügung. Auf diese Weise wird die Anpassung vereinfacht der damit verbundene Aufwand verringert.

Wird ein Softwareprodukt gemäß obiger Beschreibung zentral in einem Datenspeicher bereitgestellt, liest der Systemadministrator/Programmierer die Produktdokumentation und stellt fest, ob für den Endbenutzer oder die Endbenutzergruppe, für die er zuständig ist, eine Anpassung erforderlich ist. Wenn ja, entscheidet er, ob diese Anpassung auf die gleiche Weise für mehrere Endbenutzersysteme erfolgen kann, oder ob für jedes System eine separate Anpassung erforderlich ist.

Abhängig von dieser Entscheidung stellt er fest, welche hierarchische Overlay-Ebene im Datenspeicher erforderlich ist, um einen Pull-Prozeß gemäß der vorliegenden Erfindung zu beginnen. In diesem Pull-Prozeß werden die geeigneten Daten aus dem Datenspeicher ausgewählt, um sie für die Endbenutzersysteme herunterzuladen.

In einer für einen Mainframe angepaßten Implementierung des Tools, beispielsweise für das Betriebssystem VM, können bis zu 255 parallele Umgebungen für ein Produkt auf einem System unterstützt werden. Das bedeutet, daß mehrere parallele Eingabehierarchien mit unterschiedlichen hierarchischen Overlays verarbeitet werden können. Jede parallele Umgebung wird vollkommen separat verarbeitet.

Im einzelnen kann die Installation auf Zielsystemen exemplarisch wie folgt durchgeführt werden:

An ein System oder eine Systemgruppe wird der Befehl STORE ausgegeben. Dieser Befehl durchläuft die Hierarchie des Datenspeichers - von der lokalen zur obersten Ebene oder umgekehrt überschreiben lokale Daten zentrale Daten - und erstellt eine Dateienliste. Diese Liste gibt für jede Datei die genaue Stelle im Datenspeicher an, wo sie für das spätere Herunterladen zu finden ist.

Eine Listenverarbeitung wird ebenfalls am Zielobjekt auf dem Zielsystem ausgeführt. Falls Zielobjekte wie Verzeichnisse oder Dateien nicht existieren, können sie automatisch über Ausgänge erstellt werden.

Beide Listen werden miteinander verglichen, und es wird entschieden, welche Dateien heruntergeladen werden müssen.

Die Listenverarbeitung bestimmt außerdem, ob sich Dateien des Produkts bereits auf dem Zielobjekt befinden, jedoch dort zu einem anderen Produkt gehören, oder ob bereits Produktdateien existieren, die keinem Produkt zugeordnet sind. Letztere können dem Produkt zugeordnet werden.

Beim Mischen dieser Listen überschreiben die Daten, die sich auf näher am Zielsystem gelegenen Hierarchieebenen befinden, solche Daten, die sich auf weiter vom Zielsystem entfernten Hierarchieebenen befinden. Das Tool, mit dem das Verfahren der vorliegenden Erfindung in einem Ausführungsbeispiel für eine Mainframe-VM-Architektur implementiert wird, sucht von der obersten Ebene aus nach unten oder vom lokalen Shadow oder von der zentralen Ebene im Datenspeicher bis zur lokalen Ebene im Datenspeicher. In anderen Architekturen kann diese Sequenz jedoch anders aussehen.

Der nächste Schritt ist die Zuordnung inaktiver Namen zu den Dateien. Diese Namen erhalten die Dateien, nachdem sie heruntergeladen wurden oder wenn sie in einem inaktiven Format belassen werden, um später aktiviert zu werden, beispielsweise für einen sogenannten Backout, der an späterer Stelle beschrieben werden wird, oder im Fall einer Produktdeaktivierung.

Danach wird in Übereinstimmung mit einem bevorzugten Ausführungsbeispiel der Softwarewartung gemäß der vorliegenden Erfindung der Deltawert von der Hierarchie des Datenspeichers in das Zielobjekt geladen und mit inaktiven verborgenen Namen gespeichert. Darüber hinaus läßt sich der Speichervorgang abbrechen, und Änderungen in der Eingabehierarchie können erfolgen. Ein späterer Speicherbefehl stellt fest, welche Änderungen zwischenzeitlich vorgenommen wurden, und verschiebt weiterhin Daten, wobei bereits verschobene Daten nicht mehr kopiert werden.

Für den Fall, dass Netzwerkunterbrechungen eintreten, wird eine Wiederholungsschleife gestartet. Nach einer erfolgreichen Speicherung wird eine Protokolldatei in das Zielobjekt geschrieben. Diese enthält für jede Datei 'Dateiinformationen' wie Uhrzeit, Datum, Größe, aktiven Name und alle inaktiven Namen, die sie hat oder nach abgeschlossener Speicherung, nach einer Produktdeaktivierung oder nach Austausch durch eine neue Dateiversion erhalten wird, sowie den Speicherort, von dem sie kopiert wurde.

Der Anforderer des Befehls STORE wird über den Fortschritt und die Ergebnisse der Aktivitäten informiert. Nur die Vorbereitung und die Speicherung benötigen Zugriff auf die Hierarchie des Datenspeichers. Sie werden vor dem geplanten Cutover ausgeführt und beeinflussen die Benutzer nicht, tragen jedoch zur Netzwerkauslastung bei.

Die Aktivierung oder das Cutover in die Produktion ist der nächste logische Schritt. Die Dateien, die zuvor mit inaktiven Namen benannt wurden, werden mit aktiven Namen umbenannt. Bereits existierende Dateien, die durch eine neue Version ersetzt werden, werden zuvor in den inaktiven 'Backout'-Namen umbenannt. Das gleiche geschieht mit gelöschten Dateien.

Die genannte Aktivierung hat zahlreiche betriebssystemspezifische Aspekte. In der VM-Implementierung des vorliegenden Beispiels werden einige Dateien aktualisiert, die das Produkt für die Benutzer bekannt und verfügbar machen. Produktteile, die über einen gemeinsamen Speicher verfügbar sind, werden in diesen Speicher geladen. Für andere Betriebssysteme sind andere Zusatzaktivitäten erforderlich, damit die Aktivierung abgeschlossen werden kann.

Die Prinzipien der vorliegenden Erfindung umfassen die Bereitstellung einiger Wiederherstellungsprozesse, darunter beispielsweise BACKOUT, mit denen bereits ausgeführte Aktivierungsschritte zurückgeführt werden, falls ein Schritt fehlerhaft ist, oder wenn der Endbenutzer mit den neuen Produkten nicht zufrieden ist, beispielsweise im Fall von Produktionsfehlern:

Wenn das Produkt in der Produktion ausfällt, läßt sich die zuletzt angenommene Produktversion - Beschreibung siehe unten - über den Befehl BACKOUT wiederherstellen. Dateien, die durch neue Versionen ersetzt wurden, sowie gelöschte Dateien werden wieder in ihre aktiven Namen umbenannt, während die neuen in inaktive Namen umbenannt werden. Möglicherweise sind auch betriebssystemspezifische Aktivitäten erforderlich. Ein Beispiel hierfür ist die Aktualisierung eines gemeinsam genutzten Speichers.

In Übereinstimmung mit einem weiteren Aspekt der vorliegenden Erfindung wird ein Produkt, wenn es zur Zufriedenheit aller ausgeführt werden kann, angenommen. Das heißt, dass alle inaktiven Daten, die zu BACKOUT-Zwecken 'einsatzbereit' gehalten werden, gelöscht werden. Die Annahmestufe legt fest, was wieder verfügbar ist, wenn ein BACKOUT-Befehl ausgegeben wurde, nachdem einige andere Speicher- und Aufrufaktivitäten erneut durchgeführt wurden. ACCEPT ist daher häufig der erste Schritt, bevor ein Produkt auf einem System 'wiederaufgefrischt' wird.

Ein weiterer INACTIVATE-Befehl ist eine eher seltene Maßnahme. Normalerweise befindet sich ein Produkt in einem Zielobjekt und bleibt dort, solange es aktualisiert und gewartet wird. Über die oben beschriebenen Aktivitäten Speichern, Aktivieren, Annehmen ersetzen die neuen Teile die alten. Nur wenn ein Produkt vollständig aus einem System entfernt werden soll, muß es inaktiviert werden. Das bedeutet, dass der Benutzer nicht länger Zugriff auf das Produkt hat, das Produkt aber weiterhin inaktiv verfügbar ist. Stellt es sich später heraus, dass es noch einmal benötigt wird, läßt es sich über den Befehl ACTIVATE schnell erneut aktivieren. Mit dem Befehl INACTIVATE lassen sich also Produkte auf sichere Weise herauslösen. Außerdem hat der Befehl zahlreiche betriebssystemspezifische Funktionen.

REMOVE

Bedeutet echtes Entfernen der Dateien eines Produktes aus einem System.

Das Verfahren der vorliegenden Erfindung ermöglicht es, mehrere Produkte auf einem Zielobjekt zu installieren, indem für die Produktspeicherung und -aktivierung inaktive Namen bereitgestellt und BACKOUTS und Produktinaktivierungen durchgeführt werden. Andere Verfahren beruhen auf dem sogenannten Flip-Flop-Prinzip, d. h. auf einer Umschaltung zwischen aktiven und inaktiven Verzeichnissen, und lassen sich genauso in das Verfahren der vorliegenden Erfindung integrieren.

Es ist zu beachten, dass in Übereinstimmung mit einem bevorzugten Aspekt der vorliegenden Erfindung nur der Befehl STORE, mit dem Dateien vom Netz heruntergeladen werden, ein gewisses Maß an Konnektivität benötigt. Für alle anderen Befehle ist keine Netzwerkverbindung erforderlich. Im allgemeinen lassen sich alle bisher beschriebenen Funktionen mit einem einzigen vom Client eingegebenen Befehl ausführen.

Dank der oben beschriebenen Funktionen wird die Wartung von Software selbst bei äußerst komplexen Softwaresystemen, die aus mehreren Einzelprogrammen bestehen, die zu einem maßgeschneiderten Gesamtpaket für einen bestimmten Zweck zusammengestellt wurden, einfacher und die Geschäftsrisiken und der Netzwerkverkehr geringer.

Es wird darauf hingewiesen, dass viele der oben beschriebenen Funktionen der vorliegenden Erfindung unabhängig voneinander ausgeführt werden können und im Vergleich zum Stand der Technik spezielle Vorteile bieten. Werden diese Funktionen kombiniert, summieren sich in den meisten Fällen ihre Vorteile.

3. KURZE BESCHREIBUNG DER ZEICHNUNGEN

Die vorliegende Erfindung wird anhand von bevorzugten Ausführungsbeispielen veranschaulicht und ist nicht auf die Ausführung in den beiliegenden Zeichnungen beschränkt.

Fig. 1A, B ist eine schematische Darstellung, die das Verfahren zur Wartung von Software gemäß der vorliegenden Erfindung veranschaulicht und mit dem Stand der Technik vergleicht.

Fig. 2 ist eine schematische Darstellung der Dateisystemstruktur im Lager des Softwareanbieters, was durch die in Fig. 1B abgebildeten Datenspeicher (grob) dargestellt wird.

Fig. 3 ist eine schematische Darstellung gemäß Fig. 2 eines mittelgroßen Lagers.

Fig. 4 ist eine schematische Darstellung gemäß Fig. 3 des lokalen Lagers.

Fig. 5A, B, C zeigen ein Blockdiagramm mit den wesentlichen Schritten, die während einer Aktualisierung eines von einem Softwareanbieter angebotenen Produktes X unter Anwendung des Verfahrens zur Wartung von Software gemäß der vorliegenden Erfindung durchgeführt werden.

4. BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSBEISPIELE

Fig. 1B enthält eine zusammenfassende Übersicht, die einige grundlegende Aspekte eines ersten bevorzugten Ausführungsbeispiels der vorliegenden Erfindung wiedergibt und beschreibt, was in der gleichen Situation wie oben beschrieben passiert, während ein Vergleich mit dem Stand der Technik stattfindet.

Das Client-System 12 wird mit einer Gruppe von drei Listen gemäß der vorliegenden Erfindung bereitgestellt, wobei jede Liste angibt, welche Dateien in jedem der Datenspeicher der Hierarchie vorhanden sind.

Das Tool der vorliegenden Erfindung, das auf einem Client- System gestartet wurde, greift zuerst auf einen geografisch und logisch verbundenen lokalen Datenspeicher 20 zu, der einem Softwareanbieter gehört. Ein Vergleich zwischen der Bestandsliste und der Liste der im Client-System bereits vorhandenen Dateien aus der alten Version des Produktes X ergibt, welche Dateien heruntergeladen werden müssen. Häufig werden aus dem lokalen Datenspeicher Dateien, die zumeist der neuen Version angehören, heruntergeladen. In diesen heruntergeladenen Dateien sind die meisten Änderungen und kundenspezifischen Anpassungen bereits enthalten. Danach greift das Client-System auf den mittleren Datenspeicher 22 zu, wo die Auswahl wiederholt wird und sich beispielsweise einige für das Produkt X relevante länderspezifische Dateien herunterladen lassen.

Zum Schluß wird auf den obersten Datenspeicher 24 zugegriffen, und die verbleibenden Dateiinformationen werden auf ähnliche Weise in das Client-System heruntergeladen.

Angenommen, der lokale Datenspeicher befindet sich, geografisch gesehen, nicht weit vom Client-System entfernt, so läßt sich der Netzwerkverkehr gemäß der vorliegenden Erfindung reduzieren, da der Großteil des Netzwerkverkehrs lokal zwischen dem lokalen Datenspeicher 20 und dem Client- System 12 erfolgt. Für die Übertragung der Dateien aus dem mittleren Datenspeicher 22 bzw. aus dem oberen Datenspeicher 24 ist nur ein geringer Netzwerkverkehr erforderlich.

Nähere Einzelheiten zur genannten Verarbeitung werden später in bezug auf die Fig. 5A, 5B und 5C beschrieben. Diese Zeichnungen veranschaulichen eine ähnliche Methode, die jedoch auf einem anderen Steuerfluß beruht, um den flexiblen Anwendungsbereich der vorliegenden Erfindung zu demonstrieren.

Fig. 2 zeigt eine beispielhafte Dateisystemstruktur, die das Lager des Softwareanbieters und der darin enthaltenen Softwareprodukte für die oberste Ebene darstellt, d. h. für den zentralen Datenspeicher. Eine Untergruppe der Produkte X, Y und Z ist hier abgebildet. Für ein Produkt X werden die Programmversionen 1.0, 1.1 und 1.2 angeboten. Für ein Produkt Y werden die Versionen 5.0, 5.1 und für ein Produkt Z die Versionen 3.0, 3.1 und 4.0 angeboten. Die Dateien werden logisch voneinander getrennt in einer Dateisystemstruktur gespeichert, so dass die lieferbaren Dateien in einem Verzeichnis gespeichert werden, das die Versionsnummer wiedergibt. Wurde eine Datei bei einem Versionswechsel nicht aktualisiert, muß sie im abgebildeten Dateisystembaum nur einmal gespeichert werden. Da vom beispielhaften Softwareanbieter beabsichtigt ist, dass in jedem versionsspezifischen Verzeichnis eine vollständige Dateigruppe heruntergeladen werden kann, wäre es vorteilhaft, einige logische Verknüpfungen zur Speicherstelle der physikalisch existierenden Datei herzustellen, anstatt identische Dateien an mehreren Speicherorten im Dateisystem zu speichern. Diese 'Alias'-Funktion ist auf dem gegenwärtigen Stand der Technik bereits bekannt.

In Fig. 3 wird eine ähnliche Darstellung für den mittleren Datenspeicher gegeben, die auch die im Lager des gleichen Softwareanbieters vorhandenen Produkte enthält.

Entsprechend den Grundsätzen der vorliegenden Erfindung können in diesem Software-Datenspeicher auf der mittleren Ebene den Kunden beispielsweise länderspezifische Daten in Form von Programmkonfigurationsdateien angeboten werden, die beispielsweise die Landessprache, den Landesnamen, die Landesvorwahl oder landesspezifische Fehlerbehebungen berücksichtigen.

Vorzugsweise könnte für jede der angebotenen Programmversionen - beispielsweise werden für das Produkt X die Versionen 1.1 und 1.2 angeboten - auf ein spezifisches Verzeichnis zugegriffen werden, das die Dateien enthält, die zur Aktualisierung der alten Version kopiert werden müssen, wenn die betreffende ältere Version bereits auf dem Zielsystem vorhanden ist. Um beispielsweise auf die Version 1.1 aufzurüsten, ist ein Zugriff auf zwei Verzeichnisse möglich: eines, auf das zugegriffen werden muß, wenn ein Client-System von Version 1.0 auf Version 1.1 aufgerüstet werden soll, und ein zweites, auf das zugegriffen werden muß, wenn der Client von einer Version 1.05 auf eine Version 1.1 aufrüsten möchte. Entsprechende Informationen werden in Fig. 3 für die im Lager angebotene Version 1.2 gegeben.

Für Produkt Y und Produkt Z werden entsprechende Verzeichnisse zur Verfügung gestellt, die jedoch in der Zeichnung zum Zweck einer einfacheren Darstellung nicht abgebildet sind.

Fig. 4 enthält eine ähnliche Darstellung für den lokalen Datenspeicher, in der das Lagerdateisystem des Softwareanbieters schematisch abgebildet ist. Die Dateisystemstruktur ist mit dem in Fig. 3 abgebildeten identisch, außer daß Produkt Y nicht vorhanden ist, da für Produkt Y auf dieser Ebene keine Dateien vorhanden sind. In den für die Produkte X und Z abgebildeten Verzeichnissen sind jedoch Dateien gespeichert, die vorzugsweise lokale Anpassungen enthalten würden, die auf das betreffende Client- System oder auf mehrere Client-Systeme einer Client- Systemgruppe anwendbar wären. Darüber hinaus sind gruppenspezifische Änderungen und Fehlerbehebungen als Dateien in den jeweiligen Verzeichnissen gespeichert. Je nach Einzelfall umfassen die im lokalen Datenspeicher gespeicherten Dateien vorzugsweise bereits individuelle Konfigurationsdaten, benutzerspezifische Änderungen wie Benutzerausgänge, die sich speziell auf eine bestimmte Endbenutzer-Untergruppe beziehen. Die in diesen Dateien gespeicherten Informationen sind in bezug auf die Dateiensammlung im zentralen Datenspeicher Deltainformationen.

In anderen Worten, alle von einem Systemprogrammierer bereits durchgeführten erforderlichen Einzelschritte im Zusammenhang mit einer früheren Anpassung und Änderung können ohne nennenswerten zusätzlichen Programmieraufwand wiederverwendet werden.

Außerdem kann auf diese Weise ein Systemadministrator eine Aktualisierung vornehmen, die an eine betreffende Mehrzahl an Endbenutzern gerichtet ist.

Für die Produkte Y und Z werden ähnliche Dateien angeboten, die jedoch zum Zweck einer einfacheren Darstellung ebenfalls nicht in der Zeichnung abgebildet sind.

Wie aus der Darstellung eindeutig hervorgeht, ist das Auffüllen der Unterdatenspeicher und lokalen Datenspeicher von spezifischen Anforderungen abhängig, die durch eine willkürlich ausgewählte Situation vorgegeben sind. Somit ist je nach Organisation und Systemumgebung eine Vielzahl verschiedener Möglichkeiten zum Auffüllen der Hierarchie mit Dateien vorstellbar.

Wir betrachten nun Fig. 5A. Hier wird eine typische Aktualisierung in Übereinstimmung mit der vorliegenden Erfindung beschrieben, die die Einzelaspekte der vorliegenden Erfindung sowie vorteilhafte Optionen für eine VM- Betriebssystemumgebung darlegt. Andere Umgebungen wie beispielsweise UNIX oder Windows sind ebenfalls möglich. Die oben beschriebene Vorbereitung zum Auffüllen der Datenspeicher muß aber abgeschlossen sein.

In einem ersten Schritt 110 entscheidet der Benutzer eines Produktes X, eine Aktualisierung von Version 1.1, die auf seiner Hardware-Plattform vorhanden ist, auf Version 1.2 vorzunehmen. Im beschriebenen bevorzugten Ausführungsbeispiel der vorliegenden Erfindung bittet der genannte Endbenutzer einen für die Softwarewartung verantwortlichen Systemoperator, die gewünschte Aktualisierung vorzunehmen. Auf diese Weise verwendet er die Softwarewartungsmethode gemäß der vorliegenden Erfindung, um die beabsichtigte Aktualisierung über einen Ladevorgang im Netzwerk, mit dem das Computersystem des Endbenutzers verbunden ist, vorzunehmen. Das heißt, der Systembenutzer geht zunächst online.

In einem nächsten Schritt 120 verwendet der Systembenutzer den Befehl MOUNT, um die Datenspeicherhierarchie zu durchlaufen und eine benötigte Festplatte auf die erforderliche Ebene 'anzuheben', Schritte 120, 140, 160.

Auf jeder Ebene, beginnend auf der obersten Ebene, Schritt 130, und gefolgt von der nächsten Ebene unterhalb, Schritt 150, und von der lokalen Ebene, Schritt 170, wird für die gewünschte Aktualisierung eine Lagerbestandsliste erstellt, Lagerbestandslisten 1, 2, 3, in der jeweils dateibezogene Daten enthalten sind, beispielsweise die Speicherstelle, von der die Daten kopiert werden konnten sowie andere Dateiinformationen wie inaktiver Name usw. Nähere Einzelheiten dazu werden an späterer Stelle beschrieben.

Danach werden in einem Schritt 180 alle drei Listen zusammengefügt. Existiert ein Dateiname bereits, überschreibt eine lokale Datei eine Datei einer höheren Ebene in der Hierarchiepyramide.

Ausschließungslisten nach dem bisherigen Stand der Technik, Schritt 190, lassen sich anwenden, wenn einige zentral angebotenen Dateien in einem Client-System nicht installiert werden sollen, beispielsweise die Unterstützung der italienischen Sprache in einem System, das in Großbritannien verkauft wird. Das heißt, diese werden aus der zusammengefügten Gesamtliste herausgenommen.

Danach wird in einem Schritt 200 eine Lagerbestandsliste des Zielsystems erzeugt bzw. verwendet, wenn diese bereits irgendwo existiert, beispielsweise auf dem Client-System selbst oder anderswo, um festzustellen, welche Dateien nicht heruntergeladen werden müssen. So erhält man eine vollständige Dateiengruppe, die für eine betriebsbereite Version des aktualisierten Programms erforderlich ist.

Als nächstes wird in einem Schritt 210 die Zielliste mit der Gesamteingabeliste verglichen und die bestehenden Dateien auf dem Client-System weggenommen, d. h. aus der Eingabeliste entfernt, um eine Ladeliste zu erzeugen.

Danach werden für alle in der Eingabeliste verbleibenden Dateien Dateinamen erstellt, die eine Namensspezifikation wiedergeben, welche anzeigen kann, daß die Dateien nach einem vollständigen Herunterladen in das Client-System zuerst inaktiv bleiben können, Schritt 215.

Danach folgt das Herunterladen entsprechend den Quellenspeicherstellen-Spezifikationen für jede in der Liste enthaltene Datei, Schritt 220. Somit muß eine erste Anzahl an Dateien vom lokalen Datenspeicher 20 heruntergeladen werden, eine zweite Anzahl vom Datenspeicher 22 der darunter liegenden Ebene oder mittleren Ebene, während eine nur relativ kleine Anzahl an Dateien vom zentralen Datenspeicher der oberen Ebene (Schattenspeicher) kopiert werden muß, wie aus der Darstellung in Fig. 1B ersichtlich ist.

Dadurch wird im Vergleich mit dem Herunterladen einer vollständigen Dateigruppe der Netzwerkverkehr reduziert.

Nach dem Herunterladen kann die Online-Verbindung getrennt werden. Die weitere Wartung kann offline erfolgen.

In Übereinstimmung mit weiteren vorteilhaften Aspekten der vorliegenden Erfindung umfaßt die in diesem Dokument beschriebene Softwarewartungsmethode die Möglichkeit, eine neue Programmversion auf einem Client-Computersystem zu installieren, ohne dabei eine ältere Version zu löschen, die auf dem System bereits vorhanden ist. In einer weiteren Verbesserung dieser Vorgehensweise ist es gemäß der vorliegenden Erfindung möglich, nach dem Herunterladen der Dateien für die neue Programmversion offline zu gehen und die neue Version separat von der bereits vorhandenen Version zu installieren, damit der Benutzer die neue Version testen kann und, wenn er nicht mit ihr zufrieden ist, die alte Version wiederherstellen kann, ohne dass er hierfür einen großen Aufwand in Kauf nehmen muß, um Dateinamen zu kopieren, die Systemumgebung der alten Version wiederherzustellen, möglicherweise geänderte Dateneingaben und -ausgaben wiederherzustellen, usw. Dieser vorteilhafte Aspekt wird im bevorzugten Beispiel der vorliegenden Ausführung angewandt, und zwar u. a. unter Verwendung der Befehle ACTIVATE, BACKOUT und ACKNOWLEDGE.

Um diese vorteilhaften Aspekte zu erreichen, sind alle Dateien, die heruntergeladen werden müssen, mit einigen Attributen zu versehen. Zu diesen Attributen gehören: Pfad- und Dateiname der herunterzuladenden Datei, der zur Adressierung der Datei verwendete Dateiname, wenn die Programmversion, zu der die Datei gehört, aktiviert wird, einige weitere betriebssystemspezifische Daten, einige Dateinamen, die verwendet werden, um die betreffende Datei in einem BACKOUT, in einem INACTIVATE-Prozeß, zu identifizieren, die Datei im Lager des lokalen Datenspeichers 20 zu identifizieren, sowie einige Statusinformationen, die eine beabsichtigte Aktion erkennen lassen, sowie abgeschlossene Aktionen, die mit der betreffenden Datei durchgeführt wurden.

Während des Herunterladens in Schritt 220 wird zwischen dem lokalen Datenspeicher 20 und dem Client-System 12 ein gewisses Maß an Netzwerkverkehr erzeugt, wie aus der Darstellung in Fig. 1B hervorgeht. Wenn ein Softwareanbieter oder -verkäufer, der eine große geografische Region, beispielsweise einen oder mehrere Kontinente, mit mehreren Softwareprodukten betreut, kann er mit mehreren Datenspeichern der mittleren Ebene in jedem Kontinent eine Art zentralen Datenspeicher (oberste Ebene) aufbauen, wobei die Datenspeicher der mittleren Ebene je mit dem zentralen Datenspeicher verbunden sind, um die von ihm angebotenen Programme besser als auf zentrale Art speichern zu können. In einer weiteren Verbesserung des beschriebenen Aspekts läßt sich die Datenspeicherhierarchie so erweitern, dass sie mehrere Datenspeicher einer dritten Ebene umfaßt, von denen jeder mit einem oder mehreren Datenspeichern der mittleren Ebene sowie mit dem zentralen Datenspeicher (oberste Ebene) verbunden werden kann. Darüber hinaus lassen sich einige Schattenspeicher bereitstellen, die die Dateien in vollem Umfang enthalten, d. h. die vollständige Dateigruppe jeder vom Softwareanbieter angebotenen Version, wie oben bereits beschrieben wurde.

Wir betrachten nun Fig. 5C. In einem Schritt 230 werden alle heruntergeladenen Dateien jetzt auf dem mit dem Endbenutzer verbundenen Client-System in ein inaktives Format gesetzt. Der Status der inaktiven Dateien kann dem Betriebssystem mitgeteilt werden, indem die oben angeführten Dateiattribute referenziert werden, in diesem Fall ein Statusfeld, das mit einem 'inaktiven Flag' gefüllt ist, oder, wie oben beschrieben wurde, mit einem Dateinamen, der den genannten inaktiven Status identifizieren kann. Danach kann der Endbenutzer entscheiden, die neue Programmversion zu testen.

In einem Schritt 240 aktiviert er die neue Version 1.2. wie aus der Darstellung in der obigen Beschreibung hervorgeht, ist der Schritt der Aktivierung der neuen Version unabhängig vom Herunterladen. Dies stellt einen Vorteil dar, weil durch die geringere Online-Dauer weniger Kosten entstehen und weil beide Prozesse voneinander losgelöst werden. Eine Unterbrechung während des Herunterladens hat keinen Einfluß auf die bestehende Dateisystemarchitektur der aktiven alten Version des aufzurüstenden Anwendungsprogramms.

Insbesondere hat eine Aktivierung der neuen Version die Inaktivierung der alten Version zur Folge. Dies wird durch Umbenennung der neuen Dateien von inaktiven Namen in aktive Namen und der vorherigen aktiven Dateien in 'Backout'- Dateinamen erreicht. Das Statusfeld jeder Datei wird entsprechend geändert.

Danach kann der Endbenutzer, der die neue Programmversion angefordert hat, die neue Version ausführen und feststellen, ob sie seine Erwartungen erfüllt. Dazu läßt der Endbenutzer das Programm in der neuen Version mit verschiedenen Eingabe- und Konfigurationsdaten arbeiten und prüft in den Schritten 250 und 260 die korrekte Arbeitsweise. Danach entscheidet er, ob die neue Version zuufriedenstellend arbeitet. Wenn es keine ernsthaften Probleme gibt (siehe Ja-Verzweigung an Entscheidung 260), beschließt der Benutzer, vorwiegend mit der neuen Programmversion zu arbeiten. Dazu verwendet er oder der Systemadministrator einen bestimmten Befehl, der die wesentlichen Grundsätze der vorliegenden Erfindung inkorporiert, d. h. den Befehl ACKNOWLEDGE, welcher dem Betriebssystem mitteilt, dass die neue Version die in Zukunft zu verwendende Standard-Programmversion ist. Zu beachten ist, daß der Schritt 270 zur Bestätigung einer neuen Version für eine reguläre und immer wiederkehrende 'tägliche' Prozedur der neuen Programmversion ganz und gar nicht erforderlich ist. Stattdessen wird dieser Schritt häufig unmittelbar vor dem Erscheinen einer nächsten Version ausgeführt. Beispielsweise wird die Version 1.3 des gleichen Produkts gemäß der in diesem Dokument beschriebenen Software- Wartungsmethode installiert.

Erzeugt die neue Programmversion ernsthafte Probleme (NEIN- Verzweigung der Entscheidung 260), möchte der Benutzer seine Arbeit nicht mit der neuen Programmversion fortsetzen. Stattdessen kann er entscheiden, die Vorgängerversion 1.1 wieder zu aktivieren, Schritt 280. Dies erfolgt durch einen einzigen REACTIVATE-Befehl, der gemäß der obigen Beschreibung an das Betriebssystem gesendet wird. In diesem Fall werden die Attribute gemäß der obigen Beschreibung aktualisiert. Die alte Systemumgebung und die Eingabe- und Ausgabedateien können verwendet werden, um eine zuverlässige Arbeitsweise der alten Version 1.1 zu gewährleisten.

So kann der Endbenutzer auf jeden Fall eine angemessene und zufriedenstellende Version seines Programms ausführen, Schritt 290.

Es wird darauf hingewiesen, daß das Prinzip der vorliegenden Erfindung offen ist, um weitere Hierarchieebenen aufnehmen zu können oder auch Ebenen herauszunehmen, um nur auf zwei verschiedenen Ebenen zu arbeiten.

Darüber hinaus lassen sich die oben angeführten Schattenspeicher einrichten, um den Datenverkehr auf dem Netzwerk zu verringern, denn wenn mehrere Schattenspeicher die im zentralen Speicher vorhandenen Daten abbilden und replizieren, führt dies bei den erforderlichen Ladeprozessen zu kürzeren Netzwerkverbindungen.

In der bisherigen Spezifikation wurde die Erfindung in bezug auf ein bevorzugtes Ausführungsbeispiel beschrieben. Es wird jedoch darauf hingewiesen, daß zahlreiche Änderungen und Erweiterungen möglich sind, ohne vom Grundprinzip und Anwendungsbereich gemäß Definition in den nachfolgenden Ansprüchen möglich sind. Die Spezifikation und die Zeichnungen sind demnach beispielhaft und nicht einschränkend zu betrachten.

Zum Beispiel kann die Reihenfolge, in der auf die in Fig. 1 abgebildeten Datenspeicher zugegriffen wird und die unter Verweis auf die Fig. 5A, 5B und 5C beschrieben werden, verändert werden. Entweder man geht von oben nach unten vor oder von unten nach oben. Es muß jedoch sichergestellt sein, daß die eher individuell angepaßten und lokalen Dateien solche Dateien überschreiben, die aus einem eher zentralen Speicher kopiert wurden, falls diese in mehreren Speichern redundant gespeichert sind.

Entsprechend einem weiteren bevorzugten Aspekt der vorliegenden Erfindung läßt sich ein sogenannter Seitenblickprozeß in die oben beschriebene Aufrüstprozedur integrieren. Für den Fall, daß sich irgendwo in der Nähe des Ziel-Client-Systems ein zweites Zielsystem befindet, das bereits mehrere Dateien installiert hat, die heruntergeladen werden müssen, kann die Prozedur sozusagen auf das genannte zweite System einen 'Seitenblick werfen' und von dort unter Verwendung eines LAN-Netzes anstatt über eine online- Fernverbindung zum Herunterladen die genannten Dateien kopieren. Dies kann beispielsweise in einem Fall erfolgen, in dem das genannte zweite 'Nachbarsystem' bereits mit den Dateien der höheren Version als der auf dem Zielsystem ausgestattet ist, die neue Version jedoch auf dem genannten zweiten System noch nicht aktiv ist.

Weiterhin kann die Art, in der die zu einer betreffenden Version gehörenden Dateien für das Betriebssystem des Client- Computers gekennzeichnet werden, unterschiedlich sein. Eine sichere Methode nach dem bisherigen Stand der Technik ist eine Änderung der Dateinamen gemäß obiger Beschreibung, doch je nach Funktionalität der betreffenden Betriebssystemvariante von Dateiattributen kann eine geeignete Betriebssystem-steuerung die gleiche Funktion übernehmen.

Das Verfahren und das System zur Softwarewartung gemäß der vorliegenden Erfindung ist offen, um eine Installation mehrerer Produkte zu ermöglichen, d. h. Produkt X, Produkt Y und Produkt Z auf dem gleichen Zielsystem. Erreicht wird dies durch das Führen einer Lagerbestandsliste für jedes Produkt oder Produktteil auf dem Client-System. Die genannten Bestände bilden einen Verweis auf die aktiven und inaktiven Daten jedes Produkts.

Darüber hinaus sind in Übereinstimmung mit der vorliegenden Erfindung keine Verpackungsdateien erforderlich, die beschreiben, welche Daten oder welche Dateien zu welchen Produktversionen gehören. Diese Information geht aus der Verzeichnisstruktur bzw. den darin gespeicherten Daten hervor.

Außerdem läßt sich auf einfache Weise eine Tool-interne 'UNDO'-Funktion in das Verfahren der vorliegenden Erfindung integrieren, die unabhängig vom oben beschriebenen BACKOUT- Prozeß funktioniert. Mit dieser Funktion läßt sich die vorherige Funktion reaktivieren. Die genannte vorherige Version muß nicht notwendigerweise die zuletzt akzeptierte (ACCEPTED) Version sein. Zu beachten ist, daß der Befehl UNDO unabhängig, d. h. offline, arbeitet.

Weiterhin lassen sich das Verfahren der vorliegenden Erfindung und das Programm-Tool, welches das genannte Verfahren der vorliegenden Erfindung implementiert, erweitern, so daß eigene Ausgangspunkte integriert werden, die mit einem Code zu einem bestimmten Zweck frei programmierbar sind und separate Schnittstellen bilden, die verschiedene Aufgaben erfüllen können, beispielsweise Problemmanagement bei der Aufrüstung, Meldewesen für Lizenzmanagement, usw. Die genannten Ausgänge lassen sich vor oder nach einem bestimmten Aufruf oder Durchlauf des Tools aktivieren, bevor bzw. nachdem ein Zielsystem vom genannten Tool vollständig analysiert wurde. Die genannten Ausgänge können allen in Frage kommenden Produkten (oder Teilgruppen davon) angepaßt werden, je nach dem, um welche Produkte und Systeme es geht. Aus Ausgänge lassen sich vorteilhaft verwenden, um individuelle Kundendaten zu verarbeiten, beispielsweise Dateien oder Daten einer IP-Adresse für einen Datenspeicher, vorzugsweise für einen lokalen Datenspeicher.

Das Prinzip der vorliegenden Erfindung läßt sich in einer Hardware, einer Software oder einer Kombination aus Hardware und Software umsetzen. Ein Softwaretool zur Wartung gemäß der vorliegenden Erfindung läßt sich auf einem Datenträger speichern und beispielsweise von einem Client-System ausführen. Jedes beliebige Computersystem oder jede beliebige andere Vorrichtung, die zur Anwendung der beschriebenen Methoden angepaßt wurde, ist geeignet. Eine typische Kombination aus Hardware und Software wäre ein Mehrzweck- Computersystem mit einem Computerprogramm, das beim Laden und Ausführen das Computersystem so steuert, dass es die oben beschriebenen Methoden anwendet.

Die vorliegende Erfindung läßt sich auch in ein Computerprogrammprodukt einbetten, das alle Funktionen umfaßt, die die Implementierung der oben beschriebenen Methoden ermöglichen und das beim Laden in ein Computersystem diese Methoden anwenden kann.

Im vorliegenden Zusammenhang bezeichnet Computerprogrammittel oder Computerprogramm jeden beliebigen Ausdruck in jeder beliebigen Sprache und mit jedem beliebigen Code einer Gruppe von Anweisungen, die ein System mit einer Informationsverarbeitung veranlassen, eine bestimmte Funktion entweder direkt oder indirekt auszuführen:

• a) Umwandlung in eine andere Sprache oder in einen anderen Code;
• b) Reproduktion in einer anderen Materialform.

Claims (13)

1. Verfahren zur Wartung von Softwareprodukten, die in mehreren Dateien in Client-Computersystemen (12), die bezüglich mindestens eines zentralen Software- Wartungsstandorts (10, 24) dezentral über ein Netz implementiert sind, mit dem sie verbunden werden können, wobei dieses Verfahren die folgenden Schritte umfaßt:
Bereitstellung von Produktinformationen im Netzsystem, um es für die genannte Mehrzahl an Client-Systemen verfügbar zu machen,
wobei dieses Verfahren durch den folgenden Schritt charakterisiert ist:
Durchführung einer Software-Wartung am Client-Standort durch Herunterladen der für die genannte Wartung erforderlichen Daten von einer Reihe von Datenspeichern,
wobei die genannte Reihe von Datenspeichern mindestens einen Datenspeicher umfaßt, der für mindestens ein bestimmtes Client-System (12) zuständig ist, sowie mindestens einen Datenspeicher umfaßt, der für das genannte Client-System (12) nicht speziell zuständig ist.

2. Verfahren gemäß Anspruch 1, in dem das Herunterladen von der Aktivierung eines heruntergeladenen Programms losgelöst ist, indem die Dateien in einem inaktiven Format heruntergeladen werden, das alle zur späteren Aktivierung des genannten Programms erforderlichen Informationen umfaßt.

3. Verfahren gemäß Anspruch 1, wobei eine Rückkehr zu einer älteren Programmversion erreichbar ist, indem die neuere Version ausgeschaltet und die ältere Version eingeschaltet (240) wird.

4. Verfahren gemäß Anspruch 1, wobei der genannte Schritt zur Durchführung der genannten Wartung zur Aufrüstung eines Programms auf mindestens einem Zielsystem dient und der genannte Schritt die folgenden Schritte umfaßt:
Erzeugung (130, 150, 170) einer Eingabeliste der Dateien, die von den mindestens zwei Datenspeichern (20, 22, 24) heruntergeladen werden können,
Erzeugung einer Liste der Dateien, die auf dem genannten Ziel-Client-System (12) vorhanden sind,
Vergleich (210) der genannten Listen, und
Herunterladen (220) nur derjenigen Dateien, die im genannten Ziel-Client-System (12) noch nicht vorhanden sind.

5. Verfahren gemäß dem vorherigen Anspruch, mit dem durch schrittweisen Zugriff auf die Datenspeicher und durch Mischen der genannten Eingabelisten mit einer Priorität lokaler Dateien eine Gesamteingabeliste erzeugt wird.

6. Verfahren gemäß dem vorherigen Anspruch, das weiterhin den Schritt der Integration von Dateien in das Zielsystem umfaßt, wobei durch ein sogenanntes 'Seitenblickverfahren' bestimmt wurde, daß sich diese Dateien in einem benachbarten System befinden, auf das ein einfacherer Zugriff durch das Zielsystem möglich ist als auf einen der genannten Datenspeicher (20, 22, 24).

7. Ein System, in dem das Verfahren gemäß jedem der Ansprüche 1 bis 6 durchgeführt werden kann.

8. System gemäß dem vorherigen Anspruch, in dem in mehreren der hierarchisch angeordneten Datenspeicher (20, 22, 24) eine Dateisystemhierarchie bereitgestellt wird.

9. System gemäß dem vorherigen Anspruch, in dem mindestens der genannte Datenspeicher (20, 22) ein Overlay- Datenspeicher ist, der im wesentlichen Deltainformationen enthält.

10. System gemäß dem vorherigen Anspruch, in dem Datenspeicher auf Länderebene (22) und auf Systemebene (20) vorhanden sind.

11. System gemäß dem vorherigen Anspruch, in dem Schattendatenspeicher vorhanden sind.

12. Computerprogramm, das Code-Teile umfaßt, die für die Durchführung der Schritte entsprechend dem Verfahren in Übereinstimmung mit einem der vorherigen Ansprüche 1 bis 6 angepaßt sind und ausgeführt werden, wenn das genannte Programm in einen Computer geladen wird.

13. Computerprogrammprodukt, das auf einem computerlesbaren Medium gespeichert ist und ein computerlesbares Programmittel umfaßt, welches einen Computer veranlaßt, das Verfahren gemäß einem der Ansprüche 1 bis 6 anzuwenden.