DE69518996T2

DE69518996T2 - Verfahren und Vorrichtung zur selbstbeschreibenden Datenkodierung

Info

Publication number: DE69518996T2
Application number: DE69518996T
Authority: DE
Inventors: Bruce Alfred Delagi; Jaikumar Ramanathan; Nakul P. Saraiya
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1994-04-26
Filing date: 1995-04-25
Publication date: 2001-03-29
Anticipated expiration: 2015-04-26
Also published as: JPH0855045A; EP0679995A1; JP3699154B2; DE69518996D1; US5655121A; EP0679995B1

Description

1. Bereich der Erfindung

Die vorliegende Erfindung betrifft Datenverarbeitungssysteme. Genauer betrifft die vorliegende Erfindung ein Verfahren und eine Vorrichtung zum Codieren von Daten in einer solchen Weise, daß sich die Daten selbst beschreiben, so daß die Daten in einer vorbestimmten, mit der angezeigten Datenart verbundenen Weise verarbeitet werden können.

2. Hintergrundinformationen

Da Softwareentwicklungen immer vorherrschender werden und unter Umständen eingesetzt werden, unter denen früher diskrete Elektronik zu Durchführung gewünschter Funktionen verwendet wurde, steigt der Bedarf an Kontrolle und Überprüfung der Funktionalität von Software. Ein Verfahren zur Überprüfung von Software gemäß dem Stand der Technik umfaßt den Einsatz von sogenannten Meßpunkten und Tracern. Meßpunkte sind ein Mittel zum Unterscheiden von Punkten in einem Code und vielleicht zum Erzeugen eines Ereignisdatensatzes, obwohl auch andere Dinge durchgeführt werden können. Ein Tracer ist eine zeitlineare (oder wenigstens kausal geordnete) Sammlung von Datensätzen irgendeiner Gruppe der unterschiedenen Ereignisse bei der Ausführung eines Programms oder eines Programmsatzes. Ein Meßpunkt ist, wie ein Überprüfungspunkt in einem Stromkreis, eine Stelle, an der ein Entwickler die Funkton des laufenden Programmes bewerten kann. Einige Meßpunkte können abhängig von den Betriebsumständen selektiv freigegeben oder unwirksam gemacht werden, so daß ein Programmablaufcode Prüfinformationen erzeugen kann, ohne die Erfordernis, daß ein Programmierer den Primärcode für das Programm verändern muß. Somit können Meßpunkte innerhalb einer durchführbaren Routine selektiv in Gruppen in der Laufzeit freigegeben oder unwirksam gemacht werden, ohne Veränderung des darunterliegenden Primärcodes. So kann ein Programmierer Fehl in einem Programm feststellen, ohne irgendetwas über die Internas des Betriebscodes zu wissen (obwohl dies sicherlich hilfreich ist).
Meßpunkte können in zwei Klassen eingeteilt werden: manuelle Meßpunkte; und automatische Meßpunkte. Manuelle Meßpunkte werden von einem Programmierer von Hand in den Primärcode eines Programmes eingegeben. Sie werde von dem Programmierer verwendet, um eine detaillierte Fehlerbeseitigung und Funktionsanalyse durchzuführen. Eine Unterklasse von manuellen Meßpunkten ist als semantische Meßpunkte bekannt, deren Effekte als Teil des Programmes oder der Programmbibliotheksschnittstelle dokumentiert werden. Typischerweise werden diese Meßpunkte eingesetzt, um Informationen über die externe Fehlerbehebung oder Funktionsanalyse zu liefern. Automatische Meßpunkte sind solche, die von Vorrichtungen in die existierenden Laufzeit Programme eingegeben werden, ohne direkte Manipulation des Primärcodes durch den Programmierer. Automatische Meßpunkte könne durch einen Vorprozessor oder durch Operieren auf verarbeitete Binärdaten eingegeben werden, und können Informationen wie Ablaufausgangs- und -eingangspunkte liefern. Automatische Meßpunkte können in der Laufzeit selektiv freigegeben und unwirksam gemacht werden, um bestimmte Funktionsprobleme spezifisch zu analysieren.
Eines der Probleme bei den Meßpunkten und dem Tracing gemäß dem Stand der Technik besteht darin, daß der Prüfingenieur die Daten nur in einem bestimmten Format erwartet. Typischerweise werden die Daten in einer Rohform präsentiert, wobei der Prüfingenieur bestimmen muß, was die von den Meßpunkten zurückgegeben Daten darstellen. So muß der Prüfingenieur, der ein durchführbares Programm überprüft, welches Informationen von Meßpunkten erzeugt, ein genaues Verständnis der in der Programmlaufzeit gelieferten Meßpunktinformationen haben. Leider sind solche Informationen in vielen Fällen nicht verfügbar oder können von dem ursprünglichen Programmier des zu überprüfenden Anwendungsprogramms undurchsichtig gemacht werden. Somit ist es wünschenswert, daß ein Meßpunkte erzeugendes Programm Informationen über die Meßpunkte in einer standardisierten Weise bereitstellt, so daß eine Diagnose der zu überprüfende Programme sehr leicht durchgeführt werden kann, ohne ein detailliertes Verständnis der internen Funktionsweise des sich in der Überprüfung befindlichen Programms. Techniken gemäß dem Stand der Technik zur interprozessualen Kommunikation unter Umständen wie der Überprüfung erfordern typischerweise Fremdinformationen zu den Daten, um den von dem Programm ausgegebenen Datentyp zu erkennen.
Das IBM Technical Disclosure Bulletin, Bd. 35, Nr. 1B, Juni 1992 (New York; U.S.), Seite 321- 322, Leichttrace und Zuordner für Inter Prozessor-Timingprobleme, legt ein Verfahren für einen Tracemechanismus dar, welches immer betriebsbereit ist. "Die Traceinformationen sind jedoch in einer kryptischen Form protokolliert". Ein zweites Programm wird verwendet, um die kryptischen Traceinformationen zuzuordnen und dieses Programm muß "die Tatsache berücksichtigen, daß die Daten in einer bestimmten Position in jeder Eingabe gespeichert sind", um die Bedeutung der Daten abzuleiten.
Die internationale Veröffentlichung WO 93/25964, Computerprogram-Fehlerbeseitigung in Gegenwart von mit einem Kompilierer synthetisierten Variablen, legt ein Verfahren zur Fehlerbehebung dar, welches den Primärcode verarbeitet; um mehrere untereinander verbundene externe Tabellen zu erzeugen, die Informationen über Programmvariable enthalten, die verwendet werden können, um variable Werte an ausgewählten Programmzähladressen zu überprüfen und einzustellen.

Zusammenfassung der vorliegenden Erfindung

