EP1010073A1 - Verfahren zur ereignis- und zeitsteuerung - Google Patents

Verfahren zur ereignis- und zeitsteuerung

Info

Publication number
EP1010073A1
EP1010073A1 EP98942463A EP98942463A EP1010073A1 EP 1010073 A1 EP1010073 A1 EP 1010073A1 EP 98942463 A EP98942463 A EP 98942463A EP 98942463 A EP98942463 A EP 98942463A EP 1010073 A1 EP1010073 A1 EP 1010073A1
Authority
EP
European Patent Office
Prior art keywords
specified
property
existence
column
conditions
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP98942463A
Other languages
English (en)
French (fr)
Inventor
Ralph Rinschen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wincor Nixdorf International GmbH
Original Assignee
Wincor Nixdorf International GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wincor Nixdorf International GmbH filed Critical Wincor Nixdorf International GmbH
Publication of EP1010073A1 publication Critical patent/EP1010073A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3017—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is implementing multitasking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring

Definitions

  • the invention relates to an operating method for a data processing system, in particular starting programs on the basis of system changes.
  • time-dependent monitoring and work processes that automatically process, e.g. perform a data backup at night.
  • Examples of this are the component 'cron', e.g. in the X / OPEN Portability Guide, Vol.l, Amsterdam 1987, ISBN 0-444- 70174-5.
  • a time can be specified here at which a command is to be started.
  • a query is usually activated by the time control, which in turn then analyzes whether the events have occurred. Since this process and the queries are relatively complex, an interval which is longer in relation to the temporal resolution of the cron timer, usually one second, is used. All the more so since the known 'cron' component only allows the enumeration of times. However, this is not a quick reaction to changes in the system.
  • the object of the invention is therefore to provide a method in which a specific one is also carried out at short time intervals Change in the overall system leads to a process that reacts to it.
  • a background process similar to the 'cron' process is provided, which, however, is now not or not primarily time-controlled, but rather monitors a list of names for resources.
  • these are preferably registry entries, the actual values of which are either read out and stored at the start or taken from a file or a section of the registry reserved for this purpose at the start.
  • a file is used according to the usual procedure.
  • the invention uses a process that is started when the system is started and is only ended when the system is switched off.
  • the setup and handling of such processes also referred to as 'daemon', is to be carried out specifically for the operating system, but is otherwise generally known (e.g. /etc/init.d in POSIX, AUTOEXEC.BAT in DOS, autostart program group in Windows).
  • This process uses a number of parameters that are stored in one or more files (POSIX) or in the registry (Windows), which is read in at the start of the process.
  • One of these parameters defines the cycle time with which the subsequent steps for the other parameters are carried out.
  • the first column shows the type of query, which can preferably be abbreviated by the first letter.
  • the resource is identified in the second column, the syntax of the description depending on the type of query.
  • the third column shows the process to be started; this specification corresponds to the usual in the respective operating system and can contain parameters.
  • the fourth column notes whether or which process has already started or when and how the previous process was ended. This column is important if the type contains an absolute query, for example for the existence of an entry in the registry. This entry is deleted by the called process. Until the end of the process, another be started, which can be achieved by an entry in this fourth column.
  • a comparison value is noted in the fifth column.
  • the current time is compared with the one given in the second column and the process is started in the third if they are identical. Further details can be found in the well-known 'cron' process in POSIX.
  • the existence of a file with a name given in the second column is checked and the process specified in the third column is executed if it exists.
  • the process number of a started process is noted in the fourth column; its use is described below.
  • a file attribute of the file specified in the second column is determined.
  • the triggering attribute here a read-only attribute ('read only', RO), is specified in the fifth column; if this attribute is set, the process is carried out in the third column.
  • an entry is searched for in a system database, which is specified in the second column.
  • a system database is provided in the Windows95 and WindowsNT operating systems.
  • the entry in the second column is only abbreviated because it is quite long. If the entry exists, the process is started in the third column. Here too, measures against a double start may be necessary, as described below.
  • the date of the last modification of a file is determined and with the date in the fifth Column compared. If there is a change, the new date is entered in the fifth column and the process specified in the third column is started.
  • the started process should delete the value in order not to be reactivated immediately. If the file is found during the existence check, the flag for starting the process is set to active. If it is determined in the next interval that the file no longer exists, the flag is automatically reset. The started process therefore does not require a function to reset the flag. Nevertheless, if the process is started asynchronously and not waited for completion as a dynamic subroutine, an entry such as the process number must be provided in the fourth column. If the condition according to the first two columns applies, a check is carried out to determine whether the process noted in the fourth column is still active. If so, nothing is done. If no, the process is started again and its process number is entered. This assumes that the normal termination of a started asynchronous process is reported and used to close the entry in the fourth column Clear. Alternatively, the process number can be deleted instead of a restart if the process can no longer be found.
  • the time interval for monitoring e.g. five seconds can be specified in the first line or as a parameter when starting the process.
  • the 'registry' is preferably also used for the parameters, which are always backed up by the operating system and kept up-to-date over system breaks. Changes can be made via the registry editor if the background process systematically writes changed values to the registry and monitors them regularly for changes.
  • a development of the invention addresses the problem that the query of the status of an item of equipment depends on means of moving very quickly and efficiently or very slowly. A quick query could be much more common than a slow one.
  • a first measure for this is to specify the query interval globally only as a standard value and to optionally provide an entry for the desired sampling interval for each entry in the list of the equipment to be monitored.
  • An improvement is achieved if the time for the determination of the equipment is determined each time and instead of a fixed interval, e.g. in seconds, a factor versus execution time is given. For example, if it is ten thousand and the execution time of a query is thirty milliseconds, the interval is set to three hundred seconds or five minutes. If the execution time increases due to the increased load on the system, the polling interval also increases, so that the system load is not increased by the polls.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Debugging And Monitoring (AREA)
  • Control By Computers (AREA)

