JP2005055961A - タスク間通信プログラム及びタスク間通信方法 - Google Patents

Abstract

【課題】タスクの追加・削除に容易に対処でき、しかもイベントデータの受信側で当該データを適切に処理できるようにする。
【解決手段】汎用ＯＳが動作する計算機において、当該汎用ＯＳが起動されると、スケジューラサービス１２が起動される。スケジューラサービス１２は、グローバル設定ファイル２６に設定されているスケジューラリストに従い、当該リストの示すスケジューラ１１−１〜１１−ｎを起動する。起動されたスケジューラ１１−１〜１１−ｎはタスクからの接続待ち状態となる。ここで、例えばスケジューラ１１−１がスケジューラＡＰＩ１３を介してタスクから接続され、しかる後に当該タスクからのイベントデータを受信したものとすると、当該スケジューラ１１−１は、イベント処理のトリガとなるトリガ情報が設定されたシナリオファイル２３に従って当該受信イベントデータを処理する。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、汎用オペレーティングシステム環境でのタスク間通信に好適なタスク間通信プログラム及びタスク間通信方法に関する。
【０００２】
【従来の技術】
近年、マルチタスクオペレーティングシステム（ＯＳ）の普及に伴い、アプリケーションプログラムによって実現されるタスク間での通信を主とするタスク間制御が新たな課題となってきている。またシステム運用後、当該システムで実現する機能の変更・拡張のために、新規タスクの追加、既存タスクの削除が発生する可能性もある。
【０００３】
そこで、タスクの追加・削除に容易に対処し得るタスク間通信を実現するために、タスク間の通信を制御するシステム制御タスクを用意し、当該システム制御タスクを除く一般のタスク（以下、単にタスクと称する場合には、システム制御タスクを除く一般のタスクを表すものとする）は、当該システム制御タスクとの間でのみ通信を行い、他のタスクへの通信は当該システム制御タスクが代わって行うタスク処理システムが提案されている（例えば、特許文献１参照）。
【０００４】
特許文献１に記載されたタスク処理システム（タスク間通信システム）では、システム制御タスクはシステム制御テーブルを有している。このシステム制御テーブルには、各タスクから送信されるメッセージの種類（メッセージ番号、つまりメッセージ識別子）に対応付けて当該メッセージの出力先タスクを指定する情報が設定されている。システム制御タスクは、タスクから受信したメッセージのメッセージ種類によりシステム制御テーブルを参照し、当該メッセージ種類に対応して設定されている出力先の情報の指定するタスクに対し、当該受信メッセージに対応する出力メッセージを送信する。このようなシステムでは、システム制御テーブル上で、メッセージ種類と出力先との関係を追加・変更するだけで、タスクの追加・削除に容易に対処できる。
【０００５】
【特許文献１】
特開平６−９５８９６号公報（段落０００８〜００１４，００２２、図４、図８）
【０００６】
【発明が解決しようとする課題】
上記したように、システム制御テーブルに従ってシステム制御タスクがタスク間の通信を制御する従来技術では、システム制御テーブル上で、メッセージ種類と出力先との関係を追加・変更することにより、タスクの追加・削除に対処できる。つまり、タスクの追加・削除が発生しても、システム制御テーブルを操作するだけで、あるタスクからのメッセージ（イベントデータ）を目的のタスクに送信できる。
【０００７】
しかし、上記従来技術では、あるタスクからのメッセージ（イベントデータ）を、複数のタスクに対し、当該複数のタスクがそれぞれ理解可能なメッセージ種類（イベント識別子）のメッセージ（イベントデータ）として送信することは考慮されていない。このため従来技術では、あるタスクからの例えば第１の種類（イベント識別子）のメッセージ（イベントデータ）を、システム制御タスクが他の複数のタスクに送信したとしても、送信先のタスクの中に新規タスクが存在し、且つ当該新規タスクが第２の種類（イベント識別子）のメッセージ（イベントデータ）しか処理できない場合には、当該新規タスクではメッセージを適切に処理できない。また、このような新規タスクに対して、複数のタスクからのメッセージ（イベントデータ）をシステム制御タスクが送信した場合、当該メッセージ（イベントデータ）の種類（イベント識別子）によっては、適切に処理できないこともある。
【０００８】
本発明は上記事情を考慮してなされたものでその目的は、タスクの追加・削除に容易に対処でき、しかもイベントデータの受信側で当該データを適切に処理できるタスク間通信プログラム及びタスク間通信方法を提供することにある。
【０００９】
【課題を解決するための手段】
本発明の１つの観点によれば、汎用オペレーティングシステム（ＯＳ）が動作する計算機を、タスクとの間でイベントデータによる通信が可能な少なくとも１つのスケジューラとして機能させるためのタスク間通信プログラムが提供される。上記スケジューラは、タスクからのイベントデータの受信時には、受信イベント識別子が設定されると共に当該受信イベント識別子に対応付けて送信イベント識別子及びイベントデータの送信先となるタスクを指定する送信先アプリケーション識別子が設定可能な、イベント処理のトリガとなるトリガ情報が記録されたシナリオファイルを参照して、受信イベントデータのイベント識別子に一致する受信イベント識別子を含むトリガ情報を全て検出する手段と、この検出手段によって検出されたトリガ情報をもとに、当該トリガ情報に少なくとも上記送信先アプリケーション識別子が設定されていることを受信イベントデータの送信条件として、当該条件の成立または不成立を判定する手段と、この判定手段により送信条件成立が判定された場合に、上記検出手段によって検出されたトリガ情報に設定されている送信先アプリケーション識別子の示すタスクへ上記受信イベントデータを送信し、その際に当該イベントデータのイベント識別子を、当該トリガ情報に送信イベント識別子が設定されているか否かに応じて当該送信イベント識別子に置き換える送信手段とを備えている。
【００１０】
このような構成のタスク間通信プログラムによれば、汎用オペレーティングシステムの起動時に自動的に起動されるスケジューラにより、イベント処理のトリガとなるトリガ情報が設定されたシナリオファイルに従って受信イベントが処理されるため、タスク間通信を非同期で容易に行うことが可能となる。また、タスクの機能追加・削除（新規タスクの追加・既存タスクの削除）が必要な場合でも、シナリオファイルを書き換えるだけで容易に対応可能である。特に、シナリオファイルの中から検出されたトリガ情報に送信イベント識別子が設定されている場合には、当該トリガ情報に設定されている送信先アプリケーション識別子の示すタスクへ受信イベントデータを送信する際に、当該イベントデータのイベント識別子が当該送信イベント識別子に置き換えられる。このため、イベントデータの送信側のタスク（特に新規タスク）は、送信先のタスクだけでなく、当該送信先タスクが処理可能なイベント識別子をも意識する必要がない。また、送信先（受信側）のタスク（特に新規タスク）には、シナリオファイルに従って、スケジューラから当該タスクで処理可能なイベント識別子のイベントデータを送ることが可能なため、当該イベントデータを適切に処理することが可能となる。
【００１１】
また、上記トリガ情報に、受信イベント識別子に対応付けて起動すべきタスクを指定する起動タスク情報が設定可能な構成とし、上記検出されたトリガ情報に起動タスク情報が設定されている場合には、当該トリガ情報に送信先アプリケーション識別子が設定されているか否かと無関係に、送信条件不成立として処理し、当該起動タスク情報で指定されるタスクを起動するとよい。このようにすると、シナリオファイルの設定により、所望のタスクからのイベントデータをトリガとして所望の１つまたは複数のタスクを起動することができる。
【００１２】
また、上記タスク間通信プログラムにより、上記計算機を、上記汎用ＯＳの起動時に、上記少なくとも１つのスケジューラを指定するリスト（スケジューラリスト）が設定されたグローバル設定ファイルに従って当該スケジューラを起動するスケジューラサービス手段として更に機能させる構成とするとよい。このようにすると、汎用ＯＳの起動時に少なくとも１つのスケジューラ（つまり１つまたは複数のスケジューラ）を自動的に起動できる。
【００１３】
また、上記タスク間通信プログラムにより、上記計算機を、タスクからの要求により上記スケジューラと汎用通信プロトコルにより接続する特定アプリケーションプログラムインタフェースとして更に機能させる構成とするとよい。このようにすると、ユーザはタスクの機能追加・削除等が必要な場合、汎用通信プロトコルの知識等がなくても容易に対応可能である。またタスクの改造期間も短縮できる。特に、上記特定アプリケーションプログラムインタフェースが、タスクからの要求に従ってスケジューラとの接続のための汎用のオブジェクト間通信インタフェースを当該タスクに提供し、当該タスクにより生成される汎用の通信オブジェクトに応じて上記スケジューラとの接続または上記スケジューラからの切断を行う構成とするならば、タスクは、汎用オブジェクト間通信インタフェースを介して共通の仕様の上で通信を行うことが可能である。特に、種類の異なる複数の汎用のオブジェクト間通信インタフェースを提供するならば、タスクの開発環境や開発言語に依存せずにスケジューラを利用可能となる。
【００１４】
【発明の実施の形態】
以下、本発明の実施の形態につき図面を参照して説明する。
図１は本発明の一実施形態に係るタスク間通信システムのソフトウェア構成を示すブロック図である。図１のシステムは、汎用のマルチタスクオペレーティングシステム（以下、汎用ＯＳと称する）が動作するパーソナルコンピュータ（以下、ＰＣと称する）上に実現されるものとする。
【００１５】
図１において、スケジューラ１１−１（＃１），１１−２（＃２），…１１−ｎ（＃ｎ）は、複数のタスクと通信を行うスケジューラ部を構成する。この通信には、例えばＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）と呼ばれる汎用通信プロトコルが使用される。スケジューラ１１−ｉ（ｉ＝１〜ｎ）は後述するスケジューラサービス１２により起動され、タスクの接続待ち状態に遷移する。スケジューラ１１−ｉは当該スケジューラ１１−ｉと接続されたたとえば複数のタスク（アプリケーションプログラム）との間で、後述する各種の設定ファイル（アプリケーション登録ファイル２１、スケジューラ設定ファイル２２、シナリオファイル２３、共有変数定義ファイル２４及びセマフォ定義ファイル２５）を利用して非同期に通信する。ここで、ＴＣＰ／ＩＰを用いたスケジューラ１１−ｉとタスクとの間の通信は、スケジューラ側をサーバモード、タスク側をクライアントモードで使用する、クライアント／サーバ接続形態で行われる。
【００１６】
図１では、スケジューラ１１−１（＃１）の通信相手となるタスクがタスク２０−１（＃１）〜２０−３（＃３）であることが示されている。タスク２０−ｊ（ｊ＝１〜３）は、スケジューラ１１−１と同一ＰＣ上に存在しても、当該ＰＣとネットワークを介して接続された他のＰＣ上に存在しても、スケジューラ１１−１と通信（送受信）可能である。
【００１７】
スケジューラサービス１２は、当該スケジューラサービス１２が存在するＰＣへのインストール時に当該ＰＣ上で動作する汎用ＯＳ１０（図２参照）のサービス機能に登録される。このサービス機能とは、当該サービス機能に登録されたソフトウェアを、汎用ＯＳ１０の立ち上がり時に自動的に起動する機能である。したがって、スケジューラサービス１２が汎用ＯＳ１０のサービス機能に登録されることにより、当該スケジューラサービス１２は、ＰＣ（上の汎用ＯＳ１０）の次回起動時からは、自動的に起動される。
【００１８】
スケジューラサービス１２は起動後、ユーザの入力操作により設定された、少なくとも１つのスケジューラを（スケジューラ名により）指定するスケジューラリスト（スケジューラ名リスト）を含むグローバル設定ファイル２６に従い、当該スケジューラリストで指定される全てのスケジューラ（図１ではスケジューラ１１−１〜１１−ｎ）を認識し、当該スケジューラの起動／停止／リセットを管理する機能を有する。スケジューラサービス１２はまた、汎用ＯＳ１０のシステムツールであるイベントビューアへのログを出力する機能を有する。
【００１９】
図２は、スケジューラサービス１２の起動と、それに伴うスケジューラ１１−１〜１１−ｎの起動とを説明するための図である。図２に示すように、スケジューラサービス１２は、汎用ＯＳ１０の立ち上がり時に起動される（ステップＳ１）。スケジューラサービス１２が起動すると、当該スケジューラサービス１２によりスケジューラ１１−１〜１１−ｎが起動される（ステップＳ２−１〜２−ｎ）。
【００２０】
スケジューラＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ：アプリケーションプログラムインタフェース）１３は、スケジューラ１１−ｉ（図１ではスケジューラ１１−１）を使用してタスク間通信を実現するためのインタフェースである。スケジューラＡＰＩ１３は、タスクがソケット等を直接操作することなくスケジューラ１１−ｉの機能を容易に使用可能とするために用意される。
【００２１】
そのため、スケジューラＡＰＩ１３は、ＤＬＬ（Ｄｙｎａｍｉｃ Ｌｉｎｋ Ｌｉｂｒａｒｙ）として作成され、スケジューラ１１−ｉとの接続のための汎用のオブジェクト間通信インタフェースをタスクに提供する。ここでは特に、タスクの開発環境や開発言語に依存せずにスケジューラ１１−ｉの機能が利用できるように、複数種類、例えば２種類の汎用オブジェクト間通信インタフェースがタスクに提供される。汎用のオブジェクト間通信インタフェースとしては、例えば、米国マイクロソフト社が策定したオブジェクト間通信規約に従うＣ＋＋言語向けＣＯＭ（Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）オブジェクト、或いは当該マイクロソフト社が開発したＶＢ（Ｖｉｓｕａｌ Ｂａｓｉｃ）言語向けＡｃｔｉｖｅＸオブジェクトが知られている。タスクは汎用オブジェクト間通信インタフェースに適合する複数のスケジューラオブジェクト（通信オブジェクト）を生成することにより同時に複数のスケジューラ１１−ｉと通信することができる。つまりタスクは、汎用オブジェクト間通信インタフェースを介して共通の仕様の上で通信を行うことが可能である。このため、タスクの機能追加・削除（新規タスクの追加・既存タスクの削除）が必要となった場合でも、汎用オブジェクト間通信インタフェースの仕様を理解すれば、後述するデータフォーマットのアプリケーション登録ファイル２１（図１５参照）を変更するだけで、容易に対応可能となる。ここではユーザ（タスクの開発者）は、ＴＣＰ／ＩＰの知識等は不要である。またタスクの改造期間の短縮を図ることも可能である。
【００２２】
タスクは、上記したようにクライアントとして位置付けられる。タスクは、スケジューラＡＰＩ１３が用意するプロパティに当該タスクのアプリケーションＩＤを設定することで、当該タスクをスケジューラ１１−ｉに認識させる。
【００２３】
スケジューラＡＰＩ１３は以下の機能を有する。
【００２４】
ａ）起動時にスケジューラ１１−ｉの制御のもとで、シナリオファイル２３により指定される、自身に接続されるクライアント（タスク）の設定を行う機能。
【００２５】
ｂ）スケジューラ１１−ｉとの接続と切断をスケジューラオブジェクトにより行う機能、当該スケジューラ１１−ｉと通信するタスクのアプリケーションＩＤの認証処理を行う機能。ここでは、ＴＣＰ／ＩＰの直接の操作をタスクが考慮する必要はない。また、タスク間通信にＴＣＰ／ＩＰプロトコル（汎用通信プロトコル）を適用することにより、送信エラーやリトライをタスクレベルで考慮する必要がない。その理由は、ＴＣＰ／ＩＰプロトコルを搭載しているＰＣが自動で制御を行うためである。
【００２６】
ｃ）イベント（イベントデータ）の送受信を行う機能。このイベントの送受信により、イベントデータオブジェクト（スケジューラオブジェクト）を介してタスクとの通信が行われる。タスクがコールバックを設定することによりイベント受信時に非同期通知イベントを発生させることが可能である。
【００２７】
ｄ）スケジューラ１１−ｉが生成した共有変数を参照または更新する機能（共有変数アクセス機能）
ｅ）スケジューラ１１−ｉにより生成されたセマフォを使用してタスク間の排他制御（セマフォ操作）を行う機能。
【００２８】
ｆ）シナリオファイル２３の設定に従うスケジューラ１１−ｉの制御にもとで他のタスクを起動させる機能。この機能により起動されたタスクは自身が起動されるトリガとなったイベントデータを取得する手段を提供する。
【００２９】
ｇ）クライアント設定ファイル２７に従って、スナップ（ログ）を作成し、後述するクライアントログファイル３２（図３参照）に出力する機能。
【００３０】
スケジューラ１１−ｉはスケジューラ管理ツール１４により管理される。スケジューラ管理ツール１４は、スケジューラ１１−ｉの運用を支援する目的で用意されるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）アプリケーションである。スケジューラ管理ツール１４は、当該管理ツール１４が存在するＰＣ上のスケジューラ１１−ｉだけでなく、当該ＰＣとネットワーク接続される他のＰＣ上のスケジューラも管理可能である。スケジューラ管理ツール１４は、
ａ）スケジューラサービス１２の起動と停止
ｂ）各スケジューラ１１−ｉの運用状態の監視
ｃ）各スケジューラ１１−ｉの起動と停止とリセット
ｄ）各タスクのスケジューラ１１−ｉとの接続状況の監視
ｅ）各タスクのスナップレベルの設定
の各機能を有する。スケジューラ管理ツール１４によるスケジューラ１１−ｉのリセット処理は、当該スケジューラ１１−ｉに（スケジューラＡＰＩ１３を介して）接続されている全てのタスクへのリセット通知を行い、接続中のＴＣＰ／ＩＰを切断することにより実現される。この場合、スケジューラ管理ツール１４は、スケジューラ１１−ｉにより生成されているセマフォを解放し、当該スケジューラ１１−ｉを終了した後に、再度起動を行う。
【００３１】
タスク２０−ｊはアプリケーションプログラムであり、スケジューラＡＰＩ１３を使用してスケジューラ１１−ｉ（例えばスケジューラ１１−１）との接続を行う。タスク２０−ｊは、スケジューラ１１−ｉとの接続後、当該スケジューラ１１−ｉを介して他のタスクとイベントの通信を行う。タスク２０−ｊは、他のタスクとの通信終了後は切断要求を発行してスケジューラ１１−ｉとの通信を終了する。
【００３２】
図３は上記スケジューラ１１−１〜１１−ｎが存在するＰＣにおけるディレクトリ構成の一例を示す。図３において、ログ格納ディレクトリ３０により管理されるスケジューラログファイル３１−１，３１−２は、例えば図１中のスケジューラ１１−１，１１−２で行った処理のログを書き込むのに用いられる。同様に、クライアントログファイル３２は、スケジューラＡＰＩ１３で行った処理のログを書き込むのに用いられる。このログファイル３１−１，３１−２，３２等へのスナップあるいはイベントログの収集により、トラブル発生時の対応や原因究明が速やかに行える。
【００３３】
図４は図１の構成のソフトウェア及び各ファイルが存在するＰＣのハードウェア構成を示すブロック図である。図４のＰＣは、ＣＰＵ４１、主メモリ４２、ディスク装置４３及びネットワークインタフェース４４を含む周知のハードウェア構成を有している。ＣＰＵ４１、主メモリ４２、ディスク装置４３及びネットワークインタフェース４４はバス４５により相互接続されている。
【００３４】
主メモリ４２には、汎用ＯＳ１０、スケジューラ１１−１〜１１−ｎ、スケジューラサービス１２、スケジューラＡＰＩ１３及びタスク２０−１〜２０−３を含むタスク群（アプリケーション群）が、ＣＰＵ４１により実行可能なように、例えばディスク装置４３からロードされている。スケジューラ１１−１〜１１−ｎ、スケジューラサービス１２及びスケジューラＡＰＩ１３は、例えばＣＤ−ＲＯＭ、フレキシブルディスクまたはメモリカード等の記憶媒体により提供され、当該記憶媒体を図４のＰＣに設けられたＣＤ−ＲＯＭ装置、フレキシブルディスク装置、カードスロット等に装着して、当該記憶媒体から読み取ってディスク装置４３に転送することにより当該ディスク装置４３に記録される。また、上記スケジューラ１１−１〜１１−ｎ、スケジューラサービス１２及びスケジューラＡＰＩ１３をネットワークを介して図１のＰＣに転送することも可能である。
【００３５】
ディスク装置４３には、アプリケーション登録ファイル２１、スケジューラ設定ファイル２２、シナリオファイル２３、共有変数定義ファイル２４、セマフォ定義ファイル２５、グローバル設定ファイル２６及びクライアント設定ファイル２７を含むファイル群が記録されている。これらのファイル群は少なくとも１つの記憶媒体により提供され、当該記憶媒体が装着される読み取り装置を介してディスク装置４３に記録（保存）される。また、上記ファイル群をユーザの入力操作で他のＰＣ上で作成し、当該ファイル群を図１のＰＣにネットワークを介して転送することにより、ディスク装置４３に記録することも可能である。
【００３６】
図５はスケジューラサービス１２により使用されるグローバル設定ファイル２６（ファイル名：ｇｌｏｂａｌ．ｉｎｉ）のデータフォーマットを示す。図５において、斜体文字の部分はユーザの入力操作により設定可能な箇所である。グローバル設定ファイル２６には、スケジューラサービス１２が管理するスケジューラ１１−ｉのスケジューラ名のリスト（ＳｃｈｅｄｕｌｅｒＬｉｓｔ）５１と、当該リスト５１中のスケジューラ名で指定されるスケジューラ１１−ｉに割り当てるＴＣＰポート番号（ＴｃｐＰｏｒｔ）５２とが設定可能である。グローバル設定ファイル２６の一例を図６に示す。
【００３７】
図７はスケジューラ１１−ｉにより使用されるスケジューラ設定ファイル２２（ファイル名：Ｓｃｈｅｄｕｌｅｒ．ｉｎｉ）のデータフォーマットを示す。図７において、斜体文字の部分はユーザの入力操作により設定可能な箇所である。スケジューラ設定ファイル２２には、運用ログに書き込むべきログ事象（スナップ内容）を指定するためのログ書き込みレベル（ＬｏｇＬｅｖｅｌ）７１と、運用ログへのデータダンプの書き込み方法を示す書き込み制御値（ＬｏｇＤａｔａ）７２とが設定可能である。
【００３８】
各ログ事象にはその重要度に応じてレベル（０〜４２９４９６７２９５）が予め設定されている。ここでは、重要度が高いログ事象ほど、高レベルとなっており、スケジューラ設定ファイル２２に設定されたログ書き込みレベル７１以上のレベルのログ事象だけが運用ログへの書き込みの対象となる。ログ書き込みレベル７１が０の場合は全てのログ事象が書き込まれる。ログ書き込みレベル７１は省略可能であり、省略時は０として扱われる。書き込み制御値７２には０〜２のいずれかが適用可能であり、それぞれ次の書き込み方法
０：データダンプは書き込まない
１：全データ書き込む
２：データ長が所定バイト（例えば５１２バイト）より大きい場合は最初と最後のそれぞれ所定バイトの半分（２５６バイト）のみを書き込む
を定義する。書き込み制御値７２は省略可能であり、省略時は１として扱われる。スケジューラ設定ファイル２２の一例を図８に示す。
【００３９】
図９はスケジューラ１１−ｉにより使用されるシナリオファイル２３（ファイル名：ｓｃｅｎａｒｉｏ．ｃｓｖ）の１レコードのデータフォーマットを示す。シナリオファイル２３は少なくとも１つのレコードを有する。このシナリオファイル２３中のレコードには、桁＃１（Ａ）〜＃９（Ｉ）の各項目が設定可能である。具体的には、シナリオファイル２３中のレコードには、スケジューラ１１−ｉにおけるイベント処理のトリガとなるトリガ情報として、先頭桁から順に、受信イベントＩＤ、受信サブイベントＩＤ、送信元アプリケーションＩＤ、送信元アプリケーションマシンアドレス、送信イベントＩＤ、送信サブイベントＩＤ、送信先アプリケーションＩＤ、送信先アプリケーションマシンアドレス及び起動アプリケーション（起動アプリケーションの実行ファイル名）がそれぞれユーザの入力操作により設定可能である。本実施形態においてシナリオファイル２３はＣＳＶ（Ｃｏｍｍａ Ｓｅｐａｒａｔｅｄ Ｖａｌｕｅ）ファイル形式であり、桁と桁との間はカンマで区切られる。
【００４０】
シナリオファイル２３中のレコードの桁＃１には、スケジューラ１１−ｉのイベント処理のトリガとなる受信イベントＩＤ（識別子）が設定される。設定可能な受信イベントＩＤ値の範囲は０〜４２９４９６７２９５とする。スケジューラ１１−ｉは、受信したイベントのイベントＩＤ及びサブイベントＩＤが、それぞれ上記桁＃１の設定値及び次に述べる桁＃２の設定値と一致した場合、対応するレコードを処理対象と見なす。シナリオファイル２３内に、同じ受信イベントに対する指示が複数レコード存在する場合、スケジューラ１１−ｉは、当該複数のレコードを順次処理する。シナリオファイル２３中のレコードの桁＃２には、スケジューラ１１−ｉのイベント処理のトリガとなる受信サブイベントＩＤが設定される。
【００４１】
シナリオファイル２３中のレコードの桁＃３には、イベント送信元のアプリケーションＩＤが設定される。この桁＃３の項目は省略可能である。スケジューラ１１−ｉは、桁＃３の項目が設定されている場合、上記受信イベントＩＤ及び受信サブイベントＩＤが桁＃１及び＃２の設定値と一致し、且つイベントを送信したアプリケーション（送信元タスク）のアプリケーションＩＤ（送信元アプリケーションＩＤ）が桁３の設定値と一致した場合のみ、対応するレコードを処理対象と見なす。もし、桁＃３の項目の設定が省略されている場合、スケジューラ１１−ｉは受信イベントＩＤ及び受信サブイベントＩＤが桁＃１及び＃２の設定値と一致していれば送信元のタスクに拘わらずに、対応するレコードを処理対象とする。
【００４２】
シナリオファイル２３中のレコードの桁＃４には、イベント送信元タスクが、スケジューラ１１−ｉが動作するマシン（ＰＣ）とは別のマシン上に存在する場合、当該別のマシンのＩＰアドレス、またはＩＰアドレスに名前解決可能なマシン名が、送信元アプリケーションマシンアドレスとして設定される。この桁＃４の項目は省略可能である。この桁＃４の項目の設定がない場合、スケジューラ１１−ｉは、イベント送信元タスクが当該スケジューラ１１−ｉと同じマシン上にあるものと見なす。
【００４３】
シナリオファイル２３中のレコードの桁＃５には、送信イベントＩＤが設定される。この桁＃５の項目が設定されている場合、スケジューラ１１−ｉは、受信したイベントＩＤの代わりに、当該桁＃５に設定されているイベントＩＤを送信先に通知する。この桁＃５の項目は省略可能であり、当該桁＃５の項目の設定がない場合、スケジューラ１１−ｉは受信イベントＩＤをそのまま送信先に通知する。
【００４４】
シナリオファイル２３中のレコードの桁＃６には、送信サブイベントＩＤが設定される。この桁＃６の項目が設定されている場合、スケジューラ１１−ｉは、受信したサブイベントＩＤの代わりに、当該桁＃６に設定されているサブイベントＩＤを送信先に通知する。この桁＃６の項目は省略可能であり、当該桁＃６の項目の設定がない場合、スケジューラ１１−ｉは受信サブイベントＩＤをそのまま送信先に通知する。
【００４５】
シナリオファイル２３中のレコードの桁＃７には、イベント送信先となるアプリケーション（タスク）のアプリケーションＩＤが送信先アプリケーションＩＤとして設定される。この桁＃７の項目は省略可能である。スケジューラ１１−ｉは、桁＃７の項目の設定がない場合、あるいは当該桁＃７に設定されているアプリケーションＩＤで指定されるタスクが存在しない（スケジューラ１１−ｉと接続されていない）場合、受信イベントを送信しない。
【００４６】
シナリオファイル２３中のレコードの桁＃８には、イベント送信先タスクが、スケジューラ１１−ｉが動作するマシン（ＰＣ）とは別のマシン上に存在する場合、当該別のマシンのＩＰアドレス、またはＩＰアドレスに名前解決可能なマシン名が、送信先アプリケーションマシンアドレスとして設定される。この桁＃８の項目は省略可能であり、当該桁＃８の項目の設定がない場合、スケジューラ１１−ｉは、イベント送信先タスクが当該スケジューラ１１−ｉと同じマシン上にあるものと見なす。
【００４７】
シナリオファイル２３中のレコードの桁＃９には、イベント受信によって所望のアプリケーション（タスク）を起動したい場合に、そのアプリケーション（タスク）を指定する起動アプリケーション（タスク）情報を設定（記述）することが可能である。起動アプリケーション（タスク）情報には、起動すべきタスクの例えば実行ファイル名が用いられる。この桁＃９の項目が設定されている場合、スケジューラ１１−ｉは、桁＃５乃至＃８の各項目、即ち送信イベントＩＤ、送信サブイベントＩＤ、送信先アプリケーションＩＤ及び送信先アプリケーションマシンアドレスの各項目を無視する。
【００４８】
スケジューラ１１−ｉが特定のアプリケーション（タスク）を起動するのに用いられるコマンドライン（命令入力行）は、例えば
“桁＃９の項目の設定値（実行ファイル名） スケジューラ名
イベントＩＤ サブイベントＩＤ イベントデータトークン”
のような形式で表される。上記コマンドライン中のイベントデータトークンは、当該コマンドラインに付される一種のラベル（名前）であり、桁＃９の項目の設定値（実行ファイル名）で指定されるアプリケーションを起動するときに必要な引数として用いられる。つまり、桁＃９の項目の設定値で指定されるアプリケーション（タスク）は、引数として渡されるイベントデータトークンをスケジューラＡＰＩ１３（中の関数）に渡すことにより、スケジューラ１１−ｉで受信されたイベントデータを当該スケジューラＡＰＩ１３を介して取得することができる。なお、コマンドラインにユーザ指定の引数を含めたい場合、当該引数は桁＃９の項目中で実行ファイル名の後ろに記述される。例えば、実行ファイル名が“ａ．ｅｘｅ”で、ユーザ指定の引数が“１ ２”の場合、桁＃９の項目には“ａ．ｅｘｅ １ ２”を設定すればよい。実行ファイル名にはパスを含めることが可能である。
【００４９】
シナリオファイル２３の一例を図１０に示す。図１０の例では、シナリオファイル２３は７つのレコード２３１〜２３７から構成される。レコード２３１〜２３５は、桁＃４〜＃６，＃８，＃９の項目が設定されていないレコードの例である。レコード２３６は、受信したイベントＩＤ及びサブイベントＩＤの代わりに、＃５，＃６に設定されているイベントＩＤ＝２０２，サブイベントＩＤ＝１を送信先に通知することを指示するレコードの例である。レコード２３７は、桁＃９の項目により実行ファイル名が“ｎｏｔｅｐａｄ．ｅｘｅ”のアプリケーションの起動が指定されているレコードの例である。
【００５０】
図１１はスケジューラ１１−ｉにより使用される共有変数定義ファイル２４（ファイル名：ｖａｒｉａｂｌｅ．ｃｓｖ）の１レコードのデータフォーマットを示す。共有変数定義ファイル２４は少なくとも１つのレコードを有する。共有変数定義ファイル２４中のレコードには、桁＃１（Ａ）〜＃４（Ｄ）の各項目がユーザの入力操作により設定可能である。本実施形態において共有変数定義ファイル２４はＣＳＶファイル形式であり、桁と桁との間はカンマで区切られる。
【００５１】
共有変数定義ファイル２４中のレコードの桁＃１には、作成する変数の名称（変数名）が設定される。ここで、変数名として使用できる文字とサイズ（変数名長）については制約があるが、本実施形態とは直接関係しないため説明を省略する。
【００５２】
共有変数定義ファイル２４中のレコードの桁＃２には、作成する変数の型が設定される。変数型は“ＤＷＯＲＤ”“ＡＳＣＩＩ”“ＢＩＮ”の３種類であり、“ＤＷＯＲＤ”は３２ビット整数値を、“ＡＳＣＩＩ”は文字列を、“ＢＩＮ”は任意のバイナリデータを、それぞれ示す。この桁＃２の項目は省略可能であり、当該桁＃２の項目の設定がない場合、変数型は“ＤＷＯＲＤ”であると見なされる。
【００５３】
共有変数定義ファイル２４中のレコードの桁＃３には、２以上の値が設定される。この桁＃３の項目への２以上の値の設定により、配列型の変数（配列数）を作成することが可能である。タスクが配列の各要素にアクセスするにはインデックス（０〜）を使用する。共有変数定義ファイル２４において、桁＃３の項目は省略可能である。この桁＃３の項目の設定がない場合、配列数＝１と見なされ、桁＃１に設定されている変数名で指定される変数が配列型の変数でないとして扱われる。
【００５４】
共有変数定義ファイル２４中のレコードの桁＃４には変数の初期値が設定される。変数は、この桁＃４に設定された値で初期化される。桁＃４の項目は省略可能である。この桁＃４の項目の設定がない場合、変数は変数型に基づいて次のように初期化される。即ち、“ＤＷＯＲＤ”の場合は“０”に、“ＡＳＣＩＩ”の場合は“空”（””）に、“ＢＩＮ”の場合は“空”（サイズ＝０）に初期化される。ここでは、文字列型変数（“ＡＳＣＩＩ”）の初期化には、初期値を””で囲む必要がある。また、配列型変数を初期化するには各要素をカンマで区切って設定する。この場合、桁区切りのカンマと区別するために初期値全体を””で囲む必要がある。
【００５５】
共有変数定義ファイル２４の一例を図１２に示す。図１２の例では、共有変数定義ファイル２４は６つのレコード２４１〜２４６から構成される。
【００５６】
図１３はスケジューラ１１−ｉにより使用されるセマフォ定義ファイル２５（ファイル名：ｓｅｍａｐｈｏｒｅ．ｃｓｖ）の１レコードのデータフォーマットを示す。セマフォ定義ファイル２５は少なくとも１つのレコードを有する。セマフォ定義ファイル２５中のレコードには、桁＃１（Ａ），＃２（Ｂ）の各項目がユーザの入力操作により設定可能である。本実施形態においてセマフォ定義ファイル２５はＣＳＶファイル形式であり、桁と桁との間はカンマで区切られる。
【００５７】
セマフォ定義ファイル２５中のレコードの桁＃１には、作成するセマフォの名称（セマフォ名）が設定される。ここで、セマフォ名として使用できる文字とサイズについては制約があるが、本実施形態とは直接関係しないため説明を省略する。
【００５８】
セマフォ定義ファイル２５名のレコードの桁＃２には、セマフォの初期カウントが設定される。この桁＃２の項目は省略可能であり、当該桁＃２の項目の設定がない場合、初期カウント＝１と見なされる。
【００５９】
セマフォ定義ファイル２５の一例を図１４に示す。図１４の例では、セマフォ定義ファイル２５は２つのレコード２５１，２５２から構成される。
【００６０】
図１５はスケジューラ１１−ｉにより使用されるアプリケーション登録ファイル２１（ファイル名：ａｐｐｌｉｃａｔｉｏｎ．ｃｓｖ）の１レコードのデータフォーマットを示す。アプリケーション登録ファイル２１は少なくとも１つのレコードを有する。このアプリケーション登録ファイル２１中のレコードには、桁＃１（Ａ），＃２（Ｂ）の各項目がユーザの入力操作により設定可能である。本実施形態においてアプリケーション登録ファイル２１はＣＳＶファイル形式であり、桁と桁との間はカンマで区切られる。スケジューラ１１−ｉは、アプリケーション登録ファイル２１を読み込むことにより、当該スケジューラ１１−ｉにスケジューラＡＰＩ１３を介して接続されるタスクを認識する。
【００６１】
アプリケーション登録ファイル２１中のレコードの桁＃１には、スケジューラ１１−ｉに接続されるアプリケーション（タスク）のアプリケーションＩＤが設定される。この桁＃２には、桁＃１の項目の設定値で指定されるアプリケーションが、スケジューラ１１−ｉが動作するマシン（ＰＣ）とは別のマシン上に存在する場合に、当該別のマシンのＩＰアドレス、またはＩＰアドレスに名前解決可能なマシン名が、マシンアドレスとして設定される。桁＃２の項目は省略可能である。この桁＃２の項目の設定がない場合、スケジューラ１１−ｉは、当該スケジューラ１１−ｉに接続されるアプリケーション（タスク）が当該スケジューラ１１−ｉと同じマシン上にあるものと見なす。
【００６２】
アプリケーション登録ファイル２１の一例を図１６に示す。図１６の例では、アプリケーション登録ファイル２１は３つのレコード２１１〜２１３から構成される。
【００６３】
図１７はスケジューラＡＰＩ１３により使用されるクライアント設定ファイル２７（ファイル名：ｃｌｉｅｎｔ．ｉｎｉ）のデータフォーマットを示す。図１７において、斜体文字の部分はユーザの入力操作により設定可能な箇所である。クライアント設定ファイル２７には、図７に示したスケジューラ設定ファイル２２と同様に、運用ログに書き込まれるログ事象毎のログ書き込みレベル（ＬｏｇＬｅｖｅｌ＝０〜４２９４９６７２９５）１７１と、運用ログへのデータダンプの書き込み方法を示す書き込み制御値（ＬｏｇＤａｔａ＝０〜２）１７２とが設定可能である。ログ書き込みレベル１７１は省略可能であり、省略時は０として扱われる。クライアント設定ファイル２７には更に、スケジューラＡＰＩ１３がネットワーク上の別のマシン（ＰＣ）上で動作するスケジューラと接続する必要がある場合に、そのスケジューラと接続するためのスケジューラ接続情報１７３が設定される。スケジューラ接続情報１７３は、接続の対象となるスケジューラを示すスケジューラ名、当該スケジューラが動作するマシンのマシンアドレス、及び当該スケジューラに割り当てるＴＣＰポート番号が設定される。ここで、マシンアドレスには、ＩＰアドレス、またはＩＰアドレスに名前解決可能なマシン名を用いる必要がある。クライアント設定ファイル２７の一例を図１８に示す。
【００６４】
次に、本発明の一実施形態における、主としてスケジューラサービス１２及びスケジューラ１１−１の動作について、図２のスケジューラ起動説明図、及び図１９乃至図２２のフローチャートを適宜参照して説明する。
【００６５】
まず、図４のＰＣにおいて汎用ＯＳ１０が立ち上がると、図２のステップＳ１に示したように、スケジューラサービス１２が起動される。するとスケジューラサービス１２は、ディスク装置４３に保存されている、図５のフォーマットのグローバル設定ファイル２６を主メモリ４２に読み込む（ステップＳ１１）。そしてスケジューラサービス１２は、グローバル設定ファイル２６に設定されているスケジューラリスト（ＳｃｈｅｄｕｌｅｒＬｉｓｔ）５１に従い、管理すべきスケジューラ１１−ｉを認識する（ステップＳ１２）。ここでは、スケジューラ１１−１〜１１−ｎが認識されたものとする。この場合、スケジューラサービス１２は、認識したスケジューラ１１−１〜１１−ｎ毎に、グローバル設定ファイル２６に設定されているＴＣＰポート番号（ＴｃｐＰｏｒｔ）５２を割り当てて、当該スケジューラ１１−１〜１１−ｎを図２のステップＳ２−１〜Ｓ２−ｎに示したように起動する（ステップＳ１３）。
【００６６】
以下、スケジューラ１１−１〜１１−ｎの動作について、スケジューラ１１−１を例に説明する。スケジューラ１１−１はスケジューラサービス１２により起動されると、当該スケジューラ１１−１のスケジューラ名に対応付けてディスク装置４３に保存されている、当該スケジューラ１１−１に固有の、アプリケーション登録ファイル２１、スケジューラ設定ファイル２２、シナリオファイル２３、共有変数定義ファイル２４及びセマフォ定義ファイル２５の各設定ファイルの内容を主メモリ４２に読み込む（ステップＳ２１）。
【００６７】
次にスケジューラ１１−１は、主メモリ４２に読み込んだアプリケーション登録ファイル２１（の内容）に従って、当該スケジューラ１１−１に接続されるタスク（アプリケーション）を認識する（ステップＳ２２）。またスケジューラ１１−１は、共有変数定義ファイル２４（の内容）に従い、共有変数の領域を主メモリ４２上に確保する（ステップＳ２３）。この領域は、スケジューラ１１−１に接続されるタスクに開放される。またスケジューラ１１−１は、セマフォ定義ファイル２（の内容）５に従い、当該ファイル２５で指定されたセマフォ名のセマフォを主メモリ４２上に全て作成する（ステップＳ２４）。このとき作成されたセマフォのカウント値は、セマフォ定義ファイル２５で指定された初期カウント値に初期設定される。
【００６８】
作成されたセマフォは、スケジューラＡＰＩ１３によるタスク間通信の排他制御に用いられる。セマフォのカウント値は、タスクにより使用される都度１だけデクリメントされ、使用が終了する都度１だけインクリメントされる。セマフォのカウント値が初期値に一致する状態、つまりセマフォが使用されていない状態では、タスクは当該セマフォのセマフォ名をスケジューラＡＰＩ１３に対して指定するだけで、当該スケジューラＡＰＩ１３の排他制御を受けて、任意のリソースを使用できる。もし、セマフォの初期カウント値がＮ（Ｎは１以上の整数）である場合、当該セマフォの使用権を獲得したタスクは、最大Ｎ個のリソースを並行して使用できる。
【００６９】
スケジューラ１１−１は、ステップＳ２２乃至Ｓ２４を実行すると、ステップＳ２２で認識したタスクから（スケジューラＡＰＩ１３を介して）接続されるのを待つ状態（タスク接続待ち状態）に遷移する（ステップＳ２５）。この状態で、スケジューラ１１−１はタスクから接続されると（ステップＳ２６）、シナリオファイル２３に従ってイベントの送受信処理（ステップＳ２７）を次のように行う。
【００７０】
まずスケジューラ１１−１が、タスクとの接続状態において、当該タスクからスケジューラＡＰＩ１３を介してイベントを受信したものとする（ステップＳ３１）。ここで、イベントはイベントＩＤ及びサブイベントＩＤで識別され、タスクはアプリケーションＩＤで識別される。
【００７１】
スケジューラ１１−１は、タスクからイベントを受信するとシナリオファイル２３を参照し、当該受信したイベントのイベントＩＤ及びサブイベントＩＤに一致する受信イベントＩＤ及び受信サブイベントＩＤが設定されているレコード（以下、目的レコードと称する）がシナリオファイル２３中に存在するか否かを調べる（ステップＳ３２）。もし、目的レコードが存在しないならば、つまり目的レコードが見つからなかったならば、スケジューラ１１−１は受信したイベントはイベント送受信処理の対象外であるとして、当該イベントの受信前の状態に戻る。
【００７２】
これに対し、目的レコードが存在するならば、つまり目的レコードが見つかったならば、スケジューラ１１−１は当該レコード中に起動アプリケーションの設定がされているか否かを調べる（ステップＳ３３）。もし、起動アプリケーションの設定がされているならば、スケジューラ１１−１は目的レコードの他の設定項目（送信イベントＩＤ、送信サブイベントＩＤ、送信先アプリケーションＩＤ及び送信先アプリケーションマシンアドレスの各設定項目）の内容に無関係に、指定のアプリケーションをスケジューラＡＰＩ１３を介して新たに起動する（ステップＳ３４）。そしてスケジューラ１１−１は、受信したイベントのイベントＩＤ及びサブイベントＩＤに一致する受信イベントＩＤ及び受信サブイベントＩＤが設定されている他の目的レコードがシナリオファイル２３中に存在するか調べるために、ステップＳ３２に戻る。
【００７３】
一方、目的レコード中に起動アプリケーションの設定がされていない場合（ステップＳ３３）、スケジューラ１１−１は当該レコード中に送信元アプリケーションＩＤが設定されているか否かを調べる（ステップＳ３５）。もし、送信元アプリケーションＩＤが設定されているならば、スケジューラ１１−１は、当該設定されている送信元アプリケーションＩＤに、受信したイベントを送信したタスクのアプリケーションＩＤが一致しているか否かを調べる（ステップＳ３６）。もし、一致しないならば、スケジューラ１１−１は、受信したイベントの送信条件の不成立を判断して、目的レコードを処理対象外とする。この場合、スケジューラ１１−１は、他の目的レコードがシナリオファイル２３中に存在するか調べるために、ステップＳ３２に戻る。
【００７４】
これに対し、目的レコードに設定されている送信元アプリケーションＩＤに、受信したイベントを送信したタスクのアプリケーションＩＤが一致しているならば（ステップＳ３６）、スケジューラ１１−１はステップＳ３７に進む。またスケジューラ１１−１は、目的レコードに送信元アプリケーションＩＤが設定されていない場合にも（ステップＳ３５）、ステップＳ３７に進む。
【００７５】
ステップＳ３７において、スケジューラ１１−１は、目的レコードに送信元アプリケーションマシンアドレスが設定されているか否かを調べる。もし、設定されていないならば、スケジューラ１１−１は、受信したイベントを送信したタスク（イベント送信元タスク）が、自身と同一マシン上に存在すると判断する（ステップＳ３８）。一方、目的レコードに送信元アプリケーションマシンアドレスが設定されているならば（ステップＳ３７）、スケジューラ１１−１はイベント送信元タスクが、自身が動作するマシンとは別の、当該マシンアドレス（ＩＰアドレスまたは名前解決可能なマシン名）で指定されるマシン上に存在するものと判断する。
【００７６】
次にスケジューラ１１−１は、目的レコード中に送信先アプリケーションＩＤが設定されているか否かを調べる（ステップＳ３９）。もし、送信先アプリケーションＩＤが設定されていないならば、スケジューラ１１−１は、受信したイベントの送信条件の不成立を判断して、現在の目的レコードを処理対象外とする。この場合、スケジューラ１１−１は、他の目的レコードがシナリオファイル２３中に存在するか調べるために、ステップＳ３２に戻る。これに対し、目的レコード中に送信先アプリケーションＩＤが設定されているならば（ステップＳ３９）、スケジューラ１１−１は、目的レコードに設定されている送信先アプリケーションＩＤを持つタスクが存在する（自身と接続されている）か否かを調べる（ステップＳ４０）。
【００７７】
もし、該当するタスクが存在しないならば（ステップＳ４０）、スケジューラ１１−１は受信したイベントの送信条件の不成立を判断して現在の目的レコードを処理対象外とし、他の目的レコードがシナリオファイル２３中に存在するか調べるために、ステップＳ３２に戻る。これに対し、該当するタスクが存在するならば（ステップＳ４０）、スケジューラ１１−１は受信したイベントの送信条件の成立を判断して目的レコードに送信先アプリケーションマシンアドレスが設定されているか否かを調べる（ステップＳ４１）。もし、設定されていならば、スケジューラ１１−１は、受信したイベントの送信先となるタスク（イベント送信先タスク）が、自身と同一マシン上に存在するものと判断する（ステップＳ４２）。一方、目的レコードに送信先アプリケーションマシンアドレスが設定されているならば（ステップＳ４１）、スケジューラ１１−１はイベント送信先タスクが、自身が動作するマシンとは別の、当該マシンアドレス（ＩＰアドレスまたは名前解決可能なマシン名）で指定されるマシン上に存在するものと判断する。
【００７８】
次にスケジューラ１１−１は、目的レコード中に送信イベントＩＤ及び送信サブイベントＩＤが設定されているか否かを調べる（ステップＳ４３）。もし、目的レコード中に送信イベントＩＤ及び送信サブイベントＩＤが設定されているならば、スケジューラ１１−１は、受信したイベントの送信時に、当該イベントのイベントＩＤ及びサブイベントＩＤを、当該レコード中の送信イベントＩＤ及び送信サブイベントＩＤに置き換えて、その置き換え後のイベントを送信先アプリケーション（タスク）に送信する（ステップＳ４４）。つまりスケジューラ１１−１は、受信イベントのイベントＩＤ及びサブイベントＩＤに代えて、目的レコード中の送信イベントＩＤ及び送信サブイベントＩＤを送信先に通知する。これにより、シナリオファイル２３内に、同一の受信イベントＩＤ／サブイベントＩＤを含む複数のレコードを用意して、その複数のレコードに、それぞれ異なる送信イベントＩＤ及び送信サブイベントＩＤ並びに送信先アプリケーションＩＤを設定しておくならば、あるタスクからスケジューラ１１−１に対し、上記受信イベントＩＤ／サブイベントＩＤに一致するイベントＩＤ／サブイベントＩＤのイベントが送信された場合に、当該イベントを、複数のタスクに対してそれぞれ異なるイベントＩＤ／サブイベントＩＤで送信できる。
【００７９】
一方、目的レコード中に送信イベントＩＤ及び送信サブイベントＩＤが設定されていないならば、スケジューラ１１−１は、受信イベントのイベントＩＤ及びサブイベントＩＤをそのまま用いて、当該イベントを送信先アプリケーション（タスク）に通知する（ステップＳ４５）。つまりスケジューラ１１−１は、受信イベントのイベントＩＤ及びサブイベントＩＤをそのまま送信先に通知する。
【００８０】
その後、スケジューラ１１−１は、他の目的レコードがシナリオファイル２３中に存在するか調べるために、ステップＳ３２に戻る。そして、受信したイベントのイベントＩＤ及びサブイベントＩＤに一致する受信イベントＩＤ及び受信サブイベントＩＤが設定されている全ての目的レコードを処理すると、スケジューラ１１−１は当該イベントの受信前の状態に戻る。
【００８１】
次に、図１に示したタスク間通信システムのソフトウェア構成の具体例について、半導体製造装置に適用されるソフトウェア構成を例に説明する。図２３は半導体製造装置に適用されるタスク間通信システムのソフトウェア構成を示すブロック図である。同図に示すように、この半導体製造装置上では、スケジューラ１１０と、タスク２０１，２０２，２０３とが動作する。
【００８２】
タスク２０１は、半導体製造装置の例えば前面のパネルの表示を制御するＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を実現するアプリケーションである。以下、タスク２０１をＧＵＩタスク２０１と称する。
【００８３】
タスク２０２は、半導体製造装置内部の機器を制御するコントロール機構（ＣＯＮＴＲＯＬ）を実現するアプリケーションである。以下、タスク２０２を機器制御タスク（ＣＯＮＴＲＯＬタスク）２０１と称する。タスク２０３は、半導体製造装置外部と通信する通信機構（ＣＯＭＭＵＮＩＣＡＴＩＯＮ）を実現するアプリケーションである。以下、タスク２０３を外部通信用タスク（ＣＯＭＭＵＮＩＣＡＴＩＯＮタスク）２０３と称する。
【００８４】
図２４は、図２３のソフトウェア構成により、半導体装置前面のパネルから当該装置の状態を、例えばＯＦＦＬＩＮＥ状態（つまり外部との通信を行わない状態）から、ＯＮＬＩＮＥ状態（つまり外部と通信を行う状態）に変化させるのに必要なシナリオファイル２３の一例を示す。また、図２４の構成のシナリオファイル２３を適用すると共に、ＧＵＩによりＯＮＬＩＮＥへ変更し、イベントＩＤ＝１００（サブイベントＩＤ＝１）のイベントがＧＵＩタスク２０１からスケジューラ１１０に対して送信される場合の処理手順を、図２５のフローチャートに示す。なお、図２５のフローチャート中の“Ｘ，Ｙ”の表現は、イベントＩＤ＝Ｘ、サブイベントＩＤ＝Ｙを表す。
【００８５】
以下、図２５のフローチャートに従う処理手順について、図２６に示すスケジューラ１１０と各タスク２０１〜２０３との間の通信手順を説明するための図を併用して説明する。
【００８６】
まず、ＧＵＩタスク２０１からスケジューラ１１０に対し、ＯＮＬＩＮＥ変更を要求するイベントＩＤ＝１００、サブイベントＩＤ＝１のイベント（ＯＮＬＩＮＥ変更要求１００，１）が送信されると、スケジューラ１１０は当該イベント、つまり「ＯＮＬＩＮＥ変更要求１００，１」を受信する（図２５ステップＳ５１、図２６ステップＳ６１）。するとスケジューラ１１０から外部通信用タスク（ＣＯＭＭＵＮＩＣＡＴＩＯＮタスク）２０３に対して「ＯＮＬＩＮＥ問い合わせ２００，１」が送信される（図２５ステップＳ５２、図２６ステップＳ６２）。そしてスケジューラ１１０は、「ＯＮＬＩＮＥ問い合わせ２００，１」に対する「応答２００．２」を待つ。
【００８７】
この状態で、外部通信用タスク２０３からスケジューラ１１０に対して「ＯＮＬＩＮＥ問い合わせ２００，１」に対する「応答２００．２」が送信されると、スケジューラ１１０は当該「応答２００．２」を受信する（図２５ステップＳ５３、図２６ステップＳ６３）。するとスケジューラ１１０は、機器制御タスク（ＣＯＮＴＲＯＬタスク）２０２に対して半導体製造装置の状態を問い合わせるための「状態問い合わせ３００．１」を送信する（図２５ステップＳ５４、図２６ステップＳ６４）。そしてスケジューラ１１０は、「状態問い合わせ３００．１」に対する「応答３００．２」を待つ。
【００８８】
この状態で、機器制御タスク２０２からスケジューラ１１０に対して「状態問い合わせ３００．１」に対する「応答３００．２」が送信されると、スケジューラ１１０は当該「応答３００．２」を受信する（図２５ステップＳ５５、図２６ステップＳ６５）。するとスケジューラ１１０は、外部通信用タスク２０３に対して半導体製造装置の状態を通知するための「装置状態報告４００．１」を送信する（図２５ステップＳ５６、図２６ステップＳ６６）。そしてスケジューラ１１０は、「装置状態報告４００．１」に対する「応答４００．２」を待つ。
【００８９】
この状態で、外部通信用タスク２０３からスケジューラ１１０に対して「装置状態報告４００．１」に対する「応答４００．２」が送信されると、スケジューラ１１０は当該「応答４００．２」を受信する（図２５ステップＳ５７、図２６ステップＳ６７）。するとスケジューラ１１０は、「ＯＮＬＩＮＥ変更要求１００，１」を発したＧＵＩタスク２０１に対し、総合的な「応答１００，２」を送信する（図２５ステップＳ５８、図２６ステップＳ６８）。
【００９０】
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。
【００９１】
【発明の効果】
以上詳述したように本発明によれば、タスクから独立に設けられたスケジューラにより、イベント処理のトリガとなるトリガ情報が設定されたシナリオファイルに従って受信イベントを処理するようにしたので、タスク間通信を非同期で容易に行うことができ、タスクの機能追加・削除（新規タスクの追加・既存タスクの削除）が必要な場合でも、シナリオファイルを書き換えるだけで容易に対応できる。また本発明によれば、シナリオファイルの中から検出されたトリガ情報に送信イベント識別子が設定されている場合には、当該トリガ情報に設定されている送信先アプリケーション識別子の示すタスクに受信イベントデータを送信する際に、当該イベントデータのイベント識別子を当該送信イベント識別子に置き換えるようにしたので、タスクの追加・削除が発生しても、イベントデータの受信側で当該データを適切に処理できる
【図面の簡単な説明】
【図１】本発明の一実施形態に係るタスク間通信システムのソフトウェア構成を示すブロック図。
【図２】スケジューラサービス１２の起動と、それに伴うスケジューラ１１−１〜１１−ｎの起動とを説明するための図。
【図３】上記スケジューラ１１−１〜１１−ｎが存在するＰＣ（パーソナルコンピュータ）におけるディレクトリ構成の一例を示す図。
【図４】図１の構成のソフトウェア及び各ファイルが存在するＰＣのハードウェア構成を示すブロック図。
【図５】グローバル設定ファイル２６のデータフォーマットを示す図。
【図６】上記グローバル設定ファイル２６の一例を示す図。
【図７】スケジューラ設定ファイル２２のデータフォーマットを示す図。
【図８】上記スケジューラ設定ファイル２２の一例を示す図。
【図９】シナリオファイル２３の１レコードのデータフォーマットを示す図。
【図１０】上記シナリオファイル２３の一例を示す図。
【図１１】共有変数定義ファイル２４の１レコードのデータフォーマットを示す図。
【図１２】上記共有変数定義ファイル２４の一例を示す図。
【図１３】セマフォ定義ファイル２５の１レコードのデータフォーマットを示す図。
【図１４】上記セマフォ定義ファイル２５の一例を示す図。
【図１５】アプリケーション登録ファイル２１の１レコードのデータフォーマットを示す図。
【図１６】上記アプリケーション登録ファイル２１の一例を示す図。
【図１７】クライアント設定ファイル２７のデータフォーマットを示す図。
【図１８】上記クライアント設定ファイル２７の一例を示す図。
【図１９】同実施形態におけるスケジューラサービス１２の起動時の動作を説明するためのフローチャート。
【図２０】スケジューラサービス１２により起動されたスケジューラ１１−１の動作を説明するためのフローチャート。
【図２１】上記スケジューラ１１−１のイベント送受信処理を説明するためのフローチャート。
【図２２】上記スケジューラ１１−１のイベント送受信処理を説明するためのフローチャート。
【図２３】半導体製造装置に適用されるタスク間通信システムのソフトウェア構成を示すブロック図。
【図２４】図２３のソフトウェア構成により、半導体装置前面のパネルから当該装置の状態をＯＦＦＬＩＮＥからＯＮＬＩＮＥに変化させるのに必要なシナリオファイル２３の一例を示す図。
【図２５】図２４の構成のシナリオファイル２３を適用すると共に、イベントＩＤ＝１００（サブイベントＩＤ＝１）のイベントがＧＵＩタスク２０１からスケジューラ１１０に対して送信される場合の処理手順を示すフローチャート。
【図２６】図２５のフローチャートに従う処理手順が実行される際の、スケジューラ１１０と各タスク２０１〜２０３との間の通信手順を説明するための図。
【符号の説明】
１１−１〜１１−ｎ，１１０…スケジューラ、１２…スケジューラサービス、１３…スケジューラＡＰＩ（特定アプリケーションプログラムインタフェース）、２０−１〜２０−３，２０１〜２０３…タスク、２１…アプリケーション登録ファイル、２２…スケジューラ設定ファイル、２３…シナリオファイル、２４…共有変数定義ファイル、２５…セマフォ定義ファイル、２６…グローバル設定ファイル、４１…ＣＰＵ、４２…主メモリ、４３…ディスク装置