Die Erfindung schlägt ein Computer-implementiertes Verfahren und eine Vorrichtung in einem Computersystem vor, um Daten von in ein erstes Anwendungsprogramm eingegebenen Meßpunkten während der Laufzeit an ein zweites Anwendungsprogramm zu liefern. Die Daten sind in einem vorbestimmten Format dargestellt und als Tracerdatensätze gespeichert. Die erste Anwendung umfaßt eine Verbindung zu der Bibliothek der Datentypen, um Meßpunkte in dem ersten Anwendungsprogramm zu beschreiben. Die Bibliothek der Datentypen ermöglicht die Überprüfung der Meßpunkte in dem ersten Anwendungsprogramm, welches die Datentypen aus dem zweite Anwendungsprogramm aufweist. Die Bibliothek der Datentypen umfaßt eine Definition eines Ereignisdatensatzes, der als ein Tracerdatensatz gespeichert ist. Ein Meßpunkt wird an einem vorbestimmten Punkt innerhalb des ersten Anwendungsprogramms gemäß der Typenbibliothek eingegeben. Der Meßpunkt wird freigegeben, um den Ereignisdatensatz in dem vorbestimmten Format zu erzeugen. Das erste Anwendungsprogramm erzeugt durch den Meßpunkt Daten in einem Ereignisdatensatz. Der Ereignisdatensatz umfaßt eine Vielzahl von Feldern. Wenigstens eines aus der Vielzahl der Felder enthält die von dem ersten Anwendungsprogramm erzeugte Daten und andere aus der Vielzahl der Felder enthalten Informationen, welche die erzeugten Daten beschreiben. Eines aus der Vielzahl der Felder enthält einen Hinweis (z. B. eine relative oder absolute Hinweisadresse) auf einen Hinweissymboldatensatzt. Der Hinweissymboldatensatz listet Namen und Typen einer Vielzahl von Feldern in dem betreffenden Ereignisdatensatz auf. Der Hinweissymboldatensatz verweist ferner rekursiv auf eine Vielzahl von Hinweissymboldatensätzen, welche jeweils auf einen zugehörigen Hinweissymboldatensatz verweisen, der Namen und Typen von Feldern in einem Hinweissymboldatensatz, auf den verwiesen wurde, auflisten, und welche schließlich auf einen selbstbescbreibenden Wurzeldatensatz verweisen, der einen Selbsthinweis und Felder umfaßt; welche Namen und Typen einer Vielzahl von Feldern in dem Wurzeldatensatz auflisten. Ein zweites Anwendungsprogramm empfängt den Ereignisdatensatz (z. B. während der Computersystemlaufzeit, beispielsweise während der Durchführung einer Prüfreihe) und verweist rekursiv auf die erzeugten Daten, den Hinweissymboldatensatz und die Vielzahl von Hinweissymboldatensätzen, bis es den Wurzeldatensasz erreicht. Die zweite Anwendung verarbeitet die Daten gemäß dem Hinweissymboldatensatz und der Vielzahl von Hinweissymboldatensätzen, wobei das zweite Anwendungsprogramm in der Lage ist, eine Diagnose des ersten in Überprüfung befindlichen Programmes ohne Bezugnahme auf andere Informationen als die erzeugten Daten zu erstellen. Auf diese Weise sind die Daten in dem Datensatz selbstbeschreibend. Das zweite Anwendungsprogramm verarbeitet dann die Daten gemäß der Identifikation der von dem Datensatz, dem Hinweissymboldatensatz und jedem aus der Vielzahl der Hinweissymboldatensätze spezifizierten Daten, indem die in dem Datensatz enthaltenen Date, die von der Prüfreibe nicht benötigt werden, gefiltert werden, oder indem die Daten in einer für die Überprüfung geeigneteren Form von einem Benutzer oder Nachbearbeitungsprogramm neu formatiert werden.

Kurze Beschreibung der Zeichnungen

Die vorliegende Erfindung wird mittels eines Beispiels nicht begrenzend in den Abbildungen der anliegenden Zeichnung illustriert, in welcher gleiche Bezugszahlen gleiche Elemente bezeichnen, und in welcher:
Abb. 1 ein System illustriert, in welchem eine Ausführung der vorliegenden Erfindung implementiert werden kann;
Abb. 2 eine Beziehung zwischen einem in der Überprüfung befindlichen Anwendungsprogramm und einem Prüfreihenprogramm und die Kommunikation zwischen dies® beide ausführbaren Programmen zeigt;
Abb. 3 die Verarbeitung von verschiedenen Tracerinformationen und Zwischeninformationen illustriert, wie sie in einem System durchgeführt werden kann, welches die Ausführungen der vorliegenden Erfindung implementiert;
die Abb. 4-7 verschiedene Datenstrukturen zeigen, welche in implementierten Ausführungen der vorliegenden Erfindung geschaffen und verwendet werden können.

Detaillierte Beschreibung

