JP3741371B2 - Event control apparatus and event control method - Google Patents

Event control apparatus and event control method Download PDF

Info

Publication number
JP3741371B2
JP3741371B2 JP2002340185A JP2002340185A JP3741371B2 JP 3741371 B2 JP3741371 B2 JP 3741371B2 JP 2002340185 A JP2002340185 A JP 2002340185A JP 2002340185 A JP2002340185 A JP 2002340185A JP 3741371 B2 JP3741371 B2 JP 3741371B2
Authority
JP
Japan
Prior art keywords
event
client
server
condition
predetermined
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.)
Expired - Fee Related
Application number
JP2002340185A
Other languages
Japanese (ja)
Other versions
JP2003228489A (en
Inventor
健一 副島
太郎 井上
仁 上野
雅章 大矢
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.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
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 Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2002340185A priority Critical patent/JP3741371B2/en
Publication of JP2003228489A publication Critical patent/JP2003228489A/en
Application granted granted Critical
Publication of JP3741371B2 publication Critical patent/JP3741371B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Debugging And Monitoring (AREA)
  • Computer And Data Communications (AREA)

Description

【0001】
【産業上の利用分野】
本発明は、一般にコンピュータシステムに関し、詳細には計算機システム内で発生するイベントの制御に関する。
【0002】
【従来の技術】
計算機システム内では、プロセスが起動したりエラーが発生したりするなど、さまざまな事象が頻繁に発生している。そして、これらの事象には、事象の発生に応じて処理を行う必要があるものがある。例えば、ウィンドウシステムでは、キーが押されたというイベントが発生すると、それに対応するアクションを実行したり、文字を表示したりする、などである。
【0003】
このように、計算機システム内で発生した事象をイベントとしてとらえ、イベントが発生すると、それに対して何らかの処理を行うシステムの例として、X-Window System("X Window System, Version 11 Release 4 Release Notes",Jim Fulton, XConsortium, M.I.T. Laboratory for Computer Science)に代表されるウィンドウシステムなどがある。このウィンドウシステムでは、キーが押されたら文字を表示する、マウスボタンがクリックされたらメニューを表示する、などの様々なイベントに対する処理が定義されている。
【0004】
これらのイベントを取り扱うシステムの中には、発生したイベントを保存しておき再生するという機能をもつものがある。例えば、保存するイベントをキー入力だけに限定すれば、多くのエディタで実現されているキーボードマクロ(「GNU Emacs マニュアル」 28.3 キーボードマクロ、 Richard Stallman 著、竹内郁雄・天海良治 監訳、共立出版) もこの一種であると見ることができる。また、ウィンドウシステムにおいては、一連のイベントを保存しておき、まとめて再生して自動操作をさせることで、自動デモを行うことが可能なものもある。
【0005】
しかしながら、前記システムでは、多くの場合、イベントの保存や再生を行うフェーズはそれぞれ独立しており、保存するときは保存終了までずっと保存する、再生するときはまとめて再生する、というようになっている。また、保存するイベントも、全てのイベントを保存するか、ユーザが指定したイベントを保存する、というようになっている。さらに、保存したイベントを修正したり新規に作成したりする方法(特開平6-203030号「デモンストレーション機能付きエディタ」)も提案されているが、結局は、個々のイベントの修正や新規作成はユーザが行わなければならない。
【0006】
【発明が解決しようとする課題】
ところで、このような従来のイベントを取り扱うシステムでは、イベントのやり取りの不整合のために下記のような問題が発生する。
【0007】
例えば、従来のイベントを取り扱うシステムでは、あるイベントが発生しても、そのイベントの発生以降に当該イベントの発生を待つ状態になったアプリケーションは、当該イベントが過去に発生していることを知ることができないという問題があった。
【0008】
また、クライアントサーバシステムでは、クライアントを先に起動し、次にサーバを起動すると、サーバからサーバ起動イベントがクライアントに送られ、これによりクライアントはサーバが起動されたことを知ってそのサーバが提供するサービスの利用を開始するようになっているものがある。この場合、クライアントの起動がサーバの起動の後になると、クライアントはサーバ起動イベントを受け取ることができないためサーバが起動していることを知ることができず、システムがうまく働かないという問題があった。
【0009】
さらに、イベントは発生した時点で1回だけ伝わるため、ユーザが指定したりアプリケーションのイベント発生部分で対処しない限り、受けとったイベントを繰り返し自動的に発生させたり、あるいは一定時間を置いて自動的に発生させたりすることはできない。しかし、前記処理を行うためにユーザが指定したりアプリケーションのイベント発生部で対処したりすると、ユーザもしくはアプリケーションに負担をかけるという問題があった。
【0010】
また、上述のキーボードマクロのような発生したイベントを保存しておき再生する機能を用いても、自動操作や自動デモができる程度であり、イベントの発生順序や発生件数の自動的な制御などイベントに係る種々の制御を実現することはできない。さらに、イベントを保存する場合、発生するイベント全てを保存すると資源を大量に消費するという問題があり、ユーザが指定するようにするとユーザの手間が増え指定漏れのある可能性が出てくるという問題があった。
【0011】
本発明の目的は、計算機システム内で発生するイベントの発生順序や発生件数などを自動的に制御するイベント制御方法およびイベント制御装置を提供することにある。
【0012】
【課題を解決するための手段】
上記目的を達成するため、本発明は、計算機内で発生したイベントを取り扱うイベント制御装置であって、前記計算機内で発生したイベントを検出するイベント検出手段と、所定のイベント保存条件に従って、前記イベントのデータを保存するイベント管理手段と、所定のイベント擬似発生条件に従って、前記イベントのデータに基づくイベントを擬似発生させるイベント擬似発生手段とを備え、前記イベント保存条件として、所定の種類のイベントのみ保存させること、所定の数のイベントを保存させること、前記イベント擬似発生手段により所定の回数発生したイベントを保存させないこと、前記イベント擬似発生手段により発生した後一定時間を過ぎたイベントを保存させないことのうちの少なくともいずれか1つを条件とすることを特徴とする。
【0013】
また、本発明は、起動時にサーバ起動イベントを発生しクライアントに対しサービスを提供するサーバと、起動時にクライアント起動イベントを発生するとともに前記サーバ起動イベントを受けたとき前記サーバのサービスを利用開始するクライアントとを備えたクライアントサーバシステムにおけるイベント制御装置であって、前記サーバが起動したときに発生される前記サーバ起動イベントを検出するサーバ起動イベント検出手段と、前記サーバ起動イベント検出手段で検出したサーバ起動イベントを保存するサーバ起動イベント保存手段と、前記クライアントが起動したときに発生される前記クライアント起動イベントを検出するクライアント起動イベント検出手段と、前記クライアント起動イベント検出手段でクライアント起動イベントを検出したのを契機に、前記保存しておいたサーバ起動イベントを擬似発生して前記クライアントに送るサーバ起動イベント擬似発生手段とを備えたことを特徴とする。
【0014】
さらに、本発明は、計算機内で発生したイベントを取り扱うイベント制御方法であって、前記計算機内で発生したイベントを検出するイベント検出ステップと、所定のイベント保存条件に従って、前記イベントのデータを保存するイベント管理ステップと、所定のイベント擬似発生条件に従って、前記イベントのデータに基づくイベントを擬似発生させるイベント擬似発生ステップとを備え、前記イベント保存条件として、所定の種類のイベントのみ保存させること、所定の数のイベントを保存させること、前記イベント擬似発生ステップにより所定の回数発生したイベントを保存させないこと、前記イベント擬似発生ステップにより発生した後一定時間を過ぎたイベントを保存させないことのうちの少なくともいずれか1つを条件とすることを特徴とする。
【0015】
また、本発明は、起動時にサーバ起動イベントを発生しクライアントに対しサービスを提供するサーバと、起動時にクライアント起動イベントを発生するとともに前記サーバ起動イベントを受けたとき前記サーバのサービスを利用開始するクライアントとを備えたクライアントサーバシステムにおけるイベント制御方法であって、前記サーバが起動したときに発生される前記サーバ起動イベントを検出するサーバ起動イベント検出ステップと、前記サーバ起動イベント検出ステップで検出したサーバ起動イベントを保存するサーバ起動イベント保存ステップと、前記クライアントが起動したときに発生される前記クライアント起動イベントを検出するクライアント起動イベント検出ステップと、前記クライアント起動イベント検出ステップでクライアント起動イベントを検出したのを契機に、前記保存しておいたサーバ起動イベントを擬似発生して前記クライアントに送るサーバ起動イベント擬似発生ステップとを備えたことを特徴とする。
【0016】
【作用】
本発明によれば、イベント検出手段により、計算機内で発生したイベントを検出する。検出したとき、所定のイベント保存条件に従って、前記イベントのデータを保存する。また、所定のイベント擬似発生条件に従って、前記イベントのデータに基づくイベントを擬似発生させる。
【0017】
また、クライアントがサーバの起動イベントを受け取って処理を開始するクライアントサーバシステムでは、サーバがクライアントよりも先に起動したとき、前記サーバ起動時に発生したサーバ起動イベントをサーバ起動イベント検出手段で検出して、サーバ起動イベント保存手段でそれを保存する。そして、前記クライアント起動時に発生するクライアント起動イベントをクライアント起動イベント検出手段で受けとると、サーバ起動イベント擬似発生手段で前記保存しておいたサーバ起動イベントを擬似発生させることで、クライアントがサーバ起動イベントを受けとりそこなうことのないようにする。
【0018】
【実施例】
以下、図面を用いて、本発明の実施例を説明する。
【0019】
図1は、本発明を適用した計算機システムのシステム構成の例を示したものである。図1を参照して、本実施例の計算機システムの構成および動作の概要を説明する。
【0020】
計算機1000は、通信回線1010に接続されている。また、計算機1000上では、自計算機上や他計算機上のプロセスとのイベントによる情報交換を行うためのイベントサービス1104が提供されている。すなわち、計算機1000に入力するイベントは、自計算機内で発生したものか他計算機で発生したものかを問わず、イベントサービス1104を介して入力する。他計算機で発生したイベントは、通信回線1010を介してイベントサービス1104に入力する。自計算機で発生し他計算機に送るべきイベントは、イベントサービス1104を介して通信回線1010に送出される。なお、図1では計算機1000のみ図示しているが、通信回線1010には他の計算機(例えば、サーバとなる計算機やクライアントとなる計算機)が接続されているものとする。
【0021】
計算機1000上では前記イベントサービス1104を利用した(1430)自動運転システム1100が動作している。自動運転システム1100は、自動運転の運用ルールを記述した運用ルール定義ファイル1500を保持している。運用ルールとは、発生したイベントに対応してどのような処理を行なうかを記述したものである。この運用ルールには、計算機1000の内部で発生したイベントに対応する処理を記述した運用ルールだけではなく、他計算機で発生したイベントに対応する処理を記述した運用ルールも含まれる。運用ルールの具体例については、図12を参照して後述する。通信回線1010に接続された不図示の他計算機においても、それぞれ、イベントサービスを利用した自動運転システムが動作しているものとする。
【0022】
また、計算機1000は、ユーザが定義した擬似発生条件定義ファイル1502およびクライアント起動時発生イベント一覧ファイル1504を保持する。擬似発生条件定義ファイル1502には、後述するイベント擬似発生条件検出手段1306においてどのような条件が満たされた場合にどのようなイベントを擬似発生させるかを示すイベント擬似発生条件(ユーザが定義したもの)が記述してある。クライアント起動時発生イベント一覧ファイル1504には、本計算機1000および通信回線1010に接続された他の計算機においてクライアントが起動したときに発生するクライアント起動時発生イベントの一覧が記述されている。クライアント起動時発生イベント一覧ファイル1504については、図11を参照して後述する。なお、本実施例では簡単のため、着目すべきクライアントは1台の計算機に対して1つ動作しているものとする。したがって、クライアント起動時発生イベントは、計算機が立ち上がったことを示すイベントでもある。
【0023】
また、計算機1000では、本発明に係るイベント制御装置1202が動作している。イベント制御装置1202は、イベント検出手段1300、イベント保存条件検出手段1302、イベント管理手段1304、イベント擬似発生条件検出手段1306、およびイベント擬似発生手段1308を備えている。また、前記イベント管理手段1304が管理するイベント情報1310がファイルシステム上もしくはメモリ上に存在する。
【0024】
イベントサービス1104は、受けとった各種のイベントをイベント検出手段1300に渡す(1400)。イベント検出手段1300は、イベントサービス1104から受けとったイベントをイベント保存条件検出手段1302に渡す(1412)と同時に、イベント擬似発生条件検出手段1306にも渡す(1422)。
【0025】
イベント保存条件検出手段1302では、あらかじめ運用ルール定義ファイル1500から、どのイベントをイベント管理手段1304に渡してイベント情報1310に保存してもらうかを示す保存条件を読み取り(1402)、保持しておく。そして、イベント保存条件検出手段1302は、その保存条件に基づいて、イベント検出手段1300から受けとった(1412)イベントが保存すべきイベントであるか否かを判断し、保存すべきであれば、イベント管理手段1304に渡して(1414)イベント情報1310に保存してもらう(1432)。なお、ユーザが定義したイベント保存条件定義ファイルにより、どのイベントを保存するかを決定するようにしてもよい。
【0026】
イベント擬似発生条件検出手段1306では、あらかじめ運用ルール定義ファイル1500、ユーザが定義した擬似発生条件定義ファイル1502、およびクライアント起動時発生イベント一覧表1504から、イベントを擬似発生させる条件(イベント擬似発生条件)を求め(1400,1422)、保持しておく。イベント擬似発生条件は、条件部と、当該条件部が成立したときに擬似発生させるイベントを特定する情報とからなる。
【0027】
また、イベント擬似発生条件検出手段1306は、イベント管理手段1304を用いてイベント情報1310を参照しそれが更新されているかどうかを調べ(1416)、更新されている場合は更新分のイベントデータを取得する。そして、イベント検出手段1300から受け取ったイベントおよび更新分のイベントデータを、保持してあるイベント擬似発生条件(の条件部)と照合して、イベントを擬似発生するかどうかを決定する。詳しく言うと、イベント擬似発生条件の条件部が成立し、かつ、その条件部が成立したときに擬似発生すべきイベントがイベント情報1310に保存されているか、を判定する。イベント擬似発生条件の条件部が成立しかつその条件部が成立したときに擬似発生すべきイベントがイベント情報1310に保存されている場合、イベント擬似発生条件が成立しているものとし、当該イベントを擬似発生させる。
【0028】
なお、本実施例では、イベント擬似発生条件の条件部が成立しているか否かの判定は、後述の図5および図9に示すように、イベント検出手段1300から受け取ったイベントおよび更新分のイベントデータをイベント擬似発生条件の条件部と照合することにより行なっている。ただし、イベント擬似発生条件の条件部が、さらに過去に所定のイベントが発生していることを条件の一部に含む場合は、イベント情報1310に保存されている過去に発生しているイベントも参照して、イベント擬似発生条件の条件部が成立しているか否かを判定すればよい。
【0029】
イベントを擬似発生させる場合、イベント擬似発生条件検出手段1306は、イベント管理手段1304に、擬似発生させるイベントに関する情報の取得を依頼する(1416)。イベント管理手段1304は、この依頼に応じてイベント情報1310から必要なイベント情報を取り出し(1432)、イベント擬似発生条件検出手段1306に渡す。イベント擬似発生条件検出手段1306は、そのイベント情報を受け取って(1416)、イベント擬似発生手段1308に渡す(1418)。イベント擬似発生手段1308は、イベント擬似発生手段1306からイベント情報を受け取り、イベントを擬似発生させる(1420)。
【0030】
以上のようにして、所定の保存条件を満たすイベントを保存し、所定のイベント擬似発生条件を満たす場合には保存しておいたイベントを擬似発生させることができる。これにより、イベントの発生順序や発生件数などを自動的に制御することが可能になる。以下、図1の構成における各部の動作をさらに詳細に説明する。
【0031】
図2は、イベント検出手段(図1の1300)の処理の流れを示す。
【0032】
前記イベント検出手段1300では、初期化(2000)の後、イベントが発生したかどうかを調べ(2300)、発生していなければ、イベントが発生するまで待つ。イベントが発生していれば、イベントサービス1104からそのイベントのデータを読みこみ(2002)、イベント保存条件検出手段(図1の1302)にそのイベントを渡す(2004)。さらに、イベント擬似発生条件検出手段(図1の1306)にもそのイベントを渡す(2006)。処理2004で渡されたイベントは、後述の図3の処理3004でイベント保存条件検出手段1302に受け取られる。処理2006で渡されたイベントは、後述の図9の9002でイベント擬似発生条件検出手段1306に受け取られる。
【0033】
図3は、イベント保存条件検出手段(図1の1302)の処理の流れを示す。
【0034】
イベント保存条件検出手段1302では、初期化(3000)の後、自動運転システムの運用ルール(図1の1500)を読み込み(3002)、どのイベントを保存すればよいかを示す保存条件をその運用ルールから抽出する(3600)。イベント保存条件の抽出のアルゴリズムは、図7を参照して後述する。
【0035】
次に、イベント保存条件検出手段1302は、イベント検出手段(図1の1300)からのイベントデータがあるかどうかを調べ(3300)、なければ待つ。イベント検出手段1300からのイベントデータがあれば、そのイベントデータを受け取る(3004)。そして、処理3600で抽出したイベント保存条件に基づいて、受け取ったイベントが保存するイベントであるかどうかを調べ(3302)、保存するイベントであれば、イベント管理手段(図1の1304)に前記イベントのデータを保存する要求を出す(3006)。そして、前記要求の返事がエラーであるかどうかを調べ(3304)、エラーならばエラーログに記録するなどのエラー処理を行う(3008)。
【0036】
図4は、イベント管理手段(図1の1304)の処理の流れを示す。なお実際には、イベント管理手段1304は、後述する図10に示すようなコマンドを受け付け、受け付けたコマンドに応じてイベント情報1310に対する読み出し、イベントデータの保存、与えられた条件の判定、与えられた条件に応じた検索、およびイベントデータの削除などを行なうようになっている。図4では、これらすべてのコマンドに応じた処理は記述しておらず、簡単のため、主要な処理部分のみの概略の手順を図示している。
【0037】
イベント管理手段1304では、まず初期化を行う(4000)。このとき、更新フラグをTRUEに設定する。更新フラグとは、前回イベント擬似発生条件検出手段1306がアクセスしてきてから今までの間に、イベント情報1310が更新されたかどうかを調べるためのフラグである。更新フラグがTRUEのときは、前回イベント擬似発生条件検出手段1306がアクセスしてきてから今までの間にイベント情報1310の更新があったということを示し、FALSEのとき更新はなかったということを示す。
【0038】
初期化(4000)が終了すると、次にイベント擬似発生条件検出手段(図1の1306)からイベント情報1310が更新されたかどうかを調べる要求(後述する図5の処理5002で出される要求)が来ているかどうかを調べ(4300)、来ていれば現在の更新フラグの値をイベント擬似発生条件検出手段1306に返す(4002)。
【0039】
次に、イベント擬似発生条件検出手段1306からイベント情報1310中のイベントデータを削除する要求(後述する図5の処理5008で出される要求)が来ているかどうかを調べ(4308)、来ていれば、その要求に従ってイベントデータを削除する(4020)。そして、そのイベントデータを削除する処理でエラーが発生していたら(4312)、イベント擬似発生条件検出手段1306にエラーを返す(4024)。
【0040】
次に、イベント保存条件検出手段(図1の1302)から保存要求(図3の処理3006で出される要求)が来ているかどうかを調べ(4302)、保存要求が来ていれば、イベント保存条件検出手段1302から保存すべきイベントのデータを受けとり(4004)、そのデータが正しいものかどうかを調べる(4006)。そのイベントデータが正しいものであれば(4304)、そのイベントデータをイベント情報1310に保存して(4010)、更新フラグをTRUEとし(4012)、再び処理4300に戻る。前記データが正しいものでなければ(4304)、イベント保存条件検出手段1302にエラーを返し(4008)、再び処理4300に戻る。
【0041】
処理4302でイベント保存条件検出手段1302からの保存要求が来ていない場合は、イベント擬似発生条件検出手段1306からイベントデータの読みだし要求(後述する図5の処理5004および図9の9004で出される要求)が来ているかどうかを調べ(4306)、来ていれば、イベント情報1310からその読みだし要求に応じたデータを読みだす(4014)。このとき、エラーが発生していれば(4310)、イベント擬似発生条件検出手段1306にエラーを返し(4022)、再び処理4300に戻る。エラーが発生していなければ(4310)、更新フラグをFALSEにして(4018)、前記読み出したデータをイベント擬似発生条件検出手段1306に渡す(4016)。その後、再度イベント情報1310が更新されたかどうかを調べる要求が来ているかどうかを調べる処理4300に戻って、当該処理から繰り返す。
【0042】
図5は、イベント擬似発生条件検出手段(図1の1306)の処理の流れを示す。
【0043】
イベント擬似発生条件検出手段1306では、初期化(5000)の後、前記自動運転システム(図1の1100)の運転ルール(図1の1500)からイベント擬似発生条件を抽出する(5600)。イベント擬似発生条件の抽出のアルゴリズムは、図8を参照して後述する。その後、ユーザが作成した擬似発生条件定義ファイル1502からイベント擬似発生条件を抽出し、処理5600で抽出したイベント擬似発生条件とマージして保持しておく(5008)。
【0044】
次に、イベント情報1310に更新があったかどうかを調べる要求をイベント管理手段1304に出す(5002)。イベント管理手段1304から返された更新フラグがTRUEであったときは、前回の問合せから今までの間にイベント情報1310の更新があったということであるから(5300)、イベント管理手段1304に依頼して、イベント情報1310から更新分のイベントデータを読み出し(5004)、次の処理5602に進む。イベント管理手段1304から返された更新フラグがFALSEであったときは、前回の問合せから今までの間にイベント情報1310の更新がなかったということであるから(5300)、そのまま処理5602に進む。
【0045】
次に、前記読み出したデータ(イベント情報1310の更新分)や現在時刻などから、前記イベント擬似発生条件(処理5600,5608で抽出)のうち何れかのイベント擬似発生条件が成立しているかどうかを調べる(5602)。この処理5602の詳細は、図9を参照して後述する。イベント擬似発生条件のうち成立しているものがあれば(5302)、イベント擬似発生手段(図1の1308)に、成立しているイベント擬似発生条件に応じて擬似発生すべきイベントを擬似発生してもらう要求を出し(5006)、処理5304に進む。成立しているイベント擬似発生条件がないときは、処理5302から処理5002に戻る。
【0046】
処理5006の後、この処理5006で擬似発生させたイベントが不要になったかどうかを判断し(5304)、不要ならばイベント管理手段1304に当該イベントの削除要求を出す(5008)。この削除処理でエラーが発生したら(5306)、エラーログにエラーメッセージを書き出すなどのエラー処理を行う(5010)。処理5304で、擬似発生させたイベントが不要ではないと判別されたときは、そのまま処理5002に戻る。処理5306でエラーが発生していないとき、および処理5010のエラー処理の後、再び処理5002に戻る。
【0047】
図6は、イベント擬似発生手段(図1の1308)の処理の流れを示す。
【0048】
イベント擬似発生手段1308では、初期化(6000)の後、イベント発生条件検出手段1306からのイベント擬似発生要求(図5の処理5006で出された要求)が来たかどうか調べる(6300)。イベント擬似発生要求が来ていれば(6300)、イベント擬似発生条件検出手段1306から受けとったイベント(そのイベントデータは、後述の図9の処理9006で読出してある)を擬似発生し(6002)、再び処理6300に戻る。イベント擬似発生要求が来ていないときは(6300)、そのまま処理6300に戻る。
【0049】
図7は、イベント保存条件抽出アルゴリズムの処理の流れを示す。この図7の処理は、図3の処理3600に相当する。
【0050】
処理を開始すると(7000)、まだ保存条件を抽出していない運用ルールが存在する計算機があるかどうか調べ(7304)、なければ終了する(7006)。まだ保存条件を抽出していない運用ルールが存在する計算機がある場合は(7304)、その中から1台を選択し(7008)、選択した計算機においてまだ保存条件を抽出していない運用ルールがあるかどうか調べる(7300)。その計算機のすべての運用ルールから保存条件を抽出済みのときは、処理7300から処理7304に戻る。
【0051】
選択した計算機においてまだ保存条件を抽出していない運用ルールがある場合は(7300)、その調べていない運用ルールのうちの1つを抽出し、抽出した運用ルールの中から条件部分を抽出する(7002)。そして、抽出した条件部分がイベントIDもしくはイベントメッセージによる条件であるかどうかを調べ(7300)、前記いずれかの条件であれば、その抽出した条件をイベント保存条件に加える(7004)。その後、処理7300に戻る。処理7302で、抽出した条件がイベントIDでなくかつイベントのメッセージによる条件でもないときは、処理7302から処理7300に戻る。
【0052】
図8は、イベント擬似発生条件抽出アルゴリズムの処理の流れを示す。この図8の処理は、図5の5600に相当する。
【0053】
処理開始後(8000)、運用ルールが存在する全ての計算機について、まだイベント擬似発生条件を抽出していない計算機があるかどうか調べ(8300)、なければ処理を終了する(8008)。まだイベント擬似発生条件を抽出していない計算機があれば、その計算機のうち1台を選択し(8002)、選択した計算機の運用ルールからイベント待ちの条件の部分(どのイベントを待っているか)を取り出し(8004)、前記選択した計算機の名前と前記取り出したイベントとの対を記憶しておく(8006)。その後、処理8300に戻る。
【0054】
なお本実施例では、図1でも説明したように、1台の計算機に対して着目すべきクライアントが1つ動作することを前提としているから、「計算機」と「クライアント」は1対1に対応している。そこで、本実施例では、上記処理8006で記憶する「計算機の名前」として、当該計算機のクライアントが起動したときに発生するクライアント起動時発生イベントのイベントIDを用いている。各計算機のクライアントが起動したときに発生するクライアント起動時発生イベントのイベントIDは、クライアント起動時発生イベント一覧表1504を参照して得ている。イベント擬似発生条件の抽出の具体例は、図13を参照して後述する。
【0055】
処理終了時(8008)に記憶している前記計算機の名前(すなわち、クライアント起動時発生イベント)と前記イベント(当該クライアントに関する運用ルールのイベント待ちの条件の部分から取り出したイベント)との対が、求めるイベント擬似発生条件である。詳しく言えば、前半のクライアント起動時発生イベントはイベント擬似発生条件の条件部を示し、後半のイベントは前記条件部が成立したときに擬似発生すべきイベントを示している。
【0056】
いま、前半の条件部をAとし、後半の擬似発生すべきイベントをBとし、A:Bでイベント擬似発生条件を表すものとする。A:Bは、要するに、起動時にAが発生するクライアントaで待っているイベントがBである、ということである。もし、イベントBがクライアントaの起動より前に発生していると、クライアントaではイベントBを受け取ることができずに正常に動作しないことが考えられる。そこで、本実施例では、イベントBが発生したときにそれをイベント情報1310として保存しておき、イベント擬似発生条件にA:Bを登録しておいて、Aが成立したとき(クライアントaが起動したとき)、イベントBが保存されていたなら、そのイベントBを擬似発生させる。これにより、クライアントaは、イベントBを受け取ることができ、以後正常に動作することになる。
【0057】
図9は、イベント擬似発生条件検出アルゴリズムの処理の流れを示す。この図9の処理は、図5の5602に相当する。
【0058】
処理開始後(9000)、イベント検出手段(図1の1300)からのイベントがあるかどうか調べ(9300)、あればイベント検出手段1300からのイベントデータを受け取り(9002)、処理9004に進む。イベント検出手段1300からのイベントデータがなければ、処理9300から処理9004に進む。
【0059】
そして、処理9002で受けとったイベントや図5の処理5004で読出してある更新分のイベントデータをイベント擬似発生条件の条件部のイベントと比較する(9004)。なお、イベント擬似発生条件が時刻に関連する条件を含む場合は、時刻をも考慮して処理9004の比較を行なうものとする。また、本実施例ではイベント検出手段1300からのイベントと更新分のイベントのみをイベント擬似発生条件の条件部と比較しているが、イベント擬似発生条件の条件部がさらに過去に所定のイベントが発生していることを条件の一部に含む場合は、イベント情報1310に保存されている過去に発生しているイベントも参照して、イベント擬似発生条件の条件部が成立しているか否かを判定するようにする。
【0060】
さらに、処理9004では、上記比較の結果、条件部が一致するイベント擬似発生条件を検出した場合には、その条件部に対応して擬似発生すべきイベントが既にイベント情報1310に保存されているかどうかを調べる。
【0061】
処理9004による比較で、処理9002で受けとったイベントや図5の処理5004で読出してある更新分のイベントデータとイベント擬似発生条件の条件部のイベントとの一致が検出され、かつ、当該イベント擬似発生条件で擬似発生すべきイベントが既にイベント情報1310に保存されていたときは(9302)、イベント擬似発生条件成立とする(9006)。そうでないときは(9302)、イベント擬似発生条件不成立である。イベント擬似発生条件成立のときは、当該擬似発生すべきイベントに関するイベントデータをイベント情報1310から読出しておく。
【0062】
次に、前記イベント擬似発生条件検出手段(図1の1306)における、イベント擬似発生条件の条件部の例を挙げる。イベント擬似発生条件の条件部としては、例えば下記▲1▼〜▲7▼などの条件がある。
▲1▼事前に決められた1つ以上のイベントのうち、事前に決められた数以上のイベントが発生した
▲2▼事前に決められた数以上のイベントが、事前に決められた順序で発生した
▲3▼イベントの発生後、事前に決められた一定時間が経過した
▲4▼事前に決められた時間内に発生した
▲5▼事前に決められた時刻になった
▲6▼事前に決められた計算機上で発生した
▲7▼事前に決められた回数だけ発生した
【0063】
イベント擬似発生条件は、イベント擬似発生条件検出手段(図1の1306)により、自動運転システム(図1の1100)の運用ルール(図1の1500)から自動的に抽出される(図5の5600)。この処理については、図8を用いて説明した。また、既に述べたように、ユーザが定義した擬似発生条件定義ファイル(図1の1502)に上記▲1▼〜▲7▼などを含む任意のイベント擬似発生条件を記述することも可能である。
【0064】
次に、前記イベント情報(図1の1310)に登録するイベントデータの内容の例を挙げる。
【0065】
前記登録するイベントデータの内容としては、イベントID(識別子)、イベントメッセージ、イベントのパラメータ、イベントの発生時刻、イベントが発生した計算機、イベントを発生したユーザ名、グループ名、およびプロセス名イベントの発生回数などが挙げられる。なお、これらの項目は必ずしも全てのイベントに対して登録する必要があるというわけではない。
【0066】
図10に、イベント保存条件検出手段(図1の1302)やイベント擬似発生条件検出手段(図1の1306)が、イベント管理手段(図1の1304)に対して送信するコマンドの一覧を示す。
【0067】
Rコマンド、Wコマンド、およびDコマンドは、それぞれイベント管理手段1304に対するイベントデータの読み込み、書き込み、および削除を行うコマンドである。また、Cコマンドは、条件を与えて前記条件が成立しているかどうかを調べるコマンドで、イベント擬似発生条件が成立したかどうかを調べるときなどに使用される。また、Sコマンドは、実際に条件に合うイベントを検索するためのコマンドである。
【0068】
なお、図4の説明でも述べたが、図4のイベント管理手段1304の処理手順は、これらの各コマンドに対応する処理のうち主要な部分のみを示したものである。図3、図5、および図9のフローチャートでは、イベント管理手段1304に指示を与える処理があるが、それらの指示は実際には図10に示したコマンドを発行することにより為されている。以下では、各コマンドがどの処理で使用されているか簡単に説明する。
【0069】
Wコマンドは、前記イベント保存条件検出手段1302が図3の処理3006で発行する。また、Cコマンド、Sコマンド、およびDコマンドは、前記イベント擬似発生条件検出手段1306が図5の処理5002、処理5004、および処理5008で発行する。Sコマンドは、前記イベント擬似発生条件検出手段1306が図9の処理9004で、イベント擬似発生条件の擬似発生すべきイベントがイベント情報1310に保存されているかどうか調べる際にも使用する。また、擬似発生すべきイベントがイベント情報1310に保存されている場合、図9の処理9006でそのイベントデータを読出すが、その読出しにはRコマンドを用いる。
【0070】
次に、前記イベント管理手段1304のSコマンドで検索するときの検索条件について述べる。検索条件としては、イベント情報1310に登録されている内容のうちいずれかの項目名とその項目がとりうる任意の値を指定する。イベント管理手段1304は、指定された項目が指定された値に一致するイベントデータをイベント情報1310から取り出し、Sコマンドの発行元に返す。また、複数の条件を指定し、前記条件の論理和、論理積の指定も可能である。
【0071】
前回検索以降に更新されたイベントデータを取り出す(図5の処理5004)には、前回検索時の時刻を覚えておき、前記Sコマンドで前記時刻よりも新しいものを検索すればよい。
【0072】
前記イベント管理手段1304のCコマンドは、指定した条件式が成立するかどうかを調べるものであり、結果を0か1の数値で返す。条件式を組み合わせることにより、複数の条件のうちいくつ成立したかという条件式を作成することが可能であり、複数のイベントのうちいずれか2つ以上が発生しているという条件の指定も可能となる。条件式は、2つ以上の条件式の論理和、論理積、差、もしくは和からなるか、またはただ1つの論理式からなる。この論理式では、イベント情報1310に登録されているイベントのイベントIDと項目名およびその値を指定し、指定したイベントIDを持つイベントの指定した項目の値を前記指定した値と比較する。その比較方法としては、一致、不一致、大小関係(一致を含むもの)、または大小関係(一致を含まないもの)のいずれかを選択することができる。
【0073】
前記イベント管理手段(図1の1304)が管理するイベント情報(図1の1310)にイベントを登録してばかりいたのでは、いずれ前記イベント情報1310が溢れてしまう。そのため、不要なイベントはイベント情報1310から破棄する必要がある。イベントを破棄する条件として、例えば以下の条件が挙げられる。
▲1▼起動イベントを受けとった後、その起動イベントと同じ計算機またはプロセスの停止イベントを受けとったとき
▲2▼以前に受けとったイベントに対する取り消しイベントを受けとったとき
▲3▼同じイベントが何度もくり返し発生するとき
▲4▼2回目以降発生したイベント(必要に応じて発生回数や発生時刻を記憶しておく)
▲5▼イベント擬似発生手段により擬似発生したイベント
▲6▼発生時刻や発生回数などにより不要になったイベント
▲7▼イベントが擬似発生され、それ以降は使用されないイベント
▲8▼最新のイベントが必要なときの最新のものではないイベント
▲9▼発生後一定時間を過ぎると意味がないイベントが発生後一定時間以上経ったとき
【0074】
本実施例では、前記条件が満たされると、イベント管理手段1304自身、もしくはイベント擬似発生条件検出手段1306が前記イベント情報のDコマンドを使用して、不要なイベントデータの削除を行う。
【0075】
次に、クライアント起動時発生イベント一覧表1504について述べる。通信回線1010に接続されている計算機1000のクライアントおよび不図示の他の計算機のクライアントが起動したかどうかを知るには、どのクライアントが起動時にどのイベントを発行するかを知る必要がある。このために、クライアント起動時発生イベント一覧表1504を作成しておく。このファイルは、クライアントのIDとそのクライアントが起動したときに発生されるクライアント起動時発生イベントのイベントIDとの対の一覧である。
【0076】
図11に、クライアント起動時発生イベント一覧表1504の例を示す。このファイルは、クライアント名のフィールドとそのクライアントが起動時に発生するイベントのIDのフィールドとからなる。第1カラム(11000)はクライアント名を示し、第2カラム(11002)は前記クライアントが起動時に発生するイベントのIDを示す。
【0077】
図11のクライアント起動時発生イベント一覧表1504は、クライアント1(client1)が起動したときイベントIDが「100」のクライアント起動時発生イベントが発生し、クライアント2(client2)が起動したときイベントIDが「213」のクライアント起動時発生イベントが発生し、クライアント3(client3)が起動したときイベントIDが「125」のクライアント起動時発生イベントが発生することを示している。
【0078】
次に、自動運転システム1100における運用ルールの例について述べる。図12は、計算機システム1000内で発生したイベントに対して行う処理を定義した運用ルール定義ファイル1500の内容例を示す。
【0079】
図12の運用ルールでは、コロン「:」の前半にイベントIDを記述し、コロン「:」の後半に当該イベントIDに応じて実行すべきコマンドを記述している。図12の1行目の運用ルールは、「イベントIDが100(16000)のイベントが発生したら、startup_client_1コマンドを実行する(16002)」ということを意味している。また、図12の2行目の運用ルールは、「イベントIDが120(16004)かつイベントメッセージが"KJAE903"で始まる(16006)イベントが発生したら、startup_client_2コマンドを実行する(16008)」ということを意味している。
【0080】
既に図1、図3の処理3002,3600、および図7で説明したように、イベント保存条件検出手段1302では、運用ルール定義ファイル1500からイベント保存条件を抽出する。また、図1、図5の処理5600、および図8で説明したように、イベント擬似発生条件検出手段1306は、運用ルール定義ファイル1500およびクライアント起動時発生イベント一覧ファイル1504からイベント擬似発生条件を抽出する。図13に、イベント保存条件およびイベント擬似発生条件の抽出の例を示す。
【0081】
図13において、12000はクライアント1の運用ルール定義ファイルを示す。12002はクライアント2の運用ルール定義ファイルを示す。12004はクライアント起動時発生イベント一覧表ファイル1504を示す。
【0082】
クライアント1の運用ルール定義ファイル(12000)では、イベントIDが100のイベントが発生するとclient_command_1を実行するというルールが定義されている。また、クライアント2の運用ルール定義ファイル(12002)では、イベントIDが110かつメッセージに"test"という文字列が含まれているイベントが発生するとcilent_command_2を実行し、イベントIDが120のイベントが発生するとclient_command_3を実行するように定義されている。また、クライアント起動時発生イベント一覧ファイル(12004)では、クライアント1が起動するときはイベントIDが200のクライアント起動時発生イベントが、またクライアント2が起動するときはイベントIDが210のクライアント起動時発生イベントが発生することが記述されている。
【0083】
イベント保存条件(12006)を生成するには、図7で説明したように、運用ルール定義ファイル(12000,12002)の条件の部分を抽出する(12300,12302)。また、イベント擬似発生条件(12008)を生成するには、運用ルール定義ファイル(12000、12002)およびクライアント起動時発生イベント一覧ファイル(12004)から生成する(12304)。
【0084】
イベント擬似発生条件12008では、第1カラム(12010)のイベントが発生したとき、それに対応する第2カラムのイベント(12012)を(当該イベントが保存されていれば)擬似発生することを示している。この図のイベント擬似発生条件12008では、「クライアント1が立ち上がってイベントIDが200のクライアント起動時発生イベントが発生したとき、イベントIDが100のイベントを擬似発生する」というイベント擬似発生条件、および「クライアント2が立ち上がってイベントIDが210のクライアント起動時発生イベントが発生したとき、イベントIDが110かつメッセージに"test"という文字列が含まれているイベントを擬似発生する」というイベント擬似発生条件を示している。
【0085】
例えば、クライアント1が起動した後にイベントIDが100のイベントが発生する場合は、クライアント1でそのイベントIDが100のイベントを受け取ることができる。また、イベントIDが100のイベントが先に発生した場合(この場合、当該イベントIDが100のイベントは保存される)も、クライアント1が立ち上がってイベントIDが200のクライアント起動時発生イベントが発生したとき、イベント擬似発生条件に基づいてイベントIDが100のイベントが擬似発生され、クライアント1でその擬似発生されたイベントを受け取ることができる。
【0086】
なお、本実施例では、主として自動運転システムの運用ルールからイベント擬似発生条件を自動生成する例を説明した。しかし、これだけでは充分でない場合もあり、その場合は、ユーザが定義する擬似発生条件定義ファイル1502を記述することで、ユーザが自らイベント擬似発生条件を定義することが可能である。
【0087】
また、本実施例では、簡単のため、1台の計算機に対して1つのクライアントに着目したが、これに限らず、各計算機で複数のプロセスが動作する場合に対して本発明を適用してもよい。例えば、図1の運用ルール1500をプロセス単位で設け、ファイル1504には各プロセスの起動時発生イベントを登録しておき、図7や図8の処理では計算機単位でなくプロセス単位に処理を行なうようにすれば、プロセス間でやり取りされるイベントの制御に本発明を適用できる。
【0088】
次に、本発明の第2の実施例を説明する。この第2の実施例では、クライアントサーバシステムにおいてサーバ起動イベントおよびクライアント起動イベントを制御して不都合の生じない順序にする方法を示す。
【0089】
図14は、第2の実施例のシステム構成を示す。本システムでは、計算機15002が通信回線15000に接続されている。さらに、計算機15002上ではイベントサービス15200が提供されており、サーバ15204およびクライアント15206が動作している。また、サーバ15204およびクライアント15206の起動イベントを制御するイベント制御装置15202が動作している。このとき、クライアント15206は、サーバ15204の起動イベントを受けとり、動作を開始(サーバ15204が提供するサービスの利用開始)するものとする。イベント制御装置15202は、上述の第1の実施例のイベント制御装置1202と同様の装置である。
【0090】
図14のようなシステムにおいて、クライアント15206が先に起動した場合は、後で起動したサーバ15204が発生するサーバ起動イベントをクライアント15206で受けとることができるため、正常に動作する。しかし、サーバ15204が先に起動すると、後から起動したクライアント15206はサーバ15204の起動イベントを受けとれないため、いつまでたってもサーバ15204の起動イベント待ちになる。
【0091】
そこで、イベント制御装置15202では、サーバ15204の起動イベント15402を受け取り(15400)、そのイベントを保存しておき、後から起動したクライアント起動イベント15406を受けとったとき(15400)、前記保存しておいたサーバ15204の起動イベントを擬似発生する(15404)。クライアント15206は、その擬似発生したイベントを受け取る(15408)。これにより、クライアント15206は、後から起動した場合でも先に起動したサーバ15204の起動イベントを受けとることができる。
【0092】
図15に、イベント制御装置15202におけるそのような処理の流れを示す。
【0093】
初期化(17000)の後、イベントが発生するのを待ち(17002)、発生したイベントがサーバ起動イベントかどうかを調べる(17300)。サーバ起動イベントならば、それが自イベント制御装置15202にて発生した擬似イベントかどうかを調べる(17302)。受けとったイベントが擬似イベントでなければ、そのサーバ起動イベントを保存し(17004)、処理17002に戻る。
【0094】
処理17300で受けとったイベントがサーバ起動イベントでなかった場合は、次にクライアント起動イベントかどうかを調べる(17304)。クライアント起動イベントならば、すでにサーバ起動イベントが検知されているかどうかを調べ(17306)、検知されていればサーバ起動イベントが保存されているから、保存しているサーバ起動イベントを擬似発生して(17006)、処理17002に戻る。処理17304でクライアント起動イベントでないとき、あるいは処理17306でサーバ起動イベントが保存されていないときは、処理17002に戻る。
【0095】
次に、本発明の第3の実施例を説明する。この実施例は、上述の第2の実施例におけるサーバ/クライアント起動イベントの制御方法を自動運転システムの運用ルールを記述することで実現する方法を示すものである。そのような制御を行う運用ルールを説明する前に、運用ルールで、サーバの起動イベントを受信するとクライアントがサービスを利用開始するという内容の定義を行った例を、図16に示す。
【0096】
図16において、対象となるイベント(13000)はサーバ起動イベントであり、対象となる操作(13004)はクライアントのサービス利用開始コマンド(サーバのサービスの利用を開始するコマンド)である。これらのイベントおよびコマンドをセパレータ(13002)で区切っている。このような運用ルールを指定しておくことにより、サーバ起動イベント(13000)が発生するとクライアントのサービス利用開始コマンド(13004)が実行される。
【0097】
図17に、運用ルールで上述の第2の実施例に示した制御を実現した例を示す。本実施例では、サーバとクライアントのプロセスが実行されている計算機システムで、第3のプロセスが実行されており、その第3のプロセス(イベント制御装置と見ることができる)が図17の運用ルールにしたがって自動運転していることを前提とする。
【0098】
図17の運用ルールは、図16の運用ルールと同様の表記で記述されている。14002,14014は、イベントとコマンドとを分けるセパレータ(図16の13002に対応)である。
【0099】
図17の運用ルールでは、クライアント起動イベントを検知すると(14000)、イベントが発生したことをファイルを作成することで記録しておく(14004)。また、すでにサーバ起動イベントが発生している場合(14006)、サーバの起動イベントを送信(擬似発生)する(14008)。
【0100】
一方、サーバ起動イベントを検知すると(14012)、サーバ起動を示すファイルを作成し(14016)、クライアントがすでに起動していれば(14018)、クライアントのサービスを開始するコマンド(14020)を実行する。
【0101】
このような運用ルールを定義しておくことで、クライアントが後に起動しても、以前に発生したサーバ起動イベントを擬似発生することができる。
【0102】
【発明の効果】
以上説明したように、本発明によれば、イベント発生のタイミングや発生回数などを自動的に制御できる。また、複数のイベントが全て発生したときに処理を行うという指定が容易にできるようになる。
【0103】
また、イベント情報を保存するイベントは自動的に選択されるため、計算機資源の無駄な使用やユーザの手間を削減することができ、ユーザが指定する場合に比べ、指定漏れや指定誤りを減らすことができる。
【0104】
さらに、クライアントサーバシステムにおいて、サーバがクライアントよりも先に起動してもクライアントに対してサーバ起動イベントを自動的に送信することが可能になるため、クライアントとサーバの起動順序の制限を解消することができる。
【図面の簡単な説明】
【図1】本発明の第1の実施例のシステム構成の例を示す図
【図2】イベント検出手段のフローチャートを示す図
【図3】イベント保存条件検出手段のフローチャートを示す図
【図4】イベント管理手段のフローチャートを示す図
【図5】イベント擬似発生条件検出手段のフローチャートを示す図
【図6】イベント擬似発生手段のフローチャートを示す図
【図7】イベント保存条件抽出アルゴリズムのフローチャートを示す図
【図8】イベント擬似発生条件抽出アルゴリズムのフローチャートを示す図
【図9】イベント擬似発生条件検出アルゴリズムのフローチャートを示す図
【図10】イベント管理手段に対するコマンド表を示す図
【図11】クライアント起動時発生イベント一覧表を示す図
【図12】運用ルール定義ファイルの例を示す図
【図13】保存条件および擬似発生条件の生成例を示す図
【図14】サーバクライアントシステムにおけるイベント発生順序の制御を示す図
【図15】イベント発生順序の制御手順のフローチャートを示す図
【図16】運用ルールの例を示す図
【図17】運用ルールによる実現例を示す図
【符号の説明】
1000…計算機、1010…通信回線、1104…イベントサービス、1100…自動運転システム、1202…イベント制御装置、1300…イベント検出手段、1302…イベント保存条件検出手段、1304…イベント管理手段、1306…イベント擬似発生条件検出手段、1308…イベント擬似発生手段、1310…イベント情報、1500…運用ルール定義ファイル、1502…擬似発生条件定義ファイル、1504…クライアント起動時発生イベント一覧ファイル。
[0001]
[Industrial application fields]
The present invention relates generally to computer systems, and more particularly to controlling events that occur within a computer system.
[0002]
[Prior art]
Various events occur frequently in the computer system, such as when a process is started or an error occurs. Some of these events require processing according to the occurrence of the event. For example, in the window system, when an event that a key is pressed occurs, an action corresponding to the event is executed, or a character is displayed.
[0003]
In this way, an event that occurs in a computer system is regarded as an event. When an event occurs, an example of a system that performs some processing on the event is the X-Window System ("X Window System, Version 11 Release 4 Release Notes"). , Jim Fulton, XConsortium, MIT Laboratory for Computer Science). In this window system, processing for various events such as displaying a character when a key is pressed and displaying a menu when a mouse button is clicked is defined.
[0004]
Some systems that handle these events have a function of saving and playing back the generated events. For example, if the events to be saved are limited to keystrokes only, the keyboard macro implemented in many editors ("GNU Emacs Manual" 28.3 Keyboard Macro, written by Richard Stallman, translated by Takeo Ikuo and Amami Ryoji, Kyoritsu Shuppan) It can be seen as a kind. In some window systems, a series of events can be stored and played back together for automatic operation to perform an automatic demonstration.
[0005]
However, in the above-mentioned system, in many cases, the phases for storing and playing back events are independent of each other. When saving, all the time until the end of saving is saved, and when playing back, they are played together. Yes. Also, the events to be saved are all events saved or events designated by the user are saved. Furthermore, a method for modifying a saved event or creating a new one has also been proposed (Japanese Patent Laid-Open No. 6-30030 “Editor with Demonstration Function”). Must be done.
[0006]
[Problems to be solved by the invention]
By the way, in the system which handles such a conventional event, the following problems occur due to inconsistency in the exchange of events.
[0007]
For example, in a system that handles conventional events, even if an event occurs, an application that is in a state of waiting for the occurrence of the event after the occurrence of the event knows that the event has occurred in the past There was a problem that could not.
[0008]
In the client server system, when the client is started first and then the server is started, a server start event is sent from the server to the client, so that the client knows that the server is started and provides the server. Some have started to use the service. In this case, when the client is activated after the server is activated, the client cannot receive a server activation event, and therefore cannot know that the server is activated, and the system does not work properly.
[0009]
Furthermore, since an event is transmitted only once when it occurs, unless it is specified by the user or handled in the event generation part of the application, the received event is automatically generated repeatedly or automatically after a certain period of time. It cannot be generated. However, there is a problem that if the user designates or performs an event generation unit of the application to perform the processing, a burden is imposed on the user or the application.
[0010]
In addition, even if you use the function to save and play events such as the above-mentioned keyboard macro, you can perform automatic operation and automatic demonstration, and events such as automatic control of event occurrence order and number of occurrences It is impossible to realize various controls according to the above. Furthermore, when saving events, if you save all the events that occur, there is a problem of consuming a large amount of resources, and if you specify it, the user's effort increases and there is a possibility that there is a possibility of omission of specification was there.
[0011]
An object of the present invention is to provide an event control method and an event control apparatus for automatically controlling the occurrence order and the number of occurrences of events occurring in a computer system.
[0012]
[Means for Solving the Problems]
In order to achieve the above object, the present invention provides an event control apparatus for handling an event that has occurred in a computer, the event detecting means for detecting an event that has occurred in the computer, and the event according to a predetermined event storage condition. Event management means for storing the data of the event, and event simulation generating means for generating an event based on the event data in accordance with a predetermined event simulation generation condition As the event storage condition, only a predetermined type of event is stored, a predetermined number of events are stored, an event generated a predetermined number of times by the event simulation generation unit is not stored, and the event simulation generation unit The condition is that at least one of the following events not to be saved is not stored It is characterized by that.
[0013]
The present invention also provides a server that generates a server start event at startup and provides a service to the client, and a client that generates a client start event at startup and starts using the service of the server when the server start event is received. An event control apparatus in a client server system comprising: server activation event detection means for detecting the server activation event generated when the server is activated; and server activation detected by the server activation event detection means Server activation event storage means for storing an event, client activation event detection means for detecting the client activation event generated when the client is activated, and client activation event detected by the client activation event detection means. In response to the detected the door, characterized by comprising a server activation event pseudo generating means for sending to the client by a pseudo generate server startup event that has been the storage.
[0014]
Furthermore, the present invention is an event control method for handling an event that has occurred in a computer, the event detection step for detecting an event that has occurred in the computer, and storing the event data in accordance with a predetermined event storage condition. An event management step; and an event simulation generation step for generating an event based on the event data in accordance with a predetermined event simulation generation condition. As the event storage condition, only a predetermined type of event is stored, a predetermined number of events are stored, an event that has occurred a predetermined number of times in the event simulation generation step is not stored, and the event simulation generation step The condition is that at least one of the following events not to be saved is not stored It is characterized by that.
[0015]
The present invention also provides a server that generates a server start event at startup and provides a service to the client, and a client that generates a client start event at startup and starts using the service of the server when the server start event is received. An event control method in a client server system comprising: a server activation event detection step for detecting the server activation event that occurs when the server is activated; and a server activation detected in the server activation event detection step A server activation event storage step for storing an event, a client activation event detection step for detecting the client activation event generated when the client is activated, and a client activation event detection step. Triggered by the client to that detect activation event, characterized in that the server triggering event that has been the storage and a server activation event pseudo generating step of sending to the client in a pseudo occurred.
[0016]
[Action]
According to the present invention, the event detection means detects an event that has occurred in the computer. When detected, the event data is stored according to a predetermined event storage condition. In addition, an event based on the event data is generated in accordance with a predetermined event generation condition.
[0017]
Further, in a client server system in which a client receives a server start event and starts processing, when the server is started before the client, the server start event detecting means detects a server start event that occurs at the time of starting the server. The server activation event storage means stores it. Then, when the client activation event received at the client activation is received by the client activation event detecting means, the server activation event is simulated by the server activation event simulation generating means, so that the client receives the server activation event. Try not to miss it.
[0018]
【Example】
Embodiments of the present invention will be described below with reference to the drawings.
[0019]
FIG. 1 shows an example of the system configuration of a computer system to which the present invention is applied. With reference to FIG. 1, the outline of the configuration and operation of the computer system of this embodiment will be described.
[0020]
The computer 1000 is connected to the communication line 1010. On the computer 1000, an event service 1104 for exchanging information by an event with a process on the own computer or another computer is provided. In other words, an event to be input to the computer 1000 is input via the event service 1104 regardless of whether the event has occurred in the own computer or in another computer. An event that has occurred in another computer is input to the event service 1104 via the communication line 1010. An event that occurs in its own computer and is to be sent to another computer is sent to the communication line 1010 via the event service 1104. Although only the computer 1000 is shown in FIG. 1, it is assumed that another computer (for example, a computer serving as a server or a computer serving as a client) is connected to the communication line 1010.
[0021]
On the computer 1000, an automatic operation system 1100 using the event service 1104 (1430) is operating. The automatic operation system 1100 holds an operation rule definition file 1500 describing operation rules for automatic operation. The operation rule describes what kind of processing is performed in response to the event that has occurred. This operation rule includes not only an operation rule describing a process corresponding to an event occurring in the computer 1000 but also an operation rule describing a process corresponding to an event occurring in another computer. A specific example of the operation rule will be described later with reference to FIG. In other computers (not shown) connected to the communication line 1010, it is assumed that an automatic driving system using an event service is operating.
[0022]
Further, the computer 1000 holds a pseudo occurrence condition definition file 1502 defined by the user and an event list file 1504 generated at the time of starting the client. The pseudo-generation condition definition file 1502 includes an event pseudo-generation condition (what is defined by the user) that indicates what event is to be simulated when the condition is met in the event pseudo-generation condition detection unit 1306 described later. ) Is described. The client startup event list file 1504 describes a list of events that occur when the client is started when the client is started on the other computer connected to the computer 1000 and the communication line 1010. The client startup event list file 1504 will be described later with reference to FIG. In this embodiment, for simplicity, it is assumed that one client to be focused is operating on one computer. Therefore, the event that occurs when the client starts is also an event indicating that the computer has started up.
[0023]
In the computer 1000, an event control device 1202 according to the present invention is operating. The event control device 1202 includes event detection means 1300, event storage condition detection means 1302, event management means 1304, event simulation occurrence condition detection means 1306, and event simulation generation means 1308. Further, event information 1310 managed by the event management means 1304 exists on the file system or the memory.
[0024]
The event service 1104 passes the received various events to the event detection means 1300 (1400). The event detection means 1300 passes the event received from the event service 1104 to the event storage condition detection means 1302 (1412), and simultaneously passes it to the event simulation occurrence condition detection means 1306 (1422).
[0025]
The event storage condition detection unit 1302 reads (1402) and stores in advance a storage condition indicating which event is passed to the event management unit 1304 and stored in the event information 1310 from the operation rule definition file 1500. Then, the event storage condition detection means 1302 determines whether the event received from the event detection means 1300 is an event to be stored based on the storage condition (1412). It is passed to the management means 1304 (1414) and is saved in the event information 1310 (1432). Note that it is also possible to determine which event is to be stored by an event storage condition definition file defined by the user.
[0026]
The event pseudo-occurrence condition detection means 1306 uses the operation rule definition file 1500, the user-defined pseudo-occurrence condition definition file 1502, and the event list generated when the client starts (event pseudo-occurrence condition). Is obtained (1400, 1422) and retained. The simulated event occurrence condition includes a condition part and information for specifying an event to be simulated when the condition part is established.
[0027]
Also, the event simulation occurrence condition detection means 1306 refers to the event information 1310 using the event management means 1304 to check whether it has been updated (1416), and if it has been updated, obtains event data for the update. To do. Then, the event received from the event detection means 1300 and the updated event data are collated with the stored event simulation occurrence condition (the condition part thereof) to determine whether the event is to be simulated. More specifically, it is determined whether a condition part of the event simulation occurrence condition is satisfied and whether an event to be simulated when the condition part is satisfied is stored in the event information 1310. When the condition part of the simulated event occurrence condition is satisfied and the event to be simulated when the condition part is satisfied is stored in the event information 1310, the simulated event occurrence condition is satisfied, and the event is Simulate.
[0028]
In this embodiment, it is determined whether or not the condition part of the event simulation occurrence condition is satisfied, as shown in FIGS. 5 and 9 to be described later, an event received from the event detection unit 1300 and an updated event. This is done by checking the data against the condition part of the event simulation occurrence condition. However, if the condition part of the simulated event occurrence condition includes that a predetermined event has occurred in the past as part of the condition, refer to the event that has occurred in the past stored in the event information 1310. Then, it may be determined whether or not the condition part of the event simulation occurrence condition is established.
[0029]
When the event is simulated, the event simulation occurrence condition detection unit 1306 requests the event management unit 1304 to acquire information about the event to be simulated (1416). In response to this request, the event management unit 1304 extracts necessary event information from the event information 1310 (1432) and passes it to the event simulation occurrence condition detection unit 1306. The event simulation occurrence condition detection unit 1306 receives the event information (1416) and passes it to the event simulation generation unit 1308 (1418). The event simulation generation means 1308 receives event information from the event simulation generation means 1306 and generates an event simulation (1420).
[0030]
As described above, an event satisfying a predetermined storage condition can be stored, and if the predetermined event simulation occurrence condition is satisfied, the stored event can be simulated. This makes it possible to automatically control the order of occurrence of events and the number of occurrences. Hereinafter, the operation of each unit in the configuration of FIG. 1 will be described in more detail.
[0031]
FIG. 2 shows a process flow of the event detection means (1300 in FIG. 1).
[0032]
The event detection means 1300 checks whether an event has occurred after initialization (2000) (2300), and if not, waits until an event occurs. If an event has occurred, the event data is read from the event service 1104 (2002), and the event is passed to the event storage condition detection means (1302 in FIG. 1) (2004). Further, the event is also passed to the event simulation occurrence condition detection means (1306 in FIG. 1) (2006). The event passed in the process 2004 is received by the event storage condition detection means 1302 in the process 3004 of FIG. The event passed in the process 2006 is received by the event simulation occurrence condition detection unit 1306 in 9002 of FIG. 9 described later.
[0033]
FIG. 3 shows a processing flow of the event storage condition detection means (1302 in FIG. 1).
[0034]
In the event storage condition detection means 1302, after initialization (3000), the operation rule (1500 in FIG. 1) of the automatic driving system is read (3002), and the storage rule indicating which event should be stored is the operation rule. Extract from (3600). The algorithm for extracting the event storage condition will be described later with reference to FIG.
[0035]
Next, the event storage condition detection means 1302 checks whether there is event data from the event detection means (1300 in FIG. 1) (3300), and if not, waits. If there is event data from the event detection means 1300, the event data is received (3004). Then, based on the event storage condition extracted in the process 3600, it is checked whether the received event is an event to be stored (3302). If the event is to be stored, the event management means (1304 in FIG. 1) stores the event. A request to save the data is issued (3006). Then, it is checked whether or not the reply to the request is an error (3304), and if it is an error, error processing such as recording in an error log is performed (3008).
[0036]
FIG. 4 shows the processing flow of the event management means (1304 in FIG. 1). Actually, the event management means 1304 accepts a command as shown in FIG. 10 to be described later, reads the event information 1310 in accordance with the accepted command, stores event data, determines a given condition, and is given Searches according to conditions and deletion of event data are performed. In FIG. 4, processing corresponding to all these commands is not described, and for the sake of simplicity, a schematic procedure of only main processing portions is illustrated.
[0037]
The event management means 1304 first performs initialization (4000). At this time, the update flag is set to TRUE. The update flag is a flag for checking whether or not the event information 1310 has been updated since the previous event simulated occurrence condition detection unit 1306 accessed. When the update flag is TRUE, it indicates that the event information 1310 has been updated since the last time the simulated event occurrence detection means 1306 accessed, and when it is FALSE, it indicates that there was no update .
[0038]
When the initialization (4000) is completed, a request for checking whether or not the event information 1310 has been updated (request issued in processing 5002 in FIG. 5 described later) comes from the event simulation occurrence condition detection means (1306 in FIG. 1). (4300), if so, the current update flag value is returned to the event simulation occurrence condition detection means 1306 (4002).
[0039]
Next, it is checked whether or not a request for deleting event data in the event information 1310 (request issued in processing 5008 in FIG. 5 described later) is received from the event simulation occurrence condition detection means 1306 (4308). The event data is deleted according to the request (4020). If an error has occurred in the process of deleting the event data (4312), an error is returned to the event simulation occurrence condition detection means 1306 (4024).
[0040]
Next, it is checked whether or not a storage request (request issued in processing 3006 in FIG. 3) is received from the event storage condition detection means (1302 in FIG. 1) (4302). The event data to be stored is received from the detection means 1302 (4004), and it is checked whether the data is correct (4006). If the event data is correct (4304), the event data is stored in the event information 1310 (4010), the update flag is set to TRUE (4012), and the process returns to the process 4300 again. If the data is not correct (4304), an error is returned to the event storage condition detection means 1302 (4008), and the process returns to the process 4300 again.
[0041]
If the storage request from the event storage condition detection unit 1302 has not been received in the processing 4302, an event data read request is issued from the event simulation occurrence condition detection unit 1306 (the processing 5004 in FIG. 5 and 9004 in FIG. 9 described later). Whether or not (request) has come is checked (4306). If it has come, data corresponding to the read request is read from the event information 1310 (4014). At this time, if an error has occurred (4310), an error is returned to the event simulation occurrence condition detecting means 1306 (4022), and the process returns to the process 4300 again. If no error has occurred (4310), the update flag is set to FALSE (4018), and the read data is passed to the event simulation occurrence condition detection means 1306 (4016). Thereafter, the process returns to the process 4300 for checking whether or not a request for checking whether or not the event information 1310 has been updated is received, and the process is repeated.
[0042]
FIG. 5 shows a processing flow of the event simulation occurrence condition detection means (1306 in FIG. 1).
[0043]
After the initialization (5000), the event simulation occurrence condition detection means 1306 extracts the event simulation occurrence condition from the operation rule (1500 in FIG. 1) of the automatic operation system (1100 in FIG. 1) (5600). An algorithm for extracting the simulated event occurrence condition will be described later with reference to FIG. Thereafter, the simulated event occurrence condition is extracted from the simulated occurrence condition definition file 1502 created by the user, and merged with the simulated event occurrence condition extracted in the process 5600 (5008).
[0044]
Next, a request for checking whether or not the event information 1310 has been updated is sent to the event management means 1304 (5002). When the update flag returned from the event management means 1304 is TRUE, it means that the event information 1310 has been updated since the previous inquiry (5300), so the event management means 1304 is requested. Then, the updated event data is read from the event information 1310 (5004), and the process proceeds to the next processing 5602. If the update flag returned from the event management unit 1304 is FALSE, it means that the event information 1310 has not been updated since the previous inquiry (5300), and the process directly proceeds to the process 5602.
[0045]
Next, based on the read data (updated event information 1310), the current time, etc., whether any of the simulated event occurrence conditions (extracted in processing 5600 and 5608) is satisfied is determined. Examine (5602). Details of this processing 5602 will be described later with reference to FIG. If any of the event simulation occurrence conditions are satisfied (5302), the event simulation generation means (1308 in FIG. 1) generates an event that should be simulated according to the established event simulation generation conditions. Request (5006) to proceed to processing 5304. When there is no event simulation occurrence condition that is satisfied, the process returns from the process 5302 to the process 5002.
[0046]
After the process 5006, it is determined whether or not the event simulated in the process 5006 is unnecessary (5304). If the event is unnecessary, a request for deleting the event is issued to the event management means 1304 (5008). If an error occurs during this deletion process (5306), an error process such as writing an error message in the error log is performed (5010). If it is determined in the process 5304 that the simulated event is not unnecessary, the process returns to the process 5002 as it is. When no error has occurred in the process 5306 and after the error process in the process 5010, the process returns to the process 5002.
[0047]
FIG. 6 shows a processing flow of the event simulation generating means (1308 in FIG. 1).
[0048]
The event simulation generation means 1308 checks whether an event simulation generation request (request issued in the process 5006 in FIG. 5) from the event generation condition detection means 1306 has arrived after initialization (6000) (6300). If an event simulation occurrence request has been received (6300), an event received from the event simulation occurrence condition detection means 1306 (the event data is read in the process 9006 of FIG. 9 described later) is generated (6002), The process returns to the process 6300 again. When the event simulation occurrence request is not received (6300), the process returns to the process 6300 as it is.
[0049]
FIG. 7 shows the flow of processing of the event storage condition extraction algorithm. The process of FIG. 7 corresponds to the process 3600 of FIG.
[0050]
When the process is started (7000), it is checked whether there is a computer having an operation rule for which a storage condition has not yet been extracted (7304), and if not, the process ends (7006). If there is a computer with operational rules for which the storage conditions have not yet been extracted (7304), select one of them (7008), and there is an operational rule for which the storage conditions have not yet been extracted for the selected computer Check to see if (7300). When the storage condition has been extracted from all the operation rules of the computer, the process returns from the process 7300 to the process 7304.
[0051]
If there is an operation rule for which the storage condition has not yet been extracted in the selected computer (7300), one of the operation rules that have not been examined is extracted, and the condition part is extracted from the extracted operation rule ( 7002). Then, it is checked whether or not the extracted condition portion is a condition based on an event ID or an event message (7300), and if it is any of the above conditions, the extracted condition is added to the event storage condition (7004). Thereafter, the process returns to the process 7300. If it is determined in process 7302 that the extracted condition is neither an event ID nor a condition based on an event message, the process returns from process 7302 to process 7300.
[0052]
FIG. 8 shows the flow of processing of the simulated event occurrence condition extraction algorithm. The processing in FIG. 8 corresponds to 5600 in FIG.
[0053]
After the start of processing (8000), it is checked whether or not there is a computer that has not yet extracted the event pseudo-occurrence condition for all the computers having the operation rule (8300), and if not, the processing ends (8008). If there is a computer that has not yet extracted the simulated event occurrence conditions, select one of the computers (8002), and select the event waiting condition part (which event is waiting) from the operation rules of the selected computer. Taking out (8004), a pair of the selected computer name and the taken-out event is stored (8006). Thereafter, the process returns to the process 8300.
[0054]
In this embodiment, as described with reference to FIG. 1, it is assumed that one notable client operates for one computer, so “computer” and “client” have a one-to-one correspondence. is doing. Therefore, in this embodiment, as the “computer name” stored in the process 8006, the event ID of the event that occurs when the client of the computer is activated is used. The event ID of the event that occurs when the client of each computer is activated is obtained by referring to the event list 1504 that occurs when the client is activated. A specific example of the extraction of the simulated event occurrence condition will be described later with reference to FIG.
[0055]
The pair of the name of the computer stored at the end of processing (8008) (that is, the event that occurred when the client started) and the event (the event extracted from the event waiting condition part of the operation rule related to the client) This is a simulated event occurrence condition. More specifically, the event that occurs when the first half of the client is started indicates the condition part of the event simulation occurrence condition, and the second half event indicates the event that should be simulated when the condition part is satisfied.
[0056]
Assume that the first half of the condition part is A, the second half of the event to be simulated is B, and A: B represents the event simulation occurrence condition. In short, A: B means that the event waiting for the client a where A occurs at the time of activation is B. If the event B occurs before the start of the client a, it is possible that the client a cannot receive the event B and does not operate normally. Therefore, in the present embodiment, when event B occurs, it is stored as event information 1310, A: B is registered in the simulated event occurrence condition, and when A is established (client a starts up) If the event B has been stored, the event B is simulated. As a result, the client a can receive the event B and operates normally thereafter.
[0057]
FIG. 9 shows the processing flow of the event simulation occurrence condition detection algorithm. The processing in FIG. 9 corresponds to 5602 in FIG.
[0058]
After the processing is started (9000), it is checked whether there is an event from the event detection means (1300 in FIG. 1) (9300). If there is, the event data from the event detection means 1300 is received (9002), and the processing proceeds to processing 9004. If there is no event data from the event detection means 1300, the process proceeds from process 9300 to process 9004.
[0059]
Then, the event received in the process 9002 and the updated event data read in the process 5004 in FIG. 5 are compared with the event in the condition part of the event simulation occurrence condition (9004). When the event simulation occurrence condition includes a condition related to time, the processing 9004 is compared in consideration of time. Further, in this embodiment, only the event from the event detection means 1300 and the updated event are compared with the condition part of the event simulation occurrence condition. If it is included as part of the condition, determine whether the condition part of the simulated event occurrence condition is satisfied by referring to the events that have occurred in the past stored in the event information 1310. To do.
[0060]
Further, in the process 9004, if an event simulation occurrence condition that matches the condition part is detected as a result of the comparison, whether or not an event that should be simulated in correspondence with the condition part is already stored in the event information 1310 Check out.
[0061]
In the comparison by the process 9004, a match between the event received in the process 9002 or the updated event data read in the process 5004 in FIG. 5 and the event in the condition part of the event simulation occurrence condition is detected, and the event simulation occurrence is detected. If an event that should be simulated under the condition has already been stored in the event information 1310 (9302), the simulated event generation condition is satisfied (9006). Otherwise (9302), the event simulation occurrence condition is not satisfied. When the simulated event occurrence condition is satisfied, event data related to the event to be simulated is read from the event information 1310.
[0062]
Next, an example of the condition part of the simulated event occurrence condition in the simulated event occurrence condition detection means (1306 in FIG. 1) will be described. Examples of the condition part of the event simulation occurrence condition include the following conditions (1) to (7).
(1) Among one or more predetermined events, more than a predetermined number of events occurred
(2) More than a predetermined number of events occurred in a predetermined order
(3) A predetermined time has passed since the event occurred.
(4) Occurred within a predetermined time
▲ 5 ▼ It was time decided in advance
(6) Generated on a predetermined computer
▲ 7 ▼ It occurred for a predetermined number of times
[0063]
The simulated event occurrence condition is automatically extracted from the operation rule (1500 in FIG. 1) of the automatic driving system (1100 in FIG. 1) by the simulated event condition detection means (1306 in FIG. 1) (5600 in FIG. 5). ). This process has been described with reference to FIG. Further, as described above, it is also possible to describe any event pseudo-generation condition including the above (1) to (7) in the pseudo-generation condition definition file (1502 in FIG. 1) defined by the user.
[0064]
Next, an example of the contents of event data registered in the event information (1310 in FIG. 1) will be given.
[0065]
The contents of the event data to be registered include an event ID (identifier), an event message, an event parameter, an event occurrence time, a computer in which the event has occurred, a user name in which the event has occurred, a group name, and a process name event occurrence. Number of times. These items do not necessarily have to be registered for all events.
[0066]
FIG. 10 shows a list of commands transmitted from the event storage condition detection means (1302 in FIG. 1) and the event simulation occurrence condition detection means (1306 in FIG. 1) to the event management means (1304 in FIG. 1).
[0067]
The R command, the W command, and the D command are commands for reading, writing, and deleting event data with respect to the event management unit 1304, respectively. The C command is a command for giving a condition to check whether the condition is satisfied. The C command is used to check whether an event simulation occurrence condition is satisfied. Further, the S command is a command for searching for an event that actually meets a condition.
[0068]
As described in the explanation of FIG. 4, the processing procedure of the event management means 1304 in FIG. 4 shows only the main part of the processing corresponding to these commands. In the flowcharts of FIGS. 3, 5, and 9, there are processes for giving instructions to the event management means 1304, but these instructions are actually issued by issuing the commands shown in FIG. In the following, a brief description of which process is used for each command will be given.
[0069]
The W command is issued by the event storage condition detection means 1302 in the process 3006 of FIG. Also, the C command, S command, and D command are issued by the event simulation occurrence condition detection means 1306 in processing 5002, processing 5004, and processing 5008 in FIG. The S command is also used when the event simulation occurrence condition detection unit 1306 checks in the process 9004 of FIG. 9 whether or not an event to be simulated in the event simulation occurrence condition is stored in the event information 1310. If the event to be simulated is stored in the event information 1310, the event data is read in the process 9006 of FIG. 9, and the R command is used for the reading.
[0070]
Next, search conditions when searching with the S command of the event management means 1304 will be described. As a search condition, an item name of contents registered in the event information 1310 and an arbitrary value that the item can take are specified. The event management unit 1304 retrieves event data in which the specified item matches the specified value from the event information 1310, and returns it to the S command issuer. It is also possible to specify a plurality of conditions and specify the logical sum and logical product of the conditions.
[0071]
In order to retrieve event data updated after the previous search (process 5004 in FIG. 5), the time at the previous search may be remembered, and the S command may be used to search for data that is newer than the time.
[0072]
The C command of the event management means 1304 is for checking whether or not a specified conditional expression is satisfied, and returns the result as a numerical value of 0 or 1. By combining conditional expressions, it is possible to create a conditional expression indicating how many of multiple conditions are satisfied, and it is also possible to specify a condition that any two or more of multiple events have occurred Become. The conditional expression consists of a logical sum, logical product, difference, or sum of two or more conditional expressions, or a single logical expression. In this logical expression, the event ID, item name, and value of an event registered in the event information 1310 are specified, and the value of the specified item of the event having the specified event ID is compared with the specified value. As the comparison method, one of coincidence, non-coincidence, magnitude relation (including a coincidence), or magnitude relation (no coincidence) can be selected.
[0073]
If events are registered in the event information (1310 in FIG. 1) managed by the event management means (1304 in FIG. 1), the event information 1310 will eventually overflow. Therefore, an unnecessary event needs to be discarded from the event information 1310. Examples of the conditions for discarding the event include the following conditions.
(1) When a computer or process stop event is received after receiving a start event
(2) When a cancellation event for a previously received event is received
(3) When the same event occurs repeatedly
(4) Events that have occurred for the second time or later (if necessary, store the number of occurrences and the time of occurrence)
(5) Events simulated by event simulation generation means
(6) Events that are no longer needed due to the time of occurrence or number of occurrences
(7) Events that are simulated and are not used after that
(8) Events that are not the latest when the latest events are required
(9) When a certain event passes after a certain period of time has elapsed
[0074]
In this embodiment, when the condition is satisfied, the event management unit 1304 itself or the event simulation occurrence condition detection unit 1306 deletes unnecessary event data using the D command of the event information.
[0075]
Next, an event list 1504 that occurs when the client is started will be described. In order to know whether the client of the computer 1000 connected to the communication line 1010 and the client of another computer not shown are activated, it is necessary to know which client issues which event when it is activated. For this purpose, an event list 1504 generated at the time of starting the client is created. This file is a list of a pair of an ID of a client and an event ID of an event generated when the client is started.
[0076]
FIG. 11 shows an example of an event list table 1504 generated at the time of starting the client. This file includes a client name field and an ID field of an event that occurs when the client starts up. The first column (11000) indicates the client name, and the second column (11002) indicates the ID of an event that occurs when the client is activated.
[0077]
In the client startup event list 1504 in FIG. 11, when the client 1 (client1) starts, an event ID “100” occurs when the client starts, and when the client 2 (client2) starts, the event ID is This indicates that when a client activation event “213” occurs and a client 3 (client 3) is activated, a client activation event with an event ID “125” occurs.
[0078]
Next, an example of operation rules in the automatic driving system 1100 will be described. FIG. 12 shows an example of the contents of an operation rule definition file 1500 that defines the processing to be performed for an event that has occurred in the computer system 1000.
[0079]
In the operation rule of FIG. 12, an event ID is described in the first half of the colon “:”, and a command to be executed according to the event ID is described in the second half of the colon “:”. The operation rule on the first line in FIG. 12 means that “when an event with an event ID of 100 (16000) occurs, the startup_client_1 command is executed (16002)”. In addition, the operation rule on the second line of FIG. 12 is that “when the event ID starts with 120 (16004) and the event message starts with“ KJAE903 ”(16006), an event occurs, the startup_client_2 command is executed (16008)”. I mean.
[0080]
As already described in the processes 3002 and 3600 of FIGS. 1 and 3 and FIG. 7, the event storage condition detection unit 1302 extracts the event storage conditions from the operation rule definition file 1500. Further, as described in the processing 5600 of FIGS. 1 and 5, and the event simulation occurrence condition detection means 1306, the event simulation occurrence condition is extracted from the operation rule definition file 1500 and the event list file 1504 generated at the time of starting the client. To do. FIG. 13 shows an example of extracting the event storage condition and the event simulation occurrence condition.
[0081]
In FIG. 13, 12000 indicates an operation rule definition file of the client 1. 12002 indicates an operation rule definition file of the client 2. 12004 shows an event list file 1504 generated when the client starts.
[0082]
The operation rule definition file (12000) of the client 1 defines a rule that client_command_1 is executed when an event with an event ID of 100 occurs. Also, in the operation rule definition file (12002) of client 2, when an event with an event ID of 110 and a message containing the string "test" occurs, cilent_command_2 is executed, and when an event with an event ID of 120 occurs It is defined to execute client_command_3. In the client startup event list file (12004), when the client 1 starts, an event with an event ID of 200 occurs when the client starts, and when the client 2 starts, an event with an event ID of 210 occurs. It describes that an event occurs.
[0083]
In order to generate the event storage condition (12006), as described in FIG. 7, the condition part of the operation rule definition file (12000, 12002) is extracted (12300, 12302). Further, to generate the simulated event occurrence condition (12008), it is generated from the operation rule definition file (12000, 12002) and the event list file (12004) generated at the time of starting the client (12304).
[0084]
The simulated event occurrence condition 12008 indicates that when an event in the first column (12010) occurs, an event (12012) in the second column corresponding to the event (if the event is stored) is simulated. . In the event pseudo-occurrence condition 12008 in this figure, an event pseudo-occurrence condition that “when the client 1 starts up and an event that occurs when the client whose event ID is 200 occurs is simulated as an event whose event ID is 100”, and “ When the event that occurs when the client 2 starts up and the event ID is 210 is generated, the event pseudo-occurrence condition that the event ID is 110 and the message includes the character string "test" is simulated Show.
[0085]
For example, when an event with an event ID of 100 occurs after the client 1 is activated, the client 1 can receive an event with an event ID of 100. In addition, even when an event with an event ID of 100 occurs first (in this case, an event with the event ID of 100 is saved), an event that occurs when the client 1 starts up and an event ID of 200 is started At this time, an event having an event ID of 100 is simulated based on the simulated event occurrence condition, and the simulated event can be received by the client 1.
[0086]
In the present embodiment, the example in which the event simulation occurrence condition is automatically generated mainly from the operation rule of the automatic driving system has been described. However, in some cases, this is not sufficient. In this case, the user can define a simulated event generation condition by describing a simulated generation condition definition file 1502 defined by the user.
[0087]
In this embodiment, for simplicity, one client is focused on one computer. However, the present invention is not limited to this, and the present invention is applied to a case where a plurality of processes operate on each computer. Also good. For example, the operation rule 1500 of FIG. 1 is provided for each process, and an event generated at the start of each process is registered in the file 1504, and the processing of FIG. 7 and FIG. In this case, the present invention can be applied to control of events exchanged between processes.
[0088]
Next, a second embodiment of the present invention will be described. The second embodiment shows a method for controlling the server activation event and the client activation event in the client server system so that no inconvenience occurs.
[0089]
FIG. 14 shows the system configuration of the second embodiment. In this system, a computer 15002 is connected to the communication line 15000. Further, an event service 15200 is provided on the computer 15002, and a server 15204 and a client 15206 are operating. In addition, an event control device 15202 that controls activation events of the server 15204 and the client 15206 is operating. At this time, the client 15206 receives an activation event of the server 15204 and starts its operation (use of a service provided by the server 15204). The event control device 15202 is the same device as the event control device 1202 of the first embodiment described above.
[0090]
In the system shown in FIG. 14, when the client 15206 is activated first, the server 15206 can receive a server activation event generated by the server 15204 activated later, and thus operates normally. However, when the server 15204 is activated first, the client 15206 activated later cannot receive the activation event of the server 15204. Therefore, the server 15204 waits for the activation event of the server 15204 indefinitely.
[0091]
Therefore, the event control device 15202 receives the activation event 15402 of the server 15204 (15400), stores the event, and stores the event when the client activation event 15406 activated later is received (15400). A startup event of the server 15204 is simulated (15404). The client 15206 receives the simulated event (15408). As a result, the client 15206 can receive an activation event of the server 15204 activated earlier even when activated later.
[0092]
FIG. 15 shows the flow of such processing in the event control apparatus 15202.
[0093]
After initialization (17000), it waits for an event to occur (17002), and checks whether the event that has occurred is a server start event (17300). If it is a server start event, it is checked whether it is a pseudo event that occurred in its own event control device 15202 (17302). If the received event is not a pseudo event, the server activation event is saved (17004), and the process returns to process 17002.
[0094]
If the event received in processing 17300 is not a server start event, it is checked whether it is a client start event (17304). If it is a client start event, it is checked whether a server start event has already been detected (17306), and if it has been detected, the server start event is saved, so a simulated server start event is generated ( 17006), the process returns to the process 17002. When it is not a client activation event in the process 17304, or when a server activation event is not stored in the process 17306, the process returns to the process 17002.
[0095]
Next, a third embodiment of the present invention will be described. This embodiment shows a method for realizing the server / client start event control method in the second embodiment described above by describing the operation rules of the automatic driving system. Before explaining the operation rule for performing such control, FIG. 16 shows an example in which the operation rule defines the content that the client starts using the service when a server activation event is received.
[0096]
In FIG. 16, a target event (13000) is a server start event, and a target operation (13004) is a client service use start command (a command for starting use of a server service). These events and commands are separated by a separator (13002). By specifying such operation rules, a client service use start command (13004) is executed when a server activation event (13000) occurs.
[0097]
FIG. 17 shows an example in which the control shown in the second embodiment is realized by the operation rule. In the present embodiment, a third process is executed in a computer system in which server and client processes are executed, and the third process (which can be regarded as an event control device) is the operation rule of FIG. Assuming that you are driving automatically according to
[0098]
The operation rule of FIG. 17 is described by the same notation as the operation rule of FIG. Reference numerals 14002 and 14014 denote separators (corresponding to 13002 in FIG. 16) that separate events and commands.
[0099]
In the operation rule of FIG. 17, when a client activation event is detected (14000), the occurrence of the event is recorded by creating a file (14004). If a server start event has already occurred (14006), a server start event is transmitted (simulated) (14008).
[0100]
On the other hand, when a server activation event is detected (14012), a file indicating server activation is created (14016), and if the client is already activated (14018), a command (14020) for starting the client service is executed.
[0101]
By defining such operation rules, even if the client is activated later, a server activation event that has occurred before can be simulated.
[0102]
【The invention's effect】
As described above, according to the present invention, the timing of occurrence of events, the number of occurrences, and the like can be automatically controlled. In addition, it is possible to easily specify that processing is performed when all of a plurality of events occur.
[0103]
In addition, since events to save event information are automatically selected, it is possible to reduce unnecessary use of computer resources and user trouble, and to reduce omissions and specification errors compared to the case of user specification. Can do.
[0104]
Furthermore, in a client-server system, even if the server is started before the client, it is possible to automatically send a server startup event to the client, thus eliminating restrictions on the startup order of the client and server. Can do.
[Brief description of the drawings]
FIG. 1 is a diagram showing an example of a system configuration of a first embodiment of the present invention.
FIG. 2 shows a flowchart of event detection means
FIG. 3 is a flowchart showing event storage condition detection means;
FIG. 4 is a diagram showing a flowchart of event management means
FIG. 5 is a view showing a flowchart of event simulation occurrence condition detection means;
FIG. 6 is a diagram showing a flowchart of event simulation generation means
FIG. 7 is a flowchart showing an event storage condition extraction algorithm;
FIG. 8 is a flowchart showing an event simulation occurrence condition extraction algorithm;
FIG. 9 is a flowchart showing an event simulation occurrence condition detection algorithm;
FIG. 10 is a diagram showing a command table for event management means
FIG. 11 is a table showing a list of events that occur when a client starts.
FIG. 12 is a diagram showing an example of an operation rule definition file
FIG. 13 is a diagram showing an example of generation of storage conditions and simulated generation conditions
FIG. 14 is a diagram showing control of event generation order in the server client system.
FIG. 15 is a flowchart showing a control procedure for an event generation order;
FIG. 16 is a diagram showing an example of operation rules
FIG. 17 is a diagram showing an implementation example based on operation rules;
[Explanation of symbols]
1000 ... computer, 1010 ... communication line, 1104 ... event service, 1100 ... automatic driving system, 1202 ... event control device, 1300 ... event detection means, 1302 ... event storage condition detection means, 1304 ... event management means, 1306 ... event simulation Occurrence condition detection means, 1308 ... event simulation generation means, 1310 ... event information, 1500 ... operation rule definition file, 1502 ... simulation occurrence condition definition file, 1504 ... event list file generated at client startup.

