DE19827431C2 - Verfahren zur Fehlererkennung in einem Prozessorsystem - Google Patents

Description

Die Erfindung betrifft ein Verfahren zur Fehlererkennung in ei­ nem mit mehreren Programmen arbeitenden, mindestens einen Pro­ zessor enthaltenden Prozessorsystem.

Bei Prozessorsystemen mit umfangreicher Software-Ausstattung sind Software-Fehler weitgehend unvermeidlich. Damit der Ablauf der Programme und insgesamt der Betrieb des gesamten Prozessor­ system jedoch nicht durch solche Software-Fehler zu stark be­ einträchtigt wird, ist eine möglichst rasche Erkennung von Software-Fehlern, d. h. Programmfehlern, wünschenswert, da die Software-Fehler zu Betriebsstörungen bis hin zu einer voll­ ständigen Rücksetzung einzelner Programme oder gar des ganzen Prozessorsystems führen können. Insbesondere bei Realzeitsyste­ men wie etwa elektronischen Wählvermittlungsanlagen für die Te­ lekommunikation, die ein bevorzugtes, aber nicht ausschließli­ ches Anwendungsgebiet der vorliegenden Erfindung darstellen, müssen die durch solche Software-Fehler vorgerufenen Ausfall­ zeiten minimiert werden.

Im Hinblick auf die Fehlererkennung in Prozessorsystemen ist aus der Patentschrift US 4,953,096 A ein verteiltes Mehrprozes­ sorsystem bekannt, bei dem jeder Prozessor die Fehlerhaftigkeit eines Programms registriert und daraufhin einen Wechsel von ei­ nem Verarbeitungsmodus in einen Testmodus veranlaßt.

Aus der Patentschrift US 5,287,490 A ist eine Fehlerkorrektur­ methode im Zusammenhang mit einer ablaufenden Programmcodeüber­ setzung bekannt.

Die in den genannten Schriften offenbarten Methoden liegen auf einem anderen Anwendungsgebiet und sind daher zur Problemlösung im Zusammenhang mit der vorstehend beschriebenen erforderlichen raschen Erkennung von Software-Fehlern nicht geeignet.

Zur verbesserten Fehlerkennung und -behandlung könnte überlegt werden, einen Prozess, der eine Fehlermeldung erzeugt, zurück­ zusetzen, um hierdurch das Fehlerproblem zu beheben. Alternativ könnte auch überlegt werden, den kompletten Prozessor zurückzu­ setzen und wieder anlaufen zu lassen, insbesondere dann, wenn die Zahl der Fehlermeldungen eines Prozessors einen vorgegebe­ nen Schwellwert überschritten hat. Bei einer solchen Vorgehens­ weise findet jedoch normalerweise eine Rücksetzung in zu großem Umfang statt, da dann auch fehlerfrei arbeitende Programme rückgesetzt werden und somit das Leistungsvermögen des gesamten Prozessors verschlechtert ist.

Der Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren zur Fehlerkennung in einem mit mehreren Programmen arbeitenden, mindestens einen Prozessor enthaltenden Prozessorsystem zu schaffen, mit dem eine verbesserte Erkennbarkeit von fehlerhaft arbeitenden Programmen möglich ist.

Diese Aufgabe wird mit den im Patentanspruch 1 genannten Merk­ malen gelöst.

Vorteilhafte Ausgestaltungen der Erfindung sind in den Unteran­ sprüchen angegeben.

Bei dem erfindungsgemäßen Verfahren werden von mindestens einem Programm innerhalb des vorzugsweise in Realzeit arbeitenden Prozessorsystems Fehlererkennungsüberprüfungen, insbesondere Plausibilitätsüberprüfungen hinsichtlich der Daten durchge­ führt, mit denen die jeweiligen Programme arbeiten und die sie von anderen Programmen erhalten haben. Hierdurch lassen sich Fehler erkennen, so daß eine Fehlerfortpflanzung verhindert werden kann. Wenn die Plausibilitätsüberprüfung, die in her­ kömmlicher Weise erfolgen kann, ergibt, daß die empfangenen In­ formationen (Daten) inkonsistent, d. h. als fehlerhaft einzustu­ fen sind, gibt dieses Programm eine Fehlermeldung an das Be­ triebssystem ab. Im Betriebssystem wird entsprechend dieser Fehlermeldung eine Fehlermeldungstabelle aktualisiert, in der Informationen über das als fehlerhaft eingestufte, die fehler­ haften Daten abgebende Programm, und ggf. auch über das melden­ de Programm, registriert werden. Der meldende Prozeß gibt somit auch einen Fingerzeig auf die vermutete Fehlerquelle, d. h. auf ein anderes Programm. Hierdurch gewinnt das System verbesserte Übersichtsinformation über möglicherweise fehlerhaft arbeitende Programme und kann z. B. charakterisierende Daten für das mel­ dende und das als fehlerhaft gemeldete Programm zusammentragen, um hierdurch eine verbesserte Fehlereingrenzung zu ermöglichen, und kann auch eine statistische Bewertung, insbesondere eine Aufsummierung der Anzahl von Fehlermeldungen selektiv für jedes Programm durchführen. Das Betriebssystem kann geeignete Fehler­ behebungsmaßnahmen, z. B. eine Rücksetzung eines vermehrt als fehlerhaft gemeldeten Programms, einleiten, oder auch bei Not­ wendigkeit eine Rücksetzung des gesamten Prozessors initiieren.

Mit der vorliegenden Erfindung läßt sich somit eine genauere Erkennung und Festlegung der Erforderlichkeit von Korrekturmaß­ nahmen, insbesondere von einzelnen Programm-Rücksetzungen oder einem Anlauf in größerem Umfang, die zur Rückführung des Sy­ stems auf volle Leistungsfähigkeit erforderlich sind, errei­ chen. Das erfindungsgemäße Verfahren erlaubt somit eine Erfas­ sung von aufgrund Fehlerhaftigkeit rückzusetzenden Programmen in optimierter Weise. Dies erfolgt, indem einem Programm oder auch dem übergeordneten Betriebssystem die Möglichkeit gegeben wird, gewissermaßen auf ein anderes Programm zu zeigen und die­ ses als fehlerhaft anzuprangern. Hierdurch läßt sich der Umfang von eventuell erforderlichen Rücksetzungen auf das notwendige Maß beschränken und eine unnötige Rücksetzung einer zu großen Anzahl von Prozessen oder eventuell des gesamten Prozessors oder sogar eines mehrere Prozessoren enthaltenen Systems, ver­ meiden.