Ein Teil der Darlegung dieser Patentschrift enthält Material, das dem Urheberschutz unterliegt, und für welches Urheberschutz beansprucht wird. Der Eigentümer hat keine Einwände gegen die Faksimilevervielfältigung der Patentbeschreibung durch irgendwen, wie es der Fall bei den Patentakten oder -aufzeichngen des des Patent- und Markenamtes ist, er behält sich aber andernfalls jegliche Urheberrechte und ähnliche Rechte vor.
Die vorliegende Erfindung betrifft die interprozessuale Kommunikation und die Darstellung von Daten, welche eine solche interprozessuale Kommunikation für solche Anwendungen wie die Überprüfung erleichtert. Obwohl die vorliegende Erfindung unter Bezugnahme auf bestimmte, spezifische, implementierte Ausführungen und Beispiele beschrieben wird, in denen die hier zu beschreibenden Datenstrukturen und -formate für die Anwendung der Überprüfung eingesetzt werde, kann der Fachmann erkennen, daß solche selbstbeschreibenden Datenformate für irgendeine Anzahl von Anwendungen eingesetzt werden können, wie von den Entwicklern dieser Erfindung gewünscht. Weitere Vorteile und Anwendungen für implementierte Ausführungen werden für den Fachmann deutlich werden und können ohne diese spezifischen Details durchgeführt werden, ohne den generellen Geist und Rahmen der vorliegenden Erfindung zu verlassen.
Die vorliegende Erfindung ist als eine Reihe von Datenstrukturen und begleitenden Anweisungen implementiert, die in einem Computerprogramm implementiert sind, das innerhalb eines Computersystems betriebsbereit ist. Solche Datenstrukturen können in einem Computersystem, wie in dem Blockdiagramm der Abb. 1 illustriert, geschaffen werden.
Unter Bezugnahme auf Abb. 1 ist ein System, in welchem eine Implementierung der vorliegenden Erfindung implementiert ist; als 100 gezeigt. 100 umfaßt einen Bus oder eine andere Kommunikationseinrichtung 101, um Informationen zu übermitteln, und eine Verarbeitungsvorrichtung 102, welche mit dem Bus 101 verbunden ist, um Informationen zu verarbeiten. Das System 100 umfaßt ferner einen Random Access-Speicher (RAM) oder eine andere selbstlöschende Speichervorrichtung 104 (als Hauptspeicher bezeichnet), welche mit dem Bus 101 verbunden ist, um Informationen und Anweisungen zu speichern, die von dem Prozessor 102 ausgeführt werden sollen. Der Hauptspeicher 104 kann auch dafür verwendet werden, temporäre Variablen oder andere Zwischeninformationen während der Ausführung von Anweisungen durch den Prozessor 102 zu speichern. Das System 100 umfaßt auch einen Festspeicher (RSM) und/oder eine andere statische Speichervorrichtung 106, die mit dem Bus 101 verbunden ist, um statische Informationen und Anweisungen für den Prozessor 102 zu speichern, und eine Datenspeichervorrichtung 107, wie eine Magnetplatte oder optische Platte und ihre entsprechende Platteneinheit. Die Datenspeichervorrichtung 107 ist mit dem Bus 101 verbunden, um Informationen und Anweisungen zu speichern. Dies kann für die Speicherung der hier zu beschreibenden Datenbasen verwendet werden, die Informationen über laufend definierte Problembeschreibungen unter Verwendung im Handel erhältlicher Softwareprodukte verwalten.
Das System 100 ist ferner mit einer Anzeigevorrichtung 121, wie einer Elektronenstrahlröhre (CRT) oder einer Flüssigkristall-Sichtanzeige (LCD), verbunden, die mit dem Bus 101 verbunden ist, um einem Computerbenutzer Informationen anzuzeigen. Solch eine Anzeige 121 kann ferner über einen Datenübertragtungspuffer 110 mit dem Bus 101 verbunden sein, um Informationen wie einzelne oder mehrfache Datenübertragungen oder Bilder auf der Anzeigevorrichtung 121 anzuzeigen. Eine alphanumerische Eingabevorrichtung 122, einschließlich alphanumerischer oder anderer Schlüssel, kann auch mit dem Bus 101 verbunden sein, um dem Prozessor 102 Informationen und Befehlswahlen zu übermitteln. Eine zusätzliche Benutzereingabevorrichtung ist die Cursorsteuerung 123, wie eine Maus, eine Rollkugel, ein Schreiber oder Cursorrichtungsschlüssel, welche mit dem Bus 101 verbunden ist; um Richtungsinformationen und Befehlswahlen an den Prozessor 102 zu übermitteln, und um die Cursorbewegung auf der Anzeige 121 zu steuern.
Es ist auch festzustellen, daß einige oder alle der Komponenten des Systems 100 und der zugehörigen Hardware in verschiedenen Ausführungen verwendet werden können, wobei jedoch zu bevorzugen ist; daß irgendeine Konfiguration des Systems für verschiedene Zwecke gemäß der bestimmten Implementierung eingesetzt wird.
In einer Ausführung ist das System 100 eine der Workstations (Computer-Arbeitsplätze) aus der Sun Microsystems®-Markenfamilie, wie die SPARCstation-Workstations, die von Sun Microsystems® in Mountain View, California hergestellt werden. Der Prozessor 102 kann einer der Mikroprozessoren der SPARC-Matke sein, die von Sun Microsystems® in Mountain View, California hergestellt werden (Sun Microsystems® in Mountain View, California).
Es ist festzuhalten, daß sich die nachfolgende Diskussion von verschiedenen hier diskutierten Ausführungen speziell auf eine Reihe von Routinen bezieht, die in einer höheren Programmiersprache (z. B. der C-Sprache) erzeugt und compiliert, verbunden und dann als Zielcode in dem System 100 während der Laufzeit betrieben werden, beispielsweise von dem SPAR Computer, der von Sun Microsystems® in Mouatain View, California erhältlich ist. Insbesondere ist die vorliegende Erfindung in Verbindung mit verschiedenen Softwarebibliotheken betriebsbereit; wie dem von SunSoft, Inc. in Mountain View, California erhältlichen Solaris® Threads-Paket (Sun, Sun Microsystems und Solaris sind Warenzeichen von Sun Microsystems in Mountain View, California. SPARC und SPARCstation sind Warenzeichen von SPARC International, Inc. und sind exklusiv an Sun Microsystems lizensiert). Ein Fachmann wird jedoch erkennen, daß die folgenden Verfahren und Vorrichtungen in Hardwarevorrichtungen für spezielle Zwecke implementiert werden können, wie diskreten Verknüpfungsvorrichtungen, hochintegrierten Schaltkreisen (LSIs), anwendungsspezifischen Schaltkreisen (ASICs) oder anderer spezialisierter Hardware. Die hier gegebene Beschreibung bezieht sich auch auf eine Vorrichtung mit ähnlichen Funktionen.
Die vorliegende Erfindung implementiert ein System, bei welchem der Anwendungsprogrammierer, der das in der Überprüfung befindliche Programm erzeugt, "Meßpunkte" in dem Primärcode des Programms spezifiziert, so daß die Meßpunkte später in der Systemlaufzeit, abhängig von bestimmten, während des Aufrufens des durchführbaren Programmes spezifizierten Parametern aktiviert werden können, wodurch bewirkt wird, daß die Meßpunkte Datensätze, erzeugen, welche einem zweiten Anwendungsprogramm oder Benutzer (z. B. einem Prüfingenieur) überprüft werden können. Auf diese Weise können Anwendungsprogramme in der Überprüfung Informationen bezüglich der Daten, die sie verarbeiten, einschließlich beschreibender Informationen, liefern, welche in die Datensätze eingefügt werden, die von dem in der Überprüfung befindlichen Anwendungsprogramm selbst erzeugt werden. Die Einzelheiten hierzu werden nachfolgend genauer diskutiert, wobei jedoch der Betrieb eines solchen Mechanismus unter Bezugnahme auf Abb. 2 illustriert ist.
In Abb. 2 illustriert 200 ein Anwendungsprogramm 210, welches typischerweise ein in der Überprüfung befindliches Programm ist, und welches mit bestimmte Meßpunktparametern 201 aufgerufen werden kann. Dies kann solche Parameter beinhalten, die von einem Prüfingenieur 202 oder einem anderen Mechanismus spezifiziert werden, welche bestimmte Meßpunkte oder Meßpunktgruppen spezifiziert, die bei Aufrufen des Anwendungsprogrammes aktiviert werden. Das Anwendungsprogramm erzeugt dann Meßpunktereignisse 220, die in einer Tracerdatei 221 angeordnet werden, die Tracerdatensätze (die unten beschrieben werden sollen) enthält, welche den Status verschiedener Meßpunkte, die in das Anwendungsprogramm eingegeben wurden, anzeigen können. Bei Feststellung, daß die Meßpunktparameter 201 spezifiziert haben, daß bestimmte Meßpunkte oder Meßpunktgruppen aktiviert werden sollten, werden in der Tracerdatei 221 angeordnete Meßpunktereignisse 220 erzeugt, welche von einem zweiten Programm 230 überprüft werden können, das typischerweise ein Prüffolgen- oder anderes Anwendungsprogramm ist; das die Meßpunktereignisse 220 über die Tracerdatei 221 empfangen und verarbeiten kann. Die Tracerdatei 221 enthält Hinweise auf Datensätze, welche die Daten selbst aus dem Anwendungsprogramm 210 mit einigen identifizierenden Informationen enthaltet. Die Erzeugung und Anordnung von Datensätzen in einer Datei, wie einer Tracerdatei 221, wird von den Speicherabbildungseinrichtungen (mmap) des Sun-Betriebssystems durchgeführt, das in implementierten Ausführungen derart eingesetzt wird, daß der virtuelle Speicher, von dem unter Verwendung der implementierte Ausführungen erzeugte Datensätze abgerufen werden, als ein Speicherbild in dem Dateisystem des Computersystems 100 aufgenommen wird. In anderen Computersystemplattformen können entweder ähnliche Speicherabbildungseinrichtungen zur Dateieinrichtung oder andere Bereiche zum Speichern von Datensätzen in einem nichtlöschenden Medium (z. B. 107 in Abb. 1) verwendet werden. Dies wird jetzt diskutiert werden.
Wie bereits erläutert, werden Meßpunkte entweder von dem Anwendungsprogrammierer oder irgendeiner automatischen Vorrichtung eingegeben, die zuständig für die Eingabe solcher Meßpunkte an vorbestimmten Punkten innerhalb eines Anwendungsprogrammcodes (Primär- oder Zielcode) ist. Der Anwendungsprogrammierer verweist auf die hier zu diskutierenden indem er einen Hinweis in seinen Primärcode in der Anfangsdatei eingibt, wie "tnf_probth" oder einfach "probe.h", was eine Sammlung oder "Bibliothek" der "Bausteine" zur Meßpunkterstellung ist Muster von Hinweisen auf die in probe.h definierten Typen werden in den nachfolgenden beschreibenden Programmierseginenten gezeigt. Meßpunkte können entweder durch Gruppen oder spezifische Meßpunktnamen selektiv freigegeben oder unwirksam gemacht werden. Es wird vorweggenommen, daß in bestimmten implementierten Ausführungen ein Verfahren, um Meßpunkte freizugeben und unwirksam zu machen, von einem Programmierer benutzt wird, der gegebene Meßpunkte bei Aufruf des in der Überprüfung befindlichen Anwendungsprogrammes aktivieren möchte. Andere Arten zur Aktivierung von Meßpunkten, die innerhalb des Primärcodes eines bestimmten Programmes vorhanden sind, können in der Systemlaufzeit gemäß einer bestimmten Implementierung aktiviert oder deaktiviert werden.
Wenn Meßpunkte einmal freigegeben sind, erzeugen die Meßpunkte jeweils Informationen mittels Ereignissen, wie den Meßpunktereignissen 220, die in der Tracerdatei 221 gespeichert sind, die eine Sammlung von Tracer-"Datensätzen" in einem einzigen vorbestimmten implementierungsabhängigen Format ist. Für die Zwecke des Restes dieser Anmeldung verwenden implementierte Ausführungen der vorliegenden Erfindung ein Standardverfahren zum Darstellen von Daten, die von in den Primärcode eines Anwendungsprogrammes eingegebenen Meßpunkten erhalten werden, in einem als "Tracernormalformat" (TNF) bekannten Format, das auf viele verschiedene Arten für unterschiedliche implentierungsabhängige Anwendungen gelesen, verarbeitet und sonstwie gehandhabt werden kann. Die Datensätze in dieser Datei können derart geordnet werden, daß sie sich in einer kausalen Reihenfolge zwischen Maschinen oder in einer zeitlichen Reihenfolge innerhalb einer bestimmten Maschine befinden. Sie können auch so geordnet werden, daß die Tracerdatei mit allen den Informationen beginnt, die erforderlich sind, um den Rest der Datei zu interpretieren. In einer Ausführung kann der Erzeuger der TNF-Datei Meßpunktdatensätze filtern oder entfernen, welche nicht laufend von Interesse sind, um genau das herauszuziehen, was aus der Perspektive eines bestimmten Prüfingenieurs oder einer Prüffolge von Interesse ist.
So kann die Tracererzeugung 301, wie von dem Anwendungsprogramm 210 oder einem anderen in der Überprüfung befindlichen Programm, wie in Abb. 2 gezeigt, Zwischeninformationen 302, wie den Tracerdatensatz in Tracemormalformat, erzeugen. Dann werden diese Zwischeninformationen 302 beispielsweise von einem Prüfprogramm oder einer anderen Vorrichtung zu einer Tracermischdatei 303 verarbeitet. Dann kaum ein Verfahren, das eine Tracermischfunktion 303 erfüllt, die Zwischeninformationen 302 aufnehmen und sie entweder in kausaler oder anderer Reihenfolge sortieren und alle Informationen in einem Tracernormalformat 304 anordne. Wenn die Tracernormalformatdatei einmal erzeugt ist, dann können bestimmte Tracervorrichtungen 305, wie von einem Prüfingenieur oder einer anderen die Daten überprüfenden Person, die Informationen verwenden, um die Informationen von Interesse herauszuziehen.
Implementierte Ausführungen der vorliegenden Erfindung liefern eine Vorrichtung zur Identifizierung der Datensätze und somit der Daten, die den von Meßpunktereignissen erzeugten Datensätze enthalten sind. Auf diese Weise müssen die Prüffolge oder der Prüfingenieur, welche die Überprüfung des in der Überprüfung befindlichen Programmes durchführen, keine detaillierten Informationen über die in dem überprüften Programm enthaltenen Daten besitzen. Stattdessen können spezielle Datensätze überprüft werden und durch dieses Speicherschema der als Tracemormalformat bekannten Daten können die in den Ereignisdatensätzen enthaltenen Daten bestimmt werden. Die Einzelheiten und die Mechanismen hierzu werden jetzt diskutiert.
Die Ergebnisse des Ablaufs eines in der Überprüfung befindlichen Anwendungsprogrammes, bei welchem Meßpunktparameter spezifiziert sind, ist eine Sammlung von Tracerdatensätzen, die als eine Tracerdatei bekannt ist. Eine Tracerdatei ist in Tracernormalformat (TNF) dargestellt und beinhaltet einen Wurzeldatensatz, der verwendet wird, um eine TNF-Analyse erstmalig zu laden. Bei den implementierten Ausführungen der vorliegenden Erfindung gibt es eine minimale Menge von Formatabhängigkeiten, von denen dieses erstmalige Laden abhängt. Wie in Abb. 4 illustriert, umfaßt eine Wurzeldatei wie 400 ein Feld 401, das eine selbstbezogene Hinweisadresse enthält, und ein zweites Feld 403, welches auf einen Datensatz 420 verweist, der eine ASCII-Zeichenfolge enthält, welche die Namen der Felder in ihrer Reihenfolge in dem Datensatz liefert. Die Namen in 420 beginnen nach zwei ersten Feldern in dem Datensatz, die übergeordnete Informationen enthalten. In den implementierten Ausführungen ist die Zeichenfolge eine Leerkette, ein Fachmann kann jedoch erkennen, daß die Zeichenfolge auch in einem anderen Format, beispielsweise mit einem Längenfeld, das dem Inhalt der Zeichenfolge vorausgeht, dargestellt sein kann. Anders als bei dem ersten und dritten Feld 403 müssen beispielsweise in einem TNF-Datensatz, der einen Hinweis auf eine die Namen der Datensätze enthaltende Zeichenfolge enthält, keine weiteren Felder in TNF-Datensätzen bestimmt werden. Einzelheiten hierzu werden unter Bezugnahme auf einige spezifische Beispiele hiernach erläutert.
Wie in Abb. 4 und dem beschreibenden, unten gezeigten Segment illustriert, werden Wurzeldatensatznamen mit vorangestelltem tnf_root verwendet, um Dateien mit Hinweissymboldatensätzen anzuzeigen, die alte tnf_tag- und tnf_Operations-Felder in denselben Positionen, wie in dem Wurzeldatensatz beobachtet, umfassen. Das mit tnf_operations, oder einfach operations, bezeichnete Feld wird während der Analyse von Prüfroutinen verwendet, um eine Hinweisadresse auf die Interpretationsabläufe für die Art von Datensatz zu halten, die von dem zugehörigen Hinweissymboldatensatz beschrieben ist. Der Datensatz, der beschrieben wird, weist auf seinen Hinweissymboldatensatz hin, wie bei allen Datensätzen dieses Typs. Das operations-Feld des Hinweissymboldatensatzes wird verwendet, um Zugang zu Abläufen zu erhalten, welche diese Art von Datensatz schnell verarbeiten, beispielsweise um Koerzions- oder Übertragungsoperationen oder andere Arten von Operationen durchzuführen, welche häufig während der Analyse durchgeführt werde.
Das tnf_tag Feld in einem Datensatz, wie als 401 in Abb. 4 gezeigt, ist ein Feld, dessen Name "tnf_tag" als ein Präfix beinhaltet. Ein Wurzeldatensatz wie 400 hält eine selbstbezogene Hinweisadresse auf eine "Hinweissymboldatensatz", der den Datensatz beschreibt. Somit beschreibt sich ein Wurzeldatensatz, wie der als 400 in Abb. 4 gezeigte, selbst, wohingegen andere Hinweissymboldatensätze in der TNF Dateistruktur typischerweise andere Datensätze beschreiben. Ein Beispiel für einen tnf_root-Datensatz ist als 400 in Abb. 4 gezeigt, und ein beschreibendes Codesegment, das benutzt wird, um den Datensatz zu spezifizieren, ist unten gezeigt. Das "Slots-Feld" 403 enthält eine Hinweisadresse auf eine Zeichenfolge, die alle Felder in dem Datensatz identifiziert. Anders als bei anderen Datensätzen, die sich nicht selbst beschreiben, beschreibt die Zeichenfolge alle Datensätze, die innerhalb des tnf_root-Datensatzes 400 enthalten sind. Dies bedeutet, daß jedes mit einem Semikolon abgegrenzte Paar aus Zeichenfolgen den TNF-Typ und den Namen des in dem Datensatz enthaltenen Feldes anzeigt. So gibt es eine 1 : 1-Entsprechung zwischen jedem der in dem Wurzeldatensatz enthaltenen Felder und jedem der mit einem Semikolon abgegrenzten Zeichenfolgenpaare 420, auf die von Feld 403 verwiesen wird. Auf diese Weise sind die in dem Wurzeldatensatz enthaltenen Daten selbstbeschreibend, so daß, wenn einmal das "Slots"-Feld adressiert ist, es verwendet werde kann, um den Inhalt des TNF-Wurzeldatensatzes in diesem Fall zu bestimmen. Für andere Hinweissymboldatensätze wird dieses Feld verwendet, um den Datensatz zu beschreiben, der auf den Hinweissymboldatensatz hinweist. Dies wird in größeren Einzelheiten unten gezeigt.
In dem beschreibenden Segment unten werden mit Doppelpunkt beendete Namen einfach für Notationszwecke verwende, da sie den Namen des Feldes anzeigen, aber nicht in der Datei erscheinen. Diese erscheinen auch in 400 in Abb. 4, obwohl die Inhalte der aktuellen Felder nach dem Doppelpunkt gezeigt sind. Pfeile in dem beschreibenden Segment werden verwendet, um einen Hinweis auf einen anderen Datensatz anzuzeigen, dessen Inhalte von dem Pfeil adressiert werden. So enthalten in der Abbildung Felder wie 403 und 404 tatsächlich Hinweise auf Datensätze, welche die den Datensatz beschreibenden Zeichenfolgen enthalten. Das Slots-Feld 403 wurdet bereits erläutert, jedoch enthält das Feld 404 auch einen Hinweis auf einen anderen Datensatz 430, der eine Zeichenfolge enthält, welche der Name des Datensatzes "tnf_root_1" ist. Inhalte in dem Codesegment unten sind selbstbezogene Hinweise auf den Namendatensatz - welche von Doppel-Kolon-Endungen in der Notation identifiziert werden.
Die in dem oben dargelegten Beispiel und in Abb. 4 illustrierten Zeichenfolgen sind selbst TNF-Datensätze (z. B. 420 und 430), d. h. tnf_string-Datensätze, welche Einbyte-ASCII- Zeichen-Datenfelder sind. In dieser Implementierung sind die Namen der Felder und die Namen der Typen in den Zeichenfolgen codiert, wie sie oben gezeigt sind, und beschreiben, was sich genau in der Datei befindet. In anderen Implementierungen können die Namen und Typen in separaten Feldern codiert sein, wie nachfolgend erläutert werden wird. TNF-Dateien, wie bereits diskutiert, halten die selbstbeschreibenden Daten, so daß eine Analysenroutine oder ein anderes nachverarbeitendes Programm den Inhalt der TNF-Daten, bestimmen kann. Das size-Feld 405 zeigt die Größe in Bytes des beschriebenen Datensatzes an. Wenn jedes Feld 4 Bytes in der Länge aufweist, entspricht die Größe in diesem Beispiel 28 in Feld 405. Das object-Feld 406 zeigt in diesem Beispiel ein gemeinsames Objekt an, das Abläufe anzeigt, deren Namen diejenigen der TNF-Typen sind, die Interpretationen spezifiziert haben. Diese Abläufe liefern eine Gruppe von Operationen an den spezifizierten Typen. Das platform-Feld kann verwendet werden, um das gemeinsame Objekt oder die Operationen in ihm zu qualifizieren, wenn es wichtig ist die Plattformart zu bestimmen, welche die Quelle für die in der TNF-Datei enthaltenen Daten war. Beispielsweise kann es bei verschiedenen Gesamtausstattungen, welche eine "Big endian/little endian"-Byteordnung unterstützen, wichtig sein, die Plattform zu kennen, in welcher die Daten erstellt wurden, damit eine Koerzion der Daten stattfinden kann, bevor sie von der Analysenroutine verarbeitet werden.
In der TNF-Darei sind ein Wurzeldatensatz und eine Anzahl von Datensätzen enthalten, die das Basistypensystem der TNF-Datei definieren. Es gibt eine erhebliche Anzahl von Datensätzen, welche Tracerereignisse in den Tracerdateien registrieren. Solch ein Ereignisdatensatz und die zugehörigen Datensätze, welche den Inhalt des Ereignisdatensatzes definieren, sind unter Bezugnahme auf Abb. 5 und die beschreibenden, unten nachfolgenden Segmente illustriert. Obwohl wieder bestimmte Feldnamen in den Abbildungen aufgelistet sind, wurde dies nur aus Notations- und Bequemlichkeitsgründen vorgenommen, und die aktuellen Inhalte des Feldes variieren gemäß dem spezifischen Feldnamen. Auf jeden Fall enthält ein Ereignisdatensatz 550 drei Wörter 551-553. Das erste Feld 551 ist in zwei Bereiche 551a und 551b unterteilt, welche spezifizierte Bedeutungen aufweisen. Die erste Hälfte des Wortes 551a ist ein Hinweissymbol (tag) (z. B.) eine Hinweisadresse oder ein anderer Hinweis), welches auf den Hinweissymboldatensatz, der das Ereignis beschreibt, hinweist. Der zweite Bereich 551b des ersten Wortes 551 ist ein Zuordnungs-Offset, der ein Zuordnungsdatensatz ist, der den Ereignisdatensatz kennzeichnet. Dieser Zuordnungsdatensatz ist selbst ein Ereignisdatensatz, der als 560 in Abb. 5 gezeigt ist, und enthält Informationen, wie "thread ID", Absolutzeit und andere Informationen. Solch ein Datensatz kann irgendeine Art von Informationen aufweisen, die aus Übersichtsgründen in der Abbildung weggelassen wurde. Das nächste Feld 552 in dem Ereignisdatensatz zeigt die Zeit in Nanosekunden bezüglich des führenden Wortes der 64-Bit- Absolutzeit an, welches in den für das Ereignis adressierten Zuordnungsdatensatz 560 eingefügt wurde. Das Adressenfeld 553 enthält in einigen implementierten Ausführungen ebenfalls einen Hinweis auf die Daten, die geprüft wurden und das Ereignis bewirkten. Dies kann bestimmte Informationen liefern, wie die Stelle, an welcher die geprüfte Variable angeordnet war.
In diesem Beispiel ist das Hinweissymbol als vm_minor_fault-Datensatz bekannt, der als 500 in Abb. 5 gezeigt und in dem unten folgenden beschreibenden Segment illustriert ist:
Das operations-Feld in dem oben gezeigten Hinweissymboldatensatz kann in dieser Implementierung von Analysenroutinen benutzt werden, um die Hinweissymboldatensätze, auf die von Ereignisdatensätzen hingewiesen wird, mit den spezifizierten Operationen an den Ereignisdatensätzen zu verbinden. Der Hinweissymboldatensatz für das Ereignis beschreibt auch den Inhalt des Ereignisdatensatzes 550 (in dem "slots"-Feld des Hinweissymboldatensatzes) und die Anzahl von Bytes des Ereignisdatensatzes (in dem "size"-Feld) und fügt einen Hinweis auf eine Zeichenfolge ein, welche den Typ des Ereignisdatensatzes benennt (das "name"-Feld des Hinweissymboldatensatzes). Dieser Hinweissymboldatensatz vm_minor_fauft wird von dem Hinweissymboldatensatz 510 beschrieben, der von dem vm_minor_fault Hinweissymboldatensatz 500 über Feld 501 adressiert wird. Dies ist auch in dem beschreibenden, unten nachfolgenden Segment gezeigt. So definiert der Hinweissymboldatensatz 500 den Inhalt des Meßpunktereignisdatensatzes 550, wie in dem slots-Feld des oben illustrierten Segmentes gezeigt. Wieder sind diese Datensätze aus Vereinfachungsgründen nicht in Einzelheiten in dem in Abb. 5 gezeigten Blockdiagramm der Datensätze selbst illustriert, sondern, ähnlich wie die in Abb. 4 illustrierten Datensätze, sind die slots-Felder und die name-Felder aus Bequemlichkeits- und Notationsgründen tatsächlich nur Hinweise auf Zeichenfolgendatensätze, welche Zeichenfolgen enthalten, die den Hinweissymboldatensatz identifizieren.
In einer anderen Implementierung können die TNF-Datensätze in einer leicht abweichenden Weise formatiert sein. In dieser alternativen Implementierung kann der oben diskutierte vm_minor_fault-Datensatz in der Weise formatiert sein, wie von dem nachfolgenden beschreibenden Segment illustriert:
Es ist festzuhalten, daß der Datensatz ähnlich demjenigen ist, der unter Bezugnahme auf das oben gezeigte und in Abb. 5 illustrierte beschreibende Seginent beschrieben ist; wobei jedoch das operations-Feld hier mit "tag code" bezeichnet ist und das name-Feld bei dem dritten Wort des Datensatzes angeordnet ist. Genauer ist das "slots"-Feld in zwei separate Felder unterteilt worden: slot_types und slot_names. In diesen Beispiel ist slot_types ein Hinweis auf ein Datenfeld, das Hinweise auf jeden der Typen für jedes der in dem Datensatz benannten Felder enthält. Dem slot_types-Feld folgt dann ein slot_names-Feld, das auf die Zeichenfolge hinweist; welche die Namen für jedes der Felder auflistet, deren Typen in dem slot_types-Feld spezifiziert sind. Die restlichen Felder in dem Datensatz sind im wesentlichen dieselben wie in Abb. 5 illustriert, nur, wie oben beschrieben, mit diesen geringfügigen Änderungen. In jeder Implementierung ist es wichtig daß bestimmte Datensätze an vorbestimmten Stellen in dem TNF-Datensatz erscheinen, so daß die Routine, welche die Datensätze in der TNF- Tracerdatei Überprüft die Art der in ihr enthaltenen Daten bestimmen kann. Das bestimmte Format, das unter Bezugnahme auf das kurze modifizierte Codesegment in dieser alternativen Ausführung, wie oben illustriert, beschrieben ist, ist Illustrativ für einen einzelnen Datensatz in dem detaillierteren TNF-Format, das in dem nachfolgenden Anhang A dargestellt ist. In dem Rest dieser Anmeldung werden jedoch aus Konsequenzgründen die zuvor erwähnten Implentierungen diskutiert; um eine Verwirrung in der vorliegenden Erfindung zu vermeiden.
Wie bereits oben diskutiert; weisen die Hinweissymboldatensätze selbst auf Hinweissymboldatensätze hin, welche die Inhalte der Hinweissymboldatensätze für Datensätze, wie Meßpunktereignisdatensätze, beschrieben. Diese sind als "Basis"-TNF-Typen bekannt und allgemein als 510-530 in Abb. 5 gezeigt. Hinweissymboldatensätze weisen, wie bereits diskutiert, Hinweissymbolfelder auf, die auf Datensätze hinweisen, welche auch die Hinweissymboldatensätze beschreiben, und dies setzt sich rekursiv bis zu dem Wurzeldatensatz (z. B. 400 in den Abb. 4 und 5) fort. Der vm_minor_fault Hinweissymboldatensatz 500 wird von einem Hinweissymboldatensatz 510 beschrieben, der in dem Beispiel mit dem Namen tnf_strct_1 gezeigt ist. Der Hinweissymboldatensatz 510 kann auch dadurch gekennzeichnet sein, daß er operations, slots, ein name und ein size aufweist. Dies wird von dem beschreibenden nachfolgenden Segment gezeigt:
Datensatz 510 weist auf einen anderen Hinweissymboldatensatz 520 hin, der den Inhalt des Hinweissymboldatensatzes 510 definiert. Dies setzt sich rekursiv bis zu Datensatz 530 fort. Schließlich enthält der Datensatz 530 tnf base_1 einen Hinweis in seinem tag-Feld 531, der auf den in Abb. 5 illustrierten Wurzeldatensatz tnf_root_1 400 hinweist, der oben unter Bezugnahme auf Abb. 4 diskutiert wurde. Wieder enthält 400, das es sich um einen Wurzeldatensatz handelt, selbstbeschreibende Informationen in seinem slots-Feld, und er enthält ein selbsthinweisendes Hinweissymbol in seinem tag-Feld 401. Auf diese Weise wissen die Analysenroutinen, daß dies der Wurzeldatensatz ist. Zusätzlich muß der Datensatz tnf_base_1, da er von dem Wurzeldatensatz 400 beschrieben wird, das exakt selbe Format wie der Wurzeldatensatz aufweisen, jedoch ist er der einzige Datensatz, der in dieser Implementierung diese Erfordernis aufweist. Die beschreibenden Segmente für tnf_struct-1 und tnf_base sind unten gezeigt:
Der Hinweissymboldatensatz, der von dem Wurzeldatensatz beschrieben wird, muß wie die Wurzel aussehen (aber in diesem Schema ist er der einzige, der das muß):
Die oben beschriebenen TNF-Typen sind selbst auch TNF-Typen. Diese werden von Datensätzen beschrieben, welche auch Hinweissymbole enthalten, die auf Datensätze hinweisen, welche die Typen beschreiben. Ein Beispiel hierfür ist unter Bezugnahme auf Abb. 6 gezeigt. 600 in Abb. 6, nämlich der tnf_tag-Datensatztyp, enthält ein tag-Feld 601, das in diesem Beispiel auf einen Datensatz tnf_base_type 1 hinweist. Ähnlich kann ein tnf_byte_1- Typ von einem Datensatz 610 dargestellt werden, der auch ein Hinweissymbol 611 auf den in Abb. 6 gezeigten tnf_base_type_1 620 enthält. Der tnf_base_type_1-Datensatz 620 enthält ferner ein Hinweissymbol 621, das auf einen der unter Bezugnahme auf Abb. 5 illustrierten Datensätze zurückverweisen kann, d. h. den in Abbildung S als Hinweissymboldatensatz 520 gezeigten tnf_struct_1-Basistyp. Dann setzen sich die Hinweise wie zuvor unter Bezugnahme auf Abb. 5 diskutiert fort. Die beschreibenden Segmente für die zuvor beschriebenen drei Datensätze sind unten gezeigt. Der tnf_tag-Datensatz 600 kann wie folgt erscheinen:
Ein tnf_byte_1-Datensatz (z. B. 610 aus Abb. 6) kann aussehen wie:
Diese Hinweissymboldatensätze für diese Typen weisen auf einen tnf_base_ type-Hinweissymboldatensatz für ihre Beschreibungen hin:
Schließlich betrifft der letzte hier beschriebene Datensatztyp die Handhabung von Datenfeldern und Zeichenfolgen in implementierten Ausführungen der vorliegenden Erfindung. Diese sind unter Bezugnahme auf Abb. 7 illustriert. Eine tnf_string besteht aus einer Kopfzeile, der ein mit einer Leerfolge endendes, wortaufgefülltes Datenfeld aus Ein-Byte-Elementen folgt. Die Kopfzeile umfaßt ein tag-Feld, das als 701 in Abb. 7 gezeigt ist, ein operations-Feld und ein Feld, das die Größe des Datensatzes in Bytes enthält. Der Datensatz enthält auch einen Kontrollwert für die Zeichenfolge, um die Funktion des Anpassens von Zeichenfolgen bestimmter Symbole zu verbessern, die gegen andere Symbole verwendet werden, wie in dem nachfolgenden beschreibenden Segment illustriert:
Ein tnf_byte weist auf einen Hinweissymboldatensatz tnf_base_type (z. B. 610) hin, wie bereits unter Bezugnahme auf Abb. 6 diskutiert.
Ein Datenfeld wird von einem Hinweissymboldatensatz beschrieben, der ein tnf_base_array ist:
Eine Illustration der beiden Datensätze ist in Abb. 7 gezeigt. 700, der tnf_string-Datensatz weist ein Hinweissymbol in Feld 701 auf, das sich auf den zweiten Datensatz tnf_base_array_1 bezieht, der auf den in Abb. 5 gezeigten und oben bereits diskutierten tnf_struct-1 520 hinweist. In jedem Fall können entweder Datenfelder oder Zeichenfolgen unter Verwendung der Datensätze 700 und 710 in implementierten Ausführungen der vorliegenden Erfindung dargestellt werden, welche dann über die Tracerdatei der nachverarbeitenden Analysenroutine übermittelt werden, die Zeichenfolgen und Datenfelder überprüfen kann, die in einem in der Überprüfung befindlichen Programm vorhanden sein können.
Ein detaillierter Speicherauszug der TNF-Strukturen, welche in einer bestimmten implementierten Ausführung der vorliegenden Erfindung verwendet werden, ist in Anhang A gezeigt. Es ist festzuhalten, daß jeder der Datensätze, der in der in Anhang A gezeigten "Tracer- ASCII"-Datei gezeigt ist, ein zugehöriges Feld tnf_tag aufweist, das eine hexadezimale Hinweisadresse auf den zugehörigen Hinweissymboldatensatz enthält. So können durch Anpassung der Adresse, welche der TNF-Definition vorausgeht, und der in dem tnf_tag-Feld jedes der Datensätze in dem Speicherauszug gespeicherten Adresse die Verbindungen der verschiedenen, in einer TNF-Tracerdatei erzeugten Datensätze untereinander bestimmt werden.
Die vorangehenden, in den Abb. 3-7 gezeigten Beispiele für solche TNF-Dateien sind nur für illustrative Zwecke gezeigt und nicht dafür bestimmt, die vorliegende Erfindung zu begrenzen. So wurde ein umfassendes System zur Darstellung von Daten in einem ersten Anwendungsprogramm zur Darstellung von Daten, wie das für Prüfanwendungen, und zum Erzeugen von Datensätzen und zugehörigen Tracerdateien, die beispielsweise von einem zweiten Anwendungsprogramm überprüft werden können, und eine Analysenroutine beschrieben. Das Liefern von Daten von der ersten Routine zu der zweiten Routine ist somit ein wesentlicher Vorteil gegenüber den Verfahren des Standes der Technik, die erfordern, daß das Analysenprogramm und/oder der Prüfingenieur den Datentyp kennen, der in dem in der Überprüfung befindlichen Programm dargestellt ist, da jetzt die Daten eng mit Datensätzen codiert sind, welche die Daten selbst beschrieben, und solch eine Codierung kann derart eingerichtet werden, daß die Beziehung zwischen den Daten und der Beschreibung der Daten von einem Prozeßadressenraum andern ohne Veränderungen ohne Veränderungen Codierung angepaßt werden kann. Dies ist eine wesentliche Verbesserung gegenüber dem Stand der Technik, und es wird ein einzigartiger Vorteil geboten, der von dem Stand der Technik bisher weder durchgeführt noch gelehrt wurde. Obwohl die vorliegende Erfindung unter Bezugnahme auf spezifische Ausführungen in den Abb. 1-7 und dem beigefügten Anhang A beschrieben wurde, sind diese nicht dafür bestimmt, die vorliegende Erfindung zu begrenzen, und die vorliegende Erfindung ist nur als von den anhängenden, nachfolgenden Ansprüchen begrenzt zu betrachten.
Appendix A

