DE68924226T2

DE68924226T2 - Dienstwarnsignalfunktion für Eingangs-/Ausgangsgerät.

Info

Publication number: DE68924226T2
Application number: DE68924226T
Authority: DE
Inventors: Jerry Lee Coale
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1988-08-31
Filing date: 1989-07-24
Publication date: 1996-05-02
Anticipated expiration: 2009-07-25
Also published as: EP0357573B1; EP0357573A3; BR8904416A; US4922491A; DE68924226D1; EP0357573A2; JPH02105947A

Description

Die vorliegende Erfindung bezieht sich auf die automatische Geräteanalyse und im einzelnen auf die Dienstunterstützungsanforderungen von Computereingangs-/-ausgangsgeräten (E/A-Geräte) mit eingebauter Fehlererkennung und Fehlerkorrektur.
In "Predictive Support: Anticipating Computer Hardware Failures", Hewlett-Packard Journal, Band 37, Nr. 11, 1986, wird auf den Seiten 30-33 ein System beschrieben, das in regelmäßigen Abständen die Häufigkeit von weichen Fehlern in den verschiedenen Systemkomponenten prüft. Wenn diese Fehler so häufig auftreten, daß hierdurch die Verfügbarkeitszeit bedroht werden könnte, benachrichtigt das Predictive Support- System automatisch die entsprechende Person, damit Korrekturmaßnahmen getroffen werden können.
Die vorliegende Erfindung wird in Zusammenhang mit einem Plattenspeicher-Subsystem zur Datenspeicherung in einem Rechner beschrieben. Ein solches Speichergerat kann als Direktzugriffsspeicher (DAS)-Subsystem bezeichnet werden. Trotzdem werden die Fachleute erkennen, daß die beschriebene Erfindung auch in andere Rechner-Geräte eingebaut werden kann, insbesondere in verschiedene E/A-Geräte mit eingebauter Fehlererkennung und Fehlerkorrektur.
Das Vorkommen eines korrigierten Fehlerereignisses in einem E/A-Gerät kann anzeigen, daß eine Dienstmaßnahme zur Wiederherstellung des normalen Betriebs erforderlich ist oder nicht. Wenn die Leistung des E/A-Geräts durch einen Fehler dauernd beeinträchtigt ist, oder wenn Fehler so häufig auftreten, daß sie die Leistung des E/A-Geräts merklich versclilechtern, sollte eine Dienstmaßnahme eingeplant werden.
Wenn jedoch die Leistung des E/A-Geräts nicht wesentlich beeinträchtigt ist, wird eine Dienstmaßnahme normalerweise nicht empfohlen.
Die Entscheidung, ob eine Dienstmaßnahme erforderlich ist, oder nicht, erfolgt typischerweise in einem manuellen empirischen Verfahren. Ausführliche Fehlersymptomberichte werden aufgerufen und geprüft, um den Schweregrad und die Dauer des Problems im Hinblick auf eine Beeinflussung der Gerätefunktion zu bestimmen. Aufgrund dieses komplizierten Prozesses beruht die Entscheidung, eine Dienstmaßnahme anzufordern, oft auf einer nur unzureichenden Kenntnis des wirklichen Problems. Eine falsche Entscheidung kann Kosten verursachen, entweder durch einen Leistungsverlust oder wenn Teile ausgewechselt werden, die eigentlich fehlerfrei sind.
Die Entscheidung, ob eine Dienstmaßnahme erforderlich ist, um die Ursache für einen möglicherweise nur sehr sporadisch auftretenden oder anwendungsmustersensitiven Fehler einzugrenzen, erfolgt im typischen Fall auch über eine manuelle und empirische Auswertung. Nach dem heutigen Stand der Technik erfolgt die Eingrenzung eines Fehlers durch Wartungsdiagnoseprogramme, in denen ein Fehlersymptom erneut erzeugt wird. Diese Technik ist jedoch für intermittierende Fehlersymptome ineffizient. Eine Alternative ist die manuelle Analyse einer Fehlersymptom-Vorgeschichte zur Ableitung eines Fehlersyndroms, das mit einer hinreichenden Dienstmaßnahme gleichgesetzt werden kann. Die Dienstmaßnahme besteht dann darin, systematisch verdächtige Teile auszuwechseln, bis keine Fehler mehr auftreten, was ein Zeichen dafür ist, daß die normale Funktion wiederhergestellt ist.
FIG. 1 zeigt ein Eingangs-/Ausgangsgerät (E/A-Gerät) 11 nach dem Stand der Technik mit seinem Fehlerantwortmechanismus 13. Das E/A-Gerät empfängt einen Befehl für eine E/A-Operation, Daten zu lesen oder zu schreiben. Wenn das E/A-Gerät die Operation erfolgreich ausführt, kann es zurückmelden, daß die Operation fehlerfrei ausgeführt wurde (Antwort (1)). Wenn jedoch ein Fehler erkannt wird, führt das E/A-Gerät seine Fehlersymptomanalyse und sein Fehlerkorrekturverfahren durch, der Fehler wird entweder erfolgreich korrigiert oder nicht. Wenn die Operation erfolgreich korrigiert ist, kann eine Befehlsantwort zurückgemeldet werden, daß die Operation ausgeführt wurde, gleichzeitig wird jedoch gemeldet, daß ein Fehlersymptom korrigiert wurde (Antwort (2)). Wenn die Operation nicht korrigiert wird, gibt das E/A-Gerät eine Befehlsantwort aus, die besagt, daß die Operation nicht ausgeführt wurde; gleichzeitig erfolgt ein Schadensbericht und ein Bericht über das nicht korrigierte Fehlersymptom (Antwort (3)).
Wenn das E/A-Gerät die erfolgreiche und fehlerfreie Ausführung der Operation meldet, gibt dieser Zustand den normalen Betriebsablauf des Geräts wieder. Eine Meldung, daß die Operation ausgeführt wurde, bei gleichzeitiger Meldung eines korrigierten Fehlersymptoms, gibt an, daß die Operationen des E/A-Geräts fortgesetzt werden können, daß jedoch die Fehlersymptomdaten geprüft werden sollten, um festzustellen, ob eine Dienstmaßnahme erforderlich ist. Eine Meldung, daß die Operation nicht ausgeführt wurde, mit einem Schadensbericht und dem nicht korrigierten Fehlersymptom, erfordert eine sofortige Maßnahme zur Wiederherstellung der normalen Funktion des E/A-Geräts. Aufgrund der beiden Fehlersymptom-Meldungen kann eine Dienstmaßnahme erforderlich werden oder nicht. Ob eine Dienstmaßnahme erforderlich ist, muß immer außerhalb des E/A-Geräts durch manuelle Analyse der Fehlersymptomdaten festgestellt werden.
In einem DAS-Subsystem eines Rechnersystems werden zum Beispiel, wenn der Benutzer Schreib- und Leseoperationen ausführt und Daten in das Subsystem und aus dem Subsystem überträgt, vom Plattenspeicher regelmäßig und in der bekannten Weise Datenprüfmeldungen oder Geräteprüfmeldungen erzeugt, aus denen hervorgeht, daß neben den Routineereignissen noch andere Ereignisse stattgefunden haben. Datenprüfungen sind in vielen Plattenspeichern Ereignisse, mit denen gewissermaßen gerechnet wird; sie werden demnach beim üblichen bookkeeping des DAS-Subsystems gezählt und aufgezeichnet und deuten nicht notwendigerweise darauf hin, daß eine Dienstmaßnahme erforderlich ist.
Außerdem werden auf das DAS-Subsystem bezogene Nutzungsdaten gesammelt. Diese Daten können zum Beispiel Aussagen darüber enthalten, welche E/A-Geräte genutzt werden, sowie Hinweise auf Suchzählungen und Datenübertragungsberichte. Diese Daten werden manchmal als Nutzungsinformationen bezeichnet.
Normalerweise wird ein Bericht in regelmäßigen Abständen erstellt (beispielsweise täglich oder wöchentlich); in ihm sind alle korrigierten Ausnahmen oder andere mögliche Fehlerereignisse, die seit dem letzten Bericht stattgefunden haben, aufgezeichnet. Dieser Bericht wird von einer Person analysiert, um festzustellen, ob die aufgezeichneten Ereignisse auf ein Problem mit dem E/A-Gerät hindeuten, ob Korrektivmaßnahmen erforderlich sind und wie diese aussehen könnten. Trotzdem inuß bei den heutigen Systemen diese Analyse ausschließlich anhand gedruckter Berichte durchgeführt werden, um Ausnahmeereignisse herauszufinden und Trendfehler zu erkennen.
Die vorliegende Erfindung stellt ein Verfahren zur automatischen Erkennung und Analyse von Ausnahmeereignissen bereit, die in einem peripheren Rechner-Subsystem auftreten, das an ein Host-Rechnersystem angeschlossen ist, wobei das Verfahren durch die folgenden Schritte gekennzeichnet ist: Führen einer Subsystemumgebungs-Datenbank, die Daten über die aktuelle Konfiguration des genannten peripheren Rechner-Subsystems sowie Nutzungs- und Fehlerdaten enthält, die sich auf das genannte periphere Subsystem beziehen; bedingungsabhängiges Aufrufen einer Problembeschreibungsprozedur, wenn die Daten in der genannten Subsystemumgebungs-Datenbank auf ein Ausnahmeereignis hinweisen, das darauf hinweist, daß für das genannte periphere Subsystem eindeutig oder wahrscheinlich eine Dienstmaßnahme erforderlich ist, wobei die genannte Problembeschreibungsprozedur folgendes umfaßt: Entwicklung eines aktuellen Problemprofil-Datensatzes, in dem das genannte Ausnahmeereignis beschrieben wird; Erzeugen einer Betrachtung einer Problemprofil-Datenbank für das genannte Ausnahmeereignis aus gespeicherten Regeln; Abfragen einer Problemprofil- Datenbank, die die Problemprofil-Datensätze von bereits vorher aufgetretenen Ausnahmeereignissen enthält, um den genannten aktuellen Problemprofil-Datensatz mit einem Problemprofil-Datensatz zu vergleichen, der bereits in der genannten Problemprofil-Datenbank vorhanden ist; wenn der genannte aktuelle Problemprofil-Datensatz mit einem vorhandenen Problemprofil-Datensatz in der genannten Problemprofil-Datenbank übereinstimmt, und der genannte vorhandene Problemprofil-Datensatz angibt, daß für das betreffende Problem eine Dienstmaßnahme ansteht, Aktualisieren des genannten vorhandenen Problemprofil-Datensatzes; wenn der genannte aktuelle Problemprofil-Datensatz mit einem vorhandenen Problemprofil-Datensatz in der genannten Problemprofil-Datenbank übereinstimmt und der genannte vorhandene Problemprofil-Datensatz angibt, daß für das betreffende Problem keine Dienstmaßnahme ansteht, Aktualisieren des genannten vorhandenen Problemprofil-Datensatzes und Aufrufen einer Problemauswertungsprozedur; wenn der genannte aktuelle Problemprofil-Datensatz nicht mit einem vorhandenen Problemprofil-Datensatz in der genannten Problemprofil-Datenbank übereinstimmt, Hinzufügen des genannten Problemprofil-Datensatzes zu der genannten Problemprofil-Datenbank und Aufrufen einer Problemauswertungsprozedur; wobei die genannte Problemauswertungsprozedur folgende Schritte umfaßt: Prüfen des genannten aktuellen Problemprofil-Datensatzes hinsichtlich gespeicherter Regeln, die sich auf eine akzeptable Subsystemleistung beziehen; und, wenn die Funktionen des genannten peripheren Subsystems unterbrochen wurden oder sich die Leistung des Subsystems über eine akzeptable Grenze hinaus verschlechtert hat, Erzeugen einer Dienstwarnmeldung und Einfügen der genannten Dienstwarnmeldung in den genannten Problemprofil-Datensatz, Aktualisieren des genannten vorhandenen Problemprofil-Datensatzes in der genannten Problemprofil-Datenbank und Übertragen der genannten Dienstwarnmeldung zum genannten Host-System.
Die vorliegende Erfindung stellt außerdem ein System zur automatischen Erkennung und Analyse von Ausnahmeereignissen bereit, die in dem peripheren Subsystem eines Rechners auftreten, gemäß Definition in Anspruch 6.
Die Ausführungsbeispiele der vorliegenden Erfindung machen ein externes manuelles Verfahren, in dem festgestellt wird, ob Dienstmaßnahmen erforderlich sind, überflüssig. Das externe manuelle Verfahren wird durch eine in das E/A-Gerät eingebaute Dienstwarnfunktion ersetzt. Die Dienstwarnfunktion arbeitet gleichlaufend mit anderen E/A-Gerätefunktionen. Die interne Dienstwarnfunktion der Erfindung überwacht die E/A- Operationen der Geräte und registriert Ausnahmeereignis-Datensätze zur Erkennung eines Fehlersyndroms, das eine Dienstmaßnahme erfordert, zur Bestimmung, ob Dienstmaßnahmen erforderlich sind und zur Einleitung einer Dienstmaßnahme über eine asynchrone Dienstwarnmeldung an das E/A-Gerät.
Ein Ausführungsbeispiel der vorliegenden Erfindung stellt ein Verfahren zur automatischen Erkennung und Analyse von Ausnahme- oder Fehlerereignissen bereit, die im periphären Subsystem eines Rechners auftreten, das an ein Host-Rechnersystem angeschlossen ist. Das Verfahren der Erfindung beinhaltet das Führen einer Subsystemumgebungs-Datenbank, welche Informationen enthält, die sich auf die aktuelle Konfiguration des periphären Rechner-Subsystems beziehen, und Nutzungs- und Fehlerinformationen, die sich auf das Peripherie-Subsystem beziehen.
Eine Problembeschreibungsprozedur wird bedingungsabhängig aufgerufen, wenn die Daten in der Subsystemumgebungs-Datenbank auf ein Ausnahmeereignis hinweisen, das entweder eine eindeutige oder eine wahrscheinliche Notwendigkeit für eine Dienstmaßnahme in dem peripheren Subsystem anzeigt. Die Problembeschreibungsprozedur umfaßt die Erzeugung einer Betrachtung der Subsystemumgebungs-Datenbank aus gespeicherten Regeln, bezogen auf das Ausnahmeereignis, und die Entwicklung eines aktuellen Problemprofil-Datensatzes, der das Ausnahmeereignis beschreibt.
Eine Problemprofil-Datenbank mit den Problemprofil-Datensätzen von zuvor aufgetretenen Ausnahmereignissen wird abgefragt, um den aktuellen Problemprofil-Datensatz mit einem bereits in der Problemprofil-Datenbank vorhandenen Problemprofil-Datensatz zu vergleichen. Wenn der aktuelle Problemprofil-Datensatz mit einem vorhandenen Problemprofil-Datensatz in der Problemprofil-Datenbank übereinstimmt, und der bereits vorhandene Problemprofil-Datensatz anzeigt, daß für das betreffende Problem bereits eine Dienstmaßnahme ansteht, wird der vorhandene Problemprofil-Datensatz aktualisiert. Wenn der aktuelle Problemprofil-Datensatz mit einem vorhandenen Problemprofil-Datensatz in der Problemprofil-Datenbank übereinstimmt, und der vorhandene Problemprofil-Datensatz anzeigt, daß für das betreffende Problem keine Dienstmaßnahme ansteht, wird der vorhandene Problemprofil-Datensatz aktualisiert und eine Problemauswertungsprozedur aufgerufen. Wenn der aktuelle Problemprofil-Datensatz nicht mit einem bereits vorhandenen Problemprofil-Datensatz in der Problemprofil-Datenbank übereinstimmt, wird der aktuelle Problemprofil-Datensatz der Problemprofil-Datenbank hinzugefügt.
In der Problemauswertungsprozedur wird der aktuelle Problemprofil-Datensatz hinsichtlich der gespeicherten Regeln, die sich auf eine akzeptable Subsystem-Leistung beziehen, geprüft. Wenn die Funktionen des peripheren Subsystems unterbrochen wurden, oder wenn die Grenzen im Hinblick auf eine akzeptable Subsystem-Leistung überschritten wurden, wird eine Dienstwarnmeldung erzeugt. Die Dienstwarnmeldung wird in den Problemprofil-Datensatz in der Problemprofil-Datenbank eingefügt. Der vorhandene Problemprofil-Datensatz in der Problemprofil-Datenbank wird aktualisiert und die Dienstwarnmeldung wird an das Host-System übertragen.
Im folgenden findet sich eine ausführliche Beschreibung eines bevorzugten Ausführungsbeispiels der vorliegenden Erfindung unter Bezugnahme auf die Zeichnungen; es zeigt
FIG. 1 ein Blockdiagramm eines E/A-Geräts mit einem Fehlerkorrekturmechanismus, in dem die verschiedenen Arten von Statusmeldungen erläutert werden, die auf einen Befehl für eine E/A-Operation ausgegeben werden können,
FIG. 2 ein Blockdiagramm eines E/A-Geräts mit der Dienstwarnfunktion der Erfindung,
FIG. 3 ein Konzept-Diagramm der Erstellung der Subsystemumgebungs-Datenbank und der Anwendung der Problemerkennungsprozedur,
FIG. 4 ein Blockdiagramm, welches das Anwendungskonzept der Problembeschreibungsprozedur erläutert, und
FIG. 5 ein Konzept-Blockdiagramm, welches das Anwendungskonzept der Problemauswertungsprozedur erläutert.
Wie in FIG. 2 erläutert wird, umfaßt das periphäre Subsystem eines Rechners 21 ein oder mehrere Eingangs-/Ausgangsgeräte (E/A-Geräte) 23, die Operationsbefehle und Daten vom Host- Rechnersystem empfangen. Im typischen Fall sind das maximal 64 Geräte pro Subsystem. Das Subsystem umfaßt außerdem einen Fehlererkennungs- und -korrekturmechanismus 25. Wie nach dem bisherigen Stand der Technik wird, wenn die Operation erfolgreich ausgeführt ist, eine Antwort erzeugt, daß die Operation fehlerfrei ausgeführt wurde (Antwort (1)). Wird jedoch ein Fehler erkannt, wird der interne Fehlererkennnungs-, -bestimmungs- und -korrekturmechanismus 25 des E/A-Geräts aufgerufen. Der Fehlererkennungs-, -bestimmungs- und -korrekturmechanismus 25 ist ein Mechanismus, der typischerweise für alle Geräte des Subsystems gemeinsam arbeitet. Wenn der Fehler erfolgreich korrigiert ist, wird eine Meldung "Operation ausgeführt" ausgegeben, jedoch ohne die Meldung "korrigiertes Fehlersymptom" (Antwort (2)). Für das Host-Rechnersystem stellen also die Antworten (1) und (2) die gleiche Meldung dar. Ein Unterschied wird lediglich als ein Unterschied in der Befehlsantwortzeit gesehen. Wenn eine Operation nicht abgeschlossen ist, weil ein Fehler nicht erfolgreich korrigiert wurde, wird von dem E/A-Gerät eine Meldung ausgegeben, die eine unvollständig ausgeführte Operation anzeigt, sowie ein Schadensbericht (Antwort (3)). In den beiden Fällen, in denen ein Fehler erkannt wird, werden die Fehlersymptom-Daten nur intern von der Dienstwarnfunktion 27 des E/A-Geräts genutzt. Die Dienstwarnfunktion erzeugt bedingungsabhängig eine asynchrone Dienstwarnmeldung, die alle Dienstmaßnahmeanforderungen enthält, die zur Wiederaufnahme des normalen Betriebs des E/A-Geräts notwendig sind. Ein Subsystemspeicher 29 speichert Daten, welche die physische Konfiguration des Subsystems, ein Subsystem-Nutzungsprotokoll, ein Ausnahmeereignis-Protokoll, Fehlerkriterien, Problemprozeduren und eine Problemprofil (Datensatz)-Datenbank darstellen. Die physische Konfiguration des Subsystems, das Subsystem-Nutzungsprotokoll und das Ausnahmeereignis-Protokoll bilden zusammen eine Subsystemumgebungs-Datenbank.

