JPH0799502B2 - コンピュータ・システム - Google Patents

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

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

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

【０００５】プログラム・トレース・イベントなどある
タイプのイベントは周期的に発生する。システム／３８
オペレーティング・システムでは、関心があるイベント
・モニタに結び付けて保持すべきイベント及び関連する
イベント・データの最大数を指定することができ、また
は関心があるイベント・モニタがディスエーブルされて
いる間、これらのイベント及び関連イベント・データを
無制限に保持すると指定することができる。前者の場
合、イベント及び関連イベント・データの最大数を超え
たとき、最大水準を超える以後の新しいイベント及び関
連するイベント・データが放棄される。システム／３８
オペレーティング・システムでは、イベントを管理する
際にかなりの量の制御及び効率がもたらされ、関連する
適用業務プログラムがイベント管理サービスの定義に参
加することが可能であるが、コンピュータ・システム及
び関連する適用業務プログラムの具体的要件に応じてオ
ペレーティング・システムがより効率的かつ包括的にイ
ベントを管理できるようにするために、一層の改良が望
まれる。

【０００６】

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

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

【０００８】

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

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

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

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

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

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

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

【００１５】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００３３】先に指摘したように、通常、各イベント・
モニタ・デファイナ及び関連するイベント・ハンドラは
同じプロセスの一部分であって、あるプロセスが１つの
イベントまたは複数のイベントの組合せを監視し、その
イベントまたは組合せを処理しようとするとき、そのプ
ロセスがイベント・モニタを定義し、関連するイベント
・ハンドラを提供する。このイベント・ハンドラは、イ
ベント・ハンドラによるＥｖｅｎｔＴｅｓｔ、Ｅｖｅｎ
ｔＴｒａｐまたはＥｖｅｎｔＷａｉｔ機能の呼出しに基
づいて通知を受ける。このプロセスはイベント・モニタ
を定義または削除し、動的に、すなわちいつでも、Ｅｖ
ｅｎｔＭｏｎｉｔｏｒＣｒｅａｔｅまたはＥｖｅｎｔＭ
ｏｎｉｔｏｒＤｅｌｅｔｅ機能及びＥｖｅｎｔＴｅｓ
ｔ、ＥｖｅｎｔＴｒａｐまたはＥｖｅｎｔＷａｉｔ機能
を呼び出すことによって、他のプログラムを再連係また
は割り込むことなしに、イベント・ハンドラと関与する
ことができる。また、複数のプロセスが、複数のイベン
ト・モニタを定義し、同じまたは異なるイベントまたは
複数のイベントの組合せ用の複数のイベント・ハンドラ
を提供することもできる。呼出しを受け取った後、Ｅｖ
ｅｎｔＭｏｎｉｔｏｒＣｒｅａｔｅ機能は、その呼出し
内のすべてのパラメータを読み取り記憶する（図２０の
段階８０）。次に、ＥｖｅｎｔＭｏｎｉｔｏｒＣｒｅａ
ｔｅ機能は、ルース信号を結合すべきことをイベント・
モニタ・フラグ・パラメータが示すかどうかを判定する
（判断ブロック８２）。イエスの場合、ＥｖｅｎｔＭｏ
ｎｉｔｏｒＣｒｅａｔｅ機能は、イベント・モニタにと
って関心がある各イベントの定義に関連するルース信号
セットを読み取って、イベント・モニタにとって関心の
ある制限キーをもつルース信号（「適格イベント」）が
あるかどうか決定する。イベント・モニタにとって関係
があるためには、ルース信号は、セッション範囲をもつ
か、またはプロセス範囲をもたなければならず、そのイ
ベントはイベント・モニタを定義したのと同じプロセス
によって定義される。以前にイベントの発生がなかった
場合、または別のイベント・モニタがそのイベントに関
与するように以前に定義されていた場合、ルース信号は
ない。関心があるルース信号がある場合、ＥｖｅｎｔＭ
ｏｎｉｔｏｒＣｒｅａｔｅ機能は、これらすべてのルー
ス信号をイベント・モニタに転送し（段階８６）、イベ
ント・モニタは、下記で図２の段階１１５を参照して述
べる結合限界に従って、それらのルース信号を自分自身
に関連づける。その後、ＥｖｅｎｔＭｏｎｉｔｏｒＣｒ
ｅａｔｅ機能は、その呼出し側に戻る（段階８８）。

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

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

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

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

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

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

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

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

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

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

【００４４】１）ＥｖｅｎｔＴｅｓｔ機能は、イベント
・ハンドラによって呼び出された場合、イベント・ハン
ドラに各イベント名／イベント・キー対の状態を報告す
る。 ２）ＥｖｅｎｔＷａｉｔ機能は、イベント・ハンドラに
よって呼び出された場合、イベント・モニタをリセット
し、イベント・モニタが再び満足されるまでイベント・
ハンドラを中断する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００６７】イベント信号マネージャ機能呼出し ＥｖｅｎｔＣｒｅａｔｅ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｅｖｅｎｔ＿ｎａｍｅ ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ ｅｖｅｎｔ＿ｆｌａｇ ｅｖｅｎｔ＿ｆｌａｇ＿ｓｉｚｅ ｌｏｏｓｅ＿ｓｉｇｎａｌ＿ｌｉｍｉｔ ｓｉｇｎａｌ＿ｔｉｍｅｏｕｔ＿ｐｅｒｉｏｄ パラメータ： "ＥｖｅｎｔＣｒｅａｔｅ"は、呼び込まれる機能の名前
である。

【００６８】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＣｒｅａ
ｔｅからの戻りコードを保持するための符号付き４バイ
ト２進変数である。「戻りコード」は、呼出しまたはパ
ラメータの成否またはエラーの有無を示す。

【００６９】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＣｒｅａ
ｔｅからの理由コードを保持するための符号付き４バイ
ト２進変数である。「理由コード」は、呼出しまたはパ
ラメータの失敗またはエラーの理由を示す。

【００７０】"ｅｖｅｎｔ＿ｎａｍｅ"は、定義されるイ
ベントの名前を含む文字変数である。

【００７１】"ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ"
は、ｅｖｅｎｔ＿ｎａｍｅの長さを含む符号付き４バイ
ト２進変数である。

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

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

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

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

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

【００７７】 Ｅｖｅｎｔ Ｄｅｌｅｔｅ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｅｖｅｎｔ＿ｎａｍｅ ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ パラメータ： "ＥｖｅｎｔＤｅｌｅｔｅ"は、呼び出される機能の名前
である。

【００７８】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＤｅｌｅ
ｔｅからの戻りコードを保持するための符号付きの４バ
イト２進変数である。

【００７９】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＤｅｌｅ
ｔｅからの理由コードを保持するための符号付きの４バ
イト２進変数である。

【００８０】"ｅｖｅｎｔ＿ｎａｍｅ"は、その定義が削
除されるイベントの名前を含む文字変数である。

【００８１】"ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ"
は、ｅｖｅｎｔ＿ｎａｍｅの長さを含む符号付きの４バ
イト２進変数である。

【００８２】 ＥｖｅｎｔＤｉｓｃａｒｄ ｒｅｔｃｏｄｅ， ｒｓｎｃｏｄｅ， ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ， ｉｎｄｅｘ パラメータ： "ＥｖｅｎｔＤｉｓｃａｒｄ"は、呼び出される機能の名
前である。

【００８３】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＤｉｓｃ
ａｒｄからの戻りコードを保持するための符号付きの４
バイト２進変数である。

【００８４】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＤｉｓｃ
ａｒｄからの理由コードを保持するための符号付きの４
バイト２進変数である。

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

【００８６】 ＥｖｅｎｔＥｎａｂｌｅ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ ｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓ ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ ｅｖｅｎｔ＿ｅｎａｂｌｅｍｅｎｔ＿ｍａｓｋ パラメータ： "ＥｖｅｎｔＥｎａｂｌｅ"は、呼び出される機能の名前
である。

【００８７】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＥｎａｂ
ｌｅからの戻りコードを保持するための符号付きの４バ
イト２進変数である。

【００８８】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＥｎａｂ
ｌｅからの理由コードを保持するための符号付きの４バ
イト２進変数である。

【００８９】"ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ"は、
関心があるｅｖｅｎｔ＿ｎａｍｅとｅｖｅｎｔ＿ｋｅｙ
の対の数を含む符号付きの４バイト２進変数である。

【００９０】"ｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓ"
は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の４バイト・
ポインタ変数のアレイであり、その各要素はその発生を
監視すべきイベントの名前のアドレスを含む。

【００９１】"ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ"
は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符号付き４
バイト２進変数のアレイであり、その各要素はｅｖｅｎ
ｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓアレイの対応する要素が
指すｅｖｅｎｔ＿ｎａｍｅの長さを含む。

【００９２】"ｅｖｅｎｔ＿ｅｎａｂｌｅｍｅｎｔ＿ｍ
ａｓｋ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符
号付き４バイト２進変数のアレイであり、その各要素は
ｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓアレイの対応す
る要素が指すｅｖｅｎｔ＿ｎａｍｅのイネーブル・マス
クを含む。イベント・イネーブル・マスクは、プロセス
ごとに維持され、ＥｖｅｎｔＥｎａｂｌｅコマンドは発
行プロセスだけに影響を与える。イネーブル・マスクの
値が、実行される以下の処置を決定する。すなわち、ｅ
ｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓアレイの対応する
要素によって指示されるｅｖｅｎｔ＿ｎａｍｅをディス
エーブルすることを示す"ｖｍ＿ｅｖｎ＿ｄｉｓａｂｌ
ｅ"、またはｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓア
レイの対応する要素によって指示されるｅｖｅｎｔ＿ｎ
ａｍｅをイネーブルすることを示す"ｖｍ＿ｅｖｎ＿ｅ
ｎａｂｌｅ"である。

【００９３】 ＥｖｅｎｔＭｏｄｉｆｙ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｅｖｅｎｔ＿ｎａｍｅ ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ ｅｖｅｎｔ＿ｆｌａｇ ｅｖｅｎｔ＿ｆｌａｇ＿ｓｉｚｅ ｌｏｏｓｅ＿ｓｉｇｎａｌ＿ｌｉｍｉｔ ｓｉｇｎａｌ＿ｔｉｍｅｏｕｔ＿ｐｅｒｉｏｄ パラメータ： "ＥｖｅｎｔＭｏｄｉｆｙ"は、呼び出される機能の名前
である。

【００９４】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＭｏｄｉ
ｆｙからの戻りコードを保持するための符号付きの４バ
イト２進変数である。

【００９５】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＭｏｄｉ
ｆｙからの理由コードを保持するための符号付きの４バ
イト２進変数である。

【００９６】"ｅｖｅｎｔ＿ｎａｍｅ"は、その定義が修
正されるイベントの名前を含む文字変数である。

