DE69404647T2

DE69404647T2 - Verfahren und vorrichtung zum verwalten von tischcomputern eines unternehmens

Info

Publication number: DE69404647T2
Application number: DE69404647T
Authority: DE
Inventors: Albion Fitzgerald; Joseph Fitzgerald
Original assignee: Novadigm Inc
Current assignee: Novadigm Inc
Priority date: 1993-04-30
Filing date: 1994-05-02
Publication date: 1997-11-27
Anticipated expiration: 2014-05-03
Also published as: JP3466193B2; JPH08510341A; ATE156282T1; US6915451B2; US20010034829A1; EP0696368B1; DE69404647D1; WO1994025913A2; WO1994025923A1; WO1994025913A3; US20020049810A1; WO1994025924A1; EP0696368A1; CA2160907A1; US5581764A; US6292889B1

Description

1. Gebiet der Erfindung

Die Erfindung betrifft allgemein Computernetzwerke und insbesondere die hochautomatisierte zentrale Verwaltung von Betriebsmitteln, die in mit dem Netzwerk verbundenen Computern enthalten sind.

2. Beschreibung des Standes der Technik

A. Herkömmliche Rechenzentren und Netzwerke

Als firmeninterne Massendatenverarbeitung entwickelt wurde, wurden Online- Systeme und -Anwendungen in zunehmendem Maße in fast allen Teilbereichen des Handels durch die weitverbreitete starke Ausbreitung von Tischrechnern verfügbar, welche über Telekommunikationsnetzwerke mit zentralen Computerzentren verbunden waren. Herkömmlicherweise sind diese Netzwerke als Teil der Verantwortlichkeiten eines Informationstechnologie Verwaltungszentrums zentral verwaltet worden. Die Komplexität der Verwaltung strategisch notwendiger Datenverarbeitungsbetriebsmittel, die Verwaltung bedeutender Mengen kritischer Geschäftsanwendungen und ihrer zugehörigen Daten; das Vorsehen eines Zugriffs eines vernetzten Tischrechners auf die geeigneten Systeme und Anwendungen; und die Sicherung der Integrität, Sicherheit und Verfügbarkeit derartiger Mittel zu jeder Zeit sind einige der wichtigsten Herausforderungen gewesen, die sowohl von der Informationsverwaltung als auch von den Informatikdisziplinen angegangen wurden.
Systemverwaltungssoftware, die herkömmlicherweise auf zentralen Datenverarbeitungszentren gelaufen ist, umfaßt Aufgaben, wie etwa Bibliotheks- und Konfigurationsverwaltung, Versionskontrolle, Betriebsmittelsicherheit, Netzwerksteuerung, Daten- und Speicherverwatung, Aufgabendisposition, Kommunikationsverwaltung, Betriebsmittelüberwachung und -berichtung. Ein Großteil der früheren Verwaltungssoftware für verteilte Systeme wurde entwickelt, um in hochstrukturierten Umgebungen für eine zentrale Steuerung leicht zugänglich zu funktionieren. In der Vergangenheit hatten Benutzer an Tischrechnern im Netzwerk oft relativ geringe Flexibilität bei der Konfiguration ihrer Arbeitsplatzrechner (ihrer "Desktops"), um ihre speziellen Bedürfnisse zu befriedigen.
Vor kurzem haben die revolutionären Entwicklungsschritte in der Hardware- und Software-Technik und bei der Mensch-Computer-Schnittstelle einen enormen Bereich verschiedener Anwendungsprogramme geschaffen, die für die Desktop-Anwendung auf Personalcomputern verfügbar sind. Außerdem sind Tischrechner so leicht bedienbar geworden, daß Benutzer in zunehmendem Maße für einen breiten Bereich von Spezialaufgaben, wie etwa Textverarbeitung, Tabellenkalkulation und persönliche Informationsverwaltung, auf sie angewiesen sind. Die starke Ausbreitung von Anwendungsprogrammen für Tischrechner und die breite Verwendung von Computern in riesigen Netzwerken macht die Aufgabe der Verwaltung von Netzwerken weiterhin immer reizvoller.
Unter Bezugnahme auf die veranschaulichende Zeichnung der Figur 1 ist ein erläuterndes Blockdiagramm einer typischen verteilten Computerumgebung gezeigt, mit einem Zentralrechner, der die Anwendungssoftware und die Netzwerkaktivitäten für ein Netzwerk verwaltet, das eine Mehrzahl von Endterminals, wie etwa Arbeitsplatzrechner, aufweist. Ein typisches Rechenzentrum umfaßt einen Zentralrechner, oft ein leistungsfähiger Großrechner, und ein oder mehrere Verwaltungscomputer-Terminals. Normalerweise laufen Programme wie etwa Sicherheitsverwaltungsprogramme, Verwaltungsprogramme für Konfigurationsänderungen, Bibliotheksverwaltungsprogramme und Presentationsverwaltungsprogramme auf dem Zentralrechner.

B. Verschiebung von Rechenzentrumsfunktionen zum Tischrechner

Die Entwicklung leistungsfähigerer Tischrechner hat dazu geführt, daß viele Funktionen zum Tischrechner verschoben wurden. in der Vergangenheit wurden diese Funktionen durch einen Zentralrechner verwaltet, der in dem Rechenzentrum angeordnet war. Die Verschiebung der Funktionen zum Tischrechner ist durch das Aufkommen von grafischen Benutzeroberflächen (GUIs) vorangetrieben worden, welche eine Benutzeroberfäche in der Form einfacher Bilder darstellen, in welchen Anwendungen oder andere Betriebsmittel als zu manipulierende Icons dargestellt sind. Eine GUI kann es einem Benutzer erlauben, mit Abbildungen auf einem Computerbildschirm auf dieselbe Weise umzugehen, wie er mit einem realen Objekt, wie etwa einem Telefon, einem Aktenordner oder anderen Objekten, die oft auf einem realen Tisch zu finden sind, umgehen würde. Das sich daraus ergebende leichte Verständnis und die intuitive Umgebung schafft die Grundlage, auf der unzählige neue robuste und leistungsfähige Anwendungsprogramme aufgebaut worden sind.
Folglich haben Tischrechner-Benutzer von ihren Tischrechnern nach und nach viel Datenverarbeitungsfunktionalität, die einst für Zentralrechner und Computerzentren reserviert war, verlangt. Zusätzlich mußten viele bestehende Anwendungen von Zentralcomputern und viele Daten, die für ein Unternehmen kritisch waren, für neu entstehende Client-/Server-Anwendungen zugänglich sein. Zum Beispiel kännte eine Desktop-Anwendung für die Verwendung in der Umsatzanalyse Zugang zur Produktbestellung und Verfügbarkeitsinformationen, die durch einen Zentralrechner verwaltet werden, verlangen. Zum Beispiel könnte alternativ eine Tabellenkalkulation am Tischrechner in einer zentralen Datenbank gespeicherte Daten benötigen.
Kurz gesagt wird ein Zentralrechner oft aufgefordert, als zentrales Depot für Dienste und Daten zu dienen, die für verschiedene Abteilungen innerhalb eines Unternehmens verfügbar sein sollen. Unterschiedliche Abteilungen haben oft unterschiedliche Bedürfnisse, und die Anforderungen der zentralen Verwaltung nehmen zu, indem einzelne Benutzer innerhalb der Abteilung in der Lage sind, ihre individuellen Bedürfnisse mit größerer Ausführlichkeit zu spezifizieren. So werden die Netzwerkverwalter von verteilten Tischrechnern in zunehmenden Maße aufgefordert, das Engagement von Endbenutzern für den Tischrechner und vor allem die Produktivitätsverbesserungen von persönlicher gestaltetem Umgang mit Computern am Arbeitsplatzrechner in hohem Maße zu unterstützen.

C. Fragen der Einsatzverwaltung

Die Einsatzfragen bei der Verwaltung zentraler Systeme umfaßt die Konfiguration der vernetzten Tischrechner, die Verteilung der Betriebsmittel und laufende Wartung von Betriebsmitteln verteilter Tischrechner. Wenn erst einmal ein Tischrechner mit den geeigneten Betnebsmitteln konfiguriert worden ist, müssen diese Betriebsmittel in geeigneter Weise gewartet werden. Eine der Anforderungen, denen man bei der Verwaltung zentraler Systeme begegnet, besteht darin, daß eine große Vielfalt von Software-Betriebsmitteln in dem Netzwerk und eine große Anzahl von Tischrechnern verfügbar sein können. Die Frage, "Wer bekommt was?", kann schwierig sein. Die Komplexität dieser Frage nimmt nicht nur mit der Notwendigkeit zu, zu spezifizieren, welches Anwendungsprogramm auf welchen Tischrechnern verfügbar sein sollte, sondern auch durch Fragen, wie etwa welche Version einer Anwendung zu verwenden ist, durch Sicherheitsmaßnahmen, durch auf Firmenpolitik beruhenden Beschränkungen und durch Kompatibilität. Das Fehlen von in ausreichenden Maße automatisierter Technik, um einige oder alle Tischrechner in einem Netzwerk auf einer geforderten Grundlage dynamisch zu rekonfigurieren, kann ein bedeutender Mangel in der Systemverwaltung sein, der das Ansprechen eines ganzen Unternehmens auf sich geändernde technische und geschäftliche Anforderungen verlangsamen kann. Zum Beispiel können im Bankgewerbe auf Computersoftware gestützte Schulungsinformationen auf hunderte von Zweiggeschäftsstellen zu verteilen sein und kännen mit Änderungen in der Kreditpolitik der Bank und in Bankvorschriften auf aktuellem Stand gehalten werden müssen. In einem derartigen Bankwesen-Szenarium ist zum Beispiel die effiziente Verteilung und Aktualisierung der Software kritisch. Ein vergeblicher Versuch neue Kreditpraktiken oder neue Bankvorschriften an alle Zweigstellen unverzüglich zu verteilen, könnte ernste schädigende Konsequenzen für das Geschäft haben. Indem die Anzahl von verteilten Computern und die Komplexität und Vielfalt ihrer Betriebsmittelkonfigurartionen anwächst, kann das Fehlen einer geeignet automatisierten Technik, um diese Verteilungen zu erlauben, zu unakzeptabelen Verzögerungen oder hohen Verwaltungspersonalkosten führen.
Unter Bezugnahme auf die veranschaulichende Zeichnung der Figur 2 ist eine beispielhafte Verwaltungsstruktur mit zentralisierter Konfiguration gezeigt. Sie umfaßt mehrere Verwaltungscomputerterminals und mehrere Tischrechner, die alle mit einem Zentralrechner verbunden sind. Die Verwaltungsterminals erlauben es einem Netzwerk-Verwaltungspersonal die Tischrechner zu verwalten. Der Zentralrechner schafft einen zentralen Ort für die Verteilung von Anwendungen und Daten an die Tischrechner. Die Verwaltung derartiger Betriebsmittel kann das Aufrechterhalten von Listen von Betriebsmitteln mit sich bringen, die für die Tischrechner verfügbar sind; oder die Aufrechterhaltung von Regeln für die Benutzung der Betriebsmittel auf dem Tischrechner.
Zum Beispiel das US-Patent Nr. 5,282,273, erteilt an Ushio et al., beschreibt ein Unternehmensinformationssystem mit einer dreistufigen Hierarchie von Datenbanken und Kommunikationswegen. Das '273-Patent spricht Probleme an, die durch auf die integrierte Verwaltung von Informationen in einem Unternehmen gerichtete Versuche entstehen. Es lehrt die Verwendung von drei Arten von Datenbanken und drei Arten von Kommunikationswegen, um das Unternehmen zu verwalten. Diese Hierarchie stellt ein Beispiel einer möglichen Architektur für ein früheres unternehmensweites Informationsnetzwerk dar.

D. Gleichzeitige Verwaltung von auf Firmenpolitik und Technik beruhenden Fragen des Betriebsmitteleinsatzes

Ein wichtiges Ziel bei der zentralisierten Systemverwaltung ist es, sicherzustellen, daß die Betriebsmittel, über die jeder Tischrechner verfügt, mit den Betriebsmitteln zusammenpassen, über die der Rechner verfügen sollte, und zwar auf der Grundlage sowohl firmenpolitischer als auch technischer Überlegungen. Zum Beispiel kann ein Zugriff des Benutzers des Tischrechners auf ein Betriebsmittel durch Firmengrundsätze erzwungen worden sein, wie etwa Grundsätze, die regeln, welche Benutzer und welche Abteilungen Zugriff auf bestimmte Anwendungsfunktionen haben können und welche geschäftlichen oder technischen Daten als vertraulich zu behandeln sind. Ein Zugriff eines Benutzers eines Tischrechners auf Betriebsmittel kann auch von technischen Fragen abhängen, wie zum Beispiel, welches Betriebssystem auf dem Tischrechner benutzt wird oder wieviel Plattenspeicherplatz auf dem Tischrechner verfügbar ist.
So kann zum Beispiel ein anfänglicher Einsatz einer verteilten Computeranwendung erfordern, daß ein Firmenpolitikverwalter festlegt, welche Benutzer autorisiert werden, die Anwendung zu benutzen. Danach legt ein technischer Verwalter die bestimmte Version der für diesen bestimmten Tischrechner des Benutzers geeigneten Anwendungssoftware fest. Das Produkt dieser Festlegungen in dem gemeinsam automatisierten Verteilungszugriff umfaßt normalerweise eine "Bedarfs"-Liste von Komponenten oder durch einen Verteilungsverwalter aufbereitete "Betriebsmittel", die über eine Netzwerkverbindung zu einem Tischrechner eines Benutzers transportiert werden müssen. Der Verteilungsverwalter erstellt typischerweise eine Liste von Computern des Benutzers, welche dieselbe "Bedarfs"-Liste von Komponenten erfordern (weil sich vermutlich die Benutzer alle dieselben Anforderungen hinsichtlich Firmenpolitik und Desktop- Umgebung teilen), und verwendet typischerweise ein "Verteilungs"-Programm zusammen mit diesen "Bedarfs"-Listen, um den Transport und die Installation der Komponenten auf den Tischrechnern zu automatisieren.

E. Die Anforderung der automatisierten Änderungsverwaltung

Es ist anspruchsvoll genug, Betriebsmittel in einer Vielzahl von individualisierten Tischrechnern in einem ganzen Unternehmen basierend sowohl auf firmenpolitischen als auch technischen Faktoren zu verteilen. Die Aufgabe ist jedoch kompliziert, aufgrund der Tatsache, daß sich sowohl die technische Konfiguration (zum Beispiel, Betriebssysteme, Plattenspeicherplatz, CPU-Typ) einzelner Tischrechner und die Firmengrundsätze des Unternehmens, wer welche Computeranwendungen haben sollte, als auch die Komponenten der Computeranwendungen selbst mit großer Häufigkeit ändern können, und dies auch tun. Folglich müssen die Betriebsmittel der Tischrechner aktualisiert werden, um diese Änderungen widerzuspiegeln.
Historisch ist der Verwaltungsweg einer Änderung nur teilweise automatisiert worden. Ein Verteilungsverwalter erstellt Listen von Betriebsmitteln, die auf der Basis der "letzbekannten" Desktop-Technik-Konfigurationen für mehrere Tischrechner und basierend auf Listen von "letztbekannten" autorisierten Benutzern der Betriebsmittel geändert werden müssen. Ein Verteilungsprogramm wird zur Verteilung dieser "Bedarfs"-Listen verwendet, um die Tischrechner zu aktualisieren, d. h. neue Anwendungen zu verteilen oder vorher verteilte Anwendungen zu aktualisieren. Wie in dem typischen anfänglichen Einsatzprozeß, erstellt der Verteilungsverwalter die "Bedarfs"- Listen manuell, die notwendig sind, um das Verteilungsprogramm darüber anzuweisen, welche Betriebsmittel für welche Tischrechner abzuändern sind. Dieser manuelle Listenerstellungsprozeß für Änderungen versucht typischerweise Listen zu verwenden, die vorher für den anfänglichen Einsatz erstellt wurden. Unglücklicherweise eröffnet die Verwendung von vorher entwickelten Autorisierungslisten und Desktop-Konfigurationslisten die Möglichkeit, Fehler in den Änderungsprozeß einzufügen, weil eine oder mehrere Benutzerautorisierungen geändert worden sein können, seitdem die Liste erstellt worden ist, oder weil sich die Konfigurationen von einem oder mehreren Tischrechnern geändert haben könnten.
Die inherenten Schwierigkeiten beim Verfolgen der Änderung von Firmengrundsätzen und Desktop-Konfigurationen haben einige Unternehmen dazu veranlaßt, für einen hohen Standardisierungsgrad und eine geringe Rate von Änderungen in den Firmengrundsätzen, den Desktop-Konfigurationen und den Betriebsmittelkomponenten zu sorgen. In Wirklichkeit beschränkt das Unternehmen Änderungen in seiner Netzwerkumgebung, weil es so schwierig ist, mit einer derartigen Änderung umzugehen. Unglücklicherweise läuft eine Beschränkung von Änderungen und das Einsetzen für eine Standardisierung der gegenwärtigen Computerkultur entgegen, die sowohl die starke Ausbreitung von persönlicher gestalteten Desktop-Konfigurationen als auch die Notwendigkeit schneller Änderungen von Computerumgebungen von Benutzern anregt, um mit der schnellen Entwicklung der Tischrechner- Anwendungstechnologie Schritt zu halten.

F. Änderungsverwaltung auf der Grundlage von Listen