Erzeugungsprozeß für die Dienstwarnmeldung

Die Dienstwarnfunktion 27 ist eine Programmierte Einrichtung, die mit den E/A-Geräten im Subsystem eine Schnittstelle bildet und detaillierte Eingangsdaten vom Subsystem empfängt. Der Erzeugungsprozeß für die Dienstwarnmeldung wird von der Dienstwarnfunktion 27 ausgeführt und ist in drei Hauptprozeduren aufgeteilt:
1. Die Problemerkennung ist ein "systemresidentes" Subsystemprogramm, das eine Subsystemumgebungs-Datenbank verwaltet, und zwar so, daß die Datenbank immer die aktuellen Konfigurations-, Nutzungs- und Fehlerumgebungen für das Subsystem des Direktzugriffspeichers (DAS) beschreibt. Eine Problembeschreibungsprozedur wird bedingungsabhängig immer dann aufgerufen, wenn die Subsystemumgebung auf eine eindeutige oder eine wahrscheinliche Notwendigkeit für eine Subsystem-Dienstmaßnahme hinweist.
2. Die Problembeschreibungsprozedur ERZEUGT eine BETRACHTUNG der Subsystemumgebungs-Datenbank, wobei diese Betrachtung für die aktuelle Ausnahmegrenze innerhalb des Subsystems relevant ist. Die Daten aus der Betrachtung der Ausnahmegrenze werden zur Entwicklung eines Problemprofils herangezogen, welches den aktuellen Problemstatus für das Subsystem effizient beschreibt. Diese Profildaten werden entweder in die Problemprofil-Datenbank als Datensatz "neues Problem" EINGEFÜGT, oder sie werden zur AKTUALI- SIERUNG eines anderen Datensatzes verwendet, der eine bereits früher stattgefundene Erkennung derselben Problemsituation beschreibt. Eine Problemauswertungsprozedur wird immer dann aufgerufen, wenn es sich bei dem Problemstatus um einen "neuen" oder "regelmäßig wiederkehrenden" Problemstatus handelt. Die Problemauswertungsprozedur wird nicht aufgerufen, wenn das erkannte Problem dem Host-System bereits mitgeteilt wurde und wenn eine Dienstmaßnahme bereits ansteht.
3. Die Problemauswertungsprozedur bestimmt zunächst Art und Schweregrad des Fehlers sowie die Dienstanforderungen für einen Problemprofil-Datensatz. Diese Information wird mit dem Problemprofil-Datensatz in der Datenbank VERBUNDEN. WENN in der Problemauswertung festgestellt wird, daß Systemoperationen unterbrochen wurden ODER bestimmte Grenzen im Hinblick auf eine akzeptable Subsystem-Leistung überschritten wurden, DANN wird die Dienstwarnmeldung "Daten erfassen" erzeugt, mit dem Problemprofil-Datensatz VERBUNDEN und auch einem Host-System mitgeteilt, so daß eine Dienstmaßnahme eingeleitet werden kann.

