JPH05197568A

JPH05197568A - コンピュータ・システムおよびイベント管理方法

Info

Publication number: JPH05197568A
Application number: JP4199422A
Authority: JP
Inventors: Stephen E Record; スティーヴン・エリオット・リコード; Ann Marie Shepherd; アン・マリー・シェパード; Steven S Shultz; スティーブン・ソール・シュルツ
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1991-08-12
Filing date: 1992-07-27
Publication date: 1993-08-06
Anticipated expiration: 2010-10-25
Also published as: EP0528222A3; US5530868A; EP0528222A2; JPH0799502B2; US5305454A

Abstract

(57)【要約】【目的】特定のニーズに合わせて調整可能なイベント
管理サービスの提供。【構成】コンピュータ・オペレーティング・システム
が、当該のプログラム内の複数のイベント・ハンドラに
とって関係のあるイベントを管理する。イベント通知
が、シーケンス内のイベント・ハンドラからイベント・
ハンドラへと伝搬されるが、シーケンス内の通知を受け
取るどのイベント・ハンドラもイベント通知の以後の伝
搬をブロックすることができる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、一般にコンピュータの
オペレーティング・システムに関し、より具体的にはコ
ンピュータ・オペレーティング・システム内部のイベン
ト管理サービスに関する。

【０００２】

【従来の技術】コンピュータ・システムを操作するプロ
セスでは、多くのタイプのイベント、たとえばキーボー
ド上の実行（機能）キーの押下、ディスクからメモリへ
のデータのロード、重大なエラーや追跡イベントの発生
などが起こる可能性がある。データは、実行キーの前に
押された文字キーや、ロードされたディスクの名前など
のイベントに関連していることがある。既知のオペレー
ティング・システムは、次のようにイベントを管理す
る。すなわち、イベントが発生したとき、オペレーティ
ング・システムは、そのイベントに関係のある、オペレ
ーティング・システム内で実行中の１つまたは複数の適
用業務プログラムにその旨を通知し、関連するイベント
・データがあればそれを供給する。通知後、適用業務プ
ログラムは、イベントの通知に応答して、そのイベント
・データを処理しまたは他の処置を取ることができる。

【０００３】従来技術のＩＢＭシステム／３８オペレー
ティング・システムは、次のようにしてイベントを管理
する。各イベントは、クラス、タイプ及びサブタイプか
らなる所定の１組の数字名のうちの１つの名前を使用し
て定義される。このオペレーティング・システムは、共
通のハードウェア及びソフトウェア・イベントを表すた
めに、これらの所定の名前のいくつかを予約し、他の名
前は、他のイベントを識別するために適用業務プログラ
ムが使用できる。また適用業務プログラムは、定義され
たイベントの通知を受け取るようにイベント・モニタを
動的に定義することができる。イベントが発生したと
き、オペレーティング・システム、またはそのイベント
を検出した適用業務は、ＥｖｅｎｔＳｉｇｎａｌ機能を
呼び出してから、その他の処理を続ける。ＥｖｅｎｔＳ
ｉｇｎａｌ機能は、そのイベントに関係のある１つまた
は複数のイベント・モニタ、すなわちイベント定義中に
見られるのと同じクラス、タイプ、及びサブタイプ識別
情報を有するイベントを指名するすべてのイベント・モ
ニタに通知する。総称的なタイプまたはサブタイプ指定
も可能である。関係のあるイベント・モニタが複数ある
場合、ＥｖｅｎｔＳｉｇｎａｌ機能は、同報通信モード
で、すなわち実質的に同時に、これら関係のあるイベン
ト・モニタに通知する。つぎに、イベント・モニタは、
そのイベントに関係のある適用業務プログラムの当該の
各イベント処理サブルーチンに、そのイベント通知に作
用し、またはイベント・データを処理し、あるいはその
両方を行うよう通知する。

【０００４】イベント・ハンドラは、イベントの発生に
対して同期的にまたは非同期的に動作する。非同期「ト
ラップ」モードでは、イベント・ハンドラはイベントの
通知を要求するが、イベントがまだ発生していない場合
に、イベントが発生するのを待って遊休状態に留まるこ
とはない。イベントが発生し、当該のイベント・モニタ
が通知を受けたとき、そのイベント・モニタは、割込み
信号とそれに続いてイベント・データを送ることによっ
て、イベント・ハンドラに通知する。同期「テスト」モ
ードでは、イベント・ハンドラは、イベントが発生した
かどうかをイベント・モニタに周期的に照会し、発生し
た場合、そのイベントに応答し、またはイベント・デー
タを処理し、あるいはその両方を行う。イベントが発生
していない場合、イベント・ハンドラは他の作業を実行
する。同期「トラップ」モードでは、イベント・ハンド
ラはイベント通知及びイベント・データを一回要求し、
イベントが発生するまでスリープ・モードで待ち、イベ
ント通知によって覚醒する。システム／３８オペレーテ
ィング・システムはまた、イベント・モニタの動的イネ
ーブリング及びディスエーブリングをサポートする。デ
ィスエーブルされたイベント・モニタは、対応するイベ
ント・ハンドラにイベントを通知しない。また、システ
ム／３８オペレーティング・システムでは、イベント信
号を受け取らないようにイベント・ハンドラをマスクす
ることができる。

【０００５】プログラム追跡イベントなどあるタイプの
イベントは周期的に発生する。システム／３８オペレー
ティング・システムでは、関係のあるイベント・モニタ
に結合された保持すべきイベント及び関連するイベント
・データの最大数を指定することができ、または関係の
あるイベント・モニタがディスエーブルされている間、
これらのイベント及び関連イベント・データを無制限に
保持すると指定することができる。前者の場合、イベン
ト及び関連イベント・データの最大数を超えたとき、最
大水準を超える以後の新しいイベント及び関連するイベ
ント・データが放棄される。

【０００６】システム／３８オペレーティング・システ
ムでは、イベントを管理する際にかなりの量の制御及び
効率がもたらされ、関連する適用業務プログラムがイベ
ント管理サービスの定義に参加することが可能である
が、コンピュータ・システム及び関連する適用業務プロ
グラムの具体的要件に応じてオペレーティング・システ
ムがより効率的かつ包括的にイベントを管理できるよう
にするために、一層の改良が望まれる。

【０００７】

【発明が解決しようとする課題】したがって、本発明の
全般的目的は、効率的かつ包括的にイベントを管理し、
関連する適用業務プログラム、及びコンピュータ・シス
テムの他の部分が、イベント管理サービスをそれらの特
定のニーズに合わせて調整することを可能にする、イベ
ント管理サービスを提供することである。

【０００８】本発明の別の目的は、関連するイベント・
シグナラ、イベント・デファイナまたはイベント・ハン
ドラあるいはそれらのいくつかが効率的かつ最適の形で
動作できるようにする、前記のタイプのイベント管理サ
ービスを提供することである。

【０００９】

【課題を解決するための手段】本発明は、当該の各プロ
グラム内の複数のイベント・ハンドラにとって関係のあ
るイベントを管理する、コンピュータ・オペレーティン
グ・システムに関する。これらのイベント・ハンドラ
は、イベントの発生の順次通知を受け取るためにシーケ
ンスとして配列されている。イベントが発生したとき、
このシーケンス内の第１のイベント・ハンドラが通知を
受け、次いでそのイベントを処理する。次に、第１のイ
ベント・ハンドラは、シーケンス内の第２イベント・ハ
ンドラにそのイベントについて通知すべきかどうかを決
定する。イエスの場合、シーケンス内の第２のイベント
・ハンドラがイベント通知を受け取り、イベントを処理
し、次いでシーケンス内の第３のイベント・ハンドラに
通知すべきかどうかを決定する。このようにして、イベ
ント通知が、シーケンス内のイベント・ハンドラからイ
ベント・ハンドラへと伝搬できるが、シーケンス内の通
知を受け取るどのイベント・ハンドラも、イベント通知
の以後の伝搬をブロックすることができる。この技法
は、シーケンス内の（第１イベント・ハンドラより後
の）いくつかのまたはすべてのイベント・ハンドラがイ
ベント通知から利益を受けない場合に、処理時間を節約
する。このような場合、イベント通知はそれらのイベン
ト・ハンドラに伝搬されない。たとえば、第１イベント
・ハンドラの機能が障害の重大性を分析することであ
り、第２イベント・ハンドラの機能がその障害から回復
することであり、その障害が回復不可能なほど重大であ
る場合、第１イベント・ハンドラは第２イベント・ハン
ドラへの通知を許すべきではない。そうしても、単にプ
ロセッサ時間を浪費するだけである。

【００１０】本発明によれば、オペレーティング・シス
テムは、すべてがそのイベントに関係する複数のイベン
ト・ハンドラに通知するモード、前記の伝搬モード、ま
たは関係のあるすべてのイベント・ハンドラが同時にま
たは少なくとも偶然でなしにイベント通知を受け取る同
報通信モードを選択することが可能である。プログラム
は、イベントの定義に関する対応するパラメータを供給
することによって、関係のあるイベント・ハンドラに通
知するモードを指定する。イベントが発生したとき、オ
ペレーティング・システム内のイベント・マネージャ
が、イベント定義を読み取って、関係のあるイベント・
ハンドラに通知するモードを決定する。プログラムは、
同じタイプまたは異なるタイプのイベントの組合せに対
する関係を指定することができ、伝搬モードが選択され
た場合、イベントの通知を受け取るシーケンス内の各イ
ベント・ハンドラが、関係のあるいくつかのイベント信
号を伝搬するか、または全く伝搬しないかを決定するこ
とができる。

【００１１】本発明によれば、また、適用業務プログラ
ム、またはオペレーティング・システムの別の部分が、
イベントを定義する。各イベント定義は、イベントの発
生に対する若干のオペレーティング・システムを制御す
る、そのイベントの１つまたは複数の属性を含んでい
る。定義されたイベントの発生後、適用業務プログラ
ム、またはオペレーティング・システムの別の部分がイ
ベント・マネージャにその旨を通知する。イベント・マ
ネージャは対応するイベント定義を読み取って、そのイ
ベントのシグナラまたはイベント・シグナラに関連する
プロセスの動作モードを決定する。動作モードには、イ
ベントが処理されるまでイベント・シグナラまたは関連
プロセスが処理を中断する同期モードと、イベントの処
理中にイベント・シグナラまたは関連プロセスが処理を
継続できる非同期モードとが含まれる。イベント定義を
読み取った後、イベント・マネージャは、同期的に進め
るのかそれとも非同期的に進めるのかをイベント・シグ
ナラに知らせる。イベント処理後、中断されていたイベ
ント・シグナラが再開される。同期モードは、イベント
・ハンドラが「出口ルーチン」であるとき、特に有用で
ある。

【００１２】さらに、イベント定義は、現在そのイベン
トに関係のあるプログラムがないときに記憶されるいく
つかのイベント信号指定など他の属性を含み、イベント
定義がオペレーティング・システムの動作中を通じて動
的に受取りまたは更新できる。

【００１３】本発明によれば、また、適用業務プログラ
ム、またはオペレーティング・システムの別の部分が、
１つまたは複数のタイプのイベントを監視するイベント
・モニタを定義する。この定義は、イベント・モニタを
満足するために必要な上記１つまたは複数のタイプのイ
ベントの発生の組合せをも指定する。監視される各イベ
ントが発生するとき、イベント・モニタは、信号を受
け、イベント信号を記憶する。イベント・モニタは、そ
のイベント・モニタを満足する信号を記憶した時、（イ
ベント・ハンドラによる同時または事後の照会に従っ
て）イベント・ハンドラにその旨を通知することができ
る。その後、イベント・ハンドラは記憶されたイベント
信号にアクセスすることができる。

【００１４】本発明によれば、また、適用業務プログラ
ム、またはオペレーティング・システムの別の部分が、
それに代わって１つまたは複数のタイプのイベントを監
視するイベント・モニタを定義する。監視される各イベ
ントが発生した時、イベント・モニタは信号を受け取
り、イベント信号を記憶する。一定の条件の下で、イベ
ント・モニタはイベント・ハンドラに通知することがで
き、イベント・ハンドラは記憶されたイベント信号にア
クセスすることができる。イベント・モニタは、動的
に、すなわちコンピュータの動作中を通してコンピュー
タ・システムを停止または再結合することなく、定義し
確立することができる。あるイベントに関係のあるイベ
ント・モニタがない場合でも、そのイベントの信号が記
憶される。関係のあるイベント・モニタが後で確立され
た時、以前に記憶されたイベント信号が関係のあるイベ
ント・モニタに転送される。従って、イベント・ハンド
ラは以前のイベント信号の利益を享受できる。

【００１５】イベントはトレース・イベントであってよ
く、各イベント・モニタに関連するイベント・ハンドラ
は、トレース・イベントを実時間で受け取り処理するこ
とができる。

【００１６】

【実施例】これから図面を詳細に参照するが、図面全体
を通して同じ参照番号は同じ要素を指す。図１は、本発
明による多重タスク処理オペレーティング・システム１
１のイベント管理サービス部分を示す。このオペレーテ
ィング・システム１１は、磁気ディスクやテープなどの
コンピュータ可読媒体上に実行可能な形でプログラミン
グされ、コンピュータ・メモリ２１にロードされ、ＣＰ
Ｕ１９上で実行されることが好ましい。ただし、オペレ
ーティング・システム１１またはその一部分を、同等の
ハードウェアで実施することも可能である。

【００１７】オペレーティング・システム１１及び関連
する適用業務プログラムは、以下で詳細に述べる多くの
機能を提供する。これらの機能は、以下のカテゴリのグ
ループ分けすることができる。イベント定義、イベント
信号通知、イベント・モニタ作成、イベント監視、イベ
ント・モニタ処理及びイベント処理。

【００１８】イベント定義は、イベントを識別するため
のイベント名と、イベントに関するいくつかのオペレー
ティング・システム応答を制御するためのイベント属性
とを含む。オペレーティング・システムは定義されたイ
ベントだけを認識する。

【００１９】オペレーティング・システムまたは適用業
務プログラムは、イベントの発生を通信するためにイベ
ントを信号で通知する。イベント信号は、イベントを信
号で通知するプロセスと常に関連する。イベントは、そ
の信号がこのプロセスの内部でだけ認識されるように、
またはこのプロセスを含むセッション全体を通して認識
されるように定義することができる。イベント信号は、
イベントに関連するデータ、及びイベントの特定の発生
を指定するキー、またはイベント・データのソースなど
イベント・データのタイプのサブセットを含むことがで
きる。

【００２０】適用業務プログラム、またはオペレーティ
ング・システム１１内部の他の機能が、イベントの通知
及びイベント・データ（もしあれば）を受け取ることに
関与する場合、適用業務プログラムまたは他のオペレー
ティング・システム機能が、イベント・モニタを定義す
る。この定義は、イベント・モニタに関係のある、１つ
のイベント、または同じタイプもしくは異なるタイプの
イベントの組合せを指定する。本明細書で詳細に記述す
る本発明の実施例では、イベント・モニタを満足させる
ために同じタイプのイベントが２回以上発生する必要が
ある場合、イベント・タイプはイベント・モニタ定義中
で２回以上リストされる。（別法として、各イベント・
タイプをイベント・モニタ定義中で１回だけリストし、
イベント・モニタを満足させるために必要なタイプのイ
ベントの最低数を示すカウントを各イベント・タイプご
とに提供することもできる。）また、この定義で、イベ
ント・モニタに関係のあるイベント発生を制限するため
の、各イベント名付きのキーを指定することもできる。
イベント・モニタは、同じプロセス内の他のプログラム
・スレッドによって提供されるイベント信号、またはセ
ッション範囲によって定義されるイベントの信号を監視
することができる。またイベント・モニタ定義は、イベ
ント・モニタを「満足させる」ために必要な異なるイベ
ント信号の数または「カウント」、すなわち少なくとも
１回起こったはずの指定されたイベントの数を指定す
る。イベント・モニタが満足されたときだけ、イベント
・モニタは関連するイベント・ハンドラに記憶されたイ
ベント信号へのアクセスを許す。このようなアクセスを
提供するために、イベント・ハンドラはイベント・モニ
タに要求を行い、イベント・モニタが満足された場合、
イベント・モニタはイベント・ハンドラにイベント・モ
ニタが満足されたこと、及び記憶されたイベント信号の
位置を通知する。この要求は、ＥｖｅｎｔＴｒａｐ、Ｅ
ｖｅｎｔＷａｉｔ、またはＥｖｅｎｔＴｅｓｔ呼出しの
形をとることができる。イベント・モニタが満足された
という通知を受け取った後、イベント・ハンドラはイベ
ント・データを取り出し処理することができる。イベン
ト・データを解釈するこの方式は、イベント・シグナラ
とイベント・ハンドラの間の専用プロトコルに基づいて
おり、各名前付きイベントごとに別々に確立される。オ
ペレーティング・システム１１内部のイベント管理サー
ビスは、イベント通知及びイベント・データをイベント
・ハンドラに渡すためのチャネルを提供する。イベント
・ハンドラがイベント・データを取り出し処理した後、
イベント・モニタをリセットしてからでないと、イベン
ト・ハンドラは新しいイベント信号を取り出して処理す
ることができない。

【００２１】オペレーティング・システム１１内部のイ
ベント管理サービスは、イベント・デファイナ１２ａ、
ｂ、結果として得られるイベント定義１６ａ〜ｄ、イベ
ント・モニタ２８ａ〜ｄ、イベント・シグナラ１８ａ、
ｂ、及びイベント信号マネージャ２６を含む。図示され
ていないが、オペレーティング・システム１１はイベン
ト・モニタ・デファイナとイベント・ハンドラを含むこ
ともできる。図１は、オペレーティング・システム１１
上で走行する当該の各適用業務プログラム・スレッド内
部のイベント・デファイナ１３ａ、ｂ、イベント・シグ
ナラ１５ａ、ｂ、イベント・モニタ・デファイナ１７ａ
〜ｄ、及びイベント・ハンドラ１４ａ〜ｄをも示してい
る。前記の適用業務プログラム・スレッド１３ａ、ｂ、
１４ａ〜ｄ、１５ａ、ｂ及び１７ａ〜ｄはそれぞれ異な
るコンピュータ・プロセスの要素でもよいが、通常は、
イベント・モニタ・デファイナとイベント・ハンドラの
各対（１７ａ、１４ａ）、（１７ｂ、１４ｂ）、（１７
ｃ、１４ｃ）、（１７ｄ、１４ｄ）が同じプロセスの一
部分である。またイベント・デファイナとイベント・シ
グナラの各対は、同じプロセスの一部分であったり、オ
ペレーティング・システム１１の内部にあってもよく、
あるいはイベント・デファイナがオペレーティング・シ
ステム内部にあり、イベント・シグナラが適用業務プロ
グラムとしてオペレーティング・システムの外部にあっ
てもよい。

【００２２】次にオペレーティング・システム１１及び
関連する適用業務プログラム・スレッドの動作の高水準
の説明を行う。イベント・シグナラ１８ａ、ｂ及び１５
ａ、ｂは、イベントの発生を検出し、イベント信号マネ
ージャ２６にイベントの発生の指示、イベント名、イベ
ント・キー（すなわち、イベントに付随するイベント・
データのタイプのサブセット）、及び特定のイベント・
データを信号で通知する。これに応答して、イベント信
号マネージャは、信号で通知されたイベントの名前をイ
ベント定義１６ａ〜ｄ内のイベント名と比較して、その
名前付きイベントが定義されているかどうかを決定し、
定義されている場合、イベントの属性を読み取る。それ
らの属性は、イベント・シグナラが、他の作業に進む前
にイベントが処理されるのを待たなければならないの
か、それともイベント・シグナラがイベント処理中に他
の作業に進むことができなければならないのか、現在イ
ベントに関係のあるイベント・モニタがない場合に記憶
できるイベント信号の最大数、及びイベントに関係のあ
る複数のイベント・モニタに通知するための同報通信モ
ードまたは伝搬モードを示す。第１の属性に基づいて、
イベント信号マネージャはイベント・シグナラにイベン
ト処理が完了するのを待たせ、あるいはイベント処理が
完了する前にイベント・シグナラに処理を継続させる。
イベント信号マネージャはまた、イベント・モニタ２８
ａ〜ｄの定義を検討して、制限イベント・キーをもつ名
前付きイベントを参照する、すなわちそれに関係のある
１つまたは複数のイベント・モニタが定義されているか
どうかを決定する。定義されていない場合、イベント信
号マネージャは、イベント定義の第２の属性に従って、
イベント定義に結合されたイベント信号を記憶する。し
かし、少なくとも１つのイベント・モニタが、制限イベ
ント・キーを伴う名前付きイベントに関係がある場合、
イベント信号マネージャはイベント・モニタにイベント
通知及びイベント・データを信号で通知する。関係のあ
るイベント・モニタが２つ以上ある場合、イベント信号
マネージャはイベント定義で指定された同報通信モード
または伝搬モードで関係のあるイベント・モニタに信号
で通知する。イベント・モニタ定義は、関係のあるイベ
ント・ハンドラに後で送るためにイベント・モニタに結
合して記憶できる、リストされた各イベントの信号の最
大数と、イベント・モニタを「満足させる」ために必要
な異なるイベント信号の数を示す。満足された場合、信
号で通知された各イベント・モニタは、イベント・ハン
ドラから要求された時、要求された方式で、すなわち待
機モード、トラップ・モードまたはテスト・モードで、
当該の各イベント・ハンドラにイベントについて通知す
る資格がある。イベント・ハンドラはイベント通知に応
答し、イベント・データがあればそれを処理する。

【００２３】次に本発明についてより詳細に説明する。
オペレーティング・システムは、プロセス作成、プロセ
ス削除、開始コマンド、終了コマンド、コマンドが見つ
からない、リセット、プログラム・ロード、プログラム
・アンロード、コンソール出力完了、コンソール入力使
用可能、エラー、タイマ、トレース、入出力、会計イベ
ントなどのイベントを定義することができる。エラー・
イベントは、たとえばプログラム・チェック、接続の切
断、またはその他のシステム障害である。タイマ・イベ
ントはタイミング期間の終了である。トレース・イベン
トは、プログラム・サブルーチン、プログラムのスレッ
ドまたは重要ステップ（たとえば、データ・アクセス、
データ送信、新しいスレッドの指名、スレッドの中断な
ど）の完了である。会計イベントは、ユーザへの請求金
額を計算するコンピュータ・システムの使用である。適
用業務プログラムは、機能の完了、機能内のチェックポ
イント、データ作成、データ削除、適用業務プログラム
・エラー・イベント（たとえばユーザ入力エラー）、応
答活動の要求など、任意のタイプのイベントを定義する
ことができる。たとえば、適用業務プログラムがロボッ
トのアームを制御しようとする場合、適用業務プログラ
ムは、そのアームを移動する要求であるイベントを定義
し、その後でイベント、すなわちその要求を信号で通知
し、アームをどの方向にどれだけ移動するかを定義する
イベント・データを提供することができる。オペレーテ
ィング・システムまたは適用業務プログラムは、いつで
も、すなわちセッション初期設定中、イベントを検出す
るサービスの最初の呼出し時、またはその他のときに、
これらのイベントを定義することができる。各イベント
は、イベント信号マネージャ２６内でＥｖｅｎｔＣｒｅ
ａｔｅ機能４０を呼び出し、定義パラメータを指定する
ことによって定義される。イベント信号マネージャ２６
内部でのこの機能及び他の各機能の呼出しについては、
下記の「イベント信号マネージャ機能呼出し」と題する
節で詳細に説明する。

【００２４】呼出しのパラメータに基づいて、各イベン
ト定義１６ａ〜ｄは、イベント名及びイベントの重要な
属性または特性を含む。各イベント名は、イベント・デ
ファイナによって決定される長さ及び構成をもつ文字ス
トリングであり、イベントの主要な識別情報を提供す
る。属性には、イベント名の有効範囲、ルース信号限
界、関係のあるイベント・モニタ２８ａ〜ｄに信号で通
知するモード、及びイベント通知及び処理中の当該の各
イベント・シグナラ１５ａ、ｂまたは１８ａ、ｂの動作
状況が含まれる。イベント定義はまた、図１５及び図１
７を参照して下記で説明するイネーブル・フィールド及
び選択フィールドを含む。また、図２ないし４を参照し
て以下で詳細に説明するように、イベント・シグナラ
は、イベントをどのように管理するかを部分的に決定す
るために、名前付きイベントの属性を読み取る、イベン
ト信号マネージャ内のＥｖｅｎｔＳｉｇｎａｌ機能４９
を呼び出す。

【００２５】イベント名属性の有効範囲は、そのイベン
ト名が意味をもつ、単一のプロセスまたはセッション全
体を示す。イベント名がプロセスの範囲しかもたない場
合、イベントを定義したプロセスだけがそのイベントを
信号で通知することができ、イベント名を参照する、そ
のプロセス内で定義されたイベント・モニタだけにＥｖ
ｅｎｔＳｉｇｎａｌ機能によって信号で通知できる。し
かし、イベント名がセッション全体の範囲をもつ場合
は、どのプロセスがイベントを信号で通知したかにかか
わらず、そのイベント名を参照するすべてのイベント・
モニタに、イベント信号を受け取った後、ＥｖｅｎｔＳ
ｉｇｎａｌ機能によって信号で通知できる。セッション
全体の範囲をもつ各イベント名は、オペレーティング・
システム内で一義的でなければならないが、プロセスの
範囲をもつ各イベント名は、そのイベントを信号で通知
し監視するプロセス内でだけ一義的であればよい。

【００２６】ルース信号限界属性は、イベントが定義さ
れイベントが発生した後に、対応するイベント定義と関
連して、ただし現在イベントに関係のあるイベント・モ
ニタがない状況で、ＥｖｅｎｔＳｉｇｎａｌ機能の指令
で記憶される、イベント及び関連するイベント・データ
（「ルース信号」４１）の数である。イベント信号のル
ース信号限界に達した後、それ以後の各イベント信号
は、最も古いイベント信号が消去されてその位置に記憶
される。このルース信号の記憶は、そのイベントに関係
のあるイベント・モニタが後から定義でき、以前のイベ
ント信号から利益を得ることができるので、重要であ
る。

