DE19633002C2 - Verfahren und Datenverarbeitungssystem zum Behandeln von Fehlern - Google Patents

Description

Die vorliegende Erfindung bezieht sich allgemein auf ein ver­ bessertes Datenverarbeitungssystem und insbesondere auf ein verbessertes Verfahren zum Behandeln von Fehlern in einem Da­ tenverarbeitungssystem. Noch genauer bezieht sich die vorlie­ gende Erfindung auf ein verbessertes Verfahren und eine ver­ besserte Einrichtung zum Behandeln von Fehlern, die auftre­ ten, wenn eine Vielzahl von Objekten als Antwort auf eine An­ forderung aufgerufen werden.

Die Entwicklung von Anwendungs- und Systemsoftware für Daten­ verarbeitungssysteme ist traditionell eine zeitraubende Auf­ gabe gewesen. Das Gebiet der Softwaretechnik (Softwareengin­ eering) hat versucht, die Beschränkungen der traditionellen Verfahren durch Vorschlagen neuer, leistungsfähigerer Modelle zur Softwareentwicklung zu überwinden. Objektorientiertes Pro­ grammieren ist als eine vielversprechende Technologie aufge­ taucht, die eine schnelle Entwicklung, Implementierung und Kundenanpassung von Objekten erlaubt. Jedes neue Objekt hat bestimmte Datenattribute und Prozesse oder Verfahren, die auf diese Daten wirken. Daten werden als "eingekapselt" durch ein Objekt angesehen und können nur durch die zu Hilfe gerufenen Objektverfahren modifiziert werden durch Schicken einer Nach­ richt an ein Objekt, das das Verfahren identifiziert und die benötigten Argumente liefert.

Objektorientierte Systeme haben zwei wichtige Eigenschaften zusätzlich zu der Einkapselung. "Vererbung" ist die Fähigkeit, ein neues Objekt von einem vorhandenen Objekt abzuleiten und alle Eigenschaften, einschließlich der Verfahren und Daten­ strukturen von dem vorhandenen Objekt zu erben. Das neue Ob­ jekt kann bestimmte, eindeutige Merkmale aufweisen, die als Außerkraftsetzungen oder Modifikationen der vorhandenen Klasse geliefert werden. Zum Beispiel muß eine neue Unterklasse nur die Funktionen und Daten angeben, die diese Klasse von der existierenden allgemeineren Klasse unterscheiden.

Die Fähigkeit, eine vorhandene Verfahrensbeschreibung außer Kraft zu setzen, ermöglicht Polymorphismus, die Fähigkeit, daß eine einzelne Nachricht, die von einem Objekt empfangen wird, auf unterschiedliche Weisen, abhängig von dem Objekt selbst, verarbeitet wird.

Vererbung und Polymorphismus schaffen eine mächtige Struktur für das Implementieren neuer Softwaresysteme. Der Softwareent­ wickler muß nicht jedes Stück eines Systems entwickeln, er oder sie muß nur die eindeutigen Merkmale des Systems angeben.

Die Arbeitsleistung von objektorientierten Systemen wird durch die Entwicklung von System-"Rahmen" verwirklicht. Ein Rahmen ist eine Sammlung von Basisklassen, die von einem System­ hersteller benutzt werden können, um ein endgültiges System­ produkt zu schaffen. Der Rahmen wird definiert und entwickelt, um als ein System zusammenzuarbeiten. Begrifflich ist der Rah­ men einem Satz von Standardhardwarekomponenten vergleichbar, die von den Herstellern der Computerhardware benutzt werden. Jede der Komponenten hat bestimmte definierte Funktionen und Schnittstellen, und der Ingenieur setzt diese Komponenten ge­ mäß einem speziellen Entwurf zusammen, um ein eindeutiges Hardwaresystem zu schaffen. Mehr Informationen über objektori­ entierte Systeme findet man in Booch, Object Oriented Design With Applications, Benjamin/Cummings Publishing Company, Inc. (1991).

Ein objektorientiertes Programmiersystem ist das Systemobjekt­ modell (SOM). Weitere Informationen über SOM findet sich in SOMObjects Developer Toolkit Users's Guide, Version 2.0, Juni 1993, erhältlich von der International Business Machines Cor­ poration.

In heutigen Computersoftware-Umgebungen wird Code unter Benut­ zung eines modularen Weges entwickelt, wann immer möglich. Zu­ künftige Software-Umgebungen werden fortfahren, einen modula­ ren Weg zu benutzen, was das Konzept der wiederverwendbaren Softwarekomponenten ergibt. Diese Wiederverwendbarkeit umfaßt viele konkurrierende Schichten, beginnend mit dem Betriebssy­ stem, sich aufwärts bewegend durch die Netzwerktransport­ schichten, durch die Schichten für verteiltes Rechnen und schließlich in die Anwendungskomponenten wie Korrekturhilfen, Suchmaschinen und Datenbanken.

In Umgebungen für verteiltes Rechnen, abgekürzt als (DCE = Dis­ tributed Computing Envirenment) können verschiedene Software­ komponenten auf mehr als einem physikalischen System sich be­ finden, wie z. B. auf einer Anzahl von Computern in einem Sy­ stem für verteilte Datenverarbeitung. Beispiele solcher Dienste schließen die Sicherheit, das Verzeichnis und Zeit­ dienste ein. Diese verschiedenen Komponenten benutzen die Dienste jeder der anderen, indem sie interne Aufrufe für ein­ ander machen (in der Form von Nachrichten, die von einem Ob­ jekt zum anderen Objekt geschickt werden,) als ein Weg zur Be­ friedigung einer Anforderung nach einem speziellen Dienst. Wenn z. B. eine Anwendung eine Sicherheitskomponente aufruft und das Hinzufügen eines neuen Benutzers zu der Datenbank für die Sicherheitsregistrierung anfordert, hat die Nachricht, die ein Hinzufügen eines neuen Benutzers anfordert, zur Folge, daß andere Nachrichten zu anderen Teilender Sicherheitskomponente geschickt werden, um zu prüfen, daß die Komponente, die diese Anforderung machte, berechtigt ist, neue Benutzer zu der Da­ tenbank hinzuzufügen, die wiederum eine Komponente für den Aufruf einer Fernprozedur, abgekürzt als (RPG = Remote Pro­ cedure Call) benutzt, um diese Anforderungen zu der geeigneten Funktion zu übertragen.