Die Benutzersoftware erhält somit eine spezielle Meldungsmög­ lichkeit, so daß sie dem Betriebssystem Hinweise geben kann, welcher Prozeß eventuell fehlerhaft ist. Das Betriebssystem kann anhand dieser Fehlermeldung lokalisieren, welcher andere Prozeß ggf. rückzusetzen ist. Dies muß nicht unbedingt der als fehlerhaft gemeldete Prozeß sein, sondern kann auch ein ande­ rer, diesen Prozeß ansteuernder oder diesem übergeordneter Pro­ zeß sein. Auf jeden Fall kann das Betriebssystem die Identität des Prozesses, der die Fehlermeldung erzeugt hat, ebenfalls er­ mitteln, vorzugsweise über das gesamte System hinweg in eindeu­ tiger Weise. Das Betriebssystem kann diese Prozessidentifikati­ on für eine breite Vielzahl von Schnittstellen, z. B. von gesen­ deten Nachrichten, Fernverarbeitungsrufen (remote procedure calls) usw. durchführen.

Hierbei ist die Fähigkeit der Benutzerprozesse, d. h. der auf der untersten Interrupt-Ebene Null laufenden Benutzersoftware, einen anderen Prozeß als fehlerhaft einzustufen, auf die als mögliche Kandidaten in Betracht kommenden Programme und Schnittstellenpartner gerichtet. Die Möglichkeit, daß Benutzer- Prozesse andere Prozesse unkorrekt als fehlerhaft einstufen, wird hierbei durch den Einsatz von Compiler-basierenden Regeln in Abhängigkeit von der Art des Problems und der Art der Schnittstelle verringert.

Da das Betriebssystem in der Fehlermeldungstabelle Informatio­ nen sowohl über das meldende als auch über das als fehlerhaft bezeichnete Programm speichert, kann die Arbeitsweise des er­ findungsgemäßen Verfahrens vorzugsweise derart ausgestaltet werden, daß das Betriebssystem ein Programm dann rücksetzt und erneut anlaufen läßt, sobald die Anzahl von für dieses Programm gespeicherten Meldungen (Anzahl von Fehlermeldungen, die ein Programm abgegeben hat, oder auch Anzahl von Fehlermeldungen, die auf ein Programm als fehlerhaft hinweisen) einen vorgegebe­ nen Schwellenwert erreicht. Hierdurch wird die Wahrscheinlich­ keit, den tatsächlich aufgrund von Fehlerhaftigkeit zurückzu­ setzenden Prozeß rascher zu finden, deutlich erhöht.

Das erfindungsgemäße Verfahren kann auch derart ausgestaltet werden, daß bei einem System mit mehreren Prozessoren, bzw. mit mehreren Plattformen, wie es bei einem elektronischen Wählver­ mittlungssystem für die Telekommunikation vorliegt, das Be­ triebssystem auf einer Plattform Fehlermeldungsinformationen oder sonstige begleitende Informationen, die die Fehlereingren­ zung erlauben, von der eigenen Plattform zu einer weiteren Plattform, auf der der als fehlerhaft vermutetete Prozeß tat­ sächlich läuft, transportiert.

Die von einem Programm abgegebene Fehlermeldung kann das Be­ triebssystem veranlassen, die Identität des bezeichneten, als fehlerhaft eingestuften Programms zu ermitteln und umgehend in der Fehlermeldungstabelle zu speichern. Alternativ kann die Fehlermeldung zunächst auch nur als Aufruf ausgewertet werden, auf den hin das Betriebssystem an das meldende Programm die In­ formation über die Identität des als fehlerhaft vermuteten Pro­ gramms zurückreicht, wonach diese Information dann von dem mel­ denden Programm an die Fehlermeldungstabelle, die sich vorzugs­ weise im Betriebssystem befindet, weitergereicht wird. Die In­ formation über das jeweilige Programm befindet sich hierbei vorzugsweise in einem die als fehlerhaft eingestuften Daten enthaltenden Datenrahmen, insbesondere in Form eines Informati­ onskopfs (Header).

Die Erfindung wird nachstehend anhand von Ausführungsbeispielen un­ ter Bezugnahme auf die Zeichnungen näher erläutert.

Figs. 1 und 2 zeigen Übersichtstabellen über bestimmte Fehler­ arten und die hierdurch ausgelösten Reaktionen,

Fig. 3 zeigt eine Übersichtstabelle zur Veranschauli­ chung der Bedeutung der einzelnen Fehlermeldun­ gen,

Fig. 4 zeigt allgemein den Informationsfluß bei einer Fehlererkennung bei dem Ausführungsbeispiel,

Figs. 5 und 6 zeigen Ablaufdiagramme bei Fehlermeldungen,

Fig. 7 zeigt ein Flußdiagramm für die Verarbeitung im Software-Fehlerbehandlungsabschnitt, und

Fig. 8 zeigt den Aufbau einer Ausführungsform einer Fehlermeldungstabelle.

In Fig. 1 ist eine Übersichtstabelle über Fehlerarten, jeweili­ ge Fehlermeldungen und unmittelbare Korrekturvorgänge für die auf dem Interrupt-Level Null laufenden Benutzer-Programme (User-Software) dargestellt, während in Fig. 2 eine ähnliche Übersichtstabelle für die auf höherem Interrupt-Level laufenden Supervisor-Programme gezeigt ist. Der korrekte Einsatz der je­ weils angegebenen Aktionen wird durch entsprechende Tool-Pro­ gramme sichergestellt.

Die in der rechten Spalte der jeweiligen Tabellen vorhandenen Eintragungen bezeichnen die Identifizierungsaufrufe, die zur Meldung und/oder Erkennung eines anderen, als fehlerhaft einge­ stuften Programms dienen.