Claims

1. Computer-implementiertes Verfahren in einem Computersystem (100) zum Liefern von Daten von in ein erstes Anwendungsprogramm (210) eingegebenen Meßpunkten während der Laufzeit an ein zweites Anwendungsprogramm (230), wobei die Daten in einem vorbestimmten Format dargestellt und als Tracerdatensätze gespeichert sind, mit den folgenden Schritten:

a. Einfügen einer Verbindung zu der Bibliothek der Datentypen in die erste Anwendung (210), um Meßpunkte in dem ersten Anwendungsprogramm (210) zu beschreiben, wobei die Bibliothek der Datentypen die Überprüfung der Meßpunkte in dem ersten Anwendungsprogramm (210) ermöglicht, welches die Datentypen aus dem zweiten Anwendungsprogramm (230) aufweist, wobei die Bibliothek der Datentypen eine Definition eines Ereignisdatensatzes (550), der als ein Tracerdatensatz gespeichert ist, umfaßt;

b. Eingeben eines Meßpunktes (220) an einem vorbestimmten Punkt innerhalb des ersten Anwendungsprogramms (210) gemäß der Typenbibliothek;

c. Freigabe des Meßpunktes, um den Ereignisdatensatz in dem vorbestimmten Format zu erzeugen;

d. Erzeugen von Daten (221) in einem Ereignisdatensatz (550) durch den Meßpunkt von dem ersten Anwendungsprogramm, wobei der Ereignisdatensatz (550) umfaßt:

