JP2004355265A

JP2004355265A - 処理統括装置、及び、処理判定方法

Info

Publication number: JP2004355265A
Application number: JP2003151311A
Authority: JP
Inventors: Masanori Furuya; 雅典古谷; Takashi Shimizu; 貴司清水; Satoshi Oyamada; 聡小山田; Nobuhiro Tanigawa; 延広谷川
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2003-05-28
Filing date: 2003-05-28
Publication date: 2004-12-16

Abstract

【課題】システムにおいて複雑に発生する異常等の状態に対する処理内容を、容易に変更することができる処理統括装置及び処理統括方法を提供する。
【解決手段】オペレーションシステム１を構成する汎用計算機１０において、業務プログラムが並列に実行されている最中に、報告すべき状態が発生した場合に、処理統括装置２０の検索機能２２１は、汎用計算機１０より受信した状態報告情報に関する受信タイミングに関する条件を内包する報告内容情報を、報告内容データベース２５より検索する。監視機能２２２は、検索された報告内容情報で表される、受信タイミングに関する条件が満たされるか否かを監視し、当該条件が満たされた場合に、処理内容通知部２３は、検索された報告内容情報に対応付けられている処理内容情報で表される処理内容を、汎用計算機１０に通知する。
【選択図】図１

Description

【０００１】
【発明の属する技術分野】
本発明は、コンピュータシステムにおいて発生する異常等の状態を管理する処理統括装置及び処理判定方法に関する。
【０００２】
【従来の技術】
従来より、通信ネットワークを監視・制御するためのシステムとして、汎用計算機を構成要素とするオペレーションシステムが知られている。近年では、通信ネットワークの規模が拡大するのに伴って、オペレーションシステムにおいて監視・制御すべき通信装置の数が増加してきている。この増加にオペレーションシステムを対応させるためには、汎用計算機の単位時間当たりの業務処理量（処理能力）を増大させることが必要となる。また、オペレーションシステムには、通信ネットワークの構成変更に伴う通信装置の数の増加・減少に対して、容易に対応可能な構成が求められる。
【０００３】
これらを実現させるために、オペレーションシステムにおいて、負荷分散処理方式、もしくは、機能分散処理方式を利用することが有効である。負荷分散処理方式とは、システムにおいて同時に複数の業務が発生した場合に、複数の汎用計算機で、各々の業務に関する処理を同時に実行することにより、負荷を分散させる方式である。また、機能分散処理方式とは、１つの業務が発生したときに、その業務を完了させるまでに必要な処理を分割し、分割した処理を複数の汎用計算機で実行することにより、全体の処理量を増大させる方式である。
【０００４】
このような機能分散方式や負荷分散方式を利用し、複数の汎用計算機を用いてオペレーションシステムを構築するには、１台の汎用計算機で構築するのに比較して、ソフトウェアを用いて複雑な処理を行う必要がある。
例えば、オペレーションシステムを構成する複数の汎用計算機を起動させた場合には、各々の汎用計算機全てが業務開始可能状態となった時点で、初めてシステムとして業務開始可能であると判断するためのソフトウェアが必要となる。また、１つの業務を完結させるために、複数台の汎用計算機間で、業務処理に必要な電文を、通信回線を介して送受信するためのソフトウェアが必要となる。
【０００５】
また、複数の汎用計算機で構成したシステムは、単一の汎用計算機で構成したシステムに比べて、異常が発生する箇所や発生ケースが多くなる。このため、特に、通信異常、処理異常、起動異常といった異常状態が発生した場合に、ソフトウェアを用いて行う、当該異常状態に対応するための処理（以下「異常処理」という）は複雑となる。
【０００６】
ソフトウェアを用いて異常処理を行う方法としては、検出された異常等の内容に基づいて、ソフトウェアに処理中止、再試行等の異常処理を判定させ実行させる方法がある（例えば、非特許文献１）。
一方、ファイルに登録された情報から、検出された状態に対する処理内容を判定して実行する技術が知られている（例えば、特許文献１）。特許文献１に記載されている技術では、処理条件ファイルや知識ベースファイル等のファイルに、運用ルール、経験則、過去の障害情報、解析方法等の情報を登録しておき、システムで異常等の状態が発生した場合に、コンピュータが、これらのファイルに登録された情報を基に、処理すべき内容を判定して実行する。
【０００７】
【非特許文献１】
松野良蔵著「Ｊａｖａ−ＣＯＲＢＡ分散オブジェクトシステム構築」飛翔社出版、１９９９年２月１５日、ＰＰ．４１−４７
【特許文献１】
特開平０６−１４９６２３号公報（段落０００４、００２２、００３２、図４、図５）
【０００８】
【発明が解決しようとする課題】
非特許文献１に記載の方法を用いて異常処理を行うためには、システム管理者は、予め異常の発生箇所や発生ケースを検討し、それぞれの異常が発生した場合にどのような異常処理を行うのかを設計し、その設計に基づいてソフトウェア中にロジックを組み込んでおく必要がある。このため、システム管理者は、異常処理に関するソフトウェアを維持管理するのに労力を要し、また、ソフトウェアのロジックの組み込みや変更に時間を要するという欠点があった。また、１つの異常が原因となって、複数の箇所で異常が発生するようなケースに対応する処理を、追加、変更、または削除（以下、「変更等」という）する場合には、より広範囲なソフトウェアの変更等が必要であり、異常処理の変更等が容易でないという欠点があった。また、広範囲なソフトウェアの変更等になるほど、発生した異常に対応した異常処理がどのようになっているのかがわかりにくく、容易にソフトウェアの変更等を行うことができないといった欠点があった。
【０００９】
一方、特許文献１の技術は、コンピュータが、経験則等の情報に基づいて、実行すべき処理内容を自動的に判定することを前提としている。従って、監視対象の構成変更等に伴って、システム管理者の設計に基づいて処理内容を変更等する必要がある場合に、どのファイルのどの情報をどのように変更すれば、処理内容が変更されるのかを簡単に把握できる仕組みにはなってはいない。このため、特許文献１の技術を用いたとしても、処理内容の変更等を容易に行うことができないという、上述した欠点は解決されない。
本発明は、上述した従来技術の欠点を解決するためになされたものであり、その目的は、システムで複雑に発生する異常等の状態に対する処理内容を、容易に変更等を行うことができる処理統括装置及び処理判定方法を提供することである。
【００１０】
【課題を解決するための手段】
上記課題を解決するために、請求項１に記載の発明は、コンピュータシステムが備えるプログラムの実行中に、報告すべき状態が発生した場合に、該コンピュータシステムから送信される状態報告情報に対して、前記コンピュータシステムが実行すべき処理内容を判定して該コンピュータシステムに通知する処理統括装置において、該処理統括装置は、前記状態報告情報と他の状態報告情報との受信タイミングに関する条件を表す報告内容情報と、前記受信タイミングに関する条件を満たした場合に実行すべき処理内容を表す処理内容情報と、を対応付けて格納し、外部からの入力により、それらの情報の追加、変更、及び、削除が自在なデータベースと、前記コンピュータシステムより一の状態報告情報を受信したときに、該一の状態報告情報についての前記受信タイミングに関する条件を内包する報告内容情報を、前記データベースより検索する検索手段と、前記検索手段により検索された報告内容情報で表される、前記受信タイミングに関する条件が満たされるか否かを監視する監視手段と、前記監視手段による監視中に前記受信タイミングに関する条件が満たされた場合には、前記報告内容情報に対応付けられている処理内容情報で表される処理内容を、前記コンピュータシステムに通知する処理内容通知手段とを有することを特徴とする。
【００１１】
請求項１に記載の発明によれば、前記コンピュータシステムにおいて複雑に発生する異常等の状態に対する処理内容を、前記データベースで一元管理し、前記処理統括装置が、前記状態報告情報の受信タイミングと前記データベースに格納されている情報とに基づいて、処理内容を判定するようにしたので、前記データベースに格納される情報を変更等するのみで、複雑に発生する異常等の状態に対する処理内容を、容易に変更等することができる。また、前記データベースに格納されている情報の変更等は、前記コンピュータシステムが稼動している状態でも容易に実施することができるため、前記コンピュータシステムの業務を停止する必要がなく、利便性がよい。
【００１２】
特に、前記報告内容情報は、前記状態報告情報と他の状態報告情報との受信タイミングに関する条件を表しているため、前記処理統括装置が、異なるタイミングで複数の状態報告情報を受信した場合にも、前記報告内容情報で表される受信タイミングに関する条件に基づいて、適切な処理内容情報を選択できる。このため、前記コンピュータシステム内の１つの箇所が故障して、その故障の影響により複数のソフトウェアで異常が検出される場合にも、前記処理統括装置は、適切な処理内容を判定することができる。
【００１３】
また、請求項２に記載の発明は、請求項１に記載の処理統括装置において、予め定められた時間を表す規定時間情報を記憶する規定時間記憶手段をさらに有し、前記報告内容情報に、時間を表す指定時間情報が内包されている場合には、前記受信タイミングに関する条件は、前記報告内容情報に内包される指定時間情報で表される時間を基準とする条件であり、前記報告内容情報に、前記指定時間情報が内包されていない場合には、前記受信タイミングに関する条件は、前記規定時間記憶手段に記憶されている規定時間情報で表される時間を基準とする条件であることを特徴とする。
【００１４】
請求項２に記載の発明によれば、前記受信タイミングに関する条件が満たされるか否かを判定するための基準とする時間として、前記処理統括装置の規定時間記憶手段に記憶された規定時間情報で表される時間を使用するよりも、別の時間を使用した方が、処理内容を適切に選択可能な場合には、システム管理者は、別の時間を、前記データベースの前記報告内容情報中に指定時間情報として記述することができる。これにより、前記処理統括装置は、前記受信タイミングに関する条件が満たされるか否かを判定する際に、前記指定時間情報を基準として判定することができるため、適切な処理内容を選択することができる。
【００１５】
また、請求項３に記載の発明は、請求項１又は２に記載の処理統括装置において、前記報告内容情報は、前記報告すべき状態と、前記受信タイミングに関する条件が満たされるか否かを判定するための基準となる時間との、少なくとも一方を含んだ論理積で記述されていることを特徴とする。
請求項３に記載の発明によれば、前記報告内容情報を、前記報告すべき状態と、前記受信タイミングに関する条件が満たされるか否かを判定するための基準となる時間との、少なくとも一方を含んだ論理積で記述するようにしたため、前記受信タイミングに関する条件が、前記状態報告情報を受信した後に前記他の状態報告情報を前記基準となる時間以内に受信する条件なのか、前記状態報告情報を受信した後に他の状態報告情報を前記基準となる時間以内に受信しない条件なのか、等を、システム管理者は、前記状態報告情報の記述を参照するだけで、容易に把握することができる。また、システム管理者は、前記論理積を用いて、複雑な前記受信タイミングに関する条件を、容易に記述することができる。
【００１６】
また、請求項４に記載の発明は、請求項１乃至３のいずれか１項に記載の処理統括装置において、受信した前記状態報告情報を蓄積するログ蓄積手段と、前記ログ蓄積手段により蓄積された前記状態報告情報を提示するログ提示手段とをさらに有することを特徴とする。
請求項４に記載の発明によれば、前記処理統括装置は、前記ログ蓄積手段により、受信した前記状態報告情報を蓄積し、前記ログ提示手段により、蓄積された前記状態報告情報を提示するので、システム管理者は、前記コンピュータシステムで発生した異常等の状態を一括して確認することができ、設計した通りに状態報告情報が前記コンピュータシステムより送信されてきているか、設計した通りではあるが設計漏れのために前記コンピュータシステムより送信されてきていないのか等を、容易に把握することが可能となる。
【００１７】
請求項５に記載の発明は、請求項１乃至４のいずれか１項に記載の処理統括装置において、外部からの指示により、前記データベースに格納された情報の少なくとも一部を提示する提示手段をさらに有することを特徴とする。
請求項５に記載の発明によれば、システム管理者の外部からの指示により、前記処理統括装置は、前記データベースに格納された情報を提示するため、システム管理者は、提示された情報を照会することにより、複雑な報告内容に対応する処理内容を、容易に把握、確認することができる。また、システム管理者は、提示された情報の内容を比較することにより、論理的におかしい、例えば、同じ報告内容に対応する処理内容が異なる等を、容易に把握できる。このように、システム管理者は、提示された情報を確認することで、前記データベースに格納されている情報の内容を正確に把握でき、処理内容の変更等を正確に行うことができる。
【００１８】
請求項６に記載の発明は、請求項１乃至５のいずれか１項に記載の処理統括装置において、前記コンピュータシステムは、複数のプログラムが並列に実行される分散システムであり、前記データベースに格納される処理内容情報には、前記処理内容を実行させるべきプログラムを識別するための情報がさらに含まれることを特徴とする。
【００１９】
請求項６に記載の発明によれば、前記処理統括装置は、前記分散システムで発生する異常等の状態を監視するのに好適な装置である。前記分散システムにおいては、複数の装置で複数のプログラムが並列に実行されるため、１つの箇所の故障により、複数のプログラムで異常状態が検出されて、複数の報告内容情報が送信される。このような場合にも、前記報告内容情報に、複数の前記状態報告情報についての受信タイミングに関する条件を記述できるため、前記処理統括装置は、適切な処理内容を選択することができる。また、前記処理統括装置は、実行すべきプログラムを識別するための情報を、前記コンピュータシステムに通知するので、前記コンピュータシステムは、並列に実行されている複数のプログラムのうち、どのプログラムの処理を実行するのかを認識することができる。
【００２０】
請求項７に記載の発明によれば、コンピュータシステムが備えるプログラムの実行中に、報告すべき状態が発生した場合に、該コンピュータシステムから送信される状態報告情報に対して、前記コンピュータシステムが実行すべき処理内容を判定して該コンピュータシステムに通知する処理判定方法において、該処理判定方法は、前記状態報告情報と他の状態報告情報との受信タイミングに関する条件を表す報告内容情報と、前記受信タイミングに関する条件を満たした場合に実行すべき処理内容を表す処理内容情報と、を対応付けて格納するデータベースに対して、外部からの入力により、それらの情報を追加する処理と、変更する処理と、削除する処理との、少なくとも一の処理を行う格納ステップと、前記コンピュータシステムより一の状態報告情報を受信したときに、該一の状態報告情報についての前記受信タイミングに関する条件を内包する報告内容情報を、前記データベースより検索する検索ステップと、前記検索ステップにおいて検索された報告内容情報で表される、前記受信タイミングに関する条件が満たされるか否かを監視する監視ステップと、前記監視ステップにおいて、前記受信タイミングに関する条件が満たされた場合には、前記報告内容情報に対応付けられている処理内容情報で表される処理内容を、前記コンピュータシステムに通知する処理内容通知ステップとを有することを特徴とする。
【００２１】
請求項７に記載の発明によれば、前記データベースに格納される情報を変更等した後に、該変更等された情報に基づいて発生した状態に対する処理内容を選択するという手順を踏むことができるため、容易に処理内容を変更して実行することができる。その他の作用、効果は請求項１と同様である。
【００２２】
【発明の実施の形態】
次に、図面を参照して、本発明の実施の一形態について説明する。なお、以下の説明において参照する各図においては、他の図と同等部分に同一符号が付されている。
［Ａ．システム全体の構成］
図１は、本発明の一実施形態に係るオペレーションシステム１全体の構成を示すブロック図である。オペレーションシステム１は、図示せぬ通信ネットワークが備える通信装置を、監視・制御するシステムである。同図に示されるように、オペレーションシステム１は、当該システム１における業務を実行するための汎用計算機１０と、当該システム１で発生した状態を管理するための処理統括装置２０と、これら装置間のデータの送受を中継する通信回線３０とを備えている。
【００２３】
［Ａ−１．処理統括装置の構成］
次に、処理統括装置２０の構成について説明する。
処理統括装置２０は、オペレーションシステム１で発生した異常等の状態を集中管理して、発生した状態に応じて異常処理等の処理内容を判定し、当該処理内容の実行指示を行うための装置である。
処理統括装置２０は、通常のコンピュータ装置のハードウェア構成を備えている。すなわち、処理統括装置２０は、プログラムを実行し処理統括装置２０全体を制御するＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）と、起動時に実行されるプログラムを記憶したＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）と、データを一時的に記憶するＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）と、各種データやプログラムを記憶するハードディスク装置と、各種情報を表示するためのディスプレイと、キーボード等からの操作信号をＣＰＵに出力するための操作部と、汎用計算機１０とのデータの授受を制御する通信インターフェイスとを備えている。
処理統括装置２０のハードディスク装置には、各種データやプログラムが記憶されている。
【００２４】
（Ａ−１−１．処理内容データベースの構成）
処理統括装置２０のハードディスク装置には、処理内容データベース２５が設けられている。図２には、処理内容データベース２５のデータ構成を示す。同図に示されるように、処理内容データベース２５に格納される情報は、「報告内容」を表す報告内容情報と、「処理内容」を表す処理内容情報とで構成される。
報告内容情報は、汎用計算機１０より、発生した状態を通知する状態報告情報を受信するときの、タイミングに関する条件を表している。
【００２５】
次に、具体的な「報告内容」の記述形式について説明する。
この「報告内容」は、（１）１つの状態として記述される場合と、（２）複数の状態の論理積として記述される場合と、（３）複数の状態と時間との論理積として記述される場合と、（４）状態の論理否定と、時間と、の論理積として記述される場合と、（５）状態と時間との論理積として記述される場合と、（６）複数の状態の論理和として記述される場合と、がある。
【００２６】
「報告内容」が１つの状態として記述される例としては、例えば、図２の（１）に示されるように、「報告内容」が１つの状態“異常ａ”のみで記述される場合がある。当該報告内容情報で表される受信タイミングに関する条件が満たされるためには、汎用計算機１０より、状態“異常ａ”が発生したことを通知する状態報告情報を受信すればよい。すなわち、「報告内容」が１つの状態として記述されている場合の受信タイミングに関する条件は、１つの状態報告情報を受信するとタイミングと同時に、他の状態報告情報を受信しないという条件であると考えればよい。
【００２７】
また、「報告内容」が複数の状態の論理積として記述される例としては、例えば、図２の（２）に示されるように、「報告内容」が状態“異常ｂ”と状態“異常ｃ”との論理積として記述される場合がある。当該報告内容情報で表される受信タイミングに関する条件が満たされるためには、状態“異常ｂ”の発生を通知するための状態報告情報を受信するタイミングと、状態“異常ｃ”の発生を通知するための状態報告情報を受信するタイミングとの差が、予め、処理統括装置２０で定められている規定時間以内であればよい。すなわち、一方の状態情報を受信してから、他方の状態情報を受信するタイミングが、予め、処理統括装置２０で定められた規定時間以内である場合に、論理積が真である（条件を満たす）と判定される。また、このように、「報告内容」に時間が記述されていない場合には、受信タイミングに関する条件を満たしているかを判定するための基準時間として、処理統括装置２０で予め定められた規定時間が用いられる。
【００２８】
一方、「報告内容」が複数の状態と時間との論理積として記述されている場合には、基準時間として、「報告内容」に記述されている時間が用いられる。
「報告内容」が、複数の状態と時間との論理積として記述される例としては、例えば、図２の（３）に示されるように、「報告内容」が“異常ｄ．ＡＮＤ．異常ｅ．ＡＮＤ．２０秒”と記述されている場合がある。この報告内容情報で表される受信タイミングに関する条件を満たすためには、状態“異常ｄ”の発生を通知するための状態報告情報を受信するタイミングと、状態“異常ｅ”の発生を通知するための状態報告情報を受信するタイミングとの差が、２０秒以内である必要がある。
【００２９】
また、「報告内容」を、状態の論理否定と、時間と、の論理積として記述することで、ある状態報告情報を受信してから、特定の、他の状態報告情報を受信しないタイミングを指定することもできる。例えば、図２の（４）に示されるように、「報告内容」が“異常ｄ．ＡＮＤ．ＮＯＴ（異常ｅ）．ＡＮＤ．２１秒”と記述されている場合には、当該報告内容情報で表される受信タイミングに関する条件を満たすためには、状態“異常ｄ”の発生を通知するための状態報告情報を受信してから、２１秒以内に、状態“異常ｅ”の発生を通知するための状態報告情報を受信しない（状態“異常ｅ”の発生を通知する状態報告情報を受信するとしても、状態“異常ｄ”の発生を通知するための状態報告情報を受信してから、２１秒経過後に受信する）必要がある。
【００３０】
また、「報告内容」を、１つの状態と時間との論理積として記述することで、１つの状態報告情報を受信してから、他の状態報告情報を全く受信しないタイミングに関する条件を指定することもできる。例えば、図２の（５）に示されるように、「報告内容」が“異常ｄ．ＡＮＤ．２５秒”と記述されている場合には、当該報告内容情報で表される受信タイミングに関する条件を満たすためには、状態“異常ｄ”の発生を通知するための状態報告情報を受信してから、２５秒以内に、他の状態報告情報を全く受信しない（他の状態報告情報を受信するとしても、状態“異常ｄ”の発生を通知するための状態報告情報を受信してから、２５秒経過後に受信する）必要がある。
【００３１】
また、「報告内容」が複数の状態情報の論理和として記述される例としては、例えば、図２の（６）に示されるように、「報告内容」が、状態“異常ｆ”と状態“異常ｇ”との論理和として記述される場合がある。当該報告内容情報で表される受信タイミングに関する条件を満たすためには、受信タイミングに関係なく、状態“異常ｆ”の発生を通知するための状態報告情報と、状態“異常ｇ” の発生を通知するための状態報告情報との、少なくとも一方の状態報告情報を受信すればよい。
【００３２】
次に、処理内容情報について説明する。処理内容情報は、報告内容情報で表される受信タイミングに関する条件が満たされた場合の、実行すべき処理内容を表している。処理内容情報は、「送信先」を表す送信先情報と「処理名」を表す処理名情報とで構成されている。ここでは、「送信先」は、プログラム名を表している。例えば、図２の（１）に示されるデータは、状態“異常ａ”を表す状態報告情報を受信した場合に実行すべき処理内容が、業務プログラムＢにおける再試行処理であることを表している。
【００３３】
また、図２の（４）や（６）に示されるように、「処理内容」は、１つの「報告内容」に対して複数指定することができる。複数指定した場合には、処理を指定した順に実行させることができる。例えば、図２の（６）に示される「処理内容」は、業務プログラムＡにおける処理続行の処理を行い、当該処理が完了した後に、業務プログラムＢにおける再試行の処理を行うことを表している。
【００３４】
また、処理統括装置２０のハードディスク装置には、状態報告ログ２４が設けられている。状態報告ログ２４は、汎用計算機１０より状態報告情報を受信したときに、当該状態報告情報で表される、発生した状態に関する情報を、ログとして蓄積しておくためのデータベースである。
また、ハードディスク装置には、規定時間記憶領域２６が設けられており、当該規定時間記憶領域２６には、予め設定された規定時間を表す規定時間情報が記憶されている。当該規定時間情報で表される規定時間は、前述したように、受信タイミングに関する条件が満たされるか否かを判定する際に、判定の基準として使用される時間である。
【００３５】
（Ａ−１−２．処理統括装置の機能構成）
また、処理統括装置２０のハードディスク装置には、処理統括装置２０の機能を実現させるための各種プログラムが記憶されている。処理統括装置２０のＣＰＵが、これらのプログラムを実行することにより、図１に示す、ログ蓄積部２１、判定部２２、処理内容通知部２３、ログ提示部２７、変更部２８、及び、提示部２９の機能が実現される。
【００３６】
次に、これらの機能について説明する。
ログ蓄積部２１は、汎用計算機１０より、発生した状態を通知するための状態報告情報を受信したときに、当該状態報告情報を状態報告ログ２４に蓄積すると共に、判定部２２に状態報告情報を受信したことを通知する。
判定部２２は、検索機能２２１と監視機能２２２とを備えている。
【００３７】
判定部２２の検索機能２２１は、受信した状態報告情報を基に、処理内容データベース２５に格納されているデータの中から、該当するデータを検索する。具体的には、検索機能２２１は、受信した状態報告情報についての、受信タイミングに関する条件を内包する報告内容情報を、処理内容データベース２５に格納されたデータの中から検索する。
【００３８】
判定部２２の監視機能２２２は、検索機能２２１で検索された報告内容情報で表される条件の内容を解析する。監視機能２２２は、検索された報告内容情報の中に、論理積を含む報告内容情報が存在する場合には、基準時間内に他の状態報告情報を受信することにより、或いは、基準時間内に他の状態報告情報を受信しないことにより、検索された報告内容情報で表される受信タイミングに関する条件が満たされる（論理積が真となる）か否かを監視する監視処理を行う。監視機能２２２は、監視処理中に、報告内容情報で表される受信タイミングに関する条件が満たされた場合には、当該報告内容情報に対応する処理内容情報を、処理内容通知部２３に送信する。
【００３９】
また、監視機能２２２は、検索機能２２１で検索された報告内容情報の中に、論理積を含む報告内容情報が存在しない場合、すなわち、報告内容情報が、１つの状態のみで記述されている場合、または、複数の状態の論理和で記述されている場合には、即座に、報告内容情報に対応する処理内容情報を、処理内容通知部２３に送信する。
【００４０】
処理内容通知部２３は、監視機能２２２より処理内容情報を受信すると、当該処理内容情報で表される、実行すべきプログラム名と処理名とを、汎用計算機１０に通知する。また、処理内容通知部２３は、処理内容情報に複数の処理内容情報が対応付けられているために、監視機能２２２より複数の処理内容情報を受信した場合には、処理順に、汎用計算機１０に処理内容を通知する。
また、ログ提示部２７は、操作部からの指示入力により、状態報告ログ２４に蓄積されている状態報告情報を、処理統括装置２０のディスプレイに表示する。
【００４１】
変更部２８は、操作部からの指示入力により、処理内容データベース２５に格納されるデータについての、追加、変更、及び、削除を自在に行う。具体的には、変更部２８は、操作部からの、特定のデータを削除するための指令を検知した場合には、処理内容データベース２５に格納されている当該特定のデータを削除する。また、変更部２８は、操作部からの、特定のデータを変更するための指令を検知した場合には、処理内容データベース２５に格納されている特定のデータを、入力された報告内容情報や処理内容情報で更新（変更）する。また、変更部２８は、操作部からの、データを追加するための指令を検知した場合には、入力された報告内容情報や処理内容情報を処理内容データベース２５に追加する。以上のように、変更部２８は、処理内容データベース２５に格納されるデータを、自在に、追加、変更、及び、削除する。
また、提示部２９は、操作部からの指示入力により、指示に合致した情報を、処理内容データベース２５より抽出して、図示せぬプリンタから印刷する。
【００４２】
［Ａ−２．汎用計算機の構成］
次に、汎用計算機１０の構成について説明する。
汎用計算機１０は、処理統括装置２０と同様に、通常のコンピュータのハードウェア構成を備えている。
汎用計算機１０のハードディスク装置には、各種プログラムが記憶されている。例えば、ハードディスク装置には、オペレーションシステム１における業務を実行するための、複数の業務プログラムが記憶されている。
【００４３】
また、これらの業務プログラムの実行を制御するためのプログラムとして、複数の業務プログラムを並列に実行するためのプログラムや、これらの業務プログラムが実行されている最中に報告すべき異常等の状態が検出された場合に、処理統括装置２０に状態報告情報を送信するためのプログラムや、汎用計算機１０が処理統括装置２０より処理内容の通知を受けた場合に、処理内容の実行指示を行うためのプログラム等が記憶されている。
ここで、報告すべき異常等の状態は、システム管理者によって予め設計され、プログラムに組み込まれている。ここでは、状態“異常ａ”、状態“異常ｂ”、状態“異常ｃ”、・・・・、状態“異常ｇ”が、報告すべき状態として設計されている。
【００４４】
汎用計算機１０のＣＰＵが、上述したプログラムを実行することにより、図１に示される、業務プログラム制御部１１が実現される。なお、同図においては、簡単のため、１つの業務プログラム制御部１１のみ表示しているが、実際には、各々の業務プログラムの実行を制御するための業務プログラム制御部が存在する。以下では、各々の業務プログラム制御部やこれらを構成する機能を、特に区別して説明する必要がある場合には、符号の末尾に“Ａ”、“Ｂ”、“Ｃ”、・・・、を付加して（例えば、業務プログラム実行部１１Ａ、業務プログラム実行部１１Ｂ、・・・）説明することとする。
【００４５】
（Ａ−２−１．業務プログラム制御部の機能構成）
次に、業務プログラム制御部１１の機能構成について説明する。
業務プログラム制御部１１は、業務実行機能１１１と、状態報告機能１１２と、処理内容受信機能１１３と、処理実行機能１１４とを備えている。
業務実行機能１１１は、業務プログラムを実行する。業務実行機能１１１は、当該業務プログラムを実行している最中に、報告すべき異常等の状態を検出した場合には、当該状態を検出したことを状態報告機能１１２に通知する。
【００４６】
状態報告機能１１２は、業務実行機能１１１より通知を受けた場合に、検出された状態を処理統括装置２０に通知するための状態報告情報を生成し、当該状態報告情報を処理統括装置２０に送信する。
処理内容受信機能１１３は、処理統括装置２０より、実行すべき処理内容の通知を受けると、当該処理内容を実行すべきことを、処理実行機能１１４に通知する。
処理実行機能１１４は、通知された処理内容を実行する。処理実行機能１１４は、処理の実行が完了すると、完了したことを表す処理完了通知情報を処理統括装置２０に送信する。
【００４７】
［Ａ−３．処理統括処理］
次に、状態報告情報を受信したときに、処理統括装置２０の各機能部が行う処理統括処理について、図３に示されるフローチャートを参照しながら説明する。
まず、ログ蓄積部２１は、状態報告情報を受信すると（ステップＳ２０１；Ｙｅｓ）、状態報告ログ２４に当該状態報告情報を蓄積する。
次に、判定部２２の検索機能２２１は、当該状態報告情報についての、受信タイミングに関する条件を内包する報告内容情報を、処理内容データベース２５より検索する（ステップＳ２０２）。ここで、検索機能２２１は、検索した結果、該当する報告内容情報が存在しなかった場合には、処理を終了する。
【００４８】
次に、判定部２２は、判定処理を行う。
まず、判定部２２の監視機能２２２は、ステップＳ２０２において検索された報告内容情報の中に、論理積“ＡＮＤ”を含むものが存在するか否かを判定する（ステップＳ２０３）。
検索された報告内容情報の中に、論理積“ＡＮＤ”を含む報告内容情報が存在しない場合には（ステップＳ２０３；Ｎｏ）、すなわち、報告内容が、１つの状態情報のみで記述されている場合、または、複数の状態報告情報の論理和“ＯＲ”で記述されている場合には、処理内容通知部２３は、報告内容情報に対応付けられている処理内容情報に基づいて、処理内容を通知するための処理内容通知情報を生成し、汎用計算機１０宛に送信する（ステップＳ２０９）。
【００４９】
一方、ステップＳ２０２で検索された報告内容情報の中に、論理積“ＡＮＤ”を含む報告内容情報が存在する場合には、監視機能２２２は、ステップＳ２０４〜Ｓ２０８の監視処理を行う。すなわち、監視機能２２２は、状態報告情報を受信した後に、受信する他の状態報告情報により、検索された報告内容情報で表される受信タイミングに関する条件が満たされるか否か（論理積が真となるか否か）を監視する。
【００５０】
具体的には、まず、監視機能２２２は、受信タイミングに関する条件が満たされるか否かを判定するために使用する基準時間を決定する。すなわち、監視機能２２２は、検索された報告内容情報に、時間を表す指定時間情報が含まれているかを判定し（ステップＳ２０４）、報告内容情報に指定時間情報が含まれている場合には（ステップＳ２０４；Ｙｅｓ）、監視機能２２２は、報告内容情報に内包されている指定時間情報で表される時間を、基準時間として使用することに決定する（ステップＳ２０５）。一方、検索された報告内容情報に、指定時間情報が含まれていない場合には（ステップＳ２０４；Ｎｏ）、処理統括装置２０の規定時間記憶領域２６に記憶されている規定時間情報を読み出し、当該規定時間情報で表される規定時間を、基準時間として使用することに決定する（ステップＳ２０６）。そして、監視機能２２２は、状態報告情報を受信してから基準時間内に、受信タイミングに関する条件を満たす状態報告情報を受信するのを監視する。或いは、監視機能２２２は、基準時間内に、当該条件を満たすための状態報告情報を受信しないのを監視する（ステップＳ２０７〜Ｓ２０８）。
【００５１】
ステップＳ２０７〜Ｓ２０８における監視中に、受信タイミングに関する条件が満たされた場合（基準時間内に状態報告情報を受信したために、または、基準時間内に状態報告情報を受信しなかったために、論理積が真となる条件が満たされた場合）には（ステップＳ２０７；Ｙｅｓ）、処理内容通知部２３は、報告内容情報に対応付けられている処理内容情報に基づいて、処理内容を通知するための処理内容通知情報を生成し、汎用計算機１０宛に送信する（ステップＳ２０９）。
【００５２】
なお、ステップＳ２０２において、複数の報告内容情報が検索された場合には、監視機能２２２は、検索された各々の報告内容情報毎に監視処理を行う。そして、監視機能２２２は、最も早く、受信タイミングに関する条件を満たした報告内容情報を処理対象として選択し、処理内容通知部２３は当該選択された報告内容情報に対応する処理内容情報に基づいて、処理内容を通知するための処理内容通知情報を生成する。
【００５３】
［Ｂ．動作］
次に、以上のような構成からなるオペレーションシステム１の動作について説明する。
前提として、システム管理者は、処理統括装置２０の操作部を操作して、報告内容情報や処理内容情報を入力している。これにより、変更部２８は、処理内容データベース２５に当該情報を追加する処理を行い、図２に示される内容の情報が、処理内容データベース２５に格納されているものとする。
また、処理統括装置２０の規定時間記憶領域２６には、予め、規定時間“３０秒”を表す規定時間情報が記憶されているものとする。
【００５４】
また、汎用計算機１０においては、業務プログラムＡと業務プログラムＢと業務プログラムＣとが並列に実行されており、業務プログラム制御部１１Ａが業務プログラムＡの実行を制御し、業務プログラム制御部１１Ｂが業務プログラムＢの実行を制御し、業務プログラム制御部１１Ｃが業務プログラムＣの実行を制御しているものとする。
【００５５】
（Ｂ−１．動作例１）
図４と図３とを参照しながら、業務プログラム制御部１１Ａが、報告すべき状態“異常ａ”の発生を検出した場合の動作について説明する。
まず、業務プログラム制御部１１Ａの業務実行機能１１１Ａは、業務プログラムＡを実行している最中に、状態“異常ａ”を検出する（図４のプロセスＰ１）。そして、業務実行機能１１１Ａは、状態“異常ａ”が発生したことを状態報告機能１１２Ａに通知する。
状態報告機能１１２Ａは、業務実行機能１１１Ａより通知を受けて、状態“異常ａ”が発生したことを通知するための状態報告情報Ｄ１を生成し、当該状態報告情報Ｄ１を処理統括装置２０に送信する（プロセスＰ２）。
【００５６】
処理統括装置２０のログ蓄積部２１は、状態報告情報Ｄ１を受信すると、状態報告ログ２４に状態“異常ａ”が発生したことを表す情報をログとして蓄積する（プロセスＰ３）。
次に、判定部２３は、判定処理を行う（プロセスＰ４）。
具体的には、判定部２３の検索機能２２１は、状態報告情報Ｄ１が状態“異常ａ”の発生を表していることから、当該状態“異常ａ”の受信タイミングに関する条件を内包する報告内容情報を、処理内容データベース２５より検索する（図３のステップＳ２０２）。
【００５７】
ここでは、図２（１）に示される、状態“異常ａ”を表す報告内容情報が検索される。
次に、判定部２３の検索機能２２１は、検索された報告内容情報に、論理積“ＡＮＤ”が含まれているか否かを判定する（ステップＳ２０３）。
ここでは、（１）に示される報告内容情報には、論理積“ＡＮＤ”は含まれていないため、（ステップＳ２０３；Ｎｏ）、処理内容通知部２３は、（１）の報告内容情報に対応付けられている処理内容情報を基に、業務プログラムＢに再試行処理を指示するための処理内容通知情報Ｄ２を生成する。そして、検索機能２２１は、当該処理内容通知情報Ｄ２を汎用計算機１０宛に送信する（図３のステップＳ２０９、図４のプロセスＰ５）。
【００５８】
業務プログラム制御部１１Ｂの処理内容受信部１１３Ｂは、処理内容通知情報Ｄ２を受信し（図４のプロセスＰ６）、業務プログラムＢにおける再試行処理を実行すべきことを、処理実行部１１４Ｂに通知する。処理実行部１１４Ｂは、通知を受けて、再試行処理を実行する（プロセスＰ７）。処理実行部１１４Ｂは、再試行処理が完了すると、再試行処理が完了したことを通知するための完了通知情報Ｄ３を、処理統括装置２０に送信する。
【００５９】
処理統括装置２０の処理内容通知部２３は、完了通知情報Ｄ３を受信して、次に通知すべき処理内容が存在するかを判断する。ここでは、（２）に示される報告内容情報に対応付けられている処理内容情報は１つであるため、次に通知すべき処理内容は存在せず、処理統括装置２０は処理を終了する。
【００６０】
（Ｂ−２．動作例２）
次に、図５と図３とを参照しながら、業務プログラム制御部１１Ａが、報告すべき状態“異常ｂ”の発生を検出し、その後、業務プログラム制御部１１Ｂが、報告すべき状態“異常ｃ”の発生を検出した場合の動作について説明する。
このとき、処理統括装置２０は、状態“異常ｂ” の発生を通知するための状態報告情報を受信してから、１０秒後のタイミングで、状態“異常ｃ” の発生を通知するための状態報告情報を受信したものとする。
まず、業務プログラム制御部１１Ａの業務実行機能１１１Ａは、業務プログラムＡの実行中に、状態“異常ｂ”が発生したことを検出し（図５のプロセスＰ１１）、状態“異常ｂ”が発生を検出したことを、状態報告機能１１２Ａに通知する。
【００６１】
状態報告機能１１２Ａは、業務実行機能１１１Ａより通知を受けて、状態“異常ｂ”が発生したことを通知するための状態報告情報Ｄ１０を生成し、当該状態報告情報Ｄ１０を処理統括装置２０に送信する（プロセスＰ１２）。
処理統括装置２０のログ蓄積部２１は、状態報告情報Ｄ１０を受信すると、状態報告ログ２４に状態“異常ｂ”が発生したことを表す情報をログとして蓄積する（プロセスＰ１３）。
【００６２】
次に、判定部２３は、判定処理を行う（プロセスＰ１４）。
具体的には、判定部２３の検索機能２２１は、状態報告情報Ｄ１０が状態“異常ｂ”の発生を表していることから、当該状態“異常ｂ”の受信タイミングに関する条件を内包する報告内容情報を、処理内容データベース２５より検索する（図３のステップＳ２０２）。
【００６３】
ここでは、図２の（２）に示される、“異常ｂ．ＡＮＤ．異常ｃ”を表す報告内容情報が検索される。
次に、判定部２３の検索機能２２１は、検索された報告内容情報に、論理積“ＡＮＤ”を表す情報が含まれているか否かを判定する（ステップＳ２０３）。
ここでは、（２）の報告内容情報には、論理積“ＡＮＤ”を表す情報が含まれているため（ステップＳ２０３；Ｙｅｓ）、監視機能２２２は、（２）の報告内容情報で表される受信タイミングに関する条件が満たされるのを監視する（監視処理；ステップＳ２０４〜Ｓ２０８）。
【００６４】
具体的には、まず、監視機能２２２は、受信タイミングに関する条件が満たされるか否かを判定するために使用する基準時間を決定する。すなわち、監視機能２２２は、検索された（２）の報告内容情報に、時間を表す情報が含まれているか否かを判定する（ステップＳ２０４）。ここでは、（２）の“異常ｂ．ＡＮＤ．異常ｃ”で表される報告内容情報には、時間を表す情報が含まれていないため（ステップＳ２０４；Ｎｏ）、監視機能２２２は、処理統括装置２０の規定時間記憶領域２６に記憶されている規定時間情報を読み出す。そして、監視機能２２２は、当該規定時間情報で表される規定時間“３０秒”を、基準時間として使用することに決定する（ステップＳ２０６）。
【００６５】
そして、監視機能２２２は、（２）の報告内容情報を基に、状態“異常ｂ”が発生したことを通知する状態報告情報を受信してから、状態“異常ｃ”が発生したことを通知する状態報告情報を受信するタイミングが３０秒以内である場合に“異常ｂ．ＡＮＤ．異常ｃ”が真となる、すなわち、報告内容情報で表される受信タイミングに関する条件が満たされることを解析する。そして、監視機能２２２は、状態報告情報Ｄ２０を受信してから基準時間“３０秒”以内に、状態“異常ｃ”の発生を通知する状態報告情報が送信されてくるか否かを監視する（監視処理；ステップＳ２０７〜Ｓ２０８）。
【００６６】
ここでは、上述の通り、業務実行機能１１１Ａが状態“異常ｂ”の発生を検出した後に、業務実行機能１１１Ｂが状態“異常ｃ”の発生を検出する。
業務実行機能１１１Ｂは、状態“異常ｃ”の発生を検出すると（図５のプロセスＰ１５）、当該検出内容を状態報告機能１１２Ｂに通知する。状態報告機能１１２Ｂは、通知を受けて、状態“異常ｃ”の発生を通知するための状態報告情報Ｄ１１を生成し、当該状態報告情報Ｄ１１を処理統括装置２０に送信する（プロセスＰ１６）。
【００６７】
監視機能２２２は、上述の通り、状態“異常ｂ” の発生を通知する状態報告情報Ｄ１０を受信してから、１０秒後のタイミングで、状態“異常ｃ” の発生を通知する状態報告情報Ｄ１１を受信する。すなわち、状態報告情報Ｄ１０を受信してから状態報告情報Ｄ１１を受信する受信タイミングが、基準時間である３０秒以内であるため、監視機能２２２は、（２）の報告内容情報で表される受信タイミングに関する条件が満たされたと判定する（図３のステップＳ２０７；Ｙｅｓ）。そして、処理内容通知部２３は、（２）の報告内容情報に対応する処理内容情報を基に、業務プログラムＣに処理続行処理を指示するための処理内容通知情報Ｄ１２を生成する。そして、処理内容通知部２３は、当該処理内容通知情報Ｄ１２を、汎用計算機１０宛に送信する（図３のステップＳ２０９、図５のプロセスＰ１７）。
【００６８】
業務プログラム制御部１１Ｃの処理内容受信機能１１３Ｃは、処理内容通知情報Ｄ１２を受信し（図５のプロセスＰ１８）、当該処理内容通知情報Ｄ１２の内容より、業務プログラムＣにおける処理続行処理を実行する指示を受けたことを、処理実行機能１１４Ｃに通知する。処理実行機能１１４Ｃは、当該通知を受けて、処理続行処理を行う（プロセスＰ１９）。処理実行機能１１４Ｃは、処理が完了すると、完了通知情報Ｄ１３を、処理統括装置２０に送信する。
【００６９】
処理統括装置２０の処理内容通知部２３は、完了通知情報Ｄ１３を受信して、次に通知すべき処理内容が存在するかを判断する。ここでは、（２）の報告内容情報に対応付けられている処理内容情報は１つであり、次に通知すべき処理内容は存在しないため、処理統括装置２０は処理を終了する。
（Ｂ−３．動作例３）
次に、図６と図３とを参照しながら、業務プログラム制御部１１Ａが報告すべき状態“異常ｄ”の発生を検出し、その後、業務プログラム制御部１１Ｂが報告すべき状態“異常ｅ”の発生を検出した場合の動作について説明する。
【００７０】
このとき、処理統括装置２０は、状態“異常ｄ”の発生を通知するための状態報告情報を受信してから、２６秒後のタイミングで、状態“異常ｅ”の発生を通知するための状態報告情報を受信したものとする。
まず、業務プログラム制御部１１Ａの業務実行機能１１１Ａは、業務プログラムＡの実行中に、状態“異常ｄ”の発生を検出する（図６のプロセスＰ２１）。そして、業務実行機能１１１Ａは、状態“異常ｄ”の発生を検出したことを状態報告機能１１２Ａに通知する。
【００７１】
状態報告機能１１２Ａは、業務実行機能１１１Ａより通知を受けて、状態“異常ｄ”が発生したことを通知するための状態報告情報Ｄ２０を生成し、当該状態報告情報Ｄ２０を処理統括装置２０に送信する（プロセスＰ２２）。
処理統括装置２０のログ蓄積部２１は、状態報告情報Ｄ２０を受信すると、状態報告ログ２４に状態“異常ｄ”が発生したことを表す情報をログとして蓄積する（プロセスＰ２３）。
【００７２】
次に、判定部２３は、判定処理を行う（プロセスＰ２４）。
具体的には、判定部２３の検索機能２２１は、受信した状態報告情報Ｄ２０が、状態“異常ｄ”が発生したことを表していることから、当該状態“異常ｄ”の受信タイミングに関する条件を内包する報告内容情報を、処理内容データベース２５より検索する（図３のステップＳ２０２）。
【００７３】
ここでは、図２の（３）に示される“異常ｄ．ＡＮＤ．異常ｅ．ＡＮＤ．２０秒”と、（４）に示される“異常ｄ．ＡＮＤ．ＮＯＴ（異常ｅ）．ＡＮＤ．２１秒”と、（５）に示される“異常ｄ．ＡＮＤ．２５秒”とを表す報告内容情報が検索される。
次に、判定部２３の検索機能２２１は、検索された報告内容情報に、論理積“ＡＮＤ”を表す情報が含まれているか否かを判定する（ステップＳ２０３）。
【００７４】
ここでは、（３）、（４）、（５）全ての報告内容情報に、論理積“ＡＮＤ”を表す情報が含まれているため（ステップＳ２０３；Ｙｅｓ）、監視機能２２２は、（３）、（４）、（５）各々の報告内容情報について、受信タイミングに関する条件が満たされるか否かを監視する（監視処理；ステップＳ２０４〜Ｓ２０８）。
【００７５】
具体的には、まず、監視機能２２２は、受信タイミングに関する条件が満たされるか否かを判定するために使用する基準時間を決定するために、（３）、（４）、（５）の報告内容情報に、時間を表す情報が含まれているか否かを判定する（ステップＳ２０４）。ここでは、（３）、（４）、（５）全ての報告内容情報に、時間を表す情報が含まれているため（ステップＳ２０４；Ｙｅｓ）、監視機能２２２は、（３）、（４）、（５）全てについて、報告内容情報に含まれている時間を、基準時間として使用することに決定する（ステップＳ２０５）。すなわち、監視機能２２２は、（３）の“異常ｄ．ＡＮＤ．異常ｅ．ＡＮＤ．２０秒”については、基準時間として２０秒を使用し、（４）の“異常ｄ．ＡＮＤ．ＮＯＴ（異常ｅ）．ＡＮＤ．２１秒”については、基準時間として“２１秒”を使用し、（５）の“異常ｄ．ＡＮＤ．２５秒”については、基準時間として“２５秒”を使用する。
【００７６】
そして、監視機能２２２は、（３）の受信タイミングに関する条件を満たすために、状態報告情報Ｄ２０を受信してから２０秒以内に、状態“異常ｅ”の発生を通知する状態報告情報が送信されてくることを監視する。また、監視機能２２２は、（４）の受信タイミングに関する条件を満たすために、状態報告情報Ｄ２０を受信してから２１秒以内に、状態“異常ｅ”の発生を通知する状態報告情報が送信されてこないのを監視する（すなわち、この場合の受信タイミングに関する条件を満たす事象としては、状態報告情報Ｄ２０を受信してから２１秒以内に状態“異常ｅ”の発生を通知する状態報告情報を受信せず、当該状態報告情報を受信したとしても２１秒を超えたタイミングで受信した場合である）。また、監視機能２２２は、（５）の受信タイミングに関する条件を満たすために、状態報告情報Ｄ２０を受信してから２５秒以内に、全く状態報告情報が送信されてこないのを監視する（すなわち、この場合の受信タイミングに関する条件を満たす事象としては、状態報告情報Ｄ２０を受信してから２５秒以内に何も状態報告情報を受信せず、何らかの状態報告情報を受信したとしても、２５秒を超えたタイミングで受信した場合である）。（ステップＳ２０７〜Ｓ２０８）
【００７７】
ここでは、上述の通り、業務実行機能１１１Ａが状態“異常ｄ”の発生を検出した後に、業務実行機能１１１Ｂが状態“異常ｅ”の発生を検出する。業務実行機能１１１Ｂは、状態“異常ｅ”の発生を検出すると（図５のプロセスＰ２５）、当該検出内容を状態報告機能１１２Ｂに通知する。状態報告機能１１２Ｂは、通知を受けて、状態“異常ｅ”の発生を通知するための状態報告情報Ｄ２１を生成し、当該状態報告情報Ｄ２１を処理統括装置２０に送信する（プロセスＰ２６）。そして、上述の通り、処理統括装置２０は、状態“異常ｄ” の発生を通知する状態報告情報Ｄ２０を受信してから、２６秒後のタイミングで、状態“異常ｅ”の発生を通知する状態報告情報Ｄ２１を受信する。
【００７８】
従って、状態報告情報Ｄ２０を受信してから２０秒経過した時点では、処理統括装置２０は、何も状態報告情報を受信しないため、判定部２２の監視機能２２２は、（３）の報告内容情報で表される受信タイミングに関する条件“異常ｄ．ＡＮＤ．異常ｅ．ＡＮＤ．２０秒”は満たされないと判定する（図３のステップＳ２０７；Ｎｏ、ステップＳ２０８；Ｙｅｓ）。
【００７９】
状態報告情報Ｄ２０を受信してから２１秒経過した時点でも、処理統括装置２０は、状態報告情報を受信しないため、判定部２２の監視機能２２２は、（４）の報告内容情報で表される受信タイミングに関する条件“異常ｄ．ＡＮＤ．ＮＯＴ（異常ｅ）．ＡＮＤ．２１秒”が満たされたと判定する（ステップＳ２０７；Ｙｅｓ）。
【００８０】
状態報告情報Ｄ２０を受信してから２５秒経過した時点でも、処理統括装置２０は、状態報告情報を受信しないため、（５）の報告内容情報で表される受信タイミングに関する条件“異常ｄ．ＡＮＤ．２５秒”も満たされるが、（４）の報告内容情報で表される条件が満たされる時間の方が早いため、（４）が選択される。
【００８１】
そして、処理内容通知部２３は、（４）の報告内容情報に対応する処理内容情報に基づいて、処理内容を汎用計算機１０宛に通知する（図３のステップＳ２０９）。具体的には、ここでは、（４）の報告内容情報には、２つの処理内容情報が対応付けられているため、処理内容通知部２３は、まず、「送信先」“業務プログラムＣ”、「処理名」“処理中止”で表される処理内容情報に基づいて、業務プログラムＣに処理中止の処理を指示するための処理内容通知情報Ｄ２２を生成して送信する（図６のプロセスＰ２７）。
【００８２】
業務プログラム制御部１１Ｃの処理内容受信機能１１３Ｃは、処理内容通知情報Ｄ２２を受信し（プロセスＰ２８）、当該処理内容通知情報Ｄ２２の内容より、業務プログラムＣにおける処理中止処理の実行指示を受けたことを、処理実行機能１１４Ｃに通知する。処理実行機能１１４Ｃは、当該通知を受けて、処理中止の処理を行う。処理実行機能１１４Ｃは、処理が完了すると、完了通知情報Ｄ２３を、処理統括装置２０に送信する（プロセスＰ２９）。
【００８３】
処理統括装置２０の処理内容通知部２３は、完了通知情報Ｄ２３を受信して、次に通知すべき処理内容が存在するかを判断する。ここでは、（４）の報告内容情報に対応付けられている、もうひとつの処理内容情報（「送信先」“業務プログラムＣ”、「処理名」“再起動”）が存在するため、当該処理内容情報に基づいて、業務プログラムＣに再起動処理を指示するための処理内容通知情報Ｄ２４を生成して送信する（図６のプロセスＰ３０）。
【００８４】
業務プログラム制御部１１Ｃの処理内容受信機能１１３Ｃは、処理内容通知情報Ｄ２４を受信し（プロセスＰ３１）、当該処理内容通知情報Ｄ２４の内容より、業務プログラムＣにおける再起動処理の実行指示を受けたことを、処理実行機能１１４Ｃに通知する。処理実行機能１１４Ｃは、当該通知を受けて、再起動処理を実行する。処理実行機能１１４Ｃは、処理が完了すると、完了通知情報Ｄ２５を、処理統括装置２０に送信する（プロセスＰ３２）。
【００８５】
処理統括装置２０の処理内容通知部２３は、完了通知情報Ｄ２５を受信して、次に通知すべき処理内容が存在するかを判断する。ここでは、（４）の報告内容情報に対応付けられている、未送信の処理内容情報は存在しないため、処理内容通知部２３は処理を終了する。
【００８６】
［Ｃ．変形例］
以上、本発明の実施形態について説明したが、本発明は係る実施形態に限定されるものではなく、その技術思想の範囲内で様々な変形が可能である。変形例としては、例えば、以下のようなものが考えられる。
（１）上記実施形態においては、オペレーションシステム１は、汎用計算機１０と、処理統括装置２０とが、通信回線３０で接続されて構成されているとして説明したが、装置構成はこれに限定されず、例えば、オペレーションシステム１が１台の汎用計算機で構成されていて、この１台の汎用計算機が、上記実施形態における汎用計算機１０と処理統括装置２０との機能を併せ持っていてもよい。
【００８７】
また、オペレーションシステム１は、複数の汎用計算機１０と処理統括装置２０とが、専用線やインターネット等で接続されている構成でもよい。このような装置構成の場合には、複数の汎用計算機１０と処理統括装置２０との間の通信には、ＣＯＲＢＡ（ＣｏｍｍｏｎＯｂｊｅｃｔＲｅｑｕｅｓｔＢｒｏｋｅｒＡｒｃｈｉｔｅｃｔｕｒｅ）通信を利用するとよい。ＣＯＲＢＡ通信を利用すれば、処理内容情報の「送信先」として、業務プログラムを識別するための論理的な名前（オブジェクト名）を使用することで、業務プログラムがどの汎用計算機１０に配置されているかを意識せずに通信を行うことが可能となる。
【００８８】
また、上記実施形態においては、本発明を、オペレーションシステム１に適用した例について説明したが、これに限定されず、本発明は、複数のプログラムが並列に実行される分散環境のシステムであって、システムを停止せずに稼動状態で処理内容の変更等を行うことができると都合のよいシステムに適用すると有効である。
【００８９】
（２）上記実施形態における処理内容データベース２５のデータ構成やデータの記述形式、記述の表す意味内容は一例であり、これに限定されない。
例えば、上記実施形態においては、「報告内容」の受信タイミングに関する条件の記述形式は、論理和や論理積の形式で記述できるとして説明したが、これに限定されない。例えば、論理積や論理和を使用せずに、受信タイミングに関する条件を文章で記述できるようにしてもよい。
【００９０】
また、各々の記述が意味する内容は一例であり、例えば、上記実施形態においては、「報告内容」を“ａ．ＡＮＤ．ｂ．ＡＮＤ．５秒”と記述した場合に、当該記述で表される内容は、“状態ａと状態ｂとを表す報告内容情報を受信するタイミングの差が５秒以内”という条件であるとしたが、これに限定されず、例えば、当該記述に、報告内容情報を受信する順番の意味をもたせて、“状態ａを受信してから状態ｂを受信するタイミングが５秒以内（右側に記述された状態を表す報告内容を先に受信する）”という条件が表されるようにしてもよい。
【００９１】
また、上記実施形態においては、「報告内容」が、論理積で記述されていない場合、例えば、“異常ａ”のように、１つの状態で記述されている場合には、状態“異常ａ”が発生したことを通知する状態報告情報を受信すると、即座に受信タイミングに関する条件が満たされるとしたが、これに限定されず、「報告内容」が論理積で記述されていない場合にも、規定時間記憶領域２６に記憶されている規定時間情報で表される規定時間以内に、他の状態報告情報を受信しないことで受信タイミングに関する条件が満たされると判定するようにしてもよい。
【００９２】
また、上記実施形態においては、図３のステップＳ２０２で、複数の報告内容情報が検索された場合には、監視機能２２２は、監視処理において、最先に、受信タイミングに関する条件が満たされた報告内容情報に対応する処理内容情報のみを選択して、１つの処理内容のみを実行指示するとしたが、これに限定されず、例えば、監視処理において条件を満たした全ての報告内容情報に対応する処理内容を実行指示するようにしてもよい。
【００９３】
（３）上記実施形態においては、提示部２９が、処理内容データベース２５に格納されているデータをプリンタで印刷することによって、システム管理者が処理内容データベース２５に格納されているデータを一覧形式で確認できるようにしたが、処理内容データベース２５に格納されているデータを提示する方法はこれに限定されない。例えば、処理統括装置２０のディスプレイに処理内容データベース２５に格納されているデータを一覧表示するようにしてもよいし、一覧表示する際に、システム管理者が表示対象データを検索、指定できるようにしてもよい。また、処理内容データベース２５に格納されているデータを音声に変換して、処理統括装置２０に設けられたスピーカより音声出力するようにしてもよい。
【００９４】
また、上記実施形態においては、変更部２８は、操作部からの指示入力により、処理内容データベース２５に格納されるデータについての、追加、変更、及び、削除を自在に行うとして説明したが、データを変更等する方法は、操作部からの指示入力に限らず、例えば、変更用のデータを一括して処理統括装置２０に投入することにより、変更部２８が、処理内容データベース２５に格納されるデータを、バッチ処理で一括変更するようにしてもよい。
【００９５】
【発明の効果】
以上説明したように、本発明によれば、システムにおいて複雑に発生する異常等の状態に対する処理内容をデータベースで一元管理し、処理統括装置が、状態報告情報の受信タイミングに基づいて、データベースに格納されている情報から処理内容を判定するようにしたので、データベースに格納されている情報を変更するのみで、システムで複雑に発生する異常等の状態に対する処理内容を容易に変更することができる。
特に、データベースで管理されている報告内容情報は、状態報告情報と他の状態報告情報との受信タイミングに関する条件を表しているため、処理統括装置が、異なるタイミングで複数の状態報告情報を受信した場合にも、報告内容情報で表される受信タイミングに関する条件に基づいて、適切な処理内容を選択できる。
【図面の簡単な説明】
【図１】本発明の実施形態に係るオペレーションシステムの構成を示すブロック図である。
【図２】本発明の実施形態に係る処理内容データベースのデータ構成を示す図である。
【図３】本発明の実施形態に係る処理統括処理を説明するためフローチャートである。
【図４】本発明の実施形態に係る動作例１を説明するためのシーケンスチャートである。
【図５】本発明の実施形態に係る動作例２を説明するためのシーケンスチャートである。
【図６】本発明の実施形態に係る動作例３を説明するためのシーケンスチャートである。
【符号の説明】
１オペレーションシステム
１０汎用計算機
１１業務プログラム制御部
１１１業務実行機能
１１２状態報告機能
１１３処理内容受信機能
１１４処理実行機能
２０処理統括装置
２１ログ蓄積部
２２判定部
２２１検索機能
２２２監視機能
２３処理内容通知部
２４状態報告ログ
２５処理内容データベース
２６規定時間記憶領域
２７ログ提示部
２８変更部
２９提示部
３０通信回線