Bei Empfang von Daten/Nachrichten führt das empfangende Pro­ gramm eine Plausibilitätsprüfung hinsichtlich des Dateninhalts und/oder eine Überprüfung des Zeitrahmens für den Datenempfang durch und kann hierdurch Fehler erkennen. Wenn das die als feh­ lerhaft eingestuften Daten/Nachrichten erzeugende Programm auf der Benutzer-Ebene läuft, kann das empfangende, gleichfalls auf der Benutzerebene laufende Programm dieses direkt als fehler­ haft an das Betriebssystem melden. Hierzu sind spezielle, un­ terschiedliche Fehlermeldungen SWERR oder SWINC vorgesehen, die an die Supervisor-Ebene gerichtet sind. Es kann auch erkannt werden, wenn eine eigentlich erwartete Nachricht nicht erhalten wird (Message Missing), und auch in einem solchen Fall eine Fehlermeldung erzeugt werden. Hierbei sind zur genaueren Spezi­ fizierung der als fehlerhaft eingestuften Software die nachfol­ gend angegebenen Umwandlungsroutinen vorgegeben, die in den Fig. 1 und 2 jeweils in der rechten Spalte angegeben sind:
"ONCONVO_NO_BLAMING" wandelt den Vorgabewert für "Keine Fehler­ meldung" um. Diese Umwandlungsroutine wird stets dann benutzt, wenn kein Fehlerhinweis auf ein anderes Programm abzugeben ist;
"ONCONV1_BUFFER" wandelt den durch die Fehlermeldung zu be­ zeichnenden Puffer in eine Puffer-Identifikation um, die diesen Puffer und dessen Position identifiziert;
"ONCONV2_UBI" wandelt die spezielle Puffer-Identifikation (Unique Buffer Identifier) in eine Identifikation um, die die aufgrund eines vermuteten Fehlers zu meldende Puffer-Identifi­ kation und deren Position angibt;
"ONCONV3_REMOTE_PROCEDURE" wandelt die als vermutlich fehler­ haft zu meldende, entfernt laufende Prozedur in eine entspre­ chende Prozedur-Identifikation um, die die Puffer-Identifika­ tion (Unique Buffer Identifier) für die entfernt laufende Pro­ zedur und deren Position identifiziert;
"ONCONV4_SERVER" wandelt den als fehlerhaft eingestuften Server (bzw. den als fehlerhaft eingestuften Service-Kommunikations­ pfad) in eine Kommunikationspfad-Identifikation um, die den Servicevorgang und dessen Position identifiziert;
"ONCONV5_SERVICE" wandelt den Service in eine Service-Identifi­ kation um, die den oder die als fehlerhaft eingestuften Ser­ vicevorgänge und dessen bzw. deren Position identifizieren; und
"ONCONV6_PID" wandelt die Prozeßidentifikation PID in eine Pro­ zeß-Identfikation um, die den Prozeßvorgang bzw. den Prozeß in die Service-Bereitstellungs-Einheit SPU (Service Provision Unit) und deren Position identifiziert.

Ein Fehlerhinweis auf ein anderes Programm kann lediglich ge­ meinsam mit einem Aufruf SWERR oder SWINC erfolgen, wobei die jeweilige Umwandlungsroutine direkt in dem Aufruf SWERR oder SWINC enthalten sein muß. Eine Verwendung einer diese Umwand­ lungsroutinen ohne den Aufruf SWERR oder SWINC wird nicht als Fehlermeldung bzw. Fehlerhinweis eingestuft.

Die Tabellen in den Fig. 1 und 2 sind aus sich selbst heraus selbstverständlich und eindeutig, so daß keine nähere Erläute­ rung erforderlich ist. Z. B. wird bei Empfang einer unbekannten Nachricht (s. Fig. 1, erste Spalte "Fehlertyp", zweite Tabel­ lenzeile) die Fehlermeldung SWERR erzeugt und die Umwandlungs­ routine "ONCONV6_PID" benutzt, um den die unbekannte Nachricht erzeugende Prozeß zu identifizieren und dem Betriebssystem zu melden. Weiterhin wird als aktuelle Fehlerkorrektur für diese Fehlermeldung programmseitig die Nachricht einfach ignoriert. Falls demgegenüber der Fehlertype "Vorrübergehende Daten-Fehl­ anpassung" auftritt, wird die Fehlermeldung SWERR erzeugt, je­ doch die Vorgabe-Umwandlungsroutine "ONCONV0_NO_BLAMING" ge­ wählt, so daß in diesem Fall kein Fehlerhinweis auf einen Pro­ zeß erfolgt, da diese Fehlertype keine eindeutige Zuordnung ei­ ner Fehlerquelle erlaubt. Der aktuell ergriffene Korrekturvor­ gang kann hierbei beliebig sein, mit Ausnahme der Einstufung als "Kein Korrekturvorgang möglich". Aus den Tabellen in den Fig. 1 und 2 ist ersichtlich, daß von der Benutzer-Software je­ weils die Fehlermeldungen SWERR oder SWINC erzeugt werden, wo­ hingegen die entsprechenden Fehlermeldungen bei der Supervisor- Software als SUP_SWERR bzw. SUP_SWINC bezeichnet sind. Von der Supervisor-Software können auch noch weitere Fehlermeldungs- Typen erzeugt werden, die jeweils zwingend zu einem partiellen oder vollständigen Rücksetzen und neuen Anlaufen der Prozesse oder des gesamten Prozessors bzw. äußerstenfalls sogar des ge­ samten, mehrere Prozessor-Einheiten umfassenden Prozessorsy­ stems führen.

In Fig. 3 sind die einzelnen Fehlermeldungs-Typen SWERR, SWINC, SUP_SWERR und SUP_SWINC sowie ihre jeweilige Auswirkung und die verwendeten Fehlermeldungstabellen dargestellt.

Vor näherer Beschreibung der Tabelle gemäß Fig. 3 werden die hier verwendeten Begriffe summarisch definiert. Unter "Benut­ zer-Software" bzw. "Benutzer-Programme" sind alle diejenigen Programme zu verstehen, die im Benutzermodus, d. h. auf der In­ terrupt-Ebene Null laufen. "Supervisor-Software" bzw. "Super­ visor-Programme" bezeichnet alle Programme, die in höheren In­ terrupt-Ebenen oberhalb Null laufen (Supervisor-Modus). Unter "Benutzer-Programme" kann hierbei ggf. auch die gesamte Soft­ ware zusammengefaßt sein, die auf einer Plattform in einem elektronischen Wählvermittlungssystem für die Telekommunikation läuft. Solche Benutzer-Programme arbeiten dann unter Einsatz der User-Software und der Supervisor-Software. Weiterhin werden unter "Software-Problemen" alle Softwareprobleme verstanden, die als negatives Resultat einer Überprüfung während der norma­ len Verarbeitung einer Nachricht ermittelt werden, und bewir­ ken, daß die Software die gewünschte Funktion nicht erfüllen kann. Hierbei werden nicht alle Software-Probleme an eine im Prozessor vorgesehene Softwarefehlerbehandlungs-Software (-Ab­ schnitt) gemeldet, sondern können abhängig vom jeweiligen Feh­ lertyp auch an andere, zur Fehlerbehebung oder -registrierung geeignete Komponenten gemeldet werden. Die Erfindung ist hier­ bei derart ausgelegt, daß Benutzer, d. h. mit der Benutzer-Soft­ ware arbeitende Personen oder Geräte, den erkannten Fehler in gewisser Weise durch einen entsprechenden Korrekturvorang neu­ tralisieren müssen (z. B. durch Ignorieren der Nachricht, durch Initialisieren der Daten usw.). Jedoch werden zusätzlich ent­ sprechende Fehlermeldungen erzeugt und in einer entsprechenden Fehlermeldungstabelle aufgelistet (insbesondere in Filter-Sta­ tistiken (Tabellen), globalen Dateien, Archivdateien, usw.).