【００９７】"ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ"
は、ｅｖｅｎｔ＿ｎａｍｅの長さを含む符号付きの４バ
イト２進変数である。

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

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

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

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

【０１０２】 ＥｖｅｎｔＭｏｎｉｔｏｒＣｒｅａｔｅ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ ｍｏｎｉｔｏｒ＿ｆｌａｇ ｍｏｎｉｔｏｒ＿ｆｌａｇ＿ｓｉｚｅ ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ ｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓ ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ ｅｖｅｎｔ＿ｋｅｙ＿ａｄｄｒｅｓｓ ｅｖｅｎｔ＿ｋｅｙ＿ｌｅｎｇｔｈ ｂｏｕｎｄ＿ｓｉｇｎａｌ＿ｌｉｍｉｔ ｅｖｅｎｔ＿ｃｏｕｎｔ パラメータ： "ＥｖｅｎｔＭｏｎｉｔｏｒＣｒｅａｔｅ"は、呼び出さ
れる機能の名前である。

【０１０３】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉ
ｔｏｒＣｒｅａｔｅからの戻りコードを保持するための
符号付き４バイト２進変数である。

【０１０４】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉ
ｔｏｒＣｒｅａｔｅからの理由コードを保持するための
符号付き４バイト２進変数である。

【０１０５】"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ"は、他のイ
ベント管理機能が後で呼び込まれるときにイベント・モ
ニタを識別するトークンがその中で返される、符号付き
の４バイト２進変数である。

【０１０６】"ｍｏｎｉｔｏｒ＿ｆｌａｇ"は、符号付き
の４バイト２進変数のアレイであり、その各要素は、イ
ベント・モニタをどのように管理すべきかの情報を含
む。以下の各セットからそれぞれただ１つのオプション
を指定することができる。特定のセットからのオプショ
ンが与えられていない場合、省略時指定が適用される。

【０１０７】モニタの寿命は、イベント・モニタが明示
的ＥｖｅｎｔＭｏｎｉｔｏｒＤｅｌｅｔｅまで持続する
ことを意味する"ｖｍ＿ｅｖｎ＿ｎｏ＿ａｕｔｏ＿ｄｅ
ｌｅｔｅ"（省略時）、またはイベント・モニタが最初
に非活動化されるときに、またはＥｖｅｎｔＭｏｎｉｔ
ｏｒＲｅｓｅｔ時に自動的に削除されることを意味す
る"ｖｍ＿ｅｖｎ＿ａｕｔｏ＿ｄｅｌｅｔｅ"によって指
示される。指名可能性に対するモニタ活動化の効果は、
そのモニタを含むプロセス内のすべてのスレッドが指名
可能なままとなることを意味する"ｖｍ＿ｅｖｎ＿ａｓ
ｙｎｃ＿ｍｏｎｉｔｏｒ"（省略時指定）、またはその
上でモニタが活動化されているスレッド（すなわち、こ
のイベント・モニタ用のイベント・ハンドラ）を除き、
現在そのモニタを含むプロセス内にあるすべてのスレッ
ドが、モニタが非活動化されるまで中断されることを意
味する"ｖｍ＿ｅｖｎ＿ｓｙｎｃ＿ｐｒｏｃｅｓｓ＿ｍ
ｏｎｉｔｏｒ"によって指示される。ルース信号のこの
モニタへの結合は、モニタが作成されたときまたはＥｖ
ｅｎｔＳｅｌｅｃｔもしくはＥｖｅｎｔＭｏｎｉｔｏｒ
Ｓｅｌｅｃｔによって監視が再開されたときにこのモニ
タがそれに対して適格な任意のルース信号がこのモニタ
に結合されることを意味する"ｖｍ＿ｅｖｎ＿ｂｉｎｄ
＿ｌｏｏｓｅ＿ｓｉｇｎａｌｓ"（省略時指定）、また
はいかなるルース信号もこのモニタに結合されていない
ことを意味する"ｖｍ＿ｅｖｎ＿ｉｇｎｏｒｅ＿ｌｏｏ
ｓｅ＿ｓｉｇｎａｌｓ"によって指示される。

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

【０１０９】"ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ"は、
関心があるｅｖｅｎｔ＿ｎａｍｅとｅｖｅｎｔ＿ｋｅｙ
の対の数を含む符号付きの４バイト２進変数である。

【０１１０】"ｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓ"
は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の４バイト・
ポインタ変数のアレイであり、その各要素は、その発生
が監視されるイベントの名前のアドレスを含む。

【０１１１】"ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ"
は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符号付き４
バイト２進変数のアレイであり、その各要素は、ｅｖｅ
ｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓアレイの対応する要素
が指すｅｖｅｎｔ＿ｎａｍｅの長さを含む。

【０１１２】"ｅｖｅｎｔ＿ｋｅｙ＿ａｄｄｒｅｓｓ"
は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の４バイト・
ポインタ変数のアレイであり、その各要素は、監視され
るｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓアレイの対応
するエントリが指すｅｖｅｎｔ＿ｎａｍｅの特定のイン
スタンスをさらに特徴づけるキーのアドレスを含む。こ
のキーは、関心がある信号によって搬送されるキーとぴ
ったり一致するように選択することができ、または部分
キー（おそらくワイルドカード文字を含む）をより広い
範囲の発生に合致するように使用することができる。

【０１１３】"ｅｖｅｎｔ＿ｋｅｙ＿ｌｅｎｇｔｈ"は、
ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符号付き４バイ
ト２進変数のアレイであり、その各要素は、ｅｖｅｎｔ
＿ｋｅｙ＿ａｄｄｒｅｓｓアレイの対応する要素が指す
ｅｖｅｎｔ＿ｋｅｙの長さを含む。このキーは、関心が
ある発生を定義するためにイベントの２次的特徴付けが
必要でない場合は、空でよい（すなわち、その長さは０
でよい）。モニタ内の空白キーは信号上の任意のキーに
合致する。

【０１１４】"ｂｏｕｎｄ＿ｓｉｇｎａｌ＿ｌｉｍｉｔ"
は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符号付き４
バイト２進変数のアレイであり、その各要素は、モニタ
がすでに活動状態またはテスト可能である間、または監
視された条件が満足されないままである間、イベント・
モニタに結合されているが未処理の状態に保持できる、
対応するイベント名／イベント・キー対の信号の数を含
む。限界を超えたとき、特定のｅｖｅｎｔ＿ｎａｍｅ／
ｅｖｅｎｔ＿ｋｅｙ対の最も古い結合信号が新しく到着
した信号用の場所をあけるために放棄される。許される
最小値は１であり、これは各信号の最近のインスタンス
だけが保持されることを意味する。値−１は、仮想記憶
域が利用できるという条件の下で結合信号リストが無制
限に成長できることを意味する。その他の負の値または
０は、エラーと見なされる。

【０１１５】"ｅｖｅｎｔ＿ｃｏｕｎｔ"は、監視された
条件が満足されたと見なされるために信号がモニタに結
合されなければならない、指定されたｅｖｅｎｔ＿ｎａ
ｍｅとｅｖｅｎｔ＿ｋｅｙの対の数を含む符号付き４バ
イト２進変数である。この値は１とｎｕｍｂｅｒ＿ｏｆ
＿ｅｖｅｎｔｓの間でなければならない。あるいは、本
発明の別の実施例では、ｅｖｅｎｔ＿ｃｏｕｎｔは、イ
ベント・モニタを満足させるために必要な各イベント・
タイプの発生回数を示すために、各イベント・タイプご
とに指定される。

【０１１６】 ＥｖｅｎｔＭｏｎｉｔｏｒＤｅｌｅｔｅ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ パラメータ： "ＥｖｅｎｔＭｏｎｉｔｏｒＤｅｌｅｔｅ"は、呼び出さ
れる機能の名前である。

【０１１７】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉ
ｔｏｒＤｅｌｅｔｅからの戻りコードを保持するための
符号付き４バイト２進変数である。

【０１１８】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉ
ｔｏｒＤｅｌｅｔｅからの理由コードを保持するための
符号付き４バイト２進変数である。

【０１１９】"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ"は、削除さ
れるイベント・モニタを識別するトークンを含む符号付
きの４バイト２進変数である。値０は、現スレッド上で
最近に活動化された活動状態のイベント・モニタを識別
するために使用される。

【０１２０】 ＥｖｅｎｔＭｏｎｉｔｏｒＥｎａｂｌｅ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｎｕｍｂｅｒ＿ｏｆ＿ｍｏｎｉｔｏｒｓ ｍｏｎｉｔｏｒ＿ｔｏｋｅｎｓ ｍｏｎｉｔｏｒ＿ｅｎａｂｌｅｍｅｎｔ＿ｍａｓｋｓ パラメータ： "ＥｖｅｎｔＭｏｎｉｔｏｒＥｎａｂｌｅ"は、呼び出さ
れる機能の名前である。

【０１２１】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉ
ｔｏｒＥｎａｂｌｅからの戻りコードを保持するための
符号付き４バイト２進変数である。

【０１２２】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉ
ｔｏｒＥｎａｂｌｅからの理由コードを保持するための
符号付き４バイト２進変数である。

【０１２３】"ｎｕｍｂｅｒ＿ｏｆ＿ｍｏｎｉｔｏｒｓ"
は、関心があるｍｏｎｉｔｏｒ＿ｔｏｋｅｎｓの数を含
む符号付き４バイト２進変数である。

【０１２４】"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎｓ"は、ｎｕ
ｍｂｅｒ＿ｏｆ＿ｍｏｎｉｔｏｒｓ個の４バイト・ポイ
ンタ変数のアレイであり、その各要素は、イネーブルま
たはディスエーブルされるモニタのトークンを含む。値
０は、現スレッド上で最近に活動化された活動状態のイ
ベント・モニタを識別するために使用される。

【０１２５】"ｍｏｎｉｔｏｒ＿ｅｎａｂｌｅｍｅｎｔ
＿ｍａｓｋｓ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｍｏｎｉｔｏ
ｒｓ個の符号付き４バイト２進変数のアレイであり、そ
の各要素は、ｍｏｎｉｔｏｒ＿ｔｏｋｅｎｓアレイの対
応する要素によって識別されるモニタ用のイネーブル・
マスクを含む。モニタ・イネーブル・マスクの値が、実
行される以下の処置を決定する。すなわち、ｍｏｎｉｔ
ｏｒ＿ｔｏｋｅｎｓアレイの対応する要素によって識別
されるモニタをディスエーブルすることを示す"ｖｍ＿
ｅｖｎ＿ｄｉｓａｂｌｅ"、及びｍｏｎｉｔｏｒ＿ｔｏ
ｋｅｎｓアレイの対応する要素によって識別されるモニ
タをイネーブルすることを示す"ｖｍ＿ｅｖｎ＿ｅｎａ
ｂｌｅ"である。

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

