DE69031706T2

DE69031706T2 - Architektur für Datenanbietungsnebenstelle

Info

Publication number: DE69031706T2
Application number: DE69031706T
Authority: DE
Inventors: Richard Francis Annicchiarico; Robert Todd Chesler; Alan Quentin Jamison
Original assignee: Digital Equipment Corp
Current assignee: Digital Equipment Corp
Priority date: 1989-11-30
Filing date: 1990-11-30
Publication date: 1998-04-30
Anticipated expiration: 2010-12-01
Also published as: EP0430708B1; US6247148B1; EP0430708A2; JPH03224037A; DE69031706D1; JPH0659934U; EP0430708A3

Description

Gebiet der Erfindung

Diese Erfindung betrifft allgemein eine Architektur für eine in einem Computersystem verwendete Servererweiterung, und insbesondere eine Architektur für eine Servererweiterung zum Abfangen von durch ein Anwenderprogramm erzeugten Eingabeereignissen und Protokollaufrufen. Die abgefangenen Eingabeereignisse und Protokolaufrufe werden nachfolgend für irgendeinen Zweck verwendet, wie beispielsweise zum Bestimmen der verstrichenen Zeit zwischen dem Eingabeereignis und dem Protokollaufruf zum Beurteilen der Leistungsfähigkeit des Servers und/oder des Anwenderprogramms.

Hintergrund

Der Server ist der Teil einer Computersystem-Architektur, der als Schnittstelle zwischen dem Computer oder dem Zentralprozessor und dem Benutzer wirkt. Es ist erwünscht, die Leistungsfähigkeit des Servers für verschiedene Zwecke zu testen oder zu beurteilen. Beispielsweise können lange Verzögerungen zwischen einer Benutzereingabe und der Systemantwort erfaßt und nachfolgend eliminiert werden. Gleichermaßen ist es erwünscht, auf dem Zentralprozessor des Computers laufende Anwenderprogramme für viele Zwecke zu testen und zu beurteilen. Allgemeine Verfahren zum Testen der Leistungsfähigkeit eines Servers enthalten die Verwendung von Videokameras oder Stoppuhren. Bei einem derartigen Verfahren werden der Anwender oder Operator, der an einem Terminal arbeitet, und der Terminalbildschirm durch eine Videokamera gefilmt. Danach wird das Video auf einer Maschine abgespielt, die eine Zeit als Funktion der Filmgeschwindigkeit anzeigt. Dann werden Bemessungen für die Leistungsfähigkeit basierend auf der Differenz zwischen der angezeigten Zeit eines Anfangsfilmereignisses und eines Endfilmereignisses berechnet. Dann werden die Bemessungen für die Leistungsfähigkeit für jedes zeitlich bestimmte Ereignis aufgezeichnet. Bei einem weiteren Verfahren weist der Schritt zum Berechnen von Bemessungen für die Leistungsfähigkeit ein manuelles zeitliches Bestimmen von Antwortzeiten mit einer Stoppuhr auf. Bei jedem Verfahren werden dann die Bemessungen für die Leistungsfähigkeit für alle zeitlich bestimmten Ereignisse analysiert, um die Leistungsfähigkeit der Anwendungen oder des Servers zu bestimmen. Genau derselbe Ansatz wird auch zum Bestimmen der Leistungsfähigkeit des Servers für ein einzelnes oder ein spezifisches Eingabeereignis verwendet. Dieses Verfahren ist zeitaufwendig, ermüdend und fehleranfällig. Weiterhin muß ein Benutzer bei diesem Verfahren tatsächlich an einem Arbeitsplatzrechner arbeiten. Somit ist eine simulierte Benutzereingabe unmöglich. Weiterhin ist es deshalb, weil eine tatsächliche Benutzereingabe von einer Operation zur nächsten inkonsistent ist, unmöglich, Durchlauf für Durchlauf eine konsistente Eingabe zu haben.
Eine andere Art zum Testen der Leistungsfähigkeit eines Anwenderprogramms oder eines Servers in Antwort auf Eingabeereignisse oder Protokolaufrufe erfolgt mit einer Fernterminal-Emulation (RTE). Eine RTE kommt ohne Bediener oder Operator zum Senden einer Eingabe zum Server oder zum Anwenderprogramm aus und ersetzt den Operator durch mittels Software erzeugte Eingabeereignisse, die auf die Servereingabeereignis-Warteschlange geladen werden. Jedoch sind frühere Versuche bei einer RTE an Servern der Systeme vom X-Fenstertyp diesbezüglich fehlgeschlagen, einen Weg zum Abfangen von ausgegebenen erzeugten Protokolaufrufen durch den Server oder die Anwendung bereitzustellen. Weiterhin hat keiner dieser Versuche ein Empfangen einer simulierten Eingabe von einer entfernten Quelle unterstützt, d.h. einer Quelle, die eine Eingabe über eine Nicht-X- Transportverbindung sendet, wie beispielsweise ein Netzwerk oder eine asynchrone Terminalitung. Somit können diese früheren Versuche bei einer RTE Testsystem-Konfigurationen nicht testen, die Netzwerke, Modems und andere periphere Vorrichtungen enthalten.
IBM Technical disclosure bulletin, Bd. 25, Nr. 11B, April 1983, New York, US, Seiten 6003-6008 von J. D. Dixon lehrt ein Computersystem mit einer Eingabelausgabesteuereinheit. Eine Statistikdaten-Sammeleinheit, die einer Servererweiterung entspricht, ist an die Eingabe/Ausgabeeinheit angebracht. Auf einen Empfang von Daten hin führt die Eingabe/Ausgabesteuereinheit eine Mikroprogramm-Routine zum Bearbeiten der Daten aus. Dieses Dokument offenbart die im Oberbegriff des Anspruchs 1 aufgezeigten Merkmale.

ZUSAMMENFASSUNG DER ERFINDUNG

