DE69031538T2

DE69031538T2 - System und Verfahren zur Sammlung von Softwareanwendungsereignissen

Info

Publication number: DE69031538T2
Application number: DE69031538T
Authority: DE
Inventors: Philip K Royal
Original assignee: Digital Equipment Corp
Current assignee: Digital Equipment Corp
Priority date: 1990-02-26
Filing date: 1990-12-28
Publication date: 1998-05-07
Anticipated expiration: 2010-12-29
Also published as: JPH0810440B2; DE69031538D1; EP0444315B1; EP0444315A3; JPH04218845A; CA2033589A1; US5446878A; EP0444315A2; CA2033589C

Description

Hintergrund der Erfindung

Diese Erfindung bezieht sich allgemein auf Ereignissammel systeme für Software-Anwendungen.
Die meisten Ereignissammelsysteme für Software-Anwendungen sind "zeitgeberbasiert", d.h., sie sammeln zu spezifizierten Zeitintervallen Daten von einem Anwendungsprogramm. Da zu irgendeinem vorgegebenen Zeitpunkt zufällige Teile der Anwendung ausgeführt werden, muß die tatsächliche Frequenz der in den gesammelten Daten vorkommenden Ereignisse als eine mittlere oder geschätzte Frequenz berechnet werden. Dagegen sammeln sogenannte "ereignisbasierte" Bewertungssysteme Daten an spezifizierten Stellen in der Anwendung, so daß sie nicht eine geschätzte, sondern die tatsächliche Ereignisfrequenz sammeln und über diese berichten. Zum Beispiel stellen Software-Austestsysteme einen Typ ereignisbasierter Bewertungssysteme dar. In Austestsystemen wird die auszutestende Anwendung an interessierenden Punkten mit Aufrufen von Dienstroutinen in einer anderen Anwendung, die das tatsächliche Austesten vornimmt, "instrumentiert". Die interessierenden Funkte werden häufig als Unterbrechungspunkte bezeichnet und enthalten z. B. die Anfänge und Enden von Unterprogrammen. Jedesmal, wenn die instrumentierten Unterprogramme ausgeführt werden, werden die mit dem Ereignis in Zusammenhang stehenden Daten als Bestandteil der Bewertung gesammelt.
Das US-Patent 4.462.077 des Standes der Technik zeigt eine Verfolgungsvorrichtung zur Verwendung in einer Mehrfachverarbeitungsumgebung in einem einzelnen Prozes sor. Eine Änderung im Verfolgungsbetrieb ist möglich durch Ändern eines Parameters in einer globalen Verfolgungstabelle und durch Ändern des Wertes eines globalen Synchronisationswortes, um anzuzeigen, daß eine Änderung in der globalen Tabelle vorgenommen wurde. Jede Verfolgungsanweisung hat ein Argument, das die Ebene seiner Wichtigkeit im Austestbetrieb anzeigt.

Zusammenfassung der Erfindung

Im allgemeinen liegt die Erfindung im weiten Sinne in einem Verfahren, das in einem Computer implementiert ist und im beigefügten Anspruch 1 angegeben ist. Eine hier im folgenden beschriebene bevorzugte Ausführungsform der Erfindung besitzt als Merkmal einen als Computersoftware ausgeführten Anwendungsereignis-Sammler, der für mehrere Zwecke wie unten in Verbindung mit einer derzeit bevorzugten Ausführungsform beschrieben ereignisbasierte Daten sammelt. Der Sammler folgt einem Verfahren, das folgende Schritte beinhaltet: (a) Speichern von Definitionen von Ereignismarkierungsbefehlen, die in die Software-Anwendung eingebettet wurden, wobei jeder Ereignismarkierungsbefehl, wenn er freigegeben ist, ereignisbasierte Daten und die Definitionen, die die Software-Anwendung identifizieren, in die die Befehle eingebettet sind, und den Typ der durch die Anweisungen gesammelten Daten sammeln kann; (b) Auswählen einer Untermenge von Ereignismarkierungsbefehlen und Freigeben dieser Befehle vor oder während der Ausführung der Software-Anwendung; und (c) Erfassen der freigegebenen Ereignismarkierungsbefehle während der Ausführung der Software-Anwendung und Sammeln der durch die Freigabebefehle spezifizierten Daten.
In bevorzugten Ausführungsformen wird die Anwendung in Schichten zerlegt, wobei in jede dieser Schichten Ereignismarkierungsbefehle eingebettet sein können. Diese Ereignismarkierungsbefehle können selektiv aus einer Anzahl von Datenelementen entweder einige oder alle Datenelemente sammeln, und ein Anwender kann auswählen, welche dieser Datenelemente zu sammeln sind. Der Anwender kann auch das Sammeln von Datenelementen sperren. Für diese Zwecke beinhalten die Definitionen der Ereignismarkierungsbefehle eine Identifikation der Software-Schicht, in die der Befehl eingebettet ist, während die Definitionen Klassen von Ereignismarkierungsbefehlen und Datenelementen, die ausgewählt werden können, beinhalten.
Der Sammler schafft verschiedene Vorteile einschließlich einer "Echtzeit"-Sammelfähigkeit, d. h. des Sammelns von Ereignisdaten von einer Anwendung, während die Anwendung in ihrer vorgesehenen Umgebung läuft. Das Gegenstück der Echtzeit-Sammelfähigkeit stellen "modellierte" Bewertungen dar, d. h. das Sammeln von Datenereignissen von einer Anwendung, während die Anwendung in einer simulierten Umgebung läuft. Diese Echtzeit-Sammelfähigkeit gestattet das Aufzeichnen nur der durch den Anwender über die Planungs-Anwenderschnittstelle spezifizierten Ereignisse, und der Sammler kann die tatsächliche Frequenz der Daten während des Ablaufs erfassen. Damit kann ein beträchtlicher (sowohl Rechen- als auch Speicher-)Ablauf-Organisationsaufwand vermieden werden. Ebenfalls kann der Sammler ereignisbasierte Daten von jeder beliebigen Kombination von Schichten innerhalb der Software-Anwendung sammeln.
Weiter schafft der Sammler das Sammeln von ereignisbasierten Daten, das als eine Grundlage zum Abstimmen der Software-Anwendungsablauf-Leistung dienen kann.
Der Sammler schafft weiter eine Grundlage zum (auch als "Kapazitätsplanung" bezeichneten) Planen der Hardware- Betriebsmittel. Das heißt, der Sammler kann die für eine Anwendung benötigten Rechen- und Speicherkapazitäten bestimmen. Die erhaltenen Daten können z. B. in ein DECcp-Kapazitätsplanungsprodukt, Version 1.1, eingegeben werden.
Der Sammler schafft weiter eine Grundlage für Austestanwendungen und zur Fehlerprotokollierung innerhalb der Anwendungen. Und schließlich ist der Sammler so beschaffen, daß er bei minimalen Leistungseinbußen der Anwendung, von der er Daten sammelt, betrieben werden kann, ferner gestattet er dem Anwender außerdem, auszuwählen, welche Daten gesammelt werden sollen. Damit kann er sowohl in Produktions- als auch in Entwicklungsumgebungen eingesetzt werden.

Kurzbeschreibung der Zeichnung