Claims (9)

1. 汎用オペレーティングシステムが動作する計算機を、タスクとの間でイベントデータによる通信が可能な少なくとも１つのスケジューラとして機能させるためのタスク間通信プログラムであって、
   前記スケジューラが、
   タスクからのイベントデータの受信時には、受信イベント識別子が設定されると共に当該受信イベント識別子に対応付けて送信イベント識別子及びイベントデータの送信先となるタスクを指定する送信先アプリケーション識別子が設定可能な、イベント処理のトリガとなるトリガ情報が記録されたシナリオファイルを参照して、受信イベントデータのイベント識別子に一致する受信イベント識別子を含むトリガ情報を全て検出する手段と、
   前記検出手段によって検出されたトリガ情報をもとに、当該トリガ情報に少なくとも前記送信先アプリケーション識別子が設定されていることを前記受信イベントデータの送信条件として、当該条件の成立または不成立を判定する手段と、
   前記判定手段により送信条件成立が判定された場合に、前記検出手段によって検出されたトリガ情報に設定されている送信先アプリケーション識別子の示すタスクへ前記受信イベントデータを送信し、その際に当該イベントデータのイベント識別子を、当該トリガ情報に前記送信イベント識別子が設定されているか否かに応じて当該送信イベント識別子に置き換える送信手段とを備えている
   ことを特徴とするタスク間通信プログラム。