【０１２７】 ＥｖｅｎｔＭｏｎｉｔｏｒＱｕｅｒｙ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ ｍｏｎｉｔｏｒ＿ｆｌａｇ ｍｏｎｉｔｏｒ＿ｆｌａｇ＿ｓｉｚｅ ｍｏｎｉｔｏｒ＿ｆｌａｇ＿ｃｏｕｎｔ ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ ｅｖｅｎｔ＿ｎａｍｅ＿ｂｕｆｆｅｒ＿ａｄｄｒｅｓｓ ｅｖｅｎｔ＿ｎａｍｅ＿ｂｕｆｆｅｒ＿ｌｅｎｇｔｈ ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ ｅｖｅｎｔ＿ｋｅｙ＿ｂｕｆｆｅｒ＿ａｄｄｒｅｓｓ ｅｖｅｎｔ＿ｋｅｙ＿ｂｕｆｆｅｒ＿ｌｅｎｇｔｈ ｅｖｅｎｔ＿ｋｅｙ＿ｌｅｎｇｔｈ ｂｏｕｎｄ＿ｓｉｇｎａｌ＿ｌｉｍｉｔ ｂｏｕｎｄ＿ｓｉｇｎａｌ＿ｃｏｕｎｔ ｍｏｎｉｔｏｒ＿ｓｅｌｅｃｔｉｏｎ＿ｍａｓｋ ｍｏｎｉｔｏｒ＿ｅｎａｂｌｅｍｅｎｔ＿ｍａｓｋ ｅｖｅｎｔ＿ｃｏｕｎｔ ｐｒｅｓｅｎｔ＿ｅｖｅｎｔ＿ｃｏｕｎｔ ｔｒａｐ＿ｒｏｕｔｉｎｅ＿ａｄｄｒｅｓｓ ｔｒａｐ＿ｒｏｕｔｉｎｅ＿ｎａｍｅ パラメータ： "ＥｖｅｎｔＭｏｎｉｔｏｒＱｕｅｒｙ"は、呼び出され
る機能の名前である。

【０１２８】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉ
ｔｏｒＱｕｅｒｙからの戻りコードを保持するための符
号付き４バイト２進変数である。

【０１２９】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉ
ｔｏｒＱｕｅｒｙからの理由コードを保持するための符
号付き４バイト２進変数である。

【０１３０】"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ"は、それに
関する情報が返されるイベント・モニタを識別する符号
付きの４バイト２進変数である。値０は、現スレッド上
で最近に活動化された活動状態のイベント・モニタを識
別するために使用される。

【０１３１】"ｍｏｎｉｔｏｒ＿ｆｌａｇ"は、符号付き
の４バイト２進変数のアレイであり、その各要素中で、
イベント・モニタをどのように管理すべきかの情報が返
される。以下の各セットからそれぞれただ１つのオプシ
ョンを含む。

【０１３２】モニタの寿命は、イベント・モニタが明示
的ＥｖｅｎｔＭｏｎｉｔｏｒＤｅｌｅｔｅまで、または
定義プロセスの終了まで持続することを意味する"ｖｍ
＿ｅｖｎ＿ｎｏ＿ａｕｔｏ＿ｄｅｌｅｔｅ"、またはイ
ベント・モニタが最初に非活動化されたときまたはＥｖ
ｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ呼出し時に自動的に削
除されることを意味する"ｖｍ＿ｅｖｎ＿ａｕｔｏ＿ｄ
ｅｌｅｔｅ"によって指示される。

【０１３３】指名可能性に関するモニタ活動化の効果
は、モニタを含むプロセス内のすべてのスレッドが指名
可能なままとなることを意味する"ｖｍ＿ｅｖｎ＿ａｓ
ｙｎｃ＿ｍｏｎｉｔｏｒ"（省略時指定）、またはモニ
タがその上で活動化されているスレッド（すなわち、こ
のイベント・モニタ用のイベント・ハンドラ）を除き、
現在モニタを含むプロセス内にあるすべてのスレッド
が、そのモニタが非活動化されるまで中断されることを
意味する"ｖｍ＿ｅｖｎ＿ｓｙｎｃ＿ｐｒｏｃｅｓｓ＿
ｍｏｎｉｔｏｒ"によって指示される。

【０１３４】ルース信号のこのモニタへの結合は、モニ
タが作成されたまたはオンに選択された時点で存在する
任意の適格ルース信号がこのモニタに結合されているこ
とを意味する"ｖｍ＿ｅｖｎ＿ｂｉｎｄ＿ｌｏｏｓｅ＿
ｓｉｇｎａｌｓ"（省略時指定）、またはいかなるルー
ス信号もこのモニタに結合されていないことを意味す
る"ｖｍ＿ｅｖｎ＿ｉｇｎｏｒｅ＿ｌｏｏｓｅ＿ｓｉｇ
ｎａｌｓ"によって指示される。

【０１３５】モニタの現在の活動化状態は、監視される
条件が満たされており、信号処理プログラムが実行中で
あることを意味する"ｖｍ＿ｅｖｎ＿ｍｏｎｉｔｏｒ＿
ａｃｔｉｖｅ"、モニタが活動状態でなく、監視される
条件が満たされておらず、モニタに関連する未処理のＥ
ｖｅｎｔＷａｉｔがあることを意味する"ｖｍ＿ｅｖｎ
＿ｍｏｎｉｔｏｒ＿ｗａｉｔｉｎｇ"、モニタが活動状
態でも待機状態でもなく、監視される条件が満たされて
おらず、モニタに関連するトラップ・ルーチンがあるこ
とを意味する"ｖｍ＿ｅｖｎ＿ｍｏｎｉｔｏｒ＿ｔｒａ
ｐｐｉｎｇ"、またはモニタが活動状態でも待機状態で
もトラッピング状態でもなく、監視される条件は満たさ
れていることも満たされていないこともあり、モニタに
関連する未処理のＥｖｅｎｔＷａｉｔもトラップ・ルー
チンもないことを意味する"ｖｍ＿ｅｖｎ＿ｍｏｎｉｔ
ｏｒ＿ｔｅｓｔａｂｌｅ"によって指示される。

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

【０１３７】"ｍｏｎｉｔｏｒ＿ｆｌａｇ＿ｃｏｕｎｔ"
は、ＥｖｅｎｔＭｏｎｉｔｏｒＱｕｅｒｙによってセッ
トされたｍｏｎｉｔｏｒ＿ｆｌａｇアレイ内の要素の数
がその中で返される、符号付きの４バイト２進変数であ
る。

【０１３８】"ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ"は、
関心があるｅｖｅｎｔ＿ｎａｍｅとｅｖｅｎｔ＿ｋｅｙ
の対の数を含む、符号付きの４バイト２進変数である。

【０１３９】"ｅｖｅｎｔ＿ｎａｍｅ＿ｂｕｆｆｅｒ＿
ａｄｄｒｅｓｓ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔ
ｓ個の４バイト・ポインタ変数のアレイであり、その各
要素は、その発生が監視されるイベントの名前がその中
で返される、文字変数のアドレスを含む。

【０１４０】"ｅｖｅｎｔ＿ｎａｍｅ＿ｂｕｆｆｅｒ＿
ｌｅｎｇｔｈ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ
個の符号付き４バイト２進変数のアレイであり、その各
要素は、ｅｖｅｎｔ＿ｎａｍｅ＿ｂｕｆｆｅｒ＿ａｄｄ
ｒｅｓｓアレイの対応する要素が指すｅｖｅｎｔ＿ｎａ
ｍｅ＿ｂｕｆｆｅｒの長さを含む。

【０１４１】"ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ"
は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符号付き４
バイト２進変数のアレイであり、その各要素中で、ｅｖ
ｅｎｔ＿ｎａｍｅ＿ｂｕｆｆｅｒ＿ａｄｄｒｅｓｓアレ
イの対応する要素が指すバッファに記憶されているｅｖ
ｅｎｔ＿ｎａｍｅの実際の長さが返される。この名前が
バッファより長い場合、それは切り捨てられる。短い場
合は、バッファの終りにある過剰スペースは変化しな
い。

【０１４２】"ｅｖｅｎｔ＿ｋｅｙ＿ｂｕｆｆｅｒ＿ａ
ｄｄｒｅｓｓ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ
個の４バイト・ポインタ変数のアレイであり、その各要
素は、監視されているｅｖｅｎｔ＿ｎａｍｅ＿ｂｕｆｆ
ｅｒ＿ａｒｒａｙの対応するエントリが指すｅｖｅｎｔ
＿ｎａｍｅの特定のインスタンスをさらに特徴づけるキ
ーがその中で返される、バッファのアドレスを含む。

【０１４３】"ｅｖｅｎｔ＿ｋｅｙ＿ｂｕｆｆｅｒ＿ｌ
ｅｎｇｔｈ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個
の符号付き４バイト２進変数のアレイであり、その各要
素は、ｅｖｅｎｔ＿ｋｅｙ＿ｂｕｆｆｅｒ＿ａｄｄｒｅ
ｓｓアレイの対応する要素が指すバッファの長さを含
む。

【０１４４】"ｅｖｅｎｔ＿ｋｅｙ＿ｌｅｎｇｔｈ"は、
ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符号付き４バイ
ト２進変数のアレイであり、その各要素中で、ｅｖｅｎ
ｔ＿ｋｅｙ＿ｂｕｆｆｅｒ＿ａｄｄｒｅｓｓアレイの対
応する要素が指すバッファに記憶されているｅｖｅｎｔ
＿ｋｅｙの実際の長さが返される。このキーがバッファ
より長い場合、それは切り捨てられる。短い場合は、バ
ッファの終りにある過剰スペースは変化しない。

【０１４５】"ｂｏｕｎｄ＿ｓｉｇｎａｌ＿ｌｉｍｉｔ"
は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符号付き４
バイト２進変数のアレイであり、その各要素中で、モニ
タがすでに活動状態またはテスト可能である期間、また
は監視される条件が満足されないままである間、イベン
ト・モニタに結合されているが未処理の状態に保持され
る対応するイベント名／イベント・キー対の信号の数が
返される。限界を超えたとき、特定のｅｖｅｎｔ＿ｎａ
ｍｅとｅｖｅｎｔ＿ｋｅｙの対の最も古い結合信号が新
しく到着した信号用の場所をあけるために放棄される。
許容される最小値は１であり、これは各信号の最近のイ
ンスタンスだけが保持されることを意味する。値−１
は、仮想記憶域が利用できるという条件の下で結合信号
リストが無制限に成長できることを意味する。

【０１４６】"ｂｏｕｎｄ＿ｓｉｇｎａｌ＿ｃｏｕｎｔ"
は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符号付き４
バイト２進変数のアレイであり、その各要素中で、イベ
ント・モニタに現在結合されているが未処理である対応
するイベント名／イベント・キー対の信号の数が返され
る。