Ein genaueres Verständnis der Erfindung wird anhand der folgenden Beschreibung einer bevorzugten Ausführungsform erhalten, die als Beispiel dient und in Verbindung mit der beigefügten Zeichnung zu verstehen ist, wobei
Fig. 1 ein Blockdiagramm einer geschichteten Anwendung ist.
Fig. 2 ein Blockschaltbild der Komponenten eines Anwendungsereignis-Sammlers gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung ist.
Fig. 3 ein Ablaufplan ist, der die allgemeine Wirkung des Anwendungsereignis-Sammlers beschreibt.
Fig. 4 ein Ablaufplan ist, der die Wirkung eines Dienstroutineaufrufs des Sammlers, d. h. INIT, zeigt.
Fig. 5 ein Blockdiagramm einer von INIT unterhaltenen Datenstruktur ist.
Fig. 6 ein Ablaufplan ist, der die Wirkung eines Dienstroutineaufrufs des Sammlers, d. h. EVENT, beschreibt.
Fig. 7 ein Ablaufplan ist, der die Wirkung eines Dienstroutineaufrufs des Sammlers, d. h. EVENTW, beschreibt.
Fig. 8 ein Äblaufplan ist, der die Wirkung eines Dienstroutineaufrufs des Sammlers, d. h. EVENTPRV, be schreibt.
Fig. 9 ein Ablaufplan ist, der die Wirkung eines Dienstroutineaufrufs des Sammlers, d. h. START_ EVENT, beschreibt.
Fig. 10 ein Ablaufplan ist, der die Wirkung eines Dienstroutineaufrufs des Sammlers, d. h. START_ EVENTW, beschreibt.
Fig. 11 ein Ablaufplan ist, der die Wirkung eines Dienstroutineaufrufs des Sammlers, d. h. START_ EVENTPRV, beschreibt.
Fig. 12 ein Ablaufplan ist, der die Wirkung eines Dienstroutineaufrufs des Sammlers, d. h. END_EVENT, beschreibt.
Fig. 13 ein Ablaufplan ist, der die Wirkung eines Dienstroutineaufrufs des Sammlers, d. h. END_EVENTW, beschreibt.
Fig. 14 ein Ablaufplan ist, der die Wirkung eines Dienstroutineaufrufs des Sammlers, d. h. END_EVENTRV, beschreibt.
Fig. 15 ein Blockdiagramm einer Leistungsmerkmaldefini tion-Datenstruktur ist.
Fig. 16 ein Blockdiagramm einer Elementdatenstruktur ist.
Fig. 17 ein Blockdiagramm einer Leistungsmerkmal-Datenstruktur ist.
Fig. 18 ein Ablaufplan ist, der die Wirkung des Speicherns der Gruppendaten, einem Aspekt des Leistungsmerkmal-Auswahlprozesses beschreibt.
Fig. 19 ein Ablaufplan ist, der die Wirkung des Leistungsmerkmal-Auskopplers, einem Aspekt des Planungssammelprozesses beschreibt.

Beschreibung der bevorzugten Ausführungsform

Der Anwendungsereignis-Sammler der vorliegenden Erfindung (hier "Sammler" genannt) ist in einer geschichteten Software-Anwendung ausgeführt, die ereignisbasierte Daten, die sie von anderen geschichteten Software-Anwendungen, welche Dienstroutineaufrufe zum Sammler enthalten, sammelt, gewinnt, formatiert und über sie berichtet. Eine Anwendung besteht aus einer oder mehreren "Schichten". Eine Anwendungsschicht kann z. B. ein Anwendungscode (z. B. Anwendercode) oder ein geschichteter Produktcode (z. B. VAX-ACMS, VAX-Rdb/VMS, Software Dritter etc.) sein. In Fig. 1 ist eine Anwendung 2 mit vier Schichten als Blockdiagramm gezeigt. Die Schichten können hierarchisch angeordnet sein, d. h. beginnend mit einer VAX-All-in-1-Schicht 3 über eine VAX-ACMS-Schicht (Anwendungssteuerungs-Managementsystem-Schicht) 4, eine Anwendercode-Schicht 5 und eine VAXRdb/VMS-Datenbank- Schicht 6. Um ereignisorientierte Daten von der Schicht zu sammeln, muß der Quellcode in der Anwendung in allen Schichten mit Aufrufen der unten beschriebenen Sammlerdienstroutinen instrumentiert sein. Wenn die Schichten einmal instrumentiert sind, kann der Anwender die Datensammlung über die unten in Verbindung mit Fig. 2 beschriebene Planungs-Anwenderschnittstelle verwalten.
Da das Ziel eines Betriebs mit minimaler Einwirkung auf die Anwendung bei abgeschalteter wie bei eingeschalteter Datensammlung ebensowichtig ist, bestimmt der Quellcode in jeder Schicht der Anwendung, welche Ereignisse momentan durch die verschiedenen "Ereignissammelmerker" gesammelt werden. Ist z. B. ein Ereignissammelmerker gesetzt, gibt die Anwendungsschicht einen Aufruf einer Sammeldienstroutine aus. Andernfalls gibt die Anwendungsschicht keinen Aufruf der Sammeldienstroutine aus und minimiert dadurch bei abgeschalteter Datensammlung den Organisationsaufwand. Der Organisationsaufwand ist dann auf genau zwei Befehle beschränkt: einen "Vergleichs"-Befehl, um zu bestimmen, ob der Merker gesetzt ist, und einen "Verzweigungs"-Befehl, um die Ausführung der Anwendungsschicht fortzusetzen.
Der Sammler verfolgt das Ziel einer Minimierung des Organisationsaufwandes weiter dadurch, daß er ein System schafft, mit dem der Anwender bestimmen kann, von welchen Schichten er Daten sammeln kann und welche Ereignisse und Datenelemente innerhalb jeder Schicht verfügbar sind. So kann der Anwender Daten nur von jenen Schichten sammeln, an denen er interessiert ist. Ist der Anwender z. B. an der Abstimmung seiner momentanen VAX-Rdb/VMS-Datenbank interessiert, kann er spezifizieren, daß er nur Daten von der Rdb/VMS-Datenbankschicht der Anwendung gesammelt haben möchte. Um den Organisationsaufwand weiter zu minimieren, kann der Anwender eine oder mehrere verschiedene Ereignis-"Klassen" spezifizieren, die innerhalb jeder Schicht gesammelt werden sollen. Ist der Anwender z. B. nur am Sammeln von Arbeitslastdaten von der VAX- Rdb/VMS-Schicht interessiert, kann er eine Datenklasse spezifizieren, die lediglich Arbeitslastdaten und -datenelemente enthält.
Der Anwender kann dann mit Hilfe des Sammlers bestimmen, welche Anwendungen momentan auf einem Computersystem, z. B. einem VAX-Cluster, laufen. Nachdem der Anwender bestimmt hat, welche Anwendungen laufen, kann der Anwender eine Datensammlung planen, die er oben spezifiziert hat. Außerdem kann er planen, wie lange er die spezifizierten Daten sammeln und wo er die gesammelten Daten speichern möchte, außerdem kann er spezifische Anwendungen planen, von denen die Daten zu sammeln sind. Weiß der Anwender z. B., welche Anwendungen eine Schnittstelle zu der VAX-Rdb/VMS-Datenbankschicht besitzen, an der er interessiert ist, kann er eine Datensammlung nur von jenen Anwendungen spezifizieren. Weiß er auch, daß die Anwendungen, von denen er Daten sammeln möchte, typisch zwischen 8 Uhr morgens und 5 Uhr nachmittags laufen, kann er die Dauer der Sammlung entsprechend einschränken.
Ein Sammler ist damit ein System, in dem ein Anwendungsprogrammierer eine "Leistungsmerkmaldefinition", d. h. die Definition einer Anzahl von Ereignissen, einer Anzahl von mit jedem Ereignis verknüpften Datenelementen und einer Anzahl von Klassen von Ereignissen und Datenelementen, die seine Anwendung enthält, erzeugt. Der Programmierer tut dies zusätzlich zum Instrumentieren des Anwendungscodes mit den verschiedenen bei ereignisbasierten Bewertungssystemen üblichen Dienstroutineaufrufen. Ist die Leistungsmerkmaldefinition einmal abgeschlossen, kann ein Anwender eine "Leistungsmerkmalauswahl" erzeugen, d. h. für eine Anzahl von Anwendungen Ereignisse, Datenelemente und Klassen aus einer Anzahl von Leistungsmerkmaldefinitionen auswählen. Der Anwender kann auch auswählen, wann er eine Leistungsmerkmalauswahl anschaltet (d. h. wann er für eine ausgewählte Anwendung mit dem Sammeln von Daten beginnt) und wann er eine Leistungsmerkmalauswahl abschaltet (d. h. wann er das Sammeln der Daten für eine ausgewählte Anwendung beendet). Ein Vorteil dieses Zugangs besteht darin, daß die Anwendung, für die die Leistungsmerkmalauswahl abgeschaltet ist, keinen Organisationsaufwand mit sich bringt, d. h., obwohl die Anwendung selbst voll instrumentiert ist, führt sie die Dienstroutineaufrufe nicht wirklich aus.
Nach Fig. 2 enthält ein Sammler 10 eine Software-Anwendung mit einer Anzahl von Anwendungsschichten 12. Ein Beispiel für eine Anwendungsschicht 12 ist die Software für einen Bankautomaten (ATM). Jede Anwendungsschicht 12 enthält eine Anzahl von "Ereignissen", d. h. eine oder mehrere ablaufende Operationen. Die Ereignisse werden in zwei Typen unterteilt: Jene, die einen Anfang und ein Ende haben (sogenannte "Zeitdauer"ereignisse) und solche, die einfach vorkommen (sogenannte "Punkt"ereignisse) Beispiele für ein Zeitdauerereignis sind grundlegende ATM-Transaktionen wie Kontostandsprüfungen, Geldeinzahlungen und Geldabhebungen. Ein Beispiel für ein Punktereignis in einer ATM-Anwendungsschicht ist die Ausführung eines Fehlerbehandlungsverfahrens.
Jedes Ereignis in der Anwendungsschicht 12 ist weiter mit einer Anzahl von Datenelementen, d. h. den unten in Tabelle 1 aufgeführten Standard-Betriebsmittel-Nutzungselementen, verknüpft. Die auf das jeweilige Element bezogenen Daten werden bei der Ausführung jedes Ereignisses durch den Sammler gesammelt, wenn die Standard-Betriebsmittel-Nutzungselemente für jedes Ereignis in der Leistungsmerkmaldefinition definiert sind. TABELLE 1
Um die obenbeschriebenen Daten zu sammeln, ist die Anwendungsschicht 12 mit einem Registratorprozeß 14 verknüpft, der die Kommunikation zwischen den Anwendungsschichten und einer Managementdatenbank 16 abwickelt, die eine Beschreibung der für die Anwendungsschichten zu sammelnden Ereignisse und Datenelemente enthält. Die Ereignisse und Datenelemente für die Anwendungsschicht 12 sind in einer in der Managementdatenbank 16 gespeicherten "Leistungsmerkmaldefinition" definiert. Ebenso definiert eine (ebenfalls in der Managementdatenbank 16 gespeicherte) "Leistungsmerkmalauswahl" Untermengen der in den Leistungsmerkmaldefinitionen definierten Ereignisse und Datenelemente, um einem Anwender so die Möglichkeit zu geben, die zu sammelnden Daten anzupassen.
Die Anwendungsschicht 12 ist über den Registrator 14 weiter mit einer Planungs-Anwenderschnittstelle 18 verknüpft, die auch mit der Managementdatenbank 16 verknüpft ist. Die Kommunikation zwischen der Planungs-Anwenderschnittstelle 18, der Managementdatenbank 16, dem Registrator 14 und der Anwendungsschicht 12 steuert z. B., wann eine Leistungsmerkmalauswahl angeschaltet ist, d. h. wenn ein Anwender eine Sammlung plant, die der Anwendungsschicht mitteilt, daß sie mit dem Sammeln von Daten beginnen soll, und wann eine Leistungsmerkmalauswahl ausgeschaltet ist, d. h. wenn ein Anwender eine Sammlung vor dem geplanten Endzeitpunkt beendet. Ein besonderer Vorteil dieser Anordnung ist, daß sie, wenn keine Daten gesammelt werden, alle Leistungseinschränkungen der Anwendungsschicht 12 reduziert.
Schließlich werden die gesammelten Daten, d. h. die zu den in der Leistungsmerkmalauswahl spezifizierten Ereignissen und Datenelementen gehörigen Daten in einer Datensammeldatei 20 gespeichert. Der Anwender kann die Daten in der Datensammeldatei 20 formatieren und, wie später in der Beschreibung beschrieben, verschiedene Berichte erzeugen. Zunächst wird jedoch unten in Verbindung mit dem Ablaufplan von Fig. 3 ein Uberblick über den Sammelprozeß einschließlich der durch den Anwendungsschichtprogrammierer unternommenen Schritte und der durch den Anwender unternommenen Schritte gegeben.
Nach Fig. 3 "instrumentiert" ein Anwendungsprogrammierer seine Anwendungsschicht 12 mit Dienstroutineaufrufen, die Daten sammeln und diese in der Datensammeldatei 20 speichern (Schritt 100). Solche Aufrufe zeigen z. B. an, wann eine Anwendungsschicht initialisiert ist, wann ein Ereignis beginnt und wann ein Ereignis endet. Während der Ausführung entscheidet die Anwendungsschicht 12, welche Ereignisse und Datenelemente für die Anwendungsschicht 12 ausgewählt sind, und beginnt mit der Sammlung. Außerdem führt der Registrator 14 beim Start der Sammlung das Management der Kommunikation mit verschiedenen Unterprogrammen aus, um in der Datensammeldatei 20 Datensätze auf zubauen, in der die Daten, die die Anwendungsschicht 12 sammelt, zu speichern sind.
Zu diesem Zweck erzeugt der Programmierer für die Anwendungsschicht 12 eine "Leistungsmerkmaldefinition" und speichert die Definition in der Managementdatenbank 16 (Schritt 102). Die Anwender betrachten diese Leistungsmerkmaldefinitionen als Hilfsmittel bei der Planung der Datensammlung. Anhand der Informationen in den Leistungsmerkmaldefinitionen erzeugt dann ein Anwender eine "Leistungsmerkmalauswahl", in der er für jedes Leistungsmerkmal, von dem er Daten sammeln möchte, die Leistungsmerkmale und Klassen von Ereignissen und Elementen benennt (Schritt 104). Nachdem der Anwender seine Auswahl abgeschlossen hat, plant er als nächstes die Datensammlung durch die Planungs-Anwenderschnittstelle 18 (Schritt 106), d. h., er bringt an der in Schritt 104 oder an einer zuvor erzeugten Leistungsmerkmalauswahl Verweise an. Danach plant der Anwender eine Sammlung über die Planungs-Anwenderschnittstelle 18 und führt die Anwendungsschicht 12 aus, wodurch die Anwendungsschicht und der Registrator 14 für die in Schritt 100 definierten Ereignisse Daten zu sammeln und die Daten in der Datensammeldatei 20 (Schritt 108) zu speichern beginnen. Schließlich formatiert der Anwender die in der Datensammeldatei 20 gespeicherten Daten (Schritt 110) und druckt die formatierten Daten in ein Berichtsformular (Schritt 112). Eine genaue Beschreibung jedes dieser Schritte ist unten gegeben.