Die veranschaulichende Zeichnung der Figur 3 zeigt ein früheres Verfahren zum Verwalten und Aufrechterhalten gespeicherter Listen für Betriebsmittel und für deren Verwendung, die Erstellung von "Bedarfs-Listen zu automatisieren. Eine als "Bereits-Haben-" (AH) (Already Have)-Liste bezeichnete Liste wird erstellt und für jeden Tischrechner gespeichert. Die AH- Liste zählt Betriebsmittel auf, die ein Tischrechner bereits hat. Solche Betriebsmittel können während einer anfänglichen Anforderung oder einer dazwischen liegenden Änderungsaktivität zu dem Tischrechner transportiert worden sein. Eine andere Liste, die als die "Sollte-Haben-" (SH) (Should Have)-Liste bezeichnet wird, kann durch Verwaltungspersonal erzeugt werden. Die (SH)-Liste zählt Betriebsmittel auf, die ein Tischrechner haben sollte. Diese Liste führt einzeln die Betriebsmittel auf, die für den Tischrechner für alle autorisierten Aktivitäten verfügbar sein sollten. Die AH-Listen werden entweder im Zentralrechner oder in den lokalen Tischrechnern gespeichert. Normalerweise werden die SH-Listen zentral oder in dem Verwaltungscomputer, der sie erstellt, gespeichert. Jedoch ist der Speicherort der AH- und SH-Listen allgemein nicht kritisch.
Eine "Bedarfs"-Liste ktnnte dann durch Vergleichen der AH-Liste mit der SH- Liste erzeugt werden. In der SH-Liste enthaltene Elemente, die in der AH-Liste nicht vorhanden sind, sind in der "Bedarfs-Liste enthalten. Zum Beispiel zeigt in Figur 3 die "Bedarfs"-Liste eine Ergänzung eines neuen Elements, das als "ggg" bezeichnet ist, welches in der SH-Liste aufgeführt ist, aber welches nicht in der AH-Liste aufgeführt ist. Die "Bedarfs"-Liste legt auch Elemente dar, die in der AH-Liste vorhanden sind, aber welche in der SH-Liste aktualisiert worden sind. Diese aktualisierten Elemente in der "Bedarfs"-Liste sollen entsprechende Elemente in der AH-Liste ersetzen. Zum Beispiel wurde das als "aaa" in der SH-Liste aufgeführte Element zum letzten Mal am 01.05.92 um 12:13:45 Uhr aktualisiert. Das korrespondierende als "aaa" in der AH-Liste aufgeführte Element wurde zum letzen Mal am 01.03.92 um 12:13:45 Uhr aktualisiert. Da die SH-Liste das aktuellere Element enthält, benötigt die AH- Liste eine Aktualisierung. So enthält die "Bedarfs-Liste das am 01.05.92 um 12:13:45 Uhr aktualisierte Element "aaa, das das Element "aaa" ersetzt, das zuletzt am 01.03.92 aktualisiert worden ist. Darüber hinaus identifiziert die "Bedarfs"-Liste Elemente, die in der AH-Liste vorhanden sind, aber in der SH- Liste nicht vorhanden sind, und welche deshalb aus dem Tischrechner gelöscht werden müssen. Das Element "fff" ist in der "Bedarfs"-Liste aufgeführt, während es eine Löschung aus der AH-Liste benötigt.
Die in der AH-Liste aufgeführten Elemente, wie zum Beispiel "ddd", können Betriebsmittelnamen oder Zeiger auf Betriebsmittel oder Datensätze darstellen. Die Datums- und Zeitangaben neben derartigen Elementen bezeichnen den Aktualitätsgrad des Betriebsmittels. Zum Beispiel wurde das als "ddd" bezeichnete Element in der SH-Liste zuletzt am 14.05.92 um 13:11:54 Uhr aktualisiert. Die "Bedarfs"-Liste identifiziert Löschungen, Ergänzungen und Aktualisierungen von Betriebsmitteln, die notwendig sind, um einen Tischrechner entsprechend den Verwaltungserfordernissen, die in der SH-Liste bezeichnet sind, zu konfigurieren.
So umfaßt das vorstehend beschriebene, frihere Verfahren zum Konfigurieren eines Tischrechners das Bestimmen, welches Betriebsmittel der Tischrechner bereits hat; das Bestimmen, welche Betriebsmittel der Tischrechner haben sollte; und basierend auf einem Vergleich von AH- und SH-Betriebsmitteln, das Erstellen einer "Bedarfs"-Liste, die angibt, welche Betriebsmittel der Tischrechner ergänzen, löschen oder aktualisieren muß. Wenn erst einmal eine "Bedarfs"-Liste erzeugt ist, wird sie zusammen mit einem automatisierten Verteilungsprogramm angewendet, um das Verfahren des Löschens von Betriebsmitteln von dem Tischrechner oder des Ergänzens von Betriebsmitteln zum Tischrechner oder des Aktualisierens von Betriebsmitteln auf dem Tischrechner zu verwalten. Das Verfahren des Löschens, Ergänzens oder Aktualisierens von Betriebsmitteln, kann das Transportieren neuer oder aktualisierter Programm- oder Datenversionen über das Netzwerk und das Löschen nicht mehr benötigter Programm- oder Datenversionen in dem Tischrechner umfassen. Die Arten von Betriebsmitteln, die gelöscht, ergänzt oder aktualisiert werden können, umfassen praktisch alle Informationen, die über das Netzwerk transportiert werden können, wie etwa Programme, Daten, lcons und Stapeldateien.
Ein Problem bei dem unter Bezugnahme auf Figur 3 beschriebenen Listentyp besteht darin, daß das Ergänzen, Löschen und Aktualisieren von Tischrechner-Betriebsmitteln das Vergleichen der gesamten SH-Listen mit den gesamten AH-Listen für eine Vielzahl von Tischrechnern umfassen kann, was hohe Netzwerktransportleistungen zur Folge haben kann. Die Komplexität der Such-Ivergleichsaufgabe nimmt sowohl mit der Anzahl von Tischrechnern als auch mit der Anzahl von verwalteten Betriebsmitteln zu. Unter Bezugnahme auf die veranschaulichenden Zeichnungen der Figur 4 ist eine starke Ausbreitung von AH-Listen und entsprechenden SH-Listen gezeigt. Jede AH- Liste und jede entsprechende SH-Liste betrifft einen anderen Tisch rechner. Das unter Bezugnahme auf Figur 3 erklärte Verfahren wird für jeden Tischrechner in dem Netzwerk ausgeführt. Da jedoch die Anzahl und Komplexität der verschiedenen Tischrechnerkonfigurationen und die Anzahl von enthaltenen Betriebsmitteln zunimmt, kann dieses Verfahren selbst praktisch undurchführbar werden, und zwar wegen der Schreibprobleme beim Aufrechterhalten verschiedener SH-Listen und der Computer- und Netzwerkleitungen, die zur Durchführung von SH mit AH-Vergleichen für jeden Tischrechner notwendig sind.
Ein früherer Versuch, die Verwaltung einer großen Zahl von Tischrechnern und Betriebsmitteln zu vereinfachen, besteht darin, Tischrechner zusammen zu gruppieren, um die Anzahl von Listen zu reduzieren. Anstatt eine unterschiedliche AH- und SH-Liste für jeden Tischrechner aufrechtzuerhalten, werden verschiedene AH- und SH-Listen für Gruppen von Tischrechnern aufrechterhalten. Folglich ist die Gesamtzahl von AH- und SH-Listen reduziert. Jedoch umfaßt eine derartige Gruppierung die Standardisierung der für Gruppierungen von Tischrechnern verfügbaren Betriebsmitteln. Diese Standardisierung beschränkt das Vermögen der Firmenpolitikverwalter, sowohl einen einzelnen Benutzerzugriff zu nur geeigneten Anwendungen als auch das Vermögen der Benutzer zu kontrollieren, ihre einzelnen Tischrechner individuell aufzumachen. Eine andere ähnliche Alternative benutzt einen auf Regeln basierenden Ansatz für die Gruppierung von Tischrechnern. Zum Beispiel könnten Tischrechner in Gruppen unterteilt werden, und Regeln könnten auferlegt werden, die einen Satz von Betriebsmitteln einer bestimmten Gruppe und einen anderen Satz von Betriebsmitteln einer anderen Gruppe zuweisen. Das Ergebnis jedoch ist dasselbe: Beschränkungen bei der Durchführung einer Firmenpolitik und im Vermögen der Benutzer, ihre einzelnen Tischrechner individuell aufzumachen.
Die Gruppierung von Betriebsmitteln erleichtert die Verwendung strukturierter SH-Listen, welche aus Unterlisten gebildete SH-Listen sind. Strukturierte SH- Listen können die Speicheranforderungen und den manuellen Aufwand für SH-Listen reduzieren, und zwar durch Vermeiden der Notwendigkeit, einen separaten Satz von Listen für jeden Computer zu speichern und aufrecht zu erhalten. Die Verwendung von strukturierten SH-Listen kann auch die Implementierung von Änderungen vereinfachen, da Änderungen an einer einzigen strukturierten Liste Auswirkungen auf mehrere Tischrechner in dem Netzwerk haben kann. Ein einzelner Satz von Änderungen kann eher einen Einfluß auf viele Tischrechner haben, als das Vornehmen einzelner Änderungen auf einzelne Tischrechner.
Unter Bezugnahme auf die veranschaulichenden Zeichnungen der Figur 5 ist eine SH-Liste gezeigt, die eine Zusammensetzung aus zwei Unterlisten ist. Wie in Figur 6 gezeigt, kännen Unterlisten unter SH-Listen aufgeteilt werden. Elemente kännen durch einen Verwalter basierend auf einer Analyse einer Betriebsmittelaufteilung unter den Tischrechnern gruppiert werden. Wenn eine Anforderung eines Tischrechners für eine Konfigurationsaktivität einen Vergleich einer SH-Liste für einen Tischrechner mit einer AH-Liste für jenen Tischrechner veranlaßt, dann kann die SH-Liste aus der Hauptuste und den Unterlisten erzeugt werden.
Eine Schwierigkeit bei der Automatisierung des SH-Listen- Erzeugungsverfahrens bestand darin, daß verschiedene Tischrechner verschiedene Hardware- und Software-Plattformen haben können. So umfaßt der SH-Listen-Erzeugungsprozeß häufig einen Schreibprozeß, bei dem Verwaltungspersonal bestimmt, welche Betriebsmittel ein Tischrechner haben sollte.
Um die Verwaltungsbelastung beim Erzeugen von SH-Listen zu vermindern, sind Tischrechner oft zusammen gruppiert und teilen sich gemeinsame SH- Listen. Wenn erst einmal die SH-Liste für einen Tischrechner oder eine Gruppe von Tischrechnern erzeugt worden ist, dann kann die SH-Liste mit den SH-Listen der verschiedenen Tischrechner verglichen werden, um "Bedarfs"-Listen zu erzeugen. Jedoch hat, wie vorstehend erklärt, das Gruppieren von Tischrechnern einen Preis zur Folge, was die Granularität der verfügbaren Betriebsmittel betrifft: Benutzer von Tischrechnern kännen zur nächstliegenden geeigneten Unterliste oder zum kleinsten gemeinsamen Teiler der Unterlisten wegen einem Unvermögen weitergeleitet werden, die speziellen Konfigurationserfordernisse von Tischrechnerbenutzern für einzelne Tischrechner vollständig darzulegen und zu verwalten.
Ein weiteres Problem bei der Verwendung von strukturierten SH-Listen besteht darin, daß die Tischrechnerplattform sich ändern kann, und die Betriebsmittel, die in einer SH-Unterliste identifiziert sind, können in der geänderten Tischrechnerplattform ungeeignet sein. Die Tischrechnerkonfiguration könnte in mehrfacher Weise geändert werden. Zum Beispiel könnte das Betriebssystem zwischen DOS, Windows und OS/2 wechseln. Die Zentraleinheit (CPU) könnte zwischen X386, X486 und Pentium- Typen wechseln. Der Drucker könnte zwischen Laser- und Matrixdrucker wechseln. Die Anzahl von Plattenlaufwerken könnte sich ändern. Die Größe des Speichers könnte sich ändern. Die Textverarbeitungs-Software könnte sich zwischen Word und Word Perfect ändern. Die Tabellenkalkulations- Software könnte sich zwischen Lotus 1-2-3 und Excel ändern. Andere beispielhafte veränderbare Tischrechnerkomponenten umfassen eine Maus, die Tastatur, ein Modem und ein CD-Laufwerk.
Ebenso könnte sich die Firmenpolitik, die auf einen Benutzer eines Tischrechners anwendbar ist, ändern. Zum Beispiel könnte ein Angestellter von der Eingangsbuchhaltung in die Ausgangsbuchhaltung versetzt werden. Folglich könnte zum Beispiel dieser Benutzer nun Zugang zur Verkäuferliste- Anwendung haben, hätte aber keinen Zugriff zur Kundenliste-Anwendung. Wohingegen vor der Versetzung derselbe Benutzer Zugang zur Kundenliste- Anwendung jedoch keinen Zugang zur Verkäuferliste-Anwendung gehabt hätte.
Auf Regeln basierende Listen können dynamischer sein, indem sie sich automatisch solchen Änderungen anpassen können. Zum Beispiel können Regeln wie etwa "falls Druckertyp A, dann verwende SH-Unterliste A; und falls Druckertyp B, dann verwende Unterliste B" angewendet werden. Jedoch können derartige Regeln eine zusätzliche Programmierleistung durch Netzwerkverwaltungspersonal notwendig machen, um Regeln für die Vielzahl von potentiellen Änderungen in der Tischrechnerplattform vorauszuberechnen und zu programmieren.
Deshalb hat eine Notwendigkeit für einen verbesserten und automatisierten Konfigurationsprozeß bestanden, der eine dynamische Rekonfiguration eines Tischrechners basierend auf Änderungen in der Firmenpolitik und Änderungen in der Tischrechnertechnik-Konfiguration ermöglicht. Die vorliegende Erfindung erfüllt diese Anforderungen.
Es hat auch eine Notwendigkeit dafür bestanden, das Verfahren des Vergleichens von SH-Listen mit AH-Listen zu optimieren, um zu bestimmen, welche Betriebsmittel an einem Tischrechner hinzugefügt, gelöscht oder aktualisiert werden müssen. Diese Notwendigkeit ist besonders akut in Netzwerken, die eine große Anzahl von Tischrechnern und eine große Anzahl von variablen Betriebsmitteln haben. In solchen großen Netzwerken kann eine Eins-zu-Eins-Näherung, bei der eine AH-Liste gegen eine erzeugte SH-Liste antritt, für eine große Anzahl von Tischrechnern und eine große Anzahl von Betriebsmitteln speicher-, verarbeitungs- und netzwerktransport-intensiv sein. Falls es zum Beispiel 5000 Tischrechner und 1000 mögliche Betriebsmittel gibt, dann könnten dort 5 Mio. Datensätze in den AH- und SH-Listen vorhanden sein. Falls es 100 Zeichen pro Datensatz gibt, dann könnte ein Gigabyte an Daten gespeichert werden müssen. Die vorliegende Erfindung wird auch der Anforderung gerecht, das Vergleichsverfahren zu verbessern.

ZUSAMMENFASSUNG DER ERFINDUNG