Die vorliegende Erfindung betrifft eine Architektur für eine in einem Computersystem verwendete Servererweiterung und besteht in ihrer allgemeinen Form in einem Gerät und einem Verfahren, wie es jeweils in den Ansprüchen 1 und 2 angegeben ist. Eine Erweiterung ist ein Softwaremodul, das Serverfunktionen durchführt und einen Zugriff zu den Server-Variablen hat, aber kein permanenter Teil des Servers ist. Die Servererweiterung fängt Benutzer-Eingabeereignisse ab, bevor sie durch das Anwenderprogramm (auch Client genannt) empfangen werden, schreibt oder speichert Informationen über die Eingabe, einschließlich des Typs einer Eingabe und der Zeit, zu der abgefangen wurde, in eine vom Client definierte Stelle. Die vom Client definierte Stelle kann ein beliebiger Typ eines Speichers sein, wie beispielsweise eine sequentielle Datei. Der Speicher kann lokal oder an einer abgesetzten bzw. entfernten Stelle sein und über eine Modemleitung, eine Terminalleitung oder eine Netzwerkleitung angeschlossen sein. Weiterhin fängt die Servererweiterung durch das Anwenderprogramm erzeugte Ausgabe-Protokollaufrufe ab, bevor sie in sichtbaren Änderungen bezüglich der Bildschirm-anzeige eines Terminals resultieren. Ein Ausgabe-Protokollaufruf ist ein durch ein Anwenderprogramm erzeugtes und zum Server gesendetes Signal, welches den Server veranlaßt, Text oder Graphik auf dem Bildschirm eines Terminals zu zeichnen. Die Servererweiterung schreibt oder speichert auch Informationen über den Ausgabe- Protokollaufruf, einschließlich des Typs des Aufrufs und der Zeit, zu der er abgefangen wurde, in eine von einem Client definierte Stelle. Die von einem Client definierte Stelle kann irgendein Typ eines Speichers sein, wie beispielsweise eine sequentielle Datei. Der Speicher kann lokal oder an einer abgesetzten Stelle sein und über eine Modemleitung, eine Terminalleitung oder eine Netzwerkleitung angeschlossen sein. Schließlich kann die Servererweiterung eine Eingabe von von einem Benutzer betriebenen Eingabevorrichtungen empfangen, wie beispielsweise der Maus oder der Tastatur eines Arbeitsplatzrechners (einer Workstation) oder eine simulierte Eingabe vom steuernden Client.
Die Servererweiterungs-Architektur, wie sie hierin beschrieben ist, fängt Eingabeereignisse und Protokolaufrufe ab, die dazu verwendet werden, dem steuernden Client zu ermöglichen, einen Server oder das Anwenderprogramm zu überwachen, oder einen Arbeitsplatzrechner (eine Workstation) zu steuern, wie zum Beispiel ein Testen der Leistungsfähigkeit von Anwendungen, Systemkonfigurationen und Benutzerschnittstellen. Die Datenstrukturen der Servererweiterungs-Architektur sind in einem Teil oder einem Block eines Speichers konfiguriert und mimisch oder sind im wesentlichen identisch zu den Datenstrukturen des Servers, die in einem anderen Teil oder Block eines Speichers konfiguriert sind. Zusätzlich wird die Servererweiterungs-Architektur der vorliegenden Erfindung unter der Steuerung des Clients oder des Anwenderprogramms betrieben. Somit kann die Servererweiterungs- Architektur, während sie in bezug zu dem wohlbekannten X-Server- Betriebssystemprogramm beschrieben ist, ebenso mit irgendeinem anderen Betriebssystem implementiert sein.
Die Servererweiterungs-Architektur stellt auch einen RTE, d.h. eine Fernterminal- Emulation, zur Verfügung und kann eine simulierte Eingabe von einer entfernten Quelle empfangen. Beispielsweise stellt die Servererweiterungs-Architektur eine RTE-Fähigkeit für das X-Fenstersystem zur Verfügung, das ein wohlbekanntes Betriebssystem ist, das in R. W. Scheiffier, J. Gettys und R. Newman, "X Window System", Digital Press (1988) dokumentiert ist. Die Servererweiterungs-Architektur stellt auch ein schnelles billiges Mittel zum Testen auf Basis einer Software- Regression zur Verfügung, und zum Testen eines Wettbewerbs oder eines wechselseitigen Betriebs von Anwendungen zwischen unterschiedlichen Hardware- und Softwareplattformen. Die Servererweiterungs-Architektur ermöglicht dort, wo es wichtig ist, auch Befehle auf Computerbasis, um eine Interaktion eines Benutzers an einem Terminal zu überwachen und richtige Interaktionen demonstrieren zu können. Sie ermöglicht weiterhin Filmvorführungen, bei denen der Vorführer die Anwendung nicht verstehen muß, die gerade vorgeführt wird, oder sich eher auf den Kunden als auf die Vorführung konzentrieren muß. Wie es aus den obigen Beispielen klar wird, kann die Servererweiterungs-Architektur der vorliegenden Erfindung für eine breite Vielzahl von Zwecken verwendet werden, die Fachleuten auf dem technischen Gebiet klar sein werden.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Ein detaillierteres Verstehen der Erfindung kann aus der folgenden Beschreibung eines bevorzugten Ausführungsbeispiels erhalten werden, das anhand eines Beispiels angegeben ist und in Zusammenhang mit der beigefügten Zeichnung zu verstehen ist, wobei:
Fig. 1 den allgemeinen Betrieb der Servererweiterung eines bevorzugten Ausführungsbeispiels dieser Erfindung bei einer Verwendung mit einem Computersystem zeigt.
Fig. 2 die Datenstrukturen der Servererweiterung dieser Erfindung zeigt, sowie die Datenstrukturen des X-Servers, auf den die Erweiterung einen Zugriff hat.
Fig. 3 ein Prozeß-Ablaufdiagramm ist, das eine Anwenderprogrammimplementierung der Servererweiterung in einer Betriebsart zeigt.
Fig. 4 ein Prozeß-Ablaufdiagramm ist, das eine Anwenderprogrammimplementierung der Servererweiterung in einer anderen Betriebsart zeigt.

BESCHREIBUNG DES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS

Fig. 1 zeigt den allgemeinen Betrieb der Servererweiterungs-Architektur eines bevorzugten Ausführungsbeispiels der vorliegenden Erfindung bei einer Verwendung mit Grundkomponenten eines Computersystems. Eine Softwarekonfiguration läuft auf einem Zentral prozessor 10, der mit einem X-Server 12 in Wechselwirkung steht. Der X-Server ist ein wohlbekanntes Betriebssystemprogramm, das eine Benutzerschnittstelle des Terminals oder des Arbeitsplatzrechners (Workstation) 14 steuert und Fenster 16 und eine Maus 18 zusätzlich zu standardmäßigen Benutzerschnittstellenelementen, wie beispielsweise einer Tastatur 20 oder eines Textes, verwendet. Der X-Server 12 kann "Erweiterungen (extensions)" unterstützen oder Softwaremodule, die einen Zugriff zu X-Server-Variablen haben, die aber nicht permanenter Teil des X-Servers sind. Die Erweiterung 22 dieses Ausführungsbeispiels wird "X-Programmsprungerweiterung (XTrap extension)" genannt. Fachleute auf dem Gebiet werden wissen, wie die Lehren dieses Ausführungsbeispiels auf andere Betriebssysteme und Server anzuwenden sind.
Eine Vielzahl von Anwenderprogrammen 24A bis 24N kann auf dem Zentralprozessor (CPU) 10 laufen. Ein Anwenderprogramm oder ein Client 24N, das oder der auf der CPU 10 läuft, wirkt als steuernder Client der X- Programmsprungerweiterung 22, die eine Softwareerweiterung des X-Servers 12 ist. Bekannte Softwaremodule oder -erweiterungen, die Betriebssystemfunktionen durchführen, werden durch den Server gesteuert; die X- Programmsprungerweiterung 22 wird durch ein einzelnes Anwenderprogramm oder einen Client 24N gesteuert. Der steuernde Client 24N setzt die Parameter der X-Programmsprungerweiterung 22 und schaltet die X-Programmsprungerweiterung 22 ein und aus. Eine Benutzereingabe von der Maus 18 oder der Tastatur 20 wird zu Beginn durch den X-Server 12 empfangen. Die vorliegende Erfindung ist auch auf Betriebssysteme mit anderen Eingabevorrichtungen anwendbar, sowie auf Betriebssysteme mit nur einem Typ von Eingabevorrichtung. Die X- Programmsprungerweiterung 22 fängt die Eingabe ab, formatiert eine Kopie der Eingabe für eine Verwendung durch ihre "Schreib"-Routine neu, wie es unten ausführlicher aufgezeigt ist, und sendet die ursprüngliche Eingabe zur normalen Verarbeitung zum Server 12. Letztlich empfängt der Client 24A bis 24N-1, während der Client überwacht oder gesteuert wird, die ursprüngliche Eingabe und bearbeitet sie gemäß seiner besonderen Implementierung.
Jeder Client 24A bis 24N-1 erzeugt eine Ausgabe in der Form von Protokollaufrufen, und zwar normalerweise zum Steuern irgendeiner Art von Bildschirmausgabe beim Arbeitsplatzrechner (bei der Workstation) 14. Der steuernde Client 24N kann dieselbe Ausgabe auf einem Bildschirm bei einer anderen Workstation (nicht dargestellt) gleichzeitig anzeigen. Diese ausgegebenen Protokolaufrufe veranlassen den Server, Text, Linien oder andere graphische Elemente auf dem Anzeigebildschirm der Workstation 14 zu zeichnen. Obwohl beim bevorzugten Ausführungsbeispiel die einzigen Kommunikationen zwischen den Anwenderprogrammen und dem X-Server, der einen X-Programmsprung abfängt, Ausgabe-Protokollaufrufe sind, könnte die vorliegende Erfindung zum Abfangen irgendeiner Kommunikation zwischen irgendeinem Client und dem Server verwendet werden. Der X-Server 12 empfängt Ausgabe-Protokollaufrufe von einem Anwenderprogramm 24A-24N-1 und die X-Programmsprungerweiterung 22 fängt sie ab, bevor der X-Server sie verarbeitet. Wie bei einer Eingabe formatiert die X-Programmsprungerweiterung eine Kopie neu und sendet das Original zurück zum X-Server. Schließlich erreicht die Ausgabe den Bildschirm der Workstation 14, um die Form des Textes, der Linien oder ein Löschen zu steuern.
Die X-Programmsprungerweiterung 22 ruft ein "Schreib"-Unterprogramm auf, das Teil des Codes der Erweiterung ist. Ein (nicht programmierter) X-Programmsprung hat für jeden Kommunikationskanal ein anderes "Schreib"-Programm, über den ein X-Programmsprung mit dem steuernden Client kommunizieren kann. Der steuernde Client kann an einer vom X-Programmsprung abgesetzten Stelle sein, wie beispielsweise am anderen Ende einer Netzwerkleitung. Dieses "Schreib"-Programm sendet die gesammelten Informationen über Eingaben und Ausgaben zum steuernden Client 24N oder zu einer sequentiellen Datei.
Fig. 2 zeigt die Architektur der X-Programmsprungerweiterung und des Servers. Die vorliegende Erfindung ist nicht auf eine Verwendung mit einer Architektur dieses Typs begrenzt, sondern wird bei einer beliebigen Betriebssystemarchitektur arbeiten, die Unterprogramme zum Verarbeiten einer Eingabe und eines Protokollaufrufs aufruft. Der X-Server verarbeitet Tastaturdaten, indem er sie zu dem Programm sendet, dessen Adresse in der "Tastatur-Verfahrenseingabeverarbeitungs"- Speicherstelle 28 gespeichert ist. Der Server bearbeitet eine Mauseingabe auf ähnliche Weise, d.h. durch Bezugnahme auf die "Zeiger Verfahrenseingabeverarbeitungs"-Speicherstelle 30. Der X-Server verarbeitet Ausgabe-Protokollaufrufe durch Senden der geeigneten Informationen zu dem Programm, dessen Adresse in einem spezifizierten Element des "Verarbeitungsvektor"-Felds 32 gespeichert ist.
Die X-Programmsprungerweiterung enthält Datenstrukturen, die halb so groß wie die X-Server-Datenstrukturen sind, jedoch kann die Größe kleiner oder sogar identisch sein. Die X-Programmsprung-Datenstrukturen sind im Speicher auch mit derselben oder im wesentlichen derselben Konfiguration wie die X-Server- Datenstrukturen ausgelegt. Ein Fachmann auf dem Gebiet wird wissen, wie die Lehren dieser Erfindung zu verwenden sind, um Mittel zum Nachahmen der Architektur eines anderen Betriebssystems zu schaffen, so daß sie Erweiterungsunterprogramme zum Verarbeiten einer Eingabe (und/oder einer Ausgabe) anstelle ihrer eigenen aufruft, während gleichzeitig Mittel zum Zurückbringen des Betriebssystems in seinen normalen Zustand geschaffen werden, nachdem die Verwendung der Erweiterung beendet ist. Wenn ein X-Programmsprung zum Abfangen einer Tastatureingabe konfiguriert ist, enthält die X-Server-Speicherstelle 28, nämlich die "Tastatur-Verfahrenseingabeverarbeitungs"-Speicherstelle, die Adresse des X- Programmsprung-Programms, das eine Tastatureingabe bearbeitet, und die X- Programmsprungversion dieses Speicherraums, die "Tastatur- Eingabeverarbeitung" 34 genannt wird, speichert die Adresse des X-Server- Eingabebearbeitungsprogramms. Wenn ein X-Programmsprung zum Abfangen einer Mauseingabe konfiguriert ist, enthält die "Zeiger- Verfahrenseingabeverarbeitungs"-Speicherstelle 30 des X-Servers die Adresse des X-Programmsprung-Programms, das eine Mauseingabe bearbeitet, und die X- Programmsprungversion dieses Speicherraums, die "Zeiger-Eingabeverarbeitung" 36 genannt wird, speichert die Adresse des X-Server Eingabebearbeitungsprogramms.
Wie es aus der obigen Konfiguration gesehen werden kann, fängt ein X- Programmsprung eine Tastatur- und Mauseingabe ab. Wie es oben erklärt ist, ruft der X-Server, wenn er eine Tastatureingabe empfängt, das Programm auf, dessen Adresse in der "Tastastur-Verfahrenseingabeverarbeitungs"-Speicherstelle 28 gespeichert ist, und wenn er eine Mauseingabe empfängt, ruft er das Programm auf, dessen Adresse in der "Zeiger-Verfahrenseingabeverarbeitungs"-Speicherstelle 30 gespeichert ist. Da während der Implementierung eines X-Programmsprungs diese Speicherstellen 28 und 30 die Adressen der X-Programmsprung-Programme enthalten, werden die Tastatur- und Mauseingabe zur X-Programmsprungerweiterung gesendet.
Die X-Programmsprungerweiterung fängt vom Client erzeugte Ausgabe- Protokollaufrufe durch Austauschen der Adresse des Programmsprungerweiterungs-Ausgabebearbeitungsprogramms mit der Adresse des in einer "Verarbeitungsvektor" genannten Datenstruktur 32 gespeicherten X- Server-Ausgabebearbeitungsprogramms ab. Jeder 4-Byte-Wert ist eine Adresse eines Programms, das einen Ausgabe-Protokollaufruf bearbeitet. Beim bevorzugten Ausführungsbeispiel gibt es 256 4-Byte-Adressen, aber es ist innerhalb des Schutzumfangs dieser vorliegenden Erfindung, kleinere oder größere Felder zu haben. Ein Feldelement 42 enthält die Adresse für das Programm, das einen "Bildtext 8"-Aufruf bearbeitet. Dieses Programm zeichnet eine einzelne Kette eines Textes auf dem Bildschirm. Wenn ein X-Programmsprung zum Abfangen des "Bildtext 8"-Ausgabe-Protokollaufrufs konfiguriert ist, ist der an dieser Stelle gespeicherte Wert die Adresse eines X-Programmsprung-Programms, das eine einzelne Kette eines Textes auf dem Bildschirm zeichnet. Dieses Programm wird "Erweiterungs-Bildtext 8" genannt. Die Adresse des "Bildtext 8"-Programms wird am entsprechenden Element 44 des "Erweiterungs-Verarbeitungsvektor"-Feldes 38 gespeichert, das eine X-Programmsprung-Version der X-Server- "Verarbeitungsvektor"-Datenstruktur 32 ist. Somit ruft der X-Server dann, wenn er einen Aufruf von einem beliebigen Client zum Zeichnen einer Textkette empfängt, das Programm auf, dessen Adresse im Element 42 des "Verarbeitungsvektors" 32 gespeichert ist. Während ein X-Programmsprung aktiv ist, wird jene Adresse die Adresse des X-Programmsprung-Programms "Erweiterungs-Bildtext 8" sein, das normalerweise beim Element 44 gespeichert ist.
Andere Ausgabe-Protokollaufrufe sind beispielsweise "Polytext 8", der mehr als eine Textkette auf dem Bildschirm zeichnet; "Fensterabbildung" bzw. "Mapwindow", der den Server zum Zeichnen eines Fensters auf dem Bildschirm vorbereitet; und "Fensterlöschen" bzw. "Unmapwindow", der Fenster vom Bildschirm löscht. Die entsprechenden Programme in der X-Programmsprung- Datenstruktur 38 sind "Erweiterungs-Polytext 8", "Erweiterungs-Fensterlöschen (ext_unmapwindow)" und "Erweiterungs-Fensterabbildung (ext_mapwindow)". Jeder andere Ausgabe-Protokollaufruf kann durch die X-Programmsprungerweiterung auf ähnliche Weise abgefangen werden.
Wenn die X-Programmsprungerweiterung eine Eingabe oder eine Ausgabe abfängt, erzeugt sie eine Kopie der Eingabe- oder Ausgabeinformationen, die zur Verarbeitung durch das X-Programmsprung-"Schreib"-Programm formatiert sind, das der Client konfiguriert hat. Während ein X-Programmsprung "ein"-geschaltet wird, wird die Adresse des "Schreib"-Programms im "X-Programmsprung-Schreib"- Vektor 40 gespeichert. Wenn ein X-Programmsprung "aus"-geschaltet wird, hält "X- Programmsprung-Schreiben" die Adresse eines Null-Programms, d.h. eines Programms, das nichts anderes tut als eine Steuerung zum X-Programmsprung zurückzubringen. In jedem Fall sendet ein X-Programmsprung dann, wenn er dazu konfiguriert ist, irgendeine Eingabe oder Ausgabe abzufangen, eine Kopie einer formatierten Eingabe oder Ausgabe zum Programm, dessen Adresse im "X- Programmsprung-Schreiben" gespeichert ist.
Die Datenstruktur "Erweiterungs-Umgebung (ext_environment)" 48 enthält die internen X-Programmsprung-Variablen. Die Variable "Austausch^G-Zustand" ist ein Bit-Feld, das anzeigt, welche Ausgabe-Protokollaufrufe und Eingabeereignisse gerade abgefangen werden. Die Variable "allgemeine Flags" ist ein Bit-Feld von allgemeinen Erweiterungsflags, die verschiedene Eigenschaften, wie beispielsweise eine Berechnung eines Zuschreibens von Datum und Uhrzeit, eine "Fenster-Identifizierungs"-Verarbeitung, freigeben und sperren und ein Format ausgeben (d.h. ein binäres Format oder ein ASCII-Format). Eine "Fenster-Identifizierungs"- Verarbeitung veranlaßt dann, wenn sie freigegeben ist, daß ein X-Programmsprung berichtet, welches Fenster das Objekt eines "Fensterabbildungs" oder eines "Fensterlöschungs"-Ausgabe-Protokollaufrufs ist. Die Variable "osflg" ist ein Bit- Feld von Flags, die spezifisch für eine Implementierung sind. Die Variable "imagcnt" hält die maximale Anzahl von Zeichen, die ein X-Programmsprung von einer Textkette aufbewahrt, wenn ein X-Programmsprung einen "Bildtext"- oder einen "Polytext"-Aufruf abfängt. Die aufbewahrten Zeichen sind Teil der Informationen über Ausgabe-Protokollaufrufe, die ein X-Programmsprung zum "Schreib"- Programm sendet. Wenn "imagcnt" negativ ist, werden die Zeichen vom Anfang der Kette an aufbewahrt; wenn "imagcnt" positiv ist, werden die Zeichen vom Ende der Kette an aufbewahrt.
Die Variable "polycnt" hält die maximale Anzahl von Ketten, die ein X- Programmsprung verarbeiten sollte, wenn ein X-Programmsprung einen "Polytext"- Aufruf abfängt. Wenn die Ketten verarbeitet werden, werden "imagcnt"-Zeichen zum "Schreib"-Programm gesendet. Wenn "polycnt" positiv ist, werden Ketten von Beginn der Kettenste an verarbeitet; wenn "polycnt" negativ ist, werden Ketten vom Ende der Kettenste an verarbeitet. Die Variable "i_comm" enthält einen Identifizierer für den Kommunikationskanal, der gerade für eine simulierte Eingabe zum X-Programmsprung verwendet wird. Die Variable "o_comm" enthält einen Identifizierer für den Kommunikationskanal, der gerade für eine Ausgabe von der X-Programmsprungerweiterung verwendet wird. Schließlich hält die Variable "write_io" den Zeiger zum "Schreib"-Programm, das im "X-Programmsprung- Schreiben" angeordnet ist, wenn ein X-Programmsprung einen START_IO-Aufruf empfängt.
Die Fig. 3 und 4 sind Prozeß-Ablaufdiagramme, die eine Konfiguration eines Anwenderprogramms oder eines steuernden Clients und eine Verwendung der X- Programmsprung-Servererweiterung in zwei unterschiedlichen Betriebsarten zeigen. Fig. 3 ist ein Prozeß-Ablaufdiagramm, das den Betrieb der X- Programmsprung-Servererweiterung zeigt, wenn eine Aufzeichnen von Eingabeereignissen oder Ausgabe-Protokollaufrufen während einer Sitzung eines Bedieners erzeugt wird, was Aufzeichnungsbetriebsart genannt wird. Fig. 4 ist ein Prozeß-Ablaufdiagramm, das den Betrieb der X-Programmsprung- Servererweiterung unter Verwendung der RTE, d.h. der Fernterminal- Emulationsfähigkeiten, zum Simulieren einer Sitzung eines Bedieners unter Verwendung simulierter Eingabeergebnisse und eines Wartens auf abgefangene Ausgabeereignisse zeigt, was Abspiel-Betriebsart genannt wird. Der steuernde Client kommuniziert mit der X-Programmsprungerweiterung durch Senden einer Datenstruktur zum Server über das XLIB xflush Makro, welches in R. W. Scheiffler, J. Gettys und R. Newman, - X Window System, veröffentlicht von Digital Press (1988) dokumentiert ist. Der Server sendet dann die Datenstruktur zur Erweiterung. Tabelle 1 zeigt das Format der Datenstruktur "xXtrapReq". Tabelle 1 Die xXtrapReq-Datenstruktur (Kurzversion)
Das erste Feld "reqType" identifiziert, zu welcher X-Programmsprungerweiterung die Datenstruktur "xXtrapReq" durchgelassen werden sollte. Der Client sammelt diesen Identifizierer durch Aufrufen von "xQueryExtension", was in R. W. Scheiffler, J. Gettys und R. Newman mit dem Titel X Window System von Digital Press (1988) dokumentiert ist. Das zweite Feld "minor_opcode" enthält den Identifizierer für den spezifischen X-Programmsprungerweiterungsaufruf, den der Client gerade sendet. Nimmt man wieder Bezug auf Fig. 2, enthält das "ext_request_vector"-Feld 46 eine Abwicklertabelle, die ein X-Programmsprung zum Schauen auf die "minor_opcodes" und zum Aufrufen des geeigneten Aufrufverarbeitungsprogramms verwendet. Das dritte Feld "Länge (length)" ist für X-Programmsprungaufrufe immer 9. Das vierte Feld "Daten (data)" ist eine Vereinigung, die für jeden Aufruf unterschiedlich konfiguriert ist. Sie enthält die Daten, die für den gerade gesendeten Aufruf spezifisch sind. Die vorliegende Erfindung ist nicht auf die Verwendung von xflush zum Kommunizieren mit der Erweiterung begrenzt.
Nimmt man wieder Bezug auf Fig. 3, besteht der erste Schritt, den ein Client beim Konfigurieren eines X-Programmsprungs durchführt, darin, den Erweiterungsidentifizierer durch Aufrufen von "yQueryExtension" zu erhalten, was in R. W. Scheiffier, J. Gettys und R. Newman mit dem Titel X Window System von Digital Press (1988) dokumentiert ist. Als nächstes ruft der Client den X-Programmsprung-Rücksetz-Aufruf (XTRAP_RESET) durch Setzen der verschiedenen Felder der "xXtrapReq" Struktur und durch Senden von ihr zum Server über das xflush-Makro auf. Der X- Programmsprung-Rücksetz-Aufruf veranlaßt die Erweiterung, sich selbst zur Verwendung durch einen neuen Client vorzubereiten. Wenn ein Client die Erweiterung bereits verwendet und sich zuvor selbst als steuemden Client konfiguriert hat, wird ein X-Programmsprung das "Zwangs"-Flag im Aufruf prüfen. Das "Zwangs"-Flag ist Teil der aufrufspezifischen Informationen, die im "Rücksetz"-Vereinigungsfeld von "xXtrapReq" zum X-Programmsprung gesendet werden. (siehe Tabelle 2) Tabelle 2 Die xXTrapReq-Datenstruktur (Langversion - die Inhalte der "Daten"-Vereinigung zeigt)
Wenn das "Zwangs"-Flag gesetzt ist, wird ein X-Programmsprung sich selbst rücksetzen und sich selbst von der Steuerung der anderen Client entfernen. Wenn das "Zwangs"-Flag nicht gesetzt ist, wird ein X-Programmsprung einen Fehlercode zum Client zurückbringen.
Ein Client kann einen anderen Client davon abhalten, eine zufällige Steuerung einer Erweiterung durch Ersetzen des "Steuer"-Flags während eines X- Programmsprung-Rücksetz-Aufrufs zu gewinnen. Ein Setzen des "Steuer"-Flags veranlaßt, daß die X-Programmsprungerweiterung alle nachfolgenden X- Programmsprung-Rücksetz-Aufrufe von einem anderen Client solange ignoriert, bis der andere Client das "Zwangs"-Flag setzt. Das "Steuer"-Flag ist wie das "Zwangs"-Flag ein Teil der "Rücksetz"-Vereinigung.
Wenn die X-Programmsprungerweiterung einen X-Programmsprung-Rücksetz- Aufruf empfängt, setzt sie interne Variable des X-Programmsprungs und Flags auf ihre Grundwerte zurück und führt keinerlei Konfiguration zum Abfangen einer Eingabe oder Ausgabe durch. Alle Client-Programme senden einen X- Programmsprung-Rücksetz-Aufruf, bevor sie enden.
Wenn die X-Programmsprungerweiterung einmal rückgesetzt ist, sendet der Client einen X-Programmsprung-Konfigurations-Aufruf (XTRAP_CONFIG) zum Einstellen der Art einer Eingabe und einer Ausgabe die von der Erweiterung abzufangen ist. Für den X-Programmsprung-Konfigurations-Aufruf hat die "Daten"-Vereinigung von "xXtrapReq" die in Tabelle 3 gezeigte Struktur. Tabelle 3 Die Konfigurationsvereinigung
Das "Flag"-Feid wird zum Freigeben und Sperren eines Abfangens einer Eingabe und einer Ausgabe verwendet und ist in Tabelle 4 gezeigt. Tabelle 4
Ein Setzen des Flags "v_kbd" veranlaßt, daß der X-Programmsprung den Zustand des Abfangens einer Tastatureingabe gemäß dem Zustand des Flags "s_kbd" setzt. Wenn "s_kbd" im Ein-Zustand ist, ist das Abfangen der Tastatureingabe freigegeben. Wenn es im Aus-Zustand ist, ist ein Abfangen der Tastatureingabe gesperrt. Eine Mauseingabe wird auf ähnliche Weise mit den Flags "v_ptr" und "s_ptr" gesteuert. Das Paar von Flags "v_opcodes" und "s_opcodes" wirken auf dieselbe Weise zum Freigeben oder Sperren des Abfangens von Ausgabe- Protokollaufrufen, die im "Listen"-Feld der in Tabelle 3 gezeigten "Konfigurations"- Struktur aufgelistet sind.
Der X-Programmsprung-Konfigurations-Aufruf kann auch die Erweiterung dazu konfigurieren, ein Zuschreiben von Datum und Uhrzeit im Millisekundenbereich für eine abgefangene Eingabe oder einen abgefangenen Ausgabe-Protokollaufruf durchzuführen. X-Programmsprung-Konfiguration stellt auch eine gewisse Steuerung über die Form einer durch einen X-Programmsprung erzeugten Ausgabe zur Verfügung, nämlich über die Auswahl zwischen einem ASCII-Format und einem binären Format.
Wenn die X-Programmsprungerweiterung einen X-Programmsprung- Konfigurations-Aufruf empfängt, führt sie die Austauschoperation durch, die die Adresse des X-Programmsprung-Eingabe- oder -Ausgabeverarbeitungsprogramms mit der Adresse des X-Server-Eingabe- oder -Ausgabeverarbeitungsprogramms für jeden Typ eines durch den Client ausgewählten Eingabe- oder Ausgabe- Protokollaufrufs austauscht. Beispielsweise wird dann, wenn der Client Flags "v_kbd" und "s_kbd" in seinem X-Programmsprung-Konfigurations-Aufruf setzt, ein X-Programmsprung unter Bezugnahme auf Fig. 2 den "Tastatur-Prozeß"-Zeiger im "Tastatur-Prozeßeingabeverarbeitungs"-Vektor 28 mit dem Zeiger "X- Programmsprung_Tastatur" in "Tastatur_Eingabeverarbeitung" 34 austauschen. Wenn der Client das Flag "v_kbd" setzt, aber das Flag "s_kbd" ungesetzt läßt, werden die zwei Zeiger nicht ausgetauscht. Der X-Programmsprung-Rücksetz-Aufruf veranlaßt den X-Programmsprung auch dazu, "Tastatur- Prozeßeingabeverarbeitung" und "X-Programmsprung_Tastatur" nicht auszutauschen.
Als nächstes sendet der Client einen Konfigurations-Eingabe/Ausgabe-Aufruf zum X-Programmsprung, um zu spezifizieren, über welche Art von Kommunikationskanal Informationen über gesammelte Eingaben und Ausgaben zum steuernden Client zu senden sind. Wenn der X-Programmsprung diesen Aufruf empfängt, setzt er seine interne Variable "write_io" (48 in Fig. 2) auf den Wert eines Zeigers zu einem "Schreib"-Programm. Dieses Programm wird zum Senden der Informationen über abgefangene Eingabeereignisse und Ausgabe-Protokollaufrufe zum steuernden Client über den konfigurierten Kommunikationskanal verwendet. Im Aufzeichnungsmodus zeichnet der Client die Informationen in einer sequentiellen Datei auf. Im Abspielmodus verwendet der steuemde Client die über das konfigurierte "Schreib"-Programm empfangenen Informationen, um zu verifizieren, daß eine simulierte Eingabe zum Server gesendet wurde. Dies läßt zu, daß der steuernde Client sicherstellt, daß der Server eine Eingabe von der Tastatur oder der Maus dann ignorieren wird, wenn dies aus Gründen der Sicherheit oder aus anderen Gründen nötig ist. Der Client verwendet auch die Informationen zum Überwachen von Ausgabe-Protokollaufrufen, um sicherzustellen, daß er mit dem Senden des nächsten Eingabeereignisses solange wartet, bis der letzte Ausgabe-Protokollaufruf verarbeitet worden ist. Im Abspielmodus kann der steuernde Client auch die Informationen in einer sequentiellen Datei aufzeichnen. Beispielsweise dann, wenn der letzte Ausgabe-Protokollaufruf ein Aufruf für ein sofortiges "$" war, muß der Client warten, bis "$" auf dem Bildschirm erscheint, bevor er das nächste Eingabeereignis sendet.
Im Abspiel modus wird der Konfigurations-Eingabelausgabe-Aufruf (CONFIF_IO) zum Impementieren einer Fernterminal-Emution (RTE) gemacht. Tabelle 5 zeigt die Struktur der "Daten"-Vereinigung "xXtrapReq" für den Konfigurations- Eingabe/Ausgabe-Aufruf. Tabelle 5 Die Eingabe/Ausgabe-Vereinigung
Das "Transport"-Feld enthält einen Dezimalwert, der den Typ eines Kommunikationskanals beschreibt, der gerade konfiguriert wird. Beispiele von Kommunikationskanälen sind asynchrone Terminalleitungen, sequentielle Daten, TCP/IP- Netzwerke, eine VMS-Briefkastenverbindung, eine XLIB-Transport und eine DEC- Netz-Aufgabe-zu-Aufgabe-Kommunikation. Eine über einen XLIB-Transport gesendete Eingabe wird über das xflush Makro unter Verwendung eines X-Ereignis- Simulations-Aufrufs (SIMULATE_XEVENT) oder des Zeiger-Bewegungs-Aufrufs (MOVE_POINTER) gesendet, die unten erörtert sind. Es kann gesehen werden, daß durch Verwenden sequentieller Daten als Quelle für eine Tastatur- und eine Mauseingabe ein Anwenderprogramm bezüglich der Leistungsfähigkeit ohne einen Bediener getestet werden kann. Weiterhin werden eine Software-Regression und ein konkurrierendes Testen vereinfacht. Das "Richtungs"-Feld spezifiziert, ob der Konfigurations-Eingabelausgabe-Aufruf eine Eingabe, eine Ausgabe oder beides betrifft.
Wenn die X-Programmsprungerweiterung einmal konfiguriert ist, führt der Client den Start-Eingabe/Ausgabe-Aufrufag (START_IO) durch, um eine Eingabe/Ausgabe über die Kommunikationsmedien zu starten, die mit dem Konfigurations-Eingabelausgabe-Aufruf konfiguriert sind, und um das "Schreib"-Programm zu initiieren, das Eingabe- und Ausgabeinformationen zum steuernden Client sendet. Die einzigen Daten, die mit diesem Aufruf spezifiziert werden, sind (1) die Anzahl von Zeichen, die die Erweiterung von einer abgefangenen Textkette speichern sollte, die Teil eines Ausgabe-Protokollaufrufs ist, und (2) die Anzahl von Textketten, die die Erweiterung verarbeiten sollte, wenn die Erweiterung "Polytext 8" abfängt, was ein Ausgabe-Protokollaufruf ist, der den Server auffordert, mehr als eine Textkette auf dem Bildschirm zu zeichnen (siehe Tabelle 6). Tabelle 6 Die Start-Vereinigung
Wenn der steuernde Client seine Fernsteuerung beendet hat, oder eine Überwachung einer Workstation, die eine X-Programmsprungimplementierung benötigt, sollte der Client einen Stop-Eingabelausgabe-Aufruf zur X-Programmsprung- Servererweiterung über den xflush Makro senden. Dies führt dazu, daß ein Zeichenfluß zu und von den Eingabelausgabe-Kanälen aufhört. Bevor der Client zum Stoppen einer Ausführung bereit ist, sollte er einen X-Programmsprung-Rücksetz- Aufruf zur X-Programmsprungerweiterung senden, um nicht irgendwelche Eingabeoder Ausgabe-Verarbeitungsprogramme auszutauschen.
Der steuernde Client kann den X-Programmspprung-Informations-Aufruf (XTRAP_INFO) senden, wann immer der steuernde Client die Werte irgendwelcher interner Variablen kennen muß.
Der steuernde Client kann die X-Ereignis-Simulations- und Zeiger-Bewegungs- Anfragen im Abspielmodus zum Senden einer Eingabe zum X-Server "ber XLIB verwenden. Tabelle 7 zeigt das Format der "Daten"-Vereinigung der "xXtrapReq"- Struktur zur Verwendung mit X-Ereignis-Simulation und Zeiger-Bewegung (SIMULATE_XEVENT und MOVE_POINTER). X-Ereignis-Simulation wird zum Senden von Tastaturereignissen und Mauskickereignissen verwendet. Tabelle 7 Die X-Eingabevereinigung
Zeiger-Bewegung wird zum Senden von Mausbewegungsereignissen verwendet. Der variable "Typ" wird auf den Wert eines ldentifizierers für den Typ des Ereignisses gesetzt, der gerade gesendet wird, was im Fall eines Zeiger-Bewegungs- Aufrufs ein Mausbewegungsereignis ist. Die Variable "Detail" wird auf den Wert eines Identifizierers für die Taste oder den Mausknopf gesetzt, die oder der bei einem X-Ereignis-Simulations-Aufruf gedrückt oder losgelassen ist. Die Variablen "x" und "y" werden auf die Zielortbildschirmkoordinaten des Maus-Cursors eingestellt.
Die vorangehende Beschreibung der Erfindung ist zu Zwecken einer Darstellung und einer Beschreibung präsentiert worden. Sie ist nicht dafür gedacht, die Erfindung auf die offenbarten präzisen Formen zu beschränken, und offensichtlich sind viele Modifikationen und Veränderungen möglich und angesichts der obigen Lehren in Aussicht gestellt.