Problemerkennungsprozedur

Die Problemerkennungsprozedur überwacht die Aktivität des DAS-Subsystems im Hinblick auf Veränderungen in der Subsystem-Konfiguration, zum Beispiel durch die Installation/den Ausbau einer Einheit, durch Datenformatmodus-Anderungen, durch Installation von technischen Veränderungen sowie Fehler aufgrund von Betriebsmittelreservierung/-schonung; außerdem die Such-/Lese-/Schreibnutzung von Subsystem-Steuerpfaden und -geräten und die Subsystem-Ausnahmeaktivitäten, die durch Fehlerbedingungen verursacht werden, die während der Abarbeitung von System-Tasks erkannt und abgewickelt werden. Die überwachten Daten werden in einer Subsystemumgebungs-Datenbank festgehalten, die immer die aktuelle Subsystem-Konfiguration, die aktuelle Nutzung und den aktuellen Fehlerstatus für das DAS-Subsystem beschreibt.
Die Problemerkennungsprozedur wird in der Pseudo-Code-Sequenz in Anhang 1 ausführlicher beschrieben. Der Problemerkennungsmechanismus ist schematisch in FIG. 3 dargestellt.
Im Normalbetrieb (fehlerfreien Betrieb), führt die Problemerkennungsstufe das "Housekeeping" aus, um die normale Beschreibung (Modellbeschreibung) der Subsystemumgebung zu pflegen.
Die aktuellen Nutzungsdaten werden von dem Plattenspeicher- Subsystem als Eingangsprotokolldatensatz empfangen. Die aktuelle Zeit wird auf den Eingangsprotokolldatensatz angewendet, um die Daten mit einer Zeitmarkierung zu versehen. Mit dem Eingangsprotokolldatensatz werden außerdem ausgewählte Vorgeschichtsdaten aus der Subsystemumgebungs-Datenbank verbunden. Die miteinander verbundenen Informationen werden in den Abschnitt 43 für aktuelle Ereignisse und Trends der Subsystemumgebungs-Datenbank 29 (a) (b) (c) eingelesen.
In dem Subsystem-Nutzungsprotokoll oder der Datenbank (die ein Teil der Subsystemumgebungs-Datenbank ist) werden also Daten darüber gespeichert, welche Geräte genutzt werden, welche Geräte stärker genutzt werden als andere, welche durchgängig auf einem bestimmten Level genutzt werden, bei welchen Geräten zwischenzeitlich Perioden mit sehr intensiver Nutzung auftreten, sowie andere Informationen, die sich auf die Verteilung und den Umfang der Nutzung der Geräte im System beziehen. Diese Informationen sind für die Bestimmung des Fehler- beziehungsweise Ausnahmetyps der vom Subsystem möglicherweise gemeldeten Fehler wichtig. In einem bestimmten Abschnitt der Datenbank werden Muster der aktuellen Nutzungshäufigkeit gespeichert.
Die gemeldeten Daten über aktuelle Zeit und aktuelle Nutzung (Eingangsprotokoll-Datensatz) werden in den Abschnitt 43 für aktuelle Ereignisse und Trends im Speicher der Subsystemnutzungs-Datenbank 29 (a) (b) (c) eingelesen. Auch das aktuelle Nutzungshäufigkeitsmuster wird Teil der Datenbank bzw. des Protokolls der Subsystemnutzung bzw. - vorgeschichte. Eine Vergleichsbetrachtung 47 wird auf die Subsystemumgebungs-Datenbank angewendet, um eine vergleichende Konfigurations- und Nutzungsvorgeschichte zu erhalten. Die neuen Nutzungsdaten werden also immer auf Trends oder Muster im Hinblick auf die physische Konfiguration des Subsystems und die bisherige Nutzungsvorgeschichte geprüft. Hierdurch entsteht ein ständig aktualisierter Datensatz über die Subsystemnutzung und die Trends und Muster der Subsystemnutzung.
Die Vergleichsbetrachtung 47 wird nach den Regeln 45 entwickelt, die in einem Regelspeicher gespeichert sind, der Teil der Problemprozeduren 29 (e) ist. Der Eingangsprotokoll- Datensatz wird auf die Regeln angewendet, um den Befehl für die Vergleichsbetrachtung zu erzeugen, der zur Erstellung der Vergleichsbetrachtung 47 der Vorgeschichtsdaten in der Subsystemumgebungs-Datenbank für die aktuelle Nutzung verwendet wird. Die Regelauswahl wird vom Nutzungstyp bestimmt (zum Beispiel Steuereinheit, Pfad, Gerätedaten oder Gerätezugriff) sowie von der physischen Adressengrenze. Die im Regelspeicher gespeicherten Regeln werden von Fachleuten bestimmt und eingegeben; sie legen fest, in welcher Weise die Nutzungsvorgeschichte in dem jeweils analysierten Gerät geprüft werden soll. Diese Information ist somit ausschließlich eine Funktion des geprüften Geräts und ist für die verschiedenen Geräte und Subsysteme unterschiedlich. Die Regeln können zum Beispiel festlegen, daß, wenn ein bestimmter Nutzungstyp vorkommt, ein bestimmter Teil der Nutzungsdatenbank als möglicherweise oder wahrscheinlich mit dieser Nutzung verbundener Teil aufgerufen wird.
Ein Eingangsprotokoll-Datensatz kann auch vom DAS-Subsystem geliefert werden, wenn die physische Subsystemkonfiguration geändert wird. Ein solcher Eingangsprotokoll-Datensatz dient der Aktualisierung der Subsystemumgebungs-Datenbank, so daß hierin die aktuelle Subsystemkonfiguration wiedergegeben wird.
Wenn in die Datenbank ein "unerwartetes" Ausnahmeereignis eingegeben wird, wird eine Entscheidung getroffen, die Problembeschreibungsprozedur entweder auf zurufen oder nicht aufzurufen.
FIG. 3 ist ebenfalls ein Konzept-Diagramm der Speicherung und der Analyse von Daten, die sich auf Ausnahmeereignisberichte oder Fehlerberichte beziehen, die aus verschiedenen Teilen des Speichersubsystems empfangen werden können, wie zum Beispiel vom Gerät, vom Kanal, oder von dem Pfad zwischen Kanal und Gerät. Ein Journal beziehungsweise eine Datenbank 29 (c) mit Ausnahmeereignissen und Trends wird entwickelt und im Fehlerereignisprotokoll-Speicher des E/A-Geräts gespeichert. Das Protokoll enthält einen Unterabschnitt 43 mit dem aktuellen Ausnahmeereignis und den Trenddaten.
Wenn ein neuer Ausnahmerereignisbericht (aktuelles Ausnahmeereignis oder aktueller Fehler) als Eingangsprotokoll-Datensatz eingeht, erhält er einen Zeitstempel und wird in dem Abschnitt oder der Datenbank für aktuelle Ausnahmeereignisse des Ausnahmeereignisprotokolls in der Subsystemumgebungs-Datenbank aufgezeichnet. Der Bericht über aktuelle Ausnahmeereignisse wird auch auf den Regelsatz 45 angewendet, der zuvor im Gerätespeicher als Teil der Problemprozeduren 29 (e) gespeichert wurde. Diese Regeln erzeugen einen Befehl, der eine Vergleichsbetrachtung 47 darstellt, die auf die Subsystemumgebungs-Datenbank im Hinblick auf den Eingangsprotokoll-Datensatz angewendet wird, der den zuletzt eingegangenen Ausnahmeereignisbericht enthält. Wenn die Subsystemumgebungs-Datenbank durch diese Vergleichsbetrachtung gelesen wird, erhält man Vorgeschichtsdaten über den Maschinenbereich, der jeweils von Interesse ist, was durch das aktuelle Ausnahmeereignis bestimmt wird. Hierdurch kann festgestellt werden, wie das neue Ausnahmeereignis beziehungsweise der Ausfall oder Fehler mit der zurückliegenden Vorgeschichte des Subsystems und mit der physischen Konfiguration des Subsystems in Verbindung stehen. Dies ist wichtig bei der Betrachtung und der Bestimmung von Mustern und Trends in den Fehlerberichten. Wenn man diese Vergleichsbetrachtung auf die Subsystemumgebungs-Datenbank anwendet, können mit dem aktuellen Ereignis verbundene Daten gefunden und auf das aktuelle Ausnahme- oder Fehlerereignis angewendet werden.
Auf die Regeln 45 zur Erzeugung der Vergleichsbetrachtung 47 der Subsystemumgebungs-Datenbank wird von dem Bericht über aktuelle Ausnahmeereignisse vorzugsweise in Form einer Rückwärtskette zugegriffen, so daß die Regeln nacheinander von dem Fehlerereignisbericht adressiert werden. Hierdurch wird, wie bekannt ist, die erste Regel, wenn sie angetroffen wird und ihre Bedingung erfüllt ist, zum Befehl der Vergleichsbetrachtung, wenn nicht, wird die nächste Regel geprüft und so weiter. Die Reihenfolge der Regeln für die Prüfung und die Regeln selbst sind wiederum eine Funktion des Geräts, in dem sich die Dienstwarnfunktion befindet; beides wird von Fachleuten erstellt, die mit den Fehler- und Ausnahmemerkmalen des jeweiligen E/A-Geräts bestens vertraut sind.
Die Daten über das aktuelle Fehlerereignis und den aktuellen Trend werden auf einen Regelsatz für das Analysewarnsignal 29 (d) angewendet; diese Regeln enthalten Fehlerkriterien. Der Ausgang der Regeln für das Analysewarnsignal steuert ein Gatter 49, durch das die aktuellen Ausnahmeereignis- und Trenddaten zur nächsten Stufe für die Problembeschreibung durchgeschaltet werden.
Die Entscheidung, die Problembeschreibungsprozedur aufzurufen, ist eindeutig, wenn der Ausnahmetyp auf einen "harten" Fehler hinweist. Der Systembetrieb ist unterbrochen und eine Dienstmaßnahme ist höchstwahrscheinlich notwendig. Wahrscheinlicher jedoch sind "weiche" Ausnahmetypen, die keine wesentliche Unterbrechung verursachen, jedoch aufgrund einer reparaturfähigen Fehlerbedingung auftreten können.
Bei "weichen" Ausnahmebedingungen wird die Entscheidung, die Problembeschreibungsprozedur aufzurufen, getroffen, wenn in dem EINFÜGE- und AKTUALISIERUNGS-Prozeß der Datenbank eine häufig wiederkehrende Sequenz von "weichen" Fehlerereignissen erkannt wird, die durch Symptom UND Quelle miteinander in Beziehung stehen. Das Ziel ist, nicht auf beliebige, sich nicht wiederholende Ausnahmeereignisse, die höchstwahrscheinlich von der externen Subsystemumgebung verursacht wurden, zu reagieren.
Die Fehlerkriterien 29 (d) können als ein rückwärts verketteter Satz von Regeln aufgebaut sein, mit denen die aktuellen Ereignisse und Trends betrachtet werden. Die Regeln sollten so beschaffen sein, daß bei Antreffen eines "harten" Fehlers (bei dem zur Wiederherstellung des ordentlichen Subsystembetriebs Korrektivmaßnahmen erforderlich sind) oder bei Erkennen einer Ausnahmebedingung "weich, Musterschwelle überschritten" ein Analysewarnsignal erzeugt wird und das Gatter 49 die aktuellen Ereignis- und Trenddaten an die Problembeschreibungsprozedur durchschaltet. Zur Erstellung eines Regelsatzes mit den entsprechenden Fehlerkriterien ist Fachwissen über das analysierte Subsystem erforderlich. Im allgemeinen wird die Kette nach Ausnahmepriorität geordnet, so daß das gravierendste erkannte Fehlersymptom zuerst abfeuert.
Die Regeln für das Analysewarnsignal müssen so aufgestellt werden, daß eine Analysewarnmeldung erzeugt wird, die die aktuellen Ausnahmeereignis- und Trenddaten weitergibt und so die Problembeschreibungsprozedur häufiger aufruft, als wenn es wirklich ein Problem gäbe, so daß die Daten weiter analysiert werden können, wenn irgendein Zweifel besteht.