Abstract

Verfahren zum Betrieb einer Datenverarbeitungsanlage mit einem Betriebssystem für mehrere Prozesse, in der ein Hintergrundprozeß zyklisch eine Kollektion von Parametern bearbeitet und nach darin enthaltenen Bedingungen in den Parametern angegebene Prozesse aktiviert, wobei in den Bedingungen Verweise auf Eigenschaften von Betriebsmitteln angebbar sind.

Description

Verfahren zur Ereignis- und Zeitsteuerung
Technisches Hebi et
Die Erfindung betrifft ein Betriebsverfahren für eine Datenverarbeitungsanlage, insbesondere Starten von Program- men auf Grund von Systemänderungen.
Stand der Techni
Für Datenverarbeitungsanlagen mit Betriebssystemen, die mehrere Prozesse parallel abarbeiten können, ist es bekannt, zeitabhängig Überwachungs- und Arbeitsprozesse zu starten, die eine automatischen Verarbeitung, z.B. eine Datensicherung des Nachts, durchführen. Beispiele hierzu sind die Komponente 'cron', wie sie z.B. in dem X/OPEN Portability Guide, Vol.l, Amsterdam 1987, ISBN 0-444- 70174-5, beschrieben ist. Hierbei kann ein Zeitpunkt an- gegeben werden, zu dem ein Kommando gestartet werden soll.
Es ist jedoch wünschenswert, auch auf Veränderungen im System reagieren zu können. Hierzu wird üblicherweise eine Abfrage durch die Zeitsteuerung aktiviert, die dann ihrerseits analysiert, ob die Ereignisse eingetreten sind. Da dieser Prozeß und die Abfragen relativ aufwendig sind, wird ein im Verhältnis zu der zeitlichen Auflösung des cron-Zeitgebers, meist einer Sekunde, längeres Intervall verwendet. Dies umso mehr, als die bekannte 'cron'- Komponente lediglich die Aufzählung von Zeitpunkten zuläßt. Damit ist jedoch keine schnelle Reaktion auf Veränderungen im System möglich.
Aufgabe der Erfindung ist es daher, ein Verfahren anzugeben, bei dem auch in kurzen Zeitabständen eine bestimmte Änderung im Gesamtsystem zu einem darauf reagierenden Prozeß führt .
Hars fil lung der Erfindung
Die Lösung dieser Aufgabe basiert auf der Erkenntnis, daß es nicht notwendig ist, die Inhalte von Dateien zu vergleichen, um Veränderungen zu erkennen. Vielmehr sind die schnell und leicht abfragbaren Dateiattribute wie Datum der letzten Änderung oder die Einträge in einer Konfigu- rations- und Systemparameter-Datenbank wie der indows- Registry ausreichend, um eine Ereignissteuerung vorzusehen. Diese kann gegebenfalls dahingehend verwendet werden, daß die Änderung zwar einen Prozeß auslöst, dieser jedoch dann eine genauere Anlyse vorschaltet, ob ein Ereignis tatsächlich vorliegt.
Dazu wird ein Hintergrundprozeß ähnlich dem ' cron ' -Prozeß vorgesehen, der jedoch nunmehr nicht oder nicht primär zeitgesteuert ist, sondern eine Liste von Namen für Betriebsmittel überwacht . Dieses sind in einem der von der Firma Microsoft gelieferten 'Windows ' -Betriebssysteme be- vorzugt Registry-Einträge, deren Istwerte entweder bei Start ausgelesen und gespeichert oder beim Start aus einer Datei oder einem hierfür reservierten Abschnitt der Registry entnommen sind. In einem der vielen Varianten eines Betriebssystems nach dem POSIX-Standard wird nach dem dort üblichen Verfahren eine Datei verwendet.
Es handelt sich also um ein Verfahren zum Betrieb einer Datenverarbeitungsanlage mit einem Betriebssystem für mehrere Prozesse, in der ein Hintergrundprozeß zyklisch eine Kollektion von Parametern bearbeitet und nach darin enthaltenen Bedingungen in den Parametern angegebene Prozesse aktiviert, wobei in den Bedingungen Verweise auf Eigenschaften von Betriebsmitteln angebbar sind. Weitere Merkmale und Vorteile der Erfindung ergeben sich aus den Ansprüchen und der folgenden Beschreibung, welche in Verbindung mit den beigefügten Zeichnungen die Erfindung an Hand eines Ausführungsbeispiels erläutert.
Beschreibung einer Aυsführπngsfnrm der Erfindung
Die Erfindung benutzt einen Prozeß, der bei Systemstart gestartet wird und erst bei Abschalten des Systems wieder beendet wird. Die Einrichtung und Handhabung von solche, auch als 'daemon' bezeichneten Prozessen ist zwar be- triebssystemspezifisch durchzuführen, jedoch ansonsten allgemein bekannt (z.B. /etc/init.d in POSIX, AUTOEXEC.BAT in DOS, Autostart-Programmgruppe in Windows) .
Dieser Prozeß benutzt eine Reihe von Parametern, die in einer oder mehreren Dateien (POSIX) oder in der Registry (Windows) gespeichert sind, die bei Prozeßbeginn eingelesen wird.
Einer dieser Parameter legt beispielsweise die Zykluszeit fest, mit der die nachfolgenden Schritte für die weiteren Parameter durchgeführt werden.
Weiter Parameter werden beispielsweise durch eine Tabelle folgender Form festgelegt :
Die Einträge in den Spalten sind aus Gründen der Übersichtlichkeit vereinfacht und überwiegen in Anlehung an POSIX dargestellt. Eine Übertragung auf das jeweilige konkrete Betriebssystem und die konkrete Anwendung sollte dem Fachmann nicht schwerfallen.
In der ersten Spalte ist der Typ der Abfrage angegeben, der vorzugsweise durch den ersten Buchstaben abgekürzt werden kann.
In der zweiten Spalte ist das Betriebsmittel bezeichet, wobei die Syntax der Bezeichnung von dem Typ der Abfrage abhängt .
In der dritten Spalte ist der Prozeß benannt, der gestartet werden soll; diese Angabe entspricht dem in dem jeweiligen Betriebssystem üblichen und kann Parameter ent- halten.
In der vierten Spalte wird vermerkt, ob bzw. welcher Pro- zess bereits gestartet wurde oder wann und wie der vorherige Prozess beendet wurde. Diese Spalte ist von Bedeutung, wenn der Typ eine absolute Abfrage, z.B. auf die Existenz eines Eintrags in der Registry, enthält. Dieser Eintrag wird durch den aufgerufenen Prozeß gelöscht . Bis zur Beendigung des Prozesses darf daher nicht ein weite- rer gestartet werden, was durch einen Eintrag in dieser vierten Spalte erreicht werden kann.
In der fünften Spalte wird ein Vergleichswert notiert.
Ist der Typ 'Time' vorhanden, so wird die aktuelle Uhr- zeit mit der in der zweiten Spalte gegebenen verglichen und bei Gleichheit der Prozeß in der dritten gestartet . Weitere Details hierzu können aus dem bekannten 'cron'- Prozeß in POSIX entnommen werden.
Für den Typ 'File' wird die Existenz einer Datei mit ei- nem in der zweiten Spalte gegebenen Namen geprüft und bei Existenz der in der dritten Spalten angegebene Prozeß ausgeführt . In dem obigen Beispiel ist in der vierten Spalte die Prozessnummer eines gestartetn Prozesse notiert; dessen Verwendung wird weiter unten beschrieben.
Für den Typ Αttr' wird ein Dateiattribut der in der zweiten Spalte angegebene Datei bestimmt . In der fünften Spalte wird das auslösende Attribut, hier ein Nur-Lese- Attribut ( ' read only' , RO) , angegeben; wenn dieses Attribut gesetzt ist, dann wird der Prozeß in der dritten Spalte ausgeführt.
Für den Typ 'Status' wird ein Eintrag in einer Systemdatenbank gesucht, der in der zweiten Spalte angegeben wird. Eine solche Systemdatenbank ist in den Betriebssystemen Windows95 und WindowsNT vorgesehen. Der Eintrag in der zweiten Spalte ist, da recht lang, nur abgekürzt dargestellt. Ist der Eintrag vorhanden, wird der Prozeß in der dritten Spalte gestartet. Auch hier sind gegebenenfalls Maßnahmen gegen Doppelstart notwendig, wie sie weiter unten beschrieben werden.
Für den Type 'Date' wird das Datum der letzten Änderung einer Datei ermittelt und mit dem Datum in der fünften Spalte verglichen. Ergibt sich eine Änderung, wird das neue Datum in der fünften Spalte eingetragen und der in der dritten Spalte angegebene Prozeß gestartet .
Entsprechend den Möglichkeiten des verwendeten Betriebs- Systems können weitere, in der ersten Spalte anzugebende, Type bestimmt werden. Insbesondere können von vielen Typen drei Varianten vorhanden sein; eine, die auf die Existenz, eine zweite, die auf einen bestimmten Wert und eine dritte, die auf eine Veränderung gerichtet ist. Letz- tere hat den Vorteil, daß keine Maßnahmen gegen Mehrfachstart des Prozesses benötigt wird. Mit jedem Zyklus wird der Istwert mit dem (in der fünften Spalte gespeicherten) vorherigen Wert verglichen und bei Unterschied der Prozeß gestartet. Zuvor wird der Istwert in der fünften Spalte eingetragen, so daß im nächsten Zyklus kein Start erfolgt .
Wird auf Existenz abgefragt, so sollte der gestartete Prozeß den Wert löschen, um nicht sogleich wieder aktiviert zu werden. Wird bei der Existenzprüfung die Datei gefunden, ist der Merker zum Starten des Prozesses auf aktiv gesetzt. Wird im nächsten Intervall festgestellt, daß die Datei nicht mehr existiert, wird automatisch der Merker wieder zurückgesetzt. Der gestartete Prozeß benötigt demnach keine Funktion, um den Merker zurückzuset- zen. Dennoch muß, wenn der Prozeß asynchron gestartet wird und nicht als dynamisches Unterprogramm auf die Beendigung gewartet wird, ein Eintrag wie die Prozeßnummer in der vierten Spalte vorgesehen werden. Trifft die Bedingung gemäß den ersten beiden Spalten zu, wird geprüft, ob der in der vierten Spalte notierte Prozeß noch aktiv ist. Wenn ja, wird nichts unternommen. Wenn nein, wird erneut der Prozeß gestartet und dessen Prozessnummer eingetragen. Dies setzt voraus, daß die normale Beendigung eines gestarteten asynchronen Prozesses gemeldet wird und dazu benutzt wird, den Eintrag in der vierten Spalte zu löschen. Alternativ kann anstelle eines Neustarts auch die Prozessnummer gelöscht werden, wenn der Prozeß nicht mehr auffindbar ist .
Normalerweise werden lediglich die ersten drei Spalten als Parameterdatei gespeichert. Das Zeitintervall zur Überwachung von z.B. fünf Sekunden kann in der ersten Zeile oder als Parameter beim Start des Prozesses mit angegeben werden.
Eine Weiterbildung überschreibt bei Prozeßende, ggf. auch regelmäßig bei jeder Veränderung, den aktuellen Stand einschließlich der beiden letzten Spalten, die Parameterdatei. Damit sind dann Status und Vergleichswert auch über eine Betriebspause hinaus bestimmt. Bei der in einem POSIX-System üblichen Speicherung in einem Textformat kann dann auch der Vergleichswert bei der Notwendigkeit einer Fehlerkorrektur, Wartung oder ähnlich von einem Systemverwalter überschrieben oder korrigiert werden.
In einem der Microsoft-Windows-Betriebssysteme wird bevorzugt die 'registry' auch für die Parameter verwendet, die ohnehin vom Betriebssystem stets gesichert und über Systempausen hinweg aktuell gehalten wird. Änderungen sind dann über den Registrierungs-Editor möglich, wenn der Hintergrundprozeß geänderte Werte systematisch in die Registry schreibt und diese regelmäßig auf Veränderung überwacht .
Insofern ist es nützlich, als implizite Regel stets aufzunehmen, daß eine Veränderung der Parameterdatei oder der Parameter zu einem erneuten Einlesen der Parameter führt . Die dafür notwendigen Mittel sind bereits in dem Programm für den Hintergrundprozess für die Zeilen der Paramterdatei enthalten.
Eine Fortbildung der Erfindung behandelt das Problem, daß die Abfrage des Status eines Betriebsmittels je nach Be- triebsmittel sehr schnell und effizient oder recht langsam erfolgt . Eine schnelle Abfrage könnte sehr viel häufiger erfolgen als eine langsame.
Eine erste Maßnahme hierzu ist es, das Abfrageintervall global nur als Standardwert vorzugeben und bei jedem Eintrag der Liste der zu überwachenden Betriebsmittel optional noch eine Angabe für das gewünschte Abtastintervall angebbar machen. Eine Verbesserung wird erreicht, wenn jedesmal die Zeit für die Bestimmung des Betriebsmittels ermittelt und anstelle eines festen Intervalls, z.B. in Sekunden, ein Faktor gegenüber der Ausführungszeit angegeben wird. Beträgt dieser beispielsweise zehntausend und die Ausführungszeit einer Abfrage dreißig Millisekunden, dann wird das Intervall auf dreihundert Sekunden oder fünf Minuten gesetzt. Sofern durch erhöhte Belastung des Systems die Ausführungszeit steigt, wird auch das Abfrageintervall größer, um die Systemlast nicht auch noch durch die Abfragen zu erhöhen.

