-
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 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'-Prozess, durch den
die individuell angepasste Software an die zahlreichen Client-Systeme übertragen
werden könnte,
erforderlich ist.
-
Die
US 5,930,513 betrifft ein
verfahren zur Softwarewartung von Client-Applikationen in einem elektronischen
Netzwerk, das ein sogenanntes „Overlay"-Dateiensystem verwendet,
wobei individuelle Overlay-Dateisysteme zu einzelnen Client-Applikationen im
Netzwerk zugeordnet sind. Dabei enthält ein solches Overlay-System
Dateien, die nur für
einen speziellen Client verwendet werden sollen, wobei diese speziellen
Dateien in einem speziellen „Overlay-Cache" genannten Speicherbereich
für jeden
einzelnen Client vorhanden sind. In nachteilhafter Weise ist dort
keine Lehre gegeben, die Netzwerkbelastung während der Wartung gering zu
halten.
-
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 dass 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 enthaltenm, 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.
-
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.
-
2 ist
eine schematische Darstellung der Dateisystemstruktur im Lager des
Softwareanbieters, was durch die in 1B abgebildeten
Datenspeicher (grob) dargestellt wird.
-
3 ist
eine schematische Darstellung gemäß 2 eines
mittelgroßen
Lagers.
-
4 ist
eine schematische Darstellung gemäß 3 des lokalen
Lagers.
-
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
-
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 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.
-
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 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 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.
-
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 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 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 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 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 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 1 abgebildeten
Datenspeicher zugegriffen wird und die unter Verweis auf die 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.