2. 前記トリガ情報には前記受信イベント識別子に対応付けて起動すべきタスクを指定する起動タスク情報が設定可能であり、
   前記スケジューラは、前記検出手段によって検出されたトリガ情報に前記起動タスク情報が設定されている場合に、当該起動タスク情報で指定されるタスクを起動するタスク起動手段を更に備え、
   前記判定手段は、前記検出手段によって検出されたトリガ情報に前記起動タスク情報が設定されている場合には、当該トリガ情報に前記送信先アプリケーション識別子が設定されているか否かと無関係に、前記送信条件の不成立を判定する
   ことを特徴とする請求項１記載のタスク間通信プログラム。
3. 前記トリガ情報には前記受信イベント識別子に対応付けて送信元アプリケーション識別子が設定可能であり、
   前記判定手段は、前記検出手段によって検出されたトリガ情報に前記受信イベントデータを送信したタスクのアプリケーション識別子とは異なる前記送信元アプリケーション識別子が設定されている場合には、当該トリガ情報に前記送信先アプリケーション識別子が設定されているか否かと無関係に、前記送信条件の不成立を判定する
   ことを特徴とする請求項１記載のタスク間通信プログラム。
4. 前記計算機を、
   前記汎用オペレーティングシステムの起動時に、前記少なくとも１つのスケジューラを指定するリストが設定されたグローバル設定ファイルに従って当該スケジューラを起動するスケジューラサービス手段として更に機能させるための請求項１記載のタスク間通信プログラム。