Instrumentierung des Anwendungscodes

Wie oben im Zusammenhang mit Fig. 3 erwähnt, instrumentiert der Anwendungsprogrammierer im ersten Schritt des Datensammelprozesses den Quellcode der Anwendungsschicht 12 mit Dienstroutineaufrufen. Die untenstehende Tabelle 2 führt einige der vom Sammler erkannten Dienstroutineauf rufe, die jeweils einem unterschiedlichen Zweck dienen, auf. Zum Beispiel identifiziert der INIT-Dienstroutineaufruf eine Anwendung als eine (auch als ein Leistungsmerkmal bezeichnete) Schicht und informiert den Registratorprozeß 14 darüber, daß die Schicht Daten sammeln kann. Ist die Anwendungsschicht auf diese Weise einmal identifiziert, definieren die verschiedenen EVENT-Dienstroutineaufrufe innerhalb der Anwendungsschicht die Ereignisse, d. h. das Auftreten eines Punktereignisses oder den Start und das Ende eines Zeitdauerereignisses. Um sicherzustellen, daß die Anwendungsschicht alle für den Registrator zur Durchführung der Datensammlung benötigten Daten übergibt, umfaßt jeder Aufruf von der Anwendungsschicht 12 über die Sammlerdienstroutinen an den Registrator 14 weiter eine Anzahl von Fehlerprüfungen. Diese und andere Merkmale der Dienstroutineaufrufe werden unten in Zusammenhang mit den Fig. 4-13 bereitgestellt. TABELLE 2

Der INIT-Dienstroutineaufruf