Problembeschreibungsprozedur

Der Mechanismus zur Implementierung der Problembeschreibungsprozedur ist in FIG. 4 im Konzept erläutert. Die Problembeschreibungsprozdur wird in der Aufstellung der Pseudo-Codes in Anhang 2 beschrieben.
Wenn der aktuelle Fehlerereignis-Datensatz durch das Signal "Problembeschreibungsprozedur aufrufen" an die Problembeschreibungsprozedur weitergegeben wird, wird er auf einen Regelsatz 51 angewendet, der Teil der Problemprozeduren 29 (e) ist und eine Vergleichsbetrachtung 53 der Problemprofil-Datenbank 29 (f) von Ausnahmedatensätzen der Subsystemfehler erzeugt, für die eine Analyse im Gange ist und für die ein Dienst ansteht oder abgeschlossen ist. Diese Vergleichsbetrachtung gewährleistet, daß nur der Teil der Datenbank, der sich auf das aktuell betrachtete Ausnahmeereignis bezieht, verwendet wird, wenn die Auswahlregeln auf das aktuelle Ausnahmeereignis angewendet werden. Dies wiederum geschieht, um die bei der Auswahl erforderliche Rechenleistung zu reduzieren. Wie vorher, werden die Regeln 51 zur Erzeugung der Betrachtung 53 aufgrund von Expertenwissen erstellt, und zwar bezogen auf die Faktoren in Verbindung mit dem jeweiligen Subsystem und den Geräten, in denen die Dienstwarnfunktion enthalten ist, und bezüglich der verschiedenen Arten von Fehlerereignissen, die möglicherweise damit verglichen oder verbunden werden.
Der Auswahlprozessor 61 vergleicht den aktuellen Ausnahmedatensatz mit der Vergleichsbetrachtung der Problemprofil-Datenbank 29 (f), um eine Auswahl aus den folgenden Möglichkeiten zu treffen:
a) neuer Fehler;
b) Wiederholfehler;
c) Wiederholaufruf;
d) bekannter Fehler (Analyse im Gange); oder
e) bekannter Fehler (Dienstmaßnahme anstehend).
Wenn der aktuelle Ausnahmedatensatz einen neuen Fehler darstellt, wird ein Statusanzeiger oder ein Steuersignal auf der Leitung A plaziert. Die Prozedur "Problemprofil aufbauen/aktualisieren" wird dann aufgerufen und das Signal auf der Leitung A wird ein Befehl zur Analyse eines neuen Fehlers.
Wenn eine Verknüpfung zu einem vorhandenen Problemprofil-Datensatz gefunden wird, für den eine Analyse im Gange ist (der Fehler wurde dem Host-System noch nicht mitgeteilt), wird auf der Leitung B ein Steuersignal oder ein Statusanzeiger plaziert. Die Prozedur "Problemprofil aufbauen/aktualisieren" wird dann aufgerufen und das Signal auf der Leitung B wird ein Befehl zur Analyse eines bekannten Fehlers.
Wenn in dem Vergleich festgestellt wird, daß der aktuelle Ausnahmedatensatz einen Wiederholfehler oder einen Wiederholaufruf darstellt, bewirken die Auswahlregeln das Plazieren eines Steuersignals auf der Ausgangsleitung A. Ein Wiederholfehler ist ein Fehler, für den eine Dienstwarnmeldung zum Host-System gesendet wurde, eine Dienstmaßnahme jedoch noch nicht eingeleitet ist. Ein Wiederholaufruf ist ein Fehler, für den eine Dienstmaßnahme durchgeführt wurde, und der anzeigt, daß die Dienstmaßnahme nicht erfolgreich war. Obwohl ein Wiederholfehler oder ein Wiederholaufruf bedeuten, daß ein Datensatz des Fehlers in der Problemprofil-Datenbank vorhanden ist, sind diese Problemprofil-Daten eine alte Vorgeschichte, die von der Problemauswertungsprozedur aktuell nicht verwendet werden soll. Daher baut die Prozedur "Problemprofil aufbauen/aktualisieren" einen neuen Problemprofil-Datensatz auf, als ob die aktuelle Ausnahme ein neuer Fehler wäre. Die weitere Analyse erfolgt durch Aufrufen der Problemauswertungsprozedur.
Wenn der Vergleich eine Verknüpfung zwischen dem Datensatz des aktuellen Ausnahmeereignisses und einem Problemprofil-Datensatz findet, für den eine Dienstmaßnahme ansteht, zählt der Zähler für regelmäßig wiederkehrende Probleme in dem Problemprofil-Datensatz hoch und die Problembeschreibungsprozedur wird beendet. In diesem Fall wird die Problemauswertungsprozedur nicht aufgerufen.

