JPS63228335A - 計算機システムにおける事象通知・受取処理方式 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔概要〕 計算機システムにおいて９通知する事象と受取との対応
を管理する事象管理簿を設けると共に。

監視依頼の内容を登録する監視依頼処理部、事象受取に
関する要求を処理する受取要求処理部、事象通知に関す
る要求を処理する通知要求処理部。

監視依頼の解除要求を処理する監視解除処理部を設ける
ことにより、事象の通知側が事象の受は手側を明示的に
意識することなく、必要としている受は手側へ柔軟に事
象を通知できるような統一的な事象の通知・受取を可能
とする。

〔産業上の利用分野〕

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

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

〔従来の技術〕

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

計算機システムにおいて、プログラムの実行中に事象を
検出して、処理の流れとは別のところへその事象を通知
しなければならないことがある。

従来方式では、事象を受は取って処理する相手（以下、
受取者という）を事象の通知側が完全に意識し、密接な
結び付きで通知し、その通知を契機として受取者が処理
を開始するという方法がとられている。そのため、第７
図に示すように、それぞれの目的に応じた通知手段がシ
ステム内に個々に存在していた。

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

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

（ｉ）ある事象を複数の受取者に通知したい場合。

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

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

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

（ｉｖ）新たに通知したい事象がでてきた場合、そのた
めの通知手段を開発しなければならない。そのため、生
産性が向上せず、かつコストかがかる。

例えば、第７図において、プログラムＡに機能追加を行
って、先の事象Ｅとは全く別な種類の新たな事象Ｇをプ
ログラムＦに通知しなければならなくなった場合、新た
な通知方法Ｈを開発しなければならない。

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

（問題点を解決するための手段） 第１図は本発明の基本構成例を示す。

第１図において、１０はＣＰＵおよびメモリ等からなる
処理装置、１１は通知を受は取る受取主体、１２は事象
を通知する通知主体、１３は事象を管理する事象管理部
、１４は事象の監視依頼を処理する監視依頼処理部、１
５は監視依頼の解除要求を処理する監視解除処理部、１
６は事象受取に関する要求を処理する受取要求処理部、
１７は事象通知に関する要求を処理する通知要求処理部
。

１８は事象情報を保存する事象保存処理部、１９は事象
管理簿、２０は発生した事象を記憶する事象キュー、２
１は事象情報を記憶する事象ブロック、２２は事象保存
ファイル、２３はディスプレイ、２４は一般のファイル
、２５は監視依頼を行う０ＰＮＥＶＥＮＴ　（オープン
イベント）マクロ。

２６は受取を要求するＲＣＶＥＶＥＮＴ（レシーブイヘ
ント）マクロ、２７は監視解除を要求するＣＬＳＥＶＥ
ＮＴ　（クローズイベント）マクロ。

２８は通知を要求するＮＴＦＥＶＥＮＴ　（ノーティフ
ァイイベント）マクロを表す。

本発明では、システムで発生する事象情報を。

監視要求単位ごとに管理する事象管理７ｆ１１９が設け
られる。事象管理簿１９は、受取主体１１の識別情報を
記憶する受取主体情ＩＩ欄、監視・受取の対象となる事
象情報を記憶する監視事象情報欄。

受取の条件を記憶する条件欄、受取待ち情報を記憶する
受取待ち情報欄１通知要求があった事象情報を記憶する
発生事象情報欄！欄の記憶領域を有している。

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

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

通知主体１２は１通知したい事象がある場合に。

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

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

〔作用〕

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

一方、事象の通知者である通知主体１２は、事象の種類
、内容に依存しない統一的な通知手段。

即ち、ＮＴＦＥＶＥＮＴマクロ２８によって１発生また
は検出した事象を通知することができる。

第１図の例では５　このとき通知した事象を保存してお
くか否かを指示することができ、事象情報の保存が指示
されている場合には、事象保存処理部１８が起動されて
、所定の事象保存ファイル２２への事象情報の記録がな
される。この事象情報は。

後に事象保存ファイル２２から読み出すことができる。