5. 前記計算機を、
   タスクからの要求に従って前記スケジューラと汎用通信プロトコルにより接続する特定アプリケーションプログラムインタフェースとして更に機能させるための請求項１記載のタスク間通信プログラム。
6. 前記特定アプリケーションプログラムインタフェースは、タスクからの要求によりスケジューラとの接続のための汎用のオブジェクト間通信インタフェースを当該タスクに提供し、当該タスクにより生成される汎用の通信オブジェクトに応じて前記スケジューラとの接続または前記スケジューラからの切断を行う請求項５記載のタスク間通信プログラム。
7. 汎用オペレーティングシステムが動作する計算機において、当該計算機上のタスク間の通信、あるいは当該計算機上のタスク及び当該計算機とネットワーク接続された別の計算機上のタスクとの間の通信を行うタスク間通信方法であって、
   前記汎用オペレーティングシステムの起動時に、タスクとの間でイベントデータによる通信が可能な少なくとも１つのスケジューラを起動するステップと、
   起動されたスケジューラの実行により、当該スケジューラと接続されたタスクからのイベントデータを受信した場合に、受信イベント識別子が設定されると共に当該受信イベント識別子に対応付けて送信イベント識別子及びイベントデータの送信先となるタスクを指定する送信先アプリケーション識別子が設定可能な、イベント処理のトリガとなるトリガ情報が記録されたシナリオファイルを参照して、受信イベントデータのイベント識別子に一致する受信イベント識別子を含むトリガ情報を検出するステップと、
   前記受信イベントデータのイベント識別子に一致する受信イベント識別子を含むトリガ情報が検出される都度、当該トリガ情報に少なくとも前記送信先アプリケーション識別子が設定されていることを前記受信イベントデータの送信条件として、当該条件の成立または不成立を判定するステップと、
   前記送信条件の成立が判定された場合に、前記検出されたトリガ情報に設定されている送信先アプリケーション識別子の示すタスクへ前記受信イベントデータを送信し、その際に当該イベントデータのイベント識別子を、当該トリガ情報に前記送信イベント識別子が設定されているか否かに応じて当該送信イベント識別子に置き換えるステップと
   を具備することを特徴とするタスク間通信方法。
8. 前記検出されたトリガ情報に前記受信イベント識別子に対応付けて起動すべきタスクを指定する起動タスク情報が設定されているか否かを判定するステップと、
   前記起動タスク情報が設定されている場合に、前記受信イベントデータの送信に代えて当該起動タスク情報で指定されるタスクを起動するステップと
   を更に具備することを特徴とする請求項７記載のタスク間通信方法。
9. 前記汎用オペレーティングシステムの起動時に、少なくとも１つのスケジューラを指定するリストが設定されたグローバル設定ファイルに従って、当該リストにより示されるスケジューラを起動するステップを更に具備することを特徴とする請求項７記載のタスク間通信方法。

Images