i. eine Vielzahl von Feldern, wobei wenigstens eines aus der Vielzahl der Felder die von dem ersten Anwendungsprogramm (210) erzeugten Daten enthält und andere aus der Vielzahl der Felder Informationen enthalten, welche die erzeugten Daten beschreiben;

ii. wobei eines aus der Vielzahl der Felder (551a) einen Hinweis auf einen Hinweissymboldatensatz (500) enthält, wobei der Hinweissymboldatensatz (500) Namen und Typen einer Vielzahl von Feldern (551, 552, 553) in dem Hinweisereignisdatensatz (550) auflistet, wobei der Hinweissymboldatensatz (500) ferner rekursiv auf eine Vielzahl von Hinweissymboldatensätzen (510, 520, 530, 400) verweist, welche jeweils auf einen zugehörigen Hinweissymboldatensatz verweisen, der Namen und Typen von Feldern in einem Hinweissymboldatensatz, auf den verwiesen wurde, auflisten, und welche schließlich auf einen selbstbeschreibenden Wurzeldatensatz (400) verweisen, der einen Selbsthinweis (401) und Felder (420) umfaßt, welche Namen und Typen einer Vielzahl von Feldern in dem Wurzeldatensatz (400) auflisten;

e. wobei ein zweites Anwendungsprogramm (230) den Ereignisdatensatz empfängt und auf die erzeugten Daten (221), den Hinweissymboldatensatz (500) und die Vielzahl von Hinweissymboldatensätzen (510, 520, 530, 400) rekursiv hinweist, bis es den Wurzeldatensatz (400) erreicht; und