【０１４７】"ｍｏｎｉｔｏｒ＿ｓｅｌｅｃｔｉｏｎ＿
ｍａｓｋ"は、このモニタ用の選択マスクがその中で返
される、４バイト変数である。この変数は、このモニタ
がオフに選択されるかオンに選択されるかを示す。

【０１４８】"ｍｏｎｉｔｏｒ＿ｅｎａｂｌｅｍｅｎｔ
＿ｍａｓｋ"は、このモニタ用のイネーブル・マスクが
その中で返される、４バイト２進変数である。この変数
は、このモニタがディスエーブルされるかイネーブルさ
れるかを示す。

【０１４９】"ｅｖｅｎｔ＿ｃｏｕｎｔ"は、監視される
条件が満足されたと見なすためにそれに対する信号がモ
ニタに結合されなければならない、指定されたｅｖｅｎ
ｔ＿ｎａｍｅとｅｖｅｎｔ＿ｋｅｙの対の数がその中で
返される、符号付き４バイト２進変数である。

【０１５０】"ｐｒｅｓｅｎｔ＿ｅｖｅｎｔ＿ｃｏｕｎ
ｔ"は、それに対する信号がイベント・モニタに現在結
合されている、指定されたｅｖｅｎｔ＿ｎａｍｅとｅｖ
ｅｎｔ＿ｋｅｙの対の数がその中で返される、符号付き
４バイト２進変数である。

【０１５１】"ｔｒａｐ＿ｒｏｕｔｉｎｅ＿ａｄｄｒｅ
ｓｓ"は、モニタによって定義された条件が満たされる
ことが、ＥｖｅｎｔＴｒａｐ機能によって確立されたと
きに呼び込まれるルーチンのアドレスがその中で返され
る、４バイト２進変数である。ＥｖｅｎｔＴｒａｐによ
ってアドレスが確立されていない場合は、値０が返され
る。

【０１５２】"ｔｒａｐ＿ｒｏｕｔｉｎｅ＿ｎａｍｅ"
は、モニタによって定義された条件が満たされることが
ＥｖｅｎｔＴｒａｐ機能によって確立されたときに、呼
び込まれるルーチンの名前がその中で返される８バイト
変数であり、またどのイベント・トラップもモニタと関
連していない場合はブランクが返される。

【０１５３】 ＥｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ パラメータ： "ＥｖｅｎｔＭｏｎｉｔｏｒＲｅｓｅｔ"は、呼び込まれ
る機能の名前である。

【０１５４】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉ
ｔｏｒＲｅｓｅｔからの戻りコードを保持するための符
号付き４バイト２進変数である。

【０１５５】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉ
ｔｏｒＲｅｓｅｔからの理由コードを保持するための符
号付き４バイト２進変数である。

【０１５６】"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ"は、その状
態がリセットされるモニタを識別するトークンを含む、
符号付きの４バイト２進変数である。値０は、現スレッ
ド上で最近に活動化された活動状態のイベント・モニタ
を識別するために使用される。

【０１５７】 ＥｖｅｎｔＭｏｎｉｔｏｒＳｅｌｅｃｔ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｎｕｍｂｅｒ＿ｏｆ＿ｍｏｎｉｔｏｒｓ ｍｏｎｉｔｏｒ＿ｔｏｋｅｎｓ ｍｏｎｉｔｏｒ＿ｓｅｌｅｃｔｉｏｎ＿ｍａｓｋｓ パラメータ： "ＥｖｅｎｔＭｏｎｉｔｏｒＳｅｌｅｃｔ"は、呼び込ま
れる機能の名前である。

【０１５８】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉ
ｔｏｒＳｅｌｅｃｔからの戻りコードを保持するための
符号付き４バイト２進変数である。

【０１５９】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＭｏｎｉ
ｔｏｒＳｅｌｅｃｔからの理由コードを保持するための
符号付き４バイト２進変数である。

【０１６０】"ｎｕｍｂｅｒ＿ｏｆ＿ｍｏｎｉｔｏｒｓ"
は、関心があるｍｏｎｉｔｏｒ＿ｔｏｋｅｎｓの数を含
む、符号付き４バイト２進変数である。

【０１６１】"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎｓ"は、ｎｕ
ｍｂｅｒ＿ｏｆ＿ｍｏｎｉｔｏｒｓ個の４バイト２進変
数のアレイであり、その各要素は、オンまたはオフに選
択されるモニタのトークンを含む。値０は、現スレッド
上で最近に活動化された活動状態のイベント・モニタを
識別するために使用される。

【０１６２】"ｍｏｎｉｔｏｒ＿ｓｅｌｅｃｔｉｏｎ＿
ｍａｓｋｓ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｍｏｎｉｔｏｒ
ｓ個の符号付き４バイト２進変数のアレイであり、その
各要素は、ｍｏｎｉｔｏｒ＿ｔｏｋｅｎｓアレイの対応
する要素によって識別されるモニタ用の選択マスクを含
む。選択マスクの値が、実行される処置、すなわち、ｍ
ｏｎｉｔｏｒ＿ｔｏｋｅｎｓアレイの対応する要素によ
って識別されるモニタの監視の停止を意味する"ｖｍ＿
ｅｖｎ＿ｓｅｌｅｃｔ＿ｏｆｆ"、及びｍｏｎｉｔｏｒ
＿ｔｏｋｅｎｓアレイの対応する要素によって識別され
るモニタの監視の開始を意味する"ｖｍ＿ｅｖｎ＿ｓｅ
ｌｅｃｔ＿ｏｎ"を決定する。

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

【０１６４】 ＥｖｅｎｔＱｕｅｒｙ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｅｖｅｎｔ＿ｎａｍｅ ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ ｅｖｅｎｔ＿ｆｌａｇ ｅｖｅｎｔ＿ｆｌａｇ＿ｓｉｚｅ ｅｖｅｎｔ＿ｆｌａｇ＿ｃｏｕｎｔ ｌｏｏｓｅ＿ｓｉｇｎａｌ＿ｌｉｍｉｔ ｓｉｇｎａｌ＿ｔｉｍｅｏｕｔ＿ｐｅｒｉｏｄ ｌｏｏｓｅ＿ｓｉｇｎａｌ＿ｃｏｕｎｔ ｅｖｅｎｔ＿ｓｅｌｅｃｔｉｏｎ＿ｍａｓｋ ｅｖｅｎｔ＿ｅｎａｂｌｅｍｅｎｔ＿ｍａｓｋ ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｓｉｚｅ ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｃｏｕｎｔ パラメータ： "ＥｖｅｎｔＱｕｅｒｙ"は、呼び込まれる機能の名前で
ある。

【０１６５】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＱｕｅｒ
ｙからの戻りコードを保持するための符号付き４バイト
２進変数である。

【０１６６】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＱｕｅｒ
ｙからの理由コードを保持するための符号付き４バイト
２進変数である。

【０１６７】"ｅｖｅｎｔ＿ｎａｍｅ"は、照会されるイ
ベントの名前を含む文字変数である。

【０１６８】"ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ"
は、ｅｖｅｎｔ＿ｎａｍｅの長さを含む符号付き４バイ
ト２進変数である。

【０１６９】"ｅｖｅｎｔ＿ｆｌａｇ"は、イベントがど
のように管理されるかに関する情報がその中で返され
る、符号付きの４バイト２進変数のアレイである。以下
の各セットからのそれぞれただ１つのオプションが含ま
れる。

【０１７０】イベント名の範囲は、指定されたプロセス
を意味する"ｖｍ＿ｅｖｎ＿ｐｒｏｃｅｓｓ＿ｓｃｏｐ
ｅ"、または指定されたセッションを意味する"ｖｍ＿ｅ
ｖｎ＿ｓｅｓｓｉｏｎ＿ｓｃｏｐｅ"によって指示され
る。

【０１７１】イベント信号が複数のイベント・モニタに
伝搬される方式は、同報通信を意味する"ｖｍ＿ｅｖｎ
＿ｂｒｏａｄｃａｓｔ＿ｓｉｇｎａｌｓ"、ＦＩＦＯシ
ーケンスを意味する"ｖｍ＿ｅｖｎ＿ｆｉｆｏ＿ｓｉｇ
ｎａｌｓ"、またはＬＩＦＯシーケンスを意味する"ｖｍ
＿ｅｖｎ＿ｌｉｆｏ＿ｓｉｇｎａｌｓ"によって指示さ
れる。

【０１７２】シグナラの処理は、信号通知スレッドが実
行を継続できることを意味する"ｖｍ＿ｅｖｎ＿ａｓｙ
ｎｃ＿ｓｉｇｎａｌｓ"（省略時指定）、信号通知スレ
ッドがイベント処理の結果を待って中断されていること
を意味する"ｖｍ＿ｅｖｎ＿ｓｙｎｃ＿ｔｈｒｅａｄ＿
ｓｉｇｎａｌｓ"、またはモニタが信号によって活動化
された結果として走行しているスレッドを除く、信号通
知プロセスにおけるすべてのスレッドが、イベント処理
の結果を待って中断されていることを意味する"ｖｍ＿
ｅｖｎ＿ｓｙｎｃ＿ｐｒｏｃｅｓｓ＿ｓｉｇｎａｌｓ"
によって指示される。

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

【０１７４】"ｅｖｅｎｔ＿ｆｌａｇ＿ｃｏｕｎｔ"は、
ＥｖｅｎｔＱｕｅｒｙによってセットされたｅｖｅｎｔ
＿ｆｌａｇアレイ内の要素の数がその中で返される、符
号付き４バイト２進変数である。

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

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

【０１７７】"ｌｏｏｓｅ＿ｓｉｇｎａｌ＿ｃｏｕｎｔ"
は、特定のイベントに関して現在保持されているルース
信号の数がその中で返される、符号付き４バイト２進変
数である。

【０１７８】"ｅｖｅｎｔ＿ｓｅｌｅｃｔｉｏｎ＿ｍａ
ｓｋ"は、イベント選択マスクの状態、すなわちｅｖｅ
ｎｔ＿ｎａｍｅについて監視しないことを意味する"ｖ
ｍ＿ｅｖｎ＿ｓｅｌｅｃｔ＿ｏｆｆ"、またはｅｖｅｎ
ｔ＿ｎａｍｅについて監視することを意味する"ｖｍ＿
ｅｖｎ＿ｓｅｌｅｃｔ＿ｏｎ"がその中で返される、符
号付き４バイト２進変数である。