Solch eine Umgebung mit einer Komponente modularer Software liefert den Programmierern saubere, wohldefinierte Schnitt­ stellen für das Anfordern von Funktionen, die von einer Anwen­ dung benötigt werden. Ein Problem tritt jedoch auf, wenn ein Aufruf einer dieser Komponenten eine Nachricht zu dem Aufru­ fenden zurückschickt, die durch eine Komponente erzeugt wird, die nicht direkt durch den Programmierer oder Benutzer aufge­ rufen wurde, sondern durch irgendeine andere Komponente, die aufgerufen wurde, um die Anforderung des Programmierers zu er­ ledigen. In solch einem Fall kann die Nachricht, die zu dem Programmierer oder Benutzer zurückgeschickt wird, irreführend sein, da sie nicht Informationen zurückschickt, die von dem Programmierer oder Benutzer erwartet werden. Die Kette von Aufrufen für verschiedene Komponenten kann in manchen Fällen lang sein, in denen irgendeine der aufgerufenen Komponenten in der Kette von Aufrufen eine Fehlernachricht zurückschicken kann.

In einigen Fällen, wie z. B. Code der Benutzerschnittstelle möchte der Aufrufer der unterliegenden Softwarekomponenten alle die Probleme identifizieren, die bei der Dateneingabe durch den Endbenutzer gefunden wurden. Wenn z. B. beim Zurück­ kehren zu der Situation, in der ein Aufruf gemacht wird, einen neuen Benutzer der Datenbank für die Sicherheitsregistrierung hinzuzufügen, werden verschiedene Eigenschaften über den Be­ nutzer (d. h. Name, Adresse, Ort und Telefon) der Benutzer­ schnittstelle eingegeben. Nachdem die gesamten Daten eingege­ ben wurden, werden sie gespeichert und verarbeitet. Wenn Pro­ bleme bei der Gültigkeitsprüfung bei einer oder mehreren der Eingaben auftreten, ist es erwünscht, dem Benutzer, der die Informationen zu einem Zeitpunkt eingibt, Informationen über alle Probleme zu liefern anstatt den Benutzer aufzufordern, ein Problem zu bestimmen, es zu speichern und ihm dann ein anderes zu bestimmendes Problem zu präsentieren.

US Patent 5,175,735 beschreibt eine Methode und Vorrichtung zum Behandeln von Fehlern in einem Drucksystem. Das System überwacht die einzelnen Jobs auf Softwareobjektfehler. Wenn ein solcher Fehler gefunden wird, wird der Administrator vor Verarbeitung dieses Softwareobjekts informiert. Eine weitere Ausführungsvariante besteht darin, dass Softwareobjekte auch ohne Intervention des Administrators korrigiert und danach erst verarbeitet werden.

Es ist Aufgabe der vorliegenden Erfindung, ein verbessertes Verfahren und eine verbesserte Einrichtung zum Behandeln von Fehlern anzugeben, die auftreten, wenn eine Vielzahl von Objekten als Antwort auf eine Anforderung aufge­ rufen werden.

Die vorliegende Erfindung gibt ein Verfahren und ein Datenver­ arbeitungssystem zum Behandeln von Fehlern an, die während einer Verarbeitung einer Vielzahl von Objekten in einer ob­ jektorientierten Umgebung auftreten. Gemäß der vorliegenden Erfindung wird eine Nachricht eines Objektes empfangen, für das die Nachricht das Verarbeiten durch eine Vielzahl von Ob­ jekten anfordert. Fehlerinformation wird in eine Datenstruktur als Antwort auf jedes Auftreten eines Fehlers in jedem der Vielzahl von Objekten gespeichert. Diese Datenstruktur wird zu dem Objekt zurückgeschickt.

Die Merkmale und Vorteile der vorliegenden Erfindung werden aus der folgenden detail­ liert verfaßten Beschreibung offensichtlich.

Die neuen Merkmale, die als charakteristisch für die Erfindung angesehen werden, werden in den angefügten Ansprüchen dargelegt. Die Erfindung selbst jedoch, sowie auch eine bevor­ zugte Art der Benutzung, weitere Ziele und Vorteile von ihr werden am besten durch Bezugnahme auf die folgende detaillier­ te Beschreibung eines erläuternden Ausführungsbeispieles ver­ standen, wenn es in Verbindung mit den zugehörigen Zeichnungen gelesen wird, in denen:

Fig. 1 ein Datenverarbeitungssystem in der Form eines Personalcomputers veranschaulicht, in dem die vorliegende Erfindung benutzt werden kann,

Fig. 2 ein Blockdiagramm eines Personalcomputersystems ist, das die verschiedenen Komponenten eines Personalcomputersystems gemäß der vorliegenden Erfindung veranschaulicht,

Fig. 3 ein Diagramm von Objekten in einem objektorientierten System ist, das gemäß einem bevorzugten Ausführungsbeispiels der vorliegenden Erfindung veranschaulicht ist,

Fig. 4A ein Blockdiagramm eines Klientenobjektes CO, eines Objektes A, eines Objektes B und eines Objektes C gemäß der vorliegenden Erfindung ist,

Fig. 4B ein Diagramm eines Klientenobjektes CO, eines Objektes A, eines Objektes B, eines Objektes C und eines Objektes D gemäß der vorliegenden Erfindung ist,

Fig. 5 ein Diagramm von Datenstrukturen ist, die einen Mechanismus für das Melden von Fehlern oder von Ausnahmebedingungen gemäß der vorliegenden Erfindung veranschaulichen,

Fig. 6 ein Flußdiagramm eines Prozesses zum Behandeln von Ausnahmebedingungen ist, die in einer horizontalen Weise auftreten gemäß einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung,

Fig. 7 ein Flußdiagramm eines Prozesses ist zum Behandeln von Ausnahmebedingungen, die in einer vertikalen Weise gemäß einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung auftreten, und

Fig. 8 ein Flußdiagramm eines Prozesses des Objektes einer Ausnahmebedingung ist, das verwendet wird, um die Datenstrukturen eines Stapels von Ausnahmebedingungen gemäß dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung zu bearbeiten.