【００２７】信号通知モード属性は、同じイベントに関
係のある２つ以上のイベント・モニタに信号で通知する
方法を示す。同報通信モードでは、ＥｖｅｎｔＳｉｇｎ
ａｌ機能は、偶然でなしに、通常は実質的に同時に、関
係のあるすべてのイベント・モニタに信号で通知する。
関係のあるすべてのイベント・モニタが、イベントの性
質にかかわらずイベント通知及びイベント・データから
利益を得ることができるとき、イベント定義は、同報通
信モードを指示すべきである。たとえば、イベントがデ
ィスクからメモリにデータをロードすることであり、そ
のデータを読み取ることに関係のあるイベント・ハンド
ラが複数ある場合、任意選択の同時性を得るため、これ
らのイベント・ハンドラがオペレーティング・システム
によって指名されるように、イベントの発生後すぐに、
かつ偶然でなく、イベント通知及びイベント・データを
（関連するイベント・モニタを介して）イベント・ハン
ドラに同報通信するのが最も効率的である。ＦＩＦＯ
（先入れ先出し）伝搬モードでは、イベント・モニタは
各イベント・モニタの作成順に通知を受け、ＬＩＦＯ
（後入れ先出し）伝搬モードでは、イベント・モニタは
各イベント・モニタの作成順とは逆の順序で通知を受け
る。信号で通知される各イベント・モニタに関連するイ
ベント・ハンドラが、シーケンス内の次のイベント・モ
ニタにイベントの発生について信号で通知するかどうか
を制御する。これを実行するために、イベント信号を受
け取る各イベント・ハンドラは、現信号セット内の指定
されたイベント信号がシーケンス内の次のイベント・モ
ニタに伝搬できるように、ＥｖｅｎｔＭｏｎｉｔｏｒＲ
ｅｓｅｔ機能を呼び出す。またシーケンス内の各イベン
ト・ハンドラは、シーケンス内の次の（及び下流側のす
べての）イベント・モニタへの１つまたは複数のイベン
ト信号の伝搬を防止するために、ＥｖｅｎｔＤｉｓｃａ
ｒｄ機能を呼び出すことができる。イベント信号伝搬規
則は、プロセスごとに適用される。関係のあるイベント
・ハンドラが異なるプロセス中にあるときは、イベント
信号は、必ずこれらのプロセスのそれぞれにおいて少な
くとも１つのイベント・モニタに渡される。この制御に
ついては、下記で図１０及び図１１を参照してより詳細
に説明するが、それによって、イベント信号の伝搬によ
ってオペレーティング・システムが利益を得ないとイベ
ント・ハンドラが判断したとき、シーケンス内の各イベ
ント・ハンドラは、シーケンス内の以後のイベント・ハ
ンドラによるイベント・データの処理を回避することが
できる。たとえば、イベントが重大な障害であり、シー
ケンス内の第１のイベント・ハンドラの機能がこの障害
の性質を分析することであり、シーケンス内の次のイベ
ント・ハンドラの機能がこの障害から回復することであ
ると仮定する。回復が不可能なほど障害が重大である場
合、第１イベント・ハンドラは、シーケンス内の次のイ
ベント・ハンドラへのイベント信号の伝搬をブロックす
べきである。すなわち、このようなブロッキングの効果
は、オペレーティング・システムの全体的効率を向上さ
せることである。

【００２８】イベント定義内の動作状況属性は、Ｅｖｅ
ｎｔＳｉｇｎａｌ機能がイベント・モニタに信号で通知
し、イベント・モニタがイベント・ハンドラに通知し、
イベント・ハンドラがイベントに作用し、イベント・デ
ータを処理する間に、イベントを信号で通知するプロセ
スの同期的または非同期的処理を指す。たとえば、イベ
ントが、そのイベントを信号で通知したプロセス内での
エラーである場合、そのエラーが関係のあるイベント・
ハンドラによって回復されるまで、そのイベントを信号
で通知したプロセスを中断する（同期処理）ことが好ま
しいことがある。しかし、そのイベントがイベント・シ
グナラの正常な動作を表しており、イベント・シグナラ
がキーボード機能キーの押下など他の類似のイベントを
処理する準備ができているはずの場合（非同期処理）、
イベント・モニタが信号で通知を受け、イベント・ハン
ドラに通知し、イベント・ハンドラがイベント・データ
を処理する間、イベント・シグナラ・プロセスを中断す
べきではない。イベントが出口ルーチンの「呼出し」を
表す場合、その出口ルーチンを信号で通知した、または
呼び出したプロセスは、そのイベントが処理されるまで
中断すべきであり、そのイベント属性は同期処理を示す
べきである。出口ルーチンとは、ユーザ特有の機能また
は導入システム特有の機能を実行するために、オペレー
ティング・システム１１のユーザによって通常提供され
るコードのブロックである。このような機能は、その製
品の動作に対するオプション、追加または他の外部的な
ものでもよい。出口ルーチン・イベント用のイベント・
モニタが定義されていない場合、呼出し側プログラムは
実行を続け、システム障害はない。また、出口ルーチン
は、呼出し側プロセスの資源を出口ルーチンから保護す
るため、呼出し側とは異なるプロセス内に存在すること
ができる。イベント・ハンドラは出口ルーチンを提供す
ることができ、その場合、出口ルーチンが実行されるま
で制御は通常呼出し側に戻されない。したがって、出口
ルーチンは、同期属性をもつイベントとして定義すべき
である。

【００２９】イベント・モニタ・デファイナ１７ａ〜ｄ
（またはオペレーティング・システム１１内の、図示さ
れていない他のイベント・モニタ・デファイナ）は、Ｅ
ｖｅｎｔＭｏｎｉｔｏｒＣｒｅａｔｅ機能４２を呼び出
し、イベント・モニタ・パラメータを指定することによ
って、それぞれイベント・モニタ２８ａ〜ｄを定義す
る。各呼出しは、１つまたは複数のイベント名、当該の
イベント・キー、イベント・モニタを満足させるための
当該イベントの発生回数、及び各イベントに対する結合
信号限界及びイベント・モニタのその他の属性を識別す
る。イベント・キーは、イベント・モニタがすべてのタ
イプの名前付きイベントに関係があることを示す「ワイ
ルドカード」でも、それらのタイプの名前付きイベント
のサブセットでもよい。またイベント・モニタ定義は、
下記のイネーブル、選択、削除、待機及びトラップ・フ
ィールドを含む。上記のように、イベント・シグナラか
らイベント名及びイベント・キーを受け取り、名前付き
イベントがすでに定義済みであることを検証した後、Ｅ
ｖｅｎｔＳｉｇｎａｌ機能はイベント・モニタ定義を読
み取り、どのイベント・モニタ定義（もしあれば）がイ
ベント名及びキーを記述しているかを決定する。１つま
たは複数のそのようなイベント・モニタが定義済みであ
る場合、ＥｖｅｎｔＳｉｇｎａｌ機能はイベント定義中
で指定された同報通信モードまたは伝搬モードでそれら
のイベント・モニタを呼び出す。

【００３０】イベント・キーを使用すると、入力キーの
押下、メモリへのディスクのロードなど、一般イベント
名をリストできるイベントの定義が簡単になり、イベン
ト・モニタ定義は、イベント・モニタ定義内のキーに基
づいてイベント・モニタへのイベント信号通知を制限す
る。たとえば、イベント・モニタ・キーを、特定の１組
の文字キーまたはロードされたディスクのタイプのみに
制限することができる。

【００３１】上記にリストしたイベント・モニタ定義中
の次の属性である、イベント・モニタを満足させるのに
必要な異なるイベント信号の数またはカウントが、イベ
ント・モニタに、イベント・モニタ定義中で指名され
た、指定された数の異なるイベントが発生するまで、関
連するイベント・ハンドラへのイベント信号の通知を抑
えさせる。たとえば、通信エラーを回復する機能をもつ
イベント・ハンドラは、以後の分析を正当化するため、
合計１０個の通信機能エラーまたはパリティ・エラーあ
るいはその両方が発生したときだけ、そのようなエラー
の通知を受け取ることに関与し、それ以下の数の通信エ
ラーは、回復を開始するほど重大とは判断されない。本
発明のこの実施例では、通信エラーが１０回リストさ
れ、パリティ・エラーが１０回リストされ、カウントが
１０に指定されている場合、どちらか一方または両方の
タイプのエラーが合計１０回発生している限り、指定さ
れた各タイプのエラーの数の内訳は、イベント・モニタ
を満足させるのに重要ではない。しかし、通信エラーが
５回リストされ、パリティ・エラーが５回リストされ、
カウントが１０である場合は、イベント・モニタを満足
させるために各タイプのイベントが５回発生しなければ
ならない。このように、イベント・モニタ・デファイナ
は、イベント・モニタを満足させるために必要な、関係
のある各タイプのイベントの特定の発生回数を指定する
ことができる。

【００３２】上記にリストしたイベント・モニタ定義中
の最後の属性である結合信号限界は、関係のあるイベン
ト・モニタの指令で、関係のあるイベント・モニタ内の
指名された各イベントと結合してまたは関連づけて記憶
できる、未処理のイベント信号の数である。この限界を
超えたとき、最も古い結合イベント信号が消去され、最
新のイベント信号がイベント・モニタに結合される。た
とえば、固定数のトレース・イベント及びデータの記憶
に対する結合信号限界は、イベント状態の障害追求を行
う助けとして有用であるが、追加のより古いトレース・
データは、現在の問題を反映しないので、役立たないこ
とがある。結合信号は、結合信号セット４７内に記憶さ
れる。イベント・モニタが満足され、イベント・ハンド
ラがイベント通知を要求するとき、イベント・モニタ
は、イベント・ハンドラがアクセスすべき現信号セット
４５として、最も古い異なる結合イベント信号を指定す
る。イベント・モニタを満足させるために同じタイプの
イベントの発生が２回以上必要な場合、現信号セット
は、少なくともイベント・モニタを満足させるために必
要な数の、そのタイプのイベント信号を含む。

【００３３】イベント・モニタ定義中のもう１つの属性
は、イベント・モニタが、作成されたとき、そのイベン
ト・モニタの作成前に発生し、ルース信号セット内に記
憶された、そのイベント・モニタが関係のあるタイプの
信号を受け取るべきか否かを指定するものである。受け
取るべき場合は、ルース信号がイベント・モニタの作成
時に結合信号セット４７に転送される。イベント・モニ
タ定義中のさらに別の属性は、イベント・モニタが満足
された後、及びイベント・ハンドラがイベント通知を受
け取りそのイベントを処理する間に、イベント・ハンド
ラと同じプロセス内の他のプログラム・スレッドを中断
すべきか否かを指定するものである。イベントが、異常
終了を必要とするシステム障害、またはイベント・ハン
ドラにプロセス全体の「スナップショット」を取らせる
イベントである場合は、他のプログラム・スレッドの実
行を中断することが重要である。

【００３４】先に指摘したように、通常、各イベント・
モニタ・デファイナ及び関連するイベント・ハンドラは
同じプロセスの一部分であって、あるプロセスが１つの
イベントまたは複数のイベントの組合せを監視し、その
イベントまたは組合せを処理しようとするとき、そのプ
ロセスがイベント・モニタを定義し、関連するイベント
・ハンドラを提供する。このイベント・ハンドラは、イ
ベント・ハンドラによるＥｖｅｎｔＴｅｓｔ、Ｅｖｅｎ
ｔＴｒａｐまたはＥｖｅｎｔＷａｉｔ機能の呼出しに基
づいて通知を受ける。このプロセスはイベント・モニタ
を定義または削除し、動的に、すなわちいつでも、Ｅｖ
ｅｎｔＭｏｎｉｔｏｒＣｒｅａｔｅまたはＥｖｅｎｔＭ
ｏｎｉｔｏｒＤｅｌｅｔｅ機能及びＥｖｅｎｔＴｅｓ
ｔ、ＥｖｅｎｔＴｒａｐまたはＥｖｅｎｔＷａｉｔ機能
を呼び出すことによって、他のプログラムを再連係また
は割り込むことなしに、イベント・ハンドラと関与する
ことができる。また、複数のプロセスが、複数のイベン
ト・モニタを定義し、同じまたは異なるイベントまたは
複数のイベントの組合せ用の複数のイベント・ハンドラ
を提供することもできる。

【００３５】呼出しを受け取った後、ＥｖｅｎｔＭｏｎ
ｉｔｏｒＣｒｅａｔｅ機能は、その呼出し内のすべての
パラメータを読み取り記憶する（図２０の段階８０）。
次に、ＥｖｅｎｔＭｏｎｉｔｏｒＣｒｅａｔｅ機能は、
ルース信号を結合すべきことをイベント・モニタ・フラ
グ・パラメータが示すかどうかを判定する（判断ブロッ
ク８２）。イエスの場合、ＥｖｅｎｔＭｏｎｉｔｏｒＣ
ｒｅａｔｅ機能は、イベント・モニタにとって関係のあ
る各イベントの定義に関連するルース信号セットを読み
取って、イベント・モニタにとって関心のある制限キー
をもつルース信号（「適格イベント」）があるかどうか
決定する。イベント・モニタにとって関係があるために
は、ルース信号は、セッション範囲をもつか、またはプ
ロセス範囲をもたなければならず、そのイベントはイベ
ント・モニタを定義したのと同じプロセスによって定義
される。以前にイベントの発生がなかった場合、または
別のイベント・モニタがそのイベントに関与するように
以前に定義されていた場合、ルース信号はない。関係の
あるルース信号がある場合、ＥｖｅｎｔＭｏｎｉｔｏｒ
Ｃｒｅａｔｅ機能は、これらすべてのルース信号をイベ
ント・モニタに転送し（段階８６）、イベント・モニタ
は、下記で図２の段階１１５を参照して述べる結合限界
に従って、それらのルース信号をそれ自体に結合する。
その後、ＥｖｅｎｔＭｏｎｉｔｏｒＣｒｅａｔｅ機能
は、その呼出し側に戻る（段階８８）。

【００３６】イベント・モニタ・デファイナ１７ａ〜ｄ
がイベント・モニタを定義した後はいつでも、関連する
イベント・ハンドラは、そのイベント・モニタが満足さ
れたとき通知を要求することができる。要求のタイプに
は、テスト・モード、トラップ・モード、及び待機モー
ドがあり、イベント・ハンドラはＥｖｅｎｔＴｅｓｔ機
能５０、ＥｖｅｎｔＴｒａｐ機能５２、またはＥｖｅｎ
ｔＷａｉｔ機能５４の呼出しによって所望のモードを選
択する。各呼出しの効果は、当該のイベント・モニタの
状態に依存する。

【００３７】イベント・モニタがまだ満足されていない
場合、以下のことが起こる。

【００３８】１）ＥｖｅｎｔＴｅｓｔ機能は、イベント
・ハンドラによって呼び出された場合、イベント・ハン
ドラに各イベント名／イベント・キー対（イベント・ハ
ンドラに関連するイベント・モニタで参照される）の状
態、すなわち当該のキーを伴う名前付きイベントが発生
したのか、それとも削除されたのかを報告する。

【００３９】２）ＥｖｅｎｔＷａｉｔ機能は、イベント
・ハンドラによって呼び出された場合、イベント・モニ
タが満足されるまでそのイベント・ハンドラを中断す
る。満足されたとき、イベント・モニタはイベント・ハ
ンドラを覚醒させ、各イベント名／イベント・キー対の
状態を報告する。

【００４０】３）ＥｖｅｎｔＴｒａｐ機能は、イベント
・ハンドラによって呼び出された場合、イベント・モニ
タが満足されたときにトラップ・ルーチンを実行するよ
うにとオペレーティング・システムに知らせる。オペレ
ーティング・システムは、どの環境でトラップ・ルーチ
ンが実行されるかを知らないので、イベント・モニタの
状態に関する情報は最初トラップ・ルーチンに渡されて
いない。したがって、イベント・モニタが満足されたと
き、イベント・モニタはトラップ・ルーチンを呼び込
み、トラップ・ルーチンはＥｖｅｎｔＴｅｓｔ機能を呼
び出して、各イベント名／イベント・キー対の状態に関
する報告を得る。イベント・モニタが満足されたとき、
ＥｖｅｎｔＴｒａｐ機能及びＥｖｅｎｔＷａｉｔ機能の
両方が呼び出されている場合は、ＥｖｅｎｔＷａｉｔ機
能が優先され、トラップ・ルーチンは実行されない。

【００４１】イベント・モニタが満足されたが、まだ活
動化されていない（すなわち、イベント・ハンドラから
イベント通知をまだ要求されていない）場合は、以下の
ことが起こる。

【００４２】１）ＥｖｅｎｔＴｅｓｔ機能は、イベント
・ハンドラによって呼び出された場合、イベント・モニ
タを活動化し、イベント・モニタに現信号セットを確立
させ、イベント・ハンドラに各イベント名／イベント・
キー対の状態を報告させる。

【００４３】２）ＥｖｅｎｔＷａｉｔ機能は、イベント
・ハンドラによって呼び出された場合、イベント・モニ
タを活動化し、イベント・モニタに現信号セットを確立
させ、イベント・ハンドラを覚醒させ、各イベント名／
イベント・キー対の状態を報告させる。

【００４４】３）ＥｖｅｎｔＴｒａｐ機能は、イベント
・ハンドラによって呼び出された場合、イベント・モニ
タに現信号セットを確立させ、指定されたトラップ・ル
ーチンを実行させる。

【００４５】ＥｖｅｎｔＷａｉｔ機能、ＥｖｅｎｔＴｒ
ａｐ機能またはＥｖｅｎｔＴｅｓｔ機能の呼出しの結
果、イベント処理プログラムが実行している間、（イベ
ント・モニタが満足され、イベント・ハンドラがイベン
ト通知を要求した後）イベント・モニタは「活動状態」
である。イベント・モニタが現在活動状態である場合、
以下のことが起こる。

【００４６】１）ＥｖｅｎｔＴｅｓｔ機能は、イベント
・ハンドラによって呼び出された場合、イベント・ハン
ドラに各イベント名／イベント・キー対の状態を報告す
る。

【００４７】２）ＥｖｅｎｔＷａｉｔ機能は、イベント
・ハンドラによって呼び出された場合、イベント・モニ
タをリセットし、イベント・モニタが再び満足されるま
でイベント・ハンドラを中断する。

【００４８】３）ＥｖｅｎｔＴｒａｐ機能は、イベント
・ハンドラによって呼び出された場合、イベント・モニ
タを使ってトラップ・ルーチンのアドレスを監視し、こ
のイベント・モニタと以前に関連していたすべてのトラ
ップ・ルーチンのアドレスを上書きする。

【００４９】イベント・モニタが活動状態であるとき、
それが監視する新しいイベント信号は、まだイベント・
モニタに結合されており、ＥｖｅｎｔＭｏｎｉｔｏｒＲ
ｅｓｅｔ機能６２が実行された後にイベント・モニタに
よって処理される。その後で、イベント・モニタは残り
の結合信号を検査し、それらの結合信号がイベント・モ
ニタを満足させるのに十分である場合、イベント・モニ
タは再び活動化する資格を得る。

【００５０】図２は、イベント・ハンドラがＥｖｅｎｔ
Ｗａｉｔ機能５４を呼び出すときの、オペレーティング
・システム１１、具体的にはＥｖｅｎｔＳｉｇｎａｌ機
能４９、イベント・モニタ２８ａ及びイベント・ハンド
ラ１４ａの動作を示す流れ図である。段階９０の間、オ
ペレーティング・システム内部のイベント・デファイナ
１２ａが（セッションの範囲で）イベントＡを定義する
が、適用業務プログラム内部のイベント・デファイナ１
３ａもイベントＡを定義できたはずである。たとえば、
イベントＡは、ある文字キーの押下とそれに続くキーボ
ード上の入力キーの押下である。同時にまたは後で、適
用業務プログラム内部のイベント・モニタ・デファイナ
１７ａが、ＥｖｅｎｔＭｏｎｉｔｏｒＣｒｅａｔｅ機能
を呼び出すことによって、イベントＡに関係のあるイベ
ント・モニタ２８ａを定義する（段階９２）。その後、
イベント・ハンドラ１４ａが、ＥｖｅｎｔＷａｉｔ機能
５４を呼び出して、イベント・モニタ２８ａがイベント
について信号で通知されるのをイベント・ハンドラが同
期的に待つことを示し、イベント・データをどこに記憶
すべきかをＥｖｅｎｔＷａｉｔ機能に知らせる（段階９
４）。この呼出しに応答して、ＥｖｅｎｔＷａｉｔ機能
は、イベント・モニタ２８ａ内の待機ビットをセット
し、イベント・モニタ２８ａによって呼出し側（イベン
ト・ハンドラ１４ａ）をリストし（段階９５）、イベン
ト・ハンドラを、他の動作を実行せずに（段階９４）イ
ベント通知を待つスリープ・モードにする。その後、人
が文字キーを押し、続いて実行キーを押し、キーボード
を連続的に監視するサブルーチン（イベント・シグナラ
１８ａ）がこれらのキーの押下を検出する。これに応答
して、イベント・シグナラ１８ａが、ＥｖｅｎｔＳｉｇ
ｎａｌ機能４９を呼び出し、イベント名、制限キー（も
しあれば）、及びイベント・データを提供する（段階１
００）。ＥｖｅｎｔＳｉｇｎａｌ機能４９が、イベント
定義１６ａ〜ｄを読み取って、イベントＡがイベント・
シグナラ１８ａと同じプロセス範囲またはセッション範
囲で定義されているかどうか判定する（段階１０２及び
判断ブロック１０４）。ノーの場合、ＥｖｅｎｔＳｉｇ
ｎａｌ機能はエラー・コードをイベント・シグナラに返
す（段階１０５）。しかし、図２の例では、イベントＡ
はセッション範囲で定義されており、ＥｖｅｎｔＳｉｇ
ｎａｌ機能は判断ブロック１０６でイベント定義がオン
に選択されたことを知る（下記で図１７を参照して説明
する）。次に、ＥｖｅｎｔＳｉｇｎａｌ機能は、イベン
ト定義属性に基づいて、そのイベントが処理されるまで
イベント・シグナラを停止す（同期処理）べきか否かを
決定し（判断ブロック１０７）、イエスの場合、イベン
ト・シグナラを停止させる（段階１０８）。いずれの場
合も、ＥｖｅｎｔＳｉｇｎａｌ機能は次にイベント・モ
ニタ定義２８ａ〜ｄを読み取って、イベントＡに関係が
あるイベント・モニタがあるかどうか、及び制限キー
（もしあれば）がイベント・モニタの関係を制限するか
どうかを決定する（段階１０９及び判断ブロック１１
０）。そのイベント及び制限キーに関係があるイベント
・モニタがない場合、ＥｖｅｎｔＳｉｇｎａｌ機能は、
ルース信号限界に従って信号をイベント定義に結合する
（段階１１１）。ルース信号限界にすでに達している場
合、最も古いルース信号が放棄される。制限キーを伴う
そのイベント名に関係のあるイベント・モニタが１つま
たは複数あり、それがオンに選択されている場合（判断
ブロック１１２）、イベント定義が同報通信モード属性
を指定しているならば（段階１１４ａ）、ＥｖｅｎｔＳ
ｉｇｎａｌ機能はイベント信号（イベント名及びイベン
ト・データ）をそれらすべてにほぼ同時に提供し、イベ
ント定義が伝搬モード属性を指定しているならば（段階
１１４ｂ）、シーケンス内の第１のイベント・モニタに
提供する。図２の例では、制限キーを伴う名前付きイベ
ントに関係があり、オンに選択されているイベント・モ
ニタは１つしかない。しかし、制限キーを伴うイベント
に関係のあったすべてのイベント・モニタがオフに選択
された場合は、これらのイベント・モニタは通知を受け
ず、イベント信号はルース信号セット４１内のイベント
定義に結合されることになる（段階１１１）。信号で通
知されたイベント・モニタ２８ａは、イベント信号を結
合信号セット４７に記憶することによって、イベント信
号をそれ自体に結合する。次に、イベント・モニタは、
結合信号セット４７内に記憶された異なるイベント信号
の数を、イベント・モニタ定義内の"event_count"フィ
ールドと比較することによって、イベント・モニタが満
足されているかどうかを決定する（段階１１６）。イベ
ント・モニタを満足させるには、イベント・モニタに関
係のあるイベントの異なる信号が、イベント・カウント
によって示される数だけ発生しなければならない。先に
指摘したように、１つのタイプのイベントが、イベント
・モニタ定義内で２回以上リストできる。上述した本発
明の代替実施例では、段階１１６で、イベント・モニタ
は、イベント・モニタを満足させるために各イベント・
タイプが指定された回数だけ発生したかどうか判定す
る。イベント・モニタがまだ満足されていない場合、イ
ベントＡのこの発生の結果として、イベント・モニタま
たは関連するイベント・ハンドラはそれ以上の処置を取
らない。しかし、イベント・モニタが満足された場合
は、イベント・モニタは先に進んで、待機ビットを読み
取ることによって、未処理のＥｖｅｎｔＷａｉｔ呼出し
があるかどうか決定する（判断ブロック１１７）。この
例では、待機ビットは段階９５でセットされ、イベント
・モニタは先に進んで、結合信号セット４７からすべて
の異なる信号を指定することによって、現信号セット４
５を確立し（段階１１８）、ＥｖｅｎｔＷａｉｔ機能に
よってリストされたイベント・ハンドラを覚醒させる
（段階１１９）。覚醒すると、イベント・ハンドラは、
呼出し側がイベント・モニタである（以下に説明するＥ
ｖｅｎｔＭｏｎｉｔｏｒＤｅｌｅｔｅ機能ではない）と
決定し（判断ブロック１１２０）、現信号セット内に記
憶された英数字データを取り出すためにＥｖｅｎｔＲｅ
ｔｒｉｅｖｅ機能５６を呼び出し（段階１１２１）、次
にイベント・データを処理する（段階１１２２）。次
に、いずれかのイベントに関係のある他のイベント・モ
ニタがあるかどうかをイベント・ハンドラ１４ａが知る
必要がなくても、またイベント定義が伝搬モードを指定
していても、イベント・ハンドラは、現信号セット内の
いずれかまたはすべてのイベント信号を伝搬のために使
用可能にすべきか、それともどのイベント信号も使用可
能にすべきではないかを決定する。いずれかまたはすべ
てのイベント信号を伝搬のために使用可能にしたくはな
い場合、イベント・ハンドラ１４ａはＥｖｅｎｔＤｉｓ
ｃａｒｄ機能５８を呼び出し、イベント・モニタ２８
ａ、及び現信号セット内のいずれかまたはすべてのイベ
ント信号を放棄するように指定する。これによって、イ
ベント・モニタ２８ａの現信号セットからの指定された
イベント信号の伝搬がブロックされる（段階１１２
５）。