Claims

コンピュータシステムが備えるプログラムの実行中に、報告すべき状態が発生した場合に、該コンピュータシステムから送信される状態報告情報に対して、前記コンピュータシステムが実行すべき処理内容を判定して該コンピュータシステムに通知する処理統括装置において、
前記状態報告情報と他の状態報告情報との受信タイミングに関する条件を表す報告内容情報と、前記受信タイミングに関する条件を満たした場合に実行すべき処理内容を表す処理内容情報と、を対応付けて格納し、外部からの入力により、それらの情報の追加、変更、及び、削除が自在なデータベースと、
前記コンピュータシステムより一の状態報告情報を受信したときに、該一の状態報告情報についての前記受信タイミングに関する条件を内包する報告内容情報を、前記データベースより検索する検索手段と、
前記検索手段により検索された報告内容情報で表される、前記受信タイミングに関する条件が満たされるか否かを監視する監視手段と、
前記監視手段による監視中に前記受信タイミングに関する条件が満たされた場合には、前記報告内容情報に対応付けられている処理内容情報で表される処理内容を、前記コンピュータシステムに通知する処理内容通知手段と
を有することを特徴とする処理統括装置。
予め定められた時間を表す規定時間情報を記憶する規定時間記憶手段をさらに有し、
前記報告内容情報に、時間を表す指定時間情報が内包されている場合には、
前記受信タイミングに関する条件は、前記報告内容情報に内包される指定時間情報で表される時間を基準とする条件であり、
前記報告内容情報に、前記指定時間情報が内包されていない場合には、
前記受信タイミングに関する条件は、前記規定時間記憶手段に記憶されている規定時間情報で表される時間を基準とする条件である
ことを特徴とする請求項１に記載の処理統括装置。
前記報告内容情報は、前記報告すべき状態と、前記受信タイミングに関する条件が満たされるかを判定するための基準となる時間との、少なくとも一方を含んだ論理積で記述されていることを特徴とする請求項１又は２に記載の処理統括装置。
受信した前記状態報告情報を蓄積するログ蓄積手段と、
前記ログ蓄積手段により蓄積された前記状態報告情報を提示するログ提示手段と
をさらに有することを特徴とする請求項１乃至３のいずれか１項に記載の処理統括装置。
外部からの指示により、前記データベースに格納された情報の少なくとも一部を提示する提示手段をさらに有することを特徴とする請求項１乃至４のいずれか１項に記載の処理統括装置。
前記コンピュータシステムは、複数のプログラムが並列に実行される分散システムであり、
前記データベースに格納される処理内容情報には、前記処理内容を実行させるべきプログラムを識別するための情報がさらに含まれる
ことを特徴とする請求項１乃至５のいずれか１項に記載の処理統括装置。
コンピュータシステムが備えるプログラムの実行中に、報告すべき状態が発生した場合に、該コンピュータシステムから送信される状態報告情報に対して、前記コンピュータシステムが実行すべき処理内容を判定して該コンピュータシステムに通知する処理判定方法において、
前記状態報告情報と他の状態報告情報との受信タイミングに関する条件を表す報告内容情報と、前記受信タイミングに関する条件を満たした場合に実行すべき処理内容を表す処理内容情報と、を対応付けて格納するデータベースに対して、外部からの入力により、それらの情報を追加する処理と、変更する処理と、削除する処理との、少なくとも一の処理を行う格納ステップと、
前記コンピュータシステムより一の状態報告情報を受信したときに、該一の状態報告情報についての前記受信タイミングに関する条件を内包する報告内容情報を、前記データベースより検索する検索ステップと、
前記検索ステップにおいて検索された報告内容情報で表される、前記受信タイミングに関する条件が満たされるか否かを監視する監視ステップと、
前記監視ステップにおいて、前記受信タイミングに関する条件が満たされた場合には、前記報告内容情報に対応付けられている処理内容情報で表される処理内容を、前記コンピュータシステムに通知する処理内容通知ステップと
を有することを特徴とする処理判定方法。