【０１７９】"ｅｖｅｎｔ＿ｅｎａｂｌｅｍｅｎｔ＿ｍ
ａｓｋ"は、イベント・イネーブル・マスクの状態、す
なわちｅｖｅｎｔ＿ｎａｍｅについてディスエーブルさ
れたことを意味する"ｖｍ＿ｅｖｎ＿ｄｉｓａｂｌｅ"、
またはｅｖｅｎｔ＿ｎａｍｅについてイネーブルされた
ことを意味する"ｖｍ＿ｅｖｎ＿ｅｎａｂｌｅ"がその中
で返される、４バイト２進変数である。イベント選択マ
スク及びイネーブル・マスクは、プロセスごとに維持さ
れ、発行プロセスについてだけ報告される。

【０１８０】"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ"は、指定さ
れたイベントの影響を受ける可能性のある、現プロセス
において定義されたイベント・モニタを識別するトーク
ンのリストがその中で返される、符号付きの４バイト２
進変数のアレイである。順次式と定義されたイベントで
は、トークンはイベントが処理される順序で出力され
る。同報通信と定義されたイベントでは、トークンはモ
ニタが作成された順序で出力される。

【０１８１】"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｓｉｚｅ"
は、充填に使用できるｍｏｎｉｔｏｒ＿ｔｏｋｅｎアレ
イ内の要素の数を含む、符号付きの４バイト２進変数で
ある。

【０１８２】"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｃｏｕｎ
ｔ"は、指定されたイベントの影響を受ける可能性のあ
る、現プロセスにおいて定義されたイベント・モニタの
総数がその中で返される、符号付きの４バイト２進変数
である。ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｃｏｕｎｔがｍ
ｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｓｉｚｅより大きくない場
合、ｍｏｎｉｔｏｒ＿ｔｏｋｅｎアレイの第１のｍｏｎ
ｉｔｏｒ＿ｔｏｋｅｎ＿ｃｏｕｎｔ要素は、モニタ・セ
ット全体を識別するトークンを含み、アレイの残りの要
素は不変である。そうでない場合は、第１ｍｏｎｉｔｏ
ｒ＿ｔｏｋｅｎ＿ｓｉｚｅ個のモニタ・トークンが返さ
れる。

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

【０１８４】 ＥｖｅｎｔＱｕｅｒｙＡｌｌ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ ｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓ ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ ａｃｔｕａｌ＿ｎａｍｅ＿ｌｅｎｇｔｈ ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｓｉｚｅ ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｃｏｕｎｔ パラメータ： "ＥｖｅｎｔＱｕｅｒｙＡｌｌ"は、呼び込まれる機能の
名前である。

【０１８５】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＱｕｅｒ
ｙＡｌｌからの戻りコードを保持するための符号付き４
バイト２進変数である。

【０１８６】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＱｕｅｒ
ｙＡｌｌからの理由コードを保持するための符号付き４
バイト２進変数である。

【０１８７】"ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ"は、
以下の３つのアレイ内の要素の数を含む符号付きの４バ
イト２進変数である。

【０１８８】"ｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓ"
は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の４バイト・
ポインタ変数のアレイであり、その各要素は、定義され
たイベントの名前がその中で返される文字変数のアドレ
スを含む。

【０１８９】"ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ"
は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符号付き４
バイト２進変数のアレイであり、その各要素は、ｅｖｅ
ｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓアレイの対応する要素
のバッファの長さを含む。この名前がバッファより長い
場合、それは切り捨てられる。短い場合は、バッファの
終りにある過剰スペースは不変である。

【０１９０】"ａｃｔｕａｌ＿ｎａｍｅ＿ｌｅｎｇｔｈ"
は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符号付き４
バイト２進変数のアレイである。この機能は、このアレ
イを使用してｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓア
レイの対応する要素が指すイベント名の長さを出力す
る。

【０１９１】"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ"は、現プロ
セスにおいて定義されたすべてのイベント・モニタを識
別するトークンのリストがその中で返される、符号付き
の４バイト２進変数のアレイである。

【０１９２】"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｓｉｚｅ"
は、充填に使用できるｍｏｎｉｔｏｒ＿ｔｏｋｅｎアレ
イ内の要素の数を含む、符号付きの４バイト２進変数で
ある。

【０１９３】"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｃｏｕｎ
ｔ"は、現プロセスにおいて定義されたイベント・モニ
タの総数がその中で返される、符号付きの４バイト２進
変数である。ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｃｏｕｎｔ
がｍｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｓｉｚｅより大きくな
い場合、ｍｏｎｉｔｏｒ＿ｔｏｋｅｎアレイの第１のｍ
ｏｎｉｔｏｒ＿ｔｏｋｅｎ＿ｃｏｕｎｔ要素は、モニタ
・セット全体を識別するトークンを含み、アレイの残り
の要素は不変である。そうでない場合は、第１ｍｏｎｉ
ｔｏｒ＿ｔｏｋｅｎ＿ｓｉｚｅ個のモニタ・トークンだ
けが返される。

【０１９４】 ＥｖｅｎｔＲｅｔｒｉｅｖｅ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ ｉｎｄｅｘ ｄａｔａ＿ｂｕｆｆｅｒ ｄａｔａ＿ｂｕｆｆｅｒ＿ｌｅｎｇｔｈ ｅｖｅｎｔ＿ｄａｔａ＿ｌｅｎｇｔｈ パラメータ： "ＥｖｅｎｔＲｅｔｒｉｅｖｅ"は、呼び込まれる機能の
名前である。

【０１９５】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＲｅｔｒ
ｉｅｖｅからの戻りコードを保持するための符号付き４
バイト２進変数である。

【０１９６】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＲｅｔｒ
ｉｅｖｅからの理由コードを保持するための符号付き４
バイト２進変数である。

【０１９７】"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ"は、その現
信号セットから取出しが実行されるモニタを識別するト
ークンを含む、符号付きの４バイト２進変数のアレイで
ある。値０は、現スレッド上で最近に活動化された活動
状態のイベント・モニタを識別するために使用される。

【０１９８】"ｉｎｄｅｘ"は、イベント・モニタの作成
時に指定されたｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓ
ｓ、ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ、ｅｖｅｎｔ
＿ｋｅｙ＿ａｄｄｒｅｓｓ及びｅｖｅｎｔ＿ｋｅｙ＿ｌ
ｅｎｇｔｈアレイへのインデックスとして、データがそ
こから取り出される信号に対応するｅｖｅｎｔ＿ｎａｍ
ｅとｅｖｅｎｔ＿ｋｅｙの対を識別する、符号付きの４
バイト２進変数である。

【０１９９】"ｄａｔａ＿ｂｕｆｆｅｒ"は、インデック
スによって識別されたｅｖｅｎｔ＿ｎａｍｅとｅｖｅｎ
ｔ＿ｋｅｙの対に関する信号で通知されたデータがその
中で返される文字変数である。

【０２００】"ｄａｔａ＿ｂｕｆｆｅｒ＿ｌｅｎｇｔｈ"
は、ｄａｔａ＿ｂｕｆｆｅｒの定義された長さを含む符
号付きの４バイト２進変数である。

【０２０１】"ｅｖｅｎｔ＿ｄａｔａ＿ｌｅｎｇｔｈ"
は、インデックスによって識別されたｅｖｅｎｔ＿ｎａ
ｍｅとｅｖｅｎｔ＿ｋｅｙの対に関する信号で通知され
たデータの長さがその中で返される、符号付きの４バイ
ト２進変数である。ｅｖｅｎｔ＿ｄａｔａ＿ｌｅｎｇｔ
ｈがｄａｔａ＿ｂｕｆｆｅｒ＿ｌｅｎｇｔｈより大きい
場合、信号で通知されたデータは右側が切り捨てられ、
警告戻りコードが生成される。

【０２０２】 ＥｖｅｎｔＳｅｌｅｃｔ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ ｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓ ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ ｅｖｅｎｔ＿ｓｅｌｅｃｔｉｏｎ＿ｍａｓｋ パラメータ： "ＥｖｅｎｔＳｅｌｅｃｔ"は、呼び込まれる機能の名前
である。

【０２０３】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＳｅｌｅ
ｃｔからの戻りコードを保持するための符号付き４バイ
ト２進変数である。

【０２０４】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＳｅｌｅ
ｃｔからの理由コードを保持するための符号付き４バイ
ト２進変数である。

【０２０５】"ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ"は、
関心があるイベントの数を含む符号付き４バイト２進変
数である。

【０２０６】"ｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓ"
は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の４バイト・
ポインタ変数のアレイであり、その各要素は、その信号
がオンまたはオフに選択されるイベントの名前のアドレ
スを含む。

【０２０７】"ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ"
は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符号付き４
バイト２進変数のアレイであり、その各要素は、ｅｖｅ
ｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓアレイの対応する要素
が指すｅｖｅｎｔ＿ｎａｍｅの長さを含む。

【０２０８】"ｅｖｅｎｔ＿ｓｅｌｅｃｔｉｏｎ＿ｍａ
ｓｋ"は、ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ個の符号
付き４バイト２進変数のアレイであり、その各要素は、
ｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓアレイの対応す
る要素が指すｅｖｅｎｔ＿ｎａｍｅの選択マスクを含
む。選択マスクの値が、実行される処置、すなわちｅｖ
ｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓアレイの対応する要
素が指すｅｖｅｎｔ＿ｎａｍｅの監視を停止することを
意味する"ｖｍ＿ｅｖｎ＿ｓｅｌｅｃｔ＿ｏｆｆ"、また
はｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒｅｓｓアレイの対応
する要素が指すｅｖｅｎｔ＿ｎａｍｅの監視を開始する
ことを意味する"ｖｍ＿ｅｖｎ＿ｓｅｌｅｃｔ＿ｏｎ"を
決定する。

【０２０９】 ＥｖｅｎｔＳｉｇｎａｌ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｅｖｅｎｔ＿ｎａｍｅ ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ ｅｖｅｎｔ＿ｄａｔａ ｅｖｅｎｔ＿ｄａｔａ＿ｌｅｎｇｔｈ ｅｖｅｎｔ＿ｋｅｙ＿ｏｆｆｓｅｔ ｅｖｅｎｔ＿ｋｅｙ＿ｌｅｎｇｔｈ パラメータ： "ＥｖｅｎｔＳｉｇｎａｌ"は、呼び込まれる機能の名前
である。

【０２１０】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＳｉｇｎ
ａｌからの戻りコードを保持するための符号付き４バイ
ト２進変数である。

【０２１１】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＳｉｇｎ
ａｌからの理由コードを保持するための符号付き４バイ
ト２進変数である。

【０２１２】"ｅｖｅｎｔ＿ｎａｍｅ"は、その発生が信
号で通知されるイベントの名前を含む文字変数である。

【０２１３】"ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ"
は、ｅｖｅｎｔ＿ｎａｍｅの長さを含む符号付き４バイ
ト２進変数である。

【０２１４】"ｅｖｅｎｔ＿ｄａｔａ"は、関心があるイ
ベント・モニタにとって使用可能となるデータを含む文
字変数である。