【００５１】呼び出されたとき、ＥｖｅｎｔＤｉｓｃａ
ｒｄ機能は、名前付きイベント・モニタ２８ａの現信号
セットから指定された信号を消去する（図５の段階１８
６）。次に、ＥｖｅｎｔＤｉｓｃａｒｄ機能は、信号で
通知されたイベント定義のこの属性に従って、放棄され
たイベント信号のイベント・シグナラが待機状態にある
か否か判定し、待機状態にある場合は、イベント・シグ
ナラを覚醒させる（判断ブロック１８８及び段階１９
０）。次に、ＥｖｅｎｔＤｉｓｃａｒｄ機能は、イベン
ト・ハンドラに戻る（段階１９１）。段階１９１の後、
またはイベント・ハンドラがすべてのイベント信号を伝
播のために使用可能にしたことを判断ブロック１１２４
が示す場合、イベント・ハンドラは図６に示すＥｖｅｎ
ｔＭｏｎｉｔｏｒＲｅｓｅｔ機能を直接呼び出すことが
でき、またはイベント・モニタに戻って、イベント・モ
ニタが次にＥｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ機能を
呼び出すことができる。イベント・ハンドラはまたそれ
自体を終了することができ、その場合は、その終了を助
ける機能がＥｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ機能を
呼び出す。通常、イベント・ハンドラは、段階１１２０
〜１１２５の後でイベント・モニタに戻る。イベント・
ハンドラは、たとえばトラップ・ルーチンに再び入る、
またはＥｖｅｎｔＴｅｓｔ機能を使ってイベント・モニ
タを継続的にポーリングさせるために、ＥｖｅｎｔＭｏ
ｎｉｔｏｒＲｅｓｅｔ機能を呼び出して、処理の時期尚
早な終了を示すだけである。また、イベント・モニタは
イベント・ハンドラと関連づけられているので、イベン
ト・ハンドラが終了したとき、イベント・ハンドラはＥ
ｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ機能を間接的に呼び
出す。

【００５２】図６の段階１７２で、ＥｖｅｎｔＭｏｎｉ
ｔｏｒＲｅｓｅｔ機能は、現信号セットを読み取って、
残りの信号を識別する。現信号セットは、判断ブロック
１１２４から段階１１２６に直接進む場合は、満杯であ
るが、イベント・ハンドラが段階１１２５でＥｖｅｎｔ
Ｄｉｓｃａｒｄ機能を呼び出した場合は、部分的にまた
は完全に空である。現信号セットが空でない場合（判断
ブロック１７３）、ＥｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅ
ｔ機能は、現信号セット内の各イベント信号のイベント
定義を読み取って、関係がある他のイベント・モニタの
信号通知モードを決定する（段階１７６）。各イベント
信号について、信号通知モードが同報通信モードである
場合（判断ブロック１７７）、ＥｖｅｎｔＭｏｎｉｔｏ
ｒＲｅｓｅｔ機能は段階１８０に進み、（関係のある他
のイベント・モニタがイベント信号をすでに受け取った
ので）ＥｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ呼出し中で
指名されたイベント・モニタの現信号セットからイベン
ト信号を消去する。しかし、イベント定義がいずれかの
イベント信号についてＦＩＦＯまたはＬＩＦＯ伝搬モー
ドを示す場合は、判断ブロック１７７から段階１７４に
進み、そこでＥｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ機能
が他のイベント・モニタ定義を読み取って、そのイベン
ト信号に関係のあるものがあるか否かを判定する（段階
１７４）。イエスの場合（判断ブロック１７５）、Ｅｖ
ｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ機能は、当該のイベン
ト信号に関するシーケンス内の次のイベント・モニタに
信号で通知し、段階１８０に進む。このようにして、伝
搬モード用に定義されているイベントに関する現信号セ
ット内に残っているイベント信号が、各イベントに関す
るシーケンス内の次のイベント・モニタに伝搬される。
また、そのイベント・モニタは図２ないし４に示す段階
１１５〜１１９のシーケンスを実行し、当該のイベント
・ハンドラが段階１１２０〜１１２６を実行する。段階
１８０の後で、ＥｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ機
能は、下記で説明するようにイベント・モニタ２８ａが
削除のためにマークされているか否かを判定する（判断
ブロック１８１）。イエスの場合、ＥｖｅｎｔＭｏｎｉ
ｔｏｒＲｅｓｅｔ機能は、下記で説明するＥｖｅｎｔＭ
ｏｎｉｔｏｒＤｅｌｅｔｅ機能６８を呼び出す（段階１
８５）。ノーの場合、またはＥｖｅｎｔＭｏｎｉｔｏｒ
Ｄｅｌｅｔｅ機能からの戻りを受け取った後、Ｅｖｅｎ
ｔＭｏｎｉｔｏｒＲｅｓｅｔ機能はその呼出し側に戻る
（段階１８２）。

【００５３】図７は、イベント・ハンドラ１４ｃがＥｖ
ｅｎｔＴｅｓｔ機能を呼び出すときのオペレーティング
・システム１１の動作を示す流れ図である。段階１５０
で、イベント・デファイナ１２ｂまたは１３ｂがイベン
トＢを定義する。同時にまたは後で、イベント・モニタ
・デファイナ１７ｂが、イベントＢに関係のあるイベン
ト・モニタ２８ｂを定義する（段階１５１）。次に、イ
ベント・ハンドラ１４ｂが、ＥｖｅｎｔＴｅｓｔ機能５
０を呼び出して、イベント・モニタ２８ｂに関する状況
情報を要求する（段階１５３）。これに応答して、Ｅｖ
ｅｎｔＴｅｓｔ機能がイベント・モニタ２８ｂを見つけ
（判断ブロック１５４）、イベント・モニタ２８ｂの結
合信号セットを読み取り（段階１５５）、次いでイベン
ト・モニタ２８ｂが満足されたか否かを判定する（段階
１５６）。イエスの場合、ＥｖｅｎｔＴｅｓｔ機能はイ
ベント・モニタを活動化し、現信号セットを確立する
（段階１５７）。段階１５８でイベント・モニタがＥｖ
ｅｎｔＴｅｓｔ機能に戻った後、またはイベント・モニ
タが満足されなかった場合、ＥｖｅｎｔＴｅｓｔ機能
は、イベント・モニタが満足されたか否か、イベント・
モニタが満足されたときどのイベント信号が現信号セッ
ト内にあるか、及び各信号の長さをイベント・ハンドラ
１４ｂに知らせる（段階１５８）。イベント・モニタ２
８ｂが満足された場合（判断ブロック１６０）、イベン
ト・ハンドラはＥｖｅｎｔＲｅｔｒｉｅｖｅ機能を呼び
出してイベント・データを得（段階１６４）、データを
処理し（段階１６６）、次いで上記の段階１１２４〜１
１２６を実行する。しかし、イベント・モニタが満足さ
れなかった場合は、イベント・ハンドラは段階１６４、
１６６及び１１２４〜１１２６を回避し、他の作業を実
行することができる。

【００５４】図８、９は、ＥｖｅｎｔＴｒａｐ機能５２
が呼び出されたときのオペレーティング・システム１１
の動作を示す流れ図である。段階１３０で、オペレーテ
ィング・システム１１内のイベント・デファイナ１２ｂ
または適用業務プログラム内のイベント・デファイナ１
３ｂが、イベントＣを定義する。同時にまたは後で、イ
ベント・モニタ・デファイナ１７ｃが、イベントＣに関
係のあるイベント・モニタ２８ｃを定義する（段階１３
１）。次に、イベント・ハンドラ１４ｂがＥｖｅｎｔＴ
ｒａｐｔ機能５２を呼び出して、イベント・モニタが満
足されたとき、イベント・モニタ２８ｃがイベント・ハ
ンドラ１４ｃ内のトラップ・ルーチンに通知すべきこ
と、及びトラップ・ルーチンの名前またはアドレスを指
定する（段階１３２）。段階１３２の後で、イベント・
ハンドラ１４ｂは他の作業を実行することができ、イベ
ント・トラップ・モードで遊休状態でイベント通知を待
つことはない。この呼出しに応答して、ＥｖｅｎｔＴｒ
ａｐ機能はイベント・トラップ・ビットをセットし、イ
ベント・モニタ２８ｃを使ってトラップ・ルーチンの名
前またはアドレスをリストする（段階１３３）。その
後、イベントＣが発生し、イベント・シグナラ１８ｂま
たは１５ｂがＥｖｅｎｔＳｉｇｎａｌ機能４９を呼び出
す（段階１３４）。次に、ＥｖｅｎｔＳｉｇｎａｌ機能
が上記の段階１０２〜１１４を実行し、イベント・モニ
タは上記の段階１１５〜１１７を実行するが、段階１１
７はイベント待機ビットがセットされていないことを示
す。したがって、イベント・モニタは先に進んで、イベ
ント・トラップ・ビットがセットされていると判定し
（判断ブロック１２０）、イベント・ハンドラ１４ｃ内
部のトラップ・ルーチンを呼び出す（段階１２２）。ト
ラップ・ルーチンは、図７に示すＥｖｅｎｔＴｅｓｔ機
能５０を呼び出して、イベント・モニタ、イベント名及
びイベント・キーを指定する（段階１３８）。次に、Ｅ
ｖｅｎｔＴｅｓｔ機能が上記の段階１５４〜１５８を実
行する。ＥｖｅｎｔＴｅｓｔ機能から受け取った情報に
基づいて、トラップ・ルーチンはイベント・モニタが見
つかったと判定する（判断ブロック１３９）。次に、ト
ラップ・ルーチンは、ＥｖｅｎｔＲｅｔｒｉｅｖｅ機能
を呼び出して、現信号セットからイベント・データを取
り出し（段階１４０）、イベント・データを処理し（段
階１４２）、上記の段階１１２４〜１１２６を実行す
る。トラップ・ルーチンがイベント・モニタをリセット
せずに戻った場合、イベント・モニタは、イベント・ハ
ンドラから戻りを受け取ったとき、ＥｖｅｎｔＭｏｎｉ
ｔｏｒＲｅｓｅｔ機能を呼び出す（段階１２８）。

【００５５】図１０は、２つの関係のあるイベント・モ
ニタへのイベント信号の同報通信を示す流れ図である。
段階３８０で、イベントＨが定義される。この定義に
は、イベントの名前、及び関係のあるすべてのイベント
・モニタに同報通信モードで、すなわち実質的に同時に
通知すべきであるとの指示が含まれる。同時にまたは後
で、イベント・モニタ・デファイナ１７ａが、イベント
Ｈに関係のあるイベント・モニタ２８ａを定義し（段階
３８２）、イベント・モニタ・デファイナ１７ｂが、や
はりイベントＨに関係のあるイベント・モニタ２８ｂを
定義する（段階３８４）。次に、イベント・ハンドラ１
４ａは、ＥｖｅｎｔＷａｉｔ機能を呼び出し、それ自体
をスリープ・モードにして、イベントＨの通知を待つ
（段階３８６）。ＥｖｅｎｔＷａｉｔ機能が、イベント
・モニタ２８ａ用の待機ビットをセットし、イベント・
モニタ２８ａの呼出し側をリストする（段階３８７）。
同様に、イベント・ハンドラ１４ｂは、ＥｖｅｎｔＷａ
ｉｔ機能を呼び出し、それ自体をスリープ・モードにし
て、イベントＨの通知を待つ（段階３８８）。Ｅｖｅｎ
ｔＷａｉｔ機能は、イベント・モニタ２８ｂ用の待機ビ
ットをセットし、イベント・モニタ２８ｂの呼出し側を
リストする（段階３８９）。その後、イベントＨが発生
し、イベント・シグナラはＥｖｅｎｔＳｉｇｎａｌ機能
４９を呼び出す（段階３９０）。これに応答して、Ｅｖ
ｅｎｔＳｉｇｎａｌ機能が上記の段階１０２〜１１４を
実行し、段階１０２で、同報通信モードが指定されてい
ると判定する。段階１１０で、ＥｖｅｎｔＳｉｇｎａｌ
機能は、２つのイベント・モニタ２８ａ及び２８ｂがと
もにイベントＨに関係があることを知る。段階１１４ａ
で、ＥｖｅｎｔＳｉｇｎａｌ機能は両方のイベント・モ
ニタにほぼ同時に信号で通知するが、どちらのイベント
・モニタも他のイベント・モニタへの信号通知を妨げる
ことはできない。イベント信号を受け取った後、イベン
ト・モニタ２８ａは段階１１５〜１１９を実行し、関連
するイベント・ハンドラ１４ａが上記の段階１１２０〜
１１２６を実行する。同様に、イベント信号を受け取っ
た後、イベント・モニタ２８ｂは段階１１５〜１１９を
実行し、関連するイベント・ハンドラ１４ｂが上記の段
階１１２０〜１１２６を実行する。当該のイベント・モ
ニタ２８ａ及び２８ｂが段階１２８を実行する。したが
って、イベントＨが発生した後、イベント・ハンドラ１
４ａ及び１４ｂはともにイベント通知及びイベント・デ
ータをほぼ同時に受け取り、どちらのイベント・ハンド
ラも他のイベント・ハンドラがイベント通知及びイベン
ト・データを受け取ることを妨げることはできない。

【００５６】図１１は、シーケンス内の第１のイベント
・モニタから第２のイベント・モニタへのイベント信号
の伝搬を示す流れ図である。シーケンス内の第１のイベ
ント・モニタは、シーケンス内の第２のイベント・モニ
タへのイベント信号の伝搬を妨げる権利をもつ。段階４
２０で、イベントＩが定義される。この定義には、関係
のあるイベント・モニタに作成順に順次に信号を通知す
べきことを意味する、ＦＩＦＯ伝搬属性が含まれる。同
時にまたは後で、イベント・モニタ・デファイナ１７ｃ
が、イベントＩに関係のあるイベント・モニタ２８ｃを
定義し（段階４２２）、イベント・モニタ・デファイナ
１７ｄが、やはりイベントＩに関係のあるイベント・モ
ニタ２８ｄを定義する（段階４２４）。図１２に示すよ
うに、各イベント・モニタが作成されたとき、それが、
同じイベントに関係のある以前に作成されたイベント・
モニタに連鎖され、またはアドレスによって参照され
る。これは作成の順序を示す。これらのイベント・モニ
タが定義された後、イベント・ハンドラ１４ｃが、Ｅｖ
ｅｎｔＷａｉｔ機能を呼び出して、イベント・モニタ２
８ｃを指定する（段階４２６）、ＥｖｅｎｔＷａｉｔ機
能は待機ビットをセットし、呼出し側をリストする（段
階４２９）。イベント・ハンドラ１４ｄが、Ｅｖｅｎｔ
Ｗａｉｔ機能を呼び出して、イベント・モニタ２８ｄを
指定する（段階４２８）、ＥｖｅｎｔＷａｉｔ機能は待
機ビットをセットし、呼出し側をリストする（段階４２
９）。その後、イベントＩが発生し、イベント・シグナ
ラはＥｖｅｎｔＳｉｇｎａｌ機能４９を呼び出す（段階
４３０）。これに応答して、ＥｖｅｎｔＳｉｇｎａｌ機
能が段階１０２〜１１４を実行し、段階１０２で、ＦＩ
ＦＯ伝搬モードが指定されていることをイベント定義か
ら知る。段階１１０で、ＥｖｅｎｔＳｉｇｎａｌ機能は
また、イベント・モニタ２８ｃ及び２８ｄがともにイベ
ントＩに関係があること、及びイベント・モニタの連鎖
の順序からイベント・モニタ２８ｃが最初に作成された
ことを知る。次に、段階１１４ｂで、ＥｖｅｎｔＳｉｇ
ｎａｌ機能は、シーケンス内の関係のある最初のイベン
ト・モニタ、すなわちイベント・モニタ２８ｃに信号で
通知する。次に、イベント・モニタ２８ｃが段階１１５
〜１１９を実行し、段階１１９でイベント・ハンドラ１
４ｃを覚醒させる。次に、イベント・ハンドラ１４ｃが
段階１１２０〜１１２４及び１１２６を実行し、判断ブ
ロック１１２４で、イベント信号を伝搬のために使用可
能にすべきだと決定する。次に、イベント・ハンドラ１
４ｃは、段階１１２６で、イベント・モニタに戻り、イ
ベント・モニタはＥｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ
機能を自動的に呼び出す（段階１２８）。しかし、イベ
ント・ハンドラ１４ｃは、判断ブロック１１２４で、現
信号セット内のいずれかまたはすべてのイベント信号を
伝搬のために使用可能にすべきではないと決定し、Ｅｖ
ｅｎｔＤｉｓｃａｒｄ機能５８を呼び出して、どれを放
棄すべきかを指定することもできたはずである。段階１
１２５で、現信号セット内のすべてのイベント信号（こ
の例ではイベントＩ用の単独信号）を放棄すべきである
とイベント・ハンドラ１４ｃが指定した場合、図５の段
階１８６で、それらのイベント信号が放棄され、現信号
セットが空であるので、ＥｖｅｎｔＭｏｎｉｔｏｒＲｅ
ｓｅｔ機能は、イベント・モニタ２８ｄに何も伝搬しな
い（図６の判断ブロック１７３）。しかし、この例で
は、イベント・ハンドラ１４ｃは、イベントＩ用の信号
を放棄せず、イベント・モニタ２８ｃがリセットされ、
ＥｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ機能は、図６の段
階１７８でイベント・モニタ２８ｄに信号で通知し、イ
ベント・モニタ２８ｄは段階１１５〜１１９を実行す
る。次に、イベント・ハンドラ１４ｄは段階１１２０〜
１１２６を実行する。イベント・ハンドラ１４ｄが段階
１１２５でイベントＩを放棄した場合、ＥｖｅｎｔＭｏ
ｎｉｔｏｒＲｅｓｅｔ機能が呼び出されたとき、現信号
セットが空であるので、図６の判断ブロック１７３で
は、イベント信号を伝搬しようとする試みを避けること
になる。イベント・ハンドラ１４ｄが段階１１２５でイ
ベントＩを放棄しない場合は、ＥｖｅｎｔＭｏｎｉｔｏ
ｒＲｅｓｅｔ機能が呼び出されたとき、関係のあるイベ
ント・モニタがもうないので、判断ブロック１７５で
は、伝搬の試みを避けることになる。

【００５７】図１３は、伝搬の順序を示すより複雑なイ
ベント・モニタの連鎖の例を示す。イベント・モニタ２
８ｅは、イベントＭ、Ｎ及びＯに関係があり、最初に作
成された。イベント・モニタ２８ｆは、イベント・モニ
タ２８ｅより後で作成されたが、イベントＭ及びＰに関
係があり、両方のイベント・モニタがイベントＭに関係
があることを示すため、イベント・モニタ２８ｅ内のイ
ベントＭの参照から連鎖される。イベント・モニタ２８
ｇも、イベント・モニタ２８ｅより後で作成されたが、
イベントＮ及びＯに関係があり、両方のイベント・モニ
タがイベントＮ及びＯに関係があることを示すため、イ
ベント・モニタ２８ｅ内のイベントＮ及びイベントＯの
参照から連鎖される。同様に、イベント・モニタ２８ｈ
及び２８ｉは、イベント・モニタ２８ｆより後で作成さ
れたが、それぞれイベントＭ及びＰに関係があり、それ
ぞれイベント・モニタ２８ｆ内のイベントＭ及びイベン
トＰの参照から連鎖されている。このようにして、これ
らのイベント・モニタのどれかから各イベント信号を伝
搬する必要があるとき、ＥｖｅｎｔＭｏｎｉｔｏｒＲｅ
ｓｅｔ機能は、イベント・モニタ定義を読み取って、特
定のイベントに関係のあるＦＩＦＯまたはＬＩＦＯシー
ケンス内の次のイベント・モニタを識別する。

【００５８】イベントを定義した後いつでも、そのイベ
ントを定義したプロセスは、ＥｖｅｎｔＤｅｌｅｔｅ機
能６９またはＥｖｅｎｔＭｏｄｉｆｙ機能７１を呼び出
すことによって、イベント定義を削除または修正するこ
とができる。ＥｖｅｎｔＤｅｌｅｔｅ機能は図１４に示
されている。ＥｖｅｎｔＤｅｌｅｔｅ機能は、現信号セ
ットの現在の処理に影響を与えないが、削除すべきイベ
ントに関係のある各イベント・モニタに関する結合信号
セット及びそのイベント用のルース信号セット４１を読
み取って、現信号セットに関係のないイベント信号があ
るかどうか判定定する（判断ブロック２９６）。イエス
の場合、それらのイベント信号は放棄される（段階２９
８）。次に、ＥｖｅｎｔＤｅｌｅｔｅ機能は、イベント
に関係のある各イベント・モニタの定義中で、そのイベ
ントが削除されたことを示す（段階３００）。次に、Ｅ
ｖｅｎｔＤｅｌｅｔｅ機能は、そのイベントに関係があ
り未処理のＥｖｅｎｔＷａｉｔｓを有するイベント・モ
ニタがあるかどうか判定する（判断ブロック３０２）。
イエスの場合、ＥｖｅｎｔＤｅｌｅｔｅ機能は、段階１
１９でイベント・モニタを呼び出し（段階３０３）、段
階１２０〜１２８が実行される。段階１２０で、イベン
ト・ハンドラは、イベントが削除されたこと、及びその
結果イベント・ハンドラに関連するイベント・モニタが
決して満足されないことを知る。次に、ＥｖｅｎｔＤｅ
ｌｅｔｅ機能は、そのイベントに関係があり未処理のイ
ベント・トラップを有するイベント・モニタがあるかど
うか判定する（判断ブロック３０４）。イエスの場合、
ＥｖｅｎｔＤｅｌｅｔｅ機能は、段階１２２でイベント
・モニタを呼び出し（段階３０５）、段階１３８〜１４
２及び１１２４〜１１２６が実行される。（段階１３８
でトラップ・ルーチンによって呼び出された）Ｅｖｅｎ
ｔＴｅｓｔ機能の段階１５８で、ＥｖｅｎｔＴｅｓｔ機
能は、イベント・モニタが決して満足されないことをト
ラップ・ルーチンに通知する。最後に、ＥｖｅｎｔＤｅ
ｌｅｔｅ機能はイベント定義を削除する（段階３０
６）。

【００５９】ＥｖｅｎｔＭｏｄｉｆｙ機能は、イベント
定義の内部の信号通知属性のルース信号限界または操作
状況を変更するために呼び出される。ルース信号限界属
性の変更はただちに効果を示すが、動作状況属性の変更
は後の信号が発行されるまで効果を示さない。

【００６０】イベントが最初に作成されたとき、そのイ
ベントは自動的にイネーブルされる。ＥｖｅｎｔＥｎａ
ｂｌｅ機能４４は、イベントが作成された後そのイベン
トをディスエーブルするために、またはディスエーブル
されたイベントをイネーブルするために呼び出すことが
できる。イベントがディスエーブルされたとき、そのイ
ベントに関する信号は、関係のあるイベント・モニタに
結合されるが、そ（れら）のイベント・モニタを満足さ
せる方向にカウントしない。

【００６１】図１５は、ＥｖｅｎｔＥｎａｂｌｅ機能を
示す流れ図である。段階２０２で、イベント・デファイ
ナ１３ａがイベントＤを定義し、段階２０４で、イベン
ト・モニタ・デファイナ１７ｄがイベントＤに関係のあ
るイベント・モニタ２８ｄを定義する。次に、イベント
・モニタ２８ｄに関連するイベント・ハンドラ１４ｄ
が、ＥｖｅｎｔＥｎａｂｌｅ機能を呼び出し、イベント
Ｄをディスエーブルすべきことを指定することができる
（段階２０６）。これに応答して、ＥｖｅｎｔＥｎａｂ
ｌｅ機能はイベントＤ用のイベント定義をディスエーブ
ル済みとマークする（段階２０８）。その後、イベント
Ｄが発生し、イベント・シグナラはＥｖｅｎｔＳｉｇｎ
ａｌ機能を呼び出し（段階２１０）、ＥｖｅｎｔＳｉｇ
ｎａｌ機能が上記の段階１０２〜１１４を実行する。次
に、イベント・モニタは、イベント信号をイベント・モ
ニタ２８ｄに結合するが、イベント信号がイベント・モ
ニタ２８ｄを満足させる方向にカウントすべきではない
と指示する（判断ブロック２１２及び段階２１３）。次
に、イベント・モニタ２８ｄは、段階１１６及び図２に
記載の後続の段階１１７〜１１９に進むが、段階１１６
では、イベントＤの最後の発生をイベント・モニタ２８
ｄを満足させる方向にカウントしない。