Der erste der mehreren hier beschriebenen Dienstroutineaufrufe ist INIT, der vor dem ersten Ereignis jeder Anwendungsschicht 12 instrumentiert ist. Er dient dazu, den Registrator 14 darüber zu informieren, daß die Anwendungsschicht 12 läuft und Daten sammeln kann. Das untenstehende "Codebeispiel 1" zeigt ein Beispiel für den in einem Anwendungscode-Abschnitt instrumentierten INIT- Dienstroutineaufruf. CODEBEISPIEL 1
Die grundlegende Wirkung von INIT besteht darin, das Leistungsmerkmal beim Registrator 14 zu registrieren, d. h. den Registrator darüber zu informieren, daß die Anwendungsschicht 12 läuft und für das Sammeln von Daten freigegeben ist. INIT ist in dem Ablaufplan von Fig. 4 veranschaulicht. Zunächst gibt INIT einen Fehlerzustandstreiber frei (Schritt 200), der auf alle Fehler in der durch die Anwendungsschicht 12 beim Aufruf der Routine übergebenen Parameterliste reagiert. Als nächstes bestätigt INIT den Inhalt einer oder mehrerer Parameter in der Parameterliste (Schritt 202), stellt sicher, daß nicht zuvor aufgrund eines unerwarteten Fehlers eine Sammlung für die Anwendung gesperrt wurde, bestimmt, ob eine Sammlung freigegeben ist (Schritt 204) und stellt fest, ob der Inhalt des durch die Anwendungsschicht 12 übergebenen Leistungsmerkmalnummer-Parameters gültig ist (Schritt 206). Ist das Ergebnis eines der Tests in den Schritten 202-206 negativ, wird an die Anwendungsschicht 12 ein Fehler zurückgegeben (Schritt 208). Ist dagegen das Ergebnis aller Tests in den Schritten 202-206 positiv, kopiert INIT den Inhalt des von der Anwendungsschicht 12 übergebenen Leistungsmerkmalnummer-Parameters in eine lokale Variable (Schritt 210), bestätigt den Inhalt des Leistungsmerkmalversions-Parameters (Schritt 212) und kopiert den Inhalt des Leistungsmerkmalversions- Parameters in eine lokale Variable (Schritt 214). Wird dagegen festgestellt, daß der Inhalt des Leistungsmerkmalversions-Parameters ungültig ist (Schritt 212), gibt INIT einen Fehler an die Anwendungsschicht 12 zurück (Schritt 216).
Nachdem INIT den Inhalt der von der Anwendungsschicht 12 übergebenen Parameter initialisiert und bestätigt hat, entscheidet INIT als nächstes, ob die Anwendungsschicht initialisiert wurde (Schritt 218), d. h., INIT verwendet den Inhalt des von der Anwendungsschicht übergebenen Leistungsmerkmalnummer-Parameters und Leistungsmerkmalversions-Parameters um festzustellen, ob INIT innerhalb der Anwendungsschicht zweimal von der gleichen Schicht aufgerufen worden ist. Zur Unterstützung dieser Entscheidung unterhält der Registratorprozeß 14 eine Leistungsmerkmalliste, die für jede Anwendungsschicht, die INIT aufgerufen hat und deshalb mit dem Registrator verknüpft ist, einen Leistungsmerkmaleintrag enthält. Stellt INIT fest, daß die Anwendungsschicht bereits initialisiert ist, gibt INIT eine Nachricht an die Anwendungsschicht (Schritt 220), die anzeigt, daß INIT bereits von der Anwendungsschicht aufgerufen wurde. Als nächstes bestätigt INIT schließlich den Inhalt des von der Anwendungsschicht 12 übergebenen Registrierungsidentifikations- Parameters Schritt 222). Ist die Identifizierung gültig, kopiert INIT dessen Inhalt in eine lokale Variable (Schritt 224). Ist die Identifizierung dagegen ungültig, gibt INIT einen Fehler an die Anwendungsschicht zurück (Schritt 226).
Nachdem der Inhalt der meisten Parameter bestätigt wurde, bereitet INIT als nächstes alle verbleibenden von der Anwendung 12 übergebenen Parameter auf den Empfang von Informationen aus der Datensammlung vor. Genauer löscht INIT die durch die Anwendungsschicht 12 übergebenen Ereignismerkerparameter und den Elementmerkerparameter durch den Eintrag von Nullen in jeden dieser Merker (Schritt 228) und durch das Löschen des Zustandsparameters (Schritt 230). Nach den Schritten 228 und 230 konstruiert INIT den zur Übermittlung von Nachrichten von der Anwendungsschicht 12 an den Registrator 14 verwendeten Betriebsmittelnamen (Fig. 2).
Als nächstes erzeugt INIT für die Anwendungsschicht 12 einen temporären Briefkasten (Schritt 234), der Startund Stopnachrichten vom Registrator 14 zur Steuerung der Datensammlung, d. h. Nachrichten zum Start oder Abbruch einer Datensammlung, empfängt. Danach fügt INIT der Leistungsmerkmalliste, falls das Leistungsmerkmal nicht bereits in die Leistungsmerkmalliste eingetragen ist, einen Leistungsmerkmaleintrag hinzu (Schritt 236). Der Leistungsmerkmaleintrag ist in Fig. 5 als Blockdiagramm gezeigt und enthält eine Leistungsmerkmalnummer 50, Ereignismerker 52, eine Adresse für die Ereignismerker 54, Elementmerker 56 und eine Adresse für die Elementmerker 58. Andernfalls ordnet INIT den Ereignismerker 52 und den Elementmerker 56 Werte zu (Schritt 238).
Um im Schritt 236 einen neuen Leistungsmerkmaleintrag zu erzeugen, erzeugt INIT zunächst den Eintrag und kopiert den Inhalt des Leistungsmerkmalversionsnummer-Parameters in das Leistungsmerkmalnummerfeld 50 des Eintrags. Ebenso kopiert INIT den Inhalt des Identifikationsparameters, die Adressen des Ereignismerkerparameters und die Adresse des Elementmerkers in deren entsprechende Felder in dem Eintrag. Schließlich initialisiert INIT den Eintrag, so daß er zur Datensammlung verfügbar ist, sendet die Leistungseintragsinformation an den Registrator und setzt einen Merker, der anzeigt, daß der Leistungseintrag registriert worden ist.
Ist für das momentane Leistungsmerkmal eine Sammlung eingeschaltet, ist bereits ein Leistungsmerkmaleintrag vorhanden. INIT aktualisiert deshalb wie in Schritt 238 den vorhandenen Leistungsmerkmaleintrag oder setzt nach Erzeugen des Eintrags in Schritt 236 den Inhalt der Ereignismerker 52, setzt den Inhalt der Element- 56, schreibt den Eintrag in die Datensammeldatei 20 und kopiert den Inhalt der Identifikations- und Leistungsmerkmalversions-Parameter in den Eintrag. Schließlich gibt INIT den Zustand des Leistungsparameters und seiner Datensammlung, d. h. SUCCESS oder DISABLED, an die Anwendungsschicht zurück (Schritt 240).

Der EVENT-Dienstroutineaufruf

EVENT ist ein beim Auftreten jedes asynchronen Punktereignisses in der Anwendungsschicht 12 instrumentierter Dienstroutineaufruf. Er dient zur Sammlung von Punktereignisdaten in der Datensammeldatei 20. Das untenstehende "Codebeispiel 2" zeigt ein Beispiel für den in einem Anwendungscode-Abschnitt instrumentierten EVENT-Dienstroutineaufruf. CODEBEISPIEL 2
Darüber hinaus ist die Wirkung von EVENT bei Aufruf durch die Anwendungsschicht 12 in dem Ablaufdiagramm in Fig. 6 veranschaulicht. Zuerst gibt EVENT einen Fehlerzustandstreiber frei (Schritt 300), der auf alle Fehler in den durch die Anwendungsschicht 12 bei Aufruf der Routine übergebenen Parametern reagiert. Als nächstes stellt EVENT fest, ob eine Datensammlung gesperrt ist (Schritt 302). Ist eine Datensammlung gesperrt, gibt EVENT einen Fehler an die Anwendungsschicht 12 zurück (Schritt 304). Andernfalls bestätigt EVENT die benötigten Parameter in der Parameterliste (Schritt 306) und ruft eine weitere Dienstroutine EVENTPRV auf (Schritt 308), die den Inhalt der Parameter bestätigt und den Inhalt in den Leistungsmerkmaleintrag schreibt. (EVENTPRV ist unten im Zusammenhang mit Fig. 8 beschrieben.) Schließlich gibt EVENT den Zustand des Aufrufs an die Anwendungsschicht zurück (Schritt 310).
Analog ist EVENTW ein Dienstroutineaufruf, der beim Auftreten jedes synchronen Punktereignisses in der Anwendungsschicht 12 instrumentiert ist. Er dient dazu, synchrone Punktereignisdaten in die Datensammeldatei 20 einzutragen. Das obenstehende "Codebeispiel 2" zeigt ein Beispiel für den in einem Anwendungscode-Abschnitt instrumentierten EVENTW-Dienstroutineaufruf. Darüber hinaus ist die Wirkung von EVENTW beim Aufruf durch die Anwendungsschicht 12 in dem Ablaufdiagramm in Fig. 7 veranschaulicht und unten beschrieben.
Nach Fig. 7 gibt EVENTW zunächst einen Fehlerzustandstreiber frei (Schritt 400), der auf alle Fehler in den durch die Anwendungsschicht 12 beim Aufruf der Routine übergebenen Parametern reagiert. Anschließend stellt EVENTW fest, ob eine Datensammlung gesperrt ist (Schritt 402). Ist eine Datensammlung gesperrt, gibt EVENTW einen Fehler an die Anwendungsschicht 12 zurück (Schritt 404).
Andernfalls bestätigt EVENTW den Inhalt einer oder mehre rer Parameter in der Parameterliste (Schritt 406) und ruft die Dienstroutine EVENTPRV auf (Schritt 408), die den Inhalt der Parameter bestätigt und den Inhalt in den Leistungsmerkmaleintrag schreibt. (EVENTPRV ist unten im Zusammenhang mit Fig. 8 beschrieben.) Schließlich gibt EVENTW den Zustand des Aufrufs an die Anwendungsschicht zurück (Schritt 410).