Ein System gemäß der vorliegenden Erfindung, wie es in den beigefügten Ansprüchen dargelegt ist, legt die Betriebsmittelanforderungen einzelner verteilter Computer basierend auf einem Sollte-Haben-SH(Should have)- Listen- (oder Objekt-) Schema fest. Das SH-Listenschema wird verwendet, um SH-Listen für einzelne verteilte Computer zu erstellen. Einzelne Bereits-Haben- AH(Already Have)-Listen können gespeichert werden oder können zur Konfigurationszeit für einzelne verteilte Computer erstellt werden. Ein neuartiges Unterscheid ungsverfahren wird verwendet, um Unterschiede zwischen SH-Listen (oder Objekten) und AH-Listen (oder Objekten) für einzelne verteilte Computer zu lokalisieren. Die Unterschiede zwischen SH- Listen und AH-Listen für die einzelnen verteilten Computer werden verwendet, um zu bestimmen, welche Elemente verglichen werden müssen, um einzelne Tischrechner zu aktualisieren.
Gemäß eines Aspekts der Erfindung kann eine Dynamikverkettung- Substitution verwendet werden, um die Zerlegung einer SH-Liste für einen einzelnen verteilten Computer aus einem verallgemeinerten SH-Listenschema zu ermöglichen, um den gegenwärtigen Anforderungen eines einzelnen verteilten Computers Rechnung zu tragen. Gemäß einem weiteren Aspekt der Erfindung werden Datenverg leiche während des Unterscheid ungsverfahrens angewendet, um die Unterlisten (oder Objekte) zu ermitteln und zu isolieren, für welche es Änderungen in dem Schema oder der AH-Liste für einen einzelnen verteilten Computer gegeben hat, und um so die Notwendigkeit für direkte Vergleiche von Elementen der AH-Liste mit Elementen der SH-Liste zu vermeiden, solche Änderungen zu identifizieren. Gemäß noch eines weiteren Aspekts wird während des Unterscheidungsverfahrens eine Prüfsummentechnik angewendet, um die Unterlisten (oder Objekte) einer SH- Liste zu ermitteln und zu isolieren, welche sich für einen besonderen verteilten Computer als Ergebnis von Änderungen in Dynamikverkettungswerten und/oder den Handlungen von Verwaltungspersonal geändert haben. Die vorliegende Erfindung automatisiert die Verwaltung von Änderungen in einer Umgebung verteilter Computer. Sie kann "Bedarfs"-Listen für verteilte Computer basierend auf der Wechselbeziehung von Konfigurationen einzelner verteilter Computer entwickeln. Wesentlich für diese Automation ist die Berechnung von Unterschieden zwischen bereits verteilten Betriebsmitteln und Betriebsmitteln, die auf dem verteilten Computern sein sollten.
Diese und andere Ziele und Vorteile der vorliegenden Erfindung werden Fachleuten anhand der folgenden detaillierten Beschreibung im Zusammenhang mit den beigefügten Zeichnungen klarer.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Figur 1 ist ein Blockschaltbild, das die Beziehung zwischen einem Rechenzentrum, das Verwalterterminals und einen Großrechner umfaßt, und Endbenutzern mit Tischrechnern darstellt;
Figur 2 ist eine verallgemeinerte Zeichnung einer typischen Gesellschaftsmanagementstruktur, welche einen Zentralrechner umfaßt, der über mehrere Verwalterterminals verwaltet wird, und die weiterhin eine Vielzahl von Tischrechnern umfaßt;
Figur 3 ist eine veranschaulichende Zeichnung, die zeigt, daß ein Vergleich einer Bereits-Haben-Liste und einer Solite-Haben-Liste zu einer Bedarfs-Liste führt, die Unterschiede zwischen der AH- und der SH-Liste einzeln aufführt;
Figur 4 ist eine veranschaulichende Zeichnung, die das Potential für eine starke Ausbreitung von AH-Listen und SH-Listen für ein Netzwerk darstellt, das eine Vielzahl von Tischrechnern umfaßt;
Figur 5 ist eine veranschaulichende Zeichnung, die die Verwendung einer strukturierten SH-Liste zeigt, die zwei Unterlisten aufweist; die SH-Liste wird mit einer AH-Liste verglichen, um zu einer Bedarfs-Liste zu kommen;
Figur 6 ist eine veranschaulichende Zeichnung, die die Aufteilung von Unterlisten zwischen verschiedenen strukturierten SH-Listen zeigt;
Figuren 7A - B zeigen Zeichnungen, die die Zerlegung einer dynamischen Verbindung als Teil des Erzeugungsprozesses einer SH-Liste aus Unterlisten entsprechend der vorliegender Erfindung darstellt; Figur 7a zeigt ein Schema mit einer dynamischen Verkettung; Figur 7) zeigt eine SH- Liste, die aus dem Schema der Figur 7A zerlegt ist.
Figur 8 zeigt ein veranschaulichendes Schema, das eine dynamische Verkettung entsprechend der vorliegenden Erfindung umfaßt;
Figur 9 stellt ein zuletzt aktiviertes Datum/Zeit-Feld (LUDT) in einer SH- Liste und ein zuletzt synchronisiertes Datum/Zeit-Feld (LSDT) in einer AH-Liste entsprechend der Erfindung dar;
Figur 10 verdeutlicht die Verwendung des LUDT/LSDT-Prozesses entsprechend der vorliegenden Erfindung;
Figur 11 verdeutlicht die Verwendung einer Objektkennungs-Prüfsumme (OIDC) und einer zuletzt-synchronisierten Prüfsumme (LSC), um eine Dynamikverkettungs-Substitution in einer Sollte-Haben-Liste entsprechend der vorliegenden Erfindung zu bestimmen;
Figur 12 verdeutlicht den Prozeß der Bestimmung einer teilweisen Änderung durch Analysieren eines SH-Listenschemas bei Verwendung sowohl eines LUDT/LSDT-Prozesses als auch eines OIDC/LSC-Prozesses gemäß der vorliegenden Erfindung;
Figuren 13A - B verdeutlichen ein beispielhaftes Schema, das dynamische Verkettungen auf Technikbasis gemäß der vorliegenden Erfindung enthalten;
Figuren 14A - B verdeutlichen ein beispielhaftes Schema, das sowohl eine auf Firmenpolitik basierende dynamische Verkettung als auch auf Technik basierende dynamische Verkettungen enthält;
Figuren 15A - B verdeutlichen das Schema der Figuren 14A - B, bei dem die auf Firmenpolitik basierende dynamische Verkettung und die auf Technik basierenden dynamischen Verkettungen zerlegt worden sind;
Figur 16 veranschaulicht eine beispielhafte Sollte-Haben(SH)-Liste, die aus dem Schema der Figuren 14A - B zerlegt worden ist;
Figur 17 zeigt eine veranschaulichende Bereits-Haben(AH)-Liste für einen beispielhaften Tischrechner;
Figur 18 veranschaulicht einen Unterscheidungsprozeß, der die SH-Liste der Figur 16 und die AH-Liste der Figur 17 umfaßt;
Figur 19 veranschaulicht die Ausgabe eines typischen Tischrechner- Abfrageprogramms;
Figur 20 ist ein veranschaulichendes Flußdiagramm, das einen durchgehenden Konfigurationsgesamtprozeß gemäß der vorliegenden Erfindung zeigt;
Figur 21 ist eine Konzeptansicht eines Vergleichs einer SH-Listenstruktur mit einer AH-Listenstruktur gemäß der vorliegenden Erfindung;
Figur 22 ist ein veranschaulichendes Flußdiagramm einer Sollte-Haben- Listen-Zerlegungsroutine gemäß der vorliegenden Erfindung;
Figur 23 ist ein veranschaulichendes Flußdiagramm einer "Verarbeite Datensatzfelder"-Routine gemäß der vorliegenden Erfindung;
Figur 24 ist ein veranschaulichendes Flußdiagramm einer Untersten- Unterscheidungsroutine gemäß der vorliegenden Erfindung; und
Figur 25 ist ein veranschaulichendes Flußdiagramm einer Berechnungsroutine für diskrete Änderung gemäß der vorliegenden Erfindung.

DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM

Die vorliegende Erfindung gibt ein neues Verfahren und ein System für zentralisierte Systemverwaltung der Betriebsmittel von verteilten Computern an. Die folgende Beschreibung wird dargelegt, um jeden Fachmann in die Lage zu versetzten, die Erfindung auszuführen und zu benutzen, und wird im Zusammenhang mit bestimmten Anwendungen und ihren Anforderungen angegeben. Verschiedene Modifikationen der bevorzugten Ausführungsform werden Fachleuten leicht klar, und die hierin definierten Grundprinzipien können auf andere Ausführungsformen und Anwendungen angewendet werden.

Verteilte Computer

Das Verfahren und das System der vorliegenden Erfindung werden verwendet, um Computer zu konfigurieren, die geographisch um eine Organisation herum verteilt sind und über ein Transportmedium oder Netzwerk verbunden sind. Der weitverbreitetste Typ eines "verteilten Computers" ist der Tischrechner bzw. Personalcomputer, der auch als ein "Desktop" bezeichnet wird. Jedoch sollte man verstehen, daß die Erfindung benutzt werden kann, um praktisch jeden verteilten Computer wie zum Beispiel LAN-Server, mehrere Großrechner, Laptop-Computer, Arbeitsplatzrechner und Computer, die mittels drahtloser Technik verbunden sind, zu konfigurieren.

Transportmedien

Die Techniken der vorliegenden Erfindung funktionieren mit Standard- Netzwerktransport- und Ferninstallations-Mechanismen. Das Transportmed ium kann zum Beispiel ein weiträumiges Netz, Ortsnetz, Wählnetz oder ein drahtloses Netz sein. Jedoch benötigt das Verfahren der Erfindung keinen Echtzeittransport von Informationen über ein Netzwerk. Zum Beispiel können Informationen wie etwa AH-Listen und Variablen-Werte oder Aktualisierungen für eine AH-Liste physikalisch via Kurier oder Postdienst unter Verwendung einer CD-ROM, von Disketten oder anderen tragbaren Speichermedien transportiert werden. Darüber hinaus kann das Transportmedium ein Echtzeit- Netzwerk in Kombination mit derartigen tragbaren Speichermedien umfassen.
Um einen Tischrechner unter Verwendung einer zentralen Steuerung zu installieren, werden Betriebsmittel, die ein Transportmedium wie etwa ein Netzwerk benutzen, zu dem Tischrechner transportiert. Betriebsmittel können zum Beispiel über ein Netzwerk entfernt installiert werden, das Software- "Scripts" verwendet, die bekannte Standard- oder kundenspezifische Prozeduren sind, welche bei der Software-Ferninstallation verwendet werden. Zum Beispiel kann eine Anwendung wie etwa ein Textverarbeitungsprogramm 50 Dateien enthalten. Diese 50 Dateien können in eine Dienst-Liste oder ein Dienst-Objekt gebündelt werden, die bzw. das zum Beispiel als ein bestimmtes Textverarbeitungsprogramm identifiziert werden kann. Um diesen Dienst auf einem bestimmten Tischrechner zu installieren, würden alle 50 Dateien zusammen mit einem Software-Script von einem zentralen Kontrolpunkt transportiert werden, das verwendet wird, um 50 Dateien zusammen mit den zugeordneten Icons, Ordnern usw. zu installieren.
Der Netzwerktransportmechanismus und die Software-Scripts, die für die Installierung von über ein Echtzeit-Netzwerk transportierte Dienste verwendet werden, werden aufgerufen, nachdem eine Feststellung gemäß dem System und den Verfahren der vorliegenden Erfindung getroffen worden ist, welche Betriebsmittel zu einem Tischrechner transportiert werden müssen. So umfaßt die vorliegende Erfindung einen Systemprozeß zur Feststellung, welche Betriebsmittel ein Tischrechner benötigt. Der Transportmechanismus von Betriebsmitteln über das Netzwerk und der Mechanismus für die eigentliche Installation von Betriebsmitteln auf einem Tischrechner sind Routine und wohlbekannt und brauchen hierin nicht weiter beschrieben zu werden.

Sollte-Haben-Listenschema

Unter Bezugnahme auf die veranschaulichenden Zeichnungen der Figur 7a ist ein typisches Soilte-Haben(SH)-Listenschema gemäß der vorliegenden Erfindung gezeigt. Das Schema stellt einen Satz von Beziehungen dar, die verwendet werden, um SH-Listen für einzelne verteilte Computer zu erstellen. Das Schema ist im wesentlichen eine aufgeteilte Datenstruktur. Das aufgeteilte Schema ist in dem verteilten Netzwerk aufgeteilt. Das Schema schließt sich an firmenpolitischen und technischen Überlegungen an und verwendet dynamische Verkettungen, um Sollte-Haben(SH)-Listen für unabhängige Tischrechner dynamisch zu erstellen. Für jeden Tischrechner kann das Schema verwendet werden, um einzelne SH-Listen für einzelne Tischrechner zu zerlegen. Das Schema kann aus einer Vielzahl von gewöhnlichen Systembaustein-Komponenten wie etwa Listen oder Objekten gebildet sein.

Abfrageprozeß

Der Abfrageprozeß wendet Standardtechniken an, um Informationen zu erhalten, die in der SH-Listenzerlegung für einzelne Tischrechner benötigt werden. Die erhaltenen Informationen werden verwendet, um Werte spezifisch benannter Variablen zuzuordnen, welche dann während der SH- Listenzerlegung verwendet werden, um dynamische Verkettungen mit zusammenpassenden Variablennamen zu zerlegen. Das Ziel des Abfrageprozesses kann der Tischrechner selbst sein (d.h. die physikalischen Attribute des Tischrechners - Prozessortyp, Drucker, Bildschirmtyp, usw.); ein Sicherheitssystem (z.B. IBM Resource Access Control Facility (RACF), Computer Associates-ACF2 oder Top Secret), ein Directory-System (z. B. Novell Bindery Services), oder jede andere Informationsquelle, die über eine Standard-Schnittstelle oder Programmierprozedur verfügbar ist. Es kann auch eine Datenbankquelle sein, die über eine Standardschnittstelle oder Programmierprozedur verfügbar ist. Es kann auch eine Datenbank oder eine Datei sein, welche Informationen enthält, die gelesen ("abgefragt") werden können, um Informationen zu gewinnen, die notwendig sind, den Tischrechner korrekt zu konfigurieren. Der Benutzer kann auch bezüglich informationen abgefragt werden, wie etwa Benutzeridentifikation, Paßwort, neues Paßwort, Abteilung, Stockwerk, physikalischer Ort usw.. Eine PCMCIA- Karte oder irgend eine andere Form eines tragbaren Mediums kann bezüglich Informationen abgefragt werden, die im Zusammenhang damit stehen, die Identität nachzuweisen (wie auch andere Arten von Identitätsüberprüfungen, zum Beispiel elektronische Unterschriftenüberprüfung, Magnetkartenleser, Rückantwortgeräte). Eine Ausgabe eines typischen Abfrageprogramms eines Tischrechners ist in Figur 19 gezeigt. Einige typische erhaltene Informationen und ihre Quellen sind:
Unter Bezugnahme auf die veranschaulichenden Zeichnungen der Figur 19, ist die Ausgabe eines typischen Abfrageprogramms gemäß der vorliegenden Erfindung gezeigt. Die Ausgabe ist typisch für den Typ eines Abfrageprogramms, der einen Tischrechner nach seiner Technikkonfiguration abfragt. Die Ausgabe in Figur 19 ist als Antwort auf Standardprogrammaufrufe an den Tischrechner erstellt. Das "Length"-Feld bezeichnet die Länge der variablen Werte. Das "Data"-Feld zeigt den tatsächlichen Variablenwert.
Jeder "Variable name" steht für ein Betriebsmittel des Tischrechners, welches sich ändern kann. Zum Beispiel steht der Variablenname AMEM für den am Tischrechner verfügbaren Speicherplatz. DOSVER steht für die DOS-Version, die auf dem Tischrechner verwendet wird. DRIVES bezeichnet jedes Plattenlaufwerk, das für den Tischrechner verfügbar ist. FPUTYPE bezeichnet den Coprozessortyp. FREEC steht für den freien Speicherplatz auf dem Laufwerk C. GAME gibt an, ob der Tischrechner einen Gameport besitzt. in diesem Fall gibt die "0" an, daß es keinen Garneport gibt. ZOS steht für das Betriebssystem, das momentan auf dem Tischrechner läuft.

Überblick über den durchgehenden Konfigurationsprozeß

Das Flußdiagramm der Figur 20 schafft einen Überblick über den durchgehenden Konfigurationsprozeß. Der Überprüfe-Schritt 40 ist optional (wie durch die Strichlinien angegeben). In Schritt 40 können die tatsächlichen inhalte des Tischrechners zu Beginn des Konfigurationsprozesses überprüft werden. Insbesondere wird der Tischrechner auf der Dateiebene abgefragt, um festzustellen, ob die vorher erzeugte AH-Liste immer noch gilitig ist. Falls festgestellt ist, daß die vorher erzeugte AH-Liste nicht mehr wiedergibt, was tatsächlich auf dem Tischrechner vorhanden ist, dann wird die vorher erzeugte AH-Liste überarbeitet, um die aktuellen Tischrechnerinhalte wiederzugeben, und die Olds werden geändert, und Änderungen werden an den geeigneten OIDCs und LUDTs vorgenommen, um anzuzeigen, daß sich der Tischrechner tatsächlich geändert hat. Dieser Überprüfungsschritt kann zum Beispiel durchgeführt werden, indem eine Abfrage-Software ähnlich der vorstehend beschriebenen verwendet wird.
im Ausieseschritt 42 werden die OIDC und das LSDT von der AH-Liste für den Tischrechner ausgelesen. Zum Beispiel Figur 9 veranschaulicht das Auslesen eines LSDTs für eine AH-Liste. Zum Beispiel Figur 11 veranschaulicht das Auslesen einer LSC für eine AH-Liste. Der Techngigie-Abfrageschritt 44 übernimmt die Tischrechnerabfrage, die zu einer Ausgabe von Variabienwerten führt, wie etwa jene in Figur 19 dargestellten. Der auf Firmenpoiitik basierende Abfrageschritt 46 übernimmt eine auf der Firmenpoiitik basierende Abfrage eines Benutzers und des Sicherheitssystems, um auf Firmenpolitik basierende Variablenwerte zu entlocken, wie etwa, welcher Abteilung ein Benutzer angehört, wie in Figur 14A. Dies ist ein optionaler Schritt (wie durch die Strichnien angegeben).
Die Sollte-Haben-Zerlegungsroutine 48 ist ein Prozeß (wie durch die vertikalen Linien innerhalb des Kästchens 48 angegeben), der detailliert in Figur 22 erklärt ist. Der Schritt 48 zerlegt eine SH-Liste aus einem Schema, wie etwa den in Figuren 7A, 8, 13A - B und 14A - B gezeigten Schemata. Die resultierende SH-Liste kann eine Liste sein, wie zum Beispiel die in Figur 12 gezeigte oder die in Figur 16 gezeigte.
Der Entscheidungsschritt 50 ermittelt an dem höchsten Unterscheidungsknoten oder in der höchsten Ebene in der SH-Liste, ob es Unterschiede zwischen der SH-Liste oder der AH-Liste gibt. Wenn weder das LSDT mit dem LUDT übereinstimmt, noch die OIDC mit der LSC übereinstimmt, dann wird eine Unterliste-Unterscheid ungsroutine 52 ausgeführt. Diese Routine ist unter Bezugnahme auf Figur 24 veranschaulicht. Es ist das Ziel der Unterlisten-Unterscheidungsroutine die Unterschiede zwischen der SH-Liste und der AH-Liste herauszufinden oder einzugrenzen.
Wenn jene Unterschiede erst einmal ermittelt worden sind, dann wird eine Verarbeitungsroutine 54 für teilweise Änderung ausgeführt. Die Verarbeitungsroutine für teilweise Änderung ist in Figur 25 veranschaulicht. Das Ziel dieser Routine ist es, die Änderungen tatsächlich auszuführen, um die Unterschiede zwischen der SH-Liste und der AH-Liste aufzulösen.
Der Synchronisationsschritt 56 aktualisiert das LSDT und die LSC der AH- Listen des Tischrechners. Das LSDT ist dem LUDT der zerlegten SH-Liste gleichgesetzt. Das LSC ist dem OIDC der zerlegtenten SH-Liste gleichgesetzt. Falls freilich in dem Entscheid ungsschritt 50 das LSDT mit dem LUDT übereinstimmt und die OIDC mit der LSC übereinstimmt, können die Schritte 52, 54 und 56 übersprungen werden.