【００６２】先に指摘したように、イベント・モニタが
最初に作成されたとき、そのイベント・モニタは自動的
にイネーブルされる。しかし、ＥｖｅｎｔＭｏｎｉｔｏ
ｒＥｎａｂｌｅ機能６４を呼び出して、作成後イベント
・モニタをディスエーブルし、またはディスエーブルさ
れたイベント・モニタをイネーブルすることができる。
イベント信号はディスエーブルされたイベント・モニタ
に結合されるが、ディスエーブルされたイベント・モニ
タを満足させることはできない。

【００６３】図１６は、ＥｖｅｎｔＭｏｎｉｔｏｒＥｎ
ａｂｌｅ機能を示す流れ図である。イベントＥが作成さ
れ（段階２２０）、関係のあるイベント・モニタが作成
された（段階２２２）後、イベント・ハンドラは、Ｅｖ
ｅｎｔＭｏｎｉｔｏｒＥｎａｂｌｅ機能を呼び出して名
前付きイベント・モニタをディスエーブルすべきことを
指定することができる（段階２２４）。これに応答し
て、ＥｖｅｎｔＭｏｎｉｔｏｒＥｎａｂｌｅ機能が、Ｅ
ｖｅｎｔＭｏｎｉｔｏｒ定義をディスエーブル標識でマ
ークする（段階２２６）。イベントＥが発生したとき、
イベント・シグナラはＥｖｅｎｔＳｉｇｎａｌ機能を呼
び出し（段階２２８）、ＥｖｅｎｔＳｉｇｎａｌ機能が
上記の段階１０２〜１１４を実行する。次に、イベント
・モニタは、イベント信号をイベント・モニタに結合す
る（段階１１５）が、イベント・モニタ定義内にディス
エーブル標識があるため、判断ブロック１１６でイベン
ト・モニタはイベント・モニタを満足させる方向にこの
信号またはいかなる信号もカウントせず、イベント・モ
ニタはそれ以上の処置を取らない。

【００６４】イベントが最初に定義されたとき、監視が
自動的に開始する。監視が開始したままである場合、Ｅ
ｖｅｎｔＳｉｇｎａｌ機能は、図２〜４及び７〜９に記
載の方式で、関係のあるイベント・モニタに信号で通知
する。しかし、ＥｖｅｎｔＳｅｌｅｃｔ機能６０を呼び
出して、特定のイベントの監視を停止し、または監視が
停止された後に監視を再開することができる。監視が停
止されたとき、以後のイベント信号は、ＥｖｅｎｔＳｅ
ｌｅｃｔ機能を発行したプロセスで、どのイベント・モ
ニタにも結合されない。

【００６５】図１７はＥｖｅｎｔＳｅｌｅｃｔ機能を示
す。段階２５０で、イベントＦが定義され、監視が自動
的に開始する。次に、イベント・モニタが定義される
（段階２５２）。その後、イベント・ハンドラがＥｖｅ
ｎｔＳｅｌｅｃｔ機能を呼び出し、名前付きイベントの
監視を停止すべきことを指定する（段階２５４）。これ
に応答して、ＥｖｅｎｔＳｅｌｅｃｔ機能は、名前付き
イベント用のイベント定義を監視が停止されたとマーク
する（段階２５６）。その後、イベントＦが発生し、イ
ベント・シグナラはＥｖｅｎｔＳｉｇｎａｌ機能を呼び
出す（段階２５８）。ＥｖｅｎｔＳｉｇｎａｌ機能は上
記の段階１０２及び１０４を実行し、次にイベント定義
から監視を停止すべきであると決定する（判断ブロック
１０６）。その結果、ＥｖｅｎｔＳｉｇｎａｌ機能は、
イベント定義内部のルース信号限界に従ってイベント信
号をイベント定義に結合する（段階２６２）。監視が停
止されているので、ＥｖｅｎｔＳｅｌｅｃｔ機能はどの
イベント・モニタにも信号で通知せず、関係のあるイベ
ント・モニタにも信号で通知しない。

【００６６】イベント・モニタが最初に作成されたと
き、そのイベント・モニタに関する監視が自動的に開始
する。しかし、ＥｖｅｎｔＭｏｎｉｔｏｒＳｅｌｅｃｔ
機能６６を呼び出して、イベント・モニタによる監視を
停止し、または停止されたイベント・モニタによる監視
を再開することができる。ＥｖｅｎｔＭｏｎｉｔｏｒＳ
ｅｌｅｃｔ機能６６は、ＥｖｅｎｔＭｏｎｉｔｏｒＥｎ
ａｂｌｅ機能６４とは異なる。なぜなら、停止されたイ
ベント・モニタにとって関係のある信号はそのイベント
・モニタに結合されていないが、ディスエーブルされた
イベント・モニタにとって関係のある信号はそのイベン
ト・モニタに結合されているからである。

【００６７】図１８は、ＥｖｅｎｔＭｏｎｉｔｏｒＳｅ
ｌｅｃｔ機能を示す流れ図である。段階２７０で、イベ
ントＧが定義され、段階２７２で、関係のあるイベント
・モニタ２８ｂが定義される。段階２７４で、イベント
・ハンドラ１４ｂは、ＥｖｅｎｔＭｏｎｉｔｏｒＳｅｌ
ｅｃｔ機能を呼び出して、イベント・モニタ２８ｂが監
視を停止すべきであると指定する。これに応答して、Ｅ
ｖｅｎｔＭｏｎｉｔｏｒＳｅｌｅｃｔ機能は、イベント
・モニタ定義を監視が停止されたとマークする（段階２
７６）。イベントＧが発生し、イベント・シグナラがＥ
ｖｅｎｔＳｉｇｎａｌ機能を呼び出した（段階２７８）
後、ＥｖｅｎｔＳｉｇｎａｌ機能は上記の段階１０２〜
１１４を実行し、判断ブロック１１２で、イベント・モ
ニタ２８ｂの監視が停止されていると判定する。その結
果、ＥｖｅｎｔＳｉｇｎａｌ機能は、イベント信号をイ
ベントＧのイベント定義に結合するが、イベント・モニ
タ２８ｂに信号で通知せず、またイベント信号をイベン
ト・モニタ２８ｂに結合しない。イベントＧに関係があ
り、その監視が開始されたイベント・モニタが他にある
場合、それらの他のイベント・モニタは段階１１２でイ
ベント信号を受け取り、イベント信号はイベント定義に
結合されないことに留意されたい。

【００６８】イベント・モニタの作成後いつでも、その
イベント・モニタを作成したプロセスは、図１９に示す
ＥｖｅｎｔＭｏｎｉｔｏｒＤｅｌｅｔｅ機能６８を呼び
出すことによって、そのイベント・モニタを削除するこ
ともできる。プロセスが終了したとき、そのプロセスは
ＥｖｅｎｔＭｏｎｉｔｏｒＤｅｌｅｔｅ機能を呼び出し
て、そのプロセスによって定義されたすべてのイベント
・モニタを削除する。段階４００で、ＥｖｅｎｔＭｏｎ
ｉｔｏｒＤｅｌｅｔｅ機能は、イベント・モニタに関連
する情報（定義、結合信号、状況など）を読み取る。イ
ベント・モニタが活動状態である場合（判断ブロック４
０２）、ＥｖｅｎｔＭｏｎｉｔｏｒＤｅｌｅｔｅ機能
は、イベント・モニタが次にリセットされたときそのイ
ベント・モニタを削除すべきであるとの標識でイベント
・モニタをマークする（段階４０４）。これによって、
ＥｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ機能は、図６の段
階１８５でＥｖｅｎｔＭｏｎｉｔｏｒＤｅｌｅｔｅ機能
を呼び出す。しかし、ＥｖｅｎｔＭｏｎｉｔｏｒＤｅｌ
ｅｔｅ機能は、現信号セットの処理に干渉しない。判断
ブロック４０２でイベント・モニタが非活動状態である
ことが判明した場合、または現信号セットの処理及びＥ
ｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ機能の以後の実行後
にイベント・モニタが非活動状態になった後、Ｅｖｅｎ
ｔＭｏｎｉｔｏｒＤｅｌｅｔｅ機能はそのイベント・モ
ニタを連鎖から除去し、したがってそのイベント・モニ
タは他の機能にもはやアクセスできなくなる（段階４０
６）。次に、ＥｖｅｎｔＭｏｎｉｔｏｒＤｅｌｅｔｅ機
能は、イベント・モニタが関係をもついずれかのイベン
トが伝搬属性で定義されているかどうか、及び他の関係
のある下流側イベント・モニタがあるかどうか判定する
（判断ブロック４０８）。両方の条件が満足された場
合、ＥｖｅｎｔＭｏｎｉｔｏｒＤｅｌｅｔｅ機能は、両
条件を満たす各結合イベント信号を当該のシーケンス内
の次のイベント・モニタに伝搬する（段階４１０）。Ｅ
ｖｅｎｔＭｏｎｉｔｏｒＤｅｌｅｔｅ機能は、両方の条
件に合致しない結合信号を放棄する（段階４１２）。次
に、ＥｖｅｎｔＭｏｎｉｔｏｒＤｅｌｅｔｅ機能は、イ
ベント・モニタ内のイベント待機ビットを読み取って、
未処理のＥｖｅｎｔＷａｉｔがあるかどうか判定する
（判断ブロック４１４）。イエスの場合、ＥｖｅｎｔＭ
ｏｎｉｔｏｒＤｅｌｅｔｅ機能は、当該のイベント・ハ
ンドラを覚醒させ、イベント・モニタが削除されつつあ
ることを示す（段階４１６）。次に、ＥｖｅｎｔＭｏｎ
ｉｔｏｒＤｅｌｅｔｅ機能は、トラップ・ビットを読み
取って、未処理のイベント・トラップがあるか否かを決
定する（判断ブロック４１８）。イエスの場合、Ｅｖｅ
ｎｔＭｏｎｉｔｏｒＤｅｌｅｔｅ機能は、トラップ・ル
ーチンを呼び出す（段階４２０）。トラップ・ルーチン
がＥｖｅｎｔＴｅｓｔ機能を呼び込んだとき（図６の段
階１３８）、図６の判断ブロック１３９で、Ｅｖｅｎｔ
Ｔｅｓｔ機能はイベント・モニタの位置を見つけられ
ず、イベント・モニタが存在しないとトラップ・ルーチ
ンに報告する。その後、トラップ・ルーチンはオペレー
ティング・システムに戻り、オペレーティング・システ
ムは暗示的にＥｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ機能
を呼び出す。最後に、ＥｖｅｎｔＭｏｎｉｔｏｒＤｅｌ
ｅｔｅ機能がイベント・モニタ定義を消去する（段階４
２２）。

【００６９】本発明の代替実施例では、イベント・モニ
タにとって関係のあるイベントを含めて、既存のイベン
ト・モニタのどの属性も動的に修正することができる。
あるイベント・タイプがイベント・モニタにとって関係
のあるイベントのリストから削除された場合、削除され
たイベント・タイプの結合信号は、ＥｖｅｎｔＭｏｎｉ
ｔｏｒＤｅｌｅｔｅ機能６８内で記述されるように処理
される。あるイベント・タイプがイベント・モニタ定義
に追加された場合、そのイベント・タイプのルース信号
は、ＥｖｅｎｔＭｏｎｉｔｏｒＣｒｅａｔｅ機能４２内
で記述されるように処理される。実際に、イベント・モ
ニタの修正は、ＥｖｅｎｔＭｏｎｉｔｏｒＤｅｌｅｔｅ
機能６８でイベント・モニタを原子的に削除すること、
及びＥｖｅｎｔＭｏｎｉｔｏｒＣｒｅａｔｅ機能４２で
イベント・モニタを再作成することと、次の点を除き機
能的に等価である。イベント・モニタにとって関係のあ
るイベントの結合信号は、結合信号限界が低減され、低
減された限界より多くの結合信号がある場合を除き、修
正の前後で放棄も伝搬もされない。前記の場合は、過剰
な最も古い結合信号が放棄される。また、イベント・モ
ニタ定義は原子的に（すなわち１段階で）修正されるの
で、イベント・モニタ定義が修正されている間に発生す
るイベント用の信号が失われる可能性はない。

【００７０】イベント信号マネージャ機能呼出しＥｖｅｎｔＣｒｅａｔｅｒｅｔｃｏｄｅｒｓｎｃｏｄｅｅｖｅｎｔ＿ｎａｍｅｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈｅｖｅｎｔ＿ｆｌａｇｅｖｅｎｔ＿ｆｌａｇ＿ｓｉｚｅｌｏｏｓｅ＿ｓｉｇｎａｌ＿ｌｉｍｉｔｓｉｇｎａｌ＿ｔｉｍｅｏｕｔ＿ｐｅｒｉｏｄ

【００７１】パラメータ："ＥｖｅｎｔＣｒｅａｔｅ"
は、呼び込まれる機能の名前である。"ｒｅｔｃｏｄｅ"
は、ＥｖｅｎｔＣｒｅａｔｅからの戻りコードを保持す
るための符号付き４バイト２進変数である。「戻りコー
ド」は、呼出しまたはパラメータの成否またはエラーの
有無を示す。"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＣｒｅａ
ｔｅからの理由コードを保持するための符号付き４バイ
ト２進変数である。「理由コード」は、呼出しまたはパ
ラメータの失敗またはエラーの理由を示す。"ｅｖｅｎ
ｔ＿ｎａｍｅ"は、定義されるイベントの名前を含む文
字変数である。"ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ"
は、ｅｖｅｎｔ＿ｎａｍｅの長さを含む符号付き４バイ
ト２進変数である。"ｅｖｅｎｔ＿ｆｌａｇ"は、４バイ
ト２進変数のアレイであり、その各要素はどのようにイ
ベントを管理すべきかの情報を含む。以下の各セットか
らそれぞれ１つのオプションだけを指定することができ
る。特定のセットからのオプションが指定されていない
場合、省略時指定がとられる。イベント名の範囲は、プ
ロセス及びセッションで示される。すなわち、このプロ
セスだけがこのイベントを監視でき、このプロセスだけ
がこのイベントを信号で通知できることを示す"ｖｍ＿
ｅｖｎ＿ｐｒｏｃｅｓｓ＿ｓｃｏｐｅ"、及びセッショ
ン内のすべてのプロセスが、このイベントを監視するこ
とも信号で通知することもできることを示す"ｖｍ＿ｅ
ｖｎ＿ｓｅｓｓｉｏｎ＿ｓｃｏｐｅ"である。イベント
信号を１つのプロセスで複数のイベント・モニタに渡す
方式は、同報通信、ＦＩＦＯまたはＬＩＦＯモードとし
て示される。すなわち、信号がすべての適格モニタに同
時に渡されることを示す"ｖｍ＿ｅｖｎ＿ｂｒｏａｄｃ
ａｓｔ＿ｓｉｇｎａｌｓ"、モニタが作成された順序で
信号が一時に１つの適格モニタに渡されることを示す"
ｖｍ＿ｅｖｎ＿ｆｉｆｏ＿ｓｉｇｎａｌｓ"、及びＦＩ
ＦＯオプションによって定義されたイベントとは逆の順
序で信号が一時に１つの適格モニタに渡されることを示
す"ｖｍ＿ｅｖｎ＿ｌｉｆｏ＿ｓｉｇｎａｌｓ"である。

【００７２】シグナラの処理は、"ｖｍ＿ｅｖｎ＿ａｓ
ｙｎｃ＿ｓｉｇｎａｌｓ"、"ｖｍ＿ｅｖｎ＿ｓｙｎｃ＿
ｔｈｒｅａｄ＿ｓｉｇｎａｌｓ"、または"ｖｍ＿ｅｖｎ
＿ｓｙｎｃ＿ｐｒｏｃｅｓｓ＿ｓｉｇｎａｌｓ"として
示される。ｖｍ＿ｅｖｎ＿ａｓｙｎｃ＿ｓｉｇｎａｌｓ
は、信号通知スレッドが実行を継続できることを示す
（省略時指定）。ｖｍ＿ｅｖｎ＿ｓｙｎｃ＿ｔｈｒｅａ
ｄ＿ｓｉｇｎａｌｓは、信号処理が完了するまで信号通
知スレッドが中断されることを示す。１つのプロセスに
おける信号処理は、すべての適格モニタがその信号の処
理を完了したとき、完了したと見なされ、また適格モニ
タがない場合は、ルース信号限界を超えたとき、最も古
いルース信号となった結果、信号が放棄される。信号が
イベント・モニタの現信号セットの一部分になり、その
イベント・モニタがその後リセットされたとき、そのイ
ベント・モニタは信号の処理を完了したと見なされる。
ＦＩＦＯ及びＬＩＦＯイベントでは、結合信号は、それ
が結合されているイベント名／イベント・キー対の結合
信号限界を超えたとき、その結合信号が最も古い結合信
号である場合、ＥｖｅｎｔＤｉｓｃａｒｄによって明示
的に放棄され、または暗示的に放棄される。いずれの場
合も、そのプロセスによって放棄された信号の処理は、
完了したと見なされる。これがセッション・レベルのイ
ベントである場合、すべてのプロセスが処理を完了して
からでないと、信号処理が完了したと見なされない。ｖ
ｍ＿ｅｖｎ＿ｓｙｎｃ＿ｐｒｏｃｅｓｓ＿ｓｉｇｎａｌ
ｓは、この信号によってイベント・モニタが活動化され
た結果として走行しているスレッドを除き、現在信号通
知プロセスにあるすべてのスレッドがイベント処理の結
果を待って中断されていることを示す。イベント・モニ
タが活動化された結果走行しているスレッドは、最初は
中断されていない追加のスレッドを作成することができ
る。しかし、ＥｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ時
に、これらの追加のスレッドも他のスレッドと同様に処
理される。

【００７３】"ｅｖｅｎｔ＿ｆｌａｇ＿ｓｉｚｅ"は、ｅ
ｖｅｎｔ＿ｆｌａｇアレイ内の要素の数を含む符号付き
の４バイト２進変数である。

【００７４】"ｌｏｏｓｅ＿ｓｉｇｎａｌ＿ｌｉｍｉｔ"
は、イベントが信号で通知されたときにイベント信号を
結合する適格イベント・モニタが存在しない場合に保持
されるイベント信号の数を含む、符号付きの４バイト２
進変数である。限界を超えたとき、新しく到着した信号
用の場所をあけるために最も古いルース信号が放棄され
る。値０は、ルース信号が保持されないことを示す。値
−１は、仮想記憶域が利用できるという条件の下でルー
ス信号リストが無制限に成長できることを意味する。そ
の他の負の値はエラーと見なされる。

【００７５】"ｓｉｇｎａｌ＿ｔｉｍｅｏｕｔ＿ｐｅｒ
ｉｏｄ"は、信号通知スレッドが信号の処理の完了を待
って中断状態に留まる、マイクロ秒で指定された時間の
最大長さを表す、符号付きの４バイト２進変数である。
値０は、信号通知スレッドが信号処理の完了を無限に待
たなければならないことを示す。信号通知スレッドが処
理を続けることを指定するオプションがｅｖｅｎｔ＿ｆ
ｌａｇアレイ内に含まれている場合、このパラメータは
無視される。

【００７６】ＥｖｅｎｔＤｅｌｅｔｅｒｅｔｃｏｄｅｒｓｎｃｏｄｅｅｖｅｎｔ＿ｎａｍｅｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ

【００７７】パラメータ："ＥｖｅｎｔＤｅｌｅｔｅ"
は、呼び出される機能の名前である。"ｒｅｔｃｏｄｅ"
は、ＥｖｅｎｔＤｅｌｅｔｅからの戻りコードを保持す
るための符号付きの４バイト２進変数である。"ｒｓｎ
ｃｏｄｅ"は、ＥｖｅｎｔＤｅｌｅｔｅからの理由コー
ドを保持するための符号付きの４バイト２進変数であ
る。"ｅｖｅｎｔ＿ｎａｍｅ"は、その定義が削除される
イベントの名前を含む文字変数である。"ｅｖｅｎｔ＿
ｎａｍｅ＿ｌｅｎｇｔｈ"は、ｅｖｅｎｔ＿ｎａｍｅの
長さを含む符号付きの４バイト２進変数である。

【００７８】ＥｖｅｎｔＤｉｓｃａｒｄｒｅｔｃｏｄｅ，ｒｓｎｃｏｄｅ，ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ，ｉｎｄｅｘ

【００７９】パラメータ："ＥｖｅｎｔＤｉｓｃａｒｄ"
は、呼び出される機能の名前である。"ｒｅｔｃｏｄｅ"
は、ＥｖｅｎｔＤｉｓｃａｒｄからの戻りコードを保持
するための符号付きの４バイト２進変数である。"ｒｓ
ｎｃｏｄｅ"は、ＥｖｅｎｔＤｉｓｃａｒｄからの理由
コードを保持するための符号付きの４バイト２進変数で
ある。"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ"は、その現信号セ
ットから信号が放棄されるイベント・モニタを識別する
トークンを含む符号付きの４バイト２進変数である。値
０は、現スレッド上で最近に活動化された活動状態のイ
ベント・モニタを識別するために使用される。"ｉｎｄ
ｅｘ"は、イベント・モニタの作成時に指定されたｅｖ
ｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓ、ｅｖｅｎｔ＿ｎａ
ｍｅ＿ｌｅｎｇｔｈ、ｅｖｅｎｔ＿ｋｅｙ＿ａｄｄｒｅ
ｓｓ及びｅｖｅｎｔ＿ｋｅｙ＿ｌｅｎｇｔｈアレイへの
インデックスとして、放棄される信号に対応するｅｖｅ
ｎｔ＿ｎａｍｅとｅｖｅｎｔ＿ｋｅｙの対を識別する、
符号付きの４バイト２進変数である。値０は、現信号セ
ット内のすべての信号を放棄すべきことを指示するため
に使用される。

【００８０】ＥｖｅｎｔＥｎａｂｌｅｒｅｔｃｏｄｅｒｓｎｃｏｄｅｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈｅｖｅｎｔ＿ｅｎａｂｌｅｍｅｎｔ＿ｍａｓｋ

【００８１】パラメータ："ＥｖｅｎｔＥｎａｂｌｅ"
は、呼び出される機能の名前である。"ｒｅｔｃｏｄｅ"
は、ＥｖｅｎｔＥｎａｂｌｅからの戻りコードを保持す
るための符号付きの４バイト２進変数である。"ｒｓｎ
ｃｏｄｅ"は、ＥｖｅｎｔＥｎａｂｌｅからの理由コー
ドを保持するための符号付きの４バイト２進変数であ
る。"ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ"は、関係のあ
るｅｖｅｎｔ＿ｎａｍｅとｅｖｅｎｔ＿ｋｅｙの対の数
を含む符号付きの４バイト２進変数である。"ｅｖｅｎ
ｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓ"は、ｎｕｍｂｅｒ＿ｏ
ｆ＿ｅｖｅｎｔｓ個の４バイト・ポインタ変数のアレイ
であり、その各要素はその発生を監視すべきイベントの
名前のアドレスを含む。"ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅ
ｎｇｔｈ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の
符号付き４バイト２進変数のアレイであり、その各要素
はｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓアレイの対応
する要素が指すｅｖｅｎｔ＿ｎａｍｅの長さを含む。"
ｅｖｅｎｔ＿ｅｎａｂｌｅｍｅｎｔ＿ｍａｓｋ"は、ｎ
ｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符号付き４バイト
２進変数のアレイであり、その各要素はｅｖｅｎｔ＿ｎ
ａｍｅ＿ａｄｄｒｅｓｓアレイの対応する要素が指すｅ
ｖｅｎｔ＿ｎａｍｅのイネーブル・マスクを含む。イベ
ント・イネーブル・マスクは、プロセスごとに維持さ
れ、ＥｖｅｎｔＥｎａｂｌｅコマンドは発行プロセスだ
けに影響を与える。イネーブル・マスクの値が、実行さ
れる以下の処置を決定する。すなわち、ｅｖｅｎｔ＿ｎ
ａｍｅ＿ａｄｄｒｅｓｓアレイの対応する要素によって
指示されるｅｖｅｎｔ＿ｎａｍｅをディスエーブルする
ことを示す"ｖｍ＿ｅｖｎ＿ｄｉｓａｂｌｅ"、またはｅ
ｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓアレイの対応する
要素によって指示されるｅｖｅｎｔ＿ｎａｍｅをイネー
ブルすることを示す"ｖｍ＿ｅｖｎ＿ｅｎａｂｌｅ"であ
る。

【００８２】ＥｖｅｎｔＭｏｄｉｆｙｒｅｔｃｏｄｅｒｓｎｃｏｄｅｅｖｅｎｔ＿ｎａｍｅｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈｅｖｅｎｔ＿ｆｌａｇｅｖｅｎｔ＿ｆｌａｇ＿ｓｉｚｅｌｏｏｓｅ＿ｓｉｇｎａｌ＿ｌｉｍｉｔｓｉｇｎａｌ＿ｔｉｍｅｏｕｔ＿ｐｅｒｉｏｄ

【００８３】パラメータ："ＥｖｅｎｔＭｏｄｉｆｙ"
は、呼び出される機能の名前である。"ｒｅｔｃｏｄｅ"
は、ＥｖｅｎｔＭｏｄｉｆｙからの戻りコードを保持す
るための符号付きの４バイト２進変数である。"ｒｓｎ
ｃｏｄｅ"は、ＥｖｅｎｔＭｏｄｉｆｙからの理由コー
ドを保持するための符号付きの４バイト２進変数であ
る。"ｅｖｅｎｔ＿ｎａｍｅ"は、その定義が修正される
イベントの名前を含む文字変数である。"ｅｖｅｎｔ＿
ｎａｍｅ＿ｌｅｎｇｔｈ"は、ｅｖｅｎｔ＿ｎａｍｅの
長さを含む符号付きの４バイト２進変数である。"ｅｖ
ｅｎｔ＿ｆｌａｇ"は、４バイト２進変数のアレイであ
り、その各要素はイベントをどのように管理すべきかの
情報を含む。以下のセットからただ１つのオプションを
指定することができる。このセットからのオプションが
指定されない場合、オプションの既存の値が修正されな
いままとなる。シグナラの処理は、信号通知スレッドが
実行を継続できることを示すｖｍ＿ｅｖｎ＿ａｓｙｎｃ
＿ｓｉｇｎａｌｓ（省略時指定）、信号通知スレッドが
イベント処理の結果を待って中断されることを示すｖｍ
＿ｅｖｎ＿ｓｙｎｃ＿ｔｈｒｅａｄ＿ｓｉｇｎａｌｓ、
または信号によってモニタが活動化された結果走行して
いるスレッドを除き、信号通知プロセス内のすべてのス
レッドがイベント処理の結果を待って中断されることを
示すｖｍ＿ｅｖｎ＿ｓｙｎｃ＿ｐｒｏｃｅｓｓ＿ｓｉｇ
ｎａｌｓによって指示される。