Mit "Software-Vorfällen" bzw. "Software-Ereignissen" sind Soft­ ware-Probleme gemeint (abgekürzt als SWINC), die durch speziel­ le Systemzustände wie etwa Überlastung, sich überlappende Er­ eignisse usw. hervorgerufen werden und die wahrscheinlich weder durch die Benutzerprogramme selbst noch durch zentralisierte Steuerungsmaßnahmen wie etwa eine Rücksetzung mit erneutem An­ lauf neutralisiert werden können. Software-Ereignisse schließen auch Software-Probleme ein, die keine klaren Software-Fehler sind (z. B. Fälle, bei denen es nicht eindeutig ist, ob sie tat­ sächliche Software-Fehler sind oder aber Fälle, für die aus­ drücklich festgelegt ist, daß eine zentralisierte automatische Fehlerkorrektur in unterschiedlicher Weise als durch Erfassung in einer Fehlermeldungstabelle zu verwirklichen ist). Hierbei kann es sich beispielsweise um Probleme aufgrund nicht ausrei­ chender Systemresourcen handeln. "Software-Fehler" (SWERR) sind Software-Probleme, die der Software-Fehlerbehandlungs-Software gemeldet werden und von Software-Fehlern bei der Codierung oder der Auslegung (z. B. "bugs") herrühren. Die Mitteilung eines Software-Fehlers kann zu einer entsprechenden Fehlerbehandlung durch Rücksetzung führen, wenn sich anhand der Fehlermeldungs­ tabelle ergibt, daß der Fehler wiederholt auftritt.

Bei der Erfindung sind die Programme vorzugsweise derart ausge­ legt, daß sie auch nach Abgabe eines Fehlerhinweises auf einen anderen, wahrscheinlich fehlerhaft arbeitenden Prozeß selbst ungestört weiterarbeiten können, indem sie die empfangene, feh­ lerhafte Nachricht bzw. den anderweitig, erfaßten Software- Fehler entsprechend bewerten, z. B. ignorieren, und dann ihren normalen Betrieb fortsetzen. Ähnliches gilt auch für die Su­ pervisor-Software.

Bei vorliegender Erfindung kann die Fehlermeldung von dem auf­ rufenden Prozeß oder aber von der aufgerufenen Prozedur abgege­ ben werden. Vorzugsweise wird die Fehlermeldung durch den auf­ rufenden Prozeß bei Ermittlung eines Fehlerzustands abgegeben, da der aufrufende Prozeß in der Regel noch zusätzliche Kontext- Informationen zu dem aufgerufenen Prozeß und dem ermittelten Fehler besitzt.

Ferner müssen ungültige Parameter bei einem Aufruf einer Proze­ dur nicht stets durch einen Software-Fehler bedingt sein. Dies kann am besten durch die aufrufende Prozedur bestimmt werden, so daß die Wahrscheinlichkeit der Erzeugung unkorrekter Fehler­ meldungen weiter verringert ist. Ferner wird üblicherweise eine Prozedur mehrfach innerhalb einer Schleife aufgerufen. Wenn diese Prozedur selbst zur Erzeugung der Fehlermeldung benutzt würde, würden bei jeder Schleife wiederholte Fehlermeldungen abgegeben werden, so daß das Betriebssystem stärker belastet würde und nicht unterscheiden kann, ob es sich hierbei jeweils um neue Fehler oder um die Wiederholung eines identischen Feh­ lers handelt. Wenn demgegenüber die aufrufende Prozedur die Fehlermeldung abgibt, kann sie zunächst die erkannten Fehler bzw. Unstimmigkeiten bei jedem Aufruf der aufgerufenen Prozedur sammeln und lediglich nach Abschluß der Schleife eine einzige Fehlermeldung SWERR oder SWINC erzeugen.

Eine Fehlermeldung kann auch dann gebildet werden, wenn eine durch die Benutzer-Software durchgeführte Plausibilitätsüber­ prüfung (Plausi-Check) zu dem Verdacht führt, daß semi-perma­ nente Daten fehlerhaft sind (falls z. B. zwei semi-permanente Werte miteinander Verglichen werden und unerwartet Abweichungen zeigen oder wenn sich ein semi-permanenter Wert außerhalb des zulässigen Bereichs befindet). In diesem Fall gibt das Benut­ zer-Programm eine Fehlermeldung SWERR oder SWINC ab, die ein Problem hinsichtlich der semi-permanenten Daten signalisiert, wobei in diesem Fall diese Daten off-line identifiziert und a­ nalysiert werden können.

Für die Software-Fehlerbehandlungs-Software (SWET) sind somit die folgenden Meldungen bereitgestellt: 1.) "SWINC": dieser Aufruf ermöglicht es der Benutzer-Software, Software-Ereignisse aus der Prozeßebene heraus zu berichten. Hierdurch werden kei­ nerlei Fehlerbehebungsmaßnahmen wie etwa eine Rücksetzung be­ wirkt. Die Software-Fehlerbehandlungs-Software sammelt und speichert in diesem Fall Hinweise, die mit dem gemeldeten Soft­ ware-Ereignis zusammenhängen. Es müssen keine Fehlerstatistiken (Fehlermeldungstabelle) für die gemeldeten SWINCs bereitge­ stellt werden. 2.) "SWERR" bezeichnet einen Aufruf bzw. eine Fehlermeldung, die der Benutzer-Software zum Melden von Soft­ ware-Fehlern aus der Prozeßebene heraus zur Verfügung steht. Hierdurch wird kein sofortiger Erholungsvorgang bewirkt, son­ dern es muß der Benutzer selbst mit dem erfaßten Fehler fertig werden. In diesem Fall sammelt die Software-Fehlerbehandlung- Software Hinweise, die mit dem gemeldeten Software-Fehler zu­ sammenhängen. Der Aufruf enthält die Möglichkeit, andere Benut­ zer-Software (Prozesse) als fehlerhaft mitzuteilen. 3.) Die Meldung "SUP_SWINC" stellt für die Supervisor-Software den gleichen Funktionsumfang bereit wie der Aufruf "SWINC" für die Benutzer-Software. 4.) Ebenso entspricht der Befehl "SUP_SWERR" für die Supervisor-Software dem Funktionsumfang des Aufrufs "SWERR" der Benutzer-Software. In diesem Fall werden ebenfalls viele Statistiken für den gemeldeten Fehler aufgebaut. Falls eine durch die Software-Fehlerbehandlungs-Software definierte Schwelle erreicht wird, wird der gesamte Prozeß rückgesetzt. Auch hier ist die Möglichkeit, auf eine andere, als fehlerhaft eingestufte Software zu zeigen, enthalten.

