DE69128575T2 - Flexibles Dienstnetzwerk für Rechnersysteme - Google Patents

Description

• Die vorliegende Erfindung betrifft das Gebiet der Datenverarbeitung. Im einzelnen sieht die Erfindung ein flexibles Dienstnetzwerk für Rechnersysteme vor.
• Die folgenden gleichzeitig anhängigen Patentanmeldungen wurden gemeinsam geltend gemacht und am gleichen Tag beantragt wie die vorliegende Anmeldung und stehen miteinander im Zusammenhang:
• Europäische Patentanmeldung Nr.
• Titel: AUTOMATISIERTE AUFNAHME EINES RECHNERSYSTEMS IN EINEM DIENSTNETZWERK VON RECHNERSYSTEMEN
• Europäische Patentanmeldung Nr.
• Titel: SPUREN DER LÖSUNG EINES PROBLEMS AUF EINEM RECHNERSYSTEM IN EINEM DIENSTNETZWERK VON RECHNERSYSTEMEN
• Europäische Patentanmeldung Nr. Titel: PROBLEMVERHÜTUNG AUF EINEM RECHNERSYSTEM IN EINEM DIENSTNETZWERK VON RECHNERSYSTEMEN
• Das Warten von Mittel- und Großrechner- Datenverarbeitungssystemen ist ein Hauptsektor der Datenverarbeitungsindustrie. Ein Hersteller oder eine Großfirma kann ebenso viele Angestellte für Reparatur und Wartung wie für den Verkauf oder die Entwicklung neuer Systeme beschäftigen. Das Warten verlangt ausgedehnte Netzwerke von Wartungsfachleuten, Teilelagerbestände, Software und physikalische Geräte. Ironischerweise verlangt das Warten von Datenverarbeitungssystemen zum großen Teil menschliche Arbeit und geistige Anstrengung.
• US Patent 4,654,852 schlägt einen Schritt in Richtung auf eine stärker automatisierte Instandsetzung von Datenverarbeitungssystemen vor. Dieses Patent ermöglicht es einem Bediener, Problemanalysen (Problem Determination Procedures - PDPs) zu fahren, die im System selbst abgespeichert sind. Die PDPs können selbständig bestimmen, welche Komponenten im System vorkommen, und sie testen unter Verwendung der Ergebnisse früherer Tests, um festzulegen, welche PDPs als nächste gefahren werden sollen. Diese PDPs können auch den Bediener auffordern, bestimmte Tätigkeiten vorzunehmen, wie z.B. Bedienungselemente zu betätigen, Kabel abzustecken und Programme wiederanlaufen zu lassen. Die PDPs schlagen Problemlösungen als Meldungen an den Bediener vor mit der Empfehlung, bestimmte Aktionen durchzuführen oder bestimmte Wartungsmechaniker beizuziehen.
• Auch ein zentrales Wartungsdatenverarbeitungssystem wurde eingerichtet; z.B. steht das IBM-"RETAIN"-Netzwerk seit Jahren zur Verfügung. Ein Kunde kann die überall im ganzen Staat verfügbare Einrichtung telefonisch ansprechen und ein in seinem System auftretendes Problem einem Wartungsvertreter, entweder einem Außendiensttechniker (Customer Engineer - CE) oder dem Kundendienststab darzulegen. Der Vertreter versucht, das Problem zu diagnostizieren durch Befragen des Kunden, welche Symptome sein System zeigt und welche Hardware- und Software- Komponenten in seinem System vorkommen. Je nach den Antworten des Kunden gibt der Wartungsvertreter bestimmte Schlüsselwörter in ein Terminal ein. Sobald er sich vergewissert hat, daß er das Problem hinreichend charakterisiert hat, greift der Vertreter unter Verwendung der Schlüsselwörter als Suchargumente auf eine oder mehrere im zentralsystem abgespeicherte Problemverwaltungs- Datenbanken zu. Jeder Eintrag in der Datenbank weist ein oder mehrere Schlüsselwörter und Beschreibungen für Lösungsvorschläge für Probleme auf, die durch diese Wörter betroffen werden.
• Die Europäische Patentanmeldung EP-A-0333620 offenbart ein Rechnersystem, das in der Lage ist, ein Problem zu finden und eine Wartungsaufforderung an ein zentrales Wartungssystem zu schicken. Das zentrale Wartungssystem erhält die Wartungsanforderung und durchsucht eine Datenbank, ob für das Problem eine Lösung bekannt ist. Wenn ja, wird diese Lösungsinformation automatisch an das Rechnersystem geschickt.
• Die obige Patentanmeldung stellt einen signifikanten Fortschritt auf dem Gebiet der Rechnersystem-Dienstleistungen dar, jedoch konnte das patentanmeldungsgegenständliche Rechnersystem, das eine Dienstleistung anfordert, Dienstleistungsanforderungen nur an ein zentrales Dienstleistungssystem schicken. Zusätzlich, wenn das zentrale Dienstleistungssystem keine Lösung für das Problem in seiner Datenbank finden konnte, mußte es ein Unterstützungszentrum benachrichtigen, wo sich ein Mensch weiter mit dem Problem befassen mußte. Das zentrale Dienstleistungssystem konnte also automatisch nur eine Teilmenge der Probleme behandeln, auf die die Rechnersysteme, die sich an dieses zwecks Dienstleistung wenden, wahrscheinlich stoßen werden. Das Problem wird noch vergrößert, wenn man überlegt, daß die meisten Rechnersysteme heute Hardware und Software enthalten, die von verschiedenen Herstellern gefertigt werden. Zusätzlich können Rechnersysteme grundlegend unterschiedlich in Hardware- und Software-Konfigurationen und Fähigkeiten sein. Es ist unwahrscheinlich, daß ein zentrales Dienstleistungssystem in der Lage ist, die verschiedenen Probleme, die in vielleicht hunderten und tausenden von Rechnersystemen auftreten können, die von ihm zur Wartung abhängen, auf geeignete Weise bewältigen kann. Diesem Rechnersystem fehlt ferner die Fähigkeit, die Lösung von Problemen auf geeignete Weise zu verfolgen oder eine Problemverhütung anzufordern oder zu erhalten.
• Eine Hauptaufgabe der vorliegenden Erfindung ist es, in einem Rechnersystem auftretende Probleme wirksam zu beheben.
• Eine weitere Aufgabe der Erfindung ist es, ein ganzes Netzwerk von Rechnersystemen zum wirksamen Beheben von Problemen bereitzustellen.
• Noch eine Aufgabe der vorliegenden Erfindung ist es, einen Diensteanforderer zur Verfügung zu haben, der unter mehr als einem Diensteanbieter zur Dienstleistung wählen kann.
• Eine weitere Aufgabe der Erfindung ist es, zuzulassen, daß ein Diensteanbieter ein Diensteanforderer wird, der Dienste von einem anderen Diensteanbieter anfordern kann.
• Noch eine Aufgabe der Erfindung ist es, daß ein Dienstanbieter eine Fern-Problemerfassung und -bestimmung an einem Diensteanforderer ausführt.
• Diese und noch weitere Aufgaben werden von dem hier geoffenbarten Dienstnetzwerk gelöst.
• In einem Dienstnetzwerk sind mehrere Rechnersysteme zusammengeschaltet. Ein Rechnersystem kann sein entweder ein "Diensteanforderer" (Service Requestor - SR) oder ein "Diensteanbieter" (Service Provider - SP) oder aber ein Hybridgerät aus diesen beiden, ein "Diensteanbieter/Anforderer" (Service Provider/Requestor -SP/R).
• Sobald das Dienstnetzwerk aufgebaut ist, kann ein SR automatisch in seinen Komponenten (Hardware, Software oder Mikrocode) auftretende Probleme erfassen, eine Diensteanforderung aufbauen, die das Problem beschreibt, einen SP/R anwählen, der für das Beheben des Problems zuständig ist, und die Diensteanforderung an ebendiesen SP/R schicken. Der für die Behebung des Problems zuständige SP/R erhält die Diensteanforderung, überprüft, ob der SR zum Erhalt der Dienste berechtigt ist, und durchsucht ein Lösungsprotokoll, ob es eine Lösung für das Problem enthält. Wenn ja, wird die Lösungsinformation, die die Behebung des Problems beschreibt, begleitet von einem oder mehreren Softwarekomponenten, Mikrocodekomponenten, Hardware-Teile- Bestellungen und/oder Textanweisungen zum SR geschickt. Wenn der zuständige SP/R das Problem nicht beheben kann, überprüft er, ob er Unterstützung für dieses Problem von anderen SPs oder SP/Rs erhalten kann, mit denen er verbunden ist. Wenn ja, sendet er die Diensteanforderung weiter zu diesem SP bzw. SP/R, der seinerseits die Diensteanforderung zu anderen SPs oder SP/Rs schicken kann, bis eine Lösung gefunden wird. Der SP oder SP/R kann auch Probleme der Fernerfassung und -bestimmung an einem SR durchführen.
• Die vorliegende Erfindung offenbart daher ein Verfahren zur automatischen Analyse und Lösung von Problemen in einem Dienstnetzwerk gemäß Anspruch 1.
• Fig. 1A zeigt ein erfindungsgemäßes, vereinfachtes Dienstnetzwerk.
• Fig. 1B zeigt ein erfindungsgemäßes, komplexeres Dienstnetzwerk.
• Fig. 1C zeigt ein beispielhaftes, erfindungsgemäßes Dienstnetzwerk.
• Fig. 1D zeigt ein extrem komplexes, erfindungsgemäßes Dienstnetzwerk.
• Fig. 2A zeigt ein Blockschaltbild eines erfindungsgemäßen Diensteanforderers.
• Fig. 2B zeigt ein Blockschaltbild eines erfindungsgemäßen Diensteanbieters/Anforderers.
• Fig. 2C zeigt ein Blockschaltbild eines erfindungsgemäßen Diensteanbieters.
• Fig. 3A zeigt die in einem Eintrag des erfindungsgemäßen Problemprotokolls enthaltenen Felder.
• Fig. 3B zeigt die in einem Eintrag des erfindungsgemäßen Dienstanforderung enthaltenen Felder.
• Fig. 3C zeigt die in einem Eintrag des erfindungsgemäßen Lösungsprotokolls enthaltenen Felder.
• Fig. 4A zeigt die in einem Eintrag der erfindungsgemäßen Berechtigungsdatenbank enthaltenen Felder.
• Fig. 4B zeigt die in einem Eintrag der erfindungsgemäßen Unterstützungsdatenbank enthaltenen Felder.
• Fig. 5A zeigt ein Flußdiagramm für das Aufnehmen eines Diensteanforderers in ein Dienstnetzwerk durch einen Diensteanbieter.
• Die Fig. 5B-5H zeigen beispielhafte Bildschirmanzeigen während des Aufnahmeprozesses.
• Fig. 6A zeigt ein Flußdiagramm für das Aufnehmen eines Diensteanbieters in ein Dienstnetzwerk durch einen Diensteanforderer.
• Die Fig. 6B-6D zeigen beispielhafte Bildschirmanzeigen während des Aufnahmeprozesses.
• Fig. 7 zeigt, wie Aufnahmeprozesse gemäß Fig. 5A und 6A bestätigt werden.
• Fig. 8-12 zeigt, wie Fehler von oder für einen Diensteanforderer gefunden, analysiert und gemeldet werden.
• Fig. 13 zeigt, wie Beratungen an einen Diensteanbieter geschickt werden.
• Fig. 14 zeigt, wie ein Diensteanforderer Berichtigungen für unterstützte Komponenten seines Rechnersystems anfordern kann.
• Fig. 15 zeigt die Funktionen, die von einem Diensteanbieter ausgeführt werden können.
• Fig. 16 zeigt, wie ein Diensteanbieter Dienstanforderungen bearbeitet.
• Fig. 17 zeigt, wie ein Diensteanbieter Beratungsvorschläge bearbeitet.
• Fig. 18 leigt, wie ein Diensteanbieter Problemverhütung für einen Diensteanforderer ausführt.
• Fig. 19 zeigt, wie ein Diensteanforderer Daten bearbeitet, die er von einem Diensteanforderer erhält.
• Fig. 20A-20D zeigen beispielhafte Problemverfolgungs- Bildschirmanzeigen.
• Fig. 21 zeigt eine beispielhafte grafische Bildschirmanzeige an einer Konsole für Verfolgungsprobleme.
• Die vorliegende Erfindung steht im Zusammenhang mit dem folgenden Patent und anhängigen Patentanmeldungen:
• US-Patent 4,654,852
• Europäische Patentanmeldung 88480057.4 (Calvert I)
• Europäische Patentanmeldung 89480038.2 (Calvert II).
Inhaltsverzeichnis
• I. Übersicht
• II. Aufnahme eines Rechnersystems in ein Dienstnetzwerk
• III. Lösen von Problemen in einem Dienstnetzwerk
• IV. Spurverfolgungsprobleme in einem Dienstnetzwerk
• V. Problemverhütung in einem Dienstnetzwerk
• VI. Anhang I -- AS/400 System Management Utilities User's Guide [Anwender-Richtlinien für Systemverwaltungs Dienstprogramme] (nicht veröffentlicht).
I. Übersicht
• Im Sinne der vorliegenden Patentanmeldung wird ein Rechnersystem, das eine Dienstleistung von einem oder mehreren Rechnersystemen anfordert und keine Dienstleistung an andere Rechnersysteme erbringt, ein "Service Requestor" [Diensteanforderer] , d.i. "SR" genannt. Ein Rechnersystem, das eine Dienstleistung für ein oder mehrerer Rechnersysteme erbringt, aber auch Dienstleistungen von einem oder mehreren Rechnersystemen anfordern kann, spielt eine hybride, Chamäleon-artige Rolle und heißt hier ein "Service- Provider/Requestor" [Diensteanbieter/anforderer] , d.i. "SP/R". Ein Rechnersystem, das keine Dienstleistung von einem anderen Rechnersystem anfordert, aber Dienstleistungen an ein oder mehrerer Rechnersysteme erbringt, heiß "Service Provider" [Diensteanbieter], d.i. "SP".
• Fig. 1A zeigt ein erfindungsgemäßes, vereinfachtes Dienstnetzwerk. SR 110 ist über das Verbindungselement 120 mit dem SP/R 130 verbunden. SP/R 130 ist über das Verbindungselement 140 mit SP 150 verbunden. In der bevorzugten Ausführungsform sind SR 110, SP/R 130 und SP 150 mittlere Rechnersysteme vom Typ IBM Application System/400, obwohl auch jedes andere Rechnersystem, wie z.B. Großrechner oder Personalcomputer eingesetzt werden können. Die Leitungen 120 und 140 sind normale Fernsprechleitungen, wie z.B. eine Standleitung oder ein öffentliches Schalttelefonnetz oder ein sonstiger Träger, könnte aber auch eine Direktverbindung wie z.B. ein Drahtkabel oder ein Lichtwellenleiter oder ein lokales Netz sein. SR 110 beinhaltet auch Prozessor 111, Speicher 112 und ein oder mehrere Terminals 113. Auf ähnliche Weise beinhaltet SP/R 130 Prozessor 131, Speicher 132 und ein oder mehrere Terminals 133. SP 150 beinhaltet Prozessor 151, Speicher 152 und ein oder mehrerer Terminals 153.
• Fig. 1B zeigt ein erfindungsgemäßes, komplexeres Dienstnetzwerk. Jeder SP/R ist in der Regel mit mehreren SRs verbunden. Der SP/R handelt als Diensteanbieter für diese SRs. Jeder SP/R ist in der Regel auch mit mehreren SPs verbunden. Der SP/R handelt für diese SPs als Diensteanforderer.
• Fig. 1C zeigt ein beispielhaftes, erfindungsgemäßes Dienstnetzwerk. Nehmen wir an, daß SR 110 ein Rechnersystem der Pete's Catering Company, eines hypothetischen Kleinbetriebs ist. SR 110 kommuniziert über Verbindung 120 mit SP/R 130, bekannt als Software Fixit Shoppe, ein hypothetischer Software-Instandsetzungs-Kleinbetrieb. Der Software Fixit Shoppe kommuniziert über Verbindung 140 mit SP 150, einer sagenhaften Anwender-Software-Entwicklungs-Firma, genannt Sam's Spreadsheets. Der Software Fixit Shoppe ist weiterhin verbunden mit SP/R 146 (Really Big Computer Company) und SP 145 (Lots of Words, Inc.). SP/R ist ferner angeschlossen an SP 151, SP/R 152 und SP 153. SP/R 152 ist angeschlossen an SP/R 154 und SP 155. SP/R 154 ist angeschlossen an SP 156, SP 157 und SP 158.
• Ferner ist SR 110 über die Verbindung 171 auch an SP/R170 angeschlossen. SP/R 170 ist auch bekannt als der Hardware Fixit Shoppe. SP/R 170 ist ferner verbunden mit SP 175, SP 176, SP/R 177, SP/R 178 und SP/R 146. SP/R 177 ist ferner angeschlossen an SP 181. SP/R 178 ist ferner angeschlossen an SP 182.
• In der Regel wären Hardware Fixit Shoppe 170 und Software Fixit Shoppe 130 auch mit hunderten oder sogar tausenden von Diensteanforderern wie Pete's Catering 110 verbunden und könnten an mehr SPs oder SP/Rs angeschlossen sein, als es in Fig. 1C dargestellt ist.
• Das Netzwerk der Fig. 1C wird durch einen Aufnahmeprozeß gebildet, der Rechnersysteme in das Dienstnetzwerk aufnimmt. Ein bereits im Netzwerk aufgenommener SP (oder als SP handelnder SP/R) kann die Aufnahme eines SR (bzw. SP/R, der als SR arbeitet) in das Netzwerk anlaufen lassen. Zusätzlich kann ein SR (oder ein als SP handelnder SP/R) eine Anforderung nach Aufnahme ins Netzwerk anlaufen lassen. Bei Anlaufen einer solchen Anforderung muß sie vom Empfänger der Anforderung bestätigt werden.
• Sobald das in Fig. 1C gezeigte Netzwerk aufgebaut ist, kann Pete's Catering Rechnersystem automatisch Probleme mit seinen Komponenten (Hardware, Software oder Mikrocode) entdecken, eine Diensteanforderung unter Beschreibung der Probleme aufbauen, einen SP/R anwählen, der mit der Behebung des Problems betraut wird (entweder Hardware Fixit Shoppe oder Software Fixit Shoppe) und die Diensteanforderung an diesen SP/R schicken. Der mit der Behebung des Problems betraute SP/R erhält die Diensteanforderung, überprüft, ob Pete's Catering zum Erhalt der Dienstleistung berechtigt ist, und durchsucht ein Lösungsprotokoll, um zu sehen, ob er die Lösung für das Problem hat. Wenn ja, wird eine Lösungsinformation, die die Behebung des Problems beschreibt, begleitet von einem oder mehreren Softwarekomponenten, Mikrocodekomponenten, Hardware-Teilebestellungen und/oder Text-Instruktionen an den SR geschickt. Wenn der zuständige SP bzw. SP/R das Problem nicht beheben kann, prüft er nach, ob er für dieses Problem von irgend einem anderen SP oder an die er angeschlossen ist, erhalten kann. Wenn ja, sendet er die Diensteanforderung an den betreffenden SP oder SP/R. Dieser Prozeß wird fortgesetzt, bis eine Lösung für das Problem gefunden ist.
• Nehmen wir z.B. an, Pete's Rechnersystem hat ein Problem mit einer Komponente (auch als im Feld austauschbare Einheit, Field Replaceable Unit - FRU, austauschbare Einheit, Replaceable Unit - RU, Modul oder Objekt bezeichnet) seines Tabellenkalkulations-Anwenderprogramms entdeckt hat. Es bestimmt, daß der Software Fixit Shoppe zum Instandsetzen dieser Komponente zuständig ist, also baut es eine Dienstleistungsanforderung auf und schickt sie zum Software Fixit Shoppe. Das Rechnersystem beim Software Fixit Shoppe überprüft, ob Pete's Catering zum Empfang von Dienstleistungen berechtigt ist und durchsucht ein Lösungsprotokoll nach der Lösung für das Problem. Es kann keine Lösung für das Problem finden, daher überprüft es, ob es Unterstützung für diese Komponente von einem anderen SP oder SP/R erhalten kann, mit denen es verbunden ist. Es findet, daß Sam's Spreadsheets vermutlich Probleme mit Tabellenkalkulations-Anwendungskomponenten unterstützt, deshalb sendet es die Diensteanforderung an Sam's. Das Rechnersystem bei Sam's erhält die Anforderung, durchsucht sein Lösungsprotokoll nach einer Lösung und findet eine Lösung. Es sendet die Lösungsinformation an den Software Fixit Shoppe, der sie an Pete's weiterleitet Sam's Lösungsinformation wird in einem Lösungsprotokoll beim Software Fixit Shoppe gespeichert. Die Lösungsinformation wird auch begleitet von einer Austausch-Softwarekomponente, die anstatt der Komponente des Tabellenkalkulationsprogramms eingesetzt wird, die das Problem verursacht hat.
• Sams Lösungsinformation ist jetzt in einem Lösungsprotokoll beim Software Fixit Shoppe gespeichert. Das heißt, wenn ein anderer Diensteanforderer, der vom Software Fixit Shoppe betreut wird, eine Diensteanforderung mit dem gleichen Problem an den Software Fixit Shoppe schickt, kann der Software Fixit Shoppe diese Behebung des Problems direkt an den Anforderer schicken, ohne die Diensteanforderung an Sams Spreadsheets weiterzuleiten.
• Der Status der Problemlösung kann vom Rechnersystem des Unterstützungsnetzwerks aus Fig. 1C verfolgt werden. Jeder SR, SP/R und SP enthält ein Problemprotokoll zum Verfolgen des Status jedes Problems. Probleme können den folgenden Status aufweisen: OPEN (offen), READY (bereit), PREPARED (vorbereitet), SENT (gesendet), ANSWERED (beantwortet), FIXED (behoben), VERIFIED (überprüft), und CLOSED (abgeschlossen). Das in jedem Rechnersystem vorhandene Problemprotokoll ermöglicht eine leichte Überwachung des Status des Netzwerks. Die Überwachungsaktivität kann vom Anwender über eine Reihe von Bildschirmen oder durch grafische Anzeige einer Bilddarstellung des Netzwerks oder eines Teils des Netzwerks auf einer einem Rechnersystem des Netzwerks zugeordneten Konsole abgefragt werden. Zum Beispiel kann eine Konsole (spezielles Terminal, das von einem Netzwerkbetreiber benutzt wird) beim Software Fixit Shoppe, grafisch alle RSS darstellen, die es unterstützt. Sobald die Diensteanforderung von Pete's Catering her aufgenommen ist, kann das Ikon, das Pete's darstellt, blinken oder die Farbe wechseln, als Zeichen dafür, daß eine Diensteanforderung eingegangen ist. Das Aussehen des Ikon kann sich ändern, wenn die Dienstleistungsanforderung an Sam's Spreadsheets weiterübermittelt ist, dann wieder, wenn die Lösungsinformation bei Sam's eingegangen ist, und dann wieder, wenn sie zu Pete's geschickt ist. Ein System kann auch eine Beratung an andere Rechnersysteme schicken, um diese über Probleme zu unterrichten, für die sie keine Unterstützungszuständigkeit haben.
• Die Rechnersysteme im erfindungsgemäßen Dienstnetzwerk haben ferner die Fähigkeit, Problemverhütungsmaßnahmen durchzuführen bzw. anzufordern. Ein SP (oder SP/R, der als SP handelt) kann prüfen, ob er eine Lösung für Probleme eines oder mehrerer der von ihm unterstützten SRs (oder SP/R, die als SR handeln) parat hat, die er aber bisher nicht gefunden oder gemeldet hat. Wenn ja, kann er Lösungsinformationen verteilen, begleitet von einer oder mehreren Software- Komponenten, Mikrocodekomponenten, Hardware-Teile - Bestellungen und/oder textlichen Anweisungen an die SRs. Zusätzlich kann ein SR (oder SP/R, der als SR handelt) alle bekannten Problembehebungsmaßnahmen für eine Liste Komponenten von einem SP (oder SP/R, der als SP handelt) anfordern. Der SP sendet jede beliebige Behebungsmaßnahme für Probleme, die der Liste der unterstützten Komponenten zugeordnet sind, an den anfordernden SR.
• Nehmen wir zum Beispiel an, daß der Software Fixit Shoppe nach Eingang der Lösung von Sam's für die fehlerhafte Softwarekomponente des Tabellenkalkulationsprogramms wünscht, Problemverhütungsmaßnahmen bei anderen von ihm unterstützten SRs durchzuführen, die dieses Tabellenkalkulationsprogramm benutzten, bei denen jedoch dieses Problem bisher noch nicht aufgetreten ist. Er bestimmt, wer diese SRs sind und schickt die Lösungsinformation an diese, zusammen mit der auszutauschenden Softwarekomponente.
• Fig. 1D stellt ein extrem kompliziertes erfindungsgemäßes Dienstnetzwerk dar. Die Rechnersysteme lassen sich in verschiedene Ebenen einordnen. SRs können Dienstleistungen von einem oder mehreren SPs und/oder SP/Rs anfordern. SP/Rs können einen oder mehrere SRs unterstützen und können ihrerseits Dienste von einem oder mehreren SPs und/oder SP/Rs anfordern. SPs können einen oder mehrere SRs oder SP/Rs unterstützen. Sogar ein SP/SRs-Paar kann gegenseitig Dienste anfordern.
• Fig. 2A zeigt den Diensteanforderer 110 der Fig. 1A in näheren Einzelheiten. Die ausführbaren Elemente der Fig. 2A werden vom Prozessor 111 ausgeführt, der geeignet programmiert ist, wie in den einschlägigen Flußdiagrammen gezeigt wird.
• Das Betriebssystem 210 kann von jeder Art sein, es sollte jedoch vorzugsweise in der Lage sein, eine Anzahl Programme gleichzeitig abzuarbeiten, wie z.B. das Operating System/400. Ein Betriebsmittelverwaltungsprogramm (Resource Manager - RM) 220 enthält kritische Produktdateninformationen (Vital Product Data - VPD) aus einer VPD-Tabelle 221, mit Identifizierung der Hardwarekomponenten (Typen, Baumuster, Seriennummern) und der Sof tewarekomponenten (Produktnummern, Versionshöhe, installierte PTFs); verschiedene dieser Daten wurden echt vom RAs Manager 241 erfaßt. Das RM-Programm unterhält auch eine Topologie-Datei 222, die die Verkopplungen der SR-Komponenten beschreibt.
• Appukationsprogramme 230 jeder herkömmlichen Art werden vom Betriebssystem (OS) 210 unter jeder herkömmlichen Verwaltungstechnik abgearbeitet, wie z.B. eine Auftragswarteschlange (nicht dargestellt) . Das Betriebssystem arbeitet das RM-Programm 220 in Hochfahrzeit (Urladeprogramm - Initial Program Loader -IPL) unter den Applikationsprogrammen 230 als eine Aufgabe ab.
• Eine Reihe von Dienstprogrammen beinhaltet die meisten von der Erfindung benutzten Elemente.
• Alle Subsysteme des SR beinhalten residente, ereignisgesteuerte Zuverlässigkeits- und Wartbarkeits(Reliability and Serviceability - RAS)-Dienstprogramme, die alle Fehler erfassen, die bei der Ausführung ihrer Subsysteme auftreten. Zum Beispiel kann ein E/A-Prozessor in einem Plattenuntersystem, wie 112, Fig. 1, Dienstprogramm 240 aufweisen, das als Interrupt-Routine läuft, wenn immer der E/A-Prozessor einen Interrupt ausgibt, der aus einem Fehler entsteht; sie können auch als anzeigepflichtige Aufgabe laufen. Ein Fehler kann auftreten, wenn eine Operation ein bekanntes, ungültiges Ergebnis liefert, die Zeit überschreitet, nicht anläuft, einen Staufehler in einer Busleitung produziert usw. Ein Zuverlässigkeits und Wartbarkeits-(RAS)-Manager 241 wird von Dienstprogrammen 240 ereignisgesteuert betrieben während das Kundensystem läuft. Anstatt auf der Höhe eines Jobs unter OS 220 zu laufen, arbeitet der RAS-Manager 241 vorzugsweise als ereignisgesteuerte Aufgabe in Mikrocode. Die vom RAS-Manager erfaßten Rohfehler werden in einem Fehlerprotokoll 242 gesammelt; einige dieser Daten werden später in das Problemprotokoll 243 überführt. Von den einzelnen Fehlern erfaßte Daten werden als Eintrag im Fehlerprotokoll geführt. Die Felder der einzelnen Einträge des Fehlerprotokolls sind:
• -- Ein Systemprotokoll-Identifikator, wobei ein unverwechselbarer Schlüssel diesen Fehlerprotokolleintrag identifiziert
• -- Fehlerstatistik (z.B. wie oft ist ein Suchfehler aufgetreten bis der richtige Zylinder gefunden wurde?)
• -- Die vom Auftreten des Fehlers betroffene Komponentenkonfiguration (aus der VPD-Tabelle)
• -- Der vom bestimmten RAS-Dienstprogramm vorgesehene Vorrichtungsstatus, wie z.B. Registerinhalt oder Status- Bits
• -- Ein Bezugscode, der den Fehlertyp identifiziert.
• Das Problemprotokoll 243 umfaßt eine Anzahl Einträge, jeweils einen für jedes angesprochene Problem. (Achtung: "Fehler" ist nicht gleich "Problem".) Jeder Eintrag in das Problemprotokoll enthält Felder für:
• -- Einen netzwerkweiten unverwechselbaren Problem- Identifikator
• -- Statusinformationen
• -- Maschineninformationen (Type, Seriennummer, Baumuster, Änderungsstand, Netzwerk-ID, Steuerzentrale)
• -- Anfangs- oder Einzel-FRU-Liste, in der Reihenfolge Abnehmender Wahrscheinlichkeit
• -- Einzel-FRU-Liste, in der Reihenfolge Abnehmender Wahrscheinlichkeit
• -- Endgültige oder Behebungs-FRU-Liste, in der Reihenfolge Abnehmender Wahrscheinlichkeit
• -- Symptomkette (codierte Bezugszahlen)
• -- Lösungsinformationen (wird eingetragen, sobald das Problem gelöst ist)
• -- Ursprungssystem-Identifizierung (Netzwerk-ID und Steuerzentrale)
• -- Erhalten-von-System-Identifizierung (Netzwerk-ID und Steuerzentrale)
• -- Gesendet-an-System-Identifizierung (Netzwerk-ID und Steuerzentrale)
• -- Vorgeschichte der durchgeführten Problemlösungsaktivität und wer diese Aktivität durchgeführt hat.
• Ein Problemprotokolleintrag kann einen von acht Statuszuständen annehmen: "open" (offen), sobald der Eintrag zunächst aufgebaut wird; "ready" (bereit), sobald alle anwendbaren PDPs 246 mit der Ausführung fertig sind; "prepared" (vorbereitet), nachdem die zugeordnete Diensteanforderung 249 gespeichert ist; "sent" (gesendet) sobald ihn die Diensteanforderung an das zentrale Dienstesystem zur Ausführung gesendet hat; "answered" (beantwortet), nachdem die Lösungsinformation von einem SP oder SP/R eingegangen ist; "fixed" (behoben), sobald die Lösung angewendet wurde; "verified" (geprüft), sobald der SR kontrolliert hat, daß die Lösungsinformation das Problem behoben hat; und "closed" (abgeschlossen), nachdem alle Aktivitäten im Rahmen dieses Problems abgeschlossen sind.
• Die Felder des Problemprotokolleintrags sind in Fig. A dargestellt.
• Nehmen wir wieder Bezug auf Fig. 2A; der Ausdruck "FRU" heißt wörtlich "Field Replaceable Unit" (im Feld auswechselbare Einheit) , das ist die kleinste Systemkomponente, die als Ersatz für eine ausfallende Komponente auf Lager gehalten wird, wie es in der Industrie allgemein üblich ist. Im Kontext der vorliegenden Erfindung jedoch wird dieser Begriff in einem erweiterten Sinn benutzt und bezieht sich auf die kleinste Einheit einer Problemlösung. Eine solche Einheit kann sein eine Hardwarekomponente, wie im üblichen Sinne dieses Ausdrucks, es kann aber auch eine Softwarekomponente sein, wie z.B. ein Programm, ein Modul oder ein Objekt, oder eine Meldung, die eine zur Lösung des Problems durchzuführende Maßnahme bezeichnet. Zum Beispiel kann der Bediener angewiesen werden, bestimmte Schalter zurückzustellen oder einen Kundendienstvertreter für Nachrichtenübermittlungsträger zu rufen.
• Die ursprüngliche FRU-Liste ist die Liste der Komponenten, die vom RAS-Dienstprogramm 240, das das Problem entdeckt hat, als wahrscheinlich gestört verdächtigt werden; diese Liste leitet sich aus dem Fehlerprotokolleintrag ab, der von diesem RAS-Dienstprogramm geschrieben wurde. Die Einzel-FRU-Liste enthält die Komponenten, die von den PDPs 246 verdächtigt werden; jede PDP, die vom PAR-Programm 244 ausgeführt wird, kann eine oder mehrerer FRU-Nummern in das Einzel-FRU- Listenfeld im Problemprotokoll schreiben. Der Diensteanbieter aktualisiert die Einzel-FRU-Liste um eine endgültige FRU- Liste zu erzeugen, die die verdächtigten Komponenten auflistet. Die FRU-Codenummern in jeder dieser drei Listen werden von dem Programm, das sie liefert, in absteigender Ausfallswahrscheinlichkeits-Reihenfolge geordnet; jedes Stück in der Liste hat auch eine ausdrückliche Wahrscheinlichkeitsnummer, die die Wahrscheinlichkeit abschätzt, daß es die ausgefallene Einheit ist; wieder werden diese Nummern vom Konstrukteur der betreffenden Komponenten geliefert. Unterschiedliche Felder eines Problemprotokolleintrags werden zu unterschiedlichen Zeiten geschrieben und mehr als ein Eintrag einzelner Felder kann in einen einzigen Eintrag geschrieben werden.
• Eine Kontaktdatenbank 201 enthält kundenspezifische Informationen, wie z.B. Namen und Anschrift des Kunden, Namen und Telefonnummer eines oder mehrerer Kontaktpersonen, die im Zusammenhang mit Systemproblemen angesprochen werden sollen, bevorzugte Sprachtextanweisungen, und so weiter.
• Ein Problemanalyse- und -lösungsprogramm (Problem Analysis and Resolution Program - PAR) 244 enthält Routinen zum Analysieren der Probleme, die beim RAS-Manager eingehen und in das Fehlerprotokoll eingetragen werden. Wenn der RAS- Manager 241 einen neuen Eintrag in das Fehlerprotokoll 242 vornimmt, kann das PAR-Programm 244 - muß es jedoch nicht immer - einen neuen Eintrag im Problemprotokoll 243 abfassen. Der Systemprotokoll-Identifikator, der Referenzcode, der die Störung identifiziert, und einige der Konfigurationsdaten aus dem Fehlerprotokoll werden auf den Problemprotokolleintrag übertragen. Das PAR-Programm wählt auch unter einer Anzahl Problemanalyseverfahren (Problem Determination Procedures - PDPs) 246 als Reaktion auf Referenzcodes im Problemprotokoll aus. Kurz gesagt, PAR 244 liest die codierten Referenznummern aus dem Problemprotokoll-Symptomfeldern und die Störeinheitcodes aus dem Problemprotokoll. Es wählt dann ein bestimmtes PDP 246 und führt es aus. Das ausgewählte PDP kann weitere Felder im Problemprotokolleintrag befragen, optional den Bediener des Kundensystems nach weiteren Informationen fragen (über einen Bildschirm in einem Terminal 113, Fig. 1) oder optional Anweisungen für den Bediener anzeigen, damit dieser gewisse Maßnahmen ergreift, die nicht automatisch durchgeführt werden können, wie z.B. Schalter in bestimmte Stellung stellen oder Kabel einstöpseln.
• Ein vom Anwender erfaßtes Problemlösungsprogramm (User- Perceived Problem Resolution - UPPR) 247 ermöglicht es dem Bediener des SP, einen Problemprotokolleintrag zu machen, auch wenn der RAS-Manager keine Fehler gefunden hat. Das geschieht mittels eines Anzeigebildschirms oder eines Bedienfeldes 245, die vom Bediener Informationen anfordern und seine Eingaben aufnehmen. Das UPPR-Programm kann bestimmte PDPs 246 als Reaktion auf die Dateneingabe vom Bediener fahren und kann auch den Bediener auffordern, bestimmte Aktionen durchzuführen; es baut eine bestimmte Symptomkette und Liste betroffener Komponenten aus den Ergebnissen des PDP und der Bedienerinformationen auf. In bestimmten Fällen kann ein zu diesem Zweck ausgeführtes PDP das Problem lösen; in diesem Fall wird kein Eintrag erzeugt.
• Ein Systemunterstützungs-Dienstprogramm (System Support Facility - SSF) 248 konvertiert einen ausgewählten Problemprotokolleintrag zu einer Diensteanforderung 249, leitet ihn an einen SP oder SP/R, wie SP/R 130 in Fig. 1, weiter und verwaltet den SR-Teil eines Dialogs mit dem SP oder SP/R. SSF 248 wird auch benutzt, um die Aufnahme in ein Dienstnetzwerk anzufordern, Problemverhütung anzufordern, den Status der Probleme zu verfolgen und Beratungen zu bearbeiten.
• Nehmen wir jetzt Bezug auf Fig. 3B; die Diensteanforderung 249 hat die Form gemäß Fig. 3B1, wenn ein SR verlangt, daß ein bekanntes Problem behoben werden muß. Die Dienstanforderung 249 hat die Form gemäß Fig. 3B2, wenn ein SR eine Problemverhütung für eine Komponente anfordert, wie in Abschnitt V in weiteren Einzelheiten erläutert wird. Die Dienstanforderung 249 hat Felder für:
• -- den Protokoll-Identifikator
• -- Kundendaten (Namen, Telefon-Nr. und Anschrift von Kontaktpersonen sowie Kundensprache)
• -- Maschineninformationen über Maschinen, die Probleme gefunden und gemeldet haben (Typ, Seriennummer, Baumuster, Änderungsstand, Netzwerk- ID, Steuerzentrale)
• -- Bestimmungs-ID (optional - Netzwerk-ID und Steuerzentrale des Diensteanbieters, an den diese Diensteanforderung weitergeleitet werden soll).
• Wenn das Problem bekannt ist:
• -- Problemdaten (Problemprotokollnummer, Tag und Zeit des Auftretens, Schweregrad, Symptomkette, Wiederholungsflags)
• -- Anfangs- und Einzel-FRU-Codes (d.i. Teilenummern von im Feld austauschbaren oder beim Kunden austauschbaren Hardware- und/oder Software-Komponenten, Wahrscheinlichkeitsschätzungen, daß diese Komponenten das Problem verursacht haben, Schlüsselnummer einer Meldung, die das Problem beschreibt)
• -- Textproblembeschreibung (bleibt frei, wenn automatisch).
• Bei Problemverhütung:
• -- Problemverhütungstyp- Identifikator
• -- Komponenten-ID
• Wiederholungsflags werden gesetzt, um anzuzeigen, daß die gleiche Komponente bereits früher innerhalb eines bestimmten Zeitraums (z.B. 30 Tagen) ein Problem gemeldet hat und daß die gleichen Symptome innerhalb dieser Zeitperiode bereits aufgetreten sind. Die Bewertungsziffer ist eine Codenummer, die vom Bediener oder vom System zugewiesen wird, um anzuzeigen, wie schwer das Problem aller Voraussicht nach ist.
• Die Symptomkette ist eine Reihe von Codes, die von den Ergebnissen der Problemerfassung und der anschließenden Problemanalyse neu angeordnet werden.
• Nehmen wir wieder Bezug auf Fig. 2A; das Lösungsprotokoll 202 verfolgt die Konfigurationsänderungen des SR 110. Wie in Fig. 3C gezeigt wird, weist das Lösungsprotokoll 202 die folgenden Felder auf:
• -- Netzwerk-ID und Steuerzentrale
• -- Komponenten-ID
• -- Version/Freigabestand
• -- Lösungsinformation (identifiziert eine oder mehrere Hardware-, Software- oder Mikrocodekomponenten)
• -- Lösungsstatus (für jede oben identifizierte Komponente)
• -- Symptomkette
• -- Voraussetzungen (zeigt an, ob die Lösung bei Problemverhütungsanforderungen geschickt werden sollte)
• Nehmen wir wieder Bezug auf Fig. 2A; die Unterstützungsdatenbank 203 verfolgt, welcher SP oder SP/R zuständig ist für die Unterstützung einer Komponente des Rechnersystems des SR. Wie in Fig. 4B gezeigt wird, weist die Unterstützungsdatenbank 203 die folgenden Felder auf:
• -- Komponenten-ID
• -- Netzwerk-ID des SP oder SP/R
• -- Steuerzentrale
• -- Automatische Installations - Informationen
• -- Problemverhütungsinformationen.
• SR 110 in Fig. 2A kommuniziert mit einem SP/R oder SP über die Verbindung 275.
• Fig. 2C zeigt ein Blockschaltbild des erfindungsgemäßen SP 150.
• Das Problemsteuerprogramm 295 verwaltet den Dialog mit dem SR bzw. SP/R, erledigt die Aufnahme und Problemverhütungsanforderungen, verfolgt den Problemstatus und bearbeitet Beratungen. Das Problemsteuerprogramm 295 wird ausgeführt von den Prozessoren 131 oder 150, die geeignet programmiert sind, wie in den zugehörigen Flußdiagrammen gezeigt wird. Das Problemsteuerprogramm 295 greift auf das Problemprotokoll 261, das Lösungsprotokoll 262 und die Kontaktdatenbank 263 zu. Jeder dieser obigen Teile hat das gleiche Format wie für SR 110 der Fig. 2C diskutiert wurde, enthält jedoch Informationen über alle SPs und SP/RS, die vom SP 150 unterstützt werden. Das Problemsteuerprogramm 295 kommuniziert mit anderen SP/Rs und/oder SRs über die Verbindung 275. Das Problemsteuerprogramm 295 unterrichtet das Wartungspersonal über Problemef die es unterstützt aber nicht beheben kann, über die Verbindung 285. SP 150 weist ferner Konsolenpuffer 264 auf zur-Steuerung der Informationen, die an der Konsole dargestellt werden, wie in Abschnitt IV noch besprochen wird.
• SP 150 weist auch die Berechtigungsdatenbank 270 auf. Die Berechtigungsdatenbank 270 verfolgt, zum Empfang welcher Unterstützung SRs oder SP/Rs berechtigt sind. Die Berechtigungsdatenbank 270 wird in näheren Einzelheiten in Fig. 4A gezeigt und enthält die folgenden Bereiche:
• -- Abnehmer-Beschreibungsdaten (wie in Fig. 5E dargestellt)
• -- Systemtyp
• -- System-Seriennummer
• -- Netzwerk-ID
• -- Steuerzentrale (um SR oder SP/R unverwechselbar zu identifizieren)
• -- Berechtigungsstatus (aufgenommen oder nicht aufgenommen)
• -- Berechtigte Komponenten- ID-Liste
• Fig. 2B stellt ein Blockschaltbild des erfindungsgemäßen SP/R 130 dar. Der SP/R kombiniert die bereits besprochenen Elemente des SR 110 mit den Elementen eines ebenfalls bereits besprochenen SP 150. Hier wird darauf hingewiesen, daß das Problemprotokoll 261, das Lösungsprotokoll 262 und die Kontaktdatenbank 263 Informationen über alle SRs und SP/Rs enthalten, die der SP/R 130 unterstützt; das Problemprotokoll 243, das Lösungsprotokoll 202 und die Kontaktdatenbank 201 enthalten nur Informationen über den SP/R 130.
II. Aufnahme eines Rechnersystems in ein Dienstnetzwerk
• Fig. 5A zeigt ein Flußdiagramm der Aufnahme eines Diensteanforderers in ein Dienstnetzwerk durch einen Diensteanbieter. Dieses Flußdiagramm wird ausgeführt durch den Prozessor 131 oder 151 des SP/R 130 oder SP 150 (Fig. 1) durch Problemsteuerprogramm 295 (Fig. 2B und 2C). Nehmen wir beispielsweise an, daß unser Netzwerk aus dem Software Fixit Shoppe als SP/R, der Dienste an SRs leistet, die als Joe's Deli, Willie's Wigets und Lefty's Scissors bekannt sind (Fig. 1C). Der Software Fixit Shoppe wünscht Pete's Catering als SR in das Dienstnetzwerk aufzunehmen. Block 601 überprüft, ob SP-Attribute definiert oder geändert werden müssen. Für die Zwecke dieses und folgender Flußdiagramme soll sich "SR" sowohl auf einen SR als auch auf einen SP/R, der als SR handelt, beziehen. "SP" soll sich sowohl auf einen SP als auch auf einen SP/R, der als SP handelt, beziehen.
• Wenn Block 601 bejahend beantwortet wird, wird der Bediener am SP zur Eingabe der zu ändernden Attributinformationen aufgefordert, wie in Fig. 5B gezeigt wird. Die Attributinformation der Fig. 5B ist die vorgegebene Attributinformation für alle SRs, die der SP unterstützt - diese kann fallweise für spezifische SRs überschrieben werden, wie in Fig. 5E gezeigt wird.
• Block 610 fragt, ob der Bediener mit Diensteanforderern arbeiten will. Wenn ja, zeigt der Block 611 das Hauptmenü, wie in Fig. 5C gezeigt wird. Das Hauptmenü zeigt, daß Joe's Deli, Willie's Wigets und Lefty's Scissors bereits als SRs im Netzwerk aufgenommen sind. Der Bediener wählt Option 1, um Pete's Catering aufzunehmen, antwortet also Block 620 bejahend und zeigt die Bildschirme, die in den Fig. 5D-SH dargestellt sind. Der Bediener gibt in Fig. 5D Kundeninformationen über Pete's ein, ändert die Vorgabeattribute in Fig. 5E, und fügt in Fig. 5F eine Liste von Komponenten bei, zu deren Dienstleistungen Pete's berechtigt ist. Eine "Komponente" ist definiert als austauschfähige Einheit oder Gruppe austauschfähiger Einheiten aus Hardware, Software oder Mikrocode. Als Hardware käme als Komponente eine ganze Tastatur oder der "Y"- Schlüssel selbst in Frage. Als Software könnte eine Komponente ein ganzes Anwendungsprogramm, ein Betriebssystem oder ein sonstiges Programm sein, das selbst wieder eine Kombination aus anderen Programmen sein kann. Eine Komponente könnte auch ein ganz kleiner Programmteil sein wie ein Objekt oder ein Modul, oder auch ein größerer Teil. Die oben angezogene Calvert II Patentanmeldung zeigt eine Software- Packungsarchitektur, in der ein Programm aus mehreren hierarchisch gegliederten Ebenen austauschfähiger Einheiten (Replaceable Unit - RU) besteht. Eine Komponente kann alles sein, von einer RU auf OCG-Ebene bis zu einer RU auf SFG- Ebene und seine zugeordneten RUs auf der OCG-Ebene, bis zu einer RU auf der AG-Ebene und alle RUs unter ihr in der hierarchischen Struktur. Fig. 5G ermöglicht es dem Bediener, zu unterstützende Komponenten aus einer Liste verfügbarer, jedoch im Augenblick nicht unterstützter Komponenten auszuwählen. Fig. 5H ermöglicht es dem Bediener, festzulegen, welche Sprache jeder Komponente zugeordnet ist die zur Dienstleistung berechtigt ist.
• Sobald alle diese gewünschten Informationen in die betreffenden Bildschirmanzeigen eingegeben sind, nimmt Block 622 (Fig. 5A) einen Berechtigungseintrag in die Berechtigungsdatenbank 270 vor. Der Block 623 schickt die Aufnahmeanforderung an den SR. Der Steuerfluß kehrt zu Block 610 zurück, der prüft, ob es noch weitere SRs gibt, mit denen gearbeitet werden soll. Wenn nicht, endet das Programm mit Block 625.
• Fig. 6A zeigt ein Flußdiagramm für die Anmeldung eines Diensteanbieters in das Dienstnetzwerk durch einen Diensteanforderer. Dieses Flußdiagramm wird durch den Prozessor 111 oder 131 des SR 110 oder SP/R 130 (Fig. 1) durch SSF 248 (Fig. 2B und 2C) ausgeführt. Kehren wir jetzt wieder zu unserem beispielhaften Dienstnetzwerk zurück; Pete's Catering hat jetzt Unterstützung für sein Betriebssystem, Tabellenkalkulationsprogramm, Textverarbeitung, Rezeptdatenbank und Mikrocode vom Software Fixit Shoppe, möchte jedoch, daß jemand auch seine Hardware- Komponenten unterstützt. Pete möchte daher die Aufnahme des Hardware Fixit Shoppe als Diensteanbieter beantragen. Block 651 fragt, ob der Bediener mit SPs arbeiten will. Wenn ja, zeigt Block 652 das Hauptmenü wie in Fig. 68 dargestellt wird. Das Hauptmenü zeigt, daß der Software Fixit Shoppe bereits als SP aufgenommen ist. Pete wählt Option 1, um einen SP hinzuzufügen, beantwortet daher Block 660 mit ja. Block 661 fordert den Bediener durch Anzeigen verschiedener Bildschirme gemäß Fig. 6C und 6D auf, Informationen einzugeben. Fig. 6C1 fordert den Bediener zur Kontaktinformation über den SP auf. Fig. 6C2 fordert den Bediener zur Eingabe von Dienstleistungsattributen auf. Fig. 6D fordert den Bediener zur Eingabe der Liste der Komponenten auf, für die Unterstützung angefordert wird.
• Nachdem die erforderlichen Informationen vorgesehen sind, erstellt Block 662 einen Eintrag in die Unterstützungsdatenbank 203. Dieser Eintrag zeigt, daß Unterstützung angefordert wurde, jedoch noch nicht bestätigt wurde. Block 663 schickt die Aufnahmeanforderung an den SP. Die Aufnahmeanforderung enthält die Liste der angeforderten Komponenten zusammen mit der Identifizierungsinformation über den SR.
• Hier muß angemerkt werden, daß ein SP/R fordern kann, daß eine Komponente unterstützt wird, die nicht installiert ist oder sogar im SP/R-System gar nicht vorkommt. Ein SP/R kann einen oder mehrere SRs haben, die auf ihn zwecks Unterstützung zugreifen. Die Komponente, für die ein Dienst angefordert wird, kann in einem oder mehreren dieser SR- Systeme installiert sein, jedoch möglicherweise nicht im SP/R-System, das bei der Aufnahmeanforderung für diese Komponente Dienstleistung anfordert.
• Fig. 7 zeigt jetzt, wie der Aufnahmeprozeß gemäß Fig. 5A und 6A genehmigt wird. Dieses Flußdiagramm wird von den Prozessoren 111, 131 oder 151 des SR 110, SP/R 130 oder SP 150 (Fig. 1) durch SSF 248 oder Problemsteuerprogramm 295 durchgeführt (Fig. 2). Block 710 prüft, ob es eine Aufnahmeanforderung zu bearbeiten gibt. Wenn ja, fragt Block 721, ob die Anforderung bestätigt ist. Das wird in der Regel manuell durchgeführt durch Schicken einer Meldung an den Bediener mit der Bitte um Bestätigung der Komponentenliste. Die Bestätigung könnte auch automatisch durchgeführt werden durch Prüfen der Berechtigungsdatenbank auf Informationen, die bereits im Block 622 der Fig. 5A eingegeben wurden (im Falle eines SP, der eine Anforderung von einem SR bestätigt) oder durch Prüfen der Unterstützungsdatenbank auf Informationen, die bereits in Block 662 der Fig. 6A eingegeben wurden (im Falle eines SR, der eine Anforderung auf Aufnahme von einem SP bestätigt). Zum Beispiel kann ein SP bereits einen Eintrag in einer Berechtigungsdatenbank vorbereitet haben, der alle Informationen über einen spezifischen SR und eine Komponentenliste enthält, jedoch mit einem Aufnahmestatus "nicht aufgenommen". Wenn das gemacht ist, kann eine übereinstimmende Aufnahmeanforderung, die von diesem SR her eingeht, automatisch bestätigt werden und der Status des Eintrags ändert sich zu "aufgenommen"
• Für diese bestätigten Komponenten aktualisiert Block 722 die Berechtigungsdatenbank 270 oder die Unterstützungsdatenbank 203 und sendet in Block 730 einen Gültigkeitsvermerk an den SR oder SP. Sobald der SR oder SP den Gültigkeitsvermerk aufnimmt, aktualisiert er seine Unterstützungs- oder Berechtigungsdatenbank, um anzuzeigen, daß die Aufnahmeanforderung bestätigt wurde. Für nicht bestätigte Komponenten wird in Block 731 ein Zurückweisungsvermerk gesendet. Der SR oder SP empfängt den Zurückweisungsvermerk und aktualisiert seine Unterstützungs- oder Berechtigungsdatenbank, um anzuzeigen, daß die Unterstützung für diese Komponenten zurückgewiesen wurde.
• Der Rest unseres beispielhaften Dienstnetzwerks der Fig. 1C ist so aufgebaut, wie oben bereits besprochen wurde.
III. Problemlösung in einem hierarchischen Dienstnetzwerk
• Die Fig. 8-12 zeigen, wie Probleme gefunden, bestimmt und gemeldet werden, entweder durch einen Diensteanforderer oder für einen Diensteanforderer durch Fernübertragung von einem Diensteanbieter. Diese Flußdiagramme werden von den Prozessoren 111 und 131 des SR 110, und SP/R 130 (Fig. 1A) durch seinen Element-Ressourcenmanager 220, UPPR- Dienstprogramm 247, PAR-Dienstprogramm 244, SSF 248, RAS Dienstprogramme 240, RAS-Manager 241 und PDPs 246 ausgeführt (Fig. 2A und 2B). Für die Zwecke der vorliegenden Diskussion wird angenommen, daß SP 150 die Elemente des SP/R 130 aufweist, wie in Fig. 28 dargestellt ist, wenn Problem- Fernerfassung und -bestimmung ausgeführt werden soll.
• Wenn Block 801 bejahend beantwortet wird, sucht er nach Fehlern in einem lokalen System durch Aufruf der Subroutine 900 in Fig. 9. Nehmen wir jetzt Bezug auf Fig. 9; hier bewirkt OS 210, daß das RM-Programm 220 unter Verwendung des RAS-Manager 241 bei Block 310 Systemdaten aufnimmt. Wie in den oben genannten Patentanmeldungen beschrieben, enthalten Hardware- und Softwarekomponenten des Systems 110 in sich selbst "kritische Produktdaten" (Vital Product Data - VPD), die zwecks Identifizierung ihrer Teilenummern, technischen Änderungsstands, Programmcodehöhe und so weiter gelesen werden können. Diese Daten beinhalten Typnummer, Baumusternummer und Seriennummer für das System als ganzes und/oder für eine Komponente. Das RM-Programm liest VPD- Informationen für jede Komponente und speichert sie in einer VPD-Tabelle ab. Diese Tabelle wird in einem Systembetriebsmittel-Manager (System Resource Manager - SRM), einer Datenbank oder einer Topologie-Datei gespeichert, die beschreibt, wie die Komponenten miteinander verbunden sind; diese Daten können von einem (nicht dargestellten) herkömmlichen Konfigurationsprogramm abgeleitet werden, das ausgeführt wird, sobald das SR-System umkonfiguriert oder erweitert wird.
• Das Betriebssystem 210 folgt dann einer herkömmlichen Auftragswarteschlange 230 zur Durchführung der Systemaufgaben. Einige dieser Aufgaben können gleichzeitig mit anderen Aufgaben in der Warteschlange abgearbeitet werden. Bei Ausführung jeder Aufgabe führt OS 210 eine Umgebungsaufzeichnung 322 durch, durch die jede abgearbeitete Aufgabe und der Zustand des Systems beschrieben wird.
• Während dieser Zeit, wie durch die Punktlinie 302 dargestellt wird, sind die RAS-Dienstprogramme 240, Fig. 2, in der Lage, im dortigen eigenen Teilsatz des Systems abzulaufen. Sobald ein Fehlerzustand in einer Komponente auftritt, bewirkt Block 330, daß das geeignete RAS-Dienstprogramm am Block 331 abläuft. Wenn das Dienstprogramm durch Lesen der Status-Bits, Durchführen von Tests usw. die Natur des Fehlers feststellt, schreibt es in Block 332 einen Eintrag in das Fehlerprotokoll. Fehlerprotokolleinträge wurden im Zusammenhang mit Fig. 2 beschrieben. Die FRU-Liste, die vom Fehlerprotokolleintrag abgeleitet wird, ist eine Reihe von Codes mit den begleitenden Wahrscheinlichkeiten, daß die zugeordnete FRU (d.i. eine Hardware- oder Software-Komponente oder ein Meldungscode, der eine auszuführende Maßnahme kennzeichnet) den Fehler wirklich verursacht hat. Dann geht die Steuerung wieder auf Block 330 im Dienstprogramm über, das den Fehlerprotokolleintrag geschrieben hat. Wenn ein Dienstprogramm einen Eintrag in das Fehlerprotokoll geschrieben hat, läuft der ereignisgesteuerte RAS-Manager 241 in Block 333 ab.
• Wenn der Fehler signifikant ist (der Fehler kann vom Teilsatz des Systems nicht korrigiert werden), erzeugt Block 334 einen neuen Eintrag in das Problemprotokoll und schreibt die im Zusammenhang mit Fig. 2 beschriebenen Daten einschließlich der ursprünglichen FRU-Liste, die aus dem ersten Fehlerprotokoll erhalten wurde, in diesen Datensatz. Weil noch keine Diagnose oder sonstige Analyse durchgeführt wurde, ist diese ursprüngliche FRU-Liste in der Regel länger als die Einzel-FRU-Liste, die noch in das Problemprotokoll geschrieben werden muß. Dann greift der Block 335 auf eine Meldung zu (unter Verwendung eines herkömmlichen Sprachauswahl-Dienstprogramms im System) und zeigt diese dem Systembediener auf seinem Terminal 113, Fig. 1. In Block 930 kehrt dann die Subroutine zum Block 810 der Fig. 8 zurück. Falls Fehler gefunden wurden, wird Block 810 bejahend beantwortet und die Subroutine 1000 der Fig. 10 wird aufgerufen. Nehmen wir jetzt Bezug auf Fig. 10; der Block 1001 prüft, ob das Problem vom System oder vom Bediener gemeldet wurde. Wenn es vom Bediener gemeldet wurde, wird diese Subroutine direkt in Beantwortung eines Befehl eingegeben, den der Bediener über Terminal 113 eingibt - ansonsten wird sie durch Block 810 der Fig. 8, der bejahend beantwortet wurde, eingegeben.
• Falls vom System erfaßt geht die Steuerung dann auf Block 410 über, wo das PAR-Programm 244 ein besonderes PD-Verfahren 246 gemäß den Codes in der ursprünglichen FRU-Liste des gewählten (bzw. des ersten) Problems anwählt. Die angewählte PD- Prozedur 246 läuft in Block 420 ab. PDPs haben Zugriff auf die Konfigurationsdaten des Systems und können bewirken, daß weitere PDPs ablaufen, wie bei 420 gezeigt wird. Das ausdrückliche Ergebnis eines PDP ist einer oder mehrere Codes, die eine FRU spezifizieren, zusammen mit der Fehlerwahrscheinlichkeit. PDPs sind Diagnoseroutinen, die Entscheidungsbäume verwenden, die von den Ergebnissen von Tests und/oder Bedienereingaben gesteuert werden.
• Der Block 424 schreibt die Ergebnisse der von der angewählten PD-Prozedur ausgeführten Tests in den Problemprotokolleintrag. Genauer gesagt, das Einzel-FRU-Feld des Problemprotokolleintrags nimmt Referenzcodes auf, die die am wahrscheinlichsten gestörten FRUs repräsentieren, zusammen mit einem Code, der die Identität und den Aussprungspunkt der letzten durchzuführenden PDP kennzeichnet. Block 425 schreibt bestimmte VPD-Codes, die für das Problem relevant sind, wie z.B. das Baumuster und die Seriennummer des Kundensystems, in den Problemprotokolleintrag. Der Status des Problemprotokolleintrags ändert sich jetzt und wird "ready".
• Block 430 konvertiert die Einzel-FRU-Liste aus dem Problemprotokolleintrag zu einer Symptomkette durch Anwählen der wahrscheinlichsten Störung(en) aus der Einzel-FRU-Liste unter Umformatieren derselben, und des Codes, der die PDP- Identität und den Aussprungspunkt angibt. Block 431 erhält Kundeninformationen, entweder von der Kontaktdatenbank 201, Fig. 2, oder vom Bediener, falls dieser beschließt, die Datenbankinformation zu überschreiben. Diese Informationen beinhalten die Namen und die Telefonnummern der Kontaktpersonen am Standort des Kunden und beinhalten auch eine Bewertungsziffer für das Problem. Dieser Code wird wahlweise vom Bediener vergeben, um die Dringlichkeit für die Lösung des Problems anzuzeigen. Der Bediener kann auch wahlweise eine textliche Beschreibung des Problems geben, die an diesem Punkt in die Diensteanforderung aufgenommen wird. Block 440 schreibt dann die aktuelle Diensteanforderung in den Wahrscheinlichkeitsprotokolleintrag gemäß dem Format, das im Zusammenhang mit Fig. 2 beschrieben wurde und in Fig. 3B gezeigt wird. (Wenn die Anforderung aus dem UPPR-Prozeß stammt anstatt aus dem PAR, ist die FRU-Liste jedoch in der Form einer Schlüsselwortsequenz anstatt numerischer Referenzcodes). Jetzt wird der Status des Problemprotokolleintrags "prepared".
• Möglicherweise entscheidet der Bediener, daß der SR ein Problem hat, obwohl dieser selbst noch kein Problem entdeckt hat. Wenn das geschieht, wählt er den Lösungsprozeß für ein vom Anwender gefundenes Problem (User-Perceived Problem Resolution - UPPR) über einen anderen Befehl bzw. eine Funktionstaste auf seinem Terminal (Fig. 1A).
• In diesem Fall wählt Block 450 eine Bildschirmanzeige, die vom Bediener bestimmte Informationen anfordert. Block 452 akzeptiert Eingabedaten und formatiert die Anworten des Bedieners als Schlüsselworte um und schreibt sie in eine Symptomkette im Einzel-FRU-Listenfeld eines neu erzeugten Problemprotokolleintrags für dieses Problem, der während des UPPR-Prozesses gebildet wird. Block 453 findet jedes Systemproblem, das während des UPPR-Prozesses auftritt. Wenn ein Problem erkannt wird, geht die Steuerung automatisch auf den PAR-Prozeß über und läuft in Block 420 ab. Wird kein Fehler gefunden, geht die Steuerung von Block 453 auf Block 454 über, um zu sehen, ob das Problem hinreichend isoliert ist. Wenn nicht, geht die Steuerung über auf Block 450, der dann einen anderen Bildschirm auf der Grundlage der Schlüsselwörter anwählt, die als Antwort auf vorhergehende Bildschirmanzeigen generiert wurden. Die im Block 450 angezeigten Bildschirme können bestimmte Aktionen verlangen, Fragen über das System stellen und Beratungsinformationen ausgeben. Wenn Block 454 bestimmt, daß das Problem hinreichend isoliert ist, geht die Steuerung auf Block 430 über und der Prozeß läuft weiter wie bevor.
• Block 460 legt fest, ob die Diensteanforderung jetzt gesendet werden soll oder nicht. Wenn die Problemerfassung und der Festlegungsprozeß bis zu diesem Zeitpunkt automatisch war, wird Block 460 in der Regel bejahend beantwortet. Es ist jedoch auch ganz gut möglich, daß das im augenblicklichen Problemprotokolleintrag identifizierte Problem zu diesem Zeitpunkt gelöst ist; d.h. eine oder mehrere als Antwort auf die Meldungen aus der ursprünglichen oder Einzel-FRU-Liste vom Bediener durchgeführte Aktionen haben den Fehler im Kundensystem behoben. Dann kann der Bediener in Block 1010 aus dem Prozeß aussteigen. Er kann auch aussteigen, wenn er beschließt, mit der Analyse weiterer Probleme fortzufahren und sie alle zusammen zu einem späteren Zeitpunkt zu senden oder einen direkten Anruf bei einem Außendiensttechniker (Customer Engineer - CE) oder Kundendienstmitarbeiter zu tätigen. In diesem Fall bleibt die Diensteanforderung gespeichert mit einem Status-Flag, das auf den Status "prepared" gesetzt wird, was anzeigt, daß sie zum Senden an das Dienstsystem bereit ist. Wenn er sich entscheidet, mit der Problemlösung weiterzumachen oder wenn das Problem automatisch erfaßt und voraussichtlich automatisch gesendet werden soll, sendet Block 462 die Diensteanforderung an den oder die in der Unterstützungsdatenbank 280 identifizierten SP oder SPs als diejenigen, die die vermutlich störungsbehaftete Komponente unterstützen. Im Regelfall unterstützt nur ein einziger SP eine Komponente, es kann jedoch erwünscht sein, für eine bestimmte Komponente Unterstützung von vielen unterschiedlichen SPs zu erhalten. Block 465 aktualisiert den Eintrag in das Problemprotokoll, um anzuzeigen, daß das Problem einen Status "sent" hat. Die Subroutine kehrt im Block 1010 zu Block 820 in Fig. 8 zurück. Block 820 legt fest, ob ein SP/R auf einem SR, den er unterstützt, eine Fernproblemerfassung und -bestimmung durchführen will. Wenn ja, wird ein Bediener an der SP/R- Konsole (die ein spezielles der Terminals 133 oder 153 in Fig. 1A ist, das für Netzwerk-Bediener reserviert ist) im Fernanschluß mit dem SR verbunden und kann sich in das SR- Rechnersystem einklinken. Selbstverständlich muß der Bediener eine Anwender-ID mit Paßwort haben, damit er auf das SR- System zugreifen kann. Sobald er aber angeschlossen ist, kann der Bediener am SP die Subroutinen gemäß Fig. 11 und 12 anlaufen lassen, um die Fernerfassung und -bestimmung durchzuführen.
• Die Fig. 11 und 12 sind den Fig. 9 und 10 sehr ähnlich, mit den folgenden Abweichungen.
• Block 1260 (Fig. 12) zeigt an, ob am SR ein Bediener verfügbar ist, um am SR Aufgaben auszuführen. Wenn nicht, werden die Bildschirmanzeigen in Block 1261 verändert, um die Aufgaben auszuschließen, die einen Bediener am SR voraussetzen. Innerhalb der in Block 1220 ausgeführten PDP wird festgestellt, ob ein Bediener am SR vorhanden ist; und wenn nicht, werden die in der PDP dargestellten Bildschirmanzeigen in gleicher Weise verändert. Das Fehlen eines Bedieners am SR kann dazu führen, daß das auszuführende Problem weniger isoliert ist. Wenn ein Problem entdeckt wird, zieht Block 1270 Informationen aus dem üblicherweise zur Vorbereitung einer Diensteanforderung benutzten SR heraus, um sein Lösungsprotokoll nach einer Behebung zu durchsuchen (effektiv Überspringen zu Block 1611 in Fig. 16A, weil keine Diensteanforderung erforderlich ist). Wenn keine Behebung gefunden wird, wird der SP/R ein Diensteanforderer und bereitet eine Diensteanforderung für den SR mit dem Problem in Block 1275 vor. Der SP/R schickt die Diensteanforderung an den/die SP(s), die in Block 1280 als diese Komponente unterstützend in der Unterstützungsdatenbank dieses SP/R angegeben sind. In Block 1290 kehrt die Subroutine zu Block 830 in Fig. 8 zurück. Der Rest der Fig. 8 wird in den Abschnitten IV und V diskutiert.
• In der bevorzugten Ausführungsform ist die zur Durchführung einer Fernproblemerfassung und -bestimmung erforderliche Sitzung eine APPC-Sitzung (LU 6.2) in einem APPN-Netzwerk, obwohl auch andere Typen bekannter Verbindungen wie Standleitung, geschaltetes oder öffentliches Datennetz benutzt werden könnten.
• Fig. 15 zeigt die Funktionen, die von einem Diensteanbieter geleistet werden können. Dieses Flußdiagramm wird vom Prozessor 131 oder 151 des SP/R 130 oder SP 150 (Fig. 1A) ausgeführt mittels eines Problemsteuerprogramms 295 (Fig. 2B und 2C). Block 1501 überprüft, ob es eine Diensteanforderung zu bearbeiten gibt. Wenn ja, wird Subroutine 1600 in Fig. 16 aufgerufen. Block 1601 überprüft, ob es Diensteanforderungen durchzuführen gibt. Wenn ja, überprüft Block 1602 seine Berechtigungsdatenbank, ob der SR, der die Diensteanforderung geschickt hat, zur Entgegennahme von Dienstleistungen für die vermutlich fehlerhafte Komponente berechtigt ist. Wenn nicht, wird in Block 1605 eine Fehlermeldung an den SR geschickt und die Steuerung kehrt zu Block 1601 zurück, um nach weiteren Diensteanforderungen zu suchen. Wenn Block 1602 bejahend beantwortet wird, prüft Block 1603, ob diese Diensteanforderung bereits früher einmal von diesem SR eingegangen war. Wenn ja, sendet Block 1605 eine Fehlermeldung an den SR. Wenn nicht, erzeugt Block 1610 einen Eintrag in sein Problemprotokoll um anzuzeigen, daß eine Diensteanforderung eingegangen war. Block 1615 aktualisiert die Konsole am SP. Block 1611 durchsucht das Lösungsprotokoll 262 nach möglichen Lösungen für das Problem. Das Lösungsprotokoll 262 enthält Lösungen für Probleme mit Hardware, Software und Mikrocodekomponenten.
• Block 1620 prüft, ob die Anzahl der Übereinstimmungen größer ist als der Schwellenwert, der während des Aufnahmeprozesses (Fig. 5B) spezifiziert wurde. Wenn ja, wird in Block 1621 das Kundendienstpersonal am SP über die Verbindung 285 über das Problem informiert, so daß geeignete menschliche Eingriffe vorgenommen werden können. Wenn nicht, fragt Block 1630, ob keine Übereinstimmungen gefunden wurden. Wenn keine Übereinstimmungen gefunden wurden, prüft Block 1631, ob ein anderer SP diese Komponente unterstützt. Ein anderer SP unterstützt diese Komponente, wenn a) die Diensteanforderung eine Ziel-ID enthält, die die Netzwerk-ID und die Steuerzentrale eines spezifischen Diensteanbieters spezifiziert, oder b) die Unterstützungsdatenbank zeigt, daß ein anderer SP diese Komponente unterstützt. Wenn nicht, prüft Block 1625, ob diese Dienstanforderung eine Problemverhütungsanforderung ist (die in weiteren Einzelheiten in Abschnitt V diskutiert wird). Wenn ja, wird eine Meldung an den SR zurückgegeben, daß keine Behebungen für nicht gemeldete Probleme gefunden wurden. Wenn nicht, wird das Kundendienstpersonal am SP in Block 1621 über das Problem unterrichtet. Wenn Block 1631 positiv beantwortet wurde, schickt Block 1640 die Diensteanforderung über die Verbindung 275 weiter an den unterstützenden SP bzw. die SPs. Block 1645 schickt dann eine Meldung an den SR mit der Anzeige, daß die Diensteanforderung an einen anderen SP weitergeleitet wurde. Block 1646 aktualisiert den Status im Problemprotokoll im SP auf "SENT" und aktualisiert die Konsole im SP. Der Steuerfluß kehrt zu Block 1601 zurück, um nach weiteren zu bearbeitenden Diensteanforderungen zu suchen.
• Wenn Block 1630 negativ beantwortet wird, wurde eine behandelbare Anzahl Übereinstimmungen im Lösungsprotokoll gefunden. Block 1633 speichert die Lösungsinformation, die die Lösung für das augenblickliche Problem im Problemprotokoll im SP angibt. Die Lösungsinformation kann eine oder mehrerer der nachstehenden Informationstypen enthalten:
• -- Anweisungen an den Bediener am SR, bestimmte Maßnahmen zu ergreifen, um das Problem zu lösen (z.B. einen Schalter zurückzustellen, ein Kabel wieder anzuschließen, einen Datenübermittlungsträger-Kundendienstvertreter zu rufen)
• -- Eine Teilenummerliste, die Hardwarekomponenten zum Einbau durch den Kunden oder einen Kundendienstvertreter identifiziert
• -- Eine Liste von Software- oder Mikrocodekomponenten zur Lösung eines Software- bzw. Mikrocodeproblems.
• Block 1651 fügt den Status "ANSWERED" zum Eintrag in das Problemprotokoll im SP hinzu. Block 1655 prüft durch Überprüfen der Informationen, die während des Aufnahmeprozesses in die Kontaktdatenbank eingegeben wurden, ob die Lösungsinformation automatisch gesendet werden soll. Wenn ja, fordert Block 1657, daß der SR eine derzeitige Kopie seines Lösungsprotokolls an den SP schickt. Obwohl das Lösungsprotokoll des SP Daten vom SR enthält, die er kennt, ist es möglich, daß das SP-Lösungsprotokoll nicht die auf den neuesten Stand gebrachte Information kennt. Das kann geschehen, wenn der SR Lösungsinformationen von einem anderen SP erhalten hat oder wenn der SR eine Komponente erhalten hat, die aus einer nicht im Netzwerk aufgenommenen Quelle stammt.
• Block 1660 vergleicht das vom SR gesendete Lösungsprotokoll mit seinem eigenen Lösungsprotokoll, ob der SR bereits alle Lösungsinformationen hat. Wenn ja, hat die früher gesendete Lösungsinformation das Problem nicht behoben, also informiert Block 1656 das Kundendienstpersonal am SP sowie am SR. Wenn nicht, ordert Block 1662 Hardware für den SP, sendet Austauschsoftwarekomponenten an den SP und/oder schickt Mikrocodekomponenten, die auf dem SR noch nicht vorhanden sind. Block 1663 schickt alle Lösungsinformationen zusammen mit der Problem-ID an den SR, und bringt im Block 1665 das Lösungsprotokoll im SP auf den letzten Stand, um die an den SR übermittelte Lösung anzuzeigen. Block 1666 aktualisiert die Konsole am SP, und der Steuerfluß kehrt zu Block 1601 zurück, um nach weiteren Diensteanforderungen zur Bearbeitung zu suchen. Im Block 1699 kehrt die Subroutine zu Block 1502 der Fig. 15 zurück.
• Fig. 19 zeigt die Schritte, die die Systemunterstützungseinrichtung 248 des SR ausführt, wenn sie die in Block 1662 und 1663 an sie gesendeten Informationen erhält. Block 1920 erhält die Lösungsinformationen vom SP und speichert den Eintrag in seinem Problemprotokoll entsprechend der Problem-ID und in seinem Lösungsprotokoll ab. Block 1920 prüft auch sein Problemprotokoll, ob die mit dieser Lösungsinformation gesendete Problem-ID einer Dienstanforderung entspricht, die von einem anderen SR eingegangen ist. Wenn ja, wird die Lösungsinformation an den SR gesendet, der die Anforderung geschickt hat. Block 1925 ändert den Status des Eintrags im Problemprotokoll zu ANSWERED. Der SR erhält in Block 1930 die Hardware-, die Software- und/oder die Mikrocodekomponenten und aktualisiert in Block 1935 das Lösungsstatusfeld im Lösungsprotokoll, um anzuzeigen, daß Hardware, Software und/oder Mikrocode eingegangen sind. Die Komponenten werden ggf. an den anfordernden SR weitergeleitet.
• Dann fragt Block 1950, ob diese Lösung im Rechnersystem installiert werden soll. Block 1950 kann sofort ausgeführt werden oder auch einige Stunden oder sogar Tage und Wochen später. Eingriff durch einen Menschen kann bei dieser Entscheidung erwünscht sein, oder die Entscheidung kann sich auf Informationen gründen, die während des Aufnahmeprozesses in das Feld für automatische Installation in der Unterstützungsdatenbank eingegeben wurde. Zum Beispiel kann der Software Fixit Shoppe beschließen, alle Lösungen für Komponenten, die von der Really Big Computer Company unterstützt werden, automatisch zu installieren, aber nicht Komponenten, die von Sam's Spreadsheets unterstützt werden.
• Wenn Block 1950 bejahend beantwortet wird, wendet Block 1955 die Lösung auf das System an und Block 1960 aktualisiert den Eintrag im Problemprotokoll durch Hinzufügen des Status "FIXED". Block 1960 aktualisiert auch den Eintrag in das Lösungsprotokoll durch Hinzufügen des Status "APPLIED".
• Block 1970 fragt, ob die Lösung überprüft ist. Dieser Block wird bejahend beantwortet, wenn das System getestet wurde und das Problem, das die Diensteanforderung hat anlaufen lassen, nicht mehr existiert. Dieser Überprüfungsprozeß kann automatisch abgewickelt werden durch Neuanlaufenlassen des Erfassungs-Flußdiagramms der Fig. 9, oder kann auch manuell über einen menschlichen Eingriff ausgeführt werden. Block 1970 könnte daher sofort oder mit beträchtlicher Verzögerung ausgeführt werden. Wenn Block 1970 bejahend beantwortet wird, aktualisiert Block 1975 das Problemprotokoll durch Hinzufügen des Status "VERIFIED". Block 1980 benachrichtigt den SP, daß das Problem überprüft ist, und so kann der SP sein Problemprotokoll aktualisieren. Block 1985 aktualisiert dann den Status zu "CLOSE", wenn alle Aktivitäten bezüglich des Problems abgeschlossen sind.
IV. Informationsverfolgungsprobleme in einem Dienstnetzwerk
• Die meisten Probleme in einem Dienstnetzwerk lassen sich verfolgen, sobald ein neuer Status zu einem Problemprotokolleintrag hinzugefügt wird oder wenn eine Diensteanforderung gesendet und empfangen wird. Ein SP ist in der Lage, alle Probleme, für die er auf diese Weise Unterstützung angefordert hat, zu verfolgen. Jedoch Probleme, die in SRs auftreten, für die er noch keine Unterstützungsanforderung aufgenommen hat, sind dem SP in der Regel nicht bekannt. Zum Liefern dieser zusätzlichen Informationen wird eine "Beratung" benutzt. Eine Beratung kann von jedem System im Dienstnetzwerk benutzt werden, um ein oder mehrere andere Systeme im Dienstnetzwerk über ein Problem zu informieren, das in einem anderen System im Dienstnetzwerk aufgetreten ist.
• Daher können Beratungen benutzt werden, um die über die Dienstleistungsanforderungen erhaltenen Statusinformationen betreffend andere Systeme im Dienstnetzwerk zu ergänzen.
• Nehmen wir wieder bezug auf Fig. 8, Block 830 kontrolliert, ob es Beratungen zum Senden gibt. Wenn ja, wird die Subroutine 1300 der Fig. 13 aufgerufen.
• Block 1303 baut eine Beratungsmeldung auf. Die Beratungsmeldung enthält die Komponenten-ID, textliche und/oder codierte Informationen über das Problem und Informationen, die den Sender der Beratung identifizieren. Block 1304 sendet die Beratungsmeldung an den/die betroffenen SP(s) oder SR(s). Das wird festgelegt durch Prüfen der Unterstützungsdatenbank 203 und/oder der Berechtigungsdatenbank 270, um zu sehen, welche Sp, SPs, SR oder SRs unterstützt werden sollen bzw. zur Entgegennahme der spezifizierten Komponenten-IDS berechtigt sind. Als Alternative kann das Komponenten-ID-Feld besondere Sendedaten enthalten, die angeben, daß diese Beratung an alle SPs oder SRs gesendet werden soll, die in der Unterstützungs- und/oder Berechtigungsdatenbank angezogen sind. In Block 1320 kehrt die Subroutine zu Block 840 der Fig. 8 zurück. Block 840 und Subroutine 1400 werden in Abschnitt V noch genauer besprochen St
• Beziehen wir uns jetzt auf Fig. 15; Block 1502 fragt, ob es Beratungen zu bearbeiten gibt. Wenn ja, wird Subroutine 1700 in Fig. 17 aufgerufen. Block 1701 prüft, ob es Beratungen zu bearbeiten gibt. Wenn ja, aktualisiert Block 1770 die Konsole, um die Natur der eingehenden Beratung anzugeben. In Block 1790 kehrt die Subroutine zu Block 1503 der Fig. 15 zurück. Die Blöcke 1503 und 1800 der Fig. 15 werden später in Abschnitt V besprochen. Hier ist anzumerken, daß Subroutine 1700 auch von SSF 248 in einem SR ausgeführt wird, wenn der SR eine Konsole hat.
• Durch Anwendung der Beratungen und Diensteanforderung im Zusammenhang mit den in Problemprotokollen, Lösungsprotokollen und Kontaktdatenbanken auf verschiedenen Systemen im Dienstnetzwerk abgespeicherten Informationen ist ein wahrer Reichtum an Informationen zur Analyse und Überwachung verfügbar. Zwecks Veranschaulichung wollen wir annehmen daß unser Freund Pete von Pete's Catering seine Rezeptdatenbank durchsucht und sein bevorzugtes Leberkäsrezept nicht finden kann. Er benutzt das Flußdiagramm in Fig. 10, um ein anwendergemeldetes Problem zu isolieren und schreibt in Block 440 eine Diensteanforderung. Block 460 stellt fest, daß der SP, der das Berichtigen der Rezeptdatenbank unterstützt, der Software Fixit Shoppe ist, also wird die Diensteanforderung dorthin geschickt. Der Software Fixit Shoppe arbeitet das Flußdiagramm der Fig. 16 ab und findet die Lösung für das Problem in seinem Lösungsprotokoll -- das Leberkäsrezept selbst, eine Softwarekomponente. Er sendet die Lösungsinformation und das Leberkäsrezept an Pete's und aktualisiert sein Problemprotokoll. Pete erhält das Rezept und die Lösungsinformation und aktualisiert sein Problemprotokoll und die Lösungsprotokolle.
• Die Systemunterstützungsvorrichtung (System Support Facility - SSF) bei Pete's Catering hat die Fähigkeit, in ihrem Problemprotokoll enthaltene Informationen herauszuziehen, um dem Bediener den Status jedes Problems zu jedem beliebigen Zeitpunkt anzuzeigen. Beispielhafte Bildschirme, die sich dem Bediener bei Pete's zeigen, nachdem das Problem mit dem Leberkäsrezept beantwortet wurde, sind in den Fig. 20A und 20B dargestellt. Die Fig. 20C und 20D zeigen die Musterbildschirme, die sich dem Bediener im Software Fixit Shoppe darstellen und die den Status des gleichen Problems zeigen.
• Als Alternative könnte beim Software Fixit Shoppe auch eine Konsole benutzt werden, um den Status des gesamten Dienstnetzwerks oder eines Teils desselben grafisch zu überwachen. Als Beispiel, wie eine Konsole im Software Fixit Shoppe aussehen könnte, nachdem eine Diensteanforderung von Pete's Catering eingegangen ist, wird in Fig. 21 gezeigt. Jeder SR und SP im Netzwerk, den der Bediener zu sehen wünscht, wird auf dem Bildschirm dargestellt. Vorzugsweise werden die verschiedenen Systeme im Netzwerk als Ikone dargestellt mit veränderlichem Aussehen der Ikone, die die verschiedenen Rechnersysteme darstellen, je nach Status dieses Rechnersystems im Netzwerk. Fig. 21 zeigt eine durchgezogene Linie zu Pete's Catering, das durch einen Kasten in gestrichelter Darstellung dargestellt wird. Diese Darstellung symbolisiert, daß eine Diensteanforderung von Pete's eingegangen ist, die aber noch nicht beantwortet wurde. Joe's Deli und Lefty's Scissors werden dargestellt, verbunden durch ausgezogene Linien zu ausgezogenen Kasten. Das zeigt an, daß Joe's und Lefty's Rechnersysteme auf Stand sind und normal laufen. Willie's Wigets ist durch eine ausgezogene Linie verbunden, besteht jedoch aus einem Kasten aus Punkten.
• Die Konsole im Software Fixit Shoppe zeigt auch, daß einer der SPs, Sam Spreadsheets, durch einen Kasten aus Sternen dargestellt ist. Das zeigt an, daß eben eine Beratung von Sam's her eingegangen ist. Der Bediener kann eine Funktionstaste drücken, um zusätzliche Informationen über diese Beratung sichtbar zu machen.
• Die Auswahl der Darstellungen des Systemstatus in einer Konsole ist eine Frage des Designs, die der Designer oder sogar der Bediener wählen kann. Wenn die Konsole Farbe und verschiedene Attribute unterstützt, können die Ikonen ihre Farbe wechseln, blinken, heller oder dunkler werden oder sonstige Änderungen zeigen, um eine Veränderung des Status anzuzeigen. Zum Beispiel könnte ein rot blinkendes Ikon anzeigen, daß eine Diensteanforderung eingegangen ist, jedoch noch nicht beantwortet wurde.
V. Problemverhütung in einem Dienstnetzwerk
• A. Auf Veranlassung des Diensteanforderers
• Wie bereits besprochen kann ein SR eine Problemverhütung von sich aus durchführen, indem er alle bekannten Abhilfemaßnahmen für Probleme mit einer Liste unterstützter Komponenten abruft. Wie Fig. 8 zeigt, fragt Block 840, ob Abhilfemaßnahmen für unterstützte Programme angefordert werden. Wenn ja, wird Subroutine 1400 der Fig. 14 aufgerufen. Block 1401 definiert den Typ der gewünschten Problemverhütungsanforderung. Problemverhütung kann durchgeführt werden zum Zeitpunkt der Aufnahme, wo der SR alle Abhilfemaßnahmen für alle Komponenten wünscht, deren Unterstützung der vom SP fordert. Die Problemverhütung kann auch periodisch für eine bestimmte Komponente durchgeführt werden. Zum Beispiel könnte Pete's Catering beschließen, daß sein Tabellenkalkulationsprogramm kontinuierlich mit allen Anderungen auf Stand gebracht wird. Daher wird am ersten jedes Monats von Pete's System automatisch eine Problemverhütungsanforderung für das Tabellenkalkulationsprogramm generiert. Eine Problemverhütung könnte auch auf Anforderung durch einen Bediener an einen SR für eine oder mehrerer ausgewählte Komponenten angefordert werden. Die zur Bestimmung des gewünschten Problemverhütungstyps erforderliche Information wird in der Unterstützungsdatenbank 203 abgespeichert.
• Beziehen wir uns wieder auf Fig. 14; hier fragt Block 1410, ob es eine Komponente gibt, die eine Problemverhütung anfordert. Wenn ja, holt der Block 1414 die Kundeninformation aus der Kontaktdatenbank, und Block 1420 schreibt die in Fig. 3B2 gezeigte Diensteanforderung. Die Diensteanforderung der Fig. 3B2 enthält Felder, die angeben, daß diese Diensteanforderung eine Problemverhütungsanforderung für eine bestimmte Komponenten-ID ist. Diese Felder ersetzen die Symptomenkette und die FRU-Listen-Felder, die einer generierten Diensteanforderung zugeordnet sind, wenn es ein bekanntes Problem gibt wie in Fig. 3B1 gezeigt wird. Block 1450 fragt, ob die Diensteanforderung jetzt gesendet werden soll. Wenn ja, bestimmt Block 1460 durch Prüfen der Unterstützungsdatenbank, welcher/welche SP(s) die der Diensteanforderung zugeordnete Komponente unterstützt/unterstützen, und sendet die Diensteanforderung zu dem betreffenden SP. In jedem Fall kehrt der Steuerungsfluß zu Block 1410 zurück. Wenn Block 1410 bestimmt, daß alle Anforderungen für die Problemverhütung erfüllt sind, kehrt die Subroutine in Block 1490 zu Block 890 in Fig. 8 zurück.
• Die Diensteanforderung wird vom SP aufgenommen und durch Abarbeiten des Flußdiagramms der Fig. 16 ausgeführt, wie bereits diskutiert wurde.
• B. Auf Veranlassung des Diensteanbieters
• Auch ein Diensteanbieter kann Problemverhütung für Diensteanforderer durchführen, die er unterstützt. Der SP prüft, ob er irgend eine Lösung für Probleme parat hat, die bei einem oder mehreren von ihm unterstützen SRs aufgetreten sind, die aber noch nicht gemeldet oder entdeckt wurden. Das wird in Fig. 15 dargestellt. Block 1503 in Fig. 15 fragt den SP, ob er Problemverhütung durchführen will. Wenn ja, wird die Subroutine 1800 in Fig. 18 aufgerufen. Block 1802 durchsucht die Berechtigungsdatenbank 270, für welche Komponenten ein SR berechtigt ist, Behebungsmaßnahmen zu erhalten. Block 1805 durchsucht das Lösungsprotokoll auf alle Behebungen, die Informationen in dem betreffenden Feld haben, nach denen diese Lösung als Anwort auf eine Problemverhütungsanfoderung eines SP verfügbar ist. Es mag erwünscht sein, die Problemverhütung auf nur solche Behebungen zu beschränken, die vom SR als 'Problem behoben' bezeichnet werden (die somit den Status "VERIFIED" haben), um das unnötige Senden von Behebungsmaßnahmen zu vermeiden, die nicht funktioniert haben.
• Block 1807 verlangt, daß der SR laufend eine Kopie seines Lösungsprotokolls an den SP schickt. Obwohl das Lösungsprotokoll des SP Daten von SR enthält, die er kennt, ist es möglich, daß das Lösungsprotokoll des SP die neuesten auf Stand gebrachten Informationsdaten nicht kennt. Das kann vorkommen, wenn der SR Lösungsinformationen von einem anderen SP erhalten hat oder der SR eine Komponente aus einer anderen Quelle erhalten hat, die nicht im Netzwerk ist.
• Block 1810 vergleicht das vom SR geschickte Lösungsprotokoll mit seinem eigenen Lösungsprotokoll, um vom SR nicht erfaßte oder nicht gemeldete (nicht im SR Lösungsprotokoll aufgeführte) Lösungen zu finden. Block 1820 stellt fest, ob es ein nicht gemeldetes Problem zu beheben gibt;
• Wenn ja, ordert Block 1850 den/die Hardware-Teil(e), sendet die Sof twarekomponente (n), Mikrocodekomponente (n) und/oder Textanweisungen an den SR. Block 1860 sendet die Lösungsinformation an den SR. Block 1870 aktualisiert das Lösungsprotokoll, das Problemprotokoll und die Konsole beim SP, und kehrt zu Block 1820 zurück, um nach weiteren durchzuführenden Problemverhütungen zu suchen. Wenn Block 1820 negativ beantwortet wird, kehrt die Subroutine in Block 1890 zu Block 1590 in Fig. 15 zurück. Wenn der SR die Lösungsinformation erhält, führt er das Flußdiagramm in Fig. 19 durch, wie bereits besprochen.
• RO 990 0378