Claims

1. Servererweiterung (22), die ein Softwaremodul aufweist, zur Verwendung in einem Computersystem mit einem Hostcomputer, einschließlich eines Servers zum Ausführen von Anwenderprogrammen (24A...24N), einer Benutzerschnittstelle (14) zum Anzeigen von Text- oder Graphikzeichen, wobei wenigstens ein Anwenderprogramm eine Ausführung auf dem Hostcomputer zum Erzeugen von Ausgabe-Protokollaufrufen durchführt, wobei ein steuerndes Anwenderprogramm (24N) auf dem Hostcomputer zum Erzeugen von Eingaben und Erweiterungsprotokollaufrufen handelt, wobei der Server (12) einen Teil eines Speichers mit adressierbaren Stellen und einer Vielzahl von Serverprogrammen aufweist, die jeweils eine Adresse haben, wobei der Server Leistungscharakteristiken hat, die über einen Bereich variabel sind, wobei der Server (12) die Eingaben empfängt, die Eingaben zum Anwenderprogramm überträgt, die Ausgabe-Protokollaufrufe empfängt und die Ausgabe- Protokolaufrufe zur Benutzerschnittstelle (14) überträgt, wobei die Servererweiterung (22) gekennzeichnet ist durch:

einen Erweiterungsteil eines Speichers, der direkt mit dem steuernden Anwenderprogramm (24N) verbunden ist, zum Erzeugen einer Aufzeichnung der Eingabe- und Ausgabedaten zur Verwendung bei einer Beurteilung, ob die Leistungscharakteristiken innerhalb eines akzeptierbaren Bereichs sind, und zwar durch Überwachen entweder des Servers (12) oder des Anwenderprogramms;