Übersicht über den Prozeß des Vergleichens von AH-Listenstrukturen mit SH-Listenstrukturen

Unter Bezugnahme auf die veranschaulichende Zeichnung der Figur 21 ist eine verallgemeinernde Ansicht der AH-Listenstrukturen gezeigt, die mit den SH-Listenstrukturen verglichen werden. Die AH-Liste ist aus einer in Verbindung mit einem zu konfigurierenden Tischrechner gespeicherten AH- Datei erhalten. Die AH-Datei kann vor dem Unterscheidungsprozeß überprüft werden. Das SH-Schema ist mit dem Vorteil der Eingabe von Abfragesoftware zerlegt, um eine SH-Liste zu erstellen. Die höchsten Unterscheidungsebenen oder Entscheidungspunkte in den jeweiligen AH- und SH-Listen sind durch die LSDC und die OIDC dargestellt. Falls diese zusammenpassen, dann passen die Strukturen der AH-Liste und der SH-Liste zusammen. Wenn sie nicht zusammenpassen, dann sind die Strukturen der AH-Liste und der SH- Liste verschieden. Dann wird ein Ausweichen auf die nächste Entscheidungsebene durchgeführt, um die Stellen in der AH-Liste und der SH-Liste zu isolieren, an denen die Unterschiede tatsächlich vorhanden sind.
Dies wird durch Vergleichen der jeweiligen Olds entsprechender Ebenen der AH-Liste und der SH-Liste geschaffen. Zum Beispiel wird die AH-Liste am Entscheidungspunkt 58A mit dem OID des Entscheidungspunkts 58S verglichen. Das OID des Entscheidungspunkts 60A wird mit dem OID des Entscheidungspunkts 60S verglichen. Der OID des Entscheidungspunkts 62A wird mit dem OID des Entscheidungspunkts 62B verglichen.
Unterschiede zwischen den OIDs an entsprechenden Entscheidungspunkten oder -Ebenen in den AH- und SH-Listen zeigen an, daß die SH-Liste eine Strukturänderung an oder unter jenem Punkt oder jeder Ebene durchgemacht hat, seit die AH-Liste und die SH-Liste zum letzten Mal zerlegt wurden. Weiterhin ist ein Vergleich notwendig, in dem solche Strukturänderungen isoliert werden. Es sollte verstanden werden, daß Figur 21 nur die Verwendung von Prüfsummen betrifft, um Strukturänderungen zu identifizieren und nicht die Verwendung von Daten betrifft, um Änderungen in Elementen auf dem Tischrechner zu identifizieren; die Verwendung von Daten wird woanders in diesem Dokument beschrieben.

Erzeugung einer adaptiven Liste unter Verwendung eines dynamischen Austausches

Das veranschaulichende Schema der Figur 7A wird für die Erzeugung einer adaptiven SH-Liste bei Verwendung strukturierter Listen gemäß der vorliegenden Erfindung verwendet. Das Schema enthält eine dynamische Verkettung 30. Im Betrieb wird eine SH-Liste für einen bestimmten Tischrechner adaptiv aus dem Schema erzeugt und die spezifischen Variablen während des Abfrageprozeßes für jenen Tischrechner produziert. Das bedeutet, daß die dynamische Verkettung über die "klein"-Verknüpfung oder die "groß"-Verknüpfung abhängig von einem Wert für einen Variablennarnen "Größe" gemacht wurde, der durch die Abfragesoftware für den Tischrechner geschaffen wurde. Ein Prozeß für Dynamikverkettungs-Substitution berücksichtigt die dynamische Verkettung von Unterlisten (oder Objekten), die eine automatische Anpassung bzw. Adaption einer SH-Liste an vorhersagbare Änderungen in der Tischrechnerkonfiguration ermöglichen können. Das heißt, falls der Benutzer die Umgebung des Tischrechners ändert, werden verschiedene Variablennamen durch den Abfrageprozeß an das Schema übergeben. Die SH-Liste wird sich dementsprechend durch einen Prozeß von Dynamikverkettungs-Substitutionen anpassen. Die Verbindung, die mit dem Wert zusammenpaßt, der für den Variablennamen übergeben wird, wird in die SH-Liste für jenen Tischrechner ausgetauscht.
In einem Erzeugungsprozeß einer adaptiven Liste gemäß der vorliegenden Erfindung, führt eine Programmzweigabfrage wie etwa "Größe?" in Figur 7A zu einem Austausch für einen Wert "klein" oder einen Wert "groß" basierend auf einem Variabiennamen des Tischrechners, der durch die Abfrage-Software angeboten wird. Der Variablenwert "klein" oder "groß" wird durch Abfrage der Tischrechnerkonfiguration kurz vor der SH-Listen-Zerlegung ermittelt. So gibt die zerlegte SH-Liste aktuelle Tischrechnerbetriebsmittel-Anforderungen wieder, die im Zusammenhang mit der Variablen "Größe" stehen. "Größe", zum Beispiel, könnte im Zusammenhang mit der Speicherkapazität oder dem Plattenspeicherplatz des Tischrechners stehen.
Unter Bezugnahme auf die veranschaulichende Zeichnung der Figur 8 ist ein weiteres beispielhaftes SH-Listenschema gemäß der vorliegenden Erfindung gezeigt. Das Gesamtschema weist Unterlisten (oder Objekte) A, B und C auf. Die Unterliste A umfaßt Unterlisten (oder Objekte) A1 und A2. Die Unterliste B umfaßt Unterlisten (oder Objekte) B1, B2 und B3. Die Unterliste C umfaßt Unterlisten (oder Objekte) C1 und C2. Die Unterliste B2 umfaßt Unterlisten (oder Objekte) B21, B22 und B23. Die Verkettung zwischen der Unterliste B2 und den Unterlisten B22 und B23 ist eine dynamische Verkettung. Zu der Zeit, wenn eine SH-Liste aus dem Schema zerlegt wird, wird nur eine der Unterlisten B22 und B23 in das SH-Listenschema ausgetauscht. Die detaillierten Schritte, in denen ein typisches Schema zerlegt wird, um eine SH- Liste für einen bestimmten Tischrechner zu erzeugen, sind nachstehend beschrieben.
Die Verwendung eines Dynamikverkettungs-Austausches, um Tischrechnerplattform-Änderungen unterzubringen, wird durch das folgende veranschaulichende Beispiel besser verständlich. Eine Tischrechnerbetriebsmittel-Variable könnte die Betriebssystem-Variable mit dem Namen "Größe" (genauer gesagt "ZOS" in einer Ausführungsform) sein, welche zum Beispiel OS/2 oder Windows sein könnte. Eine Änderung in der Betriebssystemvariablen des Tisch rechners kann eine Unterliste von Betriebsmitteln, die ein Tischrechner haben sollte, ändern. Während eines Tischrechner-Konfigurationsprozesses setzt die Abfragesoftware Werte für Tischrechner-Variablennamen, wie etwa Betriebssystem, Mikroprozessortyp, Plattenspeicherplatz, Speichergröße, Interrupts und installierte Anwendungssoftware. Wie vorstehend erklärt, ist der Zweck des Abfrageprozesses, Werte für jeden derartigen Variablennamen zuzuweisen. Die Betriebssystemcharakteristik kann zum Beispiel durch die Variable mit dem Namen "Größe" in Figur 7A dargestellt werden, und mögliche Werte für die Größenvariable könnte "klein" für Windows und "groß" für OS/2 sein.
So wird eine Benennungsvereinbarung für das Zuweisen von Namen für Betriebsmittelvariable verwendet. Die Unterlisten (oder Objekte), die mit einer dynamischen Verkettung verbunden sind, entsprechen verschiedenen Tischrechnerkonfigurationselementen. Der Wert, der einer Variablen durch die Abfragesoftware zugewiesen ist, bestimmt, wie die dynamische Verkettung während der Erstellung der SH-Liste zerlegt wird. Die von dem Schema verwendeten Variablennamen können willkürlich sein. Jedoch korrelieren Variablennamen-Zuweisung bzw. -Werte mit Verkettungsnamen und Unterlisten (oder Objekten), die verwendet werden, um dynamische Verkettungen in dem SH-Listenschema zu spezifizieren. Auf diese Weise können die Namen verwendet werden, um dynamische Verkettungen während der SH-Listenzerlegung zu zerlegen.
Zur Zeit der SH-Listenzerlegung können die Variablennamen und Ihre Werte von dem Tischrechner zu dem Computerort transportiert werden, an welchem die SH-Listenzerlegung auftreten soll. Der Transport findet über Standartnetzwerkverbind ungen unter Verwendung von Standard netzwerk- Transportprotokollen statt. Der SH-Listenzerlegungsprozeß tritt normalerweise an einem zentralen Steuerrechner auf. Jedoch könnte er statt dessen an dem Tischrechner durchgeführt werden. Die SH-Listenzerlegung ist Teil des Konfigurationsprozesses, der durch jede Anzahl von Ereignissen, wie etwa durch einen Tischrechner-Zeitgeber, durch "Boot-Prozeduren", oder durch den Benutzer, der ein geeignetes lcon auswählt, ausgelöst werden. Während der SH-Listenzerlegung werden Unterlisten (oder Objekte) in eine SH-Liste basierend auf Werten für die Variablennamen, die während des Abfrageprozesses zugewiesen wurden, eingefügt. Dieser Prozeß tritt für jedes variable Tischrechnerbetriebsmittel auf. So kann sich die SH-Liste des Tischrechners an die Tischrechner-Konfigurationsänderungen anpassen.
In Fortsetzung des oberen Beispiels, in dem "klein" einem Windows- Betriebssystem zugeordnet ist und "groß" einem OS/2-Betriebssystem zugeordnet ist, benötigt Windows einen Satz von Betriebsmitteln, der mit den Elementen in der Unterliste (oder Objekt) mit dem Namen "klein" entspricht. Und OS/2 benötigt einen anderen Satz von Betriebsmitteln, der den Elementen in der Unterliste (oder Objekt) mit dem Namen "groß" entspricht. Zum Beispiel die verschiedenen Unterlisten (oder Objekte) könnten verschiedene Anwendungen darlegen, die verschiedene Grafikschnittstellenmodule für die Verwendung mit Windows einerseits und mit OS/2 andererseits verwenden.
Da es vorhersehbar ist, daß ein Tischrechner-Betriebssystem von einem Typ zu einem anderen Typen wechseln kann, kann eine dynamische Verkettung in das SH-Listenschema eingebaut werden, um die Betriebssystemvariable zu handhaben. In dem vorstehenden Beispiel wird dann, wenn die SH-Liste von dem Schema zerlegt wird, eine Verkettung bevorzugt aus einer Unterliste (oder Objekt) erzeugt, welche die aktuellen Betriebsmittelerfordernisse der bestimmten Tischrechnerunterkonfiguration wiedergibt.
SH-Listenschemazerlegungen für eine Vielzahl von Tischrechnern könnten außerhalb der Spitzenlastzeiten durchgeführt werden. Das Ergebnis bestünde aus einer Vielzahl von SH-Listen. Diese SH-Listen könnten dann zu lokalen Servern für die Unterscheidungs- und Vergleichsprozesse verteilt werden. Während verkehrsreicher Netzwerkzeiten könnte der nachfolgend beschriebene Unterscheidungsprozeß unter Benutzung lokaler Server und Tischrechner durchgeführt werden. Dieser Weg reduziert sowohl Netzwerkverkehr als auch Zentralverarbeitungsanforderungen während Spitzen lastzeiten.
Darüber hinaus können zerlegte SH-Listen einzelne Tischrechner oder ganze Workgroups betreffen. Dies ist wichtig, da in dem Fall, in dem eine gesamte Workgroup dieselbe zerlegte Sollte-Haben-Liste aufweist, der Zerlegungsprozeß nur einmal durchgeführt werden müßte, und jede einzelne Bereits-Haben-Liste eines Computers könnte davon unterschieden werden. Es zeigt auch, daß der Prozeß skalierbar ist, gültig für die meisten diskreten Tischrechnerkonfigurationen bis hin zu zum größten Teil herstellerkompatiblen Gruppen von Tischrechnern.
Ein Vorteil der adaptiven SH-Listenerzeugung unter Verwendung von Dynamikverkettungs-Substitution besteht darin, daß sie die Notwendigkeit für das Eingreifen eines Verwalters reduziert, wenn die Umgebung des Tischrechners geändert wird. Die Verwendung von Bennenungsvereinbarungen gemäß der vorliegenden Erfindung erlaubt die Zerlegung aus einer SH-Liste, die die besonderen Erfordernisse einzelner Tischrechnerumgebungen ohne Ausweg zu auf Regeln basierender Programmierung wiedergibt. Die neuartige Verwendung von dynamischen Verkettungen erlaubt deshalb in vorteilhafter Weise Benutzern von Tischrechnern, ihre Tischrechner individuell aufzumachen, um ihre besonderen Anforderungen ohne Auferlegen einer übermäßigen Verwaltungsbelastung für die Netzwerkverwalter zu erfüllen. Die Verwendung dynamischer Verkettungen in Verbindung mit Abfragesoftware, die Werte Variablen zuordnet, die verwendet werden, um solche dynamischen Verkettungen aufzulösen, bietet die automatische (verwalterlose) Verbindung von Unterlisten (oder Objekten) passend für einzelne Tischrechner. Diese Unterlisten (oder Objekte) enthalten die Informationen, die benötigt werden, um den Tischrechner während des Konfigurationsereignisses zu aktualisieren.
Ein weiterer Vorteil der SH-Listenerstellung unter Verwendung eines dynamischen Verkettungsaustausches besteht darin, daß sich die SH-Listen automatisch an die Firmenpolitik- und Technikkonfigurationen der einzelnen Tischrechner anpassen können. Wie nachstehend erklärt, kann das Schema sowohl dynamische Verkettungen im Zusammenhang mit Firmenpolitiküberlegungen als auch dynamische Verkettungen in Zusammenhang mit technischen Überlegungen enthalten. Während der Tischrechnerkonfiguration wird die SH-Liste aus dem Schema durch Feststellen zerlegt, welche firmenpolitischen Verkettungen und welche technischen Verkettungen sich an den Tischrechner in seiner gegenwärtigen Konfiguration und mit seiner gegenwärtigen Benutzerautorisierungsebene wenden. Die technische Konfiguration des Tischrechners kann sich unabhängig von dem Netzwerkverwalter ändern. Da jedoch das SH- Listenschema dynamische Verbindungen aufweisen kann, die sich automatisch an derartige Änderungen anpassen können, kann eine SH-Liste dennoch automatisch erzeugt werden, selbst wenn sich eine Umgebung des Tischrechners ändert. Darüber hinaus können Verwalter den SH- Listenzerlegungsprozeß basierend auffirmenpolitischen Überlegungen durch Ändern der dynamischen Verkettungen ändern, die im Zusammenhang mit politischen Faktoren stehen. Deshalb kann ein SH-Listenschema eine SH-Liste erzeugen, die sich durch Verwaltungspersonal auferlegte firmenpolitische Änderungen und durch Benutzer von Tischrechnern durchgeführte Änderungen der Desktop-Technik anpassen.
Zusammengefaßt kann der Benutzer (oder jemand anderes) die Tischrechnerkonfiguration ändern. Das Abfrageprogramm weist Werte zu, die den gegenwärtigen Zustand von variablen Tischrechnerbetriebsmitteln darstellen. Dynamische Verkettungen in dem Schema werden basierend auf den zugewiesenen Werten zerlegt. Einzelne SH-Listen für Tischrechner werden so erzeugt, indem die Verkettungen zerlegt werden. Die einzelnen SH- Listen werden verwendet, um zu bestimmen, welche Betriebsmittel der Tischrechner "benötigt".
So erlaubt der Konfigurationsprozeß gemäß der vorliegenden Erfindung die Automatisierung der Systemverwaltung durch Trennen firmenpolitischer Entscheidungen von Entscheidungen betreffend technischer Bauweise. Die Verwendung von Variablen und dynamischen Verkettungen in dem Prozeß technischer Bauweise erlaubt Anforderungen bezüglich der technischen Bauweise, um sowohl firmenpolitische Änderungen als auch Änderungen in der Tischrechnerplattform ohne Eingreifen von Verwaltungspersonal anzupassen.

Datumsänderungsermittlung