Wie aus der Tabelle in Fig. 3 ersichtlich ist, sind für die Fehlermeldung SWERR Fehlermeldungstabellen (SWERR-Fehlermel­ dungstabelle) sowie SWERR-Filtertabellen bzw. Filterstatistiken und globale Filterstatistiken, sowie ggf. Fehlerbehebungsstati­ stiken, vorgesehen, die nachstehend unter Bezugnahme auf die Fig. 7 und 8 noch näher erläutert werden. In der linken Spalte in Fig. 3 ist jeweils die Fehlermeldungsart angegeben, während in der zweiten Spalte die mit der Fehlermeldung übersandte spe­ zifische Information dargestellt ist. In der mittleren Spalte ist der minimale Wiederanlaufpegel aufgrund einer Fehlermeldung aufgelistet. Die vierte Spalte gibt an, ob die Fehlermeldungen jeweils einer Filterung unterzogen werden, wobei in der rechten Spalte die jeweils angesprochenen Tabellen bzw. Filter angege­ ben sind. Die Fehlermeldung SWERR enthält nicht nur die eigene Kennung für den meldenden Prozeß, sondern auch die Kennung PID für den als fehlerhaft eingestuften Prozeß. Gleiches gilt auch für die Fehlermeldung SWINC. Die Fehlermeldung SUP_SWERR der Supervisor-Software enthält gleichfalls ihre eigene Kennung so­ wie den Modulnamen, d. h. die Prozeßidentifikation des als feh­ lerhaft eingestuften Moduls. Dies trifft gleichfalls für die Fehlermeldung SUP_SWINC zu. Normalerweise führt keine dieser Meldungen zu einem sofortigen Rücksetzen von Prozessen oder ei­ nem Hochfahren des Prozessors. Wenn jedoch die Anzahl von Feh­ lermeldungen SWERR je PID den intern vorgegebenen Schwellwert überschreitet, wird zunächst der als fehlerhaft gemeldete Pro­ zeß rückgesetzt und die entsprechenden Puffer gelöscht. Falls die gesamte Anzahl von Fehlermeldungen SWERR je Prozessor den Schwellwert überschreiten sollte, werden sämtliche Prozesse dieses Prozessors zurückgesetzt und die entsprechenden Puffer gelöscht. Wie aus Fig. 3 ersichtlich ist, findet eine ähnliche Behandlung auch bei den Fehlermeldungen SUP_SWERR statt. Feh­ lermeldungen SWINC oder SUP_SWINC führen jedoch nicht zu einer Rücksetzung.

In Fig. 4 ist der Informationsfluß bei dem beschriebenen Aus­ führungsbeispiel der vorliegenden Erfindung dargestellt. Die Benutzer-Software 1 erzeugt bei Erkennung eines möglicherweise fehlerhaft arbeitenden Prozesses bzw. eines andersartigen Soft­ ware-Problems eine Fehlermeldung SWERR bzw. eine Problemmeldung SWINC, die einem Software-Fehlerbehandlungs-Abschnitt 4 zuge­ führt wird. In ähnlicher Weise erzeugt die Supervisor-Software 2 die Meldungen SUP_SWERR bzw. SUP_SWINC bei entsprechenden Zu­ ständen in der Supervisor-Ebene, die gleichfalls an den Soft­ ware-Fehlerbehandlungs-Abschnitt 4 geleitet werden. Diese Hin­ weise werden in entsprechenden Meldungstabellen in dem Soft­ ware-Fehlerbehandlungs-Abschnitt 4 gespeichert, der nachfolgend noch näher beschrieben werden, wonach der Ablauf wieder zu der meldenden Benutzer-Software bzw. ggf. der meldenden Supervisor- Software zurückkehrt, sofern die Anzahl der auf einen bestimm­ ten Prozeß hinweisenden oder von einem bestimmten Prozeß stam­ menden Fehlermeldungen noch nicht den Schwellwert erreicht hat. Wenn der Schwellwert demgegenüber erreicht wird, fordert der Software-Fehlerbehandlungs-Abschnitt 4 je nach Art des mehrfach gemeldeten Fehlers entweder eine vollständige Rücksetzung der gesamten Software in einer Verarbeitungsplattform des Wählver­ mittlungssystems an, oder beginnt zunächst mit einer Rückset­ zung lediglich des als fehlerhaft gemeldeten Prozesses, oder aller Prozesse dieses Prozessors, was durch eine Anlauf-Soft­ ware 5 bewerkstelligt wird. Weiterhin ist eine zusätzliche Da­ tenaufzeichnungs-Software 6 zum Registrieren von begleitenden Fehlerindizien vorgesehen, die bei Bedarf von der Software- Fehlerbehandlungs-Software 4 getriggert wird und die von ihr gesicherten Fehlerindizien-Daten an die Software-Fehlerbehand­ lungs-Software 4 für eine dortige Speicherung weiterreicht.

Fig. 5 zeigt den Fall der Behandlung einer Fehlermeldung SWERR, die keine Rücksetzung des Prozesses oder sonstiger Prozesse er­ fordert. Hierbei sind einzelnde Unterabschnitte der Software- Fehlerbehandlungs-Software 4 sowie deren Zuordnung zur Benut­ zer-Ebene bzw. zur Supervisor-Ebene in größeren Einzelheiten gezeigt, nämlich der Ausgabeabschnitt 8, eine Report-Schnitt­ stelle 9, eine lokale Steuereinrichtung 10, ein Abschnitt 11 zur Speicherung und Bewertung von Fehlermeldungen, der die Feh­ lermeldungstabellen enthält, und ein Abschnitt 12 zur Sammlung von Fehlerindizien.