Der EVENTPRV-Dienstroutineaufruf

EVENTPRV ist eine durch EVENT und EVENTW wie oben beschrieben aufgerufene Dienstroutine. Sie dient der Eingabe von in den Event-Dienstroutinen gesammelten Daten in die Leistungsmerkmaleinträge. Hierzu verwendet EVENTPRV den Inhalt der Parameter, die EVENTPRV von den Event- Dienstroutinen erhält, bestätigt diese und kopiert sie in den Leistungsmerkmaleintrag. Die Wirkung von EVENTPRV ist unten im Zusammenhang mit dem Ablaufplan in Fig. 8 beschrieben.
Nach Fig. 8 gibt EVENTPRV zuerst einen Fehlerzustandstreiber frei (Schritt 500), der auf alle Fehler in den durch die Event-Dienstroutinen übergebenen Parametern reagiert. Danach bestätigt EVENTPRV den Inhalt des Leistungsmerkmalnummer-Parameters (Schritt 502), den Inhalt der Ereignisidentifizierung (Schritt 504) und den Inhalt aller optionalen Parameter (Schritt 506). Danach bestätigt EVENTPRV alle optionalen Parameter (Schritt 508) und gibt für alle ungültigen Parameter einen Fehler an die Event-Dienstroutine zurück.
Nachdem EVENTPRV die Parameter bestätigt hat, ermittelt EVENTPRV den Leistungsmerkmaleintrag, der dem durch die Event-Dienstroutine übergebenen Leistungsmerkmalnuinmer- Parameter entspricht (Schritt 510). Ist kein Leistungsmerkmaleintrag vorhanden, gibt EVENTPRV einen Fehler an die Event-Dienstroutine zurück (Schritt 512). Andernfalls stellt EVENTPRV fest, ob das Ereignis gesammelt werden soll (Schritt 514), d. h. ob der Merker für das Ereignis gesetzt ist. Soll das Ereignis nicht gesammelt werden, gibt EVENTPRV einen Fehler an die Event-Dienstroutine zurück (Schritt 516). Andernfalls bestimmt EVENTPRV die Größe des zum Halten der gesammelten Daten benötigten Datensatzes (Schritt 518), ordnet den Platz für jenen Datensatz zu (Schritt 520) und versieht den Datensatz mit einem Zeiteintrag (Schritt 522). Nachdem EVENTPRV den Datensatz soweit vorbereitet hat, kopiert EVENTPRV den Inhalt der durch die Event-Dienstroutine übergebenen Parameter in den Datensatz (Schritt 524), schreibt den Datensatz in die Datensammeldatei 20 (Schritt 526) und gibt eine Erfolgsmeldung, d. h. SUCCESS an die Event- Dienstroutine zurück (Schritt 528).

Der START EVENT-Dienstroutineaufruf

START_EVENT ist ein Dienstroutineaufruf, der in der Anwendungsschicht 12 beim Start jedes asynchronen Zeitdauerereignisses instrumentiert ist. Er dient dazu, in der Datensammeldatei 20 asynchrone Zeitdauerereignisse aufzuzeichnen. Ein Beispiel für den in einem Anwendungscode-Abschnitt instrumentierten START_ EVENT-Dienstroutineaufruf ist oben im "Codebeispiel 1" gegeben. Darüber hinaus ist die Wirkung von START_EVENT beim Aufruf durch die Anwendungsschicht 12 in dem in Fig. 9 gezeigten Ablaufplan gezeigt und unten beschrieben.
Nach Fig. 9 gibt START_EVENT zunächst einen Fehlerzustandstreiber frei (Schritt 600), um auf alle Fehler in den von der Anwendungsschicht 12 übergebenen Parametern zu reagieren. Anschließend stellt START_EVENT fest, ob eine Datensammlung gesperrt ist (Schritt 602). Ist eine Datensammlung gesperrt, gibt START_EVENT einen Fehler an die Anwendungsschicht 12 zurück (Schritt 604). Andernfalls bestätigt START_EVENT die benötigten Parameter (Schritt 606) und ruft die unten im Zusammenhang mit Fig. 11 beschriebene Routine START_EVENTPRV auf (Schritt 608). Schließlich gibt START_EVENT einen Zustand an die Anwendungsschicht 12 zurück (Schritt 610).
Analog ist START_EVENTW ein Dienstroutineaufruf, der beim Start jedes synchronen Zeitdauerereignisses in der Anwendungsschicht 12 instrumentiert ist. Er dient dazu, synchrone Zeitdauerereignisdaten in die Datensammeldatei 20 einzutragen. Ein Beispiel für den in einem Anwendungscode-Abschnitt instrumentierten START_ EVENTW-Dienstroutineaufruf ist oben im cycodebeispiel 1" gegeben. Darüber hinaus ist die Wirkung von START_EVENTW beim Aufruf durch die Anwendungsschicht 12 in dem Ablaufplan in Fig. 10 veranschaulicht und unten beschrieben.
Nach Fig. 10 gibt START_EVENTW zuerst einen Fehlerzustandstreiber frei (Schritt 700), der auf alle Fehler in den von der Anwendungsschicht 12 übergebenen Parametern reagiert. Danach stellt START_EVENTW fest, ob eine Datensammlung gesperrt ist (Schritt 702). Ist eine Datensammlung gesperrt, gibt START_EVENTW einen Fehler an die Anwendungsschicht 12 zurück (Schritt 704). Andernfalls bestätigt START_EVENTW den Inhalt der benötigten Parameter (Schritt 706) und ruft die unten im Zusammenhang mit Fig. 11 beschriebene Routine START_EVENTPRV auf (Schritt 708). Schließlich gibt START_EVENTW einen Zustand an die Anwendungsschicht 12 zurück (Schritt 710).

Der START EVENTPRV-Dienstroutineaufruf

Nach Fig. 11 gibt START_EVENTPRV zuerst einen Fehlerzustandstreiber frei (Schritt 800), um auf alle Fehler, die in den von den Start-Event-Dienstroutinen übergebenen Parametern auftreten, zu reagieren Danach bestätigt START_EVENTPRV den Inhalt der benötigten Parameter (Schritt 802), dc h. des Leistungsmerkmalnummer-Parameters, des Inhalts der Ereignisidentifizierung (Schritt 804) und des Inhalts des Handle (Schritt 806) c Im Ergebnis dieser Tests gibt START_EVENTPRV für jeden hiervon ungültigen Parameter einen Fehler an die Start-Event- Dienstroutine zurück (Schritt 808) c Danach löscht START_EVENTPRV den Ereignismerker des Betriebssystems (Schritt 810) und validiert den Inhalt aller optionalen Parameter (Schritt 812).
Nach der Validierung der Parameter ermittelt START_EVENTPRV als nächstes den Leistungsmerkmaleintrag, der dem von der Event-Dienstroutine übergebenen Leistungsmerkmalnummer-Parameter entspricht (Schritt 814). Liegt kein Leistungsmerkmaleintrag vor, gibt START_EVENTPRV einen Fehler an die Event-Dienstroutine zurück, der anzeigt, daß keine Daten für das Leistungsmerkmal gesammelt werden (Schritt 816). Andernfalls stellt START_EVENTPRV fest, ob das Ereignis gesammelt werden soll (Schritt 818), d. h. ob der Merker für das Ereignis gesetzt ist. Soll das Ereignis nicht gesammelt werden, gibt START_EVENTPRV einen Fehler an die Event- Dienstroutine zurück (Schritt 820). Andernfalls bestimmt START_EVENTPRV die Größe des zum Halten der gesammelten Daten benötigten Datensatzes (Schritt 822), ordnet den Platz für jenen Datensatz zu (Schritt 824) und versieht den Datensatz mit einem Zeiteintrag (Schritt 826). Nachdem START_EVENTPRV den Datensatz soweit vorbereitet hat, kopiert START_EVENTPRV den Inhalt der durch die Event- Dienstroutine übergebenen Parameter in den Datensatz (Schritt 828), schreibt den Datensatz in die Datensammeldatei 20 (Schritt 830) und gibt eine Erfolgsmeldung, d. h. SUCCESS, an die Event-Dienstroutine zurück (Schritt 840).