Unter Bezugnahme auf die veranschaulichenden Zeichnungen der Figur 9 ist die Verwendung eines zuletzt aktualisierten Datum/Zeit-Feldes (LUDT) und des zuletzt synchronisierten Datum/Zeit-Feldes (LSDT) gezeigt, die Netzwerktransport, Verarbeitung und Dateiorganisation reduzieren kann, welche dem Vergleich von SH-Liste und Bereits-Haben(AH)-Listenelementen zugeordnet sind. Das LUDT für ein Element in einer SH-Liste steht für das letzte Datum den letzten Zeitpunkt an dem das Element aktualisiert oder der SH-Liste hinzugefügt wurde. Ein "Element" kann zum Beispiel eine Datei (Programm- oder Datendatei) und/oder ein Parameter, wie etwa ein Transaktionsname oder eine Datenbankdefinition sein. Kunden-Server verwalten oft Verzeichnisse von Namen, durch die Kunden in Verbindung stehen. Die Namen in diesen Dateien können "Elemente" sein.
LUDTs hängen mit Schemata und zerlegten SH-Listen zusammen. Wann immer ein Schema aktualisiert wird, wird das LUDT für den Schemaeintrag aktualisiert. Dies bezeichnet eine Schemakonfigurationsänderung. Wenn später Unterlisten (oder Objekte) dem Schema hinzugefügt werden, dann werden die Daten für jene späteren Unterlisten (oder Objekte) nach oben durch das Schema weitergegeben (perkuliert), und ein neues letztes LUDT wird durch den Schemaeintrag zugewiesen. Ein LUDT kann sich auf zweierlei Art ändern: zu der Zeit, zu der das Schema ursprünglich konfiguriert wird, und wenn wegen einer Änderung in der Schema-Unterliste (oder in dem Objekt) ein letztes LUDT durch das Schema hindurch bis zur Spitze des Schemas aufwärts perkuliert. So kann das LUDT verwendet werden, um Änderungen in Betriebsmitteln in dem Schema zu identifizieren.
Die LSDTs hängen mit den einzelnen Tischrechnern zusammen. Das LSDT steht für das letzte Datum/den letzten Zeitpunkt an dem die SH-Liste (oder das Objekt) für einen Tischrechner und die AH-Liste (oder das Objekt) für diesen Tischrechner synchronisiert wurde. Die vorliegende Erfindung kann einen Eins-zu-Eins-Vergleich aller SH-Listenelemente mit allen AH- Listenelementen vermeiden, wenn es keine Änderungen an früher konfigurierten Betriebsmitteln gegeben hat. Beim Vergleichen des neuesten LUDTs für alle Einträge in einer erzeugten SH-Liste mit dem LSDT für eine AH-Liste eines Tischrechners kann eine Feststellung getroffen werden, ob ein Vergleich der Elemente von SH- und AH-Listen nqtwendig ist. Falls alle der LUDTs in der SH-Liste früher als das LSDT für die AH-Liste des Tischrechners sind, dann haben sich keine vorher definierten Betriebsmittel in der SH-Liste seit der letzten Synchronisation der SH- und AH-Listen für den Tischrechner geändert, und keine Listen müssen für Änderungen verglichen werden. Das heißt, falls die AH-Liste des Tischrechners und seine SH-Liste zuletzt synchronisiert wurden, nachdem die letzten Schemabetriebsmittel zum letzten Mal aktualisiert wurden, dann wird kein weiterer Vergleich benötigt.

Bestimmung einer teilweisen Datenänderung

Unter Bezugnahme auf die veranschaulichende Zeichnung der Figur 10 umfaßt eine andere Verwendung von Daten, um Änderungen zu isolieren, das Aufrechterhalten eines Gesamt-LUDTs für die gesamte SH-Liste. Diese Möglichkeit erfordert die Aufrechterhaltung von Gesamt-LUDTs für jede Unterliste innerhalb der SH-Liste. Der Gedankengang besteht darin, falls die Gesamt-LUDTs für jede der SH-Listen-Unterlisten für einen bestimmten Tischrechner früher als das LSDT des Tischrechners sind, dann können sich die Inhalte der erzeugten SH-Listenbetriebsmittel-Liste durch Hinzufügen, Löschen oder Aktualisieren seit der letzten Synchronisation der SH- und AH- Listen für den Tischrechner nicht geändert haben. Dieser Ansatz kann als verbessertes LUDT (ELUDT) bezeichnet werden. Die Verwendung des ELUDTs vermeidet flache Listen. Das ELUDT erfordert, daß die LUDT- Informationen aufwärts durch das Schema perkulieren. Ein LUDT eines "Dienstes" ist so spät wie die Aktualisierungszeit/das Aktualisierungsdatum seines zuletzt aktualisierten Betriebsmittels. Dieses LUDT ist sein ELUDT.
Die LUDT- oder ELUDT-Prozesse können während des SH-Liste/AH-Liste Vergleichs verwendet werden, um den Eins-zu-Eins-Vergleich aller AH- Listeneemente mit allen SH-Listen- oder Unterlisten-Elementen zu umgehen, wenn keine Ergänzungen, Löschungen oder Aktualisierungen in die SH-Liste oder die Unterliste (oder Objekte) seit dem Datum/Zeitpunkt der letzten Synchronisation eingefügt worden sind. Im Wesentlichen umfaßt der LUDT- oder ELUDT-Prozeß das Heranfahren an die LUDT- oder ELUDT- Informationen, um zu Bestimmen, ob Änderungen aufgetreten sind. Der Vergleich von Datums-/Zeit-Informationen in der zerlegten SH-Liste und der AH-Liste für einen vorgegebenen Tischrechner erleichtert einen Unterscheid ungsprozeß, der isolieren kann, welche Betriebsmittel aktualisiert werden müssen, ohne einen Element-für-Element-Vergleich von Sollte-Haben- Listenelementen und AH-Listenelementen durchlaufen zu müssen.
Es wird deutlich, daß das LUDT nützlich für "flache" Listen ist, während das ELUDT nützlich für strukturierte Listen ist. Das LUDT kann geänderte Betriebsmittel identifizieren. Das ELUDT ist auf der Unterlistenebene nützlich, um das Hinzufügen oder Löschen von gesamten Unterlisten von Betriebsmitteln zu identifizieren. Es können mehrere Ebenen von Unterlisten und mehrere Ebenen von ELUDTs vorhanden sein.
Die Zeichnung der Figur 10 zeigt die Anwendung des LUDT-Prozesses in Verbindung mit einer SH-Liste. Das LSDT für die AH-Liste eines Tischrechners wird mit der Gesamt-LUDT einer SH-Liste und mit den LUDTs für jede der zwei SH-Unterlisten verglichen, um zu bestimmen, ob irgendein Eins-zu-Eins- Unterlistenvergleich notwendig ist. In diesem Fall ist, da das LSDT später ist als jedes der drei LUDTs, die der SH-Liste zugeordnet sind, kein weiterer Vergleich notwendig.
Der ELUDT-Prozeß funktioniert nicht nur für Untersten, sondern auch für gleichartige zwischenverbundene Strukturen wie etwa Objekte. Falls zum Beispiel Objekte anstelle von Listen aufrechterhalten werden, dann werden gegenwärtige ELUDT-Informationen für die Objekte aufrechterhalten. Das Verfolgen von ELUDTs für eine Hauptuste und für alle Unterlisten kommt dem Übernehmen von ELUDT-Informationen innerhalb von Objektklassen gleich.
Die ELUDT-Informationen werden als Teil des Unterscheid ungsprozesses überprüft, um zu entscheiden, ob ein Element-für-Element-Vergleich des konkreten Vergleichsprozesses der konkreten Inhalte von SH- und AH-Listen notwendig ist. Konkrete Vergleiche werden nur verlangt, wenn die SH-Liste oder die Unterliste sich seit der letzten Synchronisation der AH- und SH-Liste des Tischrechners geändert haben. Darüber hinaus will, wie nachfolgend erklärt, ein Vergleichsprozeß gemäß der vorliegenden Erfindung so wenige Elemente wie nötig direkt vergleichen, um die AH-Liste mit der SH-Liste zu aktualisieren. Dies begrenzt den Netzwerktransport und reduziert die Verarbeitungs- und Dateiorganisation.

Bestimmung einer Schemaänderung

Das System und das Verfahren gemäß der vorliegenden Erfindung erlaubt in vorteilhafter Weise die Bestimmung von Änderungen in einem Schema über dynamische Verkettungen hinaus. Dies ist wichtig. Der Prozeß umfaßt die dynamische Erzeugung einer SH-Liste aus einem Schema, wenn ein Tischrechner konfiguriert werden soll. Um die Netzwerkgesamtkosten, die einem Element-für-Element-Vergleich von Komponenten des Tischrechners mit in der SH-Liste aufgeführten Komponenten eigen sind, zu vermeiden, ist es wünschenswert, einen Mechanismus zu haben, um zu bestimmen, ob in der SH-Liste oder in der AH-Liste Änderungen aufgetreten sind, die einen weiteren detaillierten Vergleich erfordern würden. Falls keiner dieser Änderungen aufgetreten ist, dann ist kein detaillierter Vergleich notwendig. Der Netzwerktransport wird dabei reduziert.
Der Prozeß der Bestimmung von Schemaänderungen umfaßt zuerst das Bestimmen, ob Strukturänderungen in der SH-Liste aufgetreten sind, und zwar durch Vergleichen eines Prüfsummenwerts für die SH-Liste mit einem entsprechenden Prüfsummenwert der AH-Liste des Tischrechners. Nicht zusammenpassende Prüfsummen geben Strukturänderungen in der SH-Liste an. Falls die Prüfsummenwerte nicht zusammenpassen, dann werden die SH und AH-Listen verglichen, um die Auswirkung der Strukturänderung zu bestimmen. Falls die Prüfsummenwerte zusammenpassen, dann wird eine Beziehung zu den LUDT-/LSDT-Informationen hergestellt, um zu bestimmen, welche Komponenten innerhalb derselben Struktur aktualisiert worden sind.
Der LUDT-/LSDT-Prozeß allein ist nicht geeignet, Änderungen zu identifizieren, bei denen eine dynamische Verkettung beteiligt ist. Der Grund dafür ist, daß eine Dynamikverkettungs-Änderung zu einem unterschiedlichen, noch "älteren" LUDT führen kann. Speziell eine aufgrund einer unterschiedlichen Dynamikverkettungs-Substitution ausgetauschte Unterliste kann in der Tat ein früheres Datum als eine vorher ausgetauschte Unterliste haben. Das Ergebnis ist ein neues und früheres LUDT. Jedoch wird bei Verwendung des LUDT- /LSDT-Prozesses allein keine Änderung in der SH-Unterliste identifiziert werden, weil das LUDT immer noch früher als das LSDT ist. So sind die Datumsvergleiche allein unzuverlässig beim Identifizieren von Änderungen, die durch unterschiedliche dynamische Verkettungszerlegungen in der SH-Liste herbeigeführt wurden.
Deshalb besteht ein potentielles Problem bei dem LUDT-/LSDT-Prozeß darin, daß sich die Umgebung des Tischrechners nach der letzten Synchronisation der AH- und SH-Listen für einen Tischrechner geändert haben könnte. Speziell das LUDT für jede zerlegte SH-Liste und jede SH-Unterliste, das in der letzten Synchronisation verwendet worden ist, könnte älter als das LSDT sein, aber die Tischrechnerplattform könnte sich dennoch seit der letzten Synchronisation geändert haben. Das heißt, nach der letzten Synchronisation könnte sich eine Tischrechnervariable geändert haben. Das Ergebnis könnte in einer von der vorhergehenden Synchronisation unterschiedlichen dynamischen Verkettungszerlegung bestehen. Diese Änderung in der Variablen, wie etwa eine Änderung zum Beispiel des Bildschirmtyps, ist normalerweise durch den LUDT-/LSDT-Prozeß alleine nicht feststellbar, weil, wie vorstehend beschrieben, eine Dynamikverkettungs-Änderung einen Satz unterschiedlicher aber technisch "alter" Elemente einbringen kann oder die "letzten" Elemente in einer Unterliste, die bewirken, daß das LUDT auf eine "ältere" Ebene zurückkehrt, fallenlassen (entfernen) kann. Dennoch kann die Änderung in Tischrechnervariablen die Betriebsmittel verändern, die ein Tischrechner haben sollte. So ist es wichtig, solche Änderungen zu bestimmen.
Eine Verweistabelle von Austauschwerten, die während des SH- Listenerzeugungsprozesses verwendet wurden, kann gespeichert werden, um benötigte SH-Listenänderungen aufgrund von Änderungen in dem SH- Schema, die durch Tischrechnervariable verursacht wurden, zu identifizieren.
Ein weiterer Prozeß gemäß der Erfindung zum identifizieren von Änderungen in den Betriebsmitteln, die ein Tischrechner haben sollte, benutzt einen Prüfsummenprozeß, um Schemaänderungen zu detektieren. Diese Schemaänderungen können statische (verwalterimplementierte) Änderungen sein; oder sie können das Ergebnis von Änderungen in dynamischen Verkettungen sein.
Ein einziger numerischer Kennzeichner für jede Liste (oder jedes Objekt), der als Objektkennzeichner (OID) bezeichnet werden kann, wird jedem Betriebsmittel und jeder Unterliste (oder Objekt und irgend welchen anderen verbindenden Elementen oder Unter-Unterlisten) zugewiesen, die verwendet werden, die SH-Liste zu erzeugen. Der OID ist wie der Fingerabdruck für ein Betriebsmittel.
Während der Erzeugung einer SH-Liste wird der OID jedes Betriebsmittels oder jeder Unterliste, die in der SH-Liste enthalten ist, verarbeitet, wobei Routinenprüfsummenverfahren wie CRC oder Sum/Product verwendet werden. Eine Gesamt-OID-Prüfsumme (OIDC) wird für die SH-Liste berechnet. Wenn die Gesamt-OIDC gleich der zuletzt synchronisierten Prüfsumme (LSC) für den Tischrechner des Benutzers ist, (welche einfach die OIDC aus dem letzten Konfigurationsprozeß ist), dann hat sich die Gesamtstruktur der erzeugten SH-Liste nicht geändert. Dies ist unbeachtlich für die Verwendung oder die Anzahl von dynamischen Verkettungen. Der LUDT-Prozeß wird angewendet, um zu bestimmen, ob es Änderungen in den Inhalten jeder bestimmten Liste oder Unterliste gegeben hat, wo sich die Struktur, wie etwa die dynamische Verkettung, (identifiziert durch die OIDC) nicht geändert hat.
Der OID-Prozeß ermittelt Schemastrukturänderungen. Der LUDT-Prozeß bestimmt Änderungen in den Inhalten von einzelnen Betriebsmittellisten oder Unterlisten. Der OID-Prüfsummenprozeß zusammen mit dem LUDT-Prozeß erlaubt es, daß der Eins-zu-Eins-Vergleich von AH-Liste und SH-Liste in dem Fall umgangen wird, in dem keine Änderungen stattgefunden haben, selbst wo ein Dynamikverkettungs-Austausch oder andere Dynamik- oder Erzeugungsverfahren angewendet worden sind.
Unter Bezugnahme auf die veranschaulichende Zeichnung der Figur 11 ist ein Beispiel einer einfachen Schemaänderungsbestimmung (keine Datumsänderungsbestimmung) unter Verwendung einer OID-Prüfsumme gezeigt, um eine Dynamikverkettungs-Substitution zu bestimmen. Die Gesamt- OIDC der SH-Liste wird mit der LSC der AH-Liste des Tischrechners verglichen. Falls die Gesamt-OIDC nicht gleich der LSC ist, welche den Gesamt-OIDC der letzten Konfiguration darstellt, dann hat eine Änderung in der Zusammenstellung der Unterliste stattgefunden. In diesem Fall wird die zuletzt erzeugte OIDC zur neuen LSC, und weiterhin wird ein Vergleich gefordert, um die detaillierten Änderungen zu bestimmen.

Bestimmung einer teilweisen Schema-/Datums-Änderung