【０２１５】"ｅｖｅｎｔ＿ｄａｔａ＿ｌｅｎｇｔｈ"
は、ｅｖｅｎｔ＿ｄａｔａの長さを与える符号付き４バ
イト２進変数キーである。

【０２１６】"ｅｖｅｎｔ＿ｋｅｙ＿ｏｆｆｓｅｔ"は、
信号で通知されるイベントの特定のインスタンスを特徴
づけるキーの第１バイトのｅｖｅｎｔ＿ｄａｔａにおけ
るオフセットを含む符号付き４バイト２進変数である。

【０２１７】"ｅｖｅｎｔ＿ｋｅｙ＿ｌｅｎｇｔｈ"は、
ｅｖｅｎｔ＿ｄａｔａに含まれるキーの長さを含む符号
付き４バイト２進変数である。このタイプのイベント
に、またはイベントのこの発生にイベントの２次的特性
づけが必要でない場合は、このキーは空白となる（すな
わち、その長さは０である）。

【０２１８】 ＥｖｅｎｔＴｅｓｔ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ ｅｖｅｎｔ＿ｆｌａｇ パラメータ： "ＥｖｅｎｔＴｅｓｔ"は、呼び込まれる機能の名前であ
る。

【０２１９】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＴｅｓｔ
からの戻りコードを保持するための符号付き４バイト２
進変数である。

【０２２０】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＴｅｓｔ
からの理由コードを保持するための符号付き４バイト２
進変数である。

【０２２１】"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ"は、その条
件がテストされるモニタを識別するトークンを含む符号
付きの４バイト２進変数である。値０は、現スレッド上
で最近に活動化された活動状態のイベント・モニタを識
別するために使用される。

【０２２２】"ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ"は、
その発生がテストされるイベントの数を含む符号付き４
バイト２進変数である。一般に、これは、イベント・モ
ニタの定義中で指定されたｅｖｅｎｔ＿ｎａｍｅとｅｖ
ｅｎｔ＿ｋｅｙの組合せの数と同じになるはずである。

【０２２３】"ｅｖｅｎｔ＿ｆｌａｇ"は、ｎｕｍｂｅｒ
＿ｏｆ＿ｅｖｅｎｔｓ個の符号付き４バイト２進変数の
アレイであり、その各要素中で、イベント・モニタを定
義する際に使用されたｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒ
ｅｓｓ、ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ、ｅｖｅ
ｎｔ＿ｋｅｙ＿ａｄｄｒｅｓｓ及びｅｖｅｎｔ＿ｋｅｙ
＿ｌｅｎｇｔｈアレイの対応する要素によって指定され
たｅｖｅｎｔ＿ｎａｍｅとｅｖｅｎｔ＿ｋｅｙの対によ
って識別されるイベントの発生または非発生の指示が返
される。すなわち、 ０、１、２．．．イベントが信号で通知され、その数
が、ＥｖｅｎｔＲｅｔｒｉｅｖｅ機能によって得られる
信号に関する提供されるデータの長さであることを示
す。

【０２２４】−１．．．．．．イベントが信号で通知さ
れていないことを示す。

【０２２５】−２．．．．．．イベント定義が削除され
たことを示す。

【０２２６】−３．．．．．．対応するｅｖｅｎｔ＿ｎ
ａｍｅとｅｖｅｎｔ＿ｋｅｙの対がイベント・モニタ内
で定義されていなかったことを示す。

【０２２７】 ＥｖｅｎｔＴｒａｐ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ ｔｒａｐ＿ｒｏｕｔｉｎｅ＿ａｄｄｒｅｓｓ ｔｒａｐ＿ｒｏｕｔｉｎｅ＿ｎａｍｅ パラメータ： "ＥｖｅｎｔＴｒａｐ"は、呼び込まれる機能の名前であ
る。

【０２２８】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＴｒａｐ
からの戻りコードを保持するための符号付き４バイト２
進変数である。

【０２２９】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＴｒａｐ
からの理由コードを保持するための符号付き４バイト２
進変数である。

【０２３０】"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ"は、その条
件がトラップされるモニタを識別するトークンを含む、
符号付きの４バイト２進変数である。値０は、現スレッ
ド上で最近に活動化された活動状態のイベント・モニタ
を識別するために使用される。

【０２３１】"ｔｒａｐ＿ｒｏｕｔｉｎｅ＿ａｄｄｒｅ
ｓｓ"は、モニタによって定義された条件が満たされた
ときに呼び込まれるルーチンのアドレスを含む４バイト
２進変数である。あるアドレスがそのイベント・モニタ
と以前に関連づけられていた場合、そのアドレスは新し
いｔｒａｐ＿ｒｏｕｔｉｎｅ＿ａｄｄｒｅｓｓで自動的
に置き換えられる。アドレスが非０値である場合、ｔｒ
ａｐ＿ｒｏｕｔｉｎｅ＿ｎａｍｅパラメータは無意味で
ある。

【０２３２】"ｔｒａｐ＿ｒｏｕｔｉｎｅ＿ｎａｍｅ"
は、モニタによって定義される条件が満たされたときに
呼び込まれるルーチンの名前を含む８バイト文字変数で
ある。このパラメータは、ｔｒａｐ＿ｒｏｕｔｉｎｅ＿
ａｄｄｒｅｓｓパラメータが０の場合にだけ意味をも
つ。ある名前がそのイベント・モニタと以前に関連づけ
られていた場合は、その名前は新しいｔｒａｐ＿ｒｏｕ
ｔｉｎｅ＿ｎａｍｅで自動的に置き換えられる。ｔｒａ
ｐ＿ｒｏｕｔｉｎｅ＿ａｄｄｒｅｓｓパラメータが０で
あり、ｔｒａｐ＿ｒｏｕｔｉｎｅ＿ｎａｍｅがブランク
である場合は、指定されたイベント・モニタに関連する
トラップが取り消される。

【０２３３】 ＥｖｅｎｔＷａｉｔ ｒｅｔｃｏｄｅ ｒｓｎｃｏｄｅ ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ ｅｖｅｎｔ＿ｆｌａｇ パラメータ： "ＥｖｅｎｔＷａｉｔ"は、呼び込まれる機能の名前であ
る。

【０２３４】"ｒｅｔｃｏｄｅ"は、ＥｖｅｎｔＷａｉｔ
からの戻りコードを保持するための符号付き４バイト２
進変数である。

【０２３５】"ｒｓｎｃｏｄｅ"は、ＥｖｅｎｔＷａｉｔ
からの理由コードを保持するための符号付き４バイト２
進変数である。

【０２３６】"ｍｏｎｉｔｏｒ＿ｔｏｋｅｎ"は、その条
件を待つべきモニタを識別するトークンを含む、符号付
きの４バイト２進変数である。モニタは、すでに待機状
態にあってはならない。モニタにとって未処理の待機は
一時にせいぜい１つである。値０は、現スレッド上で最
近に活動化された活動状態のイベント・モニタを識別す
るために使用される。

【０２３７】"ｎｕｍｂｅｒ＿ｏｆ＿ｅｖｅｎｔｓ"は、
ＥｖｅｎｔＷａｉｔ機能が完了するときにその発生が示
されるイベントの数を含む、符号付き４バイト２進変数
である。一般に、これは、イベント・モニタの定義中で
指定されたｅｖｅｎｔ＿ｎａｍｅとｅｖｅｎｔ＿ｋｅｙ
の組合せの数と同じとなるはずである。

【０２３８】"ｅｖｅｎｔ＿ｆｌａｇ"は、ｎｕｍｂｅｒ
＿ｏｆ＿ｅｖｅｎｔｓ個の符号付き４バイト２進変数の
アレイであり、その各要素中で、イベント・モニタを定
義する際に使用されたｅｖｅｎｔ＿ｎａｍｅ＿ａｄｄｒ
ｅｓｓ、ｅｖｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈ、ｅｖｅ
ｎｔ＿ｋｅｙ＿ａｄｄｒｅｓｓ及びｅｖｅｎｔ＿ｋｅｙ
＿ｌｅｎｇｔｈアレイの対応する要素によって指定され
るｅｖｅｎｔ＿ｎａｍｅとｅｖｅｎｔ＿ｋｅｙの対によ
って識別されるイベントの発生または非発生の指示が返
される。すなわち、 ０、１、２．．．イベントが信号で通知され、その数
が、ＥｖｅｎｔＲｅｔｒｉｅｖｅ機能によって得られる
信号に関する提供されるデータの長さであることを示
す。

【０２３９】−１．．．．．．イベントが信号で通知さ
れていないことを示す。

【０２４０】−２．．．．．．イベント定義が削除され
たことを示す。

【０２４１】−３．．．．．．対応するｅｖｅｎｔ＿ｎ
ａｍｅとｅｖｅｎｔ＿ｋｅｙの対がイベント・モニタ内
で定義されていなかったことを示す。

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

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

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

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

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

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

【０２４８】 ＴＲＡＣＥＣＯＮＴＲＯＬ Ｒｔｎｃｏｄｅ Ｒｓｎｃｏｄｅ Ｔｒａｃｅｆｌｇ Ｗｒａｐｓｉｚｅ Ｆｕｎｃｔｉｏｎ Ｎ Ｔｒａｃｅｔｙｐｅ（Ｎ） Ｔｒａｃｅｔｙｐｅ＿Ｓｅｔｔｉｎｇ（Ｎ） パラメータ： "Ｒｔｎｃｏｄｅ"は、ＴＲＡＣＥＣＯＮＴＲＯＬからの
戻りコードを保持するための符号付き４バイト２進変数
である。

【０２４９】"Ｒｓｎｃｏｄｅ"は、ＴＲＡＣＥＣＯＮＴ
ＲＯＬからの理由コードを保持するための符号付き４バ
イト２進変数である。

【０２５０】"Ｔｒａｃｅｆｌｇ"は、トレース・イベン
トのシグナラがどの程度同期化されるべきかを指定す
る。それは、符号付き４バイト２進整数であり、有効値
は以下の通りである。

【０２５１】０（ＡＳＹＮＣ） 信号通知スレッドがイ
ベント処理とは独立に処理を続ける。

【０２５２】１（ＴＳＹＮＣ） 信号通知スレッドがイ
ベント処理の結果を待って中断される。

【０２５３】２（ＰＳＹＮＣ） 信号通知プロセスがイ
ベント処理の結果を待って中断される。

【０２５４】３（ＤＳＹＮＣ） 信号通知プロセス及び
そのすべての子孫がイベント処理の結果を待って中断さ
れる。

【０２５５】−１（ＵＮＣＨ） 同期化が変更されな
い。