Der END EVENT-Dienstroutineaufruf

END_EVENT ist ein am Ende jedes asynchronen Zeitdauerereignisses in der Anwendungsschicht 12 instrumentierter Dienstroutineaufruf. Er dient dazu, Zeitdauerereignisdaten in die Datensammeldatei 20 einzutragen. Ein Beispiel für den in einem Anwendungscode-Abschnitt instrumentierten END_EVENT-Dienstroutineaufruf ist oben im "Codebeispiel 1" gegeben. Darüber hinaus ist die Wirkung von END_EVENT beim Aufruf durch die Anwendungsschicht 12 in dem Ablaufplan in Fig. 12 veranschaulicht und unten beschrieben.
Nach Fig. 12 gibt END_EVENT zuerst einen Fehlerzustandstreiber frei (Schritt 900), um auf alle in den von den Event-Dienstroutinen übergebenen Parametern auftretenden Fehler zu reagieren. Danach stellt END_EVENT als nächstes fest, ob eine Datensammlung freigegeben ist (Schritt 902). Ist die Datensammlung gesperrt, gibt END_EVENT einen Fehler an die Anwendungsschicht 12 zurück (Schritt 904). Andernfalls bestätigt END_EVENT die benötigten Parameter (Schritt 906). Wenn die benötigten Parameter existieren, ruft END_EVENT die Routine END_EVENTPRV auf (Schritt 908), die unten im Zusammenhang mit Fig. 14 beschrieben ist. Andernfalls gibt END_EVENT einen Fehler an die Anwendungsschicht 12 zurück (Schritt 909). Schließlich gibt END_EVENT einen Zustand an die Anwendungsschicht 12 zurück (Schritt 910).
Analog ist END_EVENTW ein Dienstroutineaufruf, der am Ende jedes synchronen Zeitdauerereignisses in der Anwendungsschicht 12 instrumentiert ist. Er dient dazu, Zeitdauerpunktereignisdaten in die Datensammeldatei 20 einzu tragen. Ein Beispiel für den in einem Anwendungscode- Abschnitt instrumentierten END_EVENTW-Dienstroutineaufruf ist oben im "Codebeispiel 1" gegeben. Darüber hinaus ist die Wirkung von END_EVENTW beim Aufruf durch die Anwendungsschicht 12 in dem Ablaufplan in Fig. 13 veranschaulicht und oben beschrieben.
Nach Fig. 13 gibt END_EVENTW zuerst einen Fehlerzustandstreiber frei (Schritt 1000), um auf alle in den von den Event-Dienstroutinen übergebenen Parametern auftretenden Fehler zu reagieren. Danach stellt END_EVENTW fest, ob eine Datensammlung freigegeben ist (Schritt 1002). Ist eine Datensammlung gesperrt, gibt END_EVENT einen Fehler an die Anwendungsschicht 12 zurück (Schritt 1004). Andernfalls prüft END_EVENTW, ob die benötigten Parameter existieren (Schritt 1006). Wenn die benötigten Parameter existieren, ruft END_EVENT die Routine END_EVENTPRV auf (Schritt 1008), die unten im Zusammenhang mit Fig. 14 beschrieben ist. Andernfalls gibt END_EVENT einen Fehler an die Anwendungsschicht 12 zurück (Schritt 1009). Schließlich gibt END_EVENT einen Zustand an die Anwendungsschicht 12 zurück (Schritt 1010).

Der END EVENTPRV-Dienstroutineaufruf

END_EVENTPTV ist ein Dienstroutineaufruf, der durch die obenbeschriebenen Routinen END_EVENT und END_EVENTW aufgerufen wird. Er dient dazu, von den End-Event- Dienstroutinen in den Leistungsmerkmaleinträgen gesammelte Daten zu speichern. Hierzu nimmt END_EVENTPRV den Inhalt der Parameter, die END_EVENTPRV von den Event- Dienstroutinen empfängt, bestätigt diese und kopiert sie in den Leistungsmerkmaleintrag. Die Wirkung von EVENTPRV ist unten im Zusammenhang mit dem Ablaufplan von Fig. 14 beschrieben.
Nach Fig. 14 gibt END_EVENTPRV zuerst einen Fehlerzu standstreiber frei (Schritt 1100), um auf alle in den von den Event-Dienstroutinen übergebenen Parametern auftretenden Fehler zu reagieren. Danach validiert END_EVENTPRV als nächstes den Inhalt des Leistungsmerkmalnummer-Parameters (Schritt 1102), den Inhalt der Ereignisidentifikation (Schritt 1104) und den Inhalt des Handle (Schritt 1106). Für jeden hiervon ungültigen Parameter gibt END_EVENTPRV einen Fehler an die End-Event-Dienstroutine zurück (Schritt 1108). Danach löscht END_EVENTPRV als nächstes die Ereignismerker (Schritt 1110) und validiert den Inhalt aller optionalen Parameter (Schritt 1112). Danach ermittelt END_EVENTPRV den Leistungsmerkmaleintrag, der dem von der Event-Dienstroutine übergebenen Leistungsmerkmalcode-Parameter entspricht (Schritt 1114). Existiert kein Leistungsmerkmaleintrag, gibt END_EVENTPRV einen Fehler an die Event-Dienstroutine zurück (Schritt 1116). Andernfalls stellt END_EVENTPRV fest, ob das Ereignis gesammelt werden soll (Schritt 1118) d. h., ob der Merker für das Ereignis gesetzt ist. Soll das Ereignis nicht gesammelt werden, gibt END_EVENTPRV einen Fehler an die Event-Dienstroutine zurück (Schritt 1120). Andernfalls bestimmt END_EVENTPRV die Größe des zum Halten der gesammelten Daten benötigten Datensatzes (Schritt 1122), ordnet den Platz für jenen Datensatz zu (Schritt 1124) und versieht den Datensatz mit einem Zeiteintrag (Schritt 1126). Nachdem END_EVENTPRV den Datensatz soweit vorbereitet hat, kopiert END_EVENTPRV den Inhalt der durch die Event-Dienstroutine übergebenen Parameter in den Datensatz (Schritt 1128), schreibt den Datensatz in die Datensammeldatei 20 (Schritt 1130) und gibt eine Erfolgsmeldung, d. h. SUCCESS, an die Event- Dienstroutine zurück (Schritt 1132).

Die Leistungsmerkmaldefinition