Figur 12 zeigt ein Beispiel einer Bestimmung einer teilweisen Schema- /Datumsänderung gemäß der Erfindung. Der Prozeß bestimmt sowohl die Änderungen in Verkettungen als auch Änderungen innerhalb der Betriebsmittelunterlisten. Zum Beispiel unter Bezugnahme auf Figur 8 kann ein Prüfsummenprozeß verwendet werden, um zu bestimmen, ob der Verkettungsaustausch von B22 oder B23 von dem Verkettungsaustausch verschieden ist, bei dem zum letzten Mal die AH- und SH-Listen synchronisiert wurden. Wieder unter Bezugnahme auf Figur 12 wird zum Beispiel der LUDT- Prozeß verwendet, um zu bestimmen, ob sich ein vorhandener Betriebsmitteleintrag innerhalb irgendeiner der Unterlisten geändert hat. Zum Beispiel kann eine Unterliste das Betriebsmittel "ggg" aufweisen. Die Parameter innerhalb des Betriebsmittels "ggg" können sich jedoch geändert haben. Diese Änderung in den Betriebsmittelparametern "ggg" wird durch Datumsänderungen festgestellt. Nur Unterlisten und Betriebsmittel, für welche Änderungen aufgetreten sind, benötigen einen Vergleich, wie im Zusammenhang in Figur 12 erklärt ist.
Unter Bezugnahme auf Figur 12 ist ein Bestimmungsprozeß für eine teilweise Datumsänderung gezeigt. Ein letztes LUDT wird für die Gesamt-SH-Liste erzeugt, während die SH-Liste erzeugt wird, und ein LLUDT wird für die AH- Liste aufrechterhalten. Ebenso wird für jede Unterliste ein separates LLUDT aufrechterhalten. Um weitere Vergleiche zu vermeiden, muß das LLUDT für eine vorgegebene Unterliste früher als das LSDT sein. Das Bestimmungsverfahren für eine teilweise Änderung umfaßt separate Änderungsbestimmungen und -vergleiche für die verschiedenen Unterlisten. Das LLUDT für Unterliste A bezeichnet das letzte LUDT aus allen Betriebsmitteleinträgen in Unterliste A. Das LLUDT für Unterliste B bezeichnet das letzte LUDT aus allen Einträgen in Unterliste B. Ebenso ist für die AH-Liste ein LLUDT für die Unterliste A aufrechterhalten und eine LLUDT für Unterliste B aufrechterhalten. So sind LUDT- und LLUDT-Werte sowohl für die SH-Liste als auch für die AH-Liste aufrechterhalten.
Eine Unterlisten-OIDC (SOIDC) wird erzeugt, während die SH-Liste erzeugt wird. Eine Tischrechner-LSC ist für die AH-Liste zu jeder Zeit gespeichert, zu der die AH-Liste und die SH-Liste währen des Konfigurationsprozesses synchronisiert werden. Die LLUDT-/SOL DC-Informationen für die SH-Liste werden mit dem LSDT der LSC für die gesamt AH-Liste verglichen. Falls das LLUDT mit dem LSDT zusammenpaßt und die SOIDC mit der LSC zusammenpaßt, dann ist kein weiterer Vergleich der Verkettungen oder Betriebsmitteleinträge in der AH-und SH-Liste notwendig. Falls sie jedoch nicht übereinstimmen, dann geht der Änderungs-Bestimmungs- /Unterscheid ungsprozeß weiter.
Insbesondere der Vergleich der SOIDC und der LSC für Unterlisten A der SH- Liste und der AH-Liste zeigt, daß für diese Unterlisten die SOIDCs und die LSCS zusammenpassen. So hat keine Änderung in den Verkettungen oder den Betriebsmittelinformationen in Unterste A für die SH-Liste oder die Unterliste A für die AH-Liste stattgefunden. Für Unterliste B jedoch sind die SOIDCs verschieden. Dies zeigt eine Verkettungsänderung in dem Schema an. Darüber hinaus sind die LUDTs ebenfalls unterschiedlich. Dies zeigt eine Aktualisierung in einem Betriebsmitteleintrag in Unterliste B an.
So passen die Inhalte der Unterliste B der SH-Liste nicht mehr mit den Inhalten der Unterliste der AH-Liste zusammen. Ein weiterer Vergleich der AH- Unterliste B und der SH-Unterliste B wird benötigt. Dieser Vergleich kann Netzwerktransport der SH-Unterliste zu dem Tischrechner für einen Vergleich mit einer AH-Unterliste des Tischrechners mit sich bringen. Insbesondere die spezifischen Inhalte der Unterliste der SH-Liste, nämlich die als "eee" bezeichnete Datei mit dem OID 005 sind von der als "fff" bezeichneten Datei verschieden, die ein OID von 009 aufweist.
Es wird deutlich, daß die vorstehende Beschreibung ein Beispiel für die Bestimmung teilweiser Änderungen ist, weil vielmehr Vergleiche an Teilstücken des Schemas als an dem gesamten Schema durchgeführt werden. Keine Änderungen zwischen der SH-Unterliste A und der AH- Unterliste A werden bestimmt. Also wird kein weiterer Vergleich der SH- Unterliste A und der AH-Unterliste A durchgeführt. Jedoch werden Änderungen zwischen der SH-Unterliste B und der AH-Unterliste B ermittelt. Also wird kein weiterer Vergleich der AH-Unterliste A und der SH-Unterliste B durchgeführt.
Beim vorliegenden Ausführungsbeispiel der Erfindung werden die Wertenamen, die durch die Abfragesoftware erzeugt wurden, von dem Tischrechner zu einem Zentralrechner (der ein lokaler Steuerpunkt oder ein zentraler Steuerpunkt sein kann) transportiert. Die SH-Listenzerlegung wird durch den Steuerpunktcomputer durchgeführt. Die LUDT- und OIDT- Informationen aus der zerlegten SH-Liste werden zu dem Tischrechner transportiert, wo der Unterscheidungsprozeß stattfindet. (Der Unterscheid ungsprozeß kann auch an dem Steuerpunktcomputer stattfinden, der die SH-Listenzerlegung durchgeführt hat, oder an einem anderen festgelegten Steuerpunktcomputer.) Falls Unterschiede bestehen, dann werden die durch die nicht zusammenpassenden OIDCs dargestellten Untersten für einen Element-für-Element-Vergleich von dem Steuerpunkt zu dem Tischrechner transportiert. Der Prozeß wiederholt sich mit den OIDCs für die Unterlisten der nächsten Ebene, weiter durch aufeinanderfolgende Unterlisten hindurch (das Verfahren ist unendlich rekursiv), wobei Unterlisten und Elementen nachgegangen wird, die nur unterschiedliche OIDCs- oder LUDT-Änderungen aufweisen. Schließlich ist die ganze Liste von Unterschieden dargelegt, und dann werden einzelne Betriebsmittel über das Netzwerk zu dem Tischrechner transportiert.

Funktionsbeispiel

Unter Bezugnahme auf die Figuren 13A - B ist ein beispielhaftes SH- Listenschema gezeigt. Die linke Seite des Schemas ist durch Figur 13 A dargestellt. Die rechte Seite des Schemas ist durch Figur 13 B dargestellt. Das Schema enthält sowohl auf Firmenpolitik basierende Informationen als auch technische/physikalische Informationen. Die linke Seite des Schemas stellt zunehmend abstrakte Überlegungen wie etwa Firmenpolitik, Sicherheit und Zugriff dar. Die rechte Seite des Schemas stellt technisch orientierte oder physikalische Faktoren der Tischrechnerumgebung, wie etwa die exakten Betriebsmittelbestandteile eines Tischrechners dar. Jedoch ist diese Rechts- /Links-Teilung nur illustrativ. Es gibt keine Beschränkung des Ortes des Typs der Vermischung von dynamischen Verkettungen in einem Schema.
Unter Bezugnahme auf Figur 13 B ist eine Serie von dynamischen Verkettungen 32 gezeigt, welche Betriebsmittel und einzelne Dateien miteinander verbinden. Diese dynamischen Verkettungen stehen für vorhersehbare Änderungen in einer Tischrechnerumgebung. In dem Beispiel der Figur 13 B ist die Variable der Betriebssystemtyp ("ZOS"). Die möglichen Alternativen sind OS/2 und Windows. Falls ein bestimmter Tischrechner OS/2 enthält, dann werden die dynamischen Verbindungen für OS/2-Betriebsmittel während des SH-Listen-Zerlegungssprozesses für den bestimmten Tischrechner ausgewählt.
Falls alternativ ein bestimmter Tischrechner das Windows-Betriebssystem enthält, dann werden die dynamischen Verkettungen für die Windows- Betriebsmittel während des SH-Listen-Zerlegungsprozesses für den Tischrechner ausgewählt.
In der Praxis dient eine Schemakonfiguration wie jene in den Figuren 13A - B als eine Schablone, die modifiziert werden kann, um den technischen Anforderungen für einen bestimmten Tischrechner und den firmenpolitischen Zwängen eines Unternehmens gerecht zu werden. Insbesondere enthält das veranschaulichende Schema Beziehungen, die typisch für Unternehmen sind. Zum Beispiel gibt es Abteilungen ("Departments") und Arbeitsgruppen ("Workgroups"). Es gibt Dienste ("Services") und Pakete ("Packages"). Es gibt Betriebsmittel ("Resoures") und Dateien ("Files").
Jede Spalte (oder jeder Stapel) kann unabhängig verwaltet werden, was eine verteilte Verwaltung berücksichtigt. Das heißt, zum Beispiel kann die Spalte mit mit "Workgroup" beschrifteten Kästchen unabhängig von den mit "Service" beschrifteten Kästchen verwaltet werden. Auch kann zum Beispiel die Spalte mit mit "Service" beschrifteten Kästchen unabhängig von der Spalte mit mit "Resoures" beschrifteten Kästchen verwaltet werden. Allgemein können zum Beispiel die näher an der linken Seite des durch Figur 13A dargestellten Spalten des Schemas durch Verwaltungspersonal verwaltet werden. Wohingegen die Spalten näher der rechten Seite des Schemas durch technisch orientiertes Personal verwaltet werden könnten. So können Fragen der verwaltungsorientierten Verwaltung von Fragen der technisch orientierten Verwaltung getrennt werden.
Das Schema kann auf einem zentralen Steuercomputer betrieben werden. Alternativ kann es verschiedene Zweige aufweisen, die "näher" an den eigentlichen Tischrechnern angeordnet sind, welche die mit diesen Zweigen verbundenen Dienste benutzen. Allgemein werden firmenpolitische Entscheidungen zentraler verwaltet. Jedoch können lokalisiertere technische Fragen lokal verwaltet werden. Folglich können zu diesen lokalisierten technischen Fragen gehörende Zweige an entfernteren Steuerpunkten betrieben werden. Um Zweige des Schemas zu verteilen, muß eine intelligente Zerlegung des Schemas geschaffen werden, so daß lokale (LAN) Prozesse lokalisierte Zweige steuern können. Eine Schemaverteilung über ein verteiltes Netzwerk ist eine Implementierungsfrage, die Fachleuten verständlich ist und die hierin nicht näher beschrieben wird.
Unter Bezugnahme auf die veranschaulichenden Zeichnungen der Figuren 14A - B ist ein anderes typisches Schema gezeigt, in dem ein auf Firmenpolitik basierender Entscheidungspunkt hinzugefügt worden ist. Dieser Entscheidungspunkt steht im Zusammenhang mit der Abteilung des Benutzers. Der Entscheidungspunkt ist durch eine andere dynamische Verkettung 34 benutzt.
Figuren 15A - B und Figur 16 zeigen als Konzept die Zerlegung einer SH-Liste aus dem Schema der Figuren 14A - B. In den Figuren 15A - B sind die dynamischen Verbindungen zerlegt worden. Die Abteilung ist "Geldwesen" ("Finance"). Das Betriebssystem ist OS/2. In Figur 16 ist das Schema aus nur zwei "Testknotenebenen" oder "Unterscheid ungsebenen" zusammengesetzt.
Prüfsummen werden nur an vorgeschriebenen Unterscheid ungs- oder Testknotenebenen berechnet. So werden zum Beispiel unter Bezugnahme auf Figuren 15A - B Unterschiede in den Arbeitsgruppen ("Workgroup")-, Packungs-("Package") oder Betriebsmittel ("Resoure")-Ebenen berechnet. Also werden für diese Ebenen keine Prüfsummen berechnet. Unterschiede werden jedoch für die Service-Ebene berechnet, und eine Prüfsumme wird für jeden Dienst ("Service") berechnet. Die Orte in dem Schema und die Anzahl der Unterscheidungsebenen ist eine durch einen Verwalter gesteuerte Implementierungsfrage.
Unter Bezugnahme auf die veranschaulichende Zeichnung der Figur 17 ist eine AH-Liste von Diensten und Dateibetriebsmitteln gezeigt, die bei einer früheren Konfiguration auf einem bestimmten Tischrechner vorhanden waren. Die AH-Liste stellt die Konfiguration dar, wie sie bei der letzten Konfigurationsaktivität synchronisiert wurde. Die eigentlichen Daten können abhängig von dem Konfigurationsprozeß geändert worden sein, zum Beispiel ein Benutzer löscht eine Datei. Die AH-Liste kann auch optional auf Fehlerfreiheit überprüft werden, und zwar vor der AH-/SH-Unterscheidung durch Vergleichen der tatsächlich gegenwärtigen Inhalte des Tischrechners mit der früheren AH-Liste und vor dem Ändern der LUDTs oder OIDCs, die mit Elementen in der AH-Liste im Zusammenhang stehen, welche sich von den tatsächlich gegenwärtigen Tischrechnerinhalten unterscheiden. Der Unterscheid ungsprozeß bestimmt diese Änderungen und rekonfiguriert dementsprechend den Tischrechner. Figur 18 zeigt einen Unterscheidungsprozeß zwischen der zerlegten SH-Liste der Figur 16 und der AH-Liste der Figur 17. Der Unterscheidungsprozeß verläuft in einer Art und Weise ähnlich zu demjenigen, welcher unter Bezugnahme auf Figur 12 beschrieben wurde. Die SH-Liste enthält "Service.Genledger". Jedoch gibt es kein "Service.Genledger" für die AH-Liste. So wird ein Unterschied zwischen der SH- und der AH-Liste festgestellt. Der nächste Schritt besteht darin, den Tischrechner zu rekonfigurieren, um "Service.Genledger" bei Benutzung normaler Netzwerktransporttechniken hinzuzufügen.

SH-Listen-Zerlegungsroutine

Das veranschaulichende Flußdiagramm der Figur 22 verdeutlicht eine SH- Listen-Zerlegungsroutine gemäß einer vorliegenden Ausführungsform der Erfindung. Im "Lese Datensatz"-Schritt 64 wird ein Datensatz aus einer Schemadatei gelesen. Das Schema kann als eine Standarddatenstruktur gespeichert sein. Zum Beispiel kann es als Objekte in einer Datenbank gespeichert sein oder es kann als eine "flache" Datei, die Daten enthält, gespeichert sein. Figuren 13A - B und 14A - B veranschaulichen Schemata, welche Ansammlungen von Einträgen mit Zeigern zwischen den Datensätzen umfassen. In dem Schema der Figuren 13A - B und 14A - B umfaßt jeder Datensatz eine Gruppe von Feldern. Jedes Feld kann entweder eine Variable oder einen Zeiger zu einem anderen Datensatz sein. Es ist zu beachten, daß Objekt-Mitteilungsübermittlung und -Übernahme als Zeiger in einer objektorientierten Implementierung verwendet werden können.
Unter Bezugnahme auf zum Beispiel Figur 14A enthält der Datensatz, der als "Service.AP Service.AR" gekennzeichnet ist, drei Felder. Zwei Felder enthalten Zeiger, die im Schema nach unten zeigen. Einer dieser abwärts weisenden Zeiger zeigt auf den Datensatz, der als "Package.Vendor Package.Check" gekennzeichnet ist. Ein anderer dieser zwei abwärts weisenden Zeiger zeigt auf den als "Package.Custlist Package.Invoice" gekennzeichneten Datensatz. Der dritte abwärts weisende Zeiger in dem Datensatz "Service.AP Service.AR" zeigt zurück aufwärts in dem Schema auf den Datensatz, der als "Workgroup.Accting Workgroup. Ledger" gekennzeichnet ist.
Im Stammdatensatz-Perkolationsschritt 66 wird der OID dieses neu gelesenen Datensatzes nach oben zum "Stammdatensatz" des Datensatzes perkuliert. Unter Bezugnahme zum Beispiel noch einmal auf Datensatz "Service.AP Service.AR", wird sein OID zu seinem Stammdatensatz "Workgroup.Accting Workgroup. Ledger" aufwärts geleitet.
Wie nachfolgend erklärt, ist die SH-Listen-Zerlegungsroutine rekursiv. Folglich werden die OIDs aller Datensätze durch das Schema vom unteren Ende (rechten Seite) des Schemas aufwärts zum oberen Ende (linke Seite) des Schemas perkoliert. Der Vorteil einer derartigen Perkolation von OIDs besteht darin, daß auf jeder Unterscheidungsebene und jeder Entscheidungspunktebene eine Prüfsumme berechnet werden kann, die die einzelnen Datensätze abwärts von einer derartigen Unterscheidungs- oder Entscheid ungspunktebene wiedergibt.
Im Entscheidungsschritt 68 wird eine Unterscheidung getroffen, ob der zuletzt gelesene Datensatz eine neue Unterscheidungsebene oder Entscheidungspunktebene darstellt. Jeder Datensatz trägt eine Anzeige ob er nicht als eine Unterscheidungs- oder Entscheidungspunktebene verwendet werden soll. Diese Anzeige ist eine durch den Verwalter gesteuerte Option. So können mehr oder weniger Unterscheidungsebenen abhängig von Verwaltungsanforderungen eingesetzt werden.
Falls der Datensatz auf einer neuen Unterscheidungsebene sitzt, dann wird im Zuordnungsschritt 70 ein neuer OID-Prüfsumme7(CRC)-Puffer geöffnet, um Olds von "abgeleiteten Datensätzen" dieses Datensatzes zu sammeln. Zum Beispiel ist "Service.AP Service.AR" in Figur 14A als eine neue Entscheidungsebene bezeichnet. Also werden die OIDs für die abwärts von dem als "Service.AP Service.AR" gekennzeichneten Datensatz verbundenen Datensätze durch das Schema zu dem Puffer aufwärts geleitet (perkoliert), der für den als "Service.AP Service.AR" gekennzeichneten Datensatz geöffnet ist.
In der "verarbeitete Datensatzfelder"-Routine 72 wird jedes Feld in dem Datensatz verarbeitet, um den Zeigern zu folgen, die den derartigen Feldern abwärts (nach rechts) durch das Schema hindurch zugeordnet sind. Die "verarbeitete Datensatzfelder"-Routine 72 ist eine rekursive Routine, die im Zusammenhang mit Figur 23 erklärt wird. Im Entscheid ungsschritt 74 wird eine Entscheidung getroffen, ob der Datensatz, der gerade verarbeitet worden ist, auf einer neuen Ebene war. Falls er dies war, dann wird im Prüfsummenberechnungsschritt 76 ein Prüfsummenwert (CRC) aus den abwärtigen Olds berechnet, die aus abwärtigen Datensätzen gesammelt werden. Das Ergebnis ist die SOIDC für diese neue Unterscheidungsebene.
Im SOID-Perkolationsschritt 78 wird die frisch berechnete SOIDC zu dem "Stammdatensatz" des Datensatzes auf dieser neuen Ebene aufwärts geleitet (perkoliert). Im Entscheidungsschritt 80 wird eine Unterscheidung getroffen, ob das LUDT für den Datensatz später als das LUDT des Stammdadensatzes des Datensatzes ist. Zum Beispiel ist unter Bezugnahme auf Figur 15A "Service.AP Service.AR" der "abgeleitete Datensatz" des als "Workgroup.Accting Workgroup.Ledger" bezeichneten Datensatzes; umgekehrt ist "Workgroup.Accting Workgroup. Led ger" der Stammdatensatz des Datensatzes "Service.AP Service.AR". Falls das LUDT des Datensatzes auf dieser neuen Ebene später ist als das seines Stammdatensatzes, dann wird im LUDT-Perkolationsschritt 82 das LUDT des abgeleiteten Datensatzes auf der neuen Ebene aufwärts geleitet (perkoliert), um zum LUDT des Stammdatensatzes zu werden.

"Verarbeite Datensatzfelder"--Übersicht