【００８４】"ｅｖｅｎｔ＿ｆｌａｇ＿ｓｉｚｅ"は、ｅ
ｖｅｎｔ＿ｆｌａｇ＿ａｒｒａｙ内の要素の数を含む符
号付きの４バイト２進変数である。

【００８５】"ｌｏｏｓｅ＿ｓｉｇｎａｌ＿ｌｉｍｉｔ"
は、イベントが信号で通知されたときイベント信号を結
合する適格イベント・モニタが存在しない場合に保持さ
れるイベント信号の数を含む符号付きの４バイト２進変
数である。限界を超えたとき、新しく到着した信号用の
場所をあけるために最も古いルース信号が放棄される。
値０は、ルース信号が保持されないことを示す。値−１
は、仮想記憶域が利用できるという条件の下でルース信
号リストが無制限に成長できることを意味する。値−２
は、既存のｌｏｏｓｅ＿ｓｉｇｎａｌ＿ｌｉｍｉｔが修
正されないままとなることを意味する。その他の負の値
はエラーと見なされる。

【００８６】"ｓｉｇｎａｌ＿ｔｉｍｅｏｕｔ＿ｐｅｒ
ｉｏｄ"は、信号通知スレッドが信号の処理の完了を待
って中断状態に留まる、マイクロ秒で指定された時間の
最大長さを表す、符号付きの４バイト２進変数である。
値０は、信号通知スレッドが信号処理の完了を無限に待
たなければならないことを示す。値−１は、既存のｓｉ
ｇｎａｌ＿ｔｉｍｅｏｕｔ＿ｐｅｒｉｏｄが修正されな
いままとなることを意味する。シグナラの中断を指定す
るオプションがｅｖｅｎｔ＿ｆｌａｇアレイ内に含まれ
ていない場合、このパラメータは無視される。

【００８７】ＥｖｅｎｔＭｏｎｉｔｏｒＣｒｅａｔｅｒｅｔｃｏｄｅｒｓｎｃｏｄｅｍｏｎｉｔｏｒ＿ｔｏｋｅｎｍｏｎｉｔｏｒ＿ｆｌａｇｍｏｎｉｔｏｒ＿ｆｌａｇ＿ｓｉｚｅｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈｅｖｅｎｔ＿ｋｅｙ＿ａｄｄｒｅｓｓｅｖｅｎｔ＿ｋｅｙ＿ｌｅｎｇｔｈｂｏｕｎｄ＿ｓｉｇｎａｌ＿ｌｉｍｉｔｅｖｅｎｔ＿ｃｏｕｎｔ

【００８８】パラメータ："ＥｖｅｎｔＭｏｎｉｔｏｒ
Ｃｒｅａｔｅ"は、呼び出される機能の名前である。"ｒ
ｅｔｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉｔｏｒＣｒｅａ
ｔｅからの戻りコードを保持するための符号付き４バイ
ト２進変数である。"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＭ
ｏｎｉｔｏｒＣｒｅａｔｅからの理由コードを保持する
ための符号付き４バイト２進変数である。"ｍｏｎｉｔ
ｏｒ＿ｔｏｋｅｎ"は、他のイベント管理機能が後で呼
び込まれるときにイベント・モニタを識別するトークン
がその中で返される、符号付きの４バイト２進変数であ
る。"ｍｏｎｉｔｏｒ＿ｆｌａｇ"は、符号付きの４バイ
ト２進変数のアレイであり、その各要素は、イベント・
モニタをどのように管理すべきかの情報を含む。以下の
各セットからそれぞれただ１つのオプションを指定する
ことができる。特定のセットからのオプションが与えら
れていない場合、省略時指定が適用される。モニタの寿
命は、イベント・モニタが明示的ＥｖｅｎｔＭｏｎｉｔ
ｏｒＤｅｌｅｔｅまで持続することを意味する"ｖｍ＿
ｅｖｎ＿ｎｏ＿ａｕｔｏ＿ｄｅｌｅｔｅ"（省略時）、
またはイベント・モニタが最初に非活動化されるとき
に、またはＥｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ時に自
動的に削除されることを意味する"ｖｍ＿ｅｖｎ＿ａｕ
ｔｏ＿ｄｅｌｅｔｅ"によって指示される。指名可能性
に対するモニタ活動化の効果は、そのモニタを含むプロ
セス内のすべてのスレッドが指名可能なままとなること
を意味する"ｖｍ＿ｅｖｎ＿ａｓｙｎｃ＿ｍｏｎｉｔｏ
ｒ"（省略時指定）、またはその上でモニタが活動化さ
れているスレッド（すなわち、このイベント・モニタ用
のイベント・ハンドラ）を除き、現在そのモニタを含む
プロセス内にあるすべてのスレッドが、モニタが非活動
化されるまで中断されることを意味する"ｖｍ＿ｅｖｎ
＿ｓｙｎｃ＿ｐｒｏｃｅｓｓ＿ｍｏｎｉｔｏｒ"によっ
て指示される。ルース信号のこのモニタへの結合は、モ
ニタが作成されたときまたはＥｖｅｎｔＳｅｌｅｃｔも
しくはＥｖｅｎｔＭｏｎｉｔｏｒＳｅｌｅｃｔによって
監視が再開されたときにこのモニタがそれに対して適格
な任意のルース信号がこのモニタに結合されることを意
味する"ｖｍ＿ｅｖｎ＿ｂｉｎｄ＿ｌｏｏｓｅ＿ｓｉｇ
ｎａｌｓ"（省略時指定）、またはいかなるルース信号
もこのモニタに結合されていないことを意味する"ｖｍ
＿ｅｖｎ＿ｉｇｎｏｒｅ＿ｌｏｏｓｅ＿ｓｉｇｎａｌ
ｓ"によって指示される。"ｍｏｎｉｔｏｒ＿ｆｌａｇ＿
ｓｉｚｅ"は、ｍｏｎｉｔｏｒ＿ｆｌａｇアレイ内の要
素の数を含む符号付きの４バイト２進変数である。"ｎ
ｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ"は、関係のあるｅｖ
ｅｎｔ＿ｎａｍｅとｅｖｅｎｔ＿ｋｅｙの対の数を含む
符号付きの４バイト２進変数である。"ｅｖｅｎｔ＿ｎ
ａｍｅ＿ａｄｄｒｅｓｓ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｅ
ｖｅｎｔｓ個の４バイト・ポインタ変数のアレイであ
り、その各要素は、その発生が監視されるイベントの名
前のアドレスを含む。"ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎ
ｇｔｈ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符
号付き４バイト２進変数のアレイであり、その各要素
は、ｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓアレイの対
応する要素が指すｅｖｅｎｔ＿ｎａｍｅの長さを含
む。"ｅｖｅｎｔ＿ｋｅｙ＿ａｄｄｒｅｓｓ"は、ｎｕｍ
ｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の４バイト・ポインタ変
数のアレイであり、その各要素は、監視されるｅｖｅｎ
ｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓアレイの対応するエント
リが指すｅｖｅｎｔ＿ｎａｍｅの特定のインスタンスを
さらに特徴づけるキーのアドレスを含む。このキーは、
関係のある信号によって搬送されるキーとぴったり一致
するように選択することができ、または部分キー（おそ
らくワイルドカード文字を含む）をより広い範囲の発生
に合致するように使用することができる。"ｅｖｅｎｔ
＿ｋｅｙ＿ｌｅｎｇｔｈ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｅ
ｖｅｎｔｓ個の符号付き４バイト２進変数のアレイであ
り、その各要素は、ｅｖｅｎｔ＿ｋｅｙ＿ａｄｄｒｅｓ
ｓアレイの対応する要素が指すｅｖｅｎｔ＿ｋｅｙの長
さを含む。このキーは、関係のある発生を定義するため
にイベントの２次的特徴付けが必要でない場合は、空で
よい（すなわち、その長さは０でよい）。モニタ内の空
白キーは信号上の任意のキーに合致する。"ｂｏｕｎｄ
＿ｓｉｇｎａｌ＿ｌｉｍｉｔ"は、ｎｕｍｂｅｒ＿ｏｆ
＿ｅｖｅｎｔｓ個の符号付き４バイト２進変数のアレイ
であり、その各要素は、モニタがすでに活動状態または
テスト可能である間、または監視された条件が満足され
ないままである間、イベント・モニタに結合されている
が未処理の状態に保持できる、対応するイベント名／イ
ベント・キー対の信号の数を含む。限界を超えたとき、
特定のｅｖｅｎｔ＿ｎａｍｅ／ｅｖｅｎｔ＿ｋｅｙ対の
最も古い結合信号が新しく到着した信号用の場所をあけ
るために放棄される。許される最小値は１であり、これ
は各信号の最近のインスタンスだけが保持されることを
意味する。値−１は、仮想記憶域が利用できるという条
件の下で結合信号リストが無制限に成長できることを意
味する。その他の負の値または０は、エラーと見なされ
る。"ｅｖｅｎｔ＿ｃｏｕｎｔ"は、監視された条件が満
足されたと見なされるために信号がモニタに結合されな
ければならない、指定されたｅｖｅｎｔ＿ｎａｍｅとｅ
ｖｅｎｔ＿ｋｅｙの対の数を含む符号付き４バイト２進
変数である。この値は１とｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅ
ｎｔｓの間でなければならない。あるいは、本発明の別
の実施例では、ｅｖｅｎｔ＿ｃｏｕｎｔは、イベント・
モニタを満足させるために必要な各イベント・タイプの
発生回数を示すために、各イベント・タイプごとに指定
される。

【００８９】ＥｖｅｎｔＭｏｎｉｔｏｒＤｅｌｅｔｅｒｅｔｃｏｄｅｒｓｎｃｏｄｅｍｏｎｉｔｏｒ＿ｔｏｋｅｎ

【００９０】パラメータ："ＥｖｅｎｔＭｏｎｉｔｏｒ
Ｄｅｌｅｔｅ"は、呼び出される機能の名前である。"ｒ
ｅｔｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉｔｏｒＤｅｌｅ
ｔｅからの戻りコードを保持するための符号付き４バイ
ト２進変数である。"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＭ
ｏｎｉｔｏｒＤｅｌｅｔｅからの理由コードを保持する
ための符号付き４バイト２進変数である。"ｍｏｎｉｔ
ｏｒ＿ｔｏｋｅｎ"は、削除されるイベント・モニタを
識別するトークンを含む符号付きの４バイト２進変数で
ある。値０は、現スレッド上で最近に活動化された活動
状態のイベント・モニタを識別するために使用される。

【００９１】ＥｖｅｎｔＭｏｎｉｔｏｒＥｎａｂｌｅｒｅｔｃｏｄｅｒｓｎｃｏｄｅｎｕｍｂｅｒ＿ｏｆ＿ｍｏｎｉｔｏｒｓｍｏｎｉｔｏｒ＿ｔｏｋｅｎｓｍｏｎｉｔｏｒ＿ｅｎａｂｌｅｍｅｎｔ＿ｍａｓｋｓ

【００９２】パラメータ："ＥｖｅｎｔＭｏｎｉｔｏｒ
Ｅｎａｂｌｅ"は、呼び出される機能の名前である。"ｒ
ｅｔｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉｔｏｒＥｎａｂ
ｌｅからの戻りコードを保持するための符号付き４バイ
ト２進変数である。"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＭ
ｏｎｉｔｏｒＥｎａｂｌｅからの理由コードを保持する
ための符号付き４バイト２進変数である。"ｎｕｍｂｅ
ｒ＿ｏｆ＿ｍｏｎｉｔｏｒｓ"は、関係のあるｍｏｎｉ
ｔｏｒ＿ｔｏｋｅｎｓの数を含む符号付き４バイト２進
変数である。"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎｓ"は、ｎｕ
ｍｂｅｒ＿ｏｆ＿ｍｏｎｉｔｏｒｓ個の４バイト・ポイ
ンタ変数のアレイであり、その各要素は、イネーブルま
たはディスエーブルされるモニタのトークンを含む。値
０は、現スレッド上で最近に活動化された活動状態のイ
ベント・モニタを識別するために使用される。"ｍｏｎ
ｉｔｏｒ＿ｅｎａｂｌｅｍｅｎｔ＿ｍａｓｋｓ"は、ｎ
ｕｍｂｅｒ＿ｏｆ＿ｍｏｎｉｔｏｒｓ個の符号付き４バ
イト２進変数のアレイであり、その各要素は、ｍｏｎｉ
ｔｏｒ＿ｔｏｋｅｎｓアレイの対応する要素によって識
別されるモニタ用のイネーブル・マスクを含む。モニタ
・イネーブル・マスクの値が、実行される以下の処置を
決定する。すなわち、ｍｏｎｉｔｏｒ＿ｔｏｋｅｎｓア
レイの対応する要素によって識別されるモニタをディス
エーブルすることを示す"ｖｍ＿ｅｖｎ＿ｄｉｓａｂｌ
ｅ"、及びｍｏｎｉｔｏｒ＿ｔｏｋｅｎｓアレイの対応
する要素によって識別されるモニタをイネーブルするこ
とを示す"ｖｍ＿ｅｖｎ＿ｅｎａｂｌｅ"である。

【００９３】ＥｖｅｎｔＭｏｎｉｔｏｒＱｕｅｒｙ−適
用業務プログラムは、以前に作成されたイベント・モニ
タの定義及び状況に関する情報を得るために、この機能
を呼び出すことができる。

【００９４】ＥｖｅｎｔＭｏｎｉｔｏｒＱｕｅｒｙｒｅｔｃｏｄｅｒｓｎｃｏｄｅｍｏｎｉｔｏｒ＿ｔｏｋｅｎｍｏｎｉｔｏｒ＿ｆｌａｇｍｏｎｉｔｏｒ＿ｆｌａｇ＿ｓｉｚｅｍｏｎｉｔｏｒ＿ｆｌａｇ＿ｃｏｕｎｔｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓｅｖｅｎｔ＿ｎａｍｅ＿ｂｕｆｆｅｒ＿ａｄｄｒｅｓｓｅｖｅｎｔ＿ｎａｍｅ＿ｂｕｆｆｅｒ＿ｌｅｎｇｔｈｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈｅｖｅｎｔ＿ｋｅｙ＿ｂｕｆｆｅｒ＿ａｄｄｒｅｓｓｅｖｅｎｔ＿ｋｅｙ＿ｂｕｆｆｅｒ＿ｌｅｎｇｔｈｅｖｅｎｔ＿ｋｅｙ＿ｌｅｎｇｔｈｂｏｕｎｄ＿ｓｉｇｎａｌ＿ｌｉｍｉｔｂｏｕｎｄ＿ｓｉｇｎａｌ＿ｃｏｕｎｔｍｏｎｉｔｏｒ＿ｓｅｌｅｃｔｉｏｎ＿ｍａｓｋｍｏｎｉｔｏｒ＿ｅｎａｂｌｅｍｅｎｔ＿ｍａｓｋｅｖｅｎｔ＿ｃｏｕｎｔｐｒｅｓｅｎｔ＿ｅｖｅｎｔ＿ｃｏｕｎｔｔｒａｐ＿ｒｏｕｔｉｎｅ＿ａｄｄｒｅｓｓｔｒａｐ＿ｒｏｕｔｉｎｅ＿ｎａｍｅ

【００９５】パラメータ："ＥｖｅｎｔＭｏｎｉｔｏｒ
Ｑｕｅｒｙ"は、呼び出される機能の名前である。"ｒｅ
ｔｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉｔｏｒＱｕｅｒｙ
からの戻りコードを保持するための符号付き４バイト２
進変数である。"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＭｏｎ
ｉｔｏｒＱｕｅｒｙからの理由コードを保持するための
符号付き４バイト２進変数である。"ｍｏｎｉｔｏｒ＿
ｔｏｋｅｎ"は、それに関する情報が返されるイベント
・モニタを識別する符号付きの４バイト２進変数であ
る。値０は、現スレッド上で最近に活動化された活動状
態のイベント・モニタを識別するために使用される。"
ｍｏｎｉｔｏｒ＿ｆｌａｇ"は、符号付きの４バイト２
進変数のアレイであり、その各要素中で、イベント・モ
ニタをどのように管理すべきかの情報が返される。以下
の各セットからそれぞれただ１つのオプションを含む。
モニタの寿命は、イベント・モニタが明示的Ｅｖｅｎｔ
ＭｏｎｉｔｏｒＤｅｌｅｔｅまで、または定義プロセス
の終了まで持続することを意味する"ｖｍ＿ｅｖｎ＿ｎ
ｏ＿ａｕｔｏ＿ｄｅｌｅｔｅ"、またはイベント・モニ
タが最初に非活動化されたときまたはＥｖｅｎｔＭｏｎ
ｉｔｏｒＲｅｓｅｔ呼出し時に自動的に削除されること
を意味する"ｖｍ＿ｅｖｎ＿ａｕｔｏ＿ｄｅｌｅｔｅ"に
よって指示される。指名可能性に関するモニタ活動化の
効果は、モニタを含むプロセス内のすべてのスレッドが
指名可能なままとなることを意味する"ｖｍ＿ｅｖｎ＿
ａｓｙｎｃ＿ｍｏｎｉｔｏｒ"（省略時指定）、または
モニタがその上で活動化されているスレッド（すなわ
ち、このイベント・モニタ用のイベント・ハンドラ）を
除き、現在モニタを含むプロセス内にあるすべてのスレ
ッドが、そのモニタが非活動化されるまで中断されるこ
とを意味する"ｖｍ＿ｅｖｎ＿ｓｙｎｃ＿ｐｒｏｃｅｓ
ｓ＿ｍｏｎｉｔｏｒ"によって指示される。ルース信号
のこのモニタへの結合は、モニタが作成されたまたはオ
ンに選択された時点で存在する任意の適格ルース信号が
このモニタに結合されていることを意味する"ｖｍ＿ｅ
ｖｎ＿ｂｉｎｄ＿ｌｏｏｓｅ＿ｓｉｇｎａｌｓ"（省略
時指定）、またはいかなるルース信号もこのモニタに結
合されていないことを意味する"ｖｍ＿ｅｖｎ＿ｉｇｎ
ｏｒｅ＿ｌｏｏｓｅ＿ｓｉｇｎａｌｓ"によって指示さ
れる。モニタの現在の活動化状態は、監視される条件が
満たされており、信号処理プログラムが実行中であるこ
とを意味する"ｖｍ＿ｅｖｎ＿ｍｏｎｉｔｏｒ＿ａｃｔ
ｉｖｅ"、モニタが活動状態でなく、監視される条件が
満たされておらず、モニタに関連する未処理のＥｖｅｎ
ｔＷａｉｔがあることを意味する"ｖｍ＿ｅｖｎ＿ｍｏ
ｎｉｔｏｒ＿ｗａｉｔｉｎｇ"、モニタが活動状態でも
待機状態でもなく、監視される条件が満たされておら
ず、モニタに関連するトラップ・ルーチンがあることを
意味する"ｖｍ＿ｅｖｎ＿ｍｏｎｉｔｏｒ＿ｔｒａｐｐ
ｉｎｇ"、またはモニタが活動状態でも待機状態でもト
ラッピング状態でもなく、監視される条件は満たされて
いることも満たされていないこともあり、モニタに関連
する未処理のＥｖｅｎｔＷａｉｔもトラップ・ルーチン
もないことを意味する"ｖｍ＿ｅｖｎ＿ｍｏｎｉｔｏｒ
＿ｔｅｓｔａｂｌｅ"によって指示される。"ｍｏｎｉｔ
ｏｒ＿ｆｌａｇ＿ｓｉｚｅ"は、ｍｏｎｉｔｏｒ＿ｆｌ
ａｇアレイ内の要素の数を含む、符号付きの４バイト２
進変数である。"ｍｏｎｉｔｏｒ＿ｆｌａｇ＿ｃｏｕｎ
ｔ"は、ＥｖｅｎｔＭｏｎｉｔｏｒＱｕｅｒｙによって
セットされたｍｏｎｉｔｏｒ＿ｆｌａｇアレイ内の要素
の数がその中で返される、符号付きの４バイト２進変数
である。"ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ"は、関係
のあるｅｖｅｎｔ＿ｎａｍｅとｅｖｅｎｔ＿ｋｅｙの対
の数を含む、符号付きの４バイト２進変数である。"ｅ
ｖｅｎｔ＿ｎａｍｅ＿ｂｕｆｆｅｒ＿ａｄｄｒｅｓｓ"
は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の４バイト・
ポインタ変数のアレイであり、その各要素は、その発生
が監視されるイベントの名前がその中で返される、文字
変数のアドレスを含む。"ｅｖｅｎｔ＿ｎａｍｅ＿ｂｕ
ｆｆｅｒ＿ｌｅｎｇｔｈ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｅ
ｖｅｎｔｓ個の符号付き４バイト２進変数のアレイであ
り、その各要素は、ｅｖｅｎｔ＿ｎａｍｅ＿ｂｕｆｆｅ
ｒ＿ａｄｄｒｅｓｓアレイの対応する要素が指すｅｖｅ
ｎｔ＿ｎａｍｅ＿ｂｕｆｆｅｒの長さを含む。"ｅｖｅ
ｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ"は、ｎｕｍｂｅｒ＿ｏ
ｆ＿ｅｖｅｎｔｓ個の符号付き４バイト２進変数のアレ
イであり、その各要素中で、ｅｖｅｎｔ＿ｎａｍｅ＿ｂ
ｕｆｆｅｒ＿ａｄｄｒｅｓｓアレイの対応する要素が指
すバッファに記憶されているｅｖｅｎｔ＿ｎａｍｅの実
際の長さが返される。この名前がバッファより長い場
合、それは切り捨てられる。短い場合は、バッファの終
りにある過剰スペースは変化しない。"ｅｖｅｎｔ＿ｋ
ｅｙ＿ｂｕｆｆｅｒ＿ａｄｄｒｅｓｓ"は、ｎｕｍｂｅ
ｒ＿ｏｆ＿ｅｖｅｎｔｓ個の４バイト・ポインタ変数の
アレイであり、その各要素は、監視されているｅｖｅｎ
ｔ＿ｎａｍｅ＿ｂｕｆｆｅｒ＿ａｒｒａｙの対応するエ
ントリが指すｅｖｅｎｔ＿ｎａｍｅの特定のインスタン
スをさらに特徴づけるキーがその中で返される、バッフ
ァのアドレスを含む。"ｅｖｅｎｔ＿ｋｅｙ＿ｂｕｆｆ
ｅｒ＿ｌｅｎｇｔｈ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅ
ｎｔｓ個の符号付き４バイト２進変数のアレイであり、
その各要素は、ｅｖｅｎｔ＿ｋｅｙ＿ｂｕｆｆｅｒ＿ａ
ｄｄｒｅｓｓアレイの対応する要素が指すバッファの長
さを含む。"ｅｖｅｎｔ＿ｋｅｙ＿ｌｅｎｇｔｈ"は、ｎ
ｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符号付き４バイト
２進変数のアレイであり、その各要素中で、ｅｖｅｎｔ
＿ｋｅｙ＿ｂｕｆｆｅｒ＿ａｄｄｒｅｓｓアレイの対応
する要素が指すバッファに記憶されているｅｖｅｎｔ＿
ｋｅｙの実際の長さが返される。このキーがバッファよ
り長い場合、それは切り捨てられる。短い場合は、バッ
ファの終りにある過剰スペースは変化しない。"ｂｏｕ
ｎｄ＿ｓｉｇｎａｌ＿ｌｉｍｉｔ"は、ｎｕｍｂｅｒ＿
ｏｆ＿ｅｖｅｎｔｓ個の符号付き４バイト２進変数のア
レイであり、その各要素中で、モニタがすでに活動状態
またはテスト可能である期間、または監視される条件が
満足されないままである間、イベント・モニタに結合さ
れているが未処理の状態に保持される対応するイベント
名／イベント・キー対の信号の数が返される。限界を超
えたとき、特定のｅｖｅｎｔ＿ｎａｍｅとｅｖｅｎｔ＿
ｋｅｙの対の最も古い結合信号が新しく到着した信号用
の場所をあけるために放棄される。許容される最小値は
１であり、これは各信号の最近のインスタンスだけが保
持されることを意味する。値−１は、仮想記憶域が利用
できるという条件の下で結合信号リストが無制限に成長
できることを意味する。"ｂｏｕｎｄ＿ｓｉｇｎａｌ＿
ｃｏｕｎｔ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個
の符号付き４バイト２進変数のアレイであり、その各要
素中で、イベント・モニタに現在結合されているが未処
理である対応するイベント名／イベント・キー対の信号
の数が返される。"ｍｏｎｉｔｏｒ＿ｓｅｌｅｃｔｉｏ
ｎ＿ｍａｓｋ"は、このモニタ用の選択マスクがその中
で返される、４バイト変数である。この変数は、このモ
ニタがオフに選択されるかオンに選択されるかを示
す。"ｍｏｎｉｔｏｒ＿ｅｎａｂｌｅｍｅｎｔ＿ｍａｓ
ｋ"は、このモニタ用のイネーブル・マスクがその中で
返される、４バイト２進変数である。この変数は、この
モニタがディスエーブルされるかイネーブルされるかを
示す。"ｅｖｅｎｔ＿ｃｏｕｎｔ"は、監視される条件が
満足されたと見なすためにそれに対する信号がモニタに
結合されなければならない、指定されたｅｖｅｎｔ＿ｎ
ａｍｅとｅｖｅｎｔ＿ｋｅｙの対の数がその中で返され
る、符号付き４バイト２進変数である。"ｐｒｅｓｅｎ
ｔ＿ｅｖｅｎｔ＿ｃｏｕｎｔ"は、それに対する信号が
イベント・モニタに現在結合されている、指定されたｅ
ｖｅｎｔ＿ｎａｍｅとｅｖｅｎｔ＿ｋｅｙの対の数がそ
の中で返される、符号付き４バイト２進変数である。"
ｔｒａｐ＿ｒｏｕｔｉｎｅ＿ａｄｄｒｅｓｓ"は、モニ
タによって定義された条件が満たされることが、Ｅｖｅ
ｎｔＴｒａｐ機能によって確立されたときに呼び込まれ
るルーチンのアドレスがその中で返される、４バイト２
進変数である。ＥｖｅｎｔＴｒａｐによってアドレスが
確立されていない場合は、値０が返される。"ｔｒａｐ
＿ｒｏｕｔｉｎｅ＿ｎａｍｅ"は、モニタによって定義
された条件が満たされることがＥｖｅｎｔＴｒａｐ機能
によって確立されたときに、呼び込まれるルーチンの名
前がその中で返される８バイト変数であり、またどのイ
ベント・トラップもモニタと関連していない場合はブラ
ンクが返される。