Jede mit Dienstroutineaufrufen für den Registratorprozeß 14 instrumentierte Anwendungsschicht 12 muß eine Leistungsmerkmaldefinition bereitstellen, die die Ereignisse in der Anwendungsschicht und auch die Datenelemente für jedes Ereignis beschreibt. Die Leistungsmerkmaldefinition ist in der Managementdatenbank 16 gespeichert, und der Anwender kann auf sie über den Registrator 14 und die Planungs-Anwenderschnittstelle 18 zugreifen, um eine Datensammlung auszuführen. Eine (im Blockdiagramm in Fig. 15 gezeigte) Leistungsmerkmaldefinition enthält den Namen des Leistungsmerkmals 30, die Identifikationsnummer des Leistungsmerkmals 32, die Versionsnummer des Leistungsmerkmals 34, eine Liste von Ereignisdefinitionen 36, eine Liste von mit jedem Ereignis verknüpften Datenelementdefinitionen 38 und eine Liste von Klassenbeschreibungen 40. In der Beispielanwendungsschicht für den ATM sind die definierten Ereignisse 36 eine Kontostandsprüfung, Einzahlungen und Auszahlungen (sämtlich Zeitdauerereignisse) und die Anzeige einer Fehlermeldung (ein Punktereignis) . Der Code für jedes Ereignis wird durch das Anbringen von Dienstroutineaufrufen an seinem Beginn und seinem Ende instrumentiert. Die Datenelemente 38 sind mit dem jeweiligen Ereignis verknüpfte Datenstücke. Standardmäßig werden für jedes Ereignis die in der obigen Tabelle 1 gezeigten Elemente gesammelt. Der Anwender kann es jedoch vorziehen, zusätzliche anwendungsschichtspezifische Elemente zu sammeln oder beliebige der Standardelemente zu übergehen. Die Struktur eines Datenelements ist in Fig. 16 gezeigt. Jedes Element ist teilweise durch seinen Datentyp (eine Liste möglicher Datentypen enthält die untenstehende Tabelle 3) definiert und ist weiter definiert durch einen Bezeichner 50; eine Größe 52, die die Maximalgröße des Elements in Bytes angibt; einen Berichtsanfangsblock 54, bei dem es sich um Text zur Bezeichnung des Elements in einem Bericht handelt; eine Breite 56, die die Anzahl der Leerstellen anzeigt, in denen das Element in einem Bericht darzustellen ist; einen Nutzungstyp 58, der einen von mehreren Werten einschließlich LEVEL, COUNTER, PERCENT, TEXT und PRIVATE (eine Liste möglicher Nutzungstypen enthält die untenstehende Tabelle 4) haben kann; und eine Charakterisierung 60, die z. B. anzeigt, ob das Element druckbar oder nicht druckbar ist. TABELLE 3 TABELLE 4
Schließlich identifiziert die Liste der Klassendefinitionen 40 Mengen von Ereignisdefinitionen 36 und Datenelementdefinitionen, die ein Anwender in einer unten beschriebenen Leistungsmerkmalauswahl als eine Gruppe auswählen kann.

Die Leistungsmerkmalauswahl

Eine Leistungsmerkmalauswahl beschreibt die Daten für die Ereignisse und Elemente, die jede Anwendungsschicht 12 während einer Sammlung sammelt. Das Sammelhilfsmittel 10 führt die Datensammlung mit minimalem Organisationsaufwand und minimalen Leistungseinbußen aus. Natürlich wächst aber der Organisationsaufwand, je mehr Leistungsmerkmale der Anwender zum Sammeln von Daten auswählt. In einer geschäftigen Umgebung wird die Datensammeldatei 20 z. B. sehr groß, was dazu führen kann, daß die Anwendungsschicht rasch den verfügbaren Plattenplatz aufbraucht. Der Anwender kann es deshalb vorziehen, seine Sammlung auf eine spezifische Funktion oder einen spezifischen Bereich der Anwendungsschicht zu beschränken. Zu diesem Zweck wählt er eine oder mehrere Klassen der obenbeschriebenen Leistungsmerkmale aus. Die Struktur einer Leistungsmerkmalauswahl ist in Fig. 17 gezeigt und enthält eine Liste von Leistungsmerkmalnamen von Leistungsmerkmaldefinitionen 60, von denen Daten von Ereignissen und Elementen gesammelt werden sollen, einen Kommentar 62, der den Zweck der Sammlung beschreibt und eine Liste von Optionen 64, die spezifizieren, welche Klassen jedes Leistungsmerkmals zu sammeln sind.
Die in der Managementdatenbank gespeicherten Informationen werden gemäß der in dem Ablaufplan von Fig. 18 gezeigten Leistungsmerkmalauswahlroutine ein Teil einer Leistungsmerkmalauswahl. Eingaben für den Leistungsmerkmalauswahlprozeß sind eine Element- und eine Elementgruppeninformation, die sich bereits in der Datenbank befinden, eine oder mehrere Leistungsmerkmaldefinitionen, eine Leistungsmerkmalidentifikation, ein Zeiger auf die Versionsnummer des Leistungsmerkmals, ein Zeiger auf die Gruppennamen und ein Zeiger auf eine Elementliste. Ist der Zeiger auf den Gruppennamen in Schritt 1200 null, gibt die Routine einen Fehler an die Anwenderschnitt stelle zurück. Andernfalls stellt die Routine fest, ob die Länge des Gruppennamens gültig ist (Schritt 1202). Ist dies der Fall, liest die Routine die Versionsnummer und den Gruppennamen aus (Schritt 1204).
Als nächstes führt die Routine eine Anzahl von Fehlerprüfungen aus. Ist für das Leistungsmerkmal kein Elementname definiert (Schritt 1206), gibt die Routine einen Fehler an die Anwenderschnittstelle zurück (Schritt 1208). Ebenso gibt die Routine einen Fehler zurück (Schritt 1212), wenn für das Leistungsmerkmal kein Elementgruppenname definiert ist (Schritt 1210). Schließlich gibt die Routine einen Fehler an die Anwenderschnittstelle zurück (Schritt 1216), wenn der Zeiger auf die Elementliste null ist (Schritt 1214).
Geben andernfalls die Fehlerprüfungen in den Schritten 1206-1216 keine Fehler zurück, liest die Routine die Elementliste aus (Schritt 1218) und bestätigt jedes Element in der Liste (Schritt 1220). Ist eines der Elemente eine Sammelelementgruppe (Schritt 1222), erzeugt die Routine für jedes Element in der Gruppe Elementlisteneinträge (Schritt 1224). Ist dagegen eines der Elemente ein Sammelelement (Schritt 1226), z. B. eines der Standard-Betriebsmittelelemente, erzeugt sie für jedes Element ein Elementtupel und nimmt das Tupel in die Leistungsmerkmaldefinition auf (Schritt 1228). Und ist eines der Elemente ein Gruppenname (Schritt 1230), liest die Routine die Elementdatensätze aus (Schritt 1232), erzeugt Einträge in der Elementliste (1234) und nimmt ein Gruppentupel in die Leistungsmerkmaldefinition auf (Schritt 1236). Schließlich prüft die Routine, ob eine Klassenoption eingegeben wurde. Falls ja, bestätigt die Routine den Klassennamen, die Existenz des Ereignisses und aller Elemente, die mit dem Ereignis verknüpft werden sollen. Falls diese existieren, erzeugt die Routine ein Klassentupel für die Klasse und ein Ereigniselementtupel für die Klasse. Unabhängig davon, ob eine Klasse eingegeben wurde, wird eine Standardklasse ALL erzeugt, die alle Ereignisse und Elemente für alle Elemente enthält.

Die Planungsschnittstelle

Um Daten von den verschiedenen auf einem System laufenden Anwendungen und Anwendungsschichten zu sammeln, plant der Anwender eine Sammlung über die Planungs-Anwenderschnittstelle 18 (Fig. 2). Der Anwender spezifiziert in der geplanten Sammlung, welche Daten gesammelt werden sollen, wieviele Daten gesammelt werden sollen, wann die Daten gesammelt werden sollen und wo die Daten gespeichert werden sollen. Die Menge der gespeicherten Daten hängt davon ab, wieviel Prozesse auf jedem Knoten des Systems Daten sammeln. Der Anwender kann eine Untermenge oder alle diese Prozesse auswählen. Jede Schicht in jeder Anwendung, die Dienstroutineaufrufe enthält, enthält einen Aufruf von INIT, um den Prozeß und die Leistungsmerkmalinformation zu registrieren. Diese Information enthält den Namen des Bildes, den/die Namen der Leistungsmerkmale, die INIT aufgerufen haben, den Registrierungsidentifikator für den Prozeß, die Prozeßidentifikationsnummer und den Namen des Knotens, auf dem der Prozeß läuft. Die Planungsinformation enthält weiter den Namen der Ausgabedatei für die gesammelten Daten, die Startund die Endzeit, welche Leistungsmerkmalauswahl verwendet werden soll, und ob von jedem Knoten in einem Computersystem, z. B. jedem Knoten in einem VAX-Cluster, oder von einem einzigen lokalen Knoten gesammelt werden soll.
Eine für den Export einer Leistungsmerkmaldefinition zu externen Computersystemen benötigte Routine ist die in dem Ablaufplan in Fig. 19 gezeigte Leistungsmerkmalauszugsroutine, die eine Leistungsmerkmaldefinition von der Managementdatenbank eingibt und eine Datei, die eine Darstellung jener Definition enthält, ausgibt. Als erstes kopiert die Routine die Leistungsmerkmalversionsnummer (Schritt 1300) und erzeugt und öffnet die Auszugsdatei (Schritt 1302). Nach Erzeugen der Auszugsdatei erzeugt die Routine innerhalb der Datei einen Versionsdatensatz (Schritt 1304) und schreibt den Versionsdatensatz von der Datenbank in die Datei (Schritt 1306).
Danach prüft die Routine als nächstes die Rechte des Anwenders (Schritt 1308). Hat der Anwender im Vergleich zu einem vorgegebenen Standard genügend Rechte, versucht die Routine, die Leistungsmerkmaldefinition in der Managementdatenbank zu ermitteln (Schritt 1310). Wird die Leistungsmerkmaldefinition nicht gefunden (Schritt 1312), gibt die Routine einen Fehler zurück (Schritt 1314). Andernfalls prüft die Routine erneut die Rechte des Anwenders (Schritt 1316). Reichen die Rechte nicht aus, gibt die Routine einen Fehler zurück (Schritt 1318). Andernfalls schreibt die Routine den Leistungsmerkmalhaupteintrag (Schritt 1320) in die Auszugsdatei, indem sie alle Leistungseintragstabellen verarbeitet und die Datensätze für jeden Elementdatensatz, Elementgruppendatensatz, Ereignisdatensatz, Ereigniselementdatensatz, Klassendatensatz und Standardklassendatensatz in die Datei schreibt (Schritt 1322).