Claims

Patentansprüche
1. Verfahren zum Betrieb einer Datenverarbeitungsanlage mit einem Betriebssystem für mehrere Prozesse, in der ein Hintergrundprozeß zyklisch eine Kollektion von Parametern bearbeitet und nach darin enthaltenen Bedingungen, welche insbesondere Zeitpunkte umfassen, in den Parametern angegebene Prozesse aktiviert, d a du r c h g e k e nn z e i c hn e t , daß in den Bedingungen Verweise auf Eigenschaften von Betriebsmitteln angebbar sind.
2. Verfahren nach Anspruch 1, wobei in den Bedingungen die Existenz einer Eigenschaft eines Betriebsmittels angebbar ist .
3. Verfahren nach Anspruch 2, wobei als Existenz einer Eigenschaft eines Betriebsmittels die Existenz einer
Datei angebbar ist .
4. Verfahren nach Anspruch 2, wobei als Existenz einer Eigenschaft eines Betriebsmittels die Existenz eines Eintrags in einem systemweiten Parameterverzeichnis ('registry') verwendbar ist.
5. Verfahren nach Anspruch 2, wobei als Existenz einer Eigenschaft eines Betriebsmittels die Zugänglichkeit einer Netzwerkadresse (URL) verwendet wird.
6. Verfahren nach Anspruch 1, wobei in den Bedingungen die Änderung einer Eigenschaft eines Betriebsmittels angebbar ist .
7. Verfahren nach Anspruch 6, wobei als Eigenschaft, deren Änderung angebbar ist, eine im Dateisystem verzeichneter Zeitpunkt eines letztmaligen Zugriffs an- gebbar ist.
8. Verfahren nach Anspruch 6, wobei als Eigenschaft, deren Änderung angebbar ist, ein Eintrag in einem sy- stemweiten Parameterverzeichnis ('registry') verwendbar ist.
9. Verfahren nach Anspruch 6, wobei als Eigenschaft, deren Änderung angebbar ist, verwendet wird, daß durch ein Protokoll (HTTP) eine Veränderung, insbesondere eines durch eine Netzwerkadresse (URL) bestimmten Betriebsmittels, ermittelbar ist.
10. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Zeit, die bei einer Abfrage zur Ermittlung einer Eigenschaft eines Betriebsmittels benötigt wird, jeweils ermittelt wird und daraus, vorzugsweise durch einen vorgegebenen Faktor, die Zeit bis zur nächsten Abfrage bestimmt wird.
EP98942463A 1997-08-29 1998-06-30 Verfahren zur ereignis- und zeitsteuerung Withdrawn EP1010073A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE19737812 1997-08-29
DE19737812 1997-08-29
PCT/DE1998/001801 WO1999012096A1 (de) 1997-08-29 1998-06-30 Verfahren zur ereignis- und zeitsteuerung