Unter Bezugnahme auf die veranschaulichende Zeichnung der Figur 23 ist ein Flußdiagramm einer "Verarbeitete Datensatzfelder"-Routine einer gegenwärtigen Ausführungsform gezeigt. Diese Routine ist als Kästchen 72 in der SH-Listen-Zerlegungsroutine der Figur 22 gekennzeichnet. Für jedes Feld in einem Datensatz bestimmt der Entscheidungsschritt 84, ob das Feld eine Verbindung mit einer dynamischen Verkettung aufweist. Falls das Feld eine Verbindung mit einer dynamischen Verkettung aufweist, dann wird der durch die Abfragesoftware ermittelte Variablenwert erhalten, um die Verkettung aufzulösen. Im Entscheidungsschritt 88 wird eine Unterscheidung getroffen, ob das Feld einen Unterlistennamen enthält. Es wird verständlich, daß ein Unterstenname im wesentlichen ein Zeiger für einen abwärtigen Datensatz sein kann. Alternativ kann in einer objektorientierten Umgebung die Verbindung mit dem abwärtigen Datensatz eine Objekt- Mitteilungsübermittlung umfassen. Falls der Entscheid ungsschritt 88 bestimmt, daß das abwärtige Feld einen Unterlistennamen enthält (oder andernfalls einen abwärtigen Datensatz identifiziert), dann wird die SH- Listenzerlegungsungsroutine, die unter Bezugnahme auf Figur 22 erklärt ist, aufgerufen und für jenen abwärtigen Datensatz, der durch den Unterlistennamen (oder den Zeiger oder die Objektmitteilungsübermittlung) identifiziert ist, in dem Feld unter Berücksichtigung ausgeführt. Es ist wichtig, zu beachten, daß der unter Bezugnahme auf die Figuren 22 und 23 beschriebene Prozeß in hohem Maße rekursiv ist. Wieder unter Bezugnahme auf Figur 22 tritt der Schritt 72 der "Verarbeitete Datensatzfelder"-Routine auf halbem Wege durch die SH-Listenzerlegungs- Routine auf. Dann kann während der Ausführung der "Verarbeitete Datensatzfelder"-Routine, wie in Figur 23 gezeigt ist, der Schritt 90 der SH- Listenzerlegungsroutine aufgerufen und ausgeführt werden, um das betreffende Feld zu verarbeiten. Das Ergebnis dieser Rekursivheit und die Verschachtelung der "Verarbeite Datensatzfelder"--Routinen innerhalb der SH- Listenzerlegungsroutinen und umgekehrt besteht darin, daß für jeden Datensatz und jedes Feld jenes Datensatzes die Schemazweige abwärts (von links nach rechts) verfolgt werden, bis die bodennächsten Zweige des Schemabaums erreicht sind. Während dieses Prozesses werden OID- und LUDT-Informationen abwärts durch den Schemabaum zurück perkoliert. Prüfsummen auf Unterscheidungsebenen werden basierend auf diesen perkolierten Informationen berechnet.
Zurückkommend auf den Entscheidungsschritt 88, wird falls die Feststellung getroffen wurde, daß die Felder keinen Unterlistennamen (oder Zeiger oder keine Objekt-Mitteilungsübermittlung) enthalten, in dem "Füge Variable hinzu"-Schritt 92 die durch das Feld gekennzeichnete Variable einem Variablen-Pool für das Feld hinzugefügt. In Schritt 94 wird die Routine der Figur 23 wieder für das nächste Feld desselben Datensatzes ausgeführt.
Wie vorstehend erwähnt, ist der Prozeß der Figuren 22 und 23 in höchstem Maße rekursiv. Wenn die SH-Listenzerlegungsroutine ausgeführt wird, werden Prüfsummen berechnet; OIDs und SOLDs werden wie abgeleitete Datensätze zu Stammdatensätzen aufwärts perkoliert; und LUDTs werden von den abgeleiteten Datensätzen zu den Stammdatensätzen aufwärts perkoliert. Wenn die komplette SH-Listenzerlegungsroutine beendet ist, ist das Ergebnis eine Hauptebenen-OIDC und SOIDCs auf jeder der Unterscheidungsebenen. Zusätzlich gibt es ein Hauptebenen-LUDT als auch LLUDTs auf jeder der Unterscheidungsebene. So führt die Schemazeregung zu SH-Listen, wie jene in Figuren 12 und 21, die mit Prüfsummen, OID- und Dateninformationen auf verschiedenen Unterscheid ungsebenen reichlich versehen sind.

Unterlistenunterscheidungs-Routine

Unter Bezugnahme auf die veranschaulichende Flußdarstelllung der Figur 24 ist ein Flußdiagramm für eine Unterlisten-Unterscheid ungsroutine gemäß einer vorliegenden Ausführungsform der Erfindung gezeigt. Diese Routine startet auf der Hauptustenebene und setzt sich abwärts zu der Unterlisten-A/B-Ebene fort. Unter Bezugnahme auf Figur 18 startet die Routine auf der Dienstebene und setzt sich zur Betriebsmitteldatei-Ebene fort.
Im Entscheidungsschritt 94 wird eine Unterscheidung getroffen, ob die AH- OIDC mit der SH-OIDC für eine bestimmte Unterscheidungsebene zusammenpaßt. Falls sie dies nicht tut, dann werden im Transportschritt 96 die SOLDs für die nächste zu beachtende Ebene von dem Tischrechner zu einem Ort transportiert, wo der Unterscheidungsprozeß stattfindet. Falls der Unterscheidungsprozeß an einem lokalen Tischrechner stattfindet, dann ist natürlich kein solcher Transportschritt notwendig. Im Vergleichsschritt 98 werden die Unterlisten-Olds verglichen, um Unterschiede zu identifizieren. Auch werden im Vergleichsschritt 98 Unterschiede zwischen den LUDTs und den LSDTs identifiziert.
Im Unterscheidungslisten-Erstellungsschritt 100 wird eine Liste von Unterschieden zwischen den Unterlisten erstellt. Auch im Schritt 100 sind die Datenunterschiede einbezogen. Im Entscheid ungsschritt 102 wird eine Unterscheidung vorgenommen, ob das LUDT der in Frage stehenden Ebene mit der LSDT zusammenpaßt. Falls nicht, wird in dem Datenunterschiedslisten-Erstellungsschritt 104 eine Liste von Elementen in der SH-Liste später als das AH-LSDT zusammengestellt.
Im Entscheidungsschritt 106 wird eine Entscheidung getroffen, ob die Elemente in den Listen, die gemäß den Schritten 100 und 104 erstellt wurden, Unterlistenelemente oder diskrete Elemente sind. Falls sie Unterlistenemente sind, dann wird die Unterlisten-Unterscheidungsroutine (rekursiv) für jede dieser Elemente ausgeführt, wie durch den Untersten- Unterscheidungsroutine-Schritt 108 gekennzeichnet ist. Für jeden Unterschied in den Listen, die gemäß den Kästen 100 und 104 erstellt worden sind, das heißt ein diskretes Element, wird die Berechnungsroutine für eine diskrete Änderung, die in Figur 25 dargestellt ist, ausgeführt. Falls natürlich im Entscheidungsschritt 94 bestimmt ist, daß die OIDCs zusammenpassen, und im Entscheidungsschritt 102 bestimmt ist, daß die Daten zusammenpassen, dann wird die Unterlistenunterscheidungsroutine ohne Umweg über andere Schritte beendet.

Verarbeitungsroutine für diskrete Änderung

Unter Bezugnahme auf die veranschaulichende Zeichnung der Figur 25 ein Flußdiagramm für eine Verarbeitungsroutine für eine diskrete Änderung gemäß einer gegenwärtigen Implementierung der Erfindung gezeigt. Für jedes Element, das in einer unterschiedlichen Liste gemäß den Schritten 100 und 104 in Figur 24 plaziert ist, bestimmt der Entscheidungsschritt 112 den Unterscheidungstyp. Falls die Unterscheidung eine Elementaktualisierung umfaßt, dann wird im Schritt 114 das Element auf dem Tischrechner aktualisiert. Falls der Unterscheidungstyp eine Elementlöschung ist, dann wird in Schritt 116 das passende Element aus dem Tischrechner gelöscht. Falls der Unterscheidungstyp eine Elementergänzung ist, dann wird ein neues Element zum Tischrechner transportiert. Wie im (optionalen) Schritt 112 gezeigt, kann die hinzugefügte Komponente über ein Script-Programm installiert werden.

Claims

1. Verfahren zum Verwalten von Betriebsmitteln in einem Netzwerk verteilter Computer, das folgende Verfahrensschritte aufweist: in dem Computernetzwerk wird eine jeweilige Bereits-Haben- AH(Already Have)-Informationsstruktur vorgesehen, die einem jeweiligen Netzwerkcomputer entspricht und die AH-Betriebsmittel erkennt, welche ein solcher Netzwerkcomputer bereits hat, wobei die AH-Informationsstruktur eine mehrstufige Hierarchie von AH- Informationseinheiten umfaßt, und

wobei jeweilige AH-Informationseinheiten auf höheren Ebenen in der AH-Informationsstrukturhierarchie AH-Strukturdaten umfassen, welche die Verkettungen zwischen AH-Informationseinheiten auf tieferen Ebenen in der AH-Informationsstrukturhierarchie betreffen; in dem Computernetzwerk wird eine jeweilige Sollte-Haben-SH(Should Have)-Informationsstruktur vorgesehen, welche SH-Betriebsmittel erkennt, welche ein solcher Netzwerkcomputer haben sollten, wobei die SH-Informationsstruktur eine mehrstufige SH- Informationsstrukturhierarchie von SH-Informationseinheiten umfaßt, und

wobei jeweilige SH-Informationseinheiten auf höheren Ebenen in der SH-Informationsstrukturhierarchie SH-Strukturdaten umfassen, welche die Verkettungen zwischen SH-Informationseinheiten auf tieferen Ebenen der SH-Informationsstrukturhierarchie betreffen; und jeweilige AH-Strukturdaten, die in jeweiligen AH-Informationseinheiten enthalten sind, werden mit jeweiligen SH-Strukturdaten, die in entsprechenden SH-Informationseinheiten enthalten sind, verglichen, um Teile der AH-Informationsstruktur zu erkennen, die sich von entsprechenden Teilen der SH-Informationsstruktur unterscheiden.

2. Verfahren nach Anspruch 1,

wobei jeweilige AH-Informationseinheiten jeweilige Listen umfassen, welche andere jeweilige AH-Informationseinheiten oder jeweilige AH- Betriebsmittel erkennen, und

wobei jeweilige SH-Informationseinheiten jeweilige Listen umfassen, welche andere jeweilige SH-Informationseinheiten oder jeweilige SH- Betriebsmittel erkennen.

3. Verfahren nach Anspruch 1,

wobei jeweilige AH-Informationseinheiten jeweilige Objekte umfassen, die mit anderen jeweiligen AH-Informationseinheiten verkettet sind oder die mit jeweiligen AH-Betriebsmitteln verkettet sind; und

wobei entsprechende SH-Informationseinheiten jeweilige Objekte umfassen, die mit anderen jeweiligen SH-Informationseinheiten verkettet sind oder die mit jeweiligen SH-Betriebsmitteln verkettet sind.

4. Verfahren nach Anspruch 1, wobei zumindest eine jeweilige AH-Informationseinheit in der AH- Informationsstrukturhierarchie eine Verkettung zu einer anderen jeweiligen in der AH-Informationsstrukturhierarchie höheren AH- Informationseinheit umfaßt, und eine Verkettung zu einem jeweiligen in der AH-Informationsstrukturhierarchie tieferen AH-Betriebsmittel umfaßt; und

zumindest eine jeweilige SH-Informationseinheit in der SH- Informationsstrukturhierarchie eine Verkettung zu einer anderen jeweiligen in der SH-Informationsstrukturhierarchie höheren SH- Informationseinheit umfaßt, und eine Verkettung zu einem jeweiligen in der SH-Datenstrukturhierarchie tieferen SH-Betriebsmittel.

5. Verfahren nach Anspruch 1, wobei der Vergleichsschritt folgendes aufweist:

anfangs werden jeweilige AH-Strukturdaten, die in jeweiligen AH- Informationseinheiten auf höheren Ebenen in der AH- Informationsstrukturhierarchie enthalten sind, mit jeweiligen SH- Strukturdaten, die in entsprechenden SH-Informationseinheiten auf höheren Ebenen in der SH-Informationsstrukturhierarchie enthalten sind, verglichen, und dann werden jeweilige AH-Strukturdaten in jeweilige AH-Informationseinheiten auf tieferen Ebenen in der AHInformationsstrukturhierarchie mit jeweiligen SH-Strukturdaten, die in entsprechenden SH-Informationseinheiten auf tieferen Ebenen in der SH-Informationsstrukturhierarchie enthalten sind, verglichen.

6. Verfahren nach Anspruch 1, wobei:

zumindest ein jeweiliges in der AH-Informationsstrukturhierarchie erkanntes AH-Betriebsmittel ein Anwendungsprogramm umfaßt; und

zumindest ein jeweiliges in der SH-Informationsstrukturhierarchie erkanntes SH-Betriebsmittel ein Anwendungsprogramm umfaßt.

7. Verfahren nach Anspruch 1, wobei:

zumindest ein jeweiliges in der AH-Informationsstrukturhierarchie erkanntes AH-Betriebsmittel eine Programmdatei umfaßt; und

zumindest ein jeweiliges in der SH-Informationsstrukturhierarchie erkanntes AH-Betriebsmittel eine Programmdatei umfaßt.

8. Verfahren nach Anspruch 1, wobei

zumindest ein jeweiliges in der AH-Informationsstrukturhierarchie erkanntes AH-Betriebsmittel Programmdaten umfaßt; und

zumindest ein jeweiliges in der SH-Informationsstrukturhierarchie erkanntes SH-Betriebsmittel Programmdaten umfaßt.

9. Verfahren nach Anspruch 1, wobei

zumindest ein jeweiliges in der AH-Informationsstrukturhierarchie erkanntes AH-Betriebsmittel Programmbefehle umfaßt; und

wobei zumindest ein jeweiliges in der SH-Informationsstrukturhierarchie erkanntes SH-Betriebsmittel Programmbefehle umfaßt.

10. Verfahren nach Anspruch 1, wobei:

zumindest ein jeweiliges in der AH-Informationsstrukturhierarchie erkanntes AH-Betriebsmittel ein Icon umfaßt; und

zumindest ein jeweiliges in der SH-Informationsstrukturhierarchie erkanntes SH-Betriebsmittel ein Icon umfaßt.

11. Verfahren nach Anspruch 1, wobei:

jeweilige AH-Informationseinheiten in der AH- Informationsstrukturhierarchie Grundsätzen entsprechen, die eine durch das Netzwerk versorgte Organisation bestimmen, und

jeweilige SH-Informationseinheiten in der SH- Informationsstrukturhierarchie Grundsätzen entsprechen, die eine durch das Netzwerk versorgte Organisation bestimmen.

12. Verfahren nach Anspruch 1, wobei: jeweiligen AH-Informationseinheiten in der AH- Informationsstrukturhierarchie Sicherheitsebenen von Benutzern im Netzwerk entsprechen; und

jeweiligen SH-Informationseinheiten in der SH- Informationsstrukturhierarchie Sicherheitsebenen von Benutzern im Netzwerk entsprechen.

13. Verfahren nach Anspruch 1, wobei der Vergleichschritt folgendes umfaßt:

jeweilige AH-Strukturdaten, die in jeweiligen AH-Informationseinheiten auf höheren Ebenen der AH-Informationsstrukturhierarchie enthalten sind&sub1; werden mit jeweiligen SH-Strukturdaten verglichen, die in entsprechenden jeweiligen SH-Informationseinheiten auf entsprechenden höheren Ebenen der SH-Informationsstrukturhierarchie enthalten sind; und

für jeweilige entsprechende AH-/SH-Informationseinheiten höherer Ebene, für die jeweilige Vergleiche einen Unterschied in den AH-/SH- Strukturdaten erkennen, werden jeweilige AH-Strukturdaten, die in jeweiligen AH-Informationseinheiten enthalten sind, welche mit einer solchen AH-Informationseinheit höherer Ebene auf einer vorgeschrieben nächst tieferen Ebene in der Informationstrukturhierarchie verkettet sind, mit jeweiligen SH- Strukturdaten verglichen, die in entsprechenden jeweiligen SH- Informationseinheiten enthalten sind, welche mit einer solchen SH- Informationseinheit höherer Ebene auf einer entsprechenden vorgeschrieben nächst tieferen Ebene in der SH- Informationsstrukturhierarchie verkettet sind.

14. Verfahren nach Anspruch 13, das weiternn die folgenden Verfahrensschritte aufweist:

die AH-Informationsstruktur wird in einem ersten Netzwerkcomputer gespeichert;

die SH-Informationsstruktur wird in einem zweiten Netzwerkcomputer gespeichert; und

jeweilige Strukturdaten, die in dem Vergleichschritt verwendet werden, werden zwischen dem ersten und zweiten Netzwerkcomputer transportiert.

15. Verfahren nach Anspruch 14, das weiterhin den folgenden Verfahrensschritt aufweist:

für jeweilige entsprechende AH-/SH-Informationseinheiten höherer Ebene, für die jeweilige Vergleiche einen Unterschied in Strukturdaten erkennen, werden jeweilige SH-Informationseinheiten oder - Betriebsmittel an den ersten Netzwerkcomputer transportiert.

16. Verfahren nach Anspruch 1, wobei der Vergleichschritt folgendes aufweist:

jeweilige AH-Strukturdaten, die in jeweiligen AH-Informationseinheiten auf höheren Ebenen der AH-Informationsstrukturhierarchie enthalten sind, werden mit jeweiligen SH-Strukturdaten verglichen, die in entsprechenden jeweiligen SH-Informationseinheiten auf entsprechenden höheren Ebenen der SH-Informationsstrukturhierarchie enthalten sind; und