Claims (4)

1. Ein Verfahren zur automatischen Analyse und Behebung von Störungen in einem ersten Rechnersystem (130, 110) innerhalb eines Dienstenetzwerks, wobei das genannte erste Rechnersystem an ein zweites Rechnersystem (130, 150) angeschlossen ist, und wobei das genannte zweite Rechnersystem an ein drittes Rechnersystem (130, 150) angeschlossen ist und wobei das genannte Verfahren die folgenden Schritte umfaßt:

- Empfang einer Diensteanforderung vom genannten ersten Rechnersystem, wobei die genannte Diensteanforderung Informationen über eine Störung enthält, die in einer Komponente des genannten ersten Rechnersystems aufgetreten ist;

- Suche in einer Berechtigungsdatenbank (270) nach einer Berechtigungsanzeige, die angibt, daß das erste Rechnersystem zu einem Dienst für die genannte Komponente berechtigt ist;

- Suche innerhalb der genannten Berechtigungsdatenbank nach der genannten Berechtigungsanzeige, die angibt, daß das genannte erste Rechnersystem zu einem Dienst für die genannte Komponente berechtigt ist;

- Suche innerhalb eines Lösungsprotokolls (202) nach Vergleichsinformationen, die mit einer Untergruppe von Daten übereinstimmen, die in der genannten Diensteanforderung enthalten sind;