Prozedur "Problemprofil aufbauen/aktualisieren"

Die Prozedur "Problemprofil aufbauen/aktualisieren" wird als eine Subroutine der Problembeschreibungsprozedur aufgerufen. Die Prozedur dient zum Aufbau eines Problemprofil-Datensatzes für die Problemprofil-Datenbank, wenn in der Datenbank kein Problemprofil-Datensatz gefunden wird, der mit dem aktuellen Ausnahmedatensatz übereinstimmt, und zur Aktualisierung des Problemprofil-Datensatzes, wenn ein Problemprofil-Datensatz in der Datenbank gefunden wird, der mit dem aktuellen Ausnahmedatensatz übereinstimmt.
Die Problemprofil-Datensätze in der Problemprofil-Datenbank 29 (f) haben vorzugsweise ein gemeinsames Datensatzformat. Unterschiedliche Bytes in dem Datensatz zeigen an, ob eine Analyse für den durch diesen Problemprofil-Datensatz dargestellten Fehler im Gange ist, oder ob eine Dienstmaßnahme ansteht, oder ob an das Host-System eine Dienstwarnmeldung übertragen wurde, oder ob eine Dienstmaßnahme abgeschlossen wurde, oder andere Informationen, die sich auf die Analyse und die Behandlung von Subsystemfehlern beziehen.
Die Prozedur "Problemprofil-Datensatz aufbauen" ist als das Element 71 (FIG. 4) dargestellt; sie wird in der Aufstellung der Pseudo-Codes im Anhang 3 ausführlicher beschrieben. Diese Prozedur baut einen Problemprofil-Datensatz in der Problemprofil-Datenbank 29 (f) auf oder aktualisiert diesen.
Der aktuelle Ausnahme- oder Problemprofil-Datensatz wird auf die Prozedur "Problemprofil-Datensatz aufbauen" angewendet. Wenn ein bekannter Fehler, für den eine Analyse im Gange ist, beteiligt ist, wird der aktualisierte Problemprofil-Datensatz von der Problemprofil-Datenbank (die nicht den aktuellen Ausnahmedatensatz enthält) auf die Prozedur "Problemprofil-Datensatz aufbauen" angewendet, so daß er mit dem aktuellen Problemprofil-Datensatz (Ausnahmedatensatz) aktualisiert werden kann. Das Steuersignal für einen bekannten Fehler (Analyse im Gange) bewirkt, daß ein Regelsatz 65 aufgerufen und eine Betrachtung 66 der Subsystemumgebungs-Datenbank 29 (a) (b) (c) erzeugt wird, die sich auf die aktuelle Ausnahme bezieht. Die betrachteten Daten werden der Prozedur 71, "Problemprofil aufbauen/aktualisieren", zusammen mit dem aktuellen Datensatz und dem vorhandenen Problemprofil-Datensatz von der Problemprofil-Datenbank 29 (f) bereitgestellt. Nachdem der Problemprofil-Datensatz aktualisiert ist, kehrt der Prozeß anschließend an den Punkt in der Problembeschreibungsprozedur zurück, an dem die Problemauswertungsprozedur (Profildatensatz, regelmäßig wiederkehrendes Problem) aufgerufen wird. Bezieht sich der aktuelle Ausnahmedatensatz auf einen neuen Fehler, wird mit der Prozedur "Problemprofil-Datensatz aufbauen", 71, ein Problemprofil-Datensatz aufgebaut. Das Steuersignal für einen neuen Fehler bewirkt, daß ein Satz von Regeln 63 aufgerufen wird, um eine Betrachtung 66 der Subsystemumgebungs-Datenbank 29 (a) (b) (c) für die aktuelle Ausnahme zu erzeugen. Die betrachteten Daten werden der Prozedur 71, "Problemprofil aufbauen/aktualisieren", zusammen mit dem aktuellen Datensatz bereitgestellt. Für einen neuen Fehler existiert in der Problemprofil-Datenbank 29 (f) kein bereits vorhandener Problemprofil-Datensatz. Nachdem der Problemprofil-Datensatz aufgebaut ist, kehrt der Prozeß zu der Problembeschreibungsprozedur zurück, und zwar zu dem Punkt, an dem die Problemauswertungsprozedur (Profildatensatz, neues Problem) aufgerufen wird.
Bezieht sich der aktuelle Ausnahmedatensatz auf einen Wiederholfehler, wird der Problemprofil-Datensatz wie für einen neuen Fehler erzeugt, danach kehrt der Prozeß zu der Problembeschreibungsprozedur zurück, und zwar zu dem Punkt, an dem die Problemauswertungsprozedur (Profildatensatz, Wiederholwarnsignal) aufgerufen wird.
Wenn der aktuelle Ausnahmedatensatz sich auf einen Wiederholaufruf bezieht, wird auch ein Problemprofil-Datensatz wie für einen neuen Fehler aufgebaut, danach kehrt der Prozeß an den Punkt in der Problembeschreibungsprozedur zurück, an dem die Problemauswertungsprozedur (Profildatensatz, Wiederholaufruf) aufgerufen wird.

Problemauswertungsprozedur