従って、監視依頼内容に発生した事象の受取を必要とす
る場合には、この事象保存ファイル２２から事象情報を
得ることができる。

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

従って、１つの事象に対し、複数の受取主体１１が、そ
れぞれディスプレイ２３に表示するとか。

ファイル２４に格納するとかいう処理を、必要な時点で
独立に行うことができる。

〔実施例〕

第２図は本発明の詳細な説明図、第３図は本発明の一実
施例に係る監視依頼処理説明図、第４図は本発明の一実
施例に係る受取要求処理説明図。

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

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

通知者Ｎ１が、事象管理部１３に事象Ａの通知を依頼す
ると、事象管理簿１９の検索により、受取者Ｒ１に事象
Ａが通知される。通知者Ｎ２が。

事象管理部１３に事象Ｂの通知を依頼すると、受取者Ｒ
１および受取者Ｒ３に事象Ｂが通知される。

同様に１通知者Ｎ３が、事象管理部１３に事象Ｃの通知
を依闘すると、事象管理簿１９の検索により、受取者Ｒ
２および受取者Ｒ３に事象Ｃが通知される。

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

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

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

第１図に示すＲＣＶＥＶＥＮＴマクロ２６によって、受
取要求処理部１６は第４図に示すように処理する。以下
の説明における番号■〜■は、第４図に示す処理番号■
〜■に対応する。

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

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

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

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

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

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

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

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

■　次にこの事象Ａを欲している受取者を、事象管理Ｗ
１９を検索して探し出す。このとき、監視依顛の事象の
外に、その監視依頼の条件内容もあわせて検査し対象と
なるものを抽出する。

事象Ａを監視依頼している受取者が存在していると（こ
こでは受取者Ｒ１が存在する）２次の処理■ないし処理
■の処理を行った後、さらに処理■から同様に処理を繰
り返して５事象管理簿１９の検索を続ける。事象管理簿
１９の検索が終了した場合、処理■を実行する。

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

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

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

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

その後５処理■へ制御を戻す。

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

第１図に示すＣＬＳＥＶＥＮＴマクロ２７によって、監
視解除処理部１５は第６図に示すように処理する。以下
の説明における番号■〜■は、第６図に示す処理番号■
〜■に対応する。

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

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

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

〔発明の効果〕

以上説明したように１本発明によれば、事象の受取側か
ら自由に発生事象を監視したり、その監視を止めたりす
ることができ、かつその監視期間内で発生した事象を漏
れな（受は取ることができるようになる。また、事象の
通知側は、事象を通知する時点で、受取側の存在や受取
者または受取者群が誰であるかを一意に意識する必要が
なく。

事象の種類、内容に依存しない統一した通知を行うこと
ができる。従って、１回の通知で複数の受取者に発生事
象を渡すことができ２通知側および受取側のプログラム
開発が容易になって生産性が向上する。また１通知・受
取の処理が統一化されるため、保守性も向上する。

【図面の簡単な説明】

第１図は本発明の基本構成例、第２図は本発明の詳細な
説明図、第３図は本発明の一実施例に係る監視依頼処理
説明図、第４図は本発明の一実施例に係る受取要求処理
説明図、第５図は本発明の一実施例に係る通知要求処理
説明図、第６図は本発明の一実施例に係る監視解除処理
説明図、第７図は従来方式の例を示す。 図中、１０は処理装置、１１は受取主体２１２は通知主
体、１３は事象管理部、１４は監視依頼処理部、１５は
監視解除処理部、１６は受取要求処理部、１７は通知要
求処理部、１８は事象保存処理部、１９は事象管理簿、
２０は事象キュー。 ２１は事象ブロック、２２は事象保存ファイル。 ２３はディスプレイ、２４はファイル、２５は０ＰＮＥ
ＶＥＮＴ？クロ、２６はＲＣＶＥＶＥＮＴマクロ、２７
はＣＬＳＥｖＥＮＴマクロ、２８はＮＴＦＥＶＥＮＴマ
クロを表す。

Claims (1)

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