Claims (14)

計算機内で発生したイベントを取り扱うイベント制御装置であって、
前記計算機内で発生したイベントを検出するイベント検出手段と、
所定のイベント保存条件に従って、前記イベントのデータを保存するイベント管理手段と、
所定のイベント擬似発生条件に従って、前記イベントのデータに基づくイベントを擬似発生させるイベント擬似発生手段と
を備え
前記イベント保存条件として、所定の種類のイベントのみ保存させること、所定の数のイベントを保存させること、前記イベント擬似発生手段により所定の回数発生したイベントを保存させないこと、前記イベント擬似発生手段により発生した後一定時間を過ぎたイベントを保存させないことのうちの少なくともいずれか1つを条件とすることを特徴とするイベント制御装置。
An event control device that handles events that occur in a computer,
Event detection means for detecting an event occurring in the computer;
Event management means for storing the event data in accordance with predetermined event storage conditions;
An event simulation generation means for generating an event based on the event data in accordance with a predetermined event simulation generation condition ;
As the event storage condition, only a predetermined type of event is stored, a predetermined number of events are stored, an event that has occurred a predetermined number of times is not stored by the event simulation generation unit, and the event simulation generation unit generates An event control apparatus characterized in that at least one of the conditions for not storing an event after a predetermined time has been saved is a condition .
計算機内で発生したイベントを取り扱うイベント制御装置であって、
前記計算機内で発生したイベントを検出するイベント検出手段と、
所定のイベント保存条件に従って、前記イベントのデータを保存するイベント管理手段と、
所定のイベント擬似発生条件に従って、前記イベントのデータに基づくイベントを擬似発生させるイベント擬似発生手段と
を備え
前記イベント擬似発生条件は、所定の種類のイベントのみ発生させること、所定の数のイベントを発生させること、所定の順序でイベントを発生させること、イベント発生後所定の時間が経過したイベントを再び発生させること、所定の計算機内で発生したイベントであるときはイベントを発生させること、予め定められたイベントが発生したときに対応するイベントを発生させることのうちの少なくともいずれか1つを条件とすることを特徴とするイベント制御装置。
An event control device that handles events that occur in a computer,
Event detection means for detecting an event occurring in the computer;
Event management means for storing the event data in accordance with predetermined event storage conditions;
An event simulation generation means for generating an event based on the event data in accordance with a predetermined event simulation generation condition ;
The simulated event occurrence condition is to generate only a predetermined type of event, to generate a predetermined number of events, to generate events in a predetermined order, and to generate an event that has passed a predetermined time after the event has occurred. Or at least one of generating an event when the event occurs in a predetermined computer and generating a corresponding event when a predetermined event occurs An event control device characterized by that.
請求項1または2に記載のイベント制御装置であって、
前記イベント保存条件は、過去に発生したイベントに関する情報に基づき作成されることを特徴とするイベント制御装置。
The event control device according to claim 1 or 2 ,
The event control apparatus is characterized in that the event storage condition is created based on information on events that have occurred in the past.
請求項1または2に記載のイベント制御装置であって、
前記イベント管理手段は、イベントごとに実行すべき処理を示す運転ルールから前記イベント保存条件を抽出し、前記イベント保存条件に基づいて、前記イベントのデータを保存することを特徴とするイベント制御装置。
The event control device according to claim 1 or 2 ,
The event control unit, wherein the event management unit extracts the event storage condition from an operation rule indicating a process to be executed for each event, and stores the event data based on the event storage condition.
請求項1または2に記載のイベント制御装置であって、
前記イベント擬似発生条件は、過去に発生したイベントに関する情報に基づき作成されることを特徴とするイベント制御装置。
The event control device according to claim 1 or 2 ,
The event pseudo-occurrence condition is created based on information on events that have occurred in the past.
請求項1または2に記載のイベント制御装置であって、
前記イベント管理手段は、発生したイベントに対応して実行すべき処理を示す運転ルールから前記イベント擬似発生条件を抽出し、前記イベント擬似発生条件に基づいて、前記イベントを発生させることを特徴とするイベント制御装置。
The event control device according to claim 1 or 2 ,
The event management means is configured to extract the simulated event occurrence condition from an operation rule indicating a process to be executed in response to the generated event, and generate the event based on the simulated event occurrence condition. Event control device.
起動時にサーバ起動イベントを発生しクライアントに対しサービスを提供するサーバと、起動時にクライアント起動イベントを発生するとともに前記サーバ起動イベントを受けたとき前記サーバのサービスを利用開始するクライアントとを備えたクライアントサーバシステムにおけるイベント制御装置であって、
前記サーバが起動したときに発生される前記サーバ起動イベントを検出するサーバ起動イベント検出手段と、
前記サーバ起動イベント検出手段で検出したサーバ起動イベントを保存するサーバ起動イベント保存手段と、
前記クライアントが起動したときに発生される前記クライアント起動イベントを検出するクライアント起動イベント検出手段と、
前記クライアント起動イベント検出手段でクライアント起動イベントを検出したのを契機に、前記保存しておいたサーバ起動イベントを擬似発生して前記クライアントに送るサーバ起動イベント擬似発生手段と
を備えたことを特徴とするイベント制御装置。
A client server comprising: a server that generates a server startup event at startup and provides a service to the client; and a client that generates a client startup event at startup and starts using the service of the server when the server startup event is received An event control device in the system,
Server activation event detection means for detecting the server activation event generated when the server is activated;
Server activation event storage means for storing a server activation event detected by the server activation event detection means;
Client activation event detection means for detecting the client activation event generated when the client is activated;
And a server activation event simulation generating means for generating the stored server activation event and sending it to the client when the client activation event is detected by the client activation event detection means. Event control device.
計算機内で発生したイベントを取り扱うイベント制御方法であって、
前記計算機内で発生したイベントを検出するイベント検出ステップと、
所定のイベント保存条件に従って、前記イベントのデータを保存するイベント管理ステップと、
所定のイベント擬似発生条件に従って、前記イベントのデータに基づくイベントを擬似発生させるイベント擬似発生ステップと
を備え
前記イベント保存条件として、所定の種類のイベントのみ保存させること、所定の数のイベントを保存させること、前記イベント擬似発生ステップにより所定の回数発生したイベントを保存させないこと、前記イベント擬似発生ステップにより発生した後一定時間を過ぎたイベントを保存させないことのうちの少なくともいずれか1つを条件とすることを特徴とするイベント制御方法。
An event control method for handling events occurring in a computer,
An event detection step for detecting an event occurring in the computer;
An event management step for storing the data of the event according to a predetermined event storage condition;
An event simulation generation step for generating an event based on the event data in accordance with a predetermined event simulation generation condition ,
As the event storage condition, only a predetermined type of event is stored, a predetermined number of events are stored, an event that has occurred a predetermined number of times in the event simulation generation step is not stored, and the event simulation generation step occurs An event control method, characterized in that at least one of the following conditions is set to prevent an event that has passed a predetermined time from being stored .
計算機内で発生したイベントを取り扱うイベント制御方法であって、
前記計算機内で発生したイベントを検出するイベント検出ステップと、
所定のイベント保存条件に従って、前記イベントのデータを保存するイベント管理ステップと、
所定のイベント擬似発生条件に従って、前記イベントのデータに基づくイベントを擬似発生させるイベント擬似発生ステップと
を備え
前記イベント擬似発生条件は、所定の種類のイベントのみ発生させること、所定の数のイベントを発生させること、所定の順序でイベントを発生させること、イベント発生後所定の時間が経過したイベントを再び発生させること、所定の計算機内で発生したイベントであるときはイベントを発生させること、予め定められたイベントが発生したときに対応するイベントを発生させることのうちの少なくともいずれか1つを条件とすることを特徴とするイベント制御方法。
An event control method for handling events occurring in a computer,
An event detection step for detecting an event occurring in the computer;
An event management step for storing the data of the event according to a predetermined event storage condition;
An event simulation generation step for generating an event based on the event data in accordance with a predetermined event simulation generation condition ,
The simulated event occurrence condition is to generate only a predetermined type of event, to generate a predetermined number of events, to generate events in a predetermined order, and to generate an event that has passed a predetermined time after the event has occurred. Or at least one of generating an event when the event occurs in a predetermined computer and generating a corresponding event when a predetermined event occurs An event control method characterized by the above.
請求項8または9に記載のイベント制御方法であって、
前記イベント保存条件は、過去に発生したイベントに関する情報に基づき作成されることを特徴とするイベント制御方法。
The event control method according to claim 8 or 9, wherein
The event storage method is characterized in that the event storage condition is created based on information on events that have occurred in the past.
請求項8または9に記載のイベント制御方法であって、
前記イベント管理ステップは、イベントごとに実行すべき処理を示す運転ルールから前記イベント保存条件を抽出し、前記イベント保存条件に基づいて、前記イベントのデータを保存することを特徴とするイベント制御方法。
The event control method according to claim 8 or 9, wherein
The event management step is characterized in that the event storage condition is extracted from an operation rule indicating a process to be executed for each event, and the event data is stored based on the event storage condition.
請求項8または9に記載のイベント制御方法であって、
前記イベント擬似発生条件は、過去に発生したイベントに関する情報に基づき作成されることを特徴とするイベント制御方法。
The event control method according to claim 8 or 9, wherein
The event pseudo-generation condition is created based on information related to events that have occurred in the past.
請求項8または9に記載のイベント制御方法であって、
前記イベント管理ステップは、発生したイベントに対応して実行すべき処理を示す運転ルールから前記イベント擬似発生条件を抽出し、前記イベント擬似発生条件に基づいて、前記イベントを発生させることを特徴とするイベント制御方法。
The event control method according to claim 8 or 9, wherein
In the event management step, the simulated event occurrence condition is extracted from an operation rule indicating a process to be executed in response to the generated event, and the event is generated based on the simulated event occurrence condition. Event control method.
起動時にサーバ起動イベントを発生しクライアントに対しサービスを提供するサーバと、起動時にクライアント起動イベントを発生するとともに前記サーバ起動イベントを受けたとき前記サーバのサービスを利用開始するクライアントとを備えたクライアントサーバシステムにおけるイベント制御方法であって、
前記サーバが起動したときに発生される前記サーバ起動イベントを検出するサーバ起動イベント検出ステップと、
前記サーバ起動イベント検出ステップで検出したサーバ起動イベントを保存するサーバ起動イベント保存ステップと、
前記クライアントが起動したときに発生される前記クライアント起動イベントを検出するクライアント起動イベント検出ステップと、
前記クライアント起動イベント検出ステップでクライアント起動イベントを検出したのを契機に、前記保存しておいたサーバ起動イベントを擬似発生して前記クライアントに送るサーバ起動イベント擬似発生ステップと
を備えたことを特徴とするイベント制御方法。
A client server comprising: a server that generates a server startup event at startup and provides a service to the client; and a client that generates a client startup event at startup and starts using the service of the server when the server startup event is received An event control method in a system,
A server activation event detection step for detecting the server activation event that occurs when the server is activated;
A server activation event storage step for storing the server activation event detected in the server activation event detection step;
A client activation event detection step for detecting the client activation event generated when the client is activated;
A server activation event simulation generating step of simulating the stored server activation event and sending it to the client when a client activation event is detected in the client activation event detection step, Event control method to do.
JP2002340185A 2002-11-22 2002-11-22 Event control apparatus and event control method Expired - Fee Related JP3741371B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2002340185A JP3741371B2 (en) 2002-11-22 2002-11-22 Event control apparatus and event control method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2002340185A JP3741371B2 (en) 2002-11-22 2002-11-22 Event control apparatus and event control method

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP10316495A Division JP3418034B2 (en) 1995-04-04 1995-04-04 Event control device and event control method