Die Problemauswertungsprozedur ist schematisch in FIG. 5 dargestellt und wird in der Pseudo-Code-Aufstellung im Anhang 4 beschrieben.
Die Problemauswertungsprozedur wird aufgerufen, wenn der Eingangsparameter des Profildatensatzes neue Problemdaten enthält, die ausgewertet werden müssen. Die Auswertungs-Task besteht darin, entsprechende Dienstmaßnahmeanforderungen für die Problembedingung zu bestimmen sowie festzustellen, ob eine Dienstmaßnahme für eine Problemlösung einzuleiten ist.
Der Problemauswertungsprozeß ist Regelgesteuert, das heißt, die Daten in dem Problemprofil-Datensatz bestimmen sowohl die REGEL-Auswahl als auch die REGEL-Produkte. Die durch die REGEL-Ausführung erzeugte Information wird mit dem Profildatensatz VERBUNDEN und wird Teil der Problemprofil-Datenbank. Das Ergebnis ist ein Datenbank-Datensatz, der sowohl das Problem als auch die Ergebnisse der Problemanalyse beschreibt.
Wenn der Auswertungsprozeß feststellt, daß eine Dienstmaßnahme (noch) nicht erforderlich ist, wird der aktualisierte Problemprofil-Datensatz an die Problemprofil-Datenbank zurückgegeben. Ein späterer Aufruf des Dienstanalyse-Meldungsprozesses kann das Problem aktualisieren und neu bewerten. Andernfalls wird der Datensatz schließlich aus der Datenbank gelöscht.
Zur Analyse der Fehler wird ein Regelsatz 73 installiert. Die Regeln 73 werden auf den Problemprofil-Datensatz angewendet, der von der Prozedur "Problemprofil aufbauen/aktualisieren", 71, empfangen (aktualisiert) wird (siehe FIG. 4). Ist der aktuelle Fehler ein bekannter Fehler, für den eine Analyse im Gange ist, ist in dem Problemprofil-Datensatz eine Dienstwarnmeldung enthalten. Diese Dienstwarnmeldung wird in dem Meldungsdatenraum 83 plaziert, aus dem sie in die Analyseregeln 73 eingelesen wird. Die Steuerbefehle auf den Leitungen (A) oder (B) instruieren die Regeln 73, ob ein neuer Fehler (einschließlich Wiederholfehler und Wiederholaufrufe) oder ein bekannter Fehler analysiert werden soll, für den eine Analyse im Gange ist. Bei einem neuen Fehler erzeugen die Regeln eine Dienstwarnmeldung, die in den Meldungsdatenraum 83 eingelesen wird. Bei einem bekannten Fehler verändern die Regeln die vorhandene, aus dem Datenraum 83 eingelesene Meldung und lesen die in dem Datenraum befindliche neue Meldung.
Die Regeln 73 grenzen den Fehler ein, bestimmen den Schweregrad des Fehlers und eine empfohlene Dienstmaßnahme. Der Ausgang von den Regeln ist eine Steuerinformation für einen Bericht und die Aktualisierung der Datenbank, die auf die Dienstwarnsignal- und Datenbank-Aktualisierungssteuerung 81 angewendet wird.
Die Dienstwarnsignal- und Datenbank-Aktualisierungssteuerung 81 empfängt den Bericht von den Fehleranalyseregeln 73 und die Dienstwarnmeldung. Der Ausgang von den Fehleranalyseregeln 73 bestimmt, ob die Dienstwarnsignal- und Datenbank- Aktualisierungssteuerung 81 einen Dienstwarnmeldungsbericht an den Host weiterleitet, oder ob er einfach an die Problemprofil-Datenbank 29 (f) zurückgegeben wird und Teil der Beobachtung für später auftretende Fehler wird. Wenn der Bericht an den Host gesendet werden soll, dann wird die Problemprofil-Datenbank auch um diesen Bericht erweitert.
Wenn in dem Problemauswertungsprozeß beschlossen wird, daß eine Dienstmaßnahme erforderlich ist, wird eine Prozedur zur Erzeugung einer Dienstanalysemeldung "Daten erfassen" für eine entsprechende Dienstanalyse-Textmeldung aufgerufen. Die Dienstanalysemeldung "Daten erfassen" wird mit dem Problemprofil-Datensatz VERBUNDEN und auch an ein Host-System weitergegeben.

Anhang 1

PROZEDUR Problemerkennung (Eingangsprotokoll-Datensatz)

(* Der Prozeß zur Erzeugung der Dienstwarnmeldung erfordert, daß das Subsystem in regelmäßigen Abständen Pfad- und Gerätenutzungszählwerte mitteilt und daß Veränderungen in der Subsystemkonfiguration und Ausnahmeereignisse, sobald sie auftreten, mitgeteilt werden. Die Informationen werden in Form eines Protokolldatensatzes mitgeteilt, wobei jeder Protokolldatensatz aus den folgenden Komponenten besteht:
Protokolltyp, Protokollquelle, Protokolldaten und Zeitstempel *)

EINFÜGEN IN WERTE

(Eingangsprotokoll-Datensatz)
Subsystemumgebung.Nächster Datensatz (Protokolltyp, Protokollquelle, Protokolldaten, Zeitstempel)
Aktueller Datensatz:= Nächster Datensatz
Nächster Datensatz := Nächster Datensatz + 1
FALL Aktueller Datensatz.Protokolltyp VON Gerätenutzungsbericht
AKTUALISIEREN Protokollquelle (Nutzungsstatistik)
(* Aktuellen Datensatz und Protokollquelle verwenden. Vorheriger Datensatz soll aktuellen aktualisieren und Nutzungshäufigkeitswerte benennen für: Pfadzugriff, Bewegungssuche, Datenschreiben und Datenlesen. *)
Veränderte Subsystemkonfiguration
AKTUALISIEREN Protokollquelle (Vitale Konfigurationsdaten)
(* Den aktuellen Datensatz verwenden, um zu bestimmen, inwieweit sich die Konfiguration geändert hat; Gültigkeit der Änderung prüfen; und die entsprechenden Konfigurationsdatensätze aktualisieren. *)
Ausnahmeereignis (Typ = "weich")
AUSWÄHLEN Zeitstempel, Ausnahmesymptom, Symptom- Domäne, Fehlermuster
AUS Subsystemumgebung
WO Die Ausnahmedatenvergleichs-REGEL bestimmt wird aus:
Aktueller Datensatz (Protokolldaten.Symptom * Protokollquelle.Grenze)
AKTUALISIEREN Aktueller Datensatz (Fehlermuster)
(* Der aktuelle Datensatz wird aktualisiert und enthält dann eine Fehlermusterbeschreibung, die aus der Vergleichsbetrachtung der Datenbank abgeleitet ist.
Ein Fehlermuster ist gekennzeichnet durch: Symptom-Profil, Fehlerereignisse, Fehler- Periode. *)
WENN Fehlermuster > Symptom (Schwellenkriterien)
DANN GEHE ZU Problembeschreibung (Anhang 2)
Ausnahmeereignis (Typ = "hart")
GEHE ZU Problembeschreibung (Anhang 2)
ENDE (des Falls)
ENDE. (Prozedur Problemerkennung)

Anhang 2

PROZEDUR Problembeschreibung (Aktueller Datensatz)

(* Diese Prozedur versucht, den aktuellen Datensatz mit einem Profildatensatz zu verknüpfen, der bereits bei einem früheren Auftreten desselben Problems erzeugt wurde. Ist die Verknüpfung erfolgreich, werden, abhängig vom Profildatensatz.Status, die Profile aktualisiert und geben die neuen Daten aus der Subsystemumgebung wieder. Andernfalls wird ein neuer Profildatensatz erzeugt. *)
AUSWÄHLEN Profildatensatz (*.ID, *.Status)
AUS Problemprofil
WO Die Profildatensatzvergleichs-REGEL bestimmt wird aus:
Aktueller Datensatz (Protokolldaten.Symptom * Protokollquelle Grenze)
FALL Auswählen Ergebnisse VON Leerer Satz (* Keine Vorgeschichts-Verknüpfung gefunden *)
Profil aufbauen (Aktueller Datensatz) (Anhang 3)
(* Die Prozedur erzeugt eine Vergleichsbetrachtung der Subsystemumgebung des aktuellen Datensatzes. Muster für einen neuen Profildatensatz werden aus den Daten in der Betrachtung aufgebaut. *)
GEHE ZU Problemauswertung (Profildatensatz, neues Problem)
Verknüpfung gefunden (*.Status = Nicht an das System gemeldet) (Analyse im Gange)
Profil aktualisieren (Aktueller Datensatz, Profildatensatz) (Anhang 3)
(* Die Prozedur erzeugt eine Vergleichsbetrachtung von neuen Einträgen (seit *.ID) in der Subsystemumgebungs-Datenbank des aktuellen Datensatzes. Die Profildatensatz-Muster werden aus den Daten in dieser Betrachtung aktualisiert. *)
GEHE ZU Problemauswertung (Profildatensatz, regelmäßig wiederkehrendes Problem)
Verknüpfung gefunden (*.Status = Dienstmaßnahme anstehend) Profildatensatz.Anzahl der regelmäßig wiederkehrenden Probleme: *.* +1
(* Zahl der wiederholten Ausnahmeereignisse pflegen. *)
Verknüpfung gefunden (*.Status = keine Dienstantwort) (Wiederholfehler)
Profil aktualisieren (Aktueller Datensatz, Profildatensatz) (Anhang 3)
(* Dienstwarnmeldung aktualisieren ünd dem System erneut mitteilen. *)
GEHE ZU Problemauswertung (Profildatensatz, Wiederhol- Warnsignal)
Verknüpfung gefunden (*.Status = Dienstmaßnahme abgeschlossen) (Wiederholaufruf)
Profil aufbauen (Aktueller Datensatz) (Anhang 3) (* Dienstmaßnahme nicht erfolgreich. Neue Dienstwarnmeldung für Maßnahme durch hierfür geschulten Kundendiensttechniker aufbauen. *)
GEHE ZU Problemauswertung (Profildatensatz, Wiederholaufruf)
ENDE
ENDE. (Prozedur Problembeschreibung)

Anhang 3

PROZEDUR Profil aufbauen (Aktueller Datensatz)

INITIALISIEREN Profildatensatz (Zeitstempel = Null) (* Aufbau eines neuen Profildatensatzes vorbereiten. *)

PROZEDUR Profil aktualisieren (Aktueller Datensatz, Profildatensatz)

