JPH0461379B2 - - Google Patents

Description

【発明の詳細な説明】 〔概要〕 計算機システムにおいて、通知する事象と受取
との対応を管理する事象管理簿を設けると共に、
監視依頼の内容を登録する監視依頼処理部、事象
受取に関する要求を処理する通知要求処理部、事
象通知に関する要求を処理する通知要求処理部、
監視依頼の解除要求を処理する監視解除処理部を
設けることにより、事象の通知側が事象の受け手
側を明示的に意識することなく、必要としている
受け手側へ柔軟に事象を通知できるような統一的
な事象の通知・受取を可能とする。

〔産業上の利用分野〕

本発明は計算機システムにおける事象通知・受
取処理方式、特に事象の種類や事象の内容に依存
しない統一した事象の通知・受取を可能とした計
算機システムにおける事象通知・受取処理方式に
関するものである。

計算機システムにおいて非同期的に発生する事
象を、その事象について何らかの処理を行う処理
部に通知する場合、通知側と受取側との独立性お
よび事象の種類や内容に依存しな汎用性を有する
通知・受取ができることが望まれる。

〔従来の技術〕

第７図は従来方式の例を示す。

計算機システムにおいて、プログラムの実行中
に事象を検出して、処理の流れとは別のところへ
その事象を通知しなければならないことがある。
従来方式では、事象を受け取つて処理する相手
（以下、受取者という）を事象の通知側が完全に
意識し、密接な結び付きで通知し、その通知を契
機として受取者が処理を開始するという方法がと
られている。そのため、第７図に示すように、そ
れぞれの目的に応じた通知手段がシステム内に
個々に存在していた。

〔発明が解決しようとする問題点〕

上記従来の方式では、次のような問題がある。

(i) ある事象を複数の受取者に通知したい場合、
それぞれに対して通知を繰り返さなければなら
ない。例えば、第７図に示すように、プログラ
ムＡが事象Ｄを検出して、別に位置するプログ
ラムＢとプログラムＣとに通知方法Ｅを使つて
通知しようとする場合、まず初めにプログラム
Ｂに通知方法Ｅを使つて通知する。その次にプ
ログラムＣにも同じように通知方法Ｅを使つて
通知しなければならない。

(ii) 事象を通知しようとする場合、相手が存在し
ていることを予め確認しておく必要がある。第
７図の例では、プログラムＢとプログラムＣと
が存在していることをプログラムＡは各々通知
する前に確認しておく必要がある。

(iii) 事象の通知側と受取側とは静的な結び付きで
あるため、受取側の増域を動的に変更すること
ができない。即ち、受取側からの監視や受取要
求の依頼およびその解除ができなく、常に通知
側からの通知に頼つている。もし、受取者が変
わつた場合、通知側にもそれに対する修正を加
えなければならない。例えば、第７図におい
て、事象Ｄを新たなプログラムＦが受け取りた
い場合に、通知元のプログラムＡは、プログラ
ムＦにも事象Ｄを通知するための処理を加えな
ければならない。

(iv) 新たに通知したい事象がでてきた場合、その
ための通知手段を開発しなければならない。そ
のため、生産性が向上せず、かつコストがかか
る。例えば、第７図において、プログラムＡに
機能追加を行つて、先の事象Ｅとは全く別な種
類の新たな事象ＧをプログラムＦに通知しなけ
ればならなくなつた場合、新たな通知方法Ｈを
開発しなければならない。

本発明は上記問題点の解決を図り、通知側と受
取側との独立性を高め、事象の種類や事象の内容
に依存しない統一した通知を可能とする手段を提
供することを目的としている。

〔問題点を解決するための手段〕

第１図は本発明の基本構成例を示す。

第１図において、１０はCPUおよびメモリ等
からなる処理装置、１１は通知を受け取る受取主
体、１２は事象を通知する通知主体、１３は事象
を管理する事象管理部、１４は事象の監視依頼を
処理する監視依頼処理部、１５は監視依頼の解除
要求を処理する監視解除処理部、１６は事象受取
に関する要求を処理する受取要求処理部、１７は
事象通知に関する要求を処理する通知要求処理
部、１８は事象情報を保存する事象保存処理部、
１９は事象管理簿、２０は発生した事象を記憶す
る事象キユー、２１は事象情報を記憶する事象ブ
ロツク、２２は事象保存フアイル、２３はデイス
プレイ、２４は一般のフアイル、２５は監視依頼
を行うOPNEVENT（オープンイベント）マク
ロ、２６は受取を要求するRCVEVENT（レシー
ブイベント）マクロ、２７は監視解除を要求する
CLSEVENT（クローズイベント）マクロ、２８
は通知を要求するNTFEVENT（ノーテイフアイ
イベント）マクロを表す。