Wenn ein Prozeß X (Bezugszeichen 7) eine Fehlermeldung SWERR erzeugt, wird diese über die Schnittstelle 9 in den Software- Fehlerbehandlungs-Abschnitt 4 aufgenommen, der dann diese Feh­ lermeldung sowie zugehörige Parameter usw. an die lokale Steu­ ereinrichtung 10 abgibt. Die Fehlermeldung wird daraufhin von dieser Steuereinrichtung 10 zusammen mit einer entsprechenden Fehlerereigniskennung und der Prozeßkennung PID des Prozesses X für den meldenden Prozessor an den Abschnitt 11 weiterleitet. Da bei vorliegendem Fall angenommen wird, daß kein Prozeß-Neu­ start oder eine sonstige Fehlerbehebungsmaßnahme erforderlich ist, gibt der Abschnitt 11 an die Steuereinrichtung 10 die In­ formation zurück, daß keine Rücksetzung erforderlich ist. Wei­ terhin enthält die abgegebene Meldung auch einen Hinweis über die Tatsache, ob eine Filterung der Daten vorgenommen worden ist, und eine kurze Information über den Grund für die getrof­ fene Entscheidung. Diese Daten können für eine spätere, verbes­ serte Fehleranalyse an den Abschnitt 12 fakultativ weitergelei­ tet werden, wonach der Programmablauf dann wieder zu der loka­ len Steuereinrichtung 10 zurückkehrt. Von der Steuereinrichtung 10 wird schließlich zu dem aufgerufenen Prozeß X zurückgekehrt, so daß der durch die Fehlermeldung SWERR ausgelöste Verarbei­ tungsablauf abgeschlossen ist.

In Fig. 6 ist der alternative Fall gezeigt, daß eine Fehlermel­ dung SWERR erzeugt wird, die aufgrund des Erreichens des Feh­ lermeldungs-Schwellwerts zu einem Rücksetzvorgang führt. Bei dem Prozeß X kann es sich hierbei wie bei Fig. 5 um den die Fehlermeldung erzeugenden Prozeß oder um denjenigen Prozeß han­ deln, der von dem meldenden Prozeß als fehlerhaft bezeichnet wird.

Da in diesem Fall eine Prozeß-Rücksetzung durchgeführt wird, sind Programme 13 und 14 für die Durchführung der Rücksetzung und des Neubeginns für den Benutzer-Modus bzw. für den Supervi­ sor-Modus gezeigt. Die obere Hälfte des Ablaufs gemäß Fig. 6 ist identisch mit demjenigen gemäß Fig. 5, mit der einzigen Ausnahme, daß von dem Abschnitt 11 nun als notwendige Reaktion die Rücksetzung des Prozesses X an die Steuereinrichtung 10 ge­ meldet wird. Genauer gesagt, wird von dem Abschnitt 11 eine Meldung an die Steuereinrichtung 10 abgegeben, die die An­ laufebene vorgibt, die hier zunächst lediglich in einer Rück­ setzung des Prozesses X besteht. Statt der als letzten Schritt gemäß Fig. 5 vorgesehenen Rückkehr zu dem aufrufenden Prozeß X wird nun gemäß Fig. 6 von der Steuereinrichtung 10 ein Trigger- Ausgangssignal sowie eine Anforderung "Rücksetzen des Prozesses X" an den Anlaufabschnitt 14 abgegeben, der daraufhin den Pro­ zeß X über das Betriebssystem anhält und anschließend erneut startet. Nach dem Neustart des Prozesses X wird überprüft, ob die Rücksetzung erfolgreich war, und, falls dies nicht der Fall gewesen sein sollte, der Software-Fehlerbehandlungs-Abschnitt 4 entsprechend informiert, was zu einer Aktualisierung der Feh­ lermeldungstabellen und zu der Festlegung eines erforderlichen, umfangreicheren Rücksetzschritts, bis hin zu einem Wiederanlauf des gesamten Prozessors oder sogar des übergeordneten Prozes­ sorsystems führt.

Hierbei bestimmt der Abschnitt 11 allgemein die durchzuführende Anlaufstufe für die Fehlermeldungen sowie die Filterinformati­ on, die für die Sammlung von Fehlerindizien eingesetzt wird. Weiterhin enthält der Abschnitt 11 mindestens eine Fehlermel­ dungstabelle zur statistischen Zählung von Fehlermeldungen über jeweils vorbestimmte Zeitabschnitte hinweg, die als Überwa­ chungsintervalle festgelegt sind. Falls der Zählstand eines Zählers für einen jeweiligen Prozeß einen vorbestimmten Wert erreicht oder überschreitet, wird dies als Erreichen des Schwellwerts eingestuft. Wenn ein solcher Schwellwert erreicht ist, wird eine Entscheidung hinsichtlich der Anlaufstufe und der einzusetzenden Filter getroffen.

Hierbei erhält der Abschnitt 11 von der Steuereinrichtung 10 die Fehlermeldungsinformation, die aus einer Ereigniskennung, der Meldungsart, der minimalen Anlaufstufe und einer Zeitangabe usw. besteht. Die Zeitangabe ist ein relativer Zählwert mit ei­ ner Stufung von 1 ms. Abhängig von der Fehlerart wird ein mini­ mal erforderlicher Anlaufpegel auf alle Fehlermeldungen ange­ wendet, die eine sofortige Erholungsreaktion erfordern. Diese minimale Anlaufstufe wird von der Steuereinrichtung 10 zum Ab­ schnitt 11 gemeldet. Hingegen werden alle Fehlermeldungen, die keine unmittelbare Rücksetzungsaktion erfordern (SWERRs und SUP_SWERRs), in der speziellen Fehlermeldungstabelle gezählt, wobei die Fehlermeldungstabellen für die Fehlermeldungen SWERR auf der Prozeßkennungs-Basis (PID-Basis) und für Fehlermeldun­ gen SUP_SWERR auf der Modulnamen-Basis geführt werden. Falls ein Zähler für die Fehlermeldungen SWERR oder SUP_SWERR eines Prozesses einen Schwellwert erreicht, wird diesen Fehlermeldun­ gen eine minimale Anlaufstufe zugeordnet, wie sie in Fig. 3 dargestellt ist. Alle durch eine Prozeßkennung charakterisier­ ten Fehlermeldungen SWERR werden somit in dieser Prozeßkennung jeweils zugeordneten PID-Zählern gezählt. Fehlermeldungen SUP_SWERR werden in der gleichen Weise verarbeitet. Falls eine Fehlermeldung SUP_SWERR eine auf einen als vermutlich fehler­ haft eingestuften Prozeß hinweisende Prozeßkennung PID enthält, wird hierbei auch der Zähler für die Prozeßkennung PID in der SWERR Fehlermeldungstabelle erhöht. Zusätzlich werden alle Feh­ lermeldungen SWERR oder SUP_SWERR jeweils für den gesamten, je­ weils zugeordneten Prozessor aufsummiert.