(* Diese Prozedur baut einen Profildatensatz auf oder aktualisiert einen Profildatensatz, der eine Vergleichsbetrachtung der Subsystemumgebung des aktuellen Datensatzes darstellt. *)
AUSWÄHLEN SCU-Konfiguration, String-Konfiguration, Geräte- Konfiguration
AUS Subsystemumgebung (Zeitstempel > Profildatensatz.Zeitstempel)
WO Die Konfigurationsdatenvergleichs-REGEL bestimmt wird aus: Aktueller Datensatz (Protokolldaten Symptom * Protokollquelle Grenze)
PROFIL (* Subsystemkanäle, SP Controller, String- Pfad-Controller, Spindeln, Geräte und Modell/Funktionsmerkmale, eingebaut und (nicht reserviert) innerhalb der "relevanten" Subsystem-Grenze. *)
AUSWÄHLEN SP-Nutzung, String-Nutzung, Pfad-Nutzung, Spindel- Nutzung, Geräte-Nutzung
AUS Subsystemumgebung (Zeitstempel > Profildatensatz. Zeitstempel)
WO Die Nutzungsstatistikvergleichs-REGEL bestimmt wird aus: Aktueller Datensatz (Protokolldaten.Symptom * Protokollquelle.Grenze)
PROFIL (* Nutzungsmuster für Subsystemkomponenten, die innerhalb der "relevanten" Subsystem- Grenze installiert und betriebsfähig sind. *)
AUSWÄHLEN ERP-Maßnahme, ERP-Ressource, ERP-Ergebnis
AUS Subsystemumgebung (Zeitstempel > Profildatensatz. Zeitstempel)
WO Die ERP-Datenvergleichs-REGEL bestimmt ward aus:Aktueller Datensatz (Protokolldaten.Symptom * Protokollquelle. Grenze)
PROFIL (* Ergebnisse von Ausnahmekorrekturmaßnahmen,
die für "relevante" Ausnahmen aufgerufen wurden, und Verwendung von Komponenten innerhalb der "relevanten" Subsystem-Grenze. *)
AUSWÄHLEN Befehlsausnahme, Ausnahme-Symptom, Sub-Symptom- Parameter, Symptom-Domäne, Strom-Status
AUS Subsystemumgebung (Zeitstempel > Profildatensatz. Zeitstempel)
WO Die Ausnahmedaten-Vergleichs-REGEL bestimmt wird aus: Aktueller Datensatz (Protokolldaten. Symptom * Protokollquelle Grenze)
PROFIL (* Syndrom-Muster, die für "relevante" Ausnahmen erkannt wurden, und Verwendung von Komponenten innerhalb der "relevanten" Subsystem-Grenze. Die Profilmuster liefern eine Knotenpunkt-Eingrenzung für (einen) wahrscheinliche(n) Fehlermodus(modi). und (eine) mögliche Fehlergrenze(n). *)
Profildatensatz.Zeitstempel := Aktuelle Zeit
ENDE (Prozedur Profil aufbauen/aktualisieren) (Rückkehr zur Prozedur Problembeschreibung)

Anhang 4

PROZEDUR Problemauswertung (Profildatensatz, Status)

(* Diese Prozedur verarbeitet Daten in dem Profildatensatz zur Erzeugung von Dienstanforderungen für das erkannte Problem. Anschließend wird die Dienstwarnmeldung "Daten erfassen" erzeugt und einem Host-System mitgeteilt, WENN die Dienstanforderungen anzeigen, daß das erkannte und ausgewertete Problem eine Dienstmaßnahme erfordert. Die durch diese Prozedur erzeugte Problemauswertungsinformation wird mit dem Profildatensatz VERBUNDEN und in der Problemprofil -Datenbank gespeichert. *)
LADEN REGEL-Satz für Profildatensatz.Ausnahmeklassen- Gruppe
(* Ausnahmeklassen-Gruppe kennzeichnet die ausgefallene DAS-Funktion. Der REGEL-Satz wird ausgeführt, um die Dienstmaßnahmeanforderungen zu bestimmen. *)
AUSFÜHREN REGEL-Satz. Fehlereingrenzung
PROFILIEREN Eingrenzungsstatus IN Profildatensatz.Dienstanforderungen
Gewißheit eingrenzen= SATZ VON 1..10
Kundendienstdiagnoseverfahren = SATZ VON 1..n
Primäre FRU = Keine _ SATZ VON 1..n
Sekundäre FRU = Keine _ SATZ VON 1..n
Defekte Stelle auf dem Medium = Keine _ Medienadresse (Grenzparameter)
Medienwartungsverfahren = Keines _ SATZ VON 1..n
(* REGEL-Satz verarbeitet die Daten des Profildatensatzes, um das aufgezeichnete Fehlersyndrom-Muster mit der höchsten Wertigkeit auszuwählen. Zum Beispiel: der Nachweis eines Stromfehlersyndroms hat Vorrang vor einem möglicherweise auch aufgezeichneten Logikfehlersyndrom; oder: der Nachweis eines Logik- oder Analogfehlersyndroms hat Vorrang gegenüber einem möglicherweise auch aufgezeichneten Datenfehlersyndrom.
Der Mindest-Eingrenzstatus ist eine Eingrenzgewißheit von = 1 und ein Verweis auf ein Kundendienst-Diagnoseverfahren.
Der Höchst-Eingrenzstatus ist eine Eingrenzgewißheit von = 10 und ein Verweis auf eine einzelne Primäre FRU oder eine Defekte Stelle auf dem Medium. *)
AUSFÜHREN REGEL-Satz. Fehlerschweregrad
PROFILIEREN Schweregrad-Status IN Profildatensatz.Dienstanforderungen
Permanenz = SATZ VON (Hart, Weich)
Fortbestehen = SATZ VON (Ereignis, Burst, Regelmäßig Wiederkehrend, Intermittierend)
Unterbrechung = SATZ VON (Keine, Unterstützung, Kanal, Pfad, Gerät, Daten)
Umfang = SATZ VON 0..n
(* REGEL-Satz verarbeitet die Daten des Profildatensatzes, um den Schweregrad-Status für das durch die Fehlereingrenzung bestimmte Fehlersyndrom zu bestimmen. Der Schweregrad-Status wird dem Profildatensatz hinzugefügt. *)
AUSFÜHREN REGEL-Satz.Dienstmaßnahme
PROFILIEREN Dienststatus IN Profildatensatz.Dienstanforderungen
Dienststatus = SATZ VON (Wahrscheinlicher Fehler, Reparaturfehler)
(* Dieser REGEL-Satz verarbeitet die Prozedur-Eingangsparameter (Neues Problem, Regelmäßg wiederkehrendes Problem, Wiederhol-Warnsignal, Wiederholaufruf) zusammen mit dem Eingrenzstatus und dem Schweregrad-Status, um den Verlauf der Maßnahmen für diesen Profildatensatz zu bestimmen. *)
FALL Dienststatus VON Wahrscheinlicher Fehler
AKTUALISIEREN Profildatensatz (Problemstatus := Analyse im Gange)
(* Der Dienstwarnmeldungsprozeß für den Aktuellen Datensatz wird durch Rücksenden des Profildatensatzes in die Problemprofil-Datenbank beendet. Wenn das Problem erneut auftritt, wird der Rekursiv-Prozeß der Aktualisierung und Neubewertung nochmals aufgerufen. Wenn das Problem innerhalb einer vorgegebenen Zeit nicht wieder auftritt, dann wird der Profildatensatz aus der Problemprofil-Datenbank gelöscht. *)
Reparaturfehler
AKTUALISIEREN Profildatensatz (Problemstatus := Problem gemeldet)
Dienstwarnmeldung erzeugen (Profildatensatz.Dienstanforderungen)
Dienstwarnmeldung "Daten erfassen" MIT Profildatensatz. Dienstwarnmeldung VERBINDEN
Dienstwarnmeldung an Host melden (Profildatensatz-Dienstwarnmeldung)
(* Der Dienstwarnmeldungsprozeß für den Aktuellen Datensatz wird beendet durch Erzeugen eines Datensatzes mit der Dienstwarnmeldung "Daten erfassen" aus den Daten im Profildatensatz. Die Dienstwarnmeldung "Daten erfassen" wird dann an ein Host-System gesendet, um den Dienstprozeß der Maschine einzuleiten. Der Meldeprozeß wird in bestimmten Intervallen wiederholt, bis die Dienstmaßnahme eingeleitet ist, oder bis ein vorgegebenes Meldefenster abgelaufen ist. *)
ENDE
ENDE. (Prozedur Problemauswertung)

Claims

1. Ein Verfahren zur automatischen Erfassung und Analyse von Ausnahmeereignissen, die in dem peripheren Subsystem eines Rechners auftreten, das an ein Host-Rechnersystem angeschlossen ist, wobei das Verfahren durch folgende Schritte gekennzeichnet ist:

Pflegen einer Subsystemumgebungs-Datenbank, die Informationen bezüglich der aktuellen Konfiguration des genannten peripheren Rechner-Subsystems sowie Nutzungs- und Fehlerinformationen bezüglich des genannten peripheren Subsystems enthält;

bedingungsabhängiges Aufrufen einer Problembeschreibungsprozedur, wenn die Daten in der genannten Subsystemumgebungs-Datenbank ein Ausnahmeereignis wiedergeben, das entweder eine eindeutige oder eine wahrscheinliche Notwendigkeit für eine Dienstmaßnahme an dem genannten peripheren Subsystem anzeigt, wobei die genannte Problembeschreibungsprozedur folgendes umfaßt: Entwicklung eines aktuellen Problemprofil-Datensatzes, der das genannte Ausnahmeereignis beschreibt; Erzeugen einer Betrachtung einer Problemprofil-Datenbank für das genannte Ausnahmeereignis aus gespeicherten Regeln;

Abfragen einer Problemprofil-Datenbank, die Problemprofil-Datensätze von bereits früher aufgetretenen Ausnahmeereignissen enthält, um den genannten aktuellen Problemprofil-Datensatz mit einem Problemprofil-Datensatz zu vergleichen, der bereits in der genannten Problemprofil-Datenbank vorhanden ist;