Es wird jetzt auf die Zeichnungen und insbesondere auf Fig. 1 Bezug genommen. Dort ist ein Datenverarbeitungssystem, ein Personalcomputersystem 10, dargestellt, in dem die vorliegende Erfindung verwendet werden kann. Wie dargestellt umfaßt das Personalcomputersystem 10 eine Reihe von Komponenten, die un­ tereinander verbunden sind. Genauer ist eine Systemeinheit 12 mit einem Monitor 14, (wie z. B. einem üblichen Videoanzeigegerät,) verbunden und kann ihn steuern. Eine Systemeinheit 12 kann auch wahlweise mit Eingabegeräten verbunden sein, wie zum Beispiel einer PC-Tastatur 16 oder einer PC Maus 18. Die PC Maus 18 schließt (nicht dargestellte) rechte und linke Tasten ein. Die linke Taste wird allgemein als Hauptauswähltaste verwendet, und auf sie wird alternativ Bezug genommen als auf die erste Taste der Steuerkugel oder die Taste 1 der PC Maus. Die rechte Taste wird typischerweise benutzt, um Hilfsfunktionen auszuwählen, wie das später erläutert wird. Auf die rechte Taste der Maus wird alternativ Bezug genommen als auf die zweite Taste der Maus oder die Taste 2 der Maus. Ein Ausgabegerät, wie zum Beispiel ein Drucker, kann ebenfalls mit der Systemeinheit 12 verbunden sein. Schließlich kann die Systemeinheit 12 einen oder mehrere Massenspeichergeräte einschließen, wie zum Beispiel das Diskettenlaufwerk.

Wie unten beschrieben wird, antwortet die Systemeinheit 12 auf Eingabegeräte, wie zum Beispiel die PC-Tastatur 16, die Steu­ erkugel 18 oder die Schnittstellen lokaler Netzwerke. Außerdem sind Eingabe-/Ausgabe (E/A)-Geräte wie zum Beispiel ein Dis­ kettenlaufwerk, eine Anzeigeeinheit 14, ein Drucker und ein lokales Netzwerk als Nachrichtenübertragungssystem mit der Systemeinheit 12 in bekannter Weise verbunden. Natürlich sind sich die Fachleute bewußt, daß andere übliche Komponenten auch mit der Systemeinheit 12 zur Interaktion mit ihr verbunden sein können. Gemäß der vorliegenden Erfindung schließt das Personalcomputersystem 10 einen Systemprozessor ein, der mit einem Speicher für wahlfreien Zugriff, abgekürzt als (RAM = Random Access Memory), einem Festwertspeicher, abgekürzt als (ROM = Read Only Memory) und einer Vielzahl von E-/A-Geräten verbunden ist.

Für normalen Gebrauch kann das Personalcomputersystem 10 so entworfen werden, daß es unabhängige Rechenleistung einer kleinen Gruppe von Benutzern als Server oder einem einzelnen Benutzer zur Verfügung stellt, und es ist mit einem billigen Preis versehen zum Kauf durch Einzelne oder kleine Firmen. Im Betrieb funktioniert der Systemprozessor unter einem Betriebs­ system, wie zum Beispiel IBMs OS/2 Betriebssystem oder DOS. "OS/2" ist ein eingetragenes Warenzeichen der International Business Machines Corportation. Diese Art des Betriebssystems schließt eine Schnittstelle eines Basis-Eingabe-/Ausgabesy­ stems, abgekürzt als (BIOS = Basic Input/Output System) zwi­ schen den E-/A-Geräten umd dem Betriebssystem ein. BIOS, das in einem Festwertspeicher auf einer Grundplatine gespeichert werden kann, schließt Diagnoseprogramme ein, die in einem Ab­ schnitt enthalten sind, der einen Testlauf durchführt bei Netzeinschaltung und auf den als POST (Power On Self Test) Be­ zug genommen wird.

Vor dem Inbeziehungsetzen der obigen Struktur zu der vorlie­ genden Erfindung verdient eine Zusammenfassung der allgemeinen Betriebsweise des Personalcomputersystems 10 einen Rückblick. Es wird auf Fig. 2 Bezug genommen. Dort ist ein Blockdiagramm eines Personalcomputersystems 10 dargestellt, das die ver­ schiedenen Komponenten des Personalcomputersystems 10 gemäß der vorliegenden Erfindung darstellt. Fig. 2 stellt weiter die Komponenten der Grundplatine 11 dar und die Verbindung der Grundplatine 11 mit den E-/A-Anschlußplätzen 46a-46d und ande­ rer Hardware des Personalcomputersystems 10. Mit der Grundpla­ tine 11 ist die Zentraleinheit (ZE) 26 des Systems verbunden, die einen Mikroprozessor umfaßt, der durch einen lokalen Hoch­ leistungsbus 24 der ZE über eine busgesteuerte Zeitgeberein­ heit 38 mit einer Speichersteuereinheit 50 verbunden ist, die weiter mit einem flüchtigen Speicher 58 für wahlfreien Zugriff verbunden ist. Während irgendein geeigneter Mikroprozessor für die ZE 26 benutzt werden kann, ist ein passender Mikropro­ zessor der Pentium-Mikroprozessor, der von der Intel Corpor­ ation vertrieben wird. "Pentium" ist ein Warenzeichen der Intel Corporation.

Während die vorliegende Erfindung im folgenden mit spezieller Bezugnahme auf das Blockdiagramm des Systems nach Fig. 2 be­ schrieben wird, versteht es sich am Beginn der Beschreibung, die folgt, daß ins Auge gefaßt ist, daß die Einrichtung und die Verfahren gemäß der vorliegenden Erfindung mit anderen Hardwarekonfigurationen auf der Grundplatine benutzt werden können. Beispielsweise könnte der Systemprozessor ein Intel 80386, 80486 oder ein Pentium-Mikroprozessor sein. Diese spe­ ziellen Mikroprozessoren können in einer Betriebsart mit re­ aler Adressierung oder in einer Betriebsart mit geschützter Adressierung arbeiten. Jede Betriebsart liefert ein Adressier­ schema für das Zugreifen auf verschiedene Bereiche des Spei­ chers des Mikroprozessors.