wobei der Erweiterungsteil des Speichers spezifische Speicherstellen für eine Datenspeicherung hat, die den spezifischen Speicherstellen im Serverteil des Speichers entsprechen;

eine Vielzahl von Erweiterungsprogrammen, die jeweils eine Adresse haben, wobei jedes der Erweiterungsprogramme einem der Serverprogramme entspricht;

wobei die Adressen für die Vielzahl von Serverprogrammen im Erweiterungsteil des Speichers gespeichert sind, und wobei die Adressen für die Vielzahl von Erweiterungsprogrammen im Serverteil des Speichers gespeichert sind;

wobei die Eingaben und die Ausgabe-Protokollaufrufe jeweils zu einem der Serverprogramme gerichtet sind;

wobei die Erweiterung (22) die Erweiterungsprotokollaufrufe vom steuemden Anwenderprogramm (24N) zum Konfigurieren und zum Steuern der Erweiterung empfängt; und

wobei die Erweiterung (22) die Eingaben und die Ausgabe- Protokollauffe abfängt, die verursacht sind, um durch das steuernde Anwenderprogramm (24N) erzeugt zu werden, und die Eingaben und die Ausgabe-Protokollanfragen erneut zu einem der Erweiterungsprogramme richtet, wobei das eine der Erweiterungsprogramme strukturmäßig dem Serverprogramm entspricht, zu dem die Eingaben und Ausgabe-Protokollaufrufe gerichtet sind, wobei die Erweiterung eine Kopie der Eingaben und der Ausgabe- Protokolaufrufe zum Überwachen des Servers (12), zum Überwachen der Leistungsfähigkeit des Anwenderprogramms oder zum Formatieren einer Anzeige der Text- oder Graphikzeichen an der Benutzerschnittstelle (14) neu formatiert.