本発明では、システムで発生する事象情報を、
監視要求単位ごとに管理する事象管理簿１９が設
けられる。事象管理簿１９は、受取主体１１の識
別情報を記憶する受取主体情報欄、監視・受取の
対象となる事象情報を記憶する監視事象情報欄、
受取の条件を記憶する条件欄、受取待ち情報を記
憶する受取待ち情報欄、通知要求があつた事象情
報を記憶する発生事象情報欄の記憶領域を有して
いる。

監視依頼処理部１４は、受取主体１１から
OPNEVENTマクロ２５による事象の監視依頼
により、事象管理簿１９に、受取主体情報、監視
事象情報、また必要に応じて受取の条件情報を登
録するものである。この条件は、例えば受取りた
い事象が種々のユーザのもとで発生するような場
合、あるユーザのもとで発生した事象だけ受け取
る対象とするというような条件である。

受取主体１１からRCVEVENTマクロ２６が
発生されると、受取要求処理部１６が起動され
る。受取要求処理部１６は、事象管理簿１９を検
索し、受取が要求された事象が発生している場合
には、その事象を受取主体１１へ通知し、その事
象が発生していない場合には、事象管理簿１９に
受取待ち情報を設定する処理を行う。

通知主体１２は、通知したい事象がある場合
に、その事象を指定してNTFEVENTマクロ２
８を発行する。これにより、通知要求処理部１７
が起動され、通知要求処理部１７は、事象管理簿
１９における対応する監視依頼内容を検索し、既
に受取待ち情報が設定されている場合に、その事
象を受取要求元へ通知する。また受取待ち情報が
設定されていない場合には、事象管理簿１９の発
生事象情報欄からポイントされる事象キユー２０
に事象情報を持つ事象ブロツク２１をキユーイン
グする処理を行う。

監視解除処理部１５は、受取主体１１による
CLSEVENTマクロ２７の発行により、事象管理
簿１９から該当する監視依頼内容を抹消する処理
を行うものである。

〔作用〕

事象の受取者である受取主体１１は、予め監視
依頼した範囲内で、後から事象の発生を待つ要求
を依頼する。従つて、受取主体１１は、柔軟に事
象の発生を待つことができ、監視依頼後に発生し
た事象を漏れなく監視して必要なときにそれを受
け取ることができる。

一方、事象の通知者である通知主体１２は、事
象の種類、内容に依存しない統一的な通知手段、
即ち、NTFEVENTマクロ２８によつて、発生
または検出した事象を通知することができる。第
１図の側では、このとき通知した事象を保存して
おくか否かを指示することができ、事象情報の保
存が指示されている場合には、事象保存処理部１
８が起動されて、所定の事象保存フアイル２２へ
の事象情報の記録がなされる。この事象情報は、
後に事象保存フアイル２２から読み出すことがで
きる。従つて、監視依頼以前に発生した事象の受
取を必要とする場合には、この事象保存フアイル
２２から事象情報を得ることができる。

事象管理簿１９に複数の受取者からの監視依頼
や受取待ち要求が出されている場合には、その対
象者のすべてに事象が通知される。この場合、監
視依頼だけで未だ受取要求が発行されていなけれ
ば、メモリ上の事象キユー２０に事象情報が記憶
され、後に受取要求がきたときに、その事象情報
を引き渡す処理がなされる。

従つて、１つの事象に対し、複数の受取主体１
１が、それぞれデイスプレイ２３に表示すると
か、フアイル２４に格納するとかいう処理を、必
要な時点で独立に行うことができる。

〔実施例〕

第２図は本発明の一実施例説明図、第３図は本
発明の一実施例に係る監視依頼処理説明図、第４
図は本発明の一実施例に係る受取要求処理説明
図、第５図は本発明の一実施例に係る通知要求処
理説明図、第６図は本発明の一実施例に係る監視
解除処理説明図である。

第２図に示す例では、受取者R1は、事象Ａと
事象Ｂとを監視することを登録しており、受取者
R2は事象Ｃを、受取者R3は事象Ｂおよび事象Ｃ
を監視することを登録している。