【００９６】ＥｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔｒｅｔｃｏｄｅｒｓｎｃｏｄｅｍｏｎｉｔｏｒ＿ｔｏｋｅｎ

【００９７】パラメータ："ＥｖｅｎｔＭｏｎｉｔｏｒ
Ｒｅｓｅｔ"は、呼び込まれる機能の名前である。"ｒｅ
ｔｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ
からの戻りコードを保持するための符号付き４バイト２
進変数である。"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＭｏｎ
ｉｔｏｒＲｅｓｅｔからの理由コードを保持するための
符号付き４バイト２進変数である。"ｍｏｎｉｔｏｒ＿
ｔｏｋｅｎ"は、その状態がリセットされるモニタを識
別するトークンを含む、符号付きの４バイト２進変数で
ある。値０は、現スレッド上で最近に活動化された活動
状態のイベント・モニタを識別するために使用される。

【００９８】ＥｖｅｎｔＭｏｎｉｔｏｒＳｅｌｅｃｔｒｅｔｃｏｄｅｒｓｎｃｏｄｅｎｕｍｂｅｒ＿ｏｆ＿ｍｏｎｉｔｏｒｓｍｏｎｉｔｏｒ＿ｔｏｋｅｎｓｍｏｎｉｔｏｒ＿ｓｅｌｅｃｔｉｏｎ＿ｍａｓｋｓ

【００９９】パラメータ："ＥｖｅｎｔＭｏｎｉｔｏｒ
Ｓｅｌｅｃｔ"は、呼び込まれる機能の名前である。"ｒ
ｅｔｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉｔｏｒＳｅｌｅ
ｃｔからの戻りコードを保持するための符号付き４バイ
ト２進変数である。"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＭ
ｏｎｉｔｏｒＳｅｌｅｃｔからの理由コードを保持する
ための符号付き４バイト２進変数である。"ｎｕｍｂｅ
ｒ＿ｏｆ＿ｍｏｎｉｔｏｒｓ"は、関係のあるｍｏｎｉ
ｔｏｒ＿ｔｏｋｅｎｓの数を含む、符号付き４バイト２
進変数である。"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎｓ"は、ｎ
ｕｍｂｅｒ＿ｏｆ＿ｍｏｎｉｔｏｒｓ個の４バイト２進
変数のアレイであり、その各要素は、オンまたはオフに
選択されるモニタのトークンを含む。値０は、現スレッ
ド上で最近に活動化された活動状態のイベント・モニタ
を識別するために使用される。"ｍｏｎｉｔｏｒ＿ｓｅ
ｌｅｃｔｉｏｎ＿ｍａｓｋｓ"は、ｎｕｍｂｅｒ＿ｏｆ
＿ｍｏｎｉｔｏｒｓ個の符号付き４バイト２進変数のア
レイであり、その各要素は、ｍｏｎｉｔｏｒ＿ｔｏｋｅ
ｎｓアレイの対応する要素によって識別されるモニタ用
の選択マスクを含む。選択マスクの値が、実行される処
置、すなわち、ｍｏｎｉｔｏｒ＿ｔｏｋｅｎｓアレイの
対応する要素によって識別されるモニタの監視の停止を
意味する"ｖｍ＿ｅｖｎ＿ｓｅｌｅｃｔ＿ｏｆｆ"、及び
ｍｏｎｉｔｏｒ＿ｔｏｋｅｎｓアレイの対応する要素に
よって識別されるモニタの監視の開始を意味する"ｖｍ
＿ｅｖｎ＿ｓｅｌｅｃｔ＿ｏｎ"を決定する。

【０１００】ＥｖｅｎｔＱｕｅｒｙ−適用業務プログラ
ムは、イベント発生の影響を受ける可能性のある、現プ
ロセスにおいて定義されているすべてのイベント・モニ
タのリストを含む既存のイベント定義に関する情報を得
るために、この機能を呼び出すことができる。Ｅｖｅｎ
ｔＭｏｎｉｔｏｒＱｕｅｒｙ機能は、特定のイベン
ト・モニタに関するより詳しい情報を得るために使用で
きる。

【０１０１】ＥｖｅｎｔＱｕｅｒｙｒｅｔｃｏｄｅｒｓｎｃｏｄｅｅｖｅｎｔ＿ｎａｍｅｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈｅｖｅｎｔ＿ｆｌａｇｅｖｅｎｔ＿ｆｌａｇ＿ｓｉｚｅｅｖｅｎｔ＿ｆｌａｇ＿ｃｏｕｎｔｌｏｏｓｅ＿ｓｉｇｎａｌ＿ｌｉｍｉｔｓｉｇｎａｌ＿ｔｉｍｅｏｕｔ＿ｐｅｒｉｏｄｌｏｏｓｅ＿ｓｉｇｎａｌ＿ｃｏｕｎｔｅｖｅｎｔ＿ｓｅｌｅｃｔｉｏｎ＿ｍａｓｋｅｖｅｎｔ＿ｅｎａｂｌｅｍｅｎｔ＿ｍａｓｋｍｏｎｉｔｏｒ＿ｔｏｋｅｎｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｓｉｚｅｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｃｏｕｎｔ

【０１０２】パラメータ："ＥｖｅｎｔＱｕｅｒｙ"は、
呼び込まれる機能の名前である。"ｒｅｔｃｏｄｅ"は、
ＥｖｅｎｔＱｕｅｒｙからの戻りコードを保持するため
の符号付き４バイト２進変数である。"ｒｓｎｃｏｄｅ"
は、ＥｖｅｎｔＱｕｅｒｙからの理由コードを保持する
ための符号付き４バイト２進変数である。"ｅｖｅｎｔ
＿ｎａｍｅ"は、照会されるイベントの名前を含む文字
変数である。"ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ"
は、ｅｖｅｎｔ＿ｎａｍｅの長さを含む符号付き４バイ
ト２進変数である。"ｅｖｅｎｔ＿ｆｌａｇ"は、イベン
トがどのように管理されるかに関する情報がその中で返
される、符号付きの４バイト２進変数のアレイである。
以下の各セットからのそれぞれただ１つのオプションが
含まれる。イベント名の範囲は、指定されたプロセスを
意味する"ｖｍ＿ｅｖｎ＿ｐｒｏｃｅｓｓ＿ｓｃｏｐ
ｅ"、または指定されたセッションを意味する"ｖｍ＿ｅ
ｖｎ＿ｓｅｓｓｉｏｎ＿ｓｃｏｐｅ"によって指示され
る。イベント信号が複数のイベント・モニタに伝搬され
る方式は、同報通信を意味する"ｖｍ＿ｅｖｎ＿ｂｒｏ
ａｄｃａｓｔ＿ｓｉｇｎａｌｓ"、ＦＩＦＯシーケンス
を意味する"ｖｍ＿ｅｖｎ＿ｆｉｆｏ＿ｓｉｇｎａｌ
ｓ"、またはＬＩＦＯシーケンスを意味する"ｖｍ＿ｅｖ
ｎ＿ｌｉｆｏ＿ｓｉｇｎａｌｓ"によって指示される。
シグナラの処理は、信号通知スレッドが実行を継続でき
ることを意味する"ｖｍ＿ｅｖｎ＿ａｓｙｎｃ＿ｓｉｇ
ｎａｌｓ"（省略時指定）、信号通知スレッドがイベン
ト処理の結果を待って中断されていることを意味する"
ｖｍ＿ｅｖｎ＿ｓｙｎｃ＿ｔｈｒｅａｄ＿ｓｉｇｎａｌ
ｓ"、またはモニタが信号によって活動化された結果と
して走行しているスレッドを除く、信号通知プロセスに
おけるすべてのスレッドが、イベント処理の結果を待っ
て中断されていることを意味する"ｖｍ＿ｅｖｎ＿ｓｙ
ｎｃ＿ｐｒｏｃｅｓｓ＿ｓｉｇｎａｌｓ"によって指示
される。"ｅｖｅｎｔ＿ｆｌａｇ＿ｓｉｚｅ"は、ｅｖｅ
ｎｔ＿ｆｌａｇアレイ内の要素の数を含む符号付き４バ
イト２進変数である。"ｅｖｅｎｔ＿ｆｌａｇ＿ｃｏｕ
ｎｔ"は、ＥｖｅｎｔＱｕｅｒｙによってセットされた
ｅｖｅｎｔ＿ｆｌａｇアレイ内の要素の数がその中で返
される、符号付き４バイト２進変数である。"ｌｏｏｓ
ｅ＿ｓｉｇｎａｌ＿ｌｉｍｉｔ"は、信号が結合される
適格イベント・モニタが存在しない場合、またはイベン
トが信号で通知された時点でプロセスがイベントについ
て監視していない場合に保持されるイベント信号の数が
その中で返される、符号付き４バイト２進変数のアレイ
である。限界を超えたとき、最も古いルース信号が、新
しく到着した信号用の場所をあけるために放棄される。
値０は、ルース信号が保持されていないことを示す。値
−１は、仮想記憶域が利用できるという条件の下でルー
ス信号セットが無制限に成長できることを意味する。"
ｓｉｇｎａｌ＿ｔｉｍｅｏｕｔ＿ｐｅｒｉｏｄ"は、信
号通知スレッドが信号の処理の完了を待って中断状態に
留まることができる、マイクロ秒で指定された時間の最
大長さがその中で返される、符号付きの４バイト２進変
数である。値０は、信号通知スレッドが信号処理の完了
を無限に待つことを示す。信号通知スレッドが処理を続
けることを指定するオプションがｅｖｅｎｔ＿ｆｌａｇ
アレイ内に含まれている場合、このパラメータは無意味
である。"ｌｏｏｓｅ＿ｓｉｇｎａｌ＿ｃｏｕｎｔ"は、
特定のイベントに関して現在保持されているルース信号
の数がその中で返される、符号付き４バイト２進変数で
ある。"ｅｖｅｎｔ＿ｓｅｌｅｃｔｉｏｎ＿ｍａｓｋ"
は、イベント選択マスクの状態、すなわちｅｖｅｎｔ＿
ｎａｍｅについて監視しないことを意味する"ｖｍ＿ｅ
ｖｎ＿ｓｅｌｅｃｔ＿ｏｆｆ"、またはｅｖｅｎｔ＿ｎ
ａｍｅについて監視することを意味する"ｖｍ＿ｅｖｎ
＿ｓｅｌｅｃｔ＿ｏｎ"がその中で返される、符号付き
４バイト２進変数である。"ｅｖｅｎｔ＿ｅｎａｂｌｅ
ｍｅｎｔ＿ｍａｓｋ"は、イベント・イネーブル・マス
クの状態、すなわちｅｖｅｎｔ＿ｎａｍｅについてディ
スエーブルされたことを意味する"ｖｍ＿ｅｖｎ＿ｄｉ
ｓａｂｌｅ"、またはｅｖｅｎｔ＿ｎａｍｅについてイ
ネーブルされたことを意味する"ｖｍ＿ｅｖｎ＿ｅｎａ
ｂｌｅ"がその中で返される、４バイト２進変数であ
る。イベント選択マスク及びイネーブル・マスクは、プ
ロセスごとに維持され、発行プロセスについてだけ報告
される。"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ"は、指定された
イベントの影響を受ける可能性のある、現プロセスにお
いて定義されたイベント・モニタを識別するトークンの
リストがその中で返される、符号付きの４バイト２進変
数のアレイである。順次式と定義されたイベントでは、
トークンはイベントが処理される順序で出力される。同
報通信と定義されたイベントでは、トークンはモニタが
作成された順序で出力される。"ｍｏｎｉｔｏｒ＿ｔｏ
ｋｅｎ＿ｓｉｚｅ"は、充填に使用できるｍｏｎｉｔｏ
ｒ＿ｔｏｋｅｎアレイ内の要素の数を含む、符号付きの
４バイト２進変数である。"ｍｏｎｉｔｏｒ＿ｔｏｋｅ
ｎ＿ｃｏｕｎｔ"は、指定されたイベントの影響を受け
る可能性のある、現プロセスにおいて定義されたイベン
ト・モニタの総数がその中で返される、符号付きの４バ
イト２進変数である。ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｃ
ｏｕｎｔがｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｓｉｚｅより
大きくない場合、ｍｏｎｉｔｏｒ＿ｔｏｋｅｎアレイの
第１のｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｃｏｕｎｔ要素
は、モニタ・セット全体を識別するトークンを含み、ア
レイの残りの要素は不変である。そうでない場合は、第
１ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｓｉｚｅ個のモニタ・
トークンが返される。

【０１０３】ＥｖｅｎｔＱｕｅｒｙＡｌｌ−適用業務プ
ログラムは、すべてのイベントの名前、及びこのプロセ
スにとって可視のすべてのイベント・モニタ用のトーク
ンを得るために、この機能を呼び出すことができる。Ｅ
ｖｅｎｔＱｕｅｒｙ及びＥｖｅｎｔＭｏｎｉｔｏｒＱｕ
ｅｒｙ機能は、イベント及びイベント・モニタに関する
より詳しい情報を得るために使用される。

【０１０４】ＥｖｅｎｔＱｕｅｒｙＡｌｌｒｅｔｃｏｄｅｒｓｎｃｏｄｅｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈａｃｔｕａｌ＿ｎａｍｅ＿ｌｅｎｇｔｈｍｏｎｉｔｏｒ＿ｔｏｋｅｎｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｓｉｚｅｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｃｏｕｎｔ

【０１０５】パラメータ："ＥｖｅｎｔＱｕｅｒｙＡｌ
ｌ"は、呼び込まれる機能の名前である。"ｒｅｔｃｏｄ
ｅ"は、ＥｖｅｎｔＱｕｅｒｙＡｌｌからの戻りコード
を保持するための符号付き４バイト２進変数である。"
ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＱｕｅｒｙＡｌｌから
の理由コードを保持するための符号付き４バイト２進変
数である。"ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ"は、以
下の３つのアレイ内の要素の数を含む符号付きの４バイ
ト２進変数である。"ｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒ
ｅｓｓ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の４
バイト・ポインタ変数のアレイであり、その各要素は、
定義されたイベントの名前がその中で返される文字変数
のアドレスを含む。"ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇ
ｔｈ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符号
付き４バイト２進変数のアレイであり、その各要素は、
ｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓアレイの対応す
る要素のバッファの長さを含む。この名前がバッファよ
り長い場合、それは切り捨てられる。短い場合は、バッ
ファの終りにある過剰スペースは不変である。"ａｃｔ
ｕａｌ＿ｎａｍｅ＿ｌｅｎｇｔｈ"は、ｎｕｍｂｅｒ＿
ｏｆ＿ｅｖｅｎｔｓ個の符号付き４バイト２進変数のア
レイである。この機能は、このアレイを使用してｅｖｅ
ｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓアレイの対応する要素
が指すイベント名の長さを出力する。"ｍｏｎｉｔｏｒ
＿ｔｏｋｅｎ"は、現プロセスにおいて定義されたすべ
てのイベント・モニタを識別するトークンのリストがそ
の中で返される、符号付きの４バイト２進変数のアレイ
である。"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｓｉｚｅ"は、
充填に使用できるｍｏｎｉｔｏｒ＿ｔｏｋｅｎアレイ内
の要素の数を含む、符号付きの４バイト２進変数であ
る。"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｃｏｕｎｔ"は、現
プロセスにおいて定義されたイベント・モニタの総数が
その中で返される、符号付きの４バイト２進変数であ
る。ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｃｏｕｎｔがｍｏｎ
ｉｔｏｒ＿ｔｏｋｅｎ＿ｓｉｚｅより大きくない場合、
ｍｏｎｉｔｏｒ＿ｔｏｋｅｎアレイの第１のｍｏｎｉｔ
ｏｒ＿ｔｏｋｅｎ＿ｃｏｕｎｔ要素は、モニタ・セット
全体を識別するトークンを含み、アレイの残りの要素は
不変である。そうでない場合は、第１ｍｏｎｉｔｏｒ＿
ｔｏｋｅｎ＿ｓｉｚｅ個のモニタ・トークンだけが返さ
れる。

【０１０６】ＥｖｅｎｔＲｅｔｒｉｅｖｅｒｅｔｃｏｄｅｒｓｎｃｏｄｅｍｏｎｉｔｏｒ＿ｔｏｋｅｎｉｎｄｅｘｄａｔａ＿ｂｕｆｆｅｒｄａｔａ＿ｂｕｆｆｅｒ＿ｌｅｎｇｔｈｅｖｅｎｔ＿ｄａｔａ＿ｌｅｎｇｔｈ

【０１０７】パラメータ："ＥｖｅｎｔＲｅｔｒｉｅｖ
ｅ"は、呼び込まれる機能の名前である。"ｒｅｔｃｏｄ
ｅ"は、ＥｖｅｎｔＲｅｔｒｉｅｖｅからの戻りコード
を保持するための符号付き４バイト２進変数である。"
ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＲｅｔｒｉｅｖｅから
の理由コードを保持するための符号付き４バイト２進変
数である。"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ"は、その現信
号セットから取出しが実行されるモニタを識別するトー
クンを含む、符号付きの４バイト２進変数のアレイであ
る。値０は、現スレッド上で最近に活動化された活動状
態のイベント・モニタを識別するために使用される。"
ｉｎｄｅｘ"は、イベント・モニタの作成時に指定され
たｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓ、ｅｖｅｎｔ
＿ｎａｍｅ＿ｌｅｎｇｔｈ、ｅｖｅｎｔ＿ｋｅｙ＿ａｄ
ｄｒｅｓｓ及びｅｖｅｎｔ＿ｋｅｙ＿ｌｅｎｇｔｈアレ
イへのインデックスとして、データがそこから取り出さ
れる信号に対応するｅｖｅｎｔ＿ｎａｍｅとｅｖｅｎｔ
＿ｋｅｙの対を識別する、符号付きの４バイト２進変数
である。"ｄａｔａ＿ｂｕｆｆｅｒ"は、インデックスに
よって識別されたｅｖｅｎｔ＿ｎａｍｅとｅｖｅｎｔ＿
ｋｅｙの対に関する信号で通知されたデータがその中で
返される文字変数である。"ｄａｔａ＿ｂｕｆｆｅｒ＿
ｌｅｎｇｔｈ"は、ｄａｔａ＿ｂｕｆｆｅｒの定義され
た長さを含む符号付きの４バイト２進変数である。"ｅ
ｖｅｎｔ＿ｄａｔａ＿ｌｅｎｇｔｈ"は、インデックス
によって識別されたｅｖｅｎｔ＿ｎａｍｅとｅｖｅｎｔ
＿ｋｅｙの対に関する信号で通知されたデータの長さが
その中で返される、符号付きの４バイト２進変数であ
る。ｅｖｅｎｔ＿ｄａｔａ＿ｌｅｎｇｔｈがｄａｔａ＿
ｂｕｆｆｅｒ＿ｌｅｎｇｔｈより大きい場合、信号で通
知されたデータは右側が切り捨てられ、警告戻りコード
が生成される。

【０１０８】ＥｖｅｎｔＳｅｌｅｃｔｒｅｔｃｏｄｅｒｓｎｃｏｄｅｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈｅｖｅｎｔ＿ｓｅｌｅｃｔｉｏｎ＿ｍａｓｋ

【０１０９】パラメータ："ＥｖｅｎｔＳｅｌｅｃｔ"
は、呼び込まれる機能の名前である。"ｒｅｔｃｏｄｅ"
は、ＥｖｅｎｔＳｅｌｅｃｔからの戻りコードを保持す
るための符号付き４バイト２進変数である。"ｒｓｎｃ
ｏｄｅ"は、ＥｖｅｎｔＳｅｌｅｃｔからの理由コード
を保持するための符号付き４バイト２進変数である。"
ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ"は、関係のあるイ
ベントの数を含む符号付き４バイト２進変数である。"
ｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓ"は、ｎｕｍｂ
ｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の４バイト・ポインタ変数
のアレイであり、その各要素は、その信号がオンまたは
オフに選択されるイベントの名前のアドレスを含む。"
ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ"は、ｎｕｍｂｅ
ｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符号付き４バイト２進変数
のアレイであり、その各要素は、ｅｖｅｎｔ＿ｎａｍｅ
＿ａｄｄｒｅｓｓアレイの対応する要素が指すｅｖｅｎ
ｔ＿ｎａｍｅの長さを含む。"ｅｖｅｎｔ＿ｓｅｌｅｃ
ｔｉｏｎ＿ｍａｓｋ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅ
ｎｔｓ個の符号付き４バイト２進変数のアレイであり、
その各要素は、ｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓ
アレイの対応する要素が指すｅｖｅｎｔ＿ｎａｍｅの選
択マスクを含む。選択マスクの値が、実行される処置、
すなわちｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓアレイ
の対応する要素が指すｅｖｅｎｔ＿ｎａｍｅの監視を停
止することを意味する"ｖｍ＿ｅｖｎ＿ｓｅｌｅｃｔ＿
ｏｆｆ"、またはｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓ
ｓアレイの対応する要素が指すｅｖｅｎｔ＿ｎａｍｅの
監視を開始することを意味する"ｖｍ＿ｅｖｎ＿ｓｅｌ
ｅｃｔ＿ｏｎ"を決定する。

【０１１０】ＥｖｅｎｔＳｉｇｎａｌｒｅｔｃｏｄｅｒｓｎｃｏｄｅｅｖｅｎｔ＿ｎａｍｅｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈｅｖｅｎｔ＿ｄａｔａｅｖｅｎｔ＿ｄａｔａ＿ｌｅｎｇｔｈｅｖｅｎｔ＿ｋｅｙ＿ｏｆｆｓｅｔｅｖｅｎｔ＿ｋｅｙ＿ｌｅｎｇｔｈ

【０１１１】パラメータ："ＥｖｅｎｔＳｉｇｎａｌ"
は、呼び込まれる機能の名前である。"ｒｅｔｃｏｄｅ"
は、ＥｖｅｎｔＳｉｇｎａｌからの戻りコードを保持す
るための符号付き４バイト２進変数である。"ｒｓｎｃ
ｏｄｅ"は、ＥｖｅｎｔＳｉｇｎａｌからの理由コード
を保持するための符号付き４バイト２進変数である。"
ｅｖｅｎｔ＿ｎａｍｅ"は、その発生が信号で通知され
るイベントの名前を含む文字変数である。"ｅｖｅｎｔ
＿ｎａｍｅ＿ｌｅｎｇｔｈ"は、ｅｖｅｎｔ＿ｎａｍｅ
の長さを含む符号付き４バイト２進変数である。"ｅｖ
ｅｎｔ＿ｄａｔａ"は、関係のあるイベント・モニタに
とって使用可能となるデータを含む文字変数である。"
ｅｖｅｎｔ＿ｄａｔａ＿ｌｅｎｇｔｈ"は、ｅｖｅｎｔ
＿ｄａｔａの長さを与える符号付き４バイト２進変数キ
ーである。"ｅｖｅｎｔ＿ｋｅｙ＿ｏｆｆｓｅｔ"は、信
号で通知されるイベントの特定のインスタンスを特徴づ
けるキーの第１バイトのｅｖｅｎｔ＿ｄａｔａにおける
オフセットを含む符号付き４バイト２進変数である。"
ｅｖｅｎｔ＿ｋｅｙ＿ｌｅｎｇｔｈ"は、ｅｖｅｎｔ＿
ｄａｔａに含まれるキーの長さを含む符号付き４バイト
２進変数である。このタイプのイベントに、またはイベ
ントのこの発生にイベントの２次的特性づけが必要でな
い場合は、このキーは空白となる（すなわち、その長さ
は０である）。

【０１１２】ＥｖｅｎｔＴｅｓｔｒｅｔｃｏｄｅｒｓｎｃｏｄｅｍｏｎｉｔｏｒ＿ｔｏｋｅｎｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓｅｖｅｎｔ＿ｆｌａｇ