wenn der genannte aktuelle Problemprofil-Datensatz mit einem bereits in der genannten Problemprofil-Datenbank vorhandenen Problemprofil-Datensatz übereinstimmt, und der genannte bereits vorhandene Problemprofil-Datensatz anzeigt, daß eine Dienstmaßnahme für das betreffende Problem bereits ansteht, Aktualisieren des genannten vorhandenen Problemprofil-Datensatzes;

wenn der genannte aktuelle Problemprofil-Datensatz mit einem in der genannten Problemprofil-Datenbank bereits vorhandenen Problemprofil-Datensatz übereinstimmt, und der genannte bereits vorhandene Problemprofil-Datensatz anzeigt, daß eine Dienstmaßnahme für das betreffende Problem nicht ansteht, Aktualisieren des genannten vorhandenen Problemprofil-Datensatzes und Aufrufen einer Problemauswertungsprozedur;

wenn der genannte aktuelle Problemprofil-Datensatz nicht mit einem in der genannten Problemprofil-Datenbank bereits vorhandenen Problemprofil-Datensatz übereinstimmt, Hinzufügen des genannten Problemprofil-Datensatzes zu der genannten Problemprofil-Datenbank und Aufrufen einer Problemauswertungsprozedur;

wobei die genannte Problemauswertungsprozedur folgendes umfaßt:

Prüfen des genannten aktuellen Problemprofil-Datensatzes im Hinblick auf gespeicherte Regeln, die sich auf eine akzeptable Subsystem-Leistung beziehen; und wenn die Funktionen des genannten peripheren Subsystems unterbrochen wurden oder sich soweit verschlechtert haben, daß bestimmte Grenzwerte im Hinblick auf eine akzeptable Subsystem-Leistung überschritten sind, Erzeugen einer Dienstwarnmeldung und Einfügen der genannten Dienstwarnmeldung in den genannten Problemprofil-Datensatz, Aktualisieren des genannten vorhandenen Problemprofil-Datensatzes in der genannten Problemprofil-Datenbank und Übertragen der genannten Dienstwarnmeldung zu dem genannten Host-System.

2. Die Methode nach Anspruch 1, bei der der genannte Schritt des bedingungsabhängigen Aufrufens der genannten Problembeschreibungsprozedur die Prüfung der genannten Subsystemumgebungs-Datenbank im Hinblick auf Regeln umfaßt, die eine normale Leistung und mögliche Ausnahmeereignisse beschreiben.

3. Das Verfahren nach Anspruch 2, bei dem der genannte Schritt des bedingungsabhängigen Aufrufens der genannten Problembeschreibungsprozedur außerdem das Prüfen der Daten umfaßt, die sich auf das genannte Ausnahmeereignis beziehen, um festzustellen, ob es sich bei dem genannten Ausnahmeereignis um ein weiches oder ein hartes Ereignis handelt, und bei dem:

wenn das genannte Ausnahmeereignis ein hartes Ereignis ist, die genannte Problembeschreibungsprozedur aufgerufen wird; und

wenn das genannte Ausnahmeereignis ein weiches Ereignis ist, das genannte Ausnahmeereignis geprüft und mit einem Regelsatz verglichen wird, um festzustellen, ob ein Schwellenkriterium überschritten wurde, und die genannte Problembeschreibungsprozedur aufgerufen wird, wenn das genannte Schwellenkriterium überschritten wurde.

4. Das Verfahren nach Anspruch 3, bei dem der genannte Schritt des Prüfens des genannten Ausnahmeereignisses im Vergleich mit einem Regelsatz, um festzustellen, ob ein Schwellenkriterium überschritten wurde, das Prüfen des genannten Ausnahmeereignisses im Vergleich mit einem Regel-Nebensatz umfaßt, der sich auf den Typ des Ausnahmeereignisses und den Abschnitt des genannten peripheren Rechner-Subsystems beziehen, der sich auf das genannte Ausnahmeereignis bezieht.

5. Das Verfahren nach Anspruch 4, bei dem das Feststellen, ob ein Schwellenkriterium überschritten wurde, die Feststellung umfaßt, ob ein Trend von miteinander verglichenen Ausnahmeereignissen in einem gemeinsamen Abschnitt des genannten peripheren Rechner-Subsystems erkannt wurde.

6. Ein System zur automatischen Erkennung und Analyse von Ausnahmeereignissen, die in einem peripheren Rechner- Subsystem auftreten, das an ein Host-Rechnersystem angeschlossen ist, wobei das System durch folgende Schritte gekennzeichnet ist:

Mittel zur Pflege einer Subsystemumgebungs-Datenbank, die Informationen bezüglich der aktuellen Konfiguration des genannten peripheren Rechner-Subsystems sowie Nutzungs- und Fehlerinformationen bezüglich des genannten peripheren Subsystems enthält;

Mittel zum bedingungsabhängigen Aufrufen eines Problembeschreibungsprozedur-Mittels, wenn die Daten in der genannten Subsystemumgebungs-Datenbank auf ein Ausnahmeereignis hinweisen, das entweder eine eindeutige oder eine wahrscheinliche Notwendigkeit einer Dienstmaßnahme an dem genannten peripheren Subsystem anzeigt, wobei das genannte Problembeschreibungsprozedur-Mittel folgendes umfaßt:

Mittel zur Entwicklung eines aktuellen Problemprofil-Datensatzes, der das genannte Ausnahmeereignis beschreibt; Mittel zur Erzeugung einer Betrachtung einer Problemprofil-Datenbank bezüglich des genannten Ausnahmeereignisses aus gespeicherten Regeln;

Mittel zum Abfragen einer Problemprofil-Datenbank, die Problemprofil-Datensätze von bereits früher aufgetretenen Ausnahmeereignissen enthält, um den genannten aktuellen Problemprofil-Datensatz mit einem Problemprofil- Datensatz zu vergleichen, der bereits in der genannten Problemprofil-Datenbank vorhanden ist;

wenn der genannte aktuelle Problemprofil-Datensatz mit einem in der genannten Problemprofil-Datenbank vorhandenen Problemprofil-Datensatz übereinstimmt, und der genannte vorhandene Problemprofil-Datensatz anzeigt, daß für das betreffende Problem eine Dienstmaßnahme ansteht, Aktualisieren des genannten vorhandenen Problemprofil- Datensatzes;

wenn der genannte aktuelle Problemprofil-Datensatz mit einem vorhandenen Problemprofil-Datensatz in der genannten Problemprofil-Datenbank übereinstimmt, und der genannte vorhandene Problemprofil-Datensatz anzeigt, daß für das betreffende Problem keine Dienstmaßnahme ansteht, Aktualisieren des genannten vorhandenen Problemprofil-Datensatzes und Aufrufen eines Problemauswertungsprozedur-Mittels;

wenn der genannte aktuelle Problemprofil-Datensatz nicht mit einem in der genannten Problemprofil-Datenbank bereits vorhandenen Problemprofil-Datensatz übereinstimmt, Hinzufügen des genannten aktuellen Problemprofil-Datensatzes zu der genannten Problemprofil-Datenbank und Aufrufen eines Problemauswertungsprozedur-Mittels; wobei das genannte Problemauswertungsprozedur-Mittel folgendes umfaßt:

Mittel zum Prüfen des genannten aktuellen Problemprofil- Datensatzes im Hinblick auf gespeicherte Regeln, die sich auf eine akzeptable Subsystem-Leistung beziehen; und

Mittel, um festzustellen, ob Funktionen des genannten peripheren Subsystems unterbrochen wurden oder sich soweit verschlechtert haben, daß eine bestimmte Grenze im Hinblick auf eine akzeptable Subsystem-Leistung überschritten wurde, Mittel zum Erzeugen einer Dienstwarnmeldung und Einfügen der genannten Dienstwarnmeldung in den genannten Problemprofil-Datensatz, Aktualisieren des genannten Problemprofil-Datensatzes in der genannten Problemprofil-Datenbank und Übertragen der genannten Dienstwarnmeldung an das genannte Host-System.

7. Ein System nach Anspruch 6, bei dem das genannte Mittel zum bedingungsabhängigen Aufrufen der genannten Problembeschreibungsprozedur Mittel zum Prüfen der genannten Subsystemumgebungs-Datenbank im Hinblick auf Regeln umfaßt, die eine normale Leistung und mögliche Ausnahmeereignisse beschreiben.

8. Ein System nach jedem der Ansprüche 6 oder 7, bei dem das genannte Mittel zum bedingungsabhängigen Aufrufen der genannten Problembeschreibungsprozedur zusätzlich Mittel zur Prüfung der Daten des genannten Ausnahmeereignisses umfaßt, um festzustellen, ob es sich bei dem genannten Ausnahmeereignis um ein weiches oder ein hartes Ereignis handelt, und bei dem:

wenn das genannte Ausnahmeereignis ein hartes Ereignis ist, das genannte Problembeschreibungsprozedur-Mittel aufgerufen wird; und

wenn das genannte Ausnahmeereignis ein weiches Ereignis ist, das genannte Ausnahmeereignis mit einem Regelsatz verglichen wird, um festzustellen, ob ein Schwellenkriterium überschritten wurde, und, wenn das genannte Schwellenkriterium überschritten wurde, Aufrufen der genannten Problembeschreibungsprozedur-Mittels.