Formatieren der Datensammeldatei

Nachdem eine geplante Datensammlung abgeschlossen wurde, kann die Datensammeldatei 20 mit zuvor erzeugten Datensammeldateien zu einer einzigen Datendatei, z. B. einer Rdb/VMS-Datenbankdatei oder einer VMS-RMS-Datei vereinigt werden. Damit kann der Anwender bequem alle Daten einer oder mehrerer Sammlungen warten. Nach dem Formatieren der Daten kann der Sammler aus den formatierten Daten auch verschiedene tabellarische Berichte erzeugen. Zum Beispiel ist ein Postenbericht für Anwendungsprogrammierer zu Austestzwecken nützlich, da er die momentanen Werte der Elemente bei jedem Auftreten eines Zeitdauerereignisses oder Punktereignisses, den Zeitpunkt des Auftretens jedes Ereignisses und andere Elementdaten zeigt. Zu den weiteren Berichten gehört ein Häufigkeitsbericht, der die Anzahl des Auftretens jedes Ereignisses pro Sekunde, pro Minute oder pro Stunde auflistet und ein Protokollbericht, der für jedes Element verschiedene statistische Daten einschließlich Maximum, Minimum, Mittelwert, Standardabweichung, Anzahl (Anzahl des Auftretens), Summe und den 95 %-Vertrauensbereich auflistet.
Als Programmiersprachen werden VAX-C, Version 3.0-031 und VAX-BLISS-32, Version 4.5-862 verwendet. Der verwendete Computer ist ein VAX 8820, und als Betriebssystem wird VAX/VMS 5.2 verwendet.
Ein Teil der Offenbarung dieser Patentschrift enthält Material, das dem Urheberrechtsschutz unterliegt. Der Inhaber des Urheberrechtsschutzes hat keine Einwände gegen die Faksimilewiedergabe durch irgend jemanden der Patentschrift, wie sie im Patent- und Warenzeichenamt vorliegt, behält sich aber alle anderweitigen Urheberschutzrechte vor.
Die vorhergehende Beschreibung war zum Zweck der Veranschaulichung und Erläuterung lediglich auf eine besondere exemplarische Ausführungsform der Erfindung gerichtet. Für Fachleute wird offensichtlich sein, daß viele Abwandlungen und Änderungen im Prozeß der vorliegenden Erfindung möglich sein werden, ohne den Umfang dieser Erfindung zu verlassen. Die folgenden Ansprüche sollen so interpretiert werden, daß sie alle solche Abweichungen und Änderungen einschließen.

Claims

1. Verfahren, das in einem Computer implementiert ist, um ereignisbasierte Daten für eine Software-Anwendung zu sammeln, wobei das Verfahren die folgenden Schritte enthält:

vor der Ausführung der Software-Anwendung:

(a) Einbetten von Ereignismarkierungsbefehlen in die Software-Anwendung, wobei jeder der Ereignismarkierungsbefehle einen freigegebenen Zustand, in dem ereignisbasierte Daten gesammelt werden, und einen gesperrten Zustand, in dem ereignisbasierte Daten nicht gesammelt werden, besitzt; gekennzeichnet durch die folgenden Schritte:

(b) Speichern von Definitionen jedes der Ereignismarkierungsbefehle, die in die Software-Anwendung eingebettet worden sind, wobei die Definitionen die Software-Anwendung identifizieren, in die die entsprechenden Ereignismarkierungsbefehle eingebettet sind, wobei jede der Definitionen ein Typ-Leistungsmerkmal oder eine Typ- Klasse von möglichen Typen von ereignisbasierten Daten identifiziert, die durch die entsprechenden Ereignismarkierungsbefehle gesammelt werden können, wobei jeder der Typen eine entsprechende Elementklasse von möglichen Elementen von ereignisbasierten Daten enthält, die für jenen Typ gesammelt werden können;

nach dem Einbetten der Ereignismarkierungsbefehle in die Software-Anwendung und vor oder während der Ausführung der Software-Anwendung:

(c) Auswählen einer Untermenge von Ereignismarkierungsbefehlen, die ausgewählte Ereignismarkierungsbefehle enthält, die bereits in die Software-Anwendung ein gebettet sind;

(d) Auswählen einer Typauswahl der Typen von zu sammelnden ereignisbasierten Daten aus dem Typ-Leistungsmerkmal oder der Typ-Klasse in der entsprechenden Definition für jeden der ausgewählten Ereignismarkierungsbefehle in der Untermenge und Auswählen einer Elementauswahl von ausgewählten der möglichen Elemente von zu sammelnden ereignisbasierten Daten aus der Elementklasse in der entsprechenden Definition für jeden der ausgewählten Typen;

(e) Auswählen einer Zeitperiode zum Sammeln der ausgewählten Elemente von ereignisbasierten Daten für die ausgewählten Ereignismarkierungsbefehle in der Untermenge; und

(f) Anordnen jedes der ausgewählten Ereignismarkierungsbefehle in der Untermenge im freigegebenen Zustand; und während der Ausführung der Software-Anwendung:

(g) Erfassen jedes der ausgewählten Ereignismarkierungsbefehle in der freigegebenen Untermenge und Sammeln jedes der ausgewählten Elemente jedes der ausgewählten Typen von ereignisbasierten Daten, die durch die Typauswahl und die Elementauswahl spezifiziert sind, zu Zeitpunkten, die in die ausgewählte Zeitperiode fallen.

2. Verfahren nach Anspruch 1, bei dem die Ereignismarkierungsbefehle einen Sammelsperrbefehl enthalten, der in die Software-Anwendung eingebettet werden kann, um jegliches Sammeln von Datenelementen durch sämtliche Ereignismarkierungsbefehle in dieser Anwendung zu sperren.

3. Verfahren nach Anspruch 1, in dem die Software- Anwendung mehrere Software-Schichten enthält, wobei in jede von ihnen Ereignismarkierungsbefehle eingebettet sein können.

4. Verfahren nach Anspruch 3, in dem die Definitionen der Ereignismarkierungsbefehle die Identifizierung der Software-Schicht enthalten, in die der Ereignismarkierungsbefehl eingebettet ist.

5. Verfahren nach Anspruch 1, in dem die Definitionen Klassen des Ereignismarkierungsbefehls und der Typen von ereignisbasierten Daten, die gesammelt werden können, enthalten.

6. Verfahren nach Anspruch 1, in dem die Definitionen der Ereignismarkierungsbefehle und die Auswahloperationen der Ereignismarkierungsbefehle in einer Datenbank gespeichert sind.

7. Verfahren nach Anspruch 1, in dem die durch die Ereignismarkierungsbefehle gesammelten ereignisbasierten Daten in einem Plattenspeicher gespeichert sind.

8. Verfahren nach Anspruch 1, das ferner so beschaffen ist, daß es ereignisbasierte Daten für mehrere Software-Anwendungen sammeln kann, und in dem die Schritte des Auswählens, Anordnens und Erfassens getrennt, gleichzeitig und selektiv in bezug auf jede der mehreren Software-Anwendungen ausgeführt werden.