Die letztendlich für die Fehlerbehebung zu wählende Anlaufstufe wird auch anhand von Anlauf-Tabellen überprüft, die statisti­ sche Informationen und die Historie für die früheren Fehlerbe­ hebungsversuche und hierbei eingesetzten Anlaufstufen enthält. Weiterhin sind für die Fehlermeldungstypen SWERR, SUP_SWERR, SWINC und SUP_SWINC jeweils spezielle Filtertabellen vorgese­ hen, die Filter für die Sammlung von Fehlerindizien für die bessere Fehlererkennung bereitstellen. Falls ein Filter aktiv ist, werden keine Fehlerindizien für diese Fehlermeldungen ge­ sammelt, so daß die Anzahl von Fehlerindizien begrenzt wird. In den Filtertabellen werden die Fehlermeldungen je Prozeßidenti­ fikation PID bzw. je Modulname während eines Überwachungsinter­ valls gezählt und Filter aktiviert, falls vorgegebene Schwell­ werte erreicht werden. Ein globales Filter wird aktiviert, falls die Anzahl von Fehlermeldungen bei einem der jeweiligen Fehlermeldung-Typen den für dieses Filter vorgesehenen Schwell­ wert während des Übergangsintervalls erreicht, so daß dann kei­ ne Fehlerindizien mehr gesammelt werden.

In Fig. 7 ist in Form eines schematischen Ablaufdiagramms die Arbeitsweise eines Ausführungsbeispiels eines erfindungsgemäßen Verfahrens dargestellt, das in dem Abschnitt 11 abläuft. Bei Empfang einer Fehlermeldung wird in einem Schritt I das Ereig­ nis klassifiziert und der Fehlermeldungs-Typ identifiziert so­ wie überprüft, ob ein Anlaufvorgang erforderlich ist. Hierbei ist im Fall einer Fehlermeldung SWINC oder SUP_SWINC niemals ein Anlaufvorgang erforderlich. Im Fall einer Fehlermeldung SWERR oder SUP_SWERR wird die Prozeßkennung PID oder der Modul­ name und die Zeitangabe an die entsprechende Fehlermeldungsta­ belle (Statistik) übergeben, die eine Rückmeldung erzeugt, falls die vorgesehene Schwelle für diese Prozeßkennung PID oder den Modulnamen erreicht ist, was bedeutet, daß ein Anlaufvor­ gang für diese Fehlermeldung erforderlich ist. Falls eine Feh­ lermeldung SUP_SWERR eine auf einen als fehlerhaft gemeldeten Prozeß hinweisende Prozeßkennung enthält, wird der für diesen gemeldeten Prozeß in der Fehlermeldungstabelle gespeicherte Wert aufgerufen, um hierdurch zu überprüfen, ob für diesen ge­ meldeten Prozeß der Schwellwert erreicht ist. Bei allen anderen Fehlermeldungs-Typen wird stets ein Anlaufvorgang durchgeführt. Falls keine gültige Zeitangabe zur Verfügung steht, wird die von einem früheren Aufruf des Abschnitts 11 stammende, zuletzt gültige Zeitangabe, sofern möglich, benutzt, oder es wird die Zeitangabe "0" hinzugefügt.

Bei einem Schritt II wird die minimale Anlaufstufe für eine ei­ nen Anlauf erfordernde Fehlermeldung anhand der in Fig. 3 dar­ gestellten Tabelle ermittelt.

In einem Schritt III wird anhand der bisherigen Anlaufvorgänge und Anlauf-Statistik die tatsächlich zu wählende Anlaufstufe festgelegt.

In einem Schritt IV werden dann für die jeweilige Fehlermeldung SWERR, SWINC, SUP_SWERR oder SUP_SWINC die entsprechenden Fil­ ter-Statistiken (Filter-Tabellen) für die Gewinnung von zusätz­ lichen Fehlerindizien ausgewählt. Am Ende der festgelegten An­ laufstufe werden Informationen über die gewählten Filter und die Entscheidungsgründe, die die Gründe für die Auswahl des Filters und der Anlaufstufe enthalten, zu der Steuereinrichtung 10 zurückgemeldet.

Die Fehlermeldungstabellen für die Fehlermeldung SWERR erhalten von dem Abschnitt 11 jeweils die Prozeßkennung PID und die Zeitangabe einer Fehlermeldung SWERR als aktuelle Zeitangabe, wobei anhand dieser Werte ermittelt wird, ob für diese spezifi­ sche Fehlermeldung ein spezifischer Wert für diese Prozeßken­ nung oder den gemeldeten Prozessor erreicht ist. Das Ermitt­ lungsergebnis wird zum Abschnitt 11 gemeldet.

Die Fehlermeldungstabelle für die Fehlermeldungen SWERR ist auf der Basis der Prozeßkennungen PID mit dem in Fig. 8 gezeigten Aufbau organisiert. Die in Fig. 8 gezeigte Fehlermeldungstabel­ le ist in Form von PID-Elementen 20, 21, 22 usw. aufgebaut, die jeweils einem gemeldeten Prozeß zugeordnet sind. Wie in Fig. 8 weiter gezeigt ist, ist auch eine Fehlermeldungstabelle für den gesamten Prozessor vorgesehen, in dem alle Fehlermeldungen SWERR für den jeweiligen Prozessor gespeichert werden.

Bei dem gezeigten Ausführungsbeispiel kann die Fehlermeldungs­ tabelle für die Fehlermeldungen SWERR bis zu 100 Fehlermeldun­ gen SWERR für unterschiedliche Prozeßkennungen PID speichern. Ein Tabellenelement für eine Prozeßkennung PID wird hierbei le­ diglich dann belegt, wenn eine Fehlermeldung SWERR für diese Prozeßkennung aktiv ist, d. h. mindestens einmal gemeldet wurde.

Wie aus Fig. 8 ersichtlich ist, enthält die Fehlermeldungsta­ belle für jede erfaßte Prozeßkennung PID ein PID-Element 20, 21, 22 usw. jeweils mit einer Reihe von Zeitangaben. Die Zeit­ angabe für jede Fehlermeldung SWERR wird gespeichert und dann mit dem Überwachungsintervall überprüft. Die Anzahl von Fehler­ meldungen SWERR, die während eines jeweiligen Überwachungsin­ tervalls aufgetreten sind, wird automatisch unter Aufsummierung der Anzahl von für diesen Prozeßkennung PID gespeicherten Zeit­ angaben ermittelt. Zusätzlich zu den Zeitangaben kann darüber­ hinaus auch noch der Task-Zähler der entsprechenden Prozeßken­ nung PID gespeichert werden. Dies kann zur Unterscheidung zwi­ schen "schnellen" Prozessen (die eine große Menge von Nachrich­ ten je Sekunde handhaben) und "langsamen" Prozessen vorgesehen sein. Jedes Mal dann, wenn ein Zugriff zu einem Element (für die Speicherung oder für ein Lesen) erforderlich ist, überprüft der Abschnitt 11 zunächst alle bereits vorhandenen Elemente, um zu ermitteln, ob für die angegebene Prozeßkennung PID bereits ein PID-Element vorgesehen ist, oder um andernfalls ein freies Element zu finden. Hierbei werden ältere Tabellenelemente, die außerhalb des Überwachungsintervalls liegen, d. h. noch von ei­ nem früheren Überwachungsintervall herrühren, gelöscht.