通知者N1が、事象管理部１３に事象Ａの通知
を依頼すると、事象管理簿１９検索により、受取
者R1に事象Ａが通知される。通知者N2が、事象
管理部１３に事象Ｂの通知を依頼すると、受取者
R1および受取者R3に事象Ｂが通知される。同様
に、通知者N3が、事象管理部１３に事象Ｃの通
知を依頼すると、事象管理簿１９の検索により、
受取者R2および受取者R3に事象Ｃが通知され
る。

このように本発明では、事象の通知側で相手を
決めつけるのではなく、第２図に示すように、受
取側の依頼を事象管理簿１９に登録し、通知され
てきた事象がどこに通知されなければならないか
を、その事象管理簿１９を検索することにより決
定して、必要なすべての受取者に事象を通知する
ようにされる。

次に本発明の一実施例について、第３図ないし
第６図に従い、さらに詳細に説明する。以下の例
では、説明を簡略化するために、受取者をR1、
監視事象をＡ、条件をユーザＸ、受取要求をＹと
して説明する。事象Ａの発生は、ユーザＸの処理
に関係して発生するものとする。

第１図に示すOPNEVENTマクロ２５により、
監視依頼処理部１４は、例えば第３図に示すよう
に処理する。即ち、事象管理簿１９に新しいエン
トリを確保し、監視依頼内容として、受取者R1
の受取主体情報と、監視事象Ａの情報と、ユーザ
Ｘの情報とを登録する。

第１図に示すRCVEVENTマクロ２６によつ
て、受取要求処理部１６は第４図に示すように処
理する。以下の説明における番号〜は、第４
図に示す処理番号〜に対応する。

事象の受取要求を受けると、事象管理簿１９
の対応する受取者R1のエントリを探し、事象
Ａが既に発生しているか否かを検査する。発生
事象情報欄に事象がキユーイングされていない
場合、発生なしであるので、処理へ制御を移
し、事象がキユーイングされている場合、処理
へ制御を移す。

事象Ａがまだ発生していない場合、事象管理
簿１９の受取待ち情報欄に、受取待ち要求Ｙの
情報を記入して待ちの状態に入る。その後、事
象Ａが通知されると、待ちの解除がなされ、処
理へ制御が移行される。

発生した事象を受取者R1に渡し、事象ブロ
ツク内に記入されている未受取者数から１減算
する。

事象Ａに対して、まだ受け取つていない受取
主体が存在する場合、即ち、事象ブロツク内に
記入されている未受取者数が０でないかどうか
を調べ、０でなかつた場合には、事象情報のそ
のままメモリ上に保存する。

事象Ａを欲している他の未受取者が存在しな
い場合には、その事象Ａの情報をメモリ上から
消去し、処理を終了する。

第１図に示すNTFEVENTマクロ２８によつ
て、通知要求処理部１７は第５図に示すように処
理する。以下の説明における番号〜は、第５
図に示す処理番号〜に対応する。

通知されてきた事象Ａの情報を、メモリ上の
事象情報域である事象ブロツク２１に記入す
る。

通知側からの指定で、事象Ａの保存が必要で
あるか否かを判断し、保存が必要であれば、第
１図に示す事象保存処理部１８に、事象保存フ
アイル２２への事象情報の書き込みを依頼す
る。

次にこの事象Ａを欲している受取者を、事象
管理簿１９を検索して探し出す。このとき、監
視依頼の事象の外に、その監視依頼の条件内容
もあわせて検査し対象となるものを抽出する。
事象Ａを監視依頼している受取者が存在してい
ると（ここでは受取者R1が存在する）、次の処
理ないし処理の処理を行つた後、さらに処
理から同様に処理を繰り返して、事象管理簿
１９の検索を続ける。事象管理簿１９の検索が
終了した場合、処理を実行する。

事象Ａが監視依頼しているものがあると、事
象ブロツク２１に記入している事象Ａの未受取
者数に１を加える。そして事象管理簿１９の受
取待ち情報欄に受取待ちがあるか否かを調べ
る。

受取待ちが存在していれば、その受取待ちを
解除する。これにより、第４図に示す受取待ち
が解除されることになる。

事象管理簿１９における受取待ち情報欄をク
リアし、受取待ち情報を削除する。その後、処
理へ制御を戻し、次の受取者を探す。