Publications (1)

Publication Number Publication Date
EP1010073A1 true EP1010073A1 (de) 2000-06-21

Family

ID=7840637

Family Applications (1)

Application Number Title Priority Date Filing Date
EP98942463A Withdrawn EP1010073A1 (de) 1997-08-29 1998-06-30 Verfahren zur ereignis- und zeitsteuerung

Country Status (5)

Country Link
EP (1) EP1010073A1 (de)
JP (1) JP2001515241A (de)
CN (1) CN1269029A (de)
BR (1) BR9812015A (de)
WO (1) WO1999012096A1 (de)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0454607A3 (en) * 1990-04-24 1993-01-27 International Business Machines Corporation Method for automated event activation of data processing procedures
US5625821A (en) * 1991-08-12 1997-04-29 International Business Machines Corporation Asynchronous or synchronous operation of event signaller by event management services in a computer system
US5321837A (en) * 1991-10-11 1994-06-14 International Business Machines Corporation Event handling mechanism having a process and an action association process

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9912096A1 *

Also Published As

Publication number Publication date
WO1999012096A1 (de) 1999-03-11
JP2001515241A (ja) 2001-09-18
CN1269029A (zh) 2000-10-04
BR9812015A (pt) 2000-09-26

Similar Documents

Publication Publication Date Title
DE69031538T2 (de) System und Verfahren zur Sammlung von Softwareanwendungsereignissen
DE69317982T2 (de) Verfahren und Anlage zur Realzeitdatensammlung und Anzeigevorrichtung
DE3786956T2 (de) Verwaltung von registrierungsdaten in einem transaktionsorientierten System.
DE69119222T2 (de) Datensicherung und Beseitigung in einem Datenverarbeitungssystem
DE69703181T2 (de) Registrierdateioptimierung in einem Client/Server-Rechnersystem
DE68927705T2 (de) Verfahren zum Entfernen unbestätigter Änderungen an gespeicherten Daten durch ein Datenbankverwaltungssystem
DE102005008520B4 (de) Verfahren, Computerprogramm-Produkt und Drucksystem zum Sortieren von Druckjobs in eienm solchen Drucksystem
WO2000003323A2 (de) System und verfahren zum prüfen von netzwerk-anwendungen
EP1430369B1 (de) Dynamischer zugriff auf automatisierungsressourcen
EP1731999B1 (de) Mechanismus zum dynamischen Registrieren von Dateien in einer stapelverarbeitungsorientierten Umgebung
WO1996038785A1 (de) Aktualisierungsmechanismus für benützerprogramme in einem rechnernetz
WO1999017192A1 (de) Konfigurierungsverfahren für datenverarbeitungsanlagen
EP1010073A1 (de) Verfahren zur ereignis- und zeitsteuerung
DE102005008519B4 (de) Verfahren zum Überwachen eines Verzeichnisses in einem Drucksystem, Computerprogramm-Produkt und Drucksystem zum Ausführen dieses Verfahrens
WO2010034548A1 (de) Testmodul und verfahren zum testen einer o/r-abbildungs-middleware
DE112016006217T5 (de) Programmierbare Anzeigevorrichtung
EP3872661A1 (de) Analyse einer container-instanz eines betriebssystems
EP1179428B1 (de) Verfahren und Vorrichtung zum Abarbeiten von Verfahrensschritten
DE102017005944B4 (de) Vorrichtung und Verfahren zur gerätetechnischen Erkennung von Verletzungen von zyklischen Echtzeitbedingungen in Datenverarbeitungseinheiten und -systemen
DE10108564A1 (de) Verfahren zur Suche nach in einem verteilten System aktuell oder früher gespeicherten Daten oder Daten enthaltenden Ressourcen unter Berücksichtigung des Zeitpunkts ihrer Verfügbarkeit
DE102004021031A1 (de) Verfahren zum Generieren und Verwalten von Vorlagen für das Event Management
EP1461701B1 (de) Programmgesteuerte einheit mit überwachungseinrichtung
DE10203409B4 (de) Computersystem mit einem Anwendungsserver, einer Gerätesteuerung mit angeschlossenen Peripheriegeräten und einem Verzeichnisserver
WO2024175581A1 (de) Verfahren und vorrichtung zur visualisierung von debug-daten eines komplexen datenverarbeitungsnetzwerks
WO2002003193A2 (de) Elektronisches system zur entwicklung von software und ein verfahren zum zugriff auf interne daten der software

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20000125

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT CH DE ES FR GB LI NL SE

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: WINCOR NIXDORF GMBH & CO KG

GRAG Despatch of communication of intention to grant

Free format text: ORIGINAL CODE: EPIDOS AGRA

GRAG Despatch of communication of intention to grant

Free format text: ORIGINAL CODE: EPIDOS AGRA

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

17Q First examination report despatched

Effective date: 20001023

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Withdrawal date: 20010406