【０２５６】"Ｗｒａｐｓｉｚｅ"は、イベントが信号で
通知されるときに適格なトレース・イベント・モニタが
存在しない場合、いくつのトレース・イベントが保持さ
れるかを指定する。これは、ルース信号限界に対応す
る。ｗｒａｐｓｉｚｅを超えたとき、最も古いトレース
・イベントが、新しく到着した信号用の場所をあけるた
めに放棄される。これは、４バイトの符号付き２進整数
である。値０は、トレース・イベントが保持されないこ
とを示す。値−１は、仮想記憶域がなくなるまでトレー
ス・イベントが保持され続けることを示す。値−２は、
ｗｒａｐｓｉｚｅが変更されないことを示す。その他の
負の値は無効である。

【０２５７】"Ｆｕｎｃｔｉｏｎ"は、後に続くアレイの
使用を指定する。これは４バイトの符号付き２進整数で
あり、有効値は以下の通りである。

【０２５８】０（ＱＵＥＲＹ ＩＴＲＡＣＥ） ＩＴＲ
ＡＣＥトレースタイプが照会され、それらの設定がｔｒ
ａｃｅｔｙｐｅ＿ｓｅｔｔｉｎｇｓアレイ中で返され
る。

【０２５９】１（ＱＵＥＲＹ ＥＴＲＡＣＥ） ＥＴＲ
ＡＣＥトレースタイプが照会され、それらの設定がｔｒ
ａｃｅｔｙｐｅ＿ｓｅｔｔｉｎｇｓアレイ中で返され
る。

【０２６０】２（ＩＴＲＡＣＥ） ｔｒａｃｅｔｙｐｅ
及びｔｒａｃｅｔｙｐｅ＿ｓｅｔｔｉｎｇが、ＩＴＲＡ
ＣＥコマンドへの呼出し可能なインターフェースとして
使用される。

【０２６１】３（ＥＴＲＡＣＥ） ｔｒａｃｅｔｙｐｅ
及びｔｒａｃｅｔｙｐｅ＿ｓｅｔｔｉｎｇが、ＥＴＲＡ
ＣＥコマンドへの呼出し可能なインターフェースとして
使用される。

【０２６２】−１（ＵＮＣＨ） 後続のアレイが無視
されることを示す。

【０２６３】"Ｎ"は、セットされるトレース・タイプの
数を指定する。これは４バイトの符号付き２進整数であ
る。

【０２６４】"Ｔｒａｃｅｔｙｐｅ"は、セットされるト
レース・タイプを指定する。それは、４バイトの符号付
き２進整数のアレイであり、有効値は以下の通りであ
る。

【０２６５】 ０（ＡＬＬ） すべてのトレース・タイプ １（ＣＯＭＭ） 通信イベント ２（ＤＩＳＰ） 指名イベント ３（ＳＴＯＲ） 記憶管理イベント ４（ＩＯ） 入出力イベント ５（ＰＲＧＭＡＮ） プログラム管理イベント ６（ＰＲＣＭＡＮ） プロセス管理イベント ７（ＭＩＳＣ） タイマ、外部割込み及び機械チェック・イベント ８（ＤＴＭＡＮ） データ管理イベント ９（ＧＲＯＵＰ） 以前の設定が、仮想機械グループ内のすべての機械に関す るものである。

【０２６６】"ｔｒａｃｅｔｙｐｅ＿ｓｅｔｔｉｎｇ"
は、ｔｒａｃｅｔｙｐｅアレイに対応する設定を指定す
る。これは、４バイトの符号付き２進整数のアレイであ
り、有効値は以下の通りである。

【０２６７】０（オフ） 対応するトレース・タイプが
オフにセットされる。

【０２６８】０（オン） 対応するトレース・タイプが
オンにセットされる。

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

【０２７０】ＩＴＲＡＣＥキーボード・コマンドは、効
果の点でＴＲＡＣＥＣＯＮＴＲＯＬＡＰＩ呼出しと類似
しており、ＣＭＳによってイベント信号マネージャへ信
号で通知するために、事前定義されたトレース・イベン
トのうちのどれが選択されるか、及び「ラップ・サイ
ズ」またはルース信号限界を指定する。そのフォーマッ
トは以下の通りである。

【０２７１】 ＩＴＲＡＣＥ ＡＬＬ ＯＮ／ＯＦＦ ＣＯＭＭＵＮＩＣＡＴＩＯＮ ＯＮ／ＯＦＦ ＤＩＳＰＡＴＣＨ ＯＮ／ＯＦＦ ＳＴＯＲＡＧＥ ＯＮ／ＯＦＦ Ｉ／Ｏ ＯＮ／ＯＦＦ ＰＲＯＧＭＡＮ ＯＮ／ＯＦＦ ＰＲＯＣＭＡＮ ＯＮ／ＯＦＦ ＤＡＴＡＭＡＮ ＯＮ／ＯＦＦ ＭＩＳＣ ＯＮ／ＯＦＦ ＧＲＯＵＰ ＯＮ／ＯＦＦ ＥＮＤ ＷＲＡＰＳＩＺＥ ＸＸＸＸＸＸＸＸ "Ａｌｌ"は、すべてのトレース・エントリが信号で通知
されるか否かを指定する。許容される値は以下の通りで
ある。

【０２７２】ＯＮ トレース・エントリが信号で通知
される。

【０２７３】ＯＦＦ トレース・エントリが信号で通知
されない。

【０２７４】"Ｃｏｍｍｕｎｉｃａｔｉｏｎ"は、通信ト
レース・エントリが信号で通知されるか否かを指定す
る。このタイプのトレース・エントリの可能な例は、Ｉ
ＵＣＶ及びＡＰＰＣトランザクション及び待ち行列動作
である。許容される値は以下の通りである。

【０２７５】ＯＮ トレース・エントリが信号で通知
される。

【０２７６】ＯＦＦ トレース・エントリが信号で通知
されない。

【０２７７】"Ｄｉｓｐａｔｃｈ"は、指名トレース・エ
ントリが信号で通知されるか否かを指定する。このタイ
プのトレース・エントリの可能な例は、Ｔｈｒｅａｄ
Ｄｉｓｐａｔｃｈ及びＴｈｒｅａｄ Ｐｒｉｏｒｉｔｙ
Ｍｏｄｉｆｉｃａｔｉｏｎである。許容される値は以
下の通りである。

【０２７８】ＯＮ トレース・エントリが信号で通知
される。

【０２７９】ＯＦＦ トレース・エントリは信号で通知
されない。

【０２８０】"Ｓｔｏｒａｇｅ"は、記憶トレース・エン
トリが信号で通知されるか否かを指定する。このタイプ
のトレース・エントリの可能な例は、Ｆｒｅｅ Ｓｔｏ
ｒａｇｅ Ｏｂｔａｉｎ及びＦｒｅｅ Ｓｔｏｒａｇｅ
Ｒｅｔｕｒｎである。許容される値は以下の通りであ
る。

【０２８１】ＯＮ トレース・エントリが信号で通知
される。

【０２８２】ＯＦＦ トレース・エントリが信号で通知
されない。

【０２８３】"Ｉ／Ｏ"は、入出力トレース・エントリが
信号で通知されるか否かを指定する。このタイプのトレ
ース・エントリの可能な例は、入出力要求及び入出力割
込み発生である。許容される値は以下の通りである。

【０２８４】ＯＮ トレース・エントリが信号で通知
される。

【０２８５】ＯＦＦ トレース・エントリが信号で通知
されない。

【０２８６】"Ｐｒｏｇｍａｎ"は、プログラム管理トレ
ース・エントリが信号で通知されるか否かを指定する。
このタイプのトレース・エントリの可能な例は、Ｃｏｍ
ｍａｎｄ Ｌｏａｄ及びＰｒｏｇｒａｍ Ｌｏａｄであ
る。許容される値は以下の通りである。

【０２８７】ＯＮ トレース・エントリが信号で通知
される。

【０２８８】ＯＦＦ トレース・エントリが信号で通知
されない。

【０２８９】"Ｐｒｏｃｍａｎ"は、プロセス管理トレー
ス・エントリが信号で通知されるか否かを指定する。こ
のタイプのトレース・エントリの可能な例は、Ｐｒｏｃ
ｅｓｓ Ｃｒｅａｔｅ及びＴｈｒｅａｄ Ｃｒｅａｔｅ
である。許容される値は以下の通りである。

【０２９０】ＯＮ トレース・エントリが信号で通知
される。

【０２９１】ＯＦＦ トレース・エントリが信号で通知
されない。

【０２９２】"Ｄａｔａｍａｎ"は、データ管理トレース
・エントリが信号で通知されるか否かを指定する。この
タイプのトレース・エントリの可能な例は、Ｆｉｌｅ
Ｓｙｓｔｅｍ Ｒｅａｄ及びＦｉｌｅ Ｓｙｓｔｅｍ
Ｗｒｉｔｅである。許容される値は以下の通りである。

【０２９３】ＯＮ トレース・エントリが信号で通知
される。

【０２９４】ＯＦＦ トレース・エントリが信号で通知
されない。

【０２９５】"Ｍｉｓｃ"は、類別できないトレース・エ
ントリが信号で通知されるか否かを指定する。このタイ
プのトレース・エントリの可能な例は、機械チェック、
外部割込み及びタイマ割込みである。許容される値は以
下の通りである。

【０２９６】ＯＮ トレース・エントリが信号で通知
される。

【０２９７】ＯＦＦ トレース・エントリが信号で通知
されない。

【０２９８】"Ｇｒｏｕｐ"は、信号で通知されるトレー
ス・エントリが発行側の仮想機械グループ内のすべての
機械において信号で通知されるか否かを指定する。この
オペランドは、ＧＲＯＵＰオペランドが処理されている
とき現在信号で通知されているトレース・エントリだけ
に適用される。すなわち、ＧＲＯＵＰオペランドの右側
のオペランドは、ＧＲＯＵＰオペランドの影響を受けな
い。このオペランドは、グループの一部分でない仮想機
械によって指定されない。許容される値は以下の通りで
ある。

【０２９９】ＯＮ 仮想機械グループ内のすべての機
械においてトレース・エントリが信号で通知される。

【０３００】ＯＦＦ 仮想機械グループ内の他のいずれ
かの機械においてトレース・エントリが信号で通知され
ない。

【０３０１】"Ｅｎｄ"は、トレース・エントリが信号で
通知されないことを指定する。

【０３０２】"Ｗｒａｐｓｉｚｅ ｘｘｘ"は、トレース
・エントリが信号で通知されるとき適格なトレース・イ
ベント・モニタが存在しない場合に、いくつのトレース
・エントリがトレース・テーブル内に保持されるかを指
定する。ラップサイズを超えたとき、新しく到着した信
号用の場所をあけるために最も古いトレース・エントリ
が放棄される。値０は、トレース・エントリが保持され
ないことを示す。

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