Die älteste Zeitangabe der Tabelle für die fragliche Prozeßken­ nung PID wird mit dem Überwachungsintervall verglichen und dann gelöscht, wenn die nachstehend angegebene Bedingung erfüllt ist:

(Zeitangabe_aktuell - Zeitangabe_älteste) < Überwachungsintervall.

Dieser Vorgang wird solange wiederholt, bis die älteste Zeitan­ gabe nicht länger die Bedingung erfüllt. Bei Auftreten einer neuen Fehlermeldung wird somit das Überwachungsintervall für die fragliche Prozeßkennung PID auf die aktuellste Zeitangabe bezogen und alle älteren Meldungen außerhalb dieses Überwa­ chungsintervalls beseitigt. Für jede neue Fehlermeldung SWERR wird für die entsprechende Prozeßkennung PID die entsprechende Zeitangabe in der Tabelle gespeichert. Falls es die erste Feh­ lermeldung SWERR für diese spezielle Prozeßkennung PID sein sollte, wird ein neues PID-Element zugeordnet.

Die Anzahl von jeweils vorhandenen Zeitangaben für die speziel­ le Prozeßkennung PID wird (nach der Beseitigung der älteren Zeitangaben außerhalb des Überwachungsintervalls) mit einem vorbestimmten Wert verglichen. Wenn sich hierbei ergibt, daß der Schwellwert erreicht ist, wird der Abschnitt 11 informiert.

Zusätzlich zu der Überprüfung, ob eine "normale" Schwelle er­ reicht worden ist, findet eine spezielle Überprüfung statt, ob mehr als z. B. 10 Ereignisse innerhalb des Überwachungsinter­ valls vorliegen. Bei dieser Überprüfung wird der Task-Zähler benutzt, um zu erkennen, wieviele Tasks dieser Prozeß innerhalb des Überwachungsintervalls gehandhabt hat. Falls sich ergibt, daß mehr als 40% der Tasks zu Fehlermeldungen SWERR geführt ha­ ben, wird der Abschnitt 11 darüber informiert, daß dieser Schwellwert erreicht ist, so daß entsprechend angepaßte Gegen­ maßnahmen ergriffen werden können.

Die Fehlermeldungstabellen für die Fehlermeldungen SUP_SWERR sind auf der Grundlage von Modulnamen organisiert, ansonsten aber gleichartig aufgebaut und strukturiert, wie es in Fig. 8 gezeigt und vorstehend erläutert ist.

Claims (9)

1. Verfahren zur Fehlererkennung in einem mit mehreren Program­ men arbeitenden, mindestens einen Prozessor enthaltenden Pro­ zessorsystem, bei dem Programme Informationen, die sie von ei­ nem anderen Programm zur Weiterverarbeitung erhalten, einer Überprüfung, insbesondere einer Plausibilitätsüberprüfung, un­ terziehen, und, wenn die Überprüfung auf einen Fehler in den empfangenen Informationen hinweist, dieses die empfangenen In­ formationen erzeugende Programm als fehlerhaft einstufen und eine Fehlermeldung (SWERR) an das Betriebssystem des zugehöri­ gen Prozessors abgeben, und das Betriebssystem mindestens eine Fehlermeldungstabel­ le enthält, in der bei Empfang einer Fehlermeldung (SWERR) In­ formationen über das als fehlerhaft eingestufte Programm regi­ striert werden.

2. Verfahren nach Anspruch 1, bei dem in der Fehlermeldungsta­ belle bei Auftreten von Fehlermeldungen auch Informationen über das jeweilige Programm, das die Fehlermeldung erzeugt hat, ge­ speichert werden.

3. Verfahren nach Anspruch 1 oder 2, bei dem das Betriebssystem in der Fehlermeldungstabelle die Anzahl der Fehlermeldungen se­ lektiv für die jeweils als fehlerhaft eingestuften Programme, und ggf. auch für die jeweils meldenden Programme, speichert.

4. Verfahren nach Anspruch 3, bei dem das Betriebssystem Feh­ lermeldungen, die bereits länger als ein bestimmtes Überwa­ chungszeitintervall zurückliegen, löscht.

5. Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Betriebssystem dann, wenn die für ein fehlerhaft eingestuf­ tes Programm gespeicherte Anzahl von Fehlermeldungen, bzw. ggf. die Anzahl von für ein meldendes Programm gezählten, von diesem abgegebenen Fehlermeldungen, einen Schwellwert erreicht, eine Fehlerbehebungsmaßnahme, insbesondere eine Rücksetzung dieses Programms, veranlaßt.

6. Verfahren nach einem der vorhergehenden Ansprüche, bei dem bei einem System mit mehreren Prozessoren oder Prozessor- Plattformen das Betriebssystem bei einer Fehlermeldung eines von ihm verwalteten Programms, die auf ein als fehlerhaft ein­ zustufendes, aber auf einem anderen Prozessor ausgeführtes Pro­ gramm hinweist, an diesen anderen Prozessor eine auf das als fehlerhaft eingestufte Programm hinweisende Information und/oder die diesbezüglichen, in der eigenen Fehlermeldungsta­ belle gespeicherten Informationen abgibt.

7. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Fehlermeldung eine Mitteilung an das Betriebssystem ent­ hält, die das Betriebssytem bei Erhalt dieser Mitteilung dazu veranlaßt, Informationen, die den als fehlerhaft eingestuften Informationen hinzugefügt sind, insbesondere in Form eines Hea­ ders, und die das als fehlerhaft einzustufende Programm kenn­ zeichnen, zu lesen.

8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß das Betriebssystem diese den als fehlerhaft einzustufenden Prozeß kennzeichnenden Informationen entweder zu den meldenden Prozeß rücküberträgt und dann von diesem in der Form der Fehlermeldung zurückerhält, oder aber direkt für einen entsprechenden Eintrag in der Fehlermeldungstabelle auswertet.

9. Verfahren nach einem der vorhergehenden Ansprüche, bei dem in der Fehlermeldungstabelle Prozeßkennungen für gemeldete Pro­ zesse zusammen mit einer den Zeitpunkt des jeweiligen Auftre­ tens der zugehörigen Fehlermeldungen charakterisierenden Zeit­ angabe gespeichert werden.