受取待ちが存在していない場合、事象管理簿
１９の発生事象情報欄に、事象Ａの情報を記憶
する事象ブロツク２１へのポインタを設定す
る。その後、処理へ制御を戻す。

事象Ａを監視依頼している受取者がいない場
合、その事象をメモリ上の事象ブロツク２１か
ら消去する。事象Ａを監視依頼している受取者
がいる場合、メモリ上の事象ブロツク２１をそ
のままにして処理を終了する。

第１図に示すCLSEVENTマクロ２７によつ
て、監視解除処理部１５は第６図に示すように処
理する。以下の説明における番号〜は、第６
図に示す処理番号〜に対応する。

監視依頼の解除を受付けると、事象管理簿１
９から監視依頼の内容を消去する。

処理による消去にあたつて、この監視依頼
に対し事象が発生しているか否かを、事象管理
簿１９の発生事象情報欄により調べる。この発
生事象情報欄に事象がキユーイングされている
場合、この事象をまだ受け取つていない受取者
がいるかどうかを、事象ブロツクに記入してい
る未受取者数により検査し、なければこの事象
ブロツクをメモリ上から消去して、処理を終了
する。

以上の説明では、受取待ちについて同期をとる
例を説明したが、受取要求に同期型と非同期型と
を設け、非同期型では、受取要求が出されたとき
に、まだその事象が発生していない場合、受取待
ち状態に入るのではなく、受取要求元へ直ちに制
御を戻すようにすることも可能である。

〔発明の効果〕

以上説明したように、本発明によれば、事象の
受取側から自由に発生事象を監視したり、その監
視を止めたりすることができ、かつその監視期間
内だ発生した事象を漏れなく受け取ることができ
るようになる。また、事象の通知側は、事象を通
知する時点で、受取側の存在や受取者または受取
者群が誰であるか一意に意識する必要がなく、事
象の種類、内容に依存しない統一した通知を行う
ことができる。従つて、１回の通知で複数の受取
者に発生事象を渡すことができ、通知側および受
取側のプログラム開発が容易になつて生産性が向
上する。また、通知・受取の処理が統一化される
ため、保守性も向上する。

【図面の簡単な説明】

第１図は本発明の基本構成例、第２図は本発明
の一実施例説明図、第３図は本発明の一実施例に
係る監視依頼処理説明図、第４図は本発明の一実
施例に係る受取要求処理説明図、第５図は本発明
の一実施例に係る通知要求処理説明図、第６図は
本発明の一実施例に係る監視解除処理説明図、第
７図は従来方式の例を示す。 図中、１０は処理装置、１１は受取主体、１２
は通知主体、１３は事象管理部、１４は監視依頼
処理部、１５は監視解除処理部、１６は受取要求
処理部、１７は通知要求処理部、１８は事象保存
処理部、１９は事象管理簿、２０は事象キユー、
２１は事象ブロツク、２２は事象保存フアイル、
２３はデイスプレイ、２４はフアイル、２５は
OPNEVENTマクロ、２６はRCVEVENTマク
ロ、２７はCLSEVENTマクロ、２８は
NTFEVENTマクロを表す。

Claims (1)

1. 【特許請求の範囲】 １ 複数の処理単位間で事象の通知および受取を
   行う計算機システムにおける事象通知・受取処理
   方式であつて、 少なくとも受取主体情報、監視事象情報、受取
   待ち情報、発生事象情報を対応させて記憶する領
   域を有する事象管理簿１９と、 事象の監視依頼に対し、上記事象管理簿１９
   に、監視依頼内容を登録する監視依頼処理部１４
   と、 監視依頼後の事象受取要求に対し、上記事象管
   理簿１９を検索し、該当する事象が発生している
   場合に、その事象を要求元へ渡し、該当する事象
   が発生していない場合に、上記事象管理簿１９に
   受取待ち情報を設定する処理を行う受取要求処理
   部１６と、 事象通知要求に対し、上記事象管理簿１９にお
   ける対応する監視依頼内容を検索し、受取待ち情
   報が設定されている場合に、その事象を受取要求
   元へ通知し、受取待ち情報が設定されていない場
   合に、上記事象管理簿１９の発生事象情報欄に通
   知する事象をキユーイングする処理を行う通知要
   求処理部１７と、 事象監視依頼の解除要求に対し、上記事象管理
   簿１９から該当する監視依頼内容を抹消する処理
   を行う監視解除処理部１５とを備えたことを特徴
   とする計算機システムにおける事象通知・受取処
   理方式。