f. wobei die zweite Anwendung (230) die Daten (221) gemäß dem Hinweissymboldatensatz (500) und der Vielzahl von Hinweissymboldatensätzen (510, 520, 530, 400) verarbeitet, wobei das zweite Anwendungsprogramm (230) in der Lage ist, eine Diagnose des ersten in Überprüfung befindlichen Programmes (210) ohne Bezugnahme auf andere Informationen als die erzeugten Daten (221) zu erstellen.

2. Verfahren gemäß Anspruch 1, bei welchem der Hinweissymboldatensatz (500) ferner ein Plattformfeld (407) umfaßt, um eine Plattform zu spezifizieren, bei welcher die Daten (221) ursprünglich sind.

3. Verfahren gemäß Anspruch 1, bei welchem der Hinweissymboldatensatz (500) ferner ein Operationsfeld (402) umfaßt, um von dem zweiten Anwendungsprogramm (230) während der Verarbeitung der Daten (221) benutzt zu werden.

4. Verfahren gemäß Anspruch 1, bei welchem der Hinweissymboldatenstz (500) ferner ein Größenfeld (405) umfaßt, um von dem zweiten Anwendungsprogramm (230) zur Bestimmung der Größe des Bezugsdatensatzes (550) benutzt zu werden.

5. Verfahren gemäß Anspruch 1, bei welchem der Hinweissymboldatenstz (500) ferner ein Namenfeld (404) umfaßt, um die Daten (221) zu identifizieren.