【０１１３】パラメータ："ＥｖｅｎｔＴｅｓｔ"は、呼
び込まれる機能の名前である。"ｒｅｔｃｏｄｅ"は、Ｅ
ｖｅｎｔＴｅｓｔからの戻りコードを保持するための符
号付き４バイト２進変数である。"ｒｓｎｃｏｄｅ"は、
ＥｖｅｎｔＴｅｓｔからの理由コードを保持するための
符号付き４バイト２進変数である。"ｍｏｎｉｔｏｒ＿
ｔｏｋｅｎ"は、その条件がテストされるモニタを識別
するトークンを含む符号付きの４バイト２進変数であ
る。値０は、現スレッド上で最近に活動化された活動状
態のイベント・モニタを識別するために使用される。"
ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ"は、その発生がテ
ストされるイベントの数を含む符号付き４バイト２進変
数である。一般に、これは、イベント・モニタの定義中
で指定されたｅｖｅｎｔ＿ｎａｍｅとｅｖｅｎｔ＿ｋｅ
ｙの組合せの数と同じになるはずである。"ｅｖｅｎｔ
＿ｆｌａｇ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個
の符号付き４バイト２進変数のアレイであり、その各要
素中で、イベント・モニタを定義する際に使用されたｅ
ｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓ、ｅｖｅｎｔ＿ｎ
ａｍｅ＿ｌｅｎｇｔｈ、ｅｖｅｎｔ＿ｋｅｙ＿ａｄｄｒ
ｅｓｓ及びｅｖｅｎｔ＿ｋｅｙ＿ｌｅｎｇｔｈアレイの
対応する要素によって指定されたｅｖｅｎｔ＿ｎａｍｅ
とｅｖｅｎｔ＿ｋｅｙの対によって識別されるイベント
の発生または非発生の指示が返される。すなわち、０、１、２．．．イベントが信号で通知され、その数
が、ＥｖｅｎｔＲｅｔｒｉｅｖｅ機能によって得られる
信号に関する提供されるデータの長さであることを示
す。 −１．．．．．．イベントが信号で通知されていないこ
とを示す。 −２．．．．．．イベント定義が削除されたことを示
す。 −３．．．．．．対応するｅｖｅｎｔ＿ｎａｍｅとｅｖ
ｅｎｔ＿ｋｅｙの対がイベント・モニタ内で定義されて
いなかったことを示す。

【０１１４】ＥｖｅｎｔＴｒａｐｒｅｔｃｏｄｅｒｓｎｃｏｄｅｍｏｎｉｔｏｒ＿ｔｏｋｅｎｔｒａｐ＿ｒｏｕｔｉｎｅ＿ａｄｄｒｅｓｓｔｒａｐ＿ｒｏｕｔｉｎｅ＿ｎａｍｅ

【０１１５】パラメータ："ＥｖｅｎｔＴｒａｐ"は、呼
び込まれる機能の名前である。"ｒｅｔｃｏｄｅ"は、Ｅ
ｖｅｎｔＴｒａｐからの戻りコードを保持するための符
号付き４バイト２進変数である。"ｒｓｎｃｏｄｅ"は、
ＥｖｅｎｔＴｒａｐからの理由コードを保持するための
符号付き４バイト２進変数である。"ｍｏｎｉｔｏｒ＿
ｔｏｋｅｎ"は、その条件がトラップされるモニタを識
別するトークンを含む、符号付きの４バイト２進変数で
ある。値０は、現スレッド上で最近に活動化された活動
状態のイベント・モニタを識別するために使用され
る。"ｔｒａｐ＿ｒｏｕｔｉｎｅ＿ａｄｄｒｅｓｓ"は、
モニタによって定義された条件が満たされたときに呼び
込まれるルーチンのアドレスを含む４バイト２進変数で
ある。あるアドレスがそのイベント・モニタと以前に関
連づけられていた場合、そのアドレスは新しいｔｒａｐ
＿ｒｏｕｔｉｎｅ＿ａｄｄｒｅｓｓで自動的に置き換え
られる。アドレスが非０値である場合、ｔｒａｐ＿ｒｏ
ｕｔｉｎｅ＿ｎａｍｅパラメータは無意味である。"ｔ
ｒａｐ＿ｒｏｕｔｉｎｅ＿ｎａｍｅ"は、モニタによっ
て定義される条件が満たされたときに呼び込まれるルー
チンの名前を含む８バイト文字変数である。このパラメ
ータは、ｔｒａｐ＿ｒｏｕｔｉｎｅ＿ａｄｄｒｅｓｓパ
ラメータが０の場合にだけ意味をもつ。ある名前がその
イベント・モニタと以前に関連づけられていた場合は、
その名前は新しいｔｒａｐ＿ｒｏｕｔｉｎｅ＿ｎａｍｅ
で自動的に置き換えられる。ｔｒａｐ＿ｒｏｕｔｉｎｅ
＿ａｄｄｒｅｓｓパラメータが０であり、ｔｒａｐ＿ｒ
ｏｕｔｉｎｅ＿ｎａｍｅがブランクである場合は、指定
されたイベント・モニタに関連するトラップが取り消さ
れる。

【０１１６】ＥｖｅｎｔＷａｉｔｒｅｔｃｏｄｅｒｓｎｃｏｄｅｍｏｎｉｔｏｒ＿ｔｏｋｅｎｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓｅｖｅｎｔ＿ｆｌａｇ

【０１１７】パラメータ："ＥｖｅｎｔＷａｉｔ"は、呼
び込まれる機能の名前である。"ｒｅｔｃｏｄｅ"は、Ｅ
ｖｅｎｔＷａｉｔからの戻りコードを保持するための符
号付き４バイト２進変数である。"ｒｓｎｃｏｄｅ"は、
ＥｖｅｎｔＷａｉｔからの理由コードを保持するための
符号付き４バイト２進変数である。"ｍｏｎｉｔｏｒ＿
ｔｏｋｅｎ"は、その条件を待つべきモニタを識別する
トークンを含む、符号付きの４バイト２進変数である。
モニタは、すでに待機状態にあってはならない。モニタ
にとって未処理の待機は一時にせいぜい１つである。値
０は、現スレッド上で最近に活動化された活動状態のイ
ベント・モニタを識別するために使用される。"ｎｕｍ
ｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ"は、ＥｖｅｎｔＷａｉｔ
機能が完了するときにその発生が示されるイベントの数
を含む、符号付き４バイト２進変数である。一般に、こ
れは、イベント・モニタの定義中で指定されたｅｖｅｎ
ｔ＿ｎａｍｅとｅｖｅｎｔ＿ｋｅｙの組合せの数と同じ
となるはずである。"ｅｖｅｎｔ＿ｆｌａｇ"は、ｎｕｍ
ｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符号付き４バイト２進
変数のアレイであり、その各要素中で、イベント・モニ
タを定義する際に使用されたｅｖｅｎｔ＿ｎａｍｅ＿ａ
ｄｄｒｅｓｓ、ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ、
ｅｖｅｎｔ＿ｋｅｙ＿ａｄｄｒｅｓｓ及びｅｖｅｎｔ＿
ｋｅｙ＿ｌｅｎｇｔｈアレイの対応する要素によって指
定されるｅｖｅｎｔ＿ｎａｍｅとｅｖｅｎｔ＿ｋｅｙの
対によって識別されるイベントの発生または非発生の指
示が返される。すなわち、０、１、２．．．イベントが信号で通知され、その数
が、ＥｖｅｎｔＲｅｔｒｉｅｖｅ機能によって得られる
信号に関する提供されるデータの長さであることを示
す。 −１．．．．．．イベントが信号で通知されていないこ
とを示す。 −２．．．．．．イベント定義が削除されたことを示
す。 −３．．．．．．対応するｅｖｅｎｔ＿ｎａｍｅとｅｖ
ｅｎｔ＿ｋｅｙの対がイベント・モニタ内で定義されて
いなかったことを示す。

【０１１８】トレース・テーブル上述のイベント管理サービスは、イベントがトレース・
イベントであるとき、下記のようにしてトレース・テー
ブルを確立し処理するために使用できる。先に指摘した
ように、各イベント定義は、（オンに選択されている）
関係のあるイベント・モニタがないときにルース信号セ
ット４１内のイベント定義に記憶し結合することのでき
るイベント信号の最大数を指定するルース信号限界を含
む。ルース信号限界に達したとき、以後の各イベント信
号は、最も古いイベント信号が消去されてその位置に記
憶される。一般に新しいイベント信号ほどより重要なト
レース情報を提供する。したがって、ルース信号セット
は、関係のあるイベント・モニタの定義を遅らせること
によって、後で定義されるイベント・モニタ用のイベン
ト信号のトレース・テーブルまたは「プール」として使
用することができる。あるプロセスがトレース・イベン
ト信号を処理することに関与するとき、そのプロセス
は、そのイベントに関係のあるイベント・モニタを定義
し、ＥｖｅｎｔＷａｉｔ機能、ＥｖｅｎｔＴｒａｐ機能
またはＥｖｅｎｔＴｅｓｔ機能を呼び出す。イベント・
モニタ作成の結果、イベント・モニタにとって関係のあ
るイベント用のルース信号が、図２０を参照して上述し
たようにイベント・モニタの結合信号セットに転送され
る。これらの信号がイベント・モニタを満足させるのに
十分である場合、イベント・モニタはＥｖｅｎｔＷａｉ
ｔ機能、ＥｖｅｎｔＴｒａｐ機能またはＥｖｅｎｔＴｅ
ｓｔ機能の呼出しに応答して現信号セットを確立し、関
連するプロセス内のイベント・ハンドラが、現信号セッ
ト内のイベント信号にアクセスすることができる。

【０１１９】このように、１つまたは複数のイベント定
義のルース信号セットは、該当するイベント・モニタを
後で定義することによって、関係のあるイベント・ハン
ドラがそれらの特定の要件に従ってそれにアクセスする
ことができる。また、各イベント・ハンドラは、実時間
で、すなわち要求があったとき、トレース・テーブルに
アクセスすることができ、現信号セットから直接に（直
接アクセス記憶装置（ＤＡＳＤ）などの外部記憶装置に
アクセスする必要なしに）トレース・データを処理する
ことができる。

【０１２０】ルース信号セットから結合信号セットへの
転送は、前述の各種の機能を使用して異なる方式で制御
できる。最初にイベントをオフに選択することなく、す
べてのトレース信号に関係のあるイベント・モニタが作
成された場合、そのイベント用のルース信号セット内の
すべてのルース信号がイベント・モニタに転送され、次
いでルース信号セットが完全に削除される。その結果、
関係のある第２のイベント・モニタが後で定義された場
合、これらのルース信号は関係のある第２のイベント・
モニタには使用できなくなる。しかし、２つ以上のイベ
ント・モニタがルース信号セットのコピーを必要とする
場合は、ルース信号をそれらのイベント・モニタのすべ
てに提供するために、以下の手順が利用できる。まず関
係のあるイベントが、ＥｖｅｎｔＳｅｌｅｃｔ機能の呼
出しによってオフに選択され（図１７の段階２５４）、
次いでこの機能がイベント定義を「オフに選択済み」と
マークする。次に、イベント・モニタが定義され、その
後、ＥｖｅｎｔＳｅｌｅｃｔ機能の別の呼出しによって
そのイベントがオンに選択される（図１７の段階２６
６）。これに応答して、ＥｖｅｎｔＳｅｌｅｃｔ機能が
イベント定義をオンに選択済みとマークし（段階２６
８）、イベント・モニタ定義を読み取ることによってそ
のイベントに関係のあるすべてのイベント・モニタを識
別する（段階２７０）。次に、ＥｖｅｎｔＳｅｌｅｃｔ
機能は、イベント定義中で同報通信モードが指定されて
いる場合は、すべてのルース信号のコピーをそのような
関係のあるすべてのイベント・モニタに転送し（ルース
信号セットを消去し）、またイベント定義中で伝搬モー
ドが指定されている場合は、すべてのルース信号をシー
ケンス内の第１のイベント・モニタに転送（しルース信
号セットを消去）する（段階２７２）。

【０１２１】やはり先に指摘したように、各イベント・
モニタ定義は、イベント・モニタに関係のある各イベン
トに関する結合信号限界及び満足レベルを含んでいる。
各イベントの結合信号限界は、イベント・モニタに結合
して記憶できる、そのイベント用のイベント信号の最大
数を示す。このイベント・タイプの次のイベント信号が
受け取られたとき、それは同じタイプのイベント用の最
も古いイベント信号を消去してその位置に記憶される。
同じイベント・モニタにとって関係のある異なるイベン
トの結合信号限界は変わり得る。各イベントの満足レベ
ルは、イベント・モニタが、関連するイベント・ハンド
ラに現信号セットからのイベント信号を提供できるよう
にするのに必要なイベントの発生の数を示す。同じイベ
ント・モニタにとって関係のある異なるイベントの満足
レベルは、変わり得る。すべてのイベントについて満足
レベルが満足されたときだけ、イベント・ハンドラは現
信号セットにアクセスすることができる。任意の数のイ
ベント・モニタを定義することができ、これらの定義は
イベント・タイプの同じ、異なる、または部分的にオー
バーラップするセットを参照することができる。１つの
イベントまたはイベント・セットは、複数のイベント・
モニタにとって関係があることができる。各適用業務プ
ログラムは、そ（れら）のイベント・モニタに対してそ
れ自体のパラメータ、すなわち関係のあるイベント・タ
イプ、結合限界、及び満足レベルを指定することができ
る。また、各適用業務プログラムは、ＥｖｅｎｔＤｅｌ
ｅｔｅ機能６９、ＥｖｅｎｔＥｎａｂｌｅ機能４４、Ｅ
ｖｅｎｔＭｏｄｉｆｙ機能７１、ＥｖｅｎｔＭｏｎｉｔ
ｏｒＤｅｌｅｔｅ機能６８、ＥｖｅｎｔＭｏｎｉｔｏｒ
Ｅｎａｂｌｅ機能６４、及びＥｖｅｎｔＭｏｎｉｔｏｒ
Ｓｅｌｅｃｔ機能６６の呼出しによって、それ自体のト
レース・テーブルを制御することができる。このような
制御ならびにイベント・モニタの作成は、いつでも、す
なわち動的に行える。

【０１２２】したがって、ルース信号セットを後で定義
されたイベント・モニタ用のトレース・テーブルまたは
プールとして使用する方法の代替法として、関係のある
イベントの発生前にイベント・モニタを定義し、これを
直接使用してトレース・テーブルを提供することができ
る。結合限界が「ラップ・サイズ」を確立し、満足レベ
ルは、要求に応じてイベント・ハンドラにとって使用可
能になる各タイプの信号の数を確立する。この構成で
は、イベント・モニタが満足される前にイベント・ハン
ドラがＥｖｅｎｔＴｒａｐまたはＥｖｅｎｔＷａｉｔ機
能を呼び出した場合、イベント・ハンドラは実時間で、
すなわちイベント・モニタが満足され次第、トレース・
テーブル（現信号セット）にアクセスすることができ
る。また、現信号セットが確立されており、イベント・
ハンドラが現信号セットにアクセスするとき、結合信号
セット内に新しいイベント信号用の場所をあけるために
現信号セットが消去される。この代替法は、ルース信号
セットをトレース・テーブルまたはプールとして使用す
るよりも優れたいくつかの利点を提供するが、複数のイ
ベント・モニタが同じイベントに関係があるときは、こ
の代替法ではすべてのイベント信号が（ルース信号限界
を超えたイベント信号さえも）すべてのイベント・モニ
タの結合信号セットに転送されるので、幾分より高いオ
ペレーティング・システム・オーバーヘッドを必要とす
る。これとは対照的に、ルース信号セットをトレース・
テーブルまたはプールとして利用する前の方法では、イ
ベント・モニタへの以後の転送のオーバーヘッドを必要
とするイベント信号の最大数がルース信号限界である。

【０１２３】トレース・テーブルの適切な確立、管理及
び使用を容易にし、確実にするために、適用業務プログ
ラム・インターフェースを含む下記の追加のトレース管
理サービスが提供される。これらのトレース管理サービ
スは、ＩＴＲＡＣＥ及びＥＴＲＡＣＥキーボード・コマ
ンド、またはＴＲＡＣＥＣＯＮＴＲＯＬ呼出しによって
管理される。ＴＲＡＣＥＣＯＮＴＲＯＬ呼出しは、所定
のセット中のどのトレース・イベントが信号で通知され
るか、及び信号で通知されたトレース・イベントの属性
を定義し、またいくつかの追加のトレース処理オプショ
ンを提供する。ＴＲＡＣＥＣＯＮＴＲＯＬ呼出しは、オ
ペレーティング・システム１１の会話モニタ・システム
（ＣＭＳ）部分に対して行われる。オペレーティング・
システム１１の会話モニタ・システム部分の標準機能の
多くは、ＩＢＭコーポレイションから１９９０年６月に
発行されたVM/ESA CMS Application Development Refer
ence（ＩＢＭ資料番号ＳＣ２４−５４５１−００）と題
する印刷物に記載されている。ＴＲＡＣＥＣＯＮＴＲＯ
Ｌ呼出しのフォーマットは以下の通りである。

【０１２４】ＴＲＡＣＥＣＯＮＴＲＯＬＲｔｎｃｏｄｅＲｓｎｃｏｄｅＴｒａｃｅｆｌｇＷｒａｐｓｉｚｅＦｕｎｃｔｉｏｎＮＴｒａｃｅｔｙｐｅ（Ｎ）Ｔｒａｃｅｔｙｐｅ＿Ｓｅｔｔｉｎｇ（Ｎ）

【０１２５】パラメータ："Ｒｔｎｃｏｄｅ"は、ＴＲＡ
ＣＥＣＯＮＴＲＯＬからの戻りコードを保持するための
符号付き４バイト２進変数である。"Ｒｓｎｃｏｄｅ"
は、ＴＲＡＣＥＣＯＮＴＲＯＬからの理由コードを保持
するための符号付き４バイト２進変数である。"Ｔｒａ
ｃｅｆｌｇ"は、トレース・イベントのシグナラがどの
程度同期化されるべきかを指定する。それは、符号付き
４バイト２進整数であり、有効値は以下の通りである。０（ＡＳＹＮＣ）信号通知スレッドがイベント処理と
は独立に処理を続ける。１（ＴＳＹＮＣ）信号通知スレッドがイベント処理の
結果を待って中断される。２（ＰＳＹＮＣ）信号通知プロセスがイベント処理の
結果を待って中断される。３（ＤＳＹＮＣ）信号通知プロセス及びそのすべての
子孫がイベント処理の結果を待って中断される。 −１（ＵＮＣＨ）同期化が変更されない。 "Ｗｒａｐｓｉｚｅ"は、イベントが信号で通知されると
きに適格なトレース・イベント・モニタが存在しない場
合、いくつのトレース・イベントが保持されるかを指定
する。これは、ルース信号限界に対応する。ｗｒａｐｓ
ｉｚｅを超えたとき、最も古いトレース・イベントが、
新しく到着した信号用の場所をあけるために放棄され
る。これは、４バイトの符号付き２進整数である。値０
は、トレース・イベントが保持されないことを示す。値
−１は、仮想記憶域がなくなるまでトレース・イベント
が保持され続けることを示す。値−２は、ｗｒａｐｓｉ
ｚｅが変更されないことを示す。その他の負の値は無効
である。"Ｆｕｎｃｔｉｏｎ"は、後に続くアレイの使用
を指定する。これは４バイトの符号付き２進整数であ
り、有効値は以下の通りである。０（ＱＵＥＲＹＩＴＲＡＣＥ）ＩＴＲＡＣＥトレー
スタイプが照会され、それらの設定がｔｒａｃｅｔｙｐ
ｅ＿ｓｅｔｔｉｎｇｓアレイ中で返される。１（ＱＵＥＲＹＥＴＲＡＣＥ）ＥＴＲＡＣＥトレー
スタイプが照会され、それらの設定がｔｒａｃｅｔｙｐ
ｅ＿ｓｅｔｔｉｎｇｓアレイ中で返される。２（ＩＴＲＡＣＥ）ｔｒａｃｅｔｙｐｅ及びｔｒａｃ
ｅｔｙｐｅ＿ｓｅｔｔｉｎｇが、ＩＴＲＡＣＥコマンド
への呼出し可能なインターフェースとして使用される。３（ＥＴＲＡＣＥ）ｔｒａｃｅｔｙｐｅ及びｔｒａｃ
ｅｔｙｐｅ＿ｓｅｔｔｉｎｇが、ＥＴＲＡＣＥコマンド
への呼出し可能なインターフェースとして使用される。 −１（ＵＮＣＨ）後続のアレイが無視されることを
示す。 "Ｎ"は、セットされるトレース・タイプの数を指定す
る。これは４バイトの符号付き２進整数である。"Ｔｒ
ａｃｅｔｙｐｅ"は、セットされるトレース・タイプを
指定する。それは、４バイトの符号付き２進整数のアレ
イであり、有効値は以下の通りである。０（ＡＬＬ）すべてのトレース・タイプ１（ＣＯＭＭ）通信イベント２（ＤＩＳＰ）指名イベント３（ＳＴＯＲ）記憶管理イベント４（ＩＯ）入出力イベント５（ＰＲＧＭＡＮ）プログラム管理イベント６（ＰＲＣＭＡＮ）プロセス管理イベント７（ＭＩＳＣ）タイマ、外部割込み及び機械チェ
ック・イベント８（ＤＴＭＡＮ）データ管理イベント９（ＧＲＯＵＰ）以前の設定が、仮想機械グループ
内のすべての機械に関するものである。 "ｔｒａｃｅｔｙｐｅ＿ｓｅｔｔｉｎｇ"は、ｔｒａｃｅ
ｔｙｐｅアレイに対応する設定を指定する。これは、４
バイトの符号付き２進整数のアレイであり、有効値は以
下の通りである。０（オフ）対応するトレース・タイプがオフにセット
される。０（オン）対応するトレース・タイプがオンにセット
される。

【０１２６】ＴＲＡＣＥＣＯＮＴＲＯＬ呼出しは、常に
セッション範囲のイベント定義及び同報通信信号をもた
らす。信号通知スレッドがイベント処理と独立に処理を
続けない場合、中断されたスレッドは無限に待つ、すな
わちタイムアウト期限はない。ｔｒａｃｅｔｙｐｅアレ
イ及びｔｒａｃｅｔｙｐｅ＿ｓｅｔｔｉｎｇアレイは配
列順に処理される。たとえば、ＡＬＬ及びＯＦＦに対応
する値がそれぞれのアレイ内の第１の要素である場合、
すべてのトレース・カテゴリがオフにセットされてか
ら、これらのアレイ内の後続の要素が処理される。その
結果、一般に、アレイ要素は、後続のアレイ要素によっ
て空白にされる。ＣＭＳは、その初期設定の一環として
以下のパラメータ設定でＴＲＡＣＥＣＯＮＴＲＯＬルー
チンを呼び出す。Ｆｕｎｃｔｉｏｎ＝ＩＴＲＡＣＥ、Ｔ
ｒａｃｅｆｌｇ＝ＡＳＹＮＣ、Ｗｒａｐｓｉｚｅ＝ＤＭ
ＳＮＧＰから決定、Ｎ＝１、Ｔｒａｃｅｔｙｐｅ＝ＡＬ
Ｌ、Ｔｒａｃｅｔｙｐｅ＿Ｓｅｔｔｉｎｇ＝ＯＮ。これ
らの設定は、システム・プロファイルが実行される前に
セットされ、したがってシステム・プロファイルによっ
てオーバーライドされることがある。

【０１２７】ＩＴＲＡＣＥキーボード・コマンドは、効
果の点でＴＲＡＣＥＣＯＮＴＲＯＬＡＰＩ呼出しと類似
しており、ＣＭＳによってイベント信号マネージャへ信
号で通知するために、事前定義されたトレース・イベン
トのうちのどれが選択されるか、及び「ラップ・サイ
ズ」またはルース信号限界を指定する。そのフォーマッ
トは以下の通りである。 "Ａｌｌ"は、すべてのトレース・エントリが信号で通知
されるか否かを指定する。許容される値は以下の通りで
ある。ＯＮトレース・エントリが信号で通知される。ＯＦＦトレース・エントリが信号で通知されない。 "Ｃｏｍｍｕｎｉｃａｔｉｏｎ"は、通信トレース・エン
トリが信号で通知されるか否かを指定する。このタイプ
のトレース・エントリの可能な例は、ＩＵＣＶ及びＡＰ
ＰＣトランザクション及び待ち行列動作である。許容さ
れる値は以下の通りである。ＯＮトレース・エントリが信号で通知される。ＯＦＦトレース・エントリが信号で通知されない。 "Ｄｉｓｐａｔｃｈ"は、指名トレース・エントリが信号
で通知されるか否かを指定する。このタイプのトレース
・エントリの可能な例は、ＴｈｒｅａｄＤｉｓｐａｔ
ｃｈ及びＴｈｒｅａｄＰｒｉｏｒｉｔｙＭｏｄｉｆ
ｉｃａｔｉｏｎである。許容される値は以下の通りであ
る。ＯＮトレース・エントリが信号で通知される。ＯＦＦトレース・エントリは信号で通知されない。 "Ｓｔｏｒａｇｅ"は、記憶トレース・エントリが信号で
通知されるか否かを指定する。このタイプのトレース・
エントリの可能な例は、ＦｒｅｅＳｔｏｒａｇｅＯ
ｂｔａｉｎ及びＦｒｅｅＳｔｏｒａｇｅＲｅｔｕｒ
ｎである。許容される値は以下の通りである。ＯＮトレース・エントリが信号で通知される。ＯＦＦトレース・エントリが信号で通知されない。 "Ｉ／Ｏ"は、入出力トレース・エントリが信号で通知さ
れるか否かを指定する。このタイプのトレース・エント
リの可能な例は、入出力要求及び入出力割込み発生であ
る。許容される値は以下の通りである。ＯＮトレース・エントリが信号で通知される。ＯＦＦトレース・エントリが信号で通知されない。 "Ｐｒｏｇｍａｎ"は、プログラム管理トレース・エント
リが信号で通知されるか否かを指定する。このタイプの
トレース・エントリの可能な例は、ＣｏｍｍａｎｄＬ
ｏａｄ及びＰｒｏｇｒａｍＬｏａｄである。許容され
る値は以下の通りである。ＯＮトレース・エントリが信号で通知される。ＯＦＦトレース・エントリが信号で通知されない。 "Ｐｒｏｃｍａｎ"は、プロセス管理トレース・エントリ
が信号で通知されるか否かを指定する。このタイプのト
レース・エントリの可能な例は、ＰｒｏｃｅｓｓＣｒ
ｅａｔｅ及びＴｈｒｅａｄＣｒｅａｔｅである。許容
される値は以下の通りである。ＯＮトレース・エントリが信号で通知される。ＯＦＦトレース・エントリが信号で通知されない。 "Ｄａｔａｍａｎ"は、データ管理トレース・エントリが
信号で通知されるか否かを指定する。このタイプのトレ
ース・エントリの可能な例は、ＦｉｌｅＳｙｓｔｅｍ
Ｒｅａｄ及びＦｉｌｅＳｙｓｔｅｍＷｒｉｔｅで
ある。許容される値は以下の通りである。ＯＮトレース・エントリが信号で通知される。ＯＦＦトレース・エントリが信号で通知されない。 "Ｍｉｓｃ"は、類別できないトレース・エントリが信号
で通知されるか否かを指定する。このタイプのトレース
・エントリの可能な例は、機械チェック、外部割込み及
びタイマ割込みである。許容される値は以下の通りであ
る。ＯＮトレース・エントリが信号で通知される。ＯＦＦトレース・エントリが信号で通知されない。 "Ｇｒｏｕｐ"は、信号で通知されるトレース・エントリ
が発行側の仮想機械グループ内のすべての機械において
信号で通知されるか否かを指定する。このオペランド
は、ＧＲＯＵＰオペランドが処理されているとき現在信
号で通知されているトレース・エントリだけに適用され
る。すなわち、ＧＲＯＵＰオペランドの右側のオペラン
ドは、ＧＲＯＵＰオペランドの影響を受けない。このオ
ペランドは、グループの一部分でない仮想機械によって
指定されない。許容される値は以下の通りである。ＯＮ仮想機械グループ内のすべての機械においてト
レース・エントリが信号で通知される。ＯＦＦ仮想機械グループ内の他のいずれかの機械にお
いてトレース・エントリが信号で通知されない。 "Ｅｎｄ"は、トレース・エントリが信号で通知されない
ことを指定する。"Ｗｒａｐｓｉｚｅｘｘｘ"は、トレ
ース・エントリが信号で通知されるとき適格なトレース
・イベント・モニタが存在しない場合に、いくつのトレ
ース・エントリがトレース・テーブル内に保持されるか
を指定する。ラップサイズを超えたとき、新しく到着し
た信号用の場所をあけるために最も古いトレース・エン
トリが放棄される。値０は、トレース・エントリが保持
されないことを示す。