Wir kehren jetzt zur Fig. 2 zurück. Der lokale Bus 24 der ZE (der Daten-, Adressen- und Steuerkomponenten umfaßt,) sorgt für die Verbindung mit der ZE 26, einem wahlweise vorhandenen mathematischen Coprozessor 27, einer Cache-Steuereinheit 28 und einem Cache-Speicher 30. Ebenfalls ist ein Puffer 32 mit dem lokalen Bus 24 der ZE verbunden. Der Puffer 32 selbst ist mit einem Bussystem 34 geringerer Leistung (verglichen mit dem lokalen Bussystem der ZE verbunden, der ebenfalls Adressen-, Daten- und Steuerkomponenten umfaßt. Der Systembus 34 er­ streckt sich zwischen dem Puffer 32 und einem weiteren Puffer 36. Der Systembus 34 ist weiter mit einer Bussteuer- und Zeit­ gebereinheit 38 verbunden und einer Einheit 40 für direkten Speicherzugriff, abgekürzt als (DMA = Direct Memory Access). Die DMA-Einheit 40 besteht aus einer zentralen Entscheidungsein­ heit 48 und einer DMA-Steuereinheit 41. Der Puffer 36 sorgt für eine Schnittstelle zwischen dem Systembus 34 und einem als wahlweises Merkmal vorhandenen Bus, wie z. B. einem als Schnittstelle für periphere Komponenten, abgekürzt als (PCI = Peripheral Component Interface) dienenden Bus 44. Mit dem Bus 44 ist eine Vielzahl von E-/A-Anschlußplätzen 46a-46d zum Auf­ nehmen von Adapterkarten verbunden, die weiter mit einem E-/A- Gerät oder Speicher verbunden sein können. Bei dem veranschau­ lichten Beispiel ist ein Festplattenlaufwerk mit dem Anschluß­ platz 46a verbunden; mit dem E-/A-Anschlußplatz 46b ist das Laufwerk eines als CD ausgebildeten Festwertspeichers, abge­ kürzt als (CD-ROM = Compact Disk Read Only Memory), verbunden, und mit dem E-/A-Anschlußplatz 46a ist ein auf einer Adapter­ karte angeordneter Festwertspeicher verbunden. Andere Geräte, wie z. B. ein Modem, können mit einem E-/A-Anschlußplatz ver­ bunden sein. Ein Bus 42 zur Entscheidungssteuerung verbindet die DMA-Steuereinheit 41 und die zentrale Entscheidungseinheit 48 mit den E-/A-Anschlußplätzen 46 und dem Diskettenadapter 82. Ebenso ist eine Speichersteuereinheit 50 mit dem Sytembus 34 verbunden, die aus einer Speichersteuereinheit 52 besteht, einem Adreßmultiplexer 54 und einem Datenpuffer 56. Die Spei­ chersteuereinheit 50 ist weiter mit einem Speicher für wahl­ freien Zugriff verbunden wie er durch den RAM-Modul 58 darge­ stellt wird. Die Speichersteuereinheit 52 schließt die Logik für das Abbilden von Adressen für die und von der ZE 26 auf bestimmte Bereiche des RAM 58 ein. Während das Personalcom­ putersystem 10 mit einem Basis RAM-Modul von 1 Megabyte darge­ stellt ist, versteht es sich, daß zusätzlicher Speicher ange­ schlossen werden kann, wie das in Fig. 2 durch die wahlweise vorhandenen Speichermodule 60 bis 64 dargestellt ist.

Ein weiterer Puffer 66 ist zwischen dem Systembus 34 und einem planaren E-/A-Bus 68 angeschlossen. Der planare E-/A-Bus 68 schließt jeweils Adressen-, Daten- und Steuerkomponenten ein. Längs des planaren Busses 68 ist eine Vielfalt von E-/A-Adap­ tern und anderen peripheren Komponenten angeschlossen, wie z. B. ein Anzeigeadapter 70, (der benutzt wird, um eine wahlweise vorhandene Anzeigeeinrichtung 14 zu steuern), ein Taktgeber 72, ein nichtflüchtiger Speicher 74 mit wahlfreiem Zugriff (auf den später Bezug genommen wird als auf "NVRAM" = Non Vo­ latile Random Access Memory), ein RS232-Adapter 78, ein paral­ leler Adapter 78, eine Vielzahl von Zeitgebern 80, ein Disket­ tenadapter 82, eine Steuereinheit 84 für die PC-Tastatur/Steu­ erkugel und ein Festwertspeicher (ROM) 86. Der ROM 86 schließt das BIOS ein, das dem Benutzer transparente Nachrichtenverbin­ dungen zwischen vielen E-/A-Geräten liefert.

Der Taktgeber 72 wird für Berechnungen der Tageszeit benutzt. NVRAM 74 wird benutzt, um Systemkonfigurationsdaten zu spei­ chern, d. h. der NVRAM enthält Werte, welche die augenblickli­ che Konfiguration des Systems beschreiben. Zum Beispiel ent­ hält NVRAM 74 Informationen, die die Kapazität einer Festplat­ te oder Diskette beschreiben, die Art der Anzeige, den Spei­ cherumfang usw. Von besonderer Wichtigkeit ist, daß NVRAM 74 Daten enthält, die benutzt werden, um die Konfiguration der Systemkonsole zu beschreiben, d. h. ob eine PC-Tastatur mit der Steuereinheit 84 für die Tastatur/Rollkugel verbunden ist, eine Steuereinheit für die Anzeige verfügbar ist oder der ASCII-Anschluß mit dem RS232-Adapter 76 verbunden ist. Dar­ überhinaus sind diese Daten in dem NVRAM 74 gespeichert, wann immer ein spezielles Konfigurationsprogramm ausgeführt wird. Der Zweck des Konfigurationsprogrammes ist es, Werte zu spei­ chern, die die Konfiguration dieses Systems für den NVRAM 76 charakterisieren, die gespeichert werden, wenn die Energie dem System entzogen wird.

Mit der Steuereinheit 84 für die Tastatur/PC Maus sind die Anschlüsse A und B verbunden. Diese Anschlüsse werden benutzt, um eine PC-Tastatur (im Gegensatz zu einem ASCII-Anschluß) und eine Maus mit dem PC-System zu verbinden. Mit der RS232- Adaptereinheit 76 ist ein RS232-Verbinder verbunden. Ein wahl­ weise vorhandener ASCII-Anschluß kann mit dem System durch diesen Verbinder verbunden werden.

Speziell kann das Personalcomputersystem 10 implementiert wer­ den durch Benutzen irgendeines geeigneten Computers, wie z. B. des Computers IBM PS/2 oder eines Computers IBM RISC SY­ STEM/6000, beides Produkte der International Business Machines Corporation, die sich in Armonk, New York befindet. "RISC Sy­ stem/600" ist ein Warenzeichen der International Business Ma­ chines Corporation und "PS/2" ist ein eingetragenes Warenzei­ chen der International Business Machines Corporation.

Die in den Fig. 4-8 veranschaulichten Prozesse können durch die Fachleute in dem durch die Fig. 1 und 2 veranschaulich­ ten Datenverarbeitungssystem implementiert werden. Die in die­ sen Figuren veranschaulichten Prozesse können in einem SOM-Sy­ stem implementiert werden, das die Behandlung von Ausnahmebe­ dingungen entsprechend der Common Object Request Broker Archi­ tecture (CORBA) verkörpert. Weitere Informationen über CORBA findet man in The Common Object Request Broker: Architecture und Specification, veröffentlicht durch Object Management Group (OMG) und X/Open.

Die Prozesse der vorliegenden Erfindung können auch in einem Programmspeicher implementiert werden, der durch ein Datenver­ arbeitungssystem gelesen werden kann, worin der Programmspei­ cher durch das Datenverarbeitungssystem ausführbare Instruk­ tionen für die Prozesse der vorliegenden Erfindung codiert. Der Programmspeicher kann verschiedene Formen annehmen ein­ schließlich z. B., aber nicht darauf beschränkt, eines Fest­ plattenlaufwerkes, einer Diskette, einer optischen Diskette, eines ROM und eines EPROM, die den Fachleuten bekannt sind. Die in dem Programmspeicher gespeicherten Prozesse sind un­ wirksam, bis sie durch Benutzen des Programmspeichers zusammen mit dem Datenverarbeitungssystem aktiviert werden. Zum Bei­ spiel kann ein Festplattenlaufwerk, das durch das Datenverar­ beitungssystem ausführbare Instruktionen für die vorliegende Erfindung enthält, mit einem Datenverarbeitungssystem verbun­ den werden; eine Diskette, die durch das Datenverarbeitungssy­ stem ausführbare Instruktionen für die vorliegende Erfindung enthält, kann in das Diskettenlaufwerk in dem Datenverarbei­ tungssystem eingeführt werden; oder ein ROM, das durch das Da­ tenverarbeitungssystem ausführbare Instruktionen für die vor­ liegende Erfindung enthält, kann mit dem Datenverarbeitungssy­ stem über eine Karte oder einen Adapter verbunden werden, der mit einem E-/A-Anschlußplatz verbunden ist.

Es wird auf Fig. 3 Bezug genommen. Ein Diagramm von Objekten in einem objektorientierten System ist gemäß einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung veranschau­ licht. Ein Objekt kapselt Daten und die Verfahren, die benö­ tigt werden, um mit diesen Daten zu arbeiten, ein. Objekte können durch ein "Pfannkuchen-Diagramm", wie das in Fig. 3 gezeigte, dargestellt werden. Objektdaten sind in dem Zentrum 302 dargestellt, umgeben durch die anwendbaren Verfahren 304 bis 314. Die Daten 302 können nur durch die Verfahren dieses Objektes modifiziert werden. Die Verfahren 304-314 werden durch das Empfangen von Nachrichten anderer Objekte aufgeru­ fen. Ein typisches objektorientiertes System besitzt einen Nachrichtenführer 320 (message router), der die Nachrichten zwischen den Objek­ ten führt. Daher veranlaßt das Objekt 330, daß das Verfahren C 308 aufgerufen wird durch Schicken einer Nachricht an den Nachrichtenführer 320, der wiederum eine Nachricht 322 zum Verfahren C 308 des Objektes 300 schickt.

Objektrahmen werden konstruiert, um einen Satz von Objekten zur Benutzung durch Anwendungs- und Systementwickler zu lie­ fern, um ein ausgeliefertes System aufzubauen. Der Rahmen für das IBM Systemobjektmodell (SOM) liefert z. B. einen sprachen­ unabhängigen Satz von Objekten zur Benutzung bei der System­ entwicklung.

Objekte werden in Klassen von zusammengehörigen Objekten grup­ piert. Die Klassenbeschreibung enthält Informationen, die für alle Objekte in einer Klasse relevant sind, einschließlich ei­ ner Beschreibung von Beispielvariablen, die von jedem der Ob­ jekte gewartet werden, und die verfügbaren Objektverfahren. Ein Objektbeispiel wird geschaffen (oder "instanziiert") auf der Basis dieser Informationen und besitzt die Eigenschaften, die in der Objektklasse definiert sind. Zum Beispiel kann die Objektklasse HUND die Beispielvariablen "Hunde_typ" und "Hunde_name" und ein Verfahren zum "Bellen" einschließen, das die Antwort auf eine Gebell-Nachricht implementiert. Ein Bei­ spiel eines Hundes, z. B. ROVER, behält die Beispielvariablen für den Typ und den Namen für sich selbst bei und antwortet auf die Gebell-Nachricht.

Abstrakte Klassen werden benutzt, um die Schnittstellen und Verfahren, von denen erwartet wird, daß sie benutzt werden, durch eine Klasse zu beschreiben, ohne Einzelheiten für die Implementierung dieser Verfahren zu liefern. Abstrakte Klassen sind in Rahmen nützlich, wo die Details der Implementierung dem Hersteller überlassen werden müssen. Konkrete Klassen werden als Unterklassen abstrakter Klassen geschaffen und im­ plementieren diese Klassen.

Wir wenden uns jetzt den Fig. 4A und 4B zu. Blockdiagramme eines Klientenobjektes CO, eines Objektes A eines Objektes B und eines Objektes C sind gemäß der vorliegenden Erfindung dargestellt. In den dargestellten Beispielen ist das Klienten­ objekt CO eine Anwendung oder ein Programm eines Klienten in einer objektorientierten Umgebung, das eine Nachricht ab­ schickt als Antwort auf irgendeine Eingabe oder eine Anforde­ rung, die durch das Klientenobjekt CO empfangen wurde. Fig. 4A ist ein Beispiel eines vertikalen Szenariums von Ausnahme­ bedingungen, in dem verschiedene Fehler einer Kette von Nach­ richten an unterschiedliche Objekte hinab auftreten können. In anderen als objektorientierten Umgebungen wird solch eine Nachricht oft als "Aufruf" bezeichnet. Die zu dem Objekt A ge­ schickte Nachricht ruft eine Operation an dem Objekt A auf, um irgendeine Reaktion dieses Objektes auszulassen. Das Objekt A ist nicht in der Lage, die Nachricht von dem Klientenobjekt CO vollständig zu verarbeiten und liefert die gewünschte Ant­ wort, ohne daß sie Nachrichten an andere Objekte schickt.

In diesem dargestellten Beispiel schickt das Objekt A eine Nachricht zum Objekt B und das Objekt B schickt wiederum eine Nachricht zu dem Objekt C, um die Antwort zu liefern, die durch die Nachricht gefordert wurde, die von dem Klientenob­ jekt CO abgeschickt wurde. Wenn vorher ein Fehler dem Objekt C begegnet, wird dieser Fehler durch die Objekte B und A zu dem Klientenobjet CO zurückgeschickt, das eine geheime Nachricht für den Benutzer liefern kann, der das Klientenobjekt CO be­ nutzt. Gemäß der vorliegenden Erfindung schickt das Objekt C den Fehler oder die Ausnahmebedingung zu dem Objekt B, das wiederum zusätzliche Fehlernachrichten hinzufügen kann, abhän­ gig von der Ausnahmebedingung, die durch das Objekt C zu dem Objekt B zurückgeschickt wurde. Das Objekt B schickt dann die Datenstruktur zurück, die die Ausnahmebedingung des Objektes C und irgendwelche zusätzlichen Informationen enthält, die es der Datenstruktur hinzugefügt haben mag. Das Objekt A schickt dann die Datenstruktur zu dem Klientenobjekt CO, einschließ­ lich irgendwelcher zusätzlichen Informationen, die es zu der Datenstruktur hinzugefügt haben mag als Antwort auf das Emp­ fangen der Datenstruktur, die die Ausnahmebedingung des Objek­ tes B enthielt.

Fig. 4B ist ein Blockdiagramm eines Klientenobjektes CO und der Objekte A-D. Diese Figur liefert ein Beispiel eines hori­ zontalen Szenariums für Ausnahmebedingungen, in dem das Klien­ tenobjekt CO eine Nachricht zu dem Objekt A schickt, A wie­ derum schickt die Nachricht zu den Objekten B, C und D. Aus der Perspektive des Klientenobjektes CO wurde die Nachricht abgeschickt, um A einzustellen, das alle Ausnahmebedingungen zurückschickt, die mit dem Verarbeiten des Klientenobjektes CO verbunden sind. In diesem Fall liefert jedes der Objekte, die eine Nachricht von dem Klientenobjekt CO empfangen, eine Ant­ wort, die eine Ausnahmebedingung einschliessen kann. In dieser Situation speichert die vorliegende Erfindung alle der zurück­ geschickten Ausnahmebedingungen in einer Datenstruktur vor dem Zurückschicken der Datenstruktur zu dem Klientenobjekt.

Eine Struktur einer Ausnahmebedingung ist eine Struktur, die eine Nachricht über eine Ausnahmebedingung enthält mit einem Zeiger auf einem Stapel von null oder mehr Nachrichten über Ausnahmebedingungen. Diese Nachrichten haben die Form einer CORBA-Folge ähnlich einer Anordnung in dem dargestellten Bei­ spiel.

Wir wenden uns jetzt der Fig. 5 zu. Darin ist ein Diagramm von Datenstrukturen dargestellt, die einen Mechanismus zum Melden von Fehlern oder Ausnahmebedingungen gemäß der vorliegen­ den Erfindung darstellen. Fig. 5 veranschaulicht, wie Aus­ nahmebedingungen gespeichert und zwischen Objekten gemäß der vorliegenden Erfindung übertragen werden. Ein Fehler tritt auf, wenn der Code nicht richtig oder wie erwartet aktiviert, und eine Ausnahmebedingung ist die Information, die den Fehler be­ schreibt. Entsprechend einer ersten Ausnahmebedingung wird eine Struktur 500 für Ausnahmebedingungen geschaffen und Argu­ mente und Parameter werden in dieser Datenstruktur gespei­ chert. Eine "Struktur für Ausnahmebedingungen" ist eine Struktur, die eine Nachricht einer Ausnahmebedingung enthält mit einem Zeiger auf einen Stapel von null oder mehr Nachrichten von Ausnahmebedingungen. Diese Nachrichten haben die Form einer CORBA-Folge, ähnlich einer Anordnung in dem veranschaulichten Beispiel.

In dem dargestellten Beispiel schließt die Nachricht über Aus­ nahmebedingungen einen Eintrag für den Typ ein, der den Typ der Nachricht für das Verwalten der Betriebsmittel angibt, wie z. B. OS/2. Der Katalogeintrag ist der Name des Katalogs, der die Nachricht enthält, die der Ausnahmebedingung hinzuzufügen ist. Der Schlüsseleintrag gibt die eindeutige Nachrichtenidentifizierung des Betriebsmittelverwalters für die Nachricht an, die der Ausnahmesituation hinzugefügt wird. Der vierte Eintrag, fehl_nachr, ist ein Eintrag für den Text der Fehlnachricht. Der Eintrag Zeitangabe gibt das Datum und die Zeit an, zu der die Nachricht gemeldet wurde. Verschiedene andere Einträge, die in diesem Beispiel nicht dargestellt sind, können in der Struktur 500 für Ausnahmebedingungen ver­ wendet werden. Der letzte Eintrag in dem dargestellten Bei­ spiel ist ein Zeiger nachr_ctx. Anfangs verweist der Zeiger nachr_ctx nicht auf irgendeine andere Datenstruktur, wenn nur eine Ausnahmebedingung aufgetreten ist.

Als Antwort auf eine zweite Ausnahmebedingung wird die Struk­ tur 502 der Ausnahmebedingung geschaffen. Die Struktur 502 der Ausnahmebedingung ist ähnlich der Struktur 500 der Ausnahmebe­ dingung, jedoch verweist der Zeiger nachr_ctx jetzt auf den Stapel 504, der eine Nachricht der Ausnahmebedingung ist, die die Daten der Struktur 500 der Ausnahmebedingung speichert. Ein "Stapel" ist eine Datenstruktur, die eine Fähigkeit unter­ stützt, mehrere Objekte auf die oder von der Oberseite der Datenstruktur nach dem Verfahren Zuletzt-hinein-zuerst-heraus, abgekürzt als (LIFO = last-in-first-out) zu schieben/stoßen. Als Antwort auf eine dritte Ausnahmebedingung wird die Struk­ tur 506 der Ausnahmebedingung geschaffen, in der der Zeiger nachr_ctx auf den Stapel 508 verweist, in dem die Nachricht der Ausnahmebedingung von der Struktur 502 der Ausnahmebedin­ gung auf die Oberseite des Stapels kopiert wird und eine Kopie der vorherigen Datenstruktur, Stapel 504, unter diese Einträge im Stapel 508 kopiert wird. Als Antwort auf die N. Ausnahmebe­ dingung wird die Struktur 510 der Ausnahmebedingung geschaf­ fen, die die Ausnahmebedingung enthält, die bei diesem spezi­ ellen Objekt auftritt, wobei der Zeiger nachr_ctx auf den Sta­ pel 512 verweist, der die Daten von der Struktur 506 der Aus­ nahmebedingung an der Oberseite des Stapels 512 enthält und eine Kopie des Stapels 508 darunter. Daher bilden die Struktur 510 der Ausnahmebedingung und der Stapel 512 eine Datenstruk­ tur, die zu dem Klientenobjekt zurückgeschickt wird, wie z. B. dem Klientenobjekt CO in den Fig. 4A und 4B. Alle diese Ausnahmebedingungen sind für die Prüfung und Analyse vorhan­ den.

Wir wenden uns jetzt der Fig. 6 zu. Ein Flußdiagramm eines Prozesses zum Bearbeiten von Ausnahmebedingungen, die in einer horizontalen Weise auftreten, ist gemäß einem bevorzugten Aus­ führungsbeispiel der vorliegenden Erfindung dargestellt. Der Prozeß beginnt mit dem Empfangen einer Benutzeranforderung in der Form einer Aktualisierungsanforderung bei dem Klientenob­ jekt (Schritt 600). Solch eine Anforderung kann darin beste­ hen, eine oder mehrere Eigenschaften (d. h. Paßwort, Ablauf des Guthabens, Datum, Mindestlänge des Paßwortes usw.) für ein Ob­ jekt zu aktualisieren wie z. B. für ein Kontoobjekt. Das Klien­ tenobjekt verarbeitet die Aktualisierungsanforderung des Kli­ nten (Schritt 602).

Beim Verarbeiten einer Anforderung kann das Klientenobjekt Nachrichten an eine Anzahl verschiedener Objekte schicken, die Eigenschaften, die in der Anforderung mitgeschickt wurden, zu bestätigen. Ein Fehler ist jetzt aufgetreten. Jedes Objekt be­ stätigt eine Eigenschaft, die in der Liste (Schritt 606) nicht verarbeitet wurde. Eine Bestimmung wird vorgenommen, ob ein Fehler bei der Bestätigung aufgetreten ist (Schritte 608). Wenn ein Fehler bei der Bestätigung aufgetreten ist, wird eine Nachricht abgeschickt, Informationen zu der Datenstruktur hin­ zuzufügen (Schritt 610). Danach wird eine Bestimmung vorgenom­ men, ob das Ende der Liste der Eigenschaften erreicht ist (Schritt 612). Wenn das Ende der Liste der Eigenschaften nicht erreicht wurde, wird die nächste nicht verarbeitete Eigen­ schaft in der Liste verarbeitet, um sie im Schritt 606 zurück zu bestätigen. Wenn das Ende der Liste der Eigenschaften er­ reicht ist, wird eine Bestimmung vorgenommen, ob ein Fehler während der Verarbeitung aufgetreten ist (Schritt 614). Wenn ein Fehler aufgetreten ist, wird die Datenstruktur einschließ­ lich einer Struktur der Ausnahmebedingungen und ein Stapel für die Benutzung des Aufrufers zurückgeschickt (Schritte 616). Wenn kein Fehler aufgetreten ist, wird eine Nachricht zu dem Aufrufer zurückgeschickt, die den Erfolg anzeigt (Schritt 618).

Wir wenden uns jetzt der Fig. 7 zu. Ein Flußdiagramm eines Prozesses für das Verarbeiten von Ausnahmebedingungen, die in einer vertikalen Weise auftreten, ist gemäß einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung dargestellt. Der Prozeß beginnt mit dem Empfangen einer Benutzeranforderung (Schritt 700). Danach verarbeitet das Klientenobjekt die Anforderung (702). Beim Verarbeiten der Anforderung wird eine Bestimmung gemacht, ob ein Fehler aufgetreten ist (Schritt 704). Wenn kein Fehler aufgetreten ist, schickt das Klienten­ objekt CO eine Nachricht zu dem Objekt A, um die Anforderung zu verarbeiten (Schritt 706). Das Objekt A verarbeitet die Anforderung des Klientenobjektes (Schritt 708).

Als nächstes wird eine Bestimmung vorgenommen, ob ein Fehler beim Verarbeiten der Anforderung aufgetreten ist (Schritt 710). Wenn kein Fehler aufgetreten ist, schickt das Objekt A eine Nachricht zu dem Objekt B, um die Anforderung weiter zu verarbeiten (Schritt 712). Das Objekt B verarbeitet die Anfor­ derung (Schritt 714). Eine Bestimmung wird gemacht, ob ein Fehler aufgetreten ist (Schritt 716). Danach schickt das Ob­ jekt B eine Nachricht zum Objekt C, um für weitere Verarbei­ tung der Anforderung zu sorgen (Schritt 718). Das Objekt C verarbeitet die Anforderung (Schritt 720) und eine Bestimmung wird vorgenommen, ob ein Fehler aufgetreten ist (Schritt 722). Wenn kein Fehler aufgetreten ist, schickt der Prozeß dann die Ergebnisse zu der Klientenanwendung über das Objekt B und das Objekt A (Schritt 724) zurück, wobei der Prozeß danach endet.

Es wird wieder auf den Schritt (722) Bezug genommen. Wenn ein Fehler aufgetreten ist, wird das Objekt für Ausnahmebedingun­ gen aufgerufen unter Benutzung einer Nachricht kontextspezifi­ sche Informationen einer Datenstruktur hinzuzufügen (Schritt 726). Danach wird die Datenstruktur zum Objekt B zurückge­ schickt (Schritt 728). Zu dieser Zeit schickt das Objekt B, das weiß, daß ein Fehler in dem Aufruf für das Objekt C aufge­ treten ist, eine Nachricht zu dem Objekt für Ausnahmebedingun­ gen, der Datenstruktur kontextspezifische Informationen hinzu­ zufügen (Schritt 730). Diese Datenstruktur wird zum Objekt A zurückgeschickt (Schritt 732), das die Anforderung im Hinblick auf die Fehler verarbeitet, die zu ihm im Schritt 708 zurück­ geschickt wurden.

Wieder wird eine Bestimmung gemacht, ob ein Fehler im Hinblick auf die früheren Fehler auftrat (Schritt 710). Wenn ein Fehler beim Verarbeiten durch das Objekt A aufgetreten ist, ruft der Prozeß dann das Objekt für Ausnahmebedingungen auf, um kon­ textspezifische Informationen der Datenstruktur hinzuzufügen (Schritt 734). Danach wird der Stapel der Ausnahmebedingungen zu dem aufrufenden Objekt zurückgeschickt, dem Klientenobjekt (Schritt 736). Das Klientenobjekt, das weiß, daß ein Fehler in der Nachricht für das Objekt A aufgetreten ist, schickt den Stapel der Ausnahmebedingungen zu dem Aufrufer zurück (Schritt 740) zur Benutzung in einer Benutzerantwort (Schritt 742), wo­ mit der Prozeß danach endet.

Es wird jetzt auf Fig. 8 Bezug genommen. Ein Flußdiagramm ei­ nes Prozesses für ein Objekt für Ausnahmebedingungen, das ver­ wendet wird, um die Datenstrukturen zu bearbeiten, die Fehler­ informationen enthalten, ist gemäß dem bevorzugten Ausfüh­ rungsbeispiel der vorliegenden Erfindung dargestellt. Das Verfahren beginnt durch Zuordnen einer Struktur für eine neue Ausnahmebedingung mit einem Null-Stapelzeiger (Schritt 800). Der Prozeß speichert dann Argumente für die Parameter der neu­ en Struktur für Ausnahmebedingungen, die sich auf den Fehler beziehen (Schritt 802). Der Prozeß bestimmt dann, ob eine exi­ stierende Ausnahmebedingung des aufrufenden Objektes vorhanden ist (Schritt 804). Wenn eine existierende Ausnahmebedingung für das aufrufende Objekt vorhanden ist, erhält der Prozeß die laufende Länge des existierenden Stapels für Ausnahmebedingun­ gen, der die existierende Ausnahmebedingung enthält (Schritt 806). Neuer Speicherplatz wird für einen neuen Stapel für Aus­ nahmebedingungen zugeteilt (Schritt 808). Der neue Speicher­ raum, der für den neuen Stapel für Ausnahmebedingungen zuge­ teilt wurde, wird dem neuen Stapelzeiger für Ausnahmebedingun­ gen nachr_ctx zugeordnet (Schritt 810).

Danach werden Parameter existierender Ausnahmebedingungen auf den oberen Eintrag des neuen Stapels für Ausnahmebedingungen kopiert (Schritt 812). Eine Bestimmung wird vorgenommen, ob die vorhandene Stapellänge größer als eins ist (Schritt 814). Wenn der existierende Stapel eine Länge größer als eins hat, dann kopiert der Prozeß den existierenden Stapel in neue Sta­ peleinträge der Struktur für Ausnahmebedingungen (Schritt 818). Der Prozeß schickt dann die Struktur für Ausnahmebedin­ gungen und den Stapel zu dem aufrufenden Objekt (Schritt 820) und der Prozeßfluß kehrt zu dem aufrufenden Objekt zurück (Schritt 822). Es wird wieder auf den Schritt 814 Bezug genom­ men. Wenn die Datenstruktur des Stapels existierende Ausnahme­ bedingungen nicht größer als eins ist, dann schickt der Prozeß direkt den neuen Stapel für Ausnahmebedingungen zu dem aufru­ fenden Objekt (Schritt 820). Der Prozeß schickt dann auch die neue Struktur für Ausnahmebedingungen zu dem aufrufenden Ob­ jekt, wenn eine existierende Ausnahmebedingung dem aufrufenden Objekt im Schritt 804 nicht zugeordnet ist.

Claims (7)

1. Verfahren für ein Datenverarbeitungssystem zum Behandeln von Fehlern, die während einer Verarbeitung einer Vielzahl von Objekten in einer objektorientierten Umgebung auftreten, wobei das Verfahren umfaßt:
Empfangen eines Aufrufs von einem aufrufenden Objekt zum Verarbeiten des Aufrufs in einer Vielzahl von Objekten
Speichern von Fehlerinformationen von jedem der Vielzahl der Objekte, in welchen ein Fehler auftritt, in einer Datenstruktur,
Speichern der Fehlerinformationen zusammen mit dem Fehler in einer Ausnahmestruktur als Antwort auf ein Auftreten eines Fehlers und des Vorhandenseins von Fehlerinformationen innerhalb der Datenstruktur, und
Zurücksenden der Ausnahmestruktur zu dem aufrufenden Objekt

2. Verfahren nach Anspruch 1, weiter umfassend: Speichern der Fehlerinformation aus der Datenstruktur in eine neue Datenstruktur, wobei die neue Datenstruktur mit der Ausnahmestruktur verbunden ist, als Antwort auf das Vorhandensein von Fehlerinformationen innerhalb der Datenstruktur.

3. Datenverarbeitungssystem zum Behandeln von Fehlern, die innerhalb einer Vielzahl von Objekten während des Verarbeitens einer Nachricht auftreten, wobei das System umfaßt:
Empfangsmittel zum Empfangen einer Nachricht zum Verarbeiten durch die Vielzahl von Objekten, wobei die Nachricht von einem ersten Objekt stammt,
Speichermittel zum Speichern von Fehlerinformation in einer ersten, primären Datenstruktur als Antwort auf ein Auftreten eines ersten Fehlers während der Verarbeitung der Nachricht durch die Vielzahl von Objekten,
Speichermittel zum Speichern von Fehlerinformation in einer zweiten, primären Datenstruktur als Antwort auf das Auftreten eines zweiten Fehlers und Speichern der Fehlerdaten aus der ersten, primären Datenstruktur in eine erste, sekundäre Datenstruktur und zum Zuordnen der ersten, sekundären Datenstruktur mit der ersten, primären Datenstruktur, wobei die erste, sekundäre Datenstruktur von der zweiten, primären Datenstruktur getrennt adressierbar ist,
Sendemittel zum Senden der ersten und zweiten primären Datenstruktur und der ersten, sekundären Datenstruktur zum aufrufenden Objekt.

4. Datenverarbeitungssystem nach Anspruch 3, weiter umfassend: Speichermittel zum Speichern von Fehlerinformation in einer nachfolgenden primären Fehlerdatenstruktur als Antwort auf ein Auftreten eines nachfolgenden Fehlers und zum Speichern der Fehlerdaten in der zweiten, primären Datenstruktur und in der ersten, sekundären Datenstruktur in einer zweiten, sekundären Datenstruktur und zum Zuordnen der zweiten, sekundären Datenstruktur mit der nachfolgenden primären Datenstruktur.

5. Datenverarbeitungssystem nach Anspruch 3 oder 4, bei dem die nachfolgende, primäre Datenstruktur mit der zweiten, sekundären Datenstruktur zugeordnet ist unter Benutzung eines Zeigers, der in der nachfolgenden, primären Datenstruktur gespeichert ist, wobei der Zeiger auf die zweite sekundäre Datenstruktur verweist.

6. Datenverarbeitungssystem nach Anspruch 3, 4 oder 5, bei dem die zweite sekundäre Datenstruktur einen oberen Teil aufweist und die Fehlerdaten in der zweiten, primären Datenstruktur in dem oberen Teil der zweiten sekundären Datenstruktur gespeichert sind.

7. Datenverarbeitungssystem nach Anspruch 3, wobei das Speichermittel eine Festplatte oder eine Diskette ist.