6. Verfahren gemäß Anspruch 1, bei welchem der Ereignisdatenstz (550) ferner Felder (551, 552, 553) umfaßt, welche ein Laufzeitereignis in dem ersten Anwendungsprogramm (210) identifizieren.

7. Verfahren gemäß Anspruch 6, bei welchem die Felder in dem Ereignisdatensatz (550) ein Typenfeld (551) umfassen, um einen Typ eines Laufzeitereignisses zu identifizieren, welches in dem ersten Anwendungsprogramm (210) aufgetreten ist.

8. Verfahren gemäß Anspruch 6, bei welchem die Felder in dem Ereignisdatensatz (550) ein Zeitfeld (552) umfassen, welches einen Zeitpunkt identifiziert, an dem das Laufzeitereignis in dem ersten Anwendungsprogramm (210) aufgetreten ist.

9. Verfahren gemäß Anspruch 8, bei welchem das Zeitfeld (552) einen Wert enthält, der einen relativen Zeitpunkt in dem ersten Anwendungsprogramm (210) darstellt, an dem das Laufzeitereignis aufgetreten ist.

10. Verfahren gemäß Anspruch 6, bei welchem die Felder in dem Ereignisdatensatz (550) ein Adressenfeld (553) umfassen, welches eine Adresse identifiziert, bei welcher das Laufzeitereignis in dem ersten Anwendungsprogramm (210) aufgetreten ist.