Publications (2)

Publication Number Publication Date
JP2003228489A JP2003228489A (en) 2003-08-15
JP3741371B2 true JP3741371B2 (en) 2006-02-01

Family

ID=27751444

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002340185A Expired - Fee Related JP3741371B2 (en) 2002-11-22 2002-11-22 Event control apparatus and event control method

Country Status (1)

Country Link
JP (1) JP3741371B2 (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4912152B2 (en) * 2003-11-25 2012-04-11 インターナショナル・ビジネス・マシーンズ・コーポレーション Mobile hub and event management in mobile hub
JP2007172131A (en) * 2005-12-20 2007-07-05 Nec Fielding Ltd Failure prediction system, failure prediction method and failure prediction program

Also Published As

Publication number Publication date
JP2003228489A (en) 2003-08-15

Similar Documents

Publication Publication Date Title
US7508985B2 (en) Pattern-matching system
US20110307488A1 (en) Information processing apparatus, information processing method, and program
JP2006344171A (en) Information processing apparatus, control method thereof, computer program, and storage medium
US8433729B2 (en) Method and system for automatically generating a communication interface
EP1850250A1 (en) Method and system for renewing an index
JP3741371B2 (en) Event control apparatus and event control method
JPH07200312A (en) Digital data processing system and error processing method
JP2002123516A (en) System and method for evaluating web site and recording medium
JP4322763B2 (en) Document file copy movement monitoring system, method and program
JP3418034B2 (en) Event control device and event control method
KR100567813B1 (en) Transaction Analysing System for Tandem system
US8775528B2 (en) Computer readable recording medium storing linking keyword automatically extracting program, linking keyword automatically extracting method and apparatus
JP2009026029A (en) Transaction control device, transaction control method, transaction control program and storage medium with the program stored
JP7119411B2 (en) DATABASE DEVICE, DATA MANAGEMENT METHOD AND COMPUTER PROGRAM
KR101091071B1 (en) Method system and software for journaling system objects
JPH064346A (en) Break point managing device for debugger
JPH09274561A (en) Operating method for job and spool
JPH10240490A (en) Information processing equipment
EP0336585A2 (en) Error message display generation
JP2892663B2 (en) Autonomous failure diagnosis type analysis method
JPH0883223A (en) File management system
WO2011069837A1 (en) A method for processing trace data
JPH11191084A (en) Communication error data recording method, device therefor and recording medium
JP2001209526A (en) System and method for extracting system information in computer system
JPS63188242A (en) Production/control system for program error information

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20050801

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20050929

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20051104

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20051104

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20091118

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101118

Year of fee payment: 5

LAPS Cancellation because of no payment of annual fees