【０１２８】ＥＴＲＡＣＥコマンドは、イベント信号を
スプール・ファイルに記録するために、選択されたトレ
ース・イベントのうちのどれがオペレーティング・シス
テム１１の制御プログラム内の所定のイベント・ハンド
ラに送られるかを指定する。この制御プログラムは、Ｉ
ＢＭコーポレイションから１９９０年６月に発行された
VM/ESA Diagnostics Guide for 370(ＩＢＭ資料番号Ｌ
Ｙ２４−５２４２−００）と題する印刷物に記載されて
いる多くの標準機能を提供する。ＥＴＲＡＣＥコマンド
のフォーマットは以下の通りである。ＥＴＲＡＣＥＥＶＥＮＴＮＡＭＥＯＮＯＲＯＦ
Ｆ、ＥＶＥＮＴＮＡＭＥＯＮＯＲＯＦＦＥＴＣ．

【０１２９】トレース管理サービスの利用に関する段階
は、以下の通りである。

【０１３０】まず、適用業務プログラムがＴＲＡＣＥＣ
ＯＮＴＲＯＬ呼出しを発行し、またはユーザがキーボー
ドを介して、どのトレース・イベントが構築され信号で
通知されるかを定義するＩＴＲＡＣＥコマンド、ならび
にラップ・サイズを入力する。次に、これらのトレース
・イベントが、ＣＭＳの処理における適当な時点で発生
し、ＣＭＳがシグナラとして機能して、イベント・デー
タを含むトレース・イベントを信号で通知する。トレー
ス・エントリのフォーマットは以下の通りである。１．ＨＥＡＤＥＲＬＥＮＧＴＨ−トレース・ヘッダ情
報の長さ。２．ＵＳＥＲＩＤ−トレース信号を発行する仮想機械の
ユーザ識別。３．ＰＲＯＣＥＳＳＩＤ−その代りにこのトレース・エ
ントリが信号で通知されるプロセスの一義的プロセス識
別子。４．ＴＲＥＡＤＩＤ−その代りにこのトレース・エント
リが信号で通知されるスレッドの一義的スレッド識別
子。５．ＴＲＡＣＥＩＤ−トレース・エントリの特定のタイ
プ。６．ＴＩＭＥＳＴＡＭＰ−トレース・エントリが信号で
通知される時間（タイマ単位で）。７．ＦＯＲＭＡＴＲＯＵＴＩＮＥ−このトレース・エ
ントリをフォーマットするのに必要なルーチンの識別
子。８．ＶＡＲＩＡＢＬＥＨＥＡＤＥＲＤＡＴＡ−ヘッ
ダに含まれるその他のデータ。９．ＤＡＴＡＬＥＮＧＴＨ−実際のトレース・データ
の長さ。１０．ＶＡＲＩＡＢＬＥＤＡＴＡ−実際のトレース・
データ。

【０１３１】イベント・モニタがトレース・イベントに
関係がない限り、記憶されるトレース・イベント信号の
最大数はラップ・サイズに等しく、これらのトレース・
イベントはルース信号セット内に記憶される。次に、ユ
ーザ適用業務プログラムは、ＥｖｅｎｔＭｏｎｉｔｏｒ
Ｃｒｅａｔｅ機能を呼び出して、イベントに関係のある
イベント・モニタを確立する。ＥｖｅｎｔＭｏｎｉｔｏ
ｒＣｒｅａｔｅ呼出しは、イベント・モニタの関係を制
限する制限キーの指定を含むことができる。このシナリ
オでは、イベントに関係のある確立された第１のイベン
ト・モニタだけがルース信号セットの内容を受け取る。
別法として、先に指摘したように、ルース信号セットの
コピーを２つ以上のイベント・モニタに提供するため
に、２つ以上のイベント・モニタが作成される前にイベ
ントをオフに選択することもできる。次に、ユーザ適用
業務プログラムは、ＥｖｅｎｔＷａｉｔまたはＥｖｅｎ
ｔＴｒａｐ機能を呼び出して、イベント・モニタが満足
されたとき現信号セットを得る。ユーザ適用業務プログ
ラムは、イベント・モニタが満足されたときその通知を
受け、ＥｖｅｎｔＲｅｔｒｉｅｖｅ機能を呼び出して現
信号セットの内容を読み取り、次いでイベント・データ
を処理することができる。

【０１３２】前述のトレース管理サービス及び適用業務
プログラム・インターフェースは仮想機械環境に関する
ものであるが、それらは他の環境でも有用であることを
理解されたい。

【０１３３】図２１及び図２２は、多重タスク処理オペ
レーティング・システム内でどのプログラム・スレッド
が実行されたか（障害追求のため）、及び各スレッドに
関する実行時間を追跡するために、トレース管理サービ
ス及び適用業務プログラム・インターフェースを使用す
る例を示す流れ図である。図２１は、この機能に関係す
る実際のトレース管理サービス及び適用業務プログラム
・インターフェースを示す。段階５００で、オペレーテ
ィング・システムは、ＥｖｅｎｔＣｒｅａｔｅ機能４０
の呼出しによって"Ｔｒａｃｅ"という名前のイベントを
作成する。次に、ユーザ適用業務プログラムは、ＴＲＡ
ＣＥＣＯＮＴＲＯＬ呼出しを発行し、その呼出し内のパ
ラメータとしてＤｉｓｐａｔｃｈイベント・タイプを指
定する（段階５０６）。オペレーティング・システム
は、その呼出しからＤｉｓｐａｔｃｈパラメータを読み
取り（段階５０８）、次いでＤｉｓｐａｔｃｈイベント
を信号で通知するようディスパッチャに通知する（段階
５１０）。ディスパッチャは、ＣＰＵ１９によって実行
されるプログラム・スレッドを選択する機能である。

【０１３４】図２２は、図２１で参照されたディスパッ
チャの流れ図である。段階５３０で、ディスパッチャ
は、ＣＰＵから古いスレッドを除去し、新しいスレッド
の実行を開始する。トレース・イベント信号を伴うイベ
ント・データを提供するために、ディスパッチャは現時
間を読み取り（クロックは図示せず）（段階５３２）、
この現時間を、新スレッドが実行を開始し旧スレッドが
実行を停止した時間として記憶する（段階５３４）。次
にディスパッチャは、旧スレッドのＣＰＵ実行時間を、
現時間と以前に記憶された旧スレッドの開始時間との差
として計算する（段階５３６）。次に、ディスパッチャ
は、ＥｖｅｎｔＳｉｇｎａｌ機能を呼び出し、以下のイ
ベント・データ、すなわち旧スレッドＩＤ、旧スレッド
のＣＰＵ使用時間、及び新スレッドＩＤを提供する（段
階５４０）。

【図面の簡単な説明】

【図１】本発明によるイベント管理サービスを提供する
オペレーティング・システムの重要な構成要素、及び関
連する適用業務プログラムのスレッド及びハードウェア
を示すブロック・ダイアグラムである。

【図２】イベントが発生し、関係のある適用業務プログ
ラム・スレッドが待機モードでそのイベントの通知を受
けたときの、図１のオペレーティング・システムの動作
を示す流れ図である。

【図３】イベントが発生し、関係のある適用業務プログ
ラム・スレッドが待機モードでそのイベントの通知を受
けたときの、図１のオペレーティング・システムの動作
を示す流れ図である。

【図４】イベントが発生し、関係のある適用業務プログ
ラム・スレッドが待機モードでそのイベントの通知を受
けたときの、図１のオペレーティング・システムの動作
を示す流れ図である。

【図５】図１のオペレーティング・システムのＥｖｅｎ
ｔＤｉｓｃａｒｄ機能を示す流れ図である。

【図６】図１のオペレーティング・システムのＥｖｅｎ
ｔＭｏｎｉｔｏｒＲｅｓｅｔ機能を示す流れ図である。

【図７】イベントが発生し、関係のある適用業務プログ
ラム・スレッドがテスト・モードでそのイベントの通知
を受けたときの、図１のオペレーティング・システムの
動作を示す流れ図である。

【図８】イベントが発生し、関係のある適用業務プログ
ラム・スレッドがトラップ・モードでそのイベントの通
知を受けたときの、図１のオペレーティング・システム
の動作を示す流れ図である。

【図９】イベントが発生し、関係のある適用業務プログ
ラム・スレッドがトラップ・モードでそのイベントの通
知を受けたときの、図１のオペレーティング・システム
の動作を示す流れ図である。

【図１０】同じイベントに関係のある２つのイベント・
モニタに信号で通知する同報通信モードを示す流れ図で
ある。

【図１１】同じイベントに関係のある２つのイベント・
モニタに信号で通知する伝搬モードを示す流れ図であ
る。

【図１２】同じイベントに関係のある、図１のオペレー
ティング・システム内部の２つのイベント・モニタの連
鎖を示すブロック・ダイアグラムである。

【図１３】異なるイベント・セットに関係のある、図１
のオペレーティング・システム内部の５つのイベント・
モニタの連鎖を示すブロック・ダイアグラムである。

【図１４】図１のオペレーティング・システムのＥｖｅ
ｎｔＤｅｌｅｔｅ機能を示す流れ図である。

【図１５】図１のオペレーティング・システムのＥｖｅ
ｎｔＥｎａｂｌｅ機能を示す流れ図である。

【図１６】図１のオペレーティング・システムのＥｖｅ
ｎｔＭｏｎｉｔｏｒＥｎａｂｌｅ機能を示す流れ図であ
る。

【図１７】図１のオペレーティング・システムのＥｖｅ
ｎｔＳｅｌｅｃｔ機能を示す流れ図である。

【図１８】図１のオペレーティング・システムのＥｖｅ
ｎｔＭｏｎｉｔｏｒＳｅｌｅｃｔ機能を示す流れ図であ
る。

【図１９】図１のオペレーティング・システムのＥｖｅ
ｎｔＭｏｎｉｔｏｒＤｅｌｅｔｅ機能を示す流れ図であ
る。

【図２０】図１のオペレーティング・システムのＥｖｅ
ｎｔＭｏｎｉｔｏｒＣｒｅａｔｅ機能を示す流れ図であ
る。

【図２１】図１のオペレーティング・システムのトレー
ス管理サービスを示す流れ図である。

【図２２】図１のオペレーティング・システムのトレー
ス管理サービスを示す流れ図である。

【符号の説明】

１１オペレーティング・システム１２イベント・ディファイナ１３イベント・ディファイナ１４イベント・ハンドラ１５イベント・シグナラ１６イベント定義１７イベント・モニタ・ディファイナ１８イベント・シグナラ１９中央演算処理装置（ＣＰＵ）２１コンピュータ・メモリ２６イベント信号マネージャ２８イベント・モニタ

───────────────────────────────────────────────────── フロントページの続き (72)発明者アン・マリー・シェパードアメリカ合衆国13760、ニューヨーク州エンドウェル、ワトソン・ブールバード 3606番地 (72)発明者スティーブン・ソール・シュルツアメリカ合衆国13760、ニューヨーク州エンディコット、バーナード・ブールバード 2016番地

Claims

【特許請求の範囲】

【請求項１】イベントを管理するためのコンピュータ・
システムにおいて、複数のプログラム、同じプログラムの複数の部分、また
は異なるプログラムの複数の部分があるイベントの通知
を受け取ることができる、シーケンスを定義する手段
と、シーケンス内の前記のプログラムまたは部分のうち第１
のものにイベントの発生について通知する手段と、イベント通知を前記シーケンス内の次のプログラムまた
は部分に伝搬すべきか否かを示す、前記第１のプログラ
ムまたは部分からの指示を受け取る手段と、前記の指示がイベント通知を伝搬することである場合
に、イベント通知をシーケンス内の前記の次のプログラ
ムまたは部分に伝搬する手段と、前記の指示がイベント通知を伝搬しないことである場合
に、シーケンス内の前記の次のプログラムまたは部分へ
のイベント通知の伝搬をブロックする手段とを含むコン
ピュータ・システム。
【請求項２】さらに、イベントを定義するパラメータを
受け取る手段を含み、前記パラメータの１つが、イベン
ト通知を受け取るシーケンス内の各プログラムまたは部
分による、イベント通知を伝搬するようにとの指示に従
って、イベント通知が伝搬手段によってシーケンス内の
次のプログラムまたは部分に順次伝搬できるかどうか、
または、前記のプログラムまたは部分による承認を得て
または承認を得ないで、そのイベントに関係のあるすべ
てのプログラム、同じプログラムのすべての部分、また
は異なるプログラムのすべての部分にイベント通知を同
報通信すべきかどうかを指定する、請求項１に記載のコ
ンピュータ・システム。
【請求項３】さらに、同報通信パラメータで定義される
イベントの信号に応答して、関係のあるすべてのプログ
ラムまたは部分にイベントの通知を同報通信する手段を
含む、請求項１に記載のコンピュータ・システム。
【請求項４】コンピュータ・システム内でイベントを管
理する方法であって、複数のプログラム、同じプログラムの複数の部分、また
は異なるプログラムの複数の部分があるイベントの通知
を受け取ることができる、シーケンスを定義する段階
と、シーケンス内の前記のプログラムまたは部分のうち第１
のものにイベントの発生について通知する段階と、イベント通知を前記シーケンス内の次のプログラムまた
は部分に伝搬すべきか否かを示す、前記第１のプログラ
ムまたは部分からの指示を受け取る段階と、前記の指示がイベント通知を伝搬することである場合
に、イベント通知をシーケンス内の前記の次のプログラ
ムまたは部分に伝搬する段階と、前記の指示がイベント通知を伝搬しないことである場合
に、シーケンス内の前記の次のプログラムまたは部分へ
のイベント通知の伝搬をブロックする段階とを含む方
法。
【請求項５】さらに、イベントを定義するパラメータを
受け取る段階を含み、前記パラメータの１つが、イベン
ト通知を受け取るシーケンス内の各プログラムまたは部
分による、イベント通知を伝搬するようにとの指示に従
って、イベント通知が伝搬手段によってシーケンス内の
次のプログラムまたは部分に順次伝搬できるかどうか、
または前記のプログラムまたは部分による承認を得てま
たは承認を得ないで、そのイベントに関係のあるすべて
のプログラム、同じプログラムのすべての部分、または
異なるプログラムのすべての部分にイベント通知を同報
通信すべきかどうかを指定する、請求項４に記載の方
法。
【請求項６】さらに、同報通信パラメータで定義される
イベントの信号を受け取る段階と、関係のあるすべてのプログラムまたは部分にイベントの
通知を同報通信する段階とを含む、請求項４に記載の方
法。
【請求項７】各定義が、あるイベントの処理中に上記イ
ベントのシグナラまたは上記イベント・シグナラに関連
するプロセスの動作モードを指定し、上記動作モードに
は、イベントが処理されるまでイベント・シグナラまた
は関連プロセスが処理を中断する同期モードと、イベン
トの処理中にイベント・シグナラまたは関連プロセスが
処理を継続する非同期モードとが含まれる、異なるタイ
プのイベントの定義を受け取る手段と、上記イベント・シグナラに結合された、上記イベントの
イベント信号を受信し、各イベントのイベント・シグナ
ラまたは関連プロセスに、イベント定義に従って同期的
に進めるのかそれとも非同期的に進めるのかを通知する
ためのイベント・マネージャ手段とを含むコンピュータ
・システム。
【請求項８】さらに、上記イベント・マネージャ手段に
結合された、上記コンピュータ内部で実行される適用業
務プログラム内に常駐し、上記イベントの通知を受取り
済みで上記イベントを処理中または処理済みのあるイベ
ント・ハンドラから、上記イベント・シグナラまたは関
連プロセスが他の処理を続行できるかどうかの通知を受
け取る手段を含み、上記イベント・マネージャ手段が、上記イベント・シグ
ナラまたは関連プロセスに、上記イベント・シグナラま
たは関連プロセスが中断されている場合、上記イベント
・ハンドラからの上記通知に基づいて他の処理を続行す
るかどうかを通知することを特徴とする、請求項７に記載のコンピュータ・システム。
【請求項９】さらに、対応するイベント定義に関連する
イベント信号を記憶する手段を含み、上記イベント・マネージャが、現在上記イベントに関係
のある適用業務プログラムがない時、記憶手段へのイベ
ント信号の記憶を制御することを特徴とする、請求項７に記載のコンピュータ・システム。
【請求項１０】あるイベントの定義を受け取るステップ
であって、上記定義が、イベントの処理中にイベントの
シグナラまたは上記イベント・シグナラに関連するプロ
セスの動作モードを指定し、上記動作モードには、イベ
ントが処理されるまでイベント・シグナラまたは関連プ
ロセスが処理を中断する同期モードと、イベントの処理
中にイベント・シグナラまたは関連プロセスが処理を続
行する非同期モードとが含まれる、イベント定義受取り
ステップと、イベントの信号を受け取るステップと、そのイベントのイベント・シグナラまたは関連プロセス
に、当該のイベント定義に従って同期的に進めるのかそ
れとも非同期的に進めるのかを通知するステップとを含
む、コンピュータ・システム内でイベントを管理する方
法。
【請求項１１】さらに、コンピュータ・システム内部で
実行される適用業務プログラム内に常駐し、イベントの
通知を受け取ったイベント・ハンドラから、イベント・
シグナラまたは関連プロセスが他の処理を続行できるか
どうかの通知を受け取るステップと、上記イベント・シグナラまたは関連プロセスに、上記イ
ベント・シグナラまたは関連プロセスが中断している場
合、上記イベント・ハンドラからの上記通知に基づいて
他の処理を続行するかどうか知らせるステップとを含
む、請求項１０に記載の方法。
【請求項１２】さらに、現在そのイベントに関係のある
適用業務プログラムがない時、対応するイベント定義に
関連する上記イベントの発生の信号を記憶するステップ
を含む、請求項１０に記載の方法。
【請求項１３】通知を受け取る際にイベント・モニタが
関係のあるイベントを指定する、イベント・モニタ用の
定義を受け取る手段と、上記受取り手段に結合され、上記定義に従って上記イベ
ント・モニタを確立する手段であって、複数のタイプの
イベントの発生の通知を受け取ることに関係のあるイベ
ント・モニタを確立する能力を有する、イベント・モニ
タ確立手段と、上記イベント・モニタにとって関係のある上記タイプの
イベントを含む様々なタイプのイベントの発生の信号を
受け取り、上記イベント・モニタに上記イベント・モニ
タにとって関係のある上記イベントの信号を転送する、
イベント・マネージャ手段とを含む、コンピュータ・シ
ステム。
【請求項１４】上記イベント・モニタが、イベント・モ
ニタ定義で指定されたタイプのイベントの信号を受け取
った時、関係のあるプログラムにその旨を通知する手段
を含むことを特徴とする、請求項１３に記載のコンピュ
ータ・システム。
【請求項１５】上記受取り手段が、それぞれの定義が通
知を受け取る際に当該の各イベント・モニタが関係のあ
るイベントを指定する、異なる複数のイベント・モニタ
用の複数の定義を受け取ることができ、確立手段が、当該の定義に従って複数のイベント・モニ
タを確立し、同じイベントの発生の通知を受け取ること
に関係のある複数のイベント・モニタを確立する能力を
有し、イベント・マネージャ手段が、上記の同じイベントの発
生に関係のある上記複数のイベント・モニタに、上記イ
ベントの発生の信号を送ることができることを特徴とす
る、請求項１３に記載のコンピュータ・システム。
【請求項１６】イベント・モニタ用の定義を受け取る手
段であって、上記定義が、通知を受け取る際に上記イベ
ント・モニタが関係のあるイベントを指定し、上記イベ
ント・モニタを満足するには上記イベントの複数回の発
生が必要である、受取り手段と、上記受取り手段に結合され、上記定義に従って上記イベ
ント・モニタを確立する手段と、上記イベントの複数の発生の信号を受け取り、上記イベ
ント信号を上記イベント・モニタに転送する、イベント
・マネージャ手段とを含み、上記イベント・モニタが、上記イベント・モニタが満足
された時、上記イベント・モニタに関連する関係のある
プログラムにその旨を通知する手段を含む、コンピュータ・システム。
【請求項１７】イベント・モニタ用の定義を受け取る手
段であって、上記定義が通知を受け取る際にイベント・
モニタが、関係のあるイベントを指定する、受取り手段
と、上記受取り手段に結合され、上記定義に従って上記イベ
ント・モニタを確立する手段と、上記イベントの発生の信号を受け取り、上記信号を上記
イベント・モニタに転送する、イベント・マネージャ手
段とを含み、上記受取り手段が、上記イベント・マネージャ手段の動
作期間の大部分を通じてあるプログラムから上記定義を
受け取ることができ、上記確立手段が、上記コンピュー
タ・システムの動作を停止することなく、上記定義に従
って上記イベント・モニタを動的に確立することがで
き、さらに、上記イベントに関係のあるイベント・モニタが
ない場合に、あるイベントの１つまたは複数のイベント
信号を記憶する手段と、上記イベントに関係のあるイベント・モニタがない場合
に記憶された上記イベントの上記イベント信号を、後で
作成される、上記イベントに関係のあるイベント・モニ
タに転送する手段とを含む、コンピュータ・システム。
【請求項１８】上記イベント・モニタが、上記イベント
・モニタが上記イベントの１つまたは複数の信号を受け
取った時、関係のあるプログラムにその旨を通知する手
段を含むことを特徴とする、請求項１７に記載のコンピ
ュータ・システム。
【請求項１９】上記受取り手段が、異なる複数のイベン
ト・モニタ用の複数の定義を受け取り、上記各定義が、
上記イベントの通知を受け取ることに上記各イベント・
モニタが関係のあることを指定し、上記確立手段が、当該の定義に従って複数のイベント・
モニタを確立し、上記各イベント・モニタが、上記コンピュータ・システ
ムを停止することなく、上記イベント・マネージャ手段
の動作期間の大部分を通じて適用業務プログラムによっ
て異なる時に定義し確立することができ、イベント・マネージャが、そのイベントが発生した時に
確立済みであったイベント・モニタに上記イベントの各
発生の信号を送ることができ、さらに、上記イベントに関係のあるイベント・モニタが
ない時に記憶された上記イベントのイベント信号を後で
生成される、上記イベントに関係のある複数のイベント
・モニタに転送する手段を含む、請求項１７に記載のコンピュータ・システム。
【請求項２０】関係のあるプログラムがない場合に記憶
されるイベント信号の最大数を指定する、あるイベント
の定義を記憶するステップと、上記イベントの発生の信号を受け取るステップと、上記イベントに関係のあるプログラムがない場合に、上
記イベント定義中の上記最大数による制限の下でイベン
ト信号を上記イベント定義と関連して記憶するステップ
と、上記記憶ステップに続いて、記憶されるイベント信号の
最大数を指定する定義で上記プログラム用のイベント・
モニタを定義することにより、上記イベントに対する上
記プログラムの関係を確立するステップと、確立ステップの後、上記イベント定義中の上記最大数と
は異なってもよい上記イベント・モニタ定義中の上記最
大数による制限の下で、記憶されたイベント信号を上記
イベント・モニタに転送するステップとを含む、コンピ
ュータ・システム中でイベントを管理する方法。
【請求項２１】さらに、関係のあるプログラムから上記
イベント・モニタへの要求に応じて、上記プログラムに
上記イベントの発生を通知するステップを含む、請求項
２０に記載の方法。