【０３０４】ＥＴＲＡＣＥ ＥＶＥＮＴＮＡＭＥ ＯＮ
ＯＲ ＯＦＦ、ＥＶＥＮＴＮＡＭＥＯＮ ＯＲ ＯＦ
Ｆ ＥＴＣ．トレース管理サービスの利用に関する段階
は、以下の通りである。

【０３０５】まず、適用業務プログラムがＴＲＡＣＥＣ
ＯＮＴＲＯＬ呼出しを発行し、またはユーザがキーボー
ドを介して、どのトレース・イベントが構築され信号で
通知されるかを定義するＩＴＲＡＣＥコマンド、ならび
にラップ・サイズを入力する。次に、これらのトレース
・イベントが、ＣＭＳの処理における適当な時点で発生
し、ＣＭＳがシグナラとして機能して、イベント・デー
タを含むトレース・イベントを信号で通知する。トレー
ス・エントリのフォーマットは以下の通りである。

【０３０６】１．ＨＥＡＤＥＲ ＬＥＮＧＴＨ−トレー
ス・ヘッダ情報の長さ。

【０３０７】２．ＵＳＥＲＩＤ−トレース信号を発行す
る仮想機械のユーザ識別。

【０３０８】３．ＰＲＯＣＥＳＳＩＤ−その代りにこの
トレース・エントリが信号で通知されるプロセスの一義
的プロセス識別子。

【０３０９】４．ＴＲＥＡＤＩＤ−その代りにこのトレ
ース・エントリが信号で通知されるスレッドの一義的ス
レッド識別子。

【０３１０】５．ＴＲＡＣＥＩＤ−トレース・エントリ
の特定のタイプ。

【０３１１】６．ＴＩＭＥＳＴＡＭＰ−トレース・エン
トリが信号で通知される時間（タイマ単位で）。

【０３１２】７．ＦＯＲＭＡＴ ＲＯＵＴＩＮＥ−この
トレース・エントリをフォーマットするのに必要なルー
チンの識別子。

【０３１３】８．ＶＡＲＩＡＢＬＥ ＨＥＡＤＥＲ Ｄ
ＡＴＡ−ヘッダに含まれるその他のデータ。

【０３１４】９．ＤＡＴＡ ＬＥＮＧＴＨ−実際のトレ
ース・データの長さ。

【０３１５】１０．ＶＡＲＩＡＢＬＥ ＤＡＴＡ−実際
のトレース・データ。

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

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

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

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

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【符号の説明】

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

───────────────────────────────────────────────────── フロントページの続き (72)発明者 アン・マリー・シェパード アメリカ合衆国13760、ニューヨーク州エ ンドウェル、ワトソン・ブールバード 3606番地 (72)発明者 スティーブン・ソール・シュルツ アメリカ合衆国13760、ニューヨーク州エ ンディコット、バーナード・ブールバード 2016番地 (56)参考文献 特開 昭63−228335（ＪＰ，Ａ) 特開 平２−230455（ＪＰ，Ａ)

Claims (12)

【特許請求の範囲】
1. 【請求項１】イベントを管理するためのコンピュータ・
   システムにおいて、 複数のプログラムまたはその部分があるイベントの通知
   を受け取ることができるシーケンスを定義する手段と、 シーケンス内の前記のプログラムまたは部分のうち第１
   のものにイベントの発生について通知する手段と、 イベント通知を前記シーケンス内の次のプログラムまた
   は部分に伝搬すべきか否かを示す指示を、前記プログラ
   ムまたは部分の第１のものから受け取る手段と、 前記の指示がイベント通知を伝搬することである場合
   に、イベント通知をシーケンス内の前記の次のプログラ
   ムまたは部分に伝搬する手段と、 前記の指示がイベント通知を伝搬しないことである場合
   に、シーケンス内の前記の次のプログラムまたは部分へ
   のイベント通知の伝搬をブロックする手段と を含むコンピュータ・システム。
2. 【請求項２】さらに、イベントを定義するパラメータを
   受け取る手段を含み、前記パラメータの１つが、イベン
   ト通知を受け取るシーケンス内の各プログラムまたは部
   分による、イベント通知を伝搬するようにとの指示に従
   って、イベント通知が伝搬手段によってシーケンス内の
   次のプログラムまたは部分に順次伝搬できるかどうか、
   または、そのイベントに関係のあるすべてのプログラム
   またはその部分にイベント通知を同報通信すべきかどう
   かを指定する、請求項１に記載のコンピュータ・システ
   ム。
3. 【請求項３】さらに、同報通信パラメータで定義される
   イベントの信号に応答して、関係のあるすべてのプログ
   ラムまたは部分にイベントの通知を同報通信する手段を
   含む、請求項２に記載のコンピュータ・システム。
4. 【請求項４】シーケンス中の先行するプログラムまたは
   その部分によりイベントの通知を伝搬して良いとの指示
   を受けることにより、それぞれのプログラムまたはその
   部分のためにイベントの通知を受け取って、それぞれの
   プログラムまたはその部分による要求があるときイベン
   トの通知をそれぞれのプログラムまたはその部分に渡す
   イベント・モニタを複数個生成するオペレーティング・
   システムと、 イベントの発生を検知してこれをシーケンスの第１のイ
   ベント・モニタに知らせる検知手段と、 を含む請求項１に記載のコンピュータ・システム。
5. 【請求項５】前記シーケンスを定義する手段が、連鎖の
   中で各イベント・モニタの位置が前記シーケンス中のイ
   ベント・モニタの位置を示し且つこれにより前記シーケ
   ンス中のそれぞれのプログラムまたはその部分の位置を
   示すようにイベント・モニタを連鎖するものである、請
   求項４に記載のコンピュータ・システム。
6. 【請求項６】前記イベント・モニタのシーケンスが、イ
   ベントの通知を前記プログラムまたはその部分が受け取
   る順番をなし、 前記伝搬する手段が、前記シーケンス中のプログラムま
   たはその部分によりイベントを伝搬させて良いとの指示
   を受けたときイベントの通知を前記シーケンス中のイベ
   ント・モニタの第１のものから次のイベント・モニタに
   伝搬させる、 ことを特徴とする請求項４に記載のコンピュータ・シス
   テム。
7. 【請求項７】異なるタイプのイベントの定義を受け取っ
   てこれを記憶する手段であって、各定義がイベントの処
   理中における前記イベントのシグナラの動作モードを指
   定し、前記動作モードには、イベントが処理されるまで
   イベント・シグナラが処理を中断する同期モードと、イ
   ベントの処理中にイベント・シグナラが処理を継続する
   非同期モードとが含まれる、手段と、 前記イベント・シグナラおよび前記記憶する手段に結合
   され、前記イベントのイベント信号を受信し、各イベン
   トのイベント・シグナラに、イベント定義に従って同期
   的に進めるのかそれとも非同期的に進めるのかを通知す
   るためのイベント・マネージャ手段と を含むコンピュータ・システム。
8. 【請求項８】前記イベント・マネージャ手段に結合さ
   れ、前記コンピュータ内部で実行される適用業務プログ
   ラム内に常駐し、前記イベントの通知を受取り済みで前
   記イベントを処理中または処理済みのイベント・ハンド
   ラから、前記イベント・シグナラが他の処理を続行でき
   るかどうかの通知を受け取る手段を含み、 前記イベント・マネージャ手段が、前記イベント・シグ
   ナラに、前記イベント・シグナラまたは関連プロセスが
   中断されている場合、前記イベント・ハンドラからの前
   記通知に基づいて他の処理を続行するかどうかを通知す
   ることを特徴とする、 請求項７に記載のコンピュータ・システム。
9. 【請求項９】対応するイベント定義に関連するイベント
   信号を記憶する手段を含み、 前記イベント・マネージャが、何らかの適用業務プログ
   ラムがイベントの通知を要求する前に、記憶手段へのイ
   ベント信号の記憶を制御することを特徴とする、 請求項７に記載のコンピュータ・システム。
10. 【請求項１０】何らかの適用業務プログラムがイベント
    の通知を要求する前に、対応するイベント定義に関連す
    る記憶手段に記憶されうるイベント信号の最大数を示す
    限界を前記イベント定義の各々が含み、前記イベント信
    号は前記限界に従って記憶されることを特徴とする請求
    項９に記載のコンピュータ・システム。
11. 【請求項１１】イベント・モニタについての定義を受け
    取る手段であって、該定義が、イベント・モニタにより
    通知を要求される複数のタイプのイベント、および該イ
    ベント・モニタに関連するプログラムに通知させる前記
    タイプのイベントの発生回数について１より大なる数値
    を指定する如きものと、 前記受取り手段に結合され、前記定義に従って前記イベ
    ント・モニタを確立する手段であって、複数のタイプの
    イベントの発生の通知を要求し、かつ複数のタイプのイ
    ベントの発生について前記個数の信号を受け取ったとき
    関連するプログラムに通知するイベント・モニタを確立
    する、イベント・モニタ確立手段と、 前記イベント・モニタに論理的に結合され、前記イベン
    ト・モニタが通知を要求している前記複数のタイプのイ
    ベントを含む種々のタイプのイベントの発生についての
    信号を受け取り、前記イベント・モニタが通知を要求し
    ている前記複数のタイプのイベントの発生についての信
    号を前記イベント・モニタに転送する、イベント・マネ
    ージャ手段と を含み、 前記イベント・モニタは、前記複数のタイプのイベント
    の発生について指定された個数の信号を受け取ったと
    き、該イベント・モニタに関連するプログラムに通知す
    る手段を含むことを特徴とするコンピュータ・システ
    ム。
12. 【請求項１２】イベント・モニタについての定義を受け
    取る手段であって、該定義が、イベント・モニタにより
    通知を要求される複数のタイプのイベント、および該イ
    ベント・モニタに関連するプログラムに通知すべき前記
    タイプのイベントの発生回数について１より大なる数値
    を指定する如きものと、 前記受取り手段に結合され、前記定義に従って前記イベ
    ント・モニタを確立する手段であって、複数のタイプの
    イベントの発生の通知を要求し、かつ複数のタイプのイ
    ベントの発生について前記指定された個数の信号を受け
    取ったとき関連するプログラムに通知するイベント・モ
    ニタを確立する、イベント・モニタ確立手段と、 前記イベント・モニタが通知を要求している前記複数の
    タイプのイベントを含む種々のタイプのイベントの発生
    についての信号を受け取り、前記イベント・モニタが通
    知を要求している前記複数のタイプのイベントの発生に
    ついての信号を前記イベント・モニタに転送する、イベ
    ント・マネージャ手段と を含み、 前記イベント・モニタは、前記複数のタイプのイベント
    の発生について指定された個数の通知を受け取ったと
    き、該イベント・モニタに関連するプログラムに通知し
    該プログラムにイベント・モニタが通知を受けたイベン
    ト信号を与える手段を含むことを特徴とするコンピュー
    タ・システム。