für jeweilige entsprechende AH-/SH-Informationseinheiten höherer Ebene, für die jeweilige Vergleiche einen Unterschied in AH-/SH- Strukturdaten erkennen, werden jeweilige AH-Strukturdaten, die in jeweiligen AH-Informationseinheiten enthalten sind, welche mit einer solchen AH-Informationseinheit höherer Ebene auf einer vorgeschrieben nächst tieferen Ebene in der Informationsstrukturhierarchie verkettet sind, mit jeweiligen SH- Strukturdaten verglichen, die in entsprechenden jeweiligen SH- Informationseinheiten enthalten sind, welche mit einer solchen SH- Informationseinheit höherer Ebene auf einer jeweiligen vorgeschrieben nächst tieferen Ebene in der SH-Informationsstrukturhierarchie verkettet sind; und

für jeweilige entsprechende AH-/SH-Informationseinheiten tieferer Ebene, für die jeweilige Vergleiche einen Unterschied in AH-/SH- Strukturdaten erkennen, werden jeweilige AH-Strukturdaten, die in jeweiligen AH-Informationseinheiten enthalten sind, welche mit einer solchen AH-Informationseinheit tieferer Ebene auf einer vorgeschrieben nächst tieferen Ebene in der Informationsstrukturhierarchie verkettet sind, mit jeweiligen SH-Strukturdaten verglichen, die in entsprechenden jeweiligen SH-Informationseinheiten enthalten sind, welche mit einer solchen SH-Informationseinheit tieferer Ebene auf einer jeweiligen vorgeschrieben nächst tieferen Ebene in der SH- Informationsstrukturhierarchie verkettet sind.

17. Verfahren nach Anspruch 16, das weiterhin folgende Verfahrensschritte aufweist:

die AH-Informationsstruktur werden in einem ersten Netzwerkcomputer gespeichert;

die SH-Informationsstruktur wird in einem zweiten Netzwerkcomputer gespeichert;

jeweilige Strukturdaten, die in den Vergleichsschritten verwendet werden, werden zwischen dem ersten und dem zweiten Netzwerkcomputer transportiert; und

für jeweilige entsprechende AH-/SH-Informationseinheiten höherer Ebene und jeweilige SH-/AH-Informationseinheiten tieferer Ebene, für welche jeweilige Vergleiche einen Unterschied in Strukturdaten erkennen, werden jeweilige SH-Informationseinheiten oder - Betriebsmittel zu oder von dem ersten Netzwerkcomputer transportiert;

18. Verfahren nach Anspruch 1, wobei der Vergleichschritt folgendes aufweist:

jeweilige AH-Strukturdaten, die in jeweiligen AH-Informationseinheiten auf höheren Ebenen der AH-Informationsstrukturhierarchie enthalten sind, werden mit jeweiligen SH-Strukturdaten verglichen, die in entsprechenden jeweiligen SH-Informationseinheiten auf entsprechenden höheren Ebenen der SH-Informationsstrukturhierarchie enthalten sind;

für jeweilige entsprechende AH-/SH-Informationseinheiten höherer Ebene, für die jeweilige Vergleiche einen Unterschied in AH-/SH- Strukturdaten erkennen, werden jeweilige AH-Strukturdaten, die in jeweiligen AH-Informationseinheiten enthalten sind, welche mit einer solchen AH-Informationseinheit höherer Ebene auf einer vorgeschrieben nächst tieferen Ebene in der Informationsstrukturhierarchie verkettet sind, mit jeweiligem SH- Strukturdaten verglichen, die in entsprechenden jeweiligen SH- Informationseinheiten enthalten sind, welche mit einer solchen SH- Informationseinheit höherer Ebene auf einer entsprechenden vorgeschrieben nächst tieferen Ebene in der SH- Informationsstrukturhierarchie verkettet sind; und für jeweilige entsprechende AH-/SH-Informationseinheiten höherer Ebene, für die jeweilige Vergleiche keinen Unterschied in AH-/SH- Strukturdaten erkennen, werden keine weiteren Vergleiche von jeweiligen AH-/SH-Strukturdaten durchgeführt, die in jeweiligen AH-/SH- Informationseinheiten enthalten sind, welche mit solchen jeweiligen entsprechenden AH-/SH-Informationseinheiten höherer Ebene auf jeweiligen tieferen Ebenen in den jeweiligen AH-/SH- Informationsstrukturen verkettet sind.

19. Verfahren nach Anspruch 18, das weiterhin die folgenden Verfahrensschritte aufweist:

die AH-Informationsstruktur wird in einem ersten Netzwerkcomputer gespeichert;

die AH-Informationsstruktur wird in einem zweiten Netzwerkcomputer gespeichert;

jeweilige Strukturdaten, die in den Vergleichsschritten verwendet werden, werden zwischen dem ersten und dem zweiten Netzwerkcomputer transportiert;

für jeweilige entsprechende AH-/SH-Informationseinheiten höherer Ebene und jeweilige SH-/AH-Informationseinheiten tieferer Ebene, für welche jeweilige Vergleiche einen Unterschied in Strukturdaten erkennen, werden jeweilige SH-Informationseinheiten oder - Betriebsmittel zu oder von dem ersten Netzwerkcomputer transportiert; und

für jeweilige entsprechende AH-/SH-Informationseinheiten höherer Ebene, für welche jeweilige Vergleiche keinen Unterschied in Strukturdaten erkennen, werden keine jeweiligen SH- Informationseinheiten oder -Betriebsmittel zu oder von dem ersten Netzwerkcomputer transportiert.

20. Verfahren nach Anspruch 1, das weiterhin die folgenden Verfahrensschritte aufweist:

die AH-Informationsstruktur wird in einem ersten Netzwerkcomputer gespeichert; und

die SH-Informationsstruktur wird in einem zweiten Netzwerkcomputer gespeichert.

21. Verfahren nach Anspruch 1, wobei:

der Schritt des Vorsehens der AH-Informationsstruktur das Speichern der AH-Informationsstruktur in dem Netzwerkcomputer, dem die AH- Informationsstruktur entspricht, umfaßt; und

der Schritt des Vorsehens der SH-Informationsstruktur das Speichern der SH-Informationsstruktur in einem von dem Netzwerkcomputer, dem die SH-Informationsstruktur entspricht, verschiedenen Netzwerkcomputer umfaßt.

22. Verfahren zum Verwalten von Betriebsmitteln in einem Netzwerk verteilter Computer, das folgende Verfahrensschritte aufweist: in dem Computernetzwerk wird eine jeweilige Bereits-Haben- AH(Already Have)-Informationsstruktur vorgesehen, die einem jeweiligen Netzwerkcomputer entspricht und die AH-Betriebsmittel erkennt, welche ein solcher Netzwerkcomputer bereits hat,

wobei die AH-Informationsstruktur eine mehrstufige Hierarchie von AH- Informationseinheiten umfaßt, und

wobei jeweilige AH-Informationseinheiten auf höheren Ebenen in der AH-Informationsstrukturhierarchie AH-Strukturdaten umfassen, welche die Verkettungen zwischen AH-Informationseinheiten auf tieferen Ebenen in der AH-Informationsstrukturhierarchie betreffen;

in dem Computernetzwerk wird ein jeweiliges Sollte-Haben-SH(Should Have)-Schema vorgesehen, das SH-Betriebsmittel erkennt, welche mehrere Computer im Netzwerk haben sollten,

wobei das SH-Schema eine mehrstufige SH-Schemahierarchie von SH- Informationseinheiten umfaßt,

wobei zumindest eine dynamische Verkettung zwischen zumindest einer SH-Informationseinheit auf einer höheren Ebene in der SH- Schemahierarchie und eine von mehreren SH-Informationseinheiten oder mehreren SH-Betriebsmitteln auf einer tieferen Ebene in der SH- Schemahierarchie vorhanden ist, und

wobei jeweilige SH-Informationseinheiten jeweilige Kennzeichner umfassen.

23. Verfahren nach Anspruch 22,

wobei die AH-Strukturdaten AH-Zahlenwerte umfassen, die für die Verkettung zwischen AH-Informationseinheiten auf tiefen Ebenen in der AH-Informationsstrukturhierarchie bezeichnend sind, und wobei jeweilige AH-Informationseinheiten auf höheren Ebenen in der AH-Informationsstrukturhierarchie AH-Gegenwärtig keitsdaten über die Gegenwärtig keit von jeweiligen in der AH-Informationsstruktur erkannten Betriebsmitteln enthalten;

wobei die jeweiligen Kennzeichner jeweilige numerische Kennzeichner umfassen, und wobei jeweilige SH-Informationseinheiten jeweilige SH- Gegenwärtigkeitsdaten umfassen; und wobei das Verfahren die folgenden Schritte aufweist:

der zumindest eine Computer wird abgefragt, um die technische Konfiguration eines solchen Netzwerkcomputers zu ermitteln;

die zumindest eine dynamische Verkettung in dem SH-Schema wird basierend auf der Konfiguration gelöst, so daß die dynamische Verkettung durch eine gelöste Verkettung zwischen der zumindest einen SH-Informationseinheit und einer der mehreren SH- Informationseinheiten tieferer Ebene oder einer der mehreren SH- Betriebsmittel tieferer Ebene ersetzt wird;

wobei eine SH-Informationsstruktur erzeugt wird, welche dem Netzwerkcomputer entspricht und welche die Betriebsmittel anzeigt, welche solch einen Neztwerkcomputer haben sollte;

eine Gegenwärtig keitshierarchie in der SH-Informationsstruktur wird erstellt, so daß jeweilige SH-Informationseinheiten auf höheren Ebenen in der SH-Informationsstruktur SH-Gegenwärtigeitsdaten über die Gegenwärtigkeit von jeweiligen SH-Informationseinheiten tieferer Ebene umfassen und SH-Betriebsmittel, die mit solchen jeweiligen SH- Informationseinheiten verkettet sind;

jeweilige SH-Zahlenwerte werden berechnet und solche jeweiligen berechneten SH-Zahlenwerte werden dementsprechend in jeweilige SH-Informationseinheiten auf vorgeschriebenen Ebenen in der SH- Informationsstruktur integriert, wobei jeweilige berechnete SH- Zahlenwerte basierend auf jeweiligen numerischen Kennzeichnern berechnet werden, die in anderen jeweiligen SH-Informationseinheiten enthalten sind, welche in der SH-Informationsstruktur unterhalb einer jeweiligen SH-Informationseinheit verkettet sind, in welche ein jeweiliger berechneter SH-Zahlenwert integriert wird; und

jeweilige AH-Zahlenwerte und jeweilige AH-Gegenwärtigkeitsdaten, die in jeweiligen AH-Informationseinheiten enthalten sind, und entsprechende jeweilige SH-Zahlenwerte und jeweilige SH- Gegenwärtigkeitsdaten, die in jeweiligen SH-Informationseinheiten enthalten sind, werden verglichen, um Teile der AH-Informationsstruktur zu erkennen, die sich von entsprechenden Teilen der SH- Informationsstruktur unterscheiden.

24. Verfahren nach Anspruch 22,

wobei jeweilige AH-Informationseinheiten mit anderen jeweiligen AH- Informationseinheiten in der AH-Informationsstrukturhierarchie verkettet sind,

wobei die AH-Strukturdaten AH-Zahlenwerte umfassen, die für andere jeweilige AH-Informationseinheiten bezeichnend sind, welche in der AH- Informationsstrukturhierarchie unterhalb jeweiliger AH- Informationseinheiten verkettet sind, in denen solche jeweiligen AH- Zahlenwerte enthalten sind und die auch bezeichnend für die jeweiligen Verkettungen zwischen solchen jeweiligen SH-Informationseinheiten tieferer Ebene sind, und

wobei jeweilige SH-Informationseinheiten mit anderen jeweiligen SH- Informationseinheiten auf verschiedenen Ebenen in der SH- Schemahierarchie verkettet sind,

wobei die jeweiligen Kennzeichner jeweilige numerische Kennzeichner umfassen, und das Verfahren die folgenden weiteren Schritte aufweist: der zumindest eine Computer wird abgefragt, um die Konfiguration eines solchen Netzwerkcomputers zu erfassen;

die zumindest eine dynamische Verkettung in dem SH-Schema wird basierend auf der Konfiguration gelöst, so daß die dynamische Verkettung durch eine gelöste Verkettung zwischen der zumindest einen SH-Informationseinheit und einer der mehreren SH- Informationseinheiten tieferer Ebene oder einer der mehreren SH- Betriebsmittel tieferer Ebene ersetzt wird; jeweilige SH-Zahlenwerte werden erzeugt und solche jeweiligen SH- Zahlenwerte werden dementsprechend in jeweilige SH- Informationseinheiten auf vorgeschriebenen Ebenen in der SH- Informationsstruktur integriert;

wobei der Schritt des Erzeugens folgendermaßen erzeugt: basierend auf jeweiligen numerischen Kennzeichnern, die in anderen jeweiligen SH-Informationseinheiten enthalten sind, welche in der SH- Informationsstrukturhierarchie unterhalb jeweiliger SH- Informationseinheiten verkettet sind, in welche solche jeweiligen SH- Zahlenwerte integriert werden, und basierend auf den jeweiligen Verkettungen zwischen solchen SH-Informationseinheiten tieferer Ebene;

wobei das SH-Schema in eine SH-Informationsstruktur umgewandelt wird, die Betriebsmittel erkennt, welche solch ein Netzwerkcomputer haben sollte; und

jeweilige AH-Zahlenwerte, die in jeweiligen AH-Informationseinheiten enthalten sind, werden mit jeweiligen SH-Zahlenwerten, die in jeweiligen SH-Informationseinheiten enthalten sind, verglichen, um Teile der AH-Informationsstruktur zu erkennen, die sich von entsprechenden Teilen der SH-Informationsstruktur unterscheiden.

25. Computernetzwerk, das folgendes aufweist: eine in dem Computernetzwerk gespeicherte Bereits-Haben-AH(Already Have)-Informationsstruktur, die AH-Betriebsmittel erkennt, welche ein erster Netzwerkcomputer bereits hat,

wobei die AH-Informationsstruktur eine mehrstufige Hierarchie von AH- Informationseinheiten aufweist, und

wobei jeweilige AH-Informationseinheiten auf höheren Ebenen in der AH-Informationsstrukturhierarchie Strukturdaten aufweisen, die für andere jeweilige AH-Informationseinheiten auf tieferen Ebenen in der AH-Informationsstrukturhierarchie und für Verkettungen zwischen solch anderen jeweiligen AH-Informationseinheiten bezeichnend sind; eine in dem Computernetzwerk gespeicherte Sollte-Haben-SH(Should Have)-Informationsstruktur, die SH-Betriebsmittel erkennt, welche ein solcher erster Netzwerkcomputer haben sollte,

wobei die SH-Informationsstruktur eine mehrstufige SH- Informationsstrukturhierarchie von SH-Informationseinheiten aufweist, und

wobei jeweilige SH-Informationseinheiten auf höheren Ebenen in der SH-Informationsstrukturhierarchie Strukturdaten aufweisen, die für andere jeweilige SH-Informationseinheiten auf tieferen Ebenen in der SH-Informationsstrukturhierarchie und für Verkettungen zwischen solch anderen jeweiligen AH-Informationseinheiten bezeichnend sind.

26. Computernetzwerk, das folgendes aufweist: eine in dem Computernetzwerk gespeicherte Bereits-Haben-AH (Already Have)-Informationsstruktur, die AH-Betriebsmittel erkennt, welche ein erster Netzwerkcomputer bereits hat,

wobei jeweilige AH-Informationseinheiten auf höheren Ebenen in der AH-Informationsstrukturhierarchie Strukturdaten aufweisen, die für andere jeweilige AH-Informationseinheiten auf tieferen Ebenen in der AH-Informationsstrukturhierarchie und für Verkettungen zwischen solch anderen jeweiligen AH-Informationseinheiten bezeichnend sind;

ein in dem Computernetzwerk gespeichertes Sollt-Haben-SH(Should Have)-Schema, das SH-Betriebsmittel erkennt, welche mehrere Computer im Netz haben sollten,

wobei das SH-Schema eine mehrstufige SH- Informationsstrukturhierarchie von SH-Informationseinheiten aufweist, wobei zumindest eine dynamische Verkettung zwischen zumindest einer SH-Informationseinheit auf einer höheren Ebene in der SH- Schemahierarchie und eine von mehreren SH-Informationseinheiten oder mehreren SH-Betriebsmitteln auf einer tieferen Ebene in der SH- Schemahierarchie vorhanden ist, und

wobei jeweilige SH-Informationseinheiten jeweilige Kennzeichner umfassen.

27. Computernetzwerk nach Anspruch 26,

wobei die jeweiligen Kennzeichner jeweilige numerische Kennzeichner umfassen, und das Computernetzwerk weiterhin folgendes aufweist: eine Einrichtung zum Bestimmen einer aktuellen Konfiguration des ersten Netzwerkcomputers;

eine Einrichtung zum Lösen der zumindest einen dynamischen Verkettung in dem SH-Schema basierend auf der Konfiguration, so daß die dynamische Verkettung durch eine gelöste Verkettung zwischen der zumindest einen SH-Informationseinheit und einer der mehreren SH- Informationseinheiten tieferer Ebene oder einer der mehreren SH- Betriebsmittel tieferer Ebene ersetzt ist; und

eine Einrichtung zum Berechnen jeweiliger SH-Zahlenwerte und zum dementsprechenden Integrieren solcher jeweiliger berechneter Zahlenwerte in jeweilige SH-Informationseinheiten auf vorgeschriebenen Ebenen in der SH-Schemainformationsstruktur, wobei jeweilige berechnete SH-Zahlenwerte basierend auf jeweiligen numerischen Kennzeichnern berechnet sind, die in anderen jeweiligen SH- Informationseinheiten enthalten sind, welche in der SH- Schemainformationsstrukturhierarchie unterhalb einer jeweiligen SH- Informationseinheit verkettet sind, in welche ein jeweiliger berechneter SH-Zahlenwert integriert ist.