- Sicherstellung, daß das genannte Lösungsprotokoll nicht die genannten Vergleichsinformationen enthält;

-Suche innerhalb einer ersten Unterstützungsdatenbank (203) nach einer Unterstützungsanzeige, die angibt, daß das genannte dritte Rechnersystem die Behebung der genannten Störung in der genannten Komponente unterstützt;

Feststellung in der genannten Unterstützungsanzeige, ob das genannte dritte Rechnersystem die Behebung der genannten Störung in der genannten Komponente unterstützt; und

-Weiterleitung der genannten Diensteanforderung an das genannte dritte Rechnersystem.

2. Das Verfahren gemäß Anspruch 1, das weiterhin den Schritt der Bestellung einer Hardware-Komponente für das genannte erste Rechnersystem zum Zweck der Behebung der genannten Störung umfaßt.

3. Das Verfahren gemäß Anspruch 1, das weiterhin den Schritt der Übertragung einer Software-Komponente an das genannte erste Rechnersystem zum Zweck der Behebung der genannten Störung umfaßt.

4. Das Verfahren gemäß jedem der vorhergehenden Ansprüche, wobei das genannte erste Rechnersystem ein Diensteanforderer (110) und das genannte zweite Rechnersystem ein Diensteanbieter/-anforderer (130) ist, der an einen Diensteanbieter (150) angeschlossen ist.