11. Verfahren gemäß Anspruch 1, bei welchem sich der Hinweis (551a) auf den Hinweissymboldatensatz (500) an einer vorbestimmten Position von dem Beginn des Ereignisdatensatzes (550) befindet.

12. Vorrichtung in einem Computersystem (100) zum Liefern von Daten (221), die von in ein erstes Anwendungsprogramm (210) eingegebenen Meßpunkten erzeugt werden, während der Laufzeit an ein zweites Anwendungsprogramm (230), wobei die Daten in einem vorbestimmten Format dargestellt und als Tracerdatensätze gespeichert sind, mit:

a. Vorrichtungen zum Einfügen einer Verbindung zu der Bibliothek der Datentypen in die erste Anwendung (210), um Meßpunkte in dem ersten Anwendungsprogramm (210) zu beschreiben, wobei die Bibliothek der Datentypen die Überprüfung der Meßpunkte in dem ersten Anwendungsprogramm (210) ermöglicht, welches die Datentypen aus dem zweiten Anwendungsprogramm (230) aufweist, wobei die Bibliothek der Datentypen eine Definition eines Ereignisdatensatzes (550), der als ein Tracerdatensatz gespeichert ist, umfaßt;

b. Vorrichtungen zum Erzeugen eines Ereignisdatensatzes (550) von dem ersten Anwendungsprogramm (210) in der Laufzeit, wobei ein Meßpunkt (220) an einem vorbestimmten Punkt innerhalb des ersten Anwendungsprogrammes (210) gemäß der Typenbibliothek eingegeben ist, und zum Freigeben des Meßpunktes, um den Ereignisdatensatz in dem vorbestimmten Format zu erzeugen, wobei der Ereignisdatensatz (550) umfaßt:

ii. wobei eines aus der Vielzahl der Felder (551a) einen Hinweis auf einen Hinweissymboldatensatz (500) enthält, wobei der Hinweissymboldatensatz (500) Namen von jedem aus der Vielzahl von Feldern (551, 552, 553), welche in dem Ereignisdatensatz (550) enthalten sind, auflistet, wobei der Hinweissymboldatensatz (500) ferner rekursiv auf eine Vielzahl von Hinweissymboldatensätzen (510, 520, 530, 400) verweist, welche jeweils auf einen zugehörigen Hinweissymboldatensatz verweisen, der Namen und Typen von Feldern in einem Hinweissymboldatensatz, auf den verwiesen wurde, auflisten, und welche schließlich auf einen selbstbeschreibenden Wurzeldatensatz (400) verweisen, der einen selbstverweisenden Hinweissymboldatensatz (401) umfaßt, welcher die Felder in dem Wurzeldatensatz (400) identifiziert;

c. Vorrichtungen zum Empfangen des Ereignisdatensatzes (550) für das zweite Anwendungsprogramm (230) und Vorrichtungen zum rekursiven Hinweisen auf den Hinweissymboldatensatz (500) und jeden aus der Vielzahl der zugehörigen Hinweissymboldatensätze (510, 520, 530, 400) bis zum Erreichen des Wurzeldatensatzes (400), um die Daten (221) durch Verweisen auf die Vielzahl von Feldern in jedem der zugehörigen Hinweissymboldatensätze (510, 520, 530, 400) zu identifizieren; und

d. Vorrichtungen zur Verarbeitung der erzeugten Daten (221) in der zweiten Anwendung (230) gemäß der Identifikation der Daten (221), welche von dem Ereignisdatensatz (550), dem Hinweissymboldatensatz (500) und jedem aus der Vielzahl von zugehörigen Hinweissymboldatensätzen spezifiziert sind, wobei das zweite Anwendungsprogramm (230) in der Lage ist, eine Diagnose des ersten in Überprüfung befindlichen Programmes (210) ohne Bezugnahme auf andere Informationen als die erzeugten Daten (221) zu erstellen.