2. Verfahren zum Betreiben einer Servererweiterung (22), die ein Softwaremodul in einem Computersystem mit einer Benutzerschnittstelle (14) zum Anzeigen von Text- oder Graphikzeichen aufweist, einen Hostcomputer einschließlich eines Servers (12) zum Ausführen von Anwenderprogrammen (24A...24N), wobei wenigstens ein Anwenderprogramm eine Ausführung auf dem Hostcomputer zum Erzeugen von Ausgabe-Protokollaufrufen durchführt, wobei ein steuerndes Anwenderprogramm (24N) eine Ausführung auf dem Hostcomputer durchführt, um ihn zu veranlassen, Eingaben und Erweiterungsprotokollaufrufe zu erzeugen, wobei der Server (12) einen Teil eines Speichers aufweist und Leistungscharakteristiken hat, die über einen Bereich variabel sind, wobei der Server (12) eine Vielzahl von Serverprogrammen aufweist, die jeweils eine Adresse haben, wobei die Eingaben und die Ausgabe- Protokolaufrufe jeweils zu einem der Serverprogramme gerichtet sind, wobei die Servererweiterung durch einen Erweiterungsteil eines Speichers gekennzeichnet ist, der direkt mit dem steuernden Anwenderprogramm verbunden ist, wobei der Serverteil des Speichers spezifische Speicherstelen zur Datenspeicherung aufweist, die spezifischen Speicherstellen dem Erweiterungsteil des Speichers entsprechen, wobei die Servererweiterung (22) eine Vielzahl von Erweiterungsprogrammen hat, die jeweils eine Adresse haben, wobei jedes der Erweiterungsprogramme strukturmäßig einem der Serverprogramme entspricht, wobei das Verfahren weiterhin gekennzeichnet ist durch:

Empfangen der Erweiterungsprotokollaufrufe vom steuernden Anwenderprogramm (24N);

Konfigurieren des Erweiterungsteils des Speichers in Antwort auf die Erweiterungsprotokollanfragen;

Empfangen der Eingaben und der Ausgabe-Protokollaufrufe vom Server (12);

erneutes Richten der Eingaben und der Ausgabe-Protokollaufrufe zu einem der Erweiterungsprogramme, wobei das eine der Erweiterungsprogramme dem Serverprogramm entspricht, zu dem die Eingaben und die Ausgabe- Protokollaufrufe gerichtet sind;

erneutes Formatieren einer Kopie der Eingaben und der Ausgabe- Protokolaufrufe zum Überwachen des Servers (12), zum Überwachen der Leistungsfähigkeit des Anwenderprogramms oder zum Formatieren einer Anzeige der Text- oder Graphikzeichen auf der Benutzerschnittstelle (14); und

Erzeugen einer Aufzeichnung von Eingabe- und Ausgabedaten zur Verwendung bei einer Beurteilung, ob die Leistungscharakteristiken innerhalb eines akzeptierbaren Bereichs sind.