JPH0362155A - エンティティ管理システムにおける情報管理システム - Google Patents

Abstract

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

Description

【発明の詳細な説明】 （産業上の利用分野） 本発明は一般に複合システムの管理の分野に関するもの
であり、更に詳細には分布ディジタル・データ処理シス
テムのような複合システムを管理する装置に関する。

（従来の技術〉 ディジタル・データ処理システム、またはコンピュータ
、が小形に且つ廉価になるにつれて、個々のコンピュー
タが個人や小グループによって使われている。データの
分配、ユーザ間の通信、および個人が頻繁には使用しな
い資源に関連する経済性を高めるため、コンピュータは
、各ユーザが直接使用するコンピュータの他に、たとえ
ば、システム内の多数のユーザによりアクセスされ、使
用され、且つ更新されることがある大量のデータを格納
し、これによりデータの分配を容易にするサーバを含む
、通信リンクを通して伝達されるメツセージにより通信
する回線網に接ぎ込まれて来ている。サーバはプリンタ
、電気通信リンクなどを制御することもできる。

その他に、サーバは、データベースの探索や分類などの
ような専門的な計算サービスを行うことができる。各種
コンピュータ、これは依頼者と言う、およびサーバは通
信リンクにより相互に接続され、分布システムを構成す
る各種コンピュータおよびサーバの間でメツセージを転
送できるようにしている。

（発明の概要） 本発明は、複数のコンピュータが、たとえば、ローカル
・エリア・ネットワークを通して通信する分布ディジタ
ル・データ処理システムのような複合システムを制御し
、監視する新しい、改良された制御装置を提供するもの
である。

手短かに要約すれば、この制御装置は一つ以上の提示モ
ジュール、機能モジュール、およびカーネル手段を通し
てオペレータからの命令に応じて発生した要求を処理し
、オ、ペレータに応答して表示するアクセス・モジュー
ル、を備えている。提示モジュールはオペレータからの
命令の受領、およびこれに対する応答の提示を含むオペ
レータ・インターフェース機能を取り扱う、オペレータ
からの命令に応じて、提示モジュールは要求を発生する
。カーネル手段は要求を受取り、これを更に処理のため
機能モジュールに伝える。ｌｌｌモモジュール要求の処
理と関連して一般機能動作を取扱う、要求に応じて、ｍ
能モジュールは一つ以上の要求（時には便宜のため以下
では従属要求と呼ぶことがある）を発生し、これは処理
のためカーネル手段へ、または他の機能モジュールへ転
送される。カーネル手段は受取った従属要求を処理のた
めアクセス・モジュールに伝える。アクセス・モジエー
ルは複合システムを構成するエンティティと関連して原
始的な動作を処理する。

一般に本発明は、時間パラメータを指定する命令に応じ
てエンティティの集団について管理情報を検索するシス
テムであって、エンティティが集団とインターフェース
して主要情報処理機能を制御すると共にエンティティが
更にシステムにインターフエースして管理情報にアクセ
スすることができるようになっていることを特徴とする
。システムは、管理情報に関連する、各記録が関連時間
の指示を含んでいる、記録を備えている記憶装置、およ
び命令に応じて記録に含まれている管理情報を検索する
か、またはエンティティから管理情報にアクセスするも
のであって、時間スケジュールにしたがって恐らく複数
回命令に対応する一続きの従属アクセスまたは検索を恐
らく発するスケジュールを備えた情報管理器、から構成
されている。

一実施例においては、システムは所定のスケジュールに
応じて新しい管理情報に定期的にアクセスし、これを記
録に格納する歴史データ記録器を備えている。システム
は少なくとも一つの所要時間範囲を指定する命令に応答
するようになっており、時間範囲は恐らく過去、現在、
および未来の時間を含んでおり、情報管理器は、可能な
場合に、記録に含まれている管理情報を検索することに
より、その他の場合、エンティティから指定時間範囲に
関係する情報にアクセスすることにより命令を満足する
。Ｍ報管理器は、時間範囲の期間中は記録に格納されて
いる記録を検索することにより、その他の場合にはエン
ティティから情報にアクセスすることにより、指定時刻
より前のすべての時間を含む時間範囲を持つ命令を指定
するように構成されている。情報管理器はまた前記エン
ティティから管理情報に直ちにアクセスすることにより
命令を満足するようにも構成されている。

（全般の説明） 第１Ａ図は複合システムの状態および条件を制御し、監
視する、本発明にしたがって構成した装置の機能ブロッ
ク図である。（複合システムそれ自身は図示していない
、）予備的に第１Ａ図に示す装置により制御される複合
システムの−・例は、ネットワークを通して伝達される
メツセージにより通信する、コンピュータ、端末、端末
サーバ、および他の構成要素を含む複数のノードから成
る、分布ディジタル・データ処理システムを備えている
。このようようなディジタル・データ処理システムの一
例は米国特許出願に記されている。ただし、第１Ａ図に
示す制御装置は分布ディジタル・データ処理システムの
制御に限定されるものではなく多数の多様な形式の複合
システムを１ｌＩｖＩｌするのに使用することができる
ことがわかるであろう。

このような複合システムは、特に複合システムの状態お
よび能力が絶えず変っているため管理するよう促してい
る。それ故、それが提供する管理設備や管理機能もシス
テムの新しい管理要求に適応するように変らなければな
らない、後に一層詳しく説明するように、第１Ａ図の装
置は拡張性の特徴を備えており、これにより装置を複合
システムに効率良く適応するよう変更することができる
。

この文書の目的で、複合システムの構成要素をエンティ
ティと呼ぶことにする。エンティティをクラスおよび段
階に関して説明する。エンティティのクラスは特定の形
式のエンティティを規定する。たとえば、一つのクラス
には所定の売り主がらのローカル・エリア・ネットワー
ク・ブリッジのすべてが含まれる。各エンティティはク
ラスのメンバーであり、そのクラスの段階を形成してい
る。

第１Ａ図を参照すれば、制御装置は提示モジュールＩＯ
Ａからｌ０Ｋ（全体として参照数字１０で区別する）、
機能モジュールＩＩＡからＩＩＭ（全般的に参照数字１
１で区別する）、およびアクセス・モジュール１２Ａか
ら１２Ｍ（全般的に参照数字１２で区別する）を含む数
種の制御モジュールを備えている。提示モジュール１０
は一般にユーザが、システム・オペレータにより使用さ
れる端末の制御を含む、複合システムの制御を行うため
の、ユーザ・インターフェースとなる。各Ｉ！能モモジ
ュール１は一般に一つのクラスの機能と関連して管理制
御および監視を行う、各アクセス・モジュール１２は一
般に、制御システム内で、一つのクラスの制御可能なエ
ンティティに属するセットで、特定の形式の制御可能な
エンティティに対する管理制御を行う、提示モジュール
１０はカーネル１３．１４の提示・機能の局面（今後単
に提示・機能カーネル１３と呼ぶ）を通して機能モジュ
ール１４と通信し、機能モジュール１１はカーネル１３
．１４の機能・アクセスの局面（今後単に機能・アクセ
ス・カーネル１４と呼ぶ〉を通してアクセス・モジュー
ルと通信する。

制御モジュール１０．１１．１２から要求される機能は
管理される複合システムのトポロジーによって幅広く変
ることがある。それ故、適応性および拡張性のある管理
を行うように、制御モジュール１０．１１．１２を装置
に対して動的に加除を行い、装置を特定の複合システム
のトポロジーに、およびそのトポロジーの変化に適応さ
せることができる。

更に適応性および拡張性の目的に向けて、制御モジュー
ル１０．１１．１２は複合システムの管理において行う
べき任務に対する「労働師団」を形成する。この方法で
、たとえば、分布データ処理システムの管理プロトコル
に関連する任務を、たとえば、管理情報をユーザに表示
することに関連する任務から切離すことができる。

Ａ、提示モジュール 更に詳細に述べれば、提示モジュール１ｏは提示す−ビ
スを行うものであって、これは、たとえば、システム・
オペレータが各種機能モジュール１１およびアクセス・
モジュール１２を制御し、複合システム内の各種エンテ
ィティを制御し且つ監視するのに使用することができる
、ビデオ表示端末、パーソナル・コンピュータ、または
コンピュータ・ワークステーションのような、ユーザ・
インターフェースの支援装置から構成することができる
。提示す−ビスは第１Ａ図に示したシステムにより管理
される管理ａ能またはエンティティと無関係に必要であ
り、したがって、管理機能またはエンティティの性質に
関係なく提供される。

各オペレータ・インターフェースまたは端末は複数の提
示モジュールで制御することができる。各種提示モジュ
ール１０は、たとえば、肖像、メニュー、グラフィック
ス、および命令行を表示し精査する支援装置のような細
目を含む、オペレータ・インターフェースの多様な局面
を制御する。他の提示モジュール１０はいろいろな形式
のグラフィック表示、たとえば、オペレータに対して端
末画面上に表示すべきヒストグラム、バー図表、パイ図
表、または他の形式の絵画式表現、に関する特定の出力
支援を行う、更に他の提示モジュール１０は、オペレー
タが命令行により入れた肖像、メニュー、グラフィック
ス、または命令によって注記することができる、管理要
求を提示・機能カーネル１３に、および提示・機能カー
ネル１３からの管理情報をオペレータが使用するビデオ
表示端末に、表示するため転送する。

Ｂ０機機能モジュー ル能モジュール１１は第１Ａ図に示す制御装置により行
われる特定の管理アプリケーションに関連し、これを支
援する。管理アプリケーションは提示モジュール１０が
行う提示す−ビス（提示モジュール１０がオペレータに
制御管理におり行われる管理アプリケーションについて
知らせる範囲以外の）、および制御管理により管理され
ている複合システムを構成している特定のエンティティ
とは無関係に存在する。

機能モジュール１１が行うことができる管理アグリゲー
ションは、たとえば、分布データ伝達システムの通信負
荷倉分析する。このような分析を行うのに、機能モジュ
ールは分布データ伝達システムの幾つかのエンティティ
から送られたパケットの数、およびバイトの数のような
通信データにアクセスする０機能モジュールは次に情報
を平均パケット・サイズおよび伝達システムの通信資源
の利用率のようなより高いレベルの情報と照合する。こ
の情報は次にユーザに送られるか、または他の管理アプ
リケーションの実行時に他の機能モジュールが利用でき
るようにする。

上の例でわかるように、機能モジュールは、データ照合
または相関サービスの形で、複合システムから利用でき
る管理情報に「価値を付加する」。

加えて、機能モジュールは他の機能モジュールが作り出
したデータを活用して複合システムの管理について高レ
ベルのサービスを行う。

分布ディジタル・データ処理システムを制御する一つの
特定の制御装置においては、一つの機能モジュール１１
が、たとえば、ネットワークのトボロジーを管理し、そ
のトポロジーを提示モジュール１０を通してオペレータ
に示す。

他の機能モジュール１１は、たとえば、分布ディジタル
・データ処理システムの構成、すなわち、エンティティ
の各種段階およびその相互関係、を規定し、ノードおよ
び他のエンティティ段階をネットワークに対して加除で
きるようにしてオペレータがネットワークの構成を制御
できるようにし、ノードの各種ユーザによるアクセス権
を変更し、また構成（または段階）データベースを維持
し、これによりオペレータが常時ネットワークの構成へ
の変更をきめることができる、構成機能モジュールを備
えることができる。

制御装置内の他の機能モジュール１１は、たとえば、分
布ディジタル・データ処理システムに所定の事象が発生
したことを示す各種警報を制御することができる。この
警報機能モジュール１１は分布ディジタル・データ処理
システムの各種エンティティの状態および条件を監視し
、オペレータに警報指示を発生するが、適切な提示モジ
ュール１０が、所定の値を有する状Ｂまたは条件に応じ
てそのオペレータに忠告する。

更に他のｌ！能モモジュール１１、たとえば、分布ディ
ジタル・データ処理システム内にエンティティの領域を
確定し、オペレータによる制＃または監視の権限を制限
するかまたはオペレータによる制御または監視を簡単に
することができる。

他の機能モジュール１１は、たとえば、歴史データ記録
器機能モジュール１１として動作し、複合システム内の
各種エンティティに定期的にボールして特定の時刻にお
けるその値を決定し、時間および数値のデータベースを
確立、保守し、利用統計を作り易くすることができる。

更に他の機能モジュール１１は複合システムの特定の局
面を制御することができないが、代わりに通り抜けとし
て動作し、オペレータが複合システムの原始的機能を直
接アクセス・モジュール１２を通して制御または監視す
ることができるようにする。

管理アプリケーションには、特定の順序で多数のアクセ
ス・モジュール１２のサービスおよび動作が必要となる
ことがあり、管理アプリケーションを支援する機能モジ
ュール１１が管理アプリケーションを遂行するのに必要
な各種アクセス・モジュール１２による動作のシーケン
スを調整する。

その他、一つの機能モジュール１１により提供される管
理アプリケーションは制御装置内の別の機能モジュール
１１のアプリケーションを必要とすることがあり、これ
によりその一つの機能モジュールも調整される。

機能モジュール１１は、最初、提示モジュール１０によ
り得られたオペレータにより入れられた管理要求に応じ
て、提示・機能カーネル１３により呼出される０機能モ
ジュール１１は他の機能モジュール１１から直接受取っ
た要求によっても呼出される。その他に、機能モジュー
ル１１はアクセス・モジュール１２よる処理の要求を発
生することができる。

Ｃ，アクセス・モジュール アクセス・モジュール１２は第１Ａ図に示す制御装置に
より管理される複合システムを構成する各種エンティテ
ィと関連して制御装置により提供される各種の原始的管
理動作に関連しており、これを支援する。たとえば、分
布ディジタル・データ処理システムにおいて、エンティ
ティは、分布ディジタル・データ処理システムのノード
を構成する事ができる、各種コンピュータ、ディスクお
よびテープ記憶装置、ルータ（ｒｏｕｔｅｒ）などを含
む、システムの各種ハードウェア構成要素ばかりではな
く、仮想回路、データベースなどを含むソフトウェア構
成要素をも備えることができる。

アクセス・モジュール１２は機能モジュール１１からの
要求に応じて機能・アクセス・カーネル１４により呼出
される。

分布ディジタル・データ処理システムを制御し、監視す
るアクセス・モジュール１２はノードにより使用される
メツセージ転送プロトコルにより幾つかの異なる形式の
ノードまたは異なるレベルを制御してメツセージを発生
し、転送することができる、一つのアクセス・モジュー
ル１２は、たとえば、二つのローカル・エリア・ネット
ワークを結び付けるブリッジの各種部分の状態を制御し
、監視することができ、メツセージを二つのローカル・
エリア・ネットワークのノード間を伝えることができる
ようにする。このようなアクセス・モジュール１２は、
たとえば、ブリッジを初期設定し、これの動作を開始で
きるようにし、ブリッジを無効にし、その端から端まで
の動作を監視し、所持しているバッファを通るメツセー
ジの数を確認し、システム内で効果的に動作するに充分
なバッファを所持しているか否かを確認することができ
る。

他のアクセス・モジュール１２は分布ディジタル・デー
タ処理システムの各種ノードのメツセージ発生・複号部
骨の動作、仮想回路、ノード間に確立されたセツション
および他のリンク、それらに関する活動、非活動を示す
各種タイマおよびカウンタなど、を制御し、監視するこ
とができる。

同様に、他のアクセス・モジュール１２は、各種メツセ
ージ伝達受領カウンタ、伝達受領タイマなどを含む、ネ
ットワークを通るメツセージの実、際の伝達および受領
を制御する、ノードのネットワク層部分動作を制御し、
監視することができる。

各種タイマおよびカウンタの値を監視する他に、タイマ
およびカウンタの双方を制御するアクセス・モジュール
１２を使用して、一つのノードが他のデフォルトおよび
動作のパラメータを保持し、確立することができる、同
時発生の仮想回路およびセツションの数に関する限界を
確定することもできる。

特定の実施例では、アクセス・モジュールはエサーネッ
トＬＡＮブリッジでの管理機能へのアクセス接続性試＠
またはＩＥＥＥ８０２１１能エサ−ネット・ステーショ
ン、エサ−ネット中継器におけるボート分画制御・チエ
ツク機能、またはＦＤＤＩエンティティにおける管理ａ
能を用意することができる。加えて、アクセス・モジュ
ールは、マサチューセッツ州メイナードのディジタル・
エクィップメント社が公表したＤＥＣｎｅｔ　　Ｐｈａ
ｓｅ１９またはＰｈａｓｅＶノード、またはＤＥＣ端末
サーバでの管理支援装置にアクセスするため設けること
ができる。

Ｄ、要求 制御モジュール１０．１１．１２は互いにおよびユーザ
と要求を通して対話する。要求には二つの一般形式があ
る。一つの要求は、たとえば、複合システム内に何かを
生じさせることができる。

すなわち、複合システムの状態または条件を変えさせる
ことができる。このような要求を処理するにあたり、一
つ以上のアセス・モジュール１２が管理されている複合
システムの一つ以上のエンティティの状態または条件を
変える所定の動作を行う、このような要求を処理するア
クセス・モジュール１２は要求の状態を示す状態情報を
発生し、これを機能・アクセス・カーネル１４に戻す。

代りに、要求はシステムの一つ以上のエンティティの状
態または条件に関して情報を請求することができ、エン
ティティが要求により識別される。

このような要求を処理する際、一つ以上のアクセス・モ
ジュール１２がエンティティの状ａｔたは条件を決定し
、その視認情報を機能・アクセス・カーネル１４に戻す
、他の場合には、制御装置に（歴史データ記録器機能モ
ジュールなどにより〉格納されている情報を使用して要
求を満足させることができる。

その他に、要求は画形式のものであってもよい。

すなわち、要求は一つ以上のエンティティの状態または
条件を変えることができ、変更後のエンティティの状態
または条件に関する情報を要求することもできる。この
ような要求を処理するにあたり、アクセス・モジュール
１２は、可能ならば、変更を生じさせ、要求の状態に関
する状態情報の他に、エンティティの状態または条件に
関する情報をも戻す。

要求は端末提示装置でのオペレータの行為に応じて発生
することができる。その場合には、端末を制御する提示
モジュール１０が要求を発生し、これを提示・機能カー
ネル１３に伝達する。加えて、要求は適切なＩｌｌモモ
ジュール１１より直接発生することができる。たとえば
、歴史データ記録器として動作する機能モジュール１１
は複合システムのそれぞれのエンティティの状態または
条件を定期的に確認する要求を発生して、オペレータの
必要に応じて後の処理に使用する歴史的データベースに
記憶させる。

Ｅ、カーネル カーネル１３．１４は情報管理器１５．２０（今後簡単
に情報管理器１５または情報管理器２０と言うが、一つ
および同じ情報管理器を形成している）、ディスパッチ
ャ１６．２１（今後単にディスパッチャ１６またはディ
スパッチャ２１と言うが、一つおよびおなしディスパッ
チャを形成している〉、およびデータ記憶装置要素１７
．２２（今後単にデータ記憶装置１７またはデータ記憶
装置２２と言うが、以下説明するように一つおよび同じ
データ記憶装置要素を形成している）を含む、幾つかの
要素を備えている。

Ｆ、データ記憶装置 データ記憶装置１７．２２は、格納するデータの形式お
よび量にしたがって、ディスパッチャ・データ構造を備
えた一つ以上のＲＡＭ、または一つ以上の固定ディスク
・ドライブ、または他の記憶装置手段を備えることがで
きる。その他、興なる形式のデータを後にカーネルが使
用するための各種記憶装置手段に格納することができ、
これらの手段をすべて一つのデータ記憶装置要素１７．
２２によって図表的に表しである。

第１Ｂ図を参照すると、一実施例において、データ記憶
装置要素１７．２２は複合システムを構成する各種エン
ティティの有無および状態に関する情報を各時点で、特
に、アクセス・モジュール１０により制御される各種エ
ンティティの状態および条件に関する所定の情報を歴史
データ記録器機能モジュール１１によって得られたまま
に、維持する。これは歴史データベース２６に格納され
る。　他の情報もデータ記憶装置要素１７．２２に格納
することができる。特に、上に説明したように、構成モ
ジュールは複合システム内にエンティティ段階が存在す
ることを示す構成データベース２３を形成することがで
きる。領域モジュールはユーザの制御範囲を限定するの
に使用するエンティティの領域を記述するデータベース
２５を格納することができる０代わりに、領域情報を構
成データベースの要素として格納することができる。

また、警報モジュールは警報規則ベース２４を使用して
複合システム内の警報状態を確認することができる。

制御装置内の個々のモジュールに関係する他の情報も記
憶装置要素１７．２２に保持することができる。たとえ
ば、以下に詳記するとおり、ディスパッチャ１６．２１
が使用するディスバッチ・テーブル２８はモジュールの
位置、およびディスパッチャがサービスする動作、エン
ティティ、および属性を格納することができる。その他
、制御装置は複合システム内のエンティティの各種クラ
スのそれぞれの属性、指令、およびサブエンティティを
格納するデータ辞書２７を保持することができる。この
後者の情報は、たとえば、ユーザからの要求を処理し、
あるいはメニューを発生してユーザ要求をプロンプトす
るのに使用することができる。

Ｇ、情報管理器 第１Ａ図を参照して、後に詳細に説明するように、情報
管理器１５が呈示モジュール１０から、データ記憶装置
要素１７の中の情報を使用して応答することができる要
求を受取ると、情報管理器１５は要求を横取りして要求
に対する応答を発生し、これを適切な提示モジュール１
０に伝えて要求を発生したオペレータに表示する。情報
管理器１５が要求に応答することができなければ、管理
器は要求が現在の時間に関係するのか未来の時間に関係
するのかを判断する。すなわち、情報管理器１５は要求
を直ちに処理すべきかまたは将来の特定の時間に予定を
組むかを判断する。適切な時刻に、即刻であってもまた
は予定の時刻であっても、情報管理器１５は要求をディ
スパッチャ１６に転送する。要求の性質から、ディスパ
ッチャ１６は要求を送るべき機能モジュール１１を識別
し、要求をその機能モジュール１１に転送する。

ディスパッチャ１６から要求を受取ったことに応じて、
機能モジュール１１は要求を処理し始める。

機能モジュール１１は、要求に応答して、それぞれ要求
で表される、今後従属要求と呼ぶ、一つ以上の動作を開
始し、これを池の機能モジュール１１または機能アクセ
ス・カーネル１４に伝える。

従属要求のすべてに対する応答を受取ると、機能モジュ
ール１１は応答を発生し、これをディスパッチャ１６に
伝達する。ディスパッチャ１６は応答を様式化して、情
報管理器１５を通して適切な提示モジュール１０に伝達
し、オペレータに表示する。

カーネル１４の機能・アクセスの局面は情報管理器２０
、ディスパッチャ２１、およびデータ記憶装置要素２２
を備えている０機能モジュール１１からの、機能・アク
セス・カーネル１４に向けられる従属要求は最初情報管
理器２０によって受取られる。データ記憶装置要素２２
も、歴史データ記録器機能モジュール１１から発生した
、複合システムの各時点における状態に関する情報を、
特に、アクセス・モジュール１０により制御される各種
エンティティの状態および条件に関する所定の情報を備
えることができる。

情報管理器２０が機能モジュール１１から、データ記憶
装置要素２２の中の情報を使用して応答することができ
る従属要求を受けとると、管理器は要求を横取りして従
属要求の発生に対する応答を発生し、これを従属要求の
発生元であるＩＮＮモモジュール１１伝達する。情報管
理器２０が機能モジュール１１からの従属要求に応答す
ることがでなければ、要求が現在の時間に関係するかま
たは将来の時間に関係するかを判断する。すなわち、情
報管理器２０は要求を直ちに処理すべきかまたは将来の
特定の時刻に予定を組むべきかを判断する。適切な時刻
に、即刻であろうとまたは予定の時刻であろうと、情報
管理器２０は従属要求をディスパッチャ２１に転送する
。従属要求を情報管理器２０から受けとったことに応じ
て、ディスパッチャ２１は従属要求を伝えるべきアクセ
ス・モジュール１２を識別し、従属要求をこのアクセス
・モジュール１２に転送する。

ディスパッチャ２１から従属要求を受取ったことに応答
して、アクセス・モジュール１２は要求の処理を開始す
る。アクセス・モジュール１２は、従属要求に応じて、
制御される複合システムのエンティティに関連する一つ
以上の動作を開始することができる。従属要求がアクセ
ス・モジュール１２にエンティティの状態または条件を
変えるように要求していれば、アクセス・モジュール１
２はそうしようとしてその試みの状態、すなわち、たと
えば、変更が成功であったか、不成功であったかまたは
部分的に成功であったか、を示す状態情報を含んだ応答
を発生する。他方、従属要求がアクセス・モジュール１
２にエンティティの状態または条件を識別するように要
求していれば、アクセス・モジュール１２はエンティテ
ィの状態または条件を示す応答を発生する。最後に、従
属要求がアクセス・モジュール１２に上記の両方を行う
ように要求していれば、アクセス・モジュール１２はエ
ンティティの状態または条件を変えようとし、試行の状
態、およびエンティティの新しい状態または条件をも示
す応答を発生する。どんな場合でも、アクセス・モジュ
ール１２は応答をディスバッチｙ２１に伝え、ディスパ
ッチャ２１はこれを要求を発生した機能モジュール１１
に転送する。Ｉｌｌモモジュール１１、ディスパッチャ
１６からの要求に対するその応答、または他の機能モジ
ュール１１からの従属要求に対するその応答、のいずれ
か該当するものを様式化するにあたり、アクセス・モジ
ュール１２からの応答を使用する。

機能モジュール１１は、従属要求を他の機能モジュール
１１から受取ると、これをデスパヴチャ２１からの要求
を処理すると同じ方法で処理する。

利点 第１Ａ図に示す制御装置には多数の利点がある。

制御装置は、チェーンに沿う各要素が要求を次の要素に
送る前に処理しようとする、処理チェーンを本質的に形
成している。したがって、情報管理器１５．２０が、関
連するデータ記憶装置１７゜２２の内容に基いて、更に
チェーンを下った他の要素に更に処理する必要なしに、
要求を処理することができれば、情報管理器１５．２０
はそのようにする。

更に、制御装置は拡張可能であるから、別の提示モジュ
ールｉ　ｏ、　＊能モジュール１１、およびアクセス・
モジュール１２を、以下に説明するよに、制御装置の構
造を変更することなく、容易に追加することができる０
機能モジエール１１およびアクセス・モジュール１２の
追加は登録手順の方法によって行うが、これについては
以下で第５図と関連して説明する。モジュール１０．１
１または１２の追加または削除は、以下に説明するよう
に、データ記憶装置要素１７．２２の一定のデータ構造
、および第５図に示すように、提示モジュール１０によ
り保持されている他のデータ劃りの内容を単に修正する
ことにより行うことができる。

その他に、制御装置がモジュール式で拡張可能な性質の
ため、制御装置それ自体の管理が容易になる。複合シス
テムに対して管理指令を発するのに使用される同じディ
スパッチおよび要求の模範を管理モジュールそれ自身へ
の命令を発生するのにも使用することができる。これに
より、制御装置自身を管理する別の管理アプリケーショ
ンの必要が無くなる。

また、モジュールのａｍが標準のフォーマットで指定さ
れ、全体として制御装置に利用できるので、制御装置は
モジュールに対する完全なユーザ・インターフェース支
援装置となり、モジュール設計者を各モジュールに対し
てユーザ・インターフェースを支援するという重荷から
解放する。この種の「自動」ユーザ・インターフェース
支援装置は、使用している管理モジュールの源または性
質に関係なく、ユーザ・インターフェースに対する−様
な見え方および感じを保証している。

制御装置を分布ディジタル・データ処理システムの制御
に使用する場合、ＩＩＪｉＸｌ装置は、その各種要素を
含めて、分布ディジタル・データ処理システムを構成す
る各種ノードおよびコンピュータにより処理される複数
のルーチンを備えることができる。すなわち、コンピュ
ータ設備は、制御される分布ディジタル・データ処理シ
ステムを構成するものの他に、分布ディジタル・データ
処理システムを、制御する制御装置を構成するモジュー
ルを処理する必要はない、従来の手順呼出し機構、プロ
セス間通信機構、およびノード間通信機構を使用して、
要求、従属要求、および応答を含む通信を、同じプロセ
スの異なる部分に、同じノードの異なるプロセスに、及
び異なるノードに、存在することがある制御装置の各部
分の間で転送することができる。モジュールが同じノー
ドの、または異なるノードの異なるプロセスに存在する
場合には、第６図に示す、以下に説明する、プロセス間
およびノード間の各通信機構が、要求および従属要求の
他に応答をも、各種プロセスおよびノードの間で転送す
るのに使用される。

１、エンティティ・モデル 先に進む前に、第１Ａ図に示す制御装置と、制御されて
いる複合システムとの間の関係を更に説明しておくこと
が役に立つであろう、特に、第２Ａ図を参照すれば、制
御装置は、提示モジュール１０のすべてを備えている指
令器３５、機能モジュール１１、およびアクセル・モジ
ュール１２を、カーネル１３．１４と共に備えている。

複合システムは一つ以上のエンティティ３６を備えてい
る。各エンティティ３６はサービス要素３１、管理イン
ターフェース３０およびサービス・インターフェース３
３を備えている。管理インターフェースはエージェント
３４を通してサービス要素を制御し、監視する。サービ
ス要素はエンティティ３６の実際に管理される部分であ
り、エンティティの主要ａａまたは機能を行う、すなわ
ち、サービス要素３１は分布ディジタル・データ処理シ
ステムの文脈内で必要となるエンティティの機能を行う
、たとえば、エンティティがネットワークを通してノー
ドに対して通信を行えば、サービス要素３１は通信を行
う。

上に注記したとおり、サービス要素３１は、管理インタ
ーフェース３０およびサービス・インク−フェース３３
を通して、指令器と、特にアクセル・モジュール１２と
、通信するエージェントを通して管理される。管理イン
ターフェース３０を通して通信することによりサービス
要素３１の開閉およびその初期設定が容易になり、また
指令器３５がエンティティ３６の動作状態を確認するこ
とができる。サービス・インターフェース３３を通して
通信することにより指令器３５がサービス要素３１を制
御し、監視することができる。そうでない場合には、こ
れは、たとえば、エンティティ３６を制御する文脈で通
信を行うか、またはエンティティ３６を監視する文脈で
カウンタの値を確認する、エンティティ３６の場合の通
信パラメータのような所定の属性の条件を確定すること
によって行われる。

エンティティの管理の特徴はそれが支援する指令、およ
びその属性にあるが、これらは、広く、その機能および
制御に関係すると共に指令に関係しているパラメータで
ある。たとえば、エンティティがデータ・パケットを分
布ディジタル・データ処理ネットワークを通して通信す
るルータの場合には、ルータの属性は伝達されるパケッ
トの数、および伝達されるバイトの数を含むことができ
る。

エンティティがモデムである場合には、属性はモデムの
動作に関連するカウンタおよび状態レジスタを含むこと
ができる。指令の例には、属性値を検索する５ＨＯＷ、
および属性値を修正するＳＥＴがある。

サービス・インターフェースはエンティティの機能に関
係し、管理インターフェースはエージェントの動作に関
係している。サービス・インターフェースを通してアク
セスされる指令及び属性はエンティティの機能を特徴づ
けるが、管理インターフェースを通してアクセスされる
指令及び属性はエンティティの制御および監視を特徴づ
ける。

二つのインターフェースの役割を明らかにし、上のモデ
ルを特定のエンティティに適用する仕方の例を示すため
、制御可能なエンティティ、モデム、を考える。モデム
は、ボーレート、回線選択、および電源スイツチ設定の
ような、幾つかの機能属性を備えることができる。その
他に、モデムは、その回線の利用率および最後の自己試
験以後経過した時間のような、幾つかの管理属性を備え
ることができる。ボーレート、回線選択、および電源ス
ィッチの設定はモデムの即時動作に関係し、それ自体で
サービス・インターフェースを通してアクセスすること
ができる０回線利用率およびモデムの最後の自己試験か
ら全般的動作までの経過時間、およびそれ自身は管理イ
ンターフェースを通してアクセスされる。

上記の例を洗練するには、提示モジュールが、提示装置
に管理情報を提示している間、情報の提示が提示装置の
主要サービスであるためサービス・インターフェースを
使用するということに注意する。しかし、制御装置のア
クセル・モジュールもたとえばそれがオンになっていれ
ばそれをポーリングして決定することにより、提示装置
を管理することができる。

上に説明した属性の他に、エンティティに関係はするが
それ自体としてはエンティティにより格納されない、他
の「擬似属性」がある、１１似属性は一般にエンティテ
ィ・モデルの説明に必要になるがエンティティからは供
給されない属性である。

−例はエンティティにより供給される属性ＩＭＰＬＥＭ
ＥＮＴＡＴＩＯＮ　　ＴＹＰＥおよびＶＥＲ８ＩＯＮの
合成であるＩＭＰＬＥＭＥＮＴＡＴＩＯＮ、およびエン
ティティのＣＲＥＡＴＩＯＮＴＩＭＥである。擬似属性
はエンティテのアクセスに責任があるアクセス・モジュ
ールにより維持される。

この点でエンティティ・モデルはエンティティの指令お
よび属性を記述する一般的方法であって、エンティティ
それ自体の内部の構造を意味するものではないことに注
意するのは価値がある。エンティティ・モデルは制御装
置が任意のエンティティの動作および属性を一貫して参
照することができるようにする道具である。任意のエン
ティティを「差し込んで」第１Ａ図の制御装置により（
１）エンティティ・モデルと矛盾せずにこれを記述し、
（２）適切なアクセス・モジュールを実現し、（３）ア
クセス・モジュールを制御装置に差込むく登録する）こ
とにより管理することができる。

Ｊ、管理モジュールの管理 上に注記したとおり、分布ディジタル・データ処理シス
テムを制御する制御装置では、各種提示モジュール１０
、機能モジュール１１、アクセス・モジュール１２、お
よびカーネル１３．１４が分布ディジタル・データ処理
システムを構成する各種ノードにより処理される。その
場合に、各種モジュール１０，１１、および１２、およ
びカーネル１３．１４が複合システム内のエンティティ
を形成しており、上述のように、他のエンティティと同
じ方法で制御される。複合システムに管理指令を発する
のに使用されるディスパッチおよび要求の模範も管理モ
ジュールそれ自身に命令を発するのに使用することがで
きる。以下のディスパッチャ仕様かられかるように、複
合システムを管理する管理ルーチンの他に、各モジュー
ルはモジュールの内部属性を操作する自己管理ルーチン
を備えている。内部および外部の両ルーチンとも要求構
文を使用する要求によりアクセスすることができる。そ
れゆえ、複合システムを管理する能力が新しい制御モジ
ュールを追加することにより増大するにつれて、制御装
置を管理する能力が同様に増大する。

明細説明 Ａ、管理モジュールの構造 １、概観 第２Ｂ図を参照すれば、一つの特定の実施例において、
管理モジュールの構造がモジュールにより提供される管
理機能を実現する実行可能コード３８を備えている。特
に、アクセス・モジュールの場合、実行可能コードはア
クセル・モジュールによりサービスされるエンティティ
・クラスに対するアクセス・プロトコルを備えている０
機能モジュールの場合、実行可能コードはモジュールに
より提供されるもっと高いレベルの機能を計算する支持
を含んでいる。提示モジュールの場合、実行可能コード
は提示モジュールにより支援される提示装置に対するイ
ンターフェース・プロトコルを備えている。

モジュールはモジュールの機能に関係する各種の読出し
専用および読出し／書込みの変数を格納する専有記憶装
置を要求することができる。この記憶装置は割当て領域
３２としてモジュールに設けられている。この記憶装置
は、例えば、提示モジュールが精査テーブルまたは提示
フオームのデータを格納するのに、またはアクセス・モ
ジュールがワイルドカード要求によるパスワード情報を
格納するのに、使用することができる（下記を参照）。

アクセス・モジュールにより提供される各種手順のアク
セス点はディスパッチ・エンティティ３９Ａおよび３９
Ｂのポインタにより示される。

後に更に完全に説明するように、ディスパッチ・エンテ
ィティはカーネル記憶装置１７．２２に格納されている
ディスパッチ・テーブルに融合されており、モジュール
が支援する各種手順の位置を定めるのに使用される。第
２Ｂ図に示すように、ディスパッチ・ポインタ３９Ａは
複合システムに対して管理サービスを行うモジュール内
の手順に関係しているが、ディスパッチ・ポインタ３９
Ｂはモジュール自身に対して管理サービスを行うモジュ
ール内の手順に関係している。上に説明したように、モ
ジュールが制御装置に登録されると、二組のポインタは
制御装置を備えている複合システムまたはモジュールを
管理する際に使用するためのカーネル記憶装置にロード
される。

上の構造に加えて、モジュールはエンティティのクラス
およびモジュールによりサービスされる属性を記述する
管理仕様４８ばかりでなく、モジュールからサービスを
要求する指令および応答の構造にも関係している。管理
仕様はまたモジュールそれ自身の管理をも指定する。モ
ジュールの登録中、関連の管理仕様はデータ辞書にロー
ドされる。

２、管理仕様 制御装置（第１図〉により管理される複合システムのエ
ンティティばかりでなく制御装置を含む各種エンティテ
ィのサービス要素３１およびサービス・インターフェー
ス３３の性質、構成、および構造は管理仕様及びディス
パッチ仕様により規定される。第３Ａ図から第３Ｄ図ま
ではエンティティの管理仕様の詳細であり、第３Ｅ図は
エンティティと関連して特定の動作を開始する際に使用
されるディスパッチ仕様を規定している。最初に第３Ａ
図を参照して、エンティティの管理仕様は見出し部分４
０および本体部分４５を備えている。

見出し部分４０はエンティティを識別する名前を備えて
いる名前フィールド、別形の識別を備えている別形フィ
ールド、複合システム内のエンティティの位置を示す位
置情報（たとえば、複合システムが分布ディジタル・デ
ータ処理システムである場合、ノードの識別）を備えて
いるａ備フィールド４３、および所定のデータ形式情報
を示す形式宣言フィールド４４のような一定の識別情報
を含んでいる。

代りの実施例では、見出し部分は、下に説明する、記号
フィールド５２と関連して使用される記号・接頭辞フィ
ールドをも備えている。

管理仕様の本体部分４５はエンティティに対する実際の
管理仕様を含んでいる０本体部分４５は第３Ａ図に更に
規定されている。予備的に、制御装置は二つの一般形式
のエンティティ、すなわち、グローバル・エンティティ
および従属エンティティを備えている。制御装置は、上
に明らかにしたように、グローバル・エンティティが階
層の最上レベルのエンティティを識別し、従属エンティ
ティが階層の他のエンティティに従属するエンティティ
を識別して、エンティティの階層を助長する管理仕様の
本体部分４５は、二つの形式のエンティティの規定、す
なわち、グローバル・エンティティに対する規定４５Ａ
、または従属エンティティに対する規定４５Ｃ５のうち
の一つを備えている。

管理モジュールはグローバル・クラスのエンティティに
対して、またはグローバル・エンティティ・クラス内の
サブエンティティのクラスに対してサービスを提供する
ことができる。特定の例はマサチュセッツ州メイナード
のディジタル・イクイプメント社が発表しているＤＥＣ
ｎｅｔ　　Ｐｈａｓｅ　　ＩＶで生ずる。ＤＥＣｎｅｔ
　　Ｐｈａｓｅ■では、隣接ノードは従属エンティティ
・クラスであり、その上位エンティティはノード４回路
である。管理ノードが特に隣接ノード従属エンティティ
・クラスにサービスを行うと、管理仕様はグローバル・
クラスに対する管理仕様が他のモジュール（ノード４回
路クラスを管理する）に対する管理仕様内に存在するこ
とを示す機構を備えなければならない。

それぞれグローバル・エンティティおよび従属エンティ
ティに対する規定４５Ａおよび４５Ｃは更に第３Ａ図か
ら第３Ｄ図に規定されている。エンティティ規定４６は
それによってエンティティを識別することができる名前
とコードとを備えている名前フィールド４７を備えてい
る。その他、名前フィールド４７はエンティティをグロ
ーバルまたは従属のエンティティとして識別し、エンテ
ィティのクラス名を識別する。エンティティ規定が従属
エンティティに対するものであれば、階層中の上位エン
ティティを識別する上位フィールド５０を備えている０
Ｍｉ別子フィールド５１は後にエソティティ本体部分５
３で規定される属性に対する属性名のリストを備えてい
る。最後に、記号フィールド５２はエンティティ・デベ
ロッパにより使用される一貫した名前を備えた特別コン
パイラ常数ファイルを発生するのに使用される記号を備
えている。

別の実施例では、エンティティ規定にＤＹＮＡＭＩＣフ
ィールドを備えることができる。このフィールドは値Ｔ
ＲＵＥまたはＦＡＬＳＦ、を持つことができ、エンティ
ティの管理仕様を構成データベース（第１Ｂ図）に格納
すべきか否かを示す。

これは管理モジュールのデベロッパにどの従属エンティ
ティ段階を構成データベースに格納すべきかを精密に示
す方法を与える。このようにして、非常に動的なノード
間の接続のようなエンティティをシステムの構成に格納
する必要がなくなる。

これにより動的段階を反復して追加削除することにより
生ずるオーバヘッドが無くなる。ＤＹＮＡＭＩＣフィー
ルドのプール値はエンティティ・クラスの性質が動的で
あるか否かを示す、ＴＲＵＥであれば、エンティティ・
クラスの段階は構成に格納されない、ＦＡＬＳＥであれ
ば、エンティティ・クラスの段階が構成に格納される。

上に注記したように、エンティティに対するエンティテ
ィ規定４６は、本体部分５３を備えている０本体部分５
３は第３Ｂ図に詳細に規定されている。第３Ｂ図を参照
して、管理仕様の本体部分５３は四つの部分、すなわち
、属性区画規定リスドラ４、集合規定リスドラ５、指令
規定リスドラ６、およびエンティティ・クラスに従属エ
ンティティが入っている場合の従属エンティティ・リス
トラフを備えている０本体部分５３が従属エンティティ
・リストラフを備えていれば、従属エンティティ・リス
トラフの中の各項目はｒｓＵＢＯＲＤ　ＩＮＡＴＥＪを
含む名前フィールド４７を有するエンティティ規定４６
（第３Ａ図）から構成されている。

上述のように、エンティティ本体は属性区画リスト５４
および属性集合リスドラ５を備えている。

この点でこれらリストの区別を説明するのが有益である
。各リストはエンティティの属性の完全な組合わせを取
り、各属性を一つ以上のグループに組合せている０区画
リスト４５により示される組分けは集合リストにより示
されるものとは無関係であり、各リストはエンティティ
の属性の独立な正確付けである。

区画リスドラ４は同じ形の属性すべてを識別し、組分け
する。たとえば、属性ＰＡＲＴ　Ｉ　Ｔ　Ｉ　ＯＮはす
べてのカウンタまたはすべての状態属性（フラゾ）を備
えることができる。「区画」の後は属性区画により形成
されるグループが属性の真の区画であることを示すのに
使用される。属性は二つの区画のメンバーであることは
できず、各属性は正確に一つの区画のメンバーでなけれ
ばならない。

集合リスドラ５は同じＩｌ能を有するすべての属性を識
別し、組分けする。たとえば、ノード４グローバル・エ
ンティティ・クラスに対するアクセス・モジュールはｒ
ｓＱＵＡＲＥ」と読む属性集合を規定することができる
。５ＱＵＡＲＥ属性集合はノード４クラス・エンティテ
ィの現在の動作性能に［するすべての属性、たとえば、
送られたバイトの数を示すカウンタ形式の属性、および
パイプライン割当てを示す特性形式の属性、を含むこと
ができる。この例では、こうしてユーザはｓＨｏｗ　Ｎ
０ＤＥ　（ｉｎｓｔａｎｃｅ＞＾ＬＬ　５ＱｔｌＡＲＥ
のような命令によりこれらの統計を一緒に見ることがで
きる。

「集合」という語は集合が類似機能を有する属性を含ん
でいるが、必ずしも属性の区画を形成していないことを
示すのに使用される。一つの属性は二つ以上の集合のメ
ンバーであることができ、すべての属性は集合のメンバ
ーである必要はない。

属性区画規定リスト５４は更に第３Ｂ図で規定するよう
に一つ以上の属性規定６４を備えることができる。各属
性区画規定６４は属性を、識別子形式の属性、状態形式
の属性、カウンタ形式の属性、特性形式の属性、参照形
式の属性、または統計形式の属性を含む、特定の形式の
属性として識別する種類フィールド５６を備えている。

属性の各形式ごとに、データ形式が付加フィールド６８
により設けられている。属性区画規定５４は属性に対す
るそれぞれデフォルト・ポーリングの速さおよび最大ポ
ーリング速さを示すフィールド６０および６１をも備え
ることができる。上に注記したとおり、歴史データ記録
器ａ能モジュール１１は複合システムを備えた各種エン
ティティと関連してデータ記憶装置要素１７．２２に格
納する状態および条件の情報を定期的に得ることができ
る。

ポーリング速さフィールドの内容はそれぞれのエンティ
ティが状態および条件の情報を提供するデフォルト速さ
および最大速さを識別する。加えて、属性規定は各々が
属性名６３を備えている一つ以上の属性フィールド６２
を備えている。このフィールドはそれによって属性にア
クセスすることができるコード、および関連の属性本体
６４を備えている。上に示したように区画のメンバーで
ある属性に対する規定はすべて一つの区画規定５４の中
にある。Ｒ性の独立的な局面は一つ以上の属性本体規定
６４によって示されている。第３Ｂ図は属性区画規定５
５の属性フィールドの属性本体６４に含まれている情報
について更に述べている。

属性本＃６４は属性を読出しまたは書込みすることがで
きるかを示すアクセス情報フィールド６５および属性を
提示モジュール１０によりオペレータに表示すべきか否
かを示す表示フィールド６６を含む、多数のフィールド
を備えることができる。

デフォルト値フィールド６７は属性のデフォルト値また
は初期値を識別する。記号フィールド７０はエンティテ
ィ・デベロッパが使用する一貫した名前を備えている特
定のコンパイラ常数ファイルを発生するのに使用される
記号を備えている。

属性本体６４は更にそれを用いて属性を組合わせること
ができる一つ以上のカテゴリを識別するカテゴリ・フィ
ールド７１を備えている。複合システムが分布ディジタ
ル・データ処理システムであれば、カテゴリはＣ０ＮＦ
　ＩＧＵＲＡＴＩＯＮ。

ＦＡＵＬＴ、ＰＥＲＦＯＲＭＡＮＣＥ、５ＥＣＵＲＩＴ
Ｙ、またはＡＣＣＯｔＪＮＴＩＮＧを含む、７４−９８
−４オープン・システムズ・インターコネクト（０１）
ｉ格で規定されるカテゴリを含むことができるが、これ
に限定されることはない、その他、属性本体６４は属性
本体６４によって規定される特定の属性に対するポーリ
ング速さが属性区画規定５４のフィールド６０および６
１に規定されているポーリング遠さと異なっていればフ
ィールド７２および７３にポーリング速さ情報を備える
ことができる。最後に、属性本体６４は属性に関連して
処理する際に管理モジュールに使用される専有変数を識
別する専有変数フィールド７４を備えることができる。

別の実施例においては、ポーリング速さ情報を、このデ
ータの正確が実施特有であるため、属性規定から全く省
略することができる。その他に、別の実施例では、属性
本体６４にＵＮＩＴフィールドを備えることができる。

ＵＮＩＴフィールドが設けられている場合には、数字形
式のデータはその規定された単位を持つことができ（持
たせるべきであ）る。

属性はまとめて複合システムの管理を簡単にすることが
できる。エンティティ本体５３の集合規定部分５５はそ
のエンティティが備えている一つ以上の集合を識別する
。属性規定部分５５の内容は第３Ｂ図に詳細に規定され
ている。集合規定部分５５は集合を識別する集合名前フ
ィールド７５、および集合に含まれている属性を識別す
る属性リスト８１を備えている。集合規定部分５５は指
令、すなわち、集合を参照することにより処理すること
ができる要求、のりストを備えることもできる。

集合規定部分５５は上述の記号フィールドと同様な記号
フィールド７７、Ｏ３Ｉカテゴリ情報を含むことができ
るがこれには限られないカテゴリ・フィールド８０、お
よびフィールド７５め集合名により識別される集合に含
まれている属性に［１して処理する際に使用される専有
変数を識別する専有変数フィールド８２を備えることが
できる。

エンティティはそれぞれ提示モジュール１０およびｆｉ
ｌ能モジュール１１からの要求および従属要求に応じて
制御装置により発生される指令を処理する。各指令は行
うべき動作を規定する指令要求を備えており、エンティ
ティが動作と関連して行う応答を規定する応答および例
外を備えることができる。各指令は指令規定５６により
規定される。

第３Ｃ図および第３Ｄ図は指令規定５６の構造を詳細に
示している。第３Ｃ図を参照して、指定規定５６は、そ
れにより指令が識別し、アクセスすることができるコー
ドを備えた名前フィールド８３を備えている。指令は要
求又は従属要求の構造を識別する要求規定フィールド９
０、応答の構造を規定する応答規定フィールド９１、お
よび指令の処理中に発生することができる例外の構造を
規定する例外規定フィールド９２を備えている。

フィールド９０．９１および９２の詳細は以下に述べる
ことにする。

指令規定５６は指令が作用指令であるか否か、すなわち
、指令が複合システムの一つ以上のエンティティの条件
または状態を変化させることができるか否か、または指
令が単に状態または情報の戻しを開始するだけであるか
、を示すフィールド８４を備えることもできる。別の実
施例においては、作用フィールド８４を指令がＥＸＡＭ
ＩＮＥ。

ＭＯＤＦＹの形式のものかまたはＡＣＴＩＯＮ形式のも
のであるかを示すＤＩＲＥＣＴ　　ＴＹＰＥフィールド
で置換えることができる。ＥＸＡＭＩＮＥ指令は属性で
のみ動作し、修正を行わない。

例として５ＨＯＷ指令またはＤＩＲＥＣＴＯＲＹ指令が
ある。ＭＯＤＥＦＹ指令は属性でのみ動作し、修正を行
う０例としてＳＥＴ、ＡＤＤ、またはＲＥＭＯＶＥの各
指令がある。ＡＣＴＩＯＮ指令は属性では動作せず、エ
ンティティそれ自身で動作する０例としてＣＲＥＡＴＥ
指令およびＴＥＳＴ指令がある。

フィールド８５を設けて指令が提示モジュール１０によ
りアクセス可能であるか否かを示すことができる。識別
テキスト・ストリングを記号フィールド８６に設けるこ
とができる。その他、カテゴリー・フィールド８７が、
フィールド７１（第３図）に関連して上に規定したよう
に、一つ以上のＯ３Ｉカテゴリーを規定することができ
るが、これには限られない。

指令規定５６の要求規定フィールド９０の構造を第３図
に規定しである。ｒＲＦ、ＱｔＪＥＳＴＪという語の他
に、要求規定フィールド９０は、各々がアクセス・コー
ドを含む名前フィールド９２で規定される０以上の引数
９１を備えることができる。その他に、引数は引数を提
示モジュール１゜によりオペレータに表示すべきか否か
を示す表示フィールド９３を備えることができる。引数
はオペレターが引数の値を提供しなければならないか否
かを示すフィールド９４、デフォルト値を備えているデ
フォルト・フィールド９６、識別用テキスト・ストリン
グを備えている記号フィールド９７、および引数値の測
定の単位を示す単位フィールド９５をも備えることがで
きる。その他、引数９１は引数と関連して処理する際に
使用される専有変数を識別する専有変数フィールド１０
０を備えることができる。

応答規定フィールド９１および例外規定フィールド９２
の構造を第３Ｄ図に示しである。第５Ｄ図を参照して、
応答規定フィールド９１がそれにより応答にアクセスす
ることができるコードを備えることができる応答名前フ
ィールド１０１を備えている。激烈フィールドは応答が
要求フィールドにより規定された要求を遂行する際５Ｕ
ＣＣＥＳＳを示すか否か、または応答がＩＮＦＯＲＭＡ
ＴＩＯＮＡＬであるか否か、を識別する。テキスト・フ
ィールド１０３は提示モジュール１ｏがオペレータに応
答を示す表示をすることができるテキスト・ストリング
を示す、ａに、応答規定フィールドは、各々が名前フィ
ールド１０５．単位フィールド１０６、および記号フィ
ールド１０７を備えている、一つ以上の引数フィールド
１０４を備えることができる。

代りの実施例では、激烈フィールド１０２を応答に対す
る識別用テキスト・ストリングを備えた記号フィールド
で置換えることができ、引数フィールド１０４は応答を
ユーザに表示するべきか否かを示すプール表示フィール
ドを備えることができる。

例外規定フィールド９２の構造は、応答規定フィールド
２１のフィールド１０１から１０７までと同様のフィー
ルド１１１から１１７までを備えている応答層室フィー
ルド９１の構造と同様である。しかし、激烈フィールド
１１２は例外を引起すエラーの激しさを示す、ＷＡＲＮ
ＩＮＧ、ＥＲＲＯＲおよびＦＡＴＡＬを含む、三つの値
を備えることができる。

応答規定９１の場合のように、別の実施例では、激烈フ
ィールド１０２を応答に対する識別用テキスト・ストリ
ングを備えた記号フィールドで置換えることができ、引
数フィールド１０４は応答をユーザに表示すべきか否か
を示すプール表示フィールドを備えることができる。

３、ディスパッチ使用 第３図はディスパッチ使用３９Ａ（第２Ｂ図）を規定し
ており、これはエンティティによる特定の動作の開始を
規定するのに使用される。エンティティに対するディス
パッチ使用内の情報は動作を遂行する手順へのポインタ
を発生するのに使用される。第３Ｅ図を参照して、ディ
スパッチ使用はディスパッチ使用の始まりを規定すると
共にテーブル名を含んでいる見出し２００、およびディ
スパッチ使用の終わりを示すフータ（ｆｏｏｔｅｒ）２
０１を備えている。見出し２００と７−タ２０１との間
に、ディスパッチ使用は一つ以上のディスパッチ・エン
トリをそなえており、その各々が一つ以上のエンティテ
ィおよび属性と関連して動作を規定する。

ディスパッチ・エントリは動詞部分２０３およびエンテ
ィティ・エントリ２０４を備えており、これは−緒に動
作を識別する。効果的に、ディスパッチ・エントリの動
詞部分２０３およびエントリ部分２０４は管理により規
定される指令に対応している。指令はエンティティで動
作するか、またはエンティティ・エントリで規定された
エントリの属性部分２０５により規定された属性で動作
することができる。エンティティ・エントリ２０４の内
容はエンティティ規定４６の名前フィールド４７および
５０のエンティティ・クラスおよびＦ１階名により識別
されるエンティティまたはサブエンティティに対応する
。同様に属性部分２０５の内容はエンティティ規定４６
のエンティティ本体５３の属性規定５４の名前フィール
ド６２により識別される属性に対応する。

ディスパッチ・エントリ２０２も手順ポインタ部分２０
６を備えており、これはディスパッチ・エントリ２０２
の部分２０３．２０４および２０５で識別されるエンテ
ィティおよび属性と関連して指令を処理するアクセス・
モジュール内の手順へのエントリ点を指すポインタを備
えている。第５図、第７Ａ図および第８Ｂ図と関連して
以下に説明するように、ディスパッチ使用はデータ構造
、特にカーネル１３．１４により要求を適切な機能モジ
ュール１１またはアクセス・モジュール１２に処理のた
め転送するのに使用されるディスパッチ・テーブル２８
（第５図）のディスパッチ・エントリ１３４（第８Ｂ図
）を様式化するのに使用される。要求または従属要求は
本質的にＩ！ｌＩ詞、エンティティ、および属性区画を
規定し、カーネルは要求により規定された動詞、エンテ
ィティ、および属性区画をディスパッチ使用の、それぞ
れ部分２０３．２０４および２０５により規定されたデ
ータ構造の部分の内容と比較する。動詞のそれぞれの部
分がデータ構造（第８Ｂ図）の対応する部分の内容と合
えば、カーネル１３．１４はディスパッチ仕Ｉｌ（第３
Ｅ図〉の部分２０６から取られる、ディスパッチ・エン
トリ１３４で規定される手順を開始する。

Ｂ、データ・ファイル及び使用 １、データ辞書 管理モジュールを登録すると、その管理仕様が新しいエ
ンティティ・クラス、サブエンティティ・クラスまたは
属性、グローバルまたはサブエンティティの指令または
事象を規定することができる。管理仕様（第３Ａ図から
第３Ｄ図まで）はデータ辞書を構成するのに使用され、
データ辞書は他のデータ構造を構成するのに使用され、
これは第５図、第８Ａ図と関連して以下に記すが、第９
図に示すように使用される。データ辞書は第４図に示す
一般Ｍｉｍまたは構造を有する３１Ｗ層的データベース
から構成されている。第４図を参照して、この組織は管
理使用（第３Ａ図）で規定されるグローバル・エンティ
ティと関連している相対根源ノード２２０を備えている
。グローバル・エンティティ・ノードは、管理仕様のエ
ンティティ規定４６のエンティティ本体５３の階層組織
の、すべての属性をリストする従属ノード２２１、属性
区画をリストする従属ノード２１９、属性集合をリスト
する、従属ノード２２２、指令をリストする従属ノード
２２３、およびサブエンティティをリストする従属ノー
ド２２４を含む、複数の従属ノドを指す。

各従属ノード２１９から２２４まではエンティティ本体
で規定されているそれぞれの要素を指す。

すなわち−１従属ノード２２１はその各々がエンティテ
ィ本体５３の属性規定５４で規定される属性の規定を備
えている属性規定ノード２２５を指し、属性区画ノード
２１９はその各々がエンティティ本体５３の属性規定５
４の区画規定５６で規定される属性規定を備えている属
性区画ノードを指し、集合ノード２２２は各々がエンテ
ィティ本体５３の集合規定５５で規定される集合の規定
を備えた集合規定ノード２２６を指し、指令ノード２２
３は各々がエンティティ本体５３の指令規定５６で規定
される指令の規定を備えている指令規定ノード２２７を
指し、サブエンティティ・ノード２２４は各々がエンテ
ィティ本体５３のサブエンティティ規定５７で規定され
るサブエンティティの規定を備えているサブエンティテ
ィ規定ノード２２８を指す、各指令ノード２２７は要求
ノード２３０、応答ノード２３１、および例外ノード２
３２を指し、この各々が今度は管理仕様の要求規定９０
、応答規定９１、および例外規定９２（第３Ｃ図〉から
取った要求、応答、および例外の規定を備えている。他
に、各サブエンティティ・ノード２２８は、属性に対す
る従属ノード２３３、集合に対する従属ノード２３４、
指令に対する従属ノード２３５、区画に対する従属ノー
ド２３７、およびサブエンティティに対する従属ノード
２３６を含む、第４図に示すグローバル・エンティティ
について描いたものと同様の構造を有するサブ組織の根
源ノードを形成している。第４図に示す組織は第３Ａ図
から第３Ｄ図までに示す管理仕様で規定されるすべての
サブエンティティおよびそのサブエンティティについて
反復される。

管理仕様の中の情報はデータ辞書のそれぞれのノードに
融合され、エンティティ識別情報および応答情報を含む
エンティティ情報をオペレータに表示すること、および
下に記すように、制御装置の他の部分および複合システ
ムのエンティティによる処理要求の発生に関連して提示
モジュール１０によって使用されるユーザ・インターフ
ェース情報ファイル２９を作るのに使用される。データ
辞書の多様なノードが管理仕様の要素から情報を受取っ
てデータ辞書から成る完全なデータベー・スを形成する
。ディスパッチ仕様内の情報（第３Ｅ図）は第８Ｂ図お
よび第９図と関連して下に説明するように、ディスパッ
チ・テーブル２８を作るのに使用される。

この背景のもとに、第５図は一つの提示モジュール１０
．Ｉｍｍモモジュール１１アクセス・モジュール１２お
よび情報管理器１５．２０およびディスパッチャ１６．
２１を備えたカーネル１３゜１４を示している。その他
に、第５図はデータ記憶装置要素１７．２２のいろいろ
な部分を示しである。特に、データ記憶装置要素１７．
２２は構成および領域データベース２３，２５、警報デ
ータベース２４、歴史的データ・ファイル２６、データ
辞書２７、およびディスパッチ・テーブル２８を備えて
いる。

２、歴史的データ・ファイル 歴史的データ・ファイル２８は、カーネル１３の提示・
機能局面の場合、エンティティの状態および条件に関す
る情報を、カーネル１４の機能・アクセス局面の場合、
エンティティを、備えている。ファイル２６では状態お
よび条件の情報は、状態および条件の情報が発生した時
刻を識別するタイミング情報をも備えている。情報管理
器１５゜２０が特定の時刻に状！ｌｌまたは条件に関す
る要求または従属要求を受けると、情報管理器は、要求
または従属要求に示されている時刻が過去のものであれ
ば、情報がファイル２６に存在するか否かを確認し、フ
ァイルの内容を使用して応答する。

他方、要求または従属要求に示されている時刻が未来の
時刻であれば、情報管理器１５．２０は要求を指示され
た時刻に処理するように効果的に計画する。すなわち、
情報管理器は要求又は従属要求を指示された時刻になる
まで保持し、その時点で直接アクセス・モジュール１２
からの、または機能モジュール１１からの、いずれかの
適切な方からの応答を利用して、または適切ならばファ
イル２６を使用して、要求を処理する。

これらの機能については「スケジューリング」の見出し
のちとに以下に完全に説明することにする。

３、ディスパッチ・テーブル ディスパッチ・テーブル２８はディスパッチャ１６．２
１により要求または従属要求を適切な機能モジュール１
１またはアクセス・モジュール１２に転送する方法を決
めるのに使用される。デイスバッチ・テーブル２８の内
容は、提示モジュール１０からの要求に応じて呼び出さ
れる各機能モジュール１１を構成しているルーチンのエ
ントリ点の、分布ディジタル・データ処理システム内の
、位置を識別する。更に詳細に述べれば、ディスバッチ
・テーブル２８はそれぞれの機能モジュール１１による
各種動作の開始を容易にする呼出し情報を含んでいる。

同様に、ディスバッチ・テーブル２８の内容は、アクセ
ス・モジュール１２のルーチンのエントリ点の、分布デ
ィジタル・データ処理システム内の、位置を識別する。

この位置は機能モジュール１１からの従属要求、すなわ
ち、それぞれのエンティティによる各種動作を規定する
呼出し情報を処理するのに使用される。

４、ユーザ・インターフェース［ａ 制御装置は更に機能モジュール１１により提供される各
穫ｍ能およびアクセス・モジュール１２により制御され
るエンティティに関する情報を備えたユーザ・インター
フェース情報ファイル２９を備えている。ユーザ・イン
ターフェース情報ファイル２９はそれぞれのエンティテ
ィの管理仕様から得られた情報を備えている。提示モジ
ュール１０はメニューおよび他の対象をオペレータ端末
に表示する際にユーザ・インターフェース情報ファイル
２９の内容を使用して複合システムの制御を容易にする
。ユーザ・インターフェース情報ファイル２９の中の情
報は複合システムのエンティティに関連する各種機能お
よび動作の表示を容易にする。

５、構成データベース 上に説明したとおり、構成機能モジュールは複合システ
ムの現在の構成（および、必要なら過去の構成も）の全
てのエンティティ段階をリストする構成データベースを
作り、維持することができる。この情報は、たとえば、
提示モジュールが利用可能なエンティティ段階をリスト
する精査テーブルまたはユーザ・メニューを作るのに使
用することができる。構成データベースはまた、下に説
明するように、ユーザの制御の範囲を限定する領域デー
タベースを設けて複合システムを使用しやすくすること
もできる。

上の特徴に加えて、一実施例においては、構成データベ
ースを提示モジュールと関連して使用し、ユーザ命令の
ワイルドカードを支援することができる。ワイルドカー
ドを含んでいるユーザ命令を提示モジュールが受けとる
と、提示モジュールは要求を構成機能モジュールに対し
て発し、ワイルドカード要求に合う構成内のすべてのエ
ンティティの目録を要求する６次に構成機能モジュール
は構成データベースの情報を（領域情報と共に）使用し
てリストを作製する。リストを受取ったら、提示モジュ
ールはユーザ要求をワイルドカードに合致する可能な従
属要求のすべてに拡張する。

たとえば、要求 ５ＨＯＷ　Ｎ０ＤＥ大ＩＮ　ＤＯＭＡＩＮ　５ＩＴＥ　
１（ここで５ＨＯＷは指令であり、ＤＯＭＡＩ　Ｎは領
域エンティティ・クラスであり、５ＩＴＥＩは領域段階
であり、ＭＯＤＥはグローバル・エンティティ・クラス
であり、大はワイルドカードである）は５ＩＴＥＩとい
う名前の領域の内部にあるノードのすべての段階を示す
命令と解釈される。

こうして提示モジュールは要求を各々が５ＨＯＷ　　Ｎ
０ＤＥ　　（ｉｎＳｔａｎＣｅ＞（ここで＜１ｎＳｔａ
ｎＣＱ）は段階の名前である〉の形で、一つが領域５Ｉ
ＴＥＩのＮ０ＤＥクラスの各段階に対応する、幾つかの
要求に拡張する。

部分的にワイルドカードも支援することができる。この
場合には、部分ワイルドカード名により指定されたパタ
ーンに適合する段階名を持つ目標エンティティのグルー
プが発せられた指令である。

タトえば「Ｎ０ＤＥ＊ＯＯ」はｒＮＯＤＥ　　ＦＯＯ」
およびｒＮＯＤＥ　　ＭＡＧＯＯＪに適合するが、ｒＮ
ＯＤＥ、　ＢＡＲ，には適合しない０部分ワイルドカー
ドは、一定のデータ形式の識別子、たとえば、テキスト
または数字ストリングを備えたフィールドには使用でき
ない。

好適実施例では、ワイルドカード拡張はユーザ指令のグ
ローバル・エンティティ・クラス・フィールドには許容
されない、グローバル・クラスの仕様はワイルドカード
にされない、何故ならそうすれば命令の範囲に関する制
御が不充分になるからである。これは一つのエンティテ
ィ・クラスにより支援される指令名が他によって支援さ
れなければエラーを発生することがある。指令名が複数
のクラスで支援される場合でも、指令名は異なるクラス
の関係の無い機能と対応して、不要な副次効果（たとえ
ば、ｒＤＥＬＥＴＥ＊、指令）を生ずることがある。他
に、グローバル・エンティティ・ワイルドカードはユー
ザの意図する以上の情報（たとえばｒｓＨＯＷ＊、指令
〉を簡単に発生することができる。ワイルドカードはサ
ブエンティティ・クラスに安全に許容されることに注意
すること。

ワイルドカードの実施例はワイルドカード拡張任務の幾
らかまたは全部をアクセス・モジュールに委任すること
もできる。

これは構成機能モジュールを使用しない場合が特にそう
である、構成機能モジュールが無ければ、アクセス・モ
ジュール（通常、クラスまたはサブクラスのすべてのモ
ジュールにアクセスすることに関係している）が段階デ
ータをその専有記憶装置３２（第２Ｂ図〉の一部として
格納することができる。この場合には、アクセス・モジ
ュールは段階データを使用して受取った要求のワイルド
カードを拡張することになる。ワイルドカードが特定の
アクセス・モジュールにより支援されなければ、この条
件を示す例外がユーザに戻されることになる。

Ｃ，データ・ファイルの管理および登録管理モジュール
を制御装置に追加すると、またはエンティティの管理に
関係する新しい情報が利用できると、制御装置が適応し
なければならない。

制御装、［はデータ駆動され、システムを新しいモジュ
ールまたは情報に適応させるには関連のデータ・ファイ
ルを修正しなければならない、一般に、このプロセスは
データ・ファイル管理として知られている。制御装置を
新しいモジュールに適応させる特定の手順は登録として
知られている。

１、歴史的データ・ファイルの管理 −つの特定の実施例において、歴史的データ・ファイル
２６の内容は歴史データ記録器機能モジュールとして働
く機能モジュール１１によって部分的に提供され、維持
される。この実施例では、歴史データ記録器機能モジュ
ールがオペレータにより提示モジュール１０に提示され
た要求を通して制御される。最初、このような要求はエ
ンティティおよび一つ以上の属性を識別するが、ポーリ
ング速さと共に、歴史的データ・ファイル内に識別され
たエンティティ及び属性に対する記録を確立し、歴史デ
ータ記録器機能モジュールが、要求で指定されたポーリ
ング速さで、エンティティに対してエンティティが要求
で指定されたエンティティおよび属性により指定された
複合システムのエンティティの状態を表す値を用いて応
答することができるようにする従属要求を発することが
できるようにする他に、他の形式の要求がオペレータに
、ポーリング速さの変更を含む、歴史データ記録器機能
モジュールと関連する他の動作を開始させ、ポーリング
を一次的に有効または無効にし、応答内の最後の値を示
す。

２、ディスパッチ・テーブル ディスパッチ・テーブル２８の、およびユーザ・インタ
ーフェース情報ファイル２９の内容は登録情報を含んで
おり、登録手順中に各種機能モジュール１１およびアク
セス・モジュール１２により供給される。モジュールを
制御装置に登録する登録手順中に、モジュールは名前お
よびコードの情報を含む表示情報をその名前フィールド
からデータ辞書にロードする。他に、モジュールは管理
仕様で規定されたコード情報および他の情報をデータ辞
書（第４図）から、ディスパッチ情報をそのディスバッ
チ仕様（第３Ｅ図）から、ディスパッチ・テーブル２４
にロードする。

３、ユーザ・インターフェース情報 提示モジュール１０はユーザ・インターフェース情報フ
ァイル２９の表示情報を使用して、最初に、エントリ、
属性、指令などを表示するか否かを、第２に、何を表示
するかを、決定する。ユーザ・インターフェース情報フ
ァイル２９は、端末のオペレータによる命令に応じて、
提示モジュール１０が命令を受取り、精査テーブルを使
用して命令を精査して、要求、エンティティ、および管
理仕様で規定された属性のコードに対応するコードを得
ることができるようにし、これを要求としてカーネル１
３に伝送する。

機能モジュールおよびアクセス・モジュールはユーザ・
インターフェース・コードを所有する必要はないことに
注意、ユーザ・インターフェース支援装置はすべてこれ
らモジュールに提供され、モジュール設計者はユーザ・
インターフェースに関わる必要は無い、これによりモジ
ュール設計が恐ろしく簡単になり、使用している実際の
モジュールに関係なく、システムの見え方および感じは
ユーザにとって一様になる。

要求を提示モジュールから受取ると、ディスパッチャ１
６はディスバッチ・テーブル２８のディスバッチ情報を
使用して機能モジュール１１を呼出す。

ディスパッチ・テーブル２８も精査テーブルを形成して
おり、これをディスパッチャ１６が使用して適格な手順
に送り、第９図と関連して以下に説明するように、要求
を処理する。

提示特有の情報をユーザ・インターフェース情報ファイ
ル２９で使用しながら精査テーブル内のおよびディスパ
ッチ・テーブル２８のコードを使用すれば、ディスパッ
チャ１６が使用したように、エンティティ、属性等が提
示モジュール１０によりオペレータに表示された識別か
ら実質上分離されることが分かる。提示モジュール１０
により発生された表示は、それ故、多様な言語で表すこ
とができ、一方提示モジュール１０により発生された要
求はエンティティ、属性等の同じ識別を備えている。

他に、ユーザ・インターフェース情報ファイル２９は構
成データベースおよびデータ辞書から一層便利なフォー
マットで既に利用可能になっている情報を格納すること
ができる。

たとえば、データ辞書（第４図）内のクラス・データは
複合システムのエンティティにより支援される全ての指
令２２３を示す。

しかし、指令２２３は階層的フォーマットで格納されて
おり、エンティティ・クラス２２０に対しては従属的で
ある。このフォーマットはエンティティ・クラスの情報
を表すには論理的であるが、精査テーブルにとってはあ
まり有用でない、ユーザ要求は典型的に第一に指令（た
とえば、ｒｓＨｏＷ　　Ｎ０ＤＥ　　ＦＯＯＪのｒｓＨ
ＯＷ」）をリストするので、精査テーブルは指令を階層
構造の第一レベルとして所持すべきである。上の例から
も分かるとおり精査テーブルはクラス名（たとえばｒＮ
ＯＤＥＪ　）がａ階名（たとえばｒＮＯＤＥＦＯＯ，の
識別子ＦＯＯ）と混合している場合命令を精査するので
必要になる。それゆえ、利用可能な指令をリストしてか
ら、精査テーブルはこれら指令を支援するクラス名を、
次いでこれらクラスの段階のデータ形式をリストすべき
である。クラスおよびデータ形式の情報はデータ辞書の
再編成により利用可能であるが、ワイルドカードの拡張
には、段階データを構成データベースから得ることがで
きる。従ってユーザ・インターフェース情報ファイル内
の精査テーブルは指令およびエンティティ・クラスを統
合することができ、ユーザ入力の精査が一層効率的と評
価される。

上の例は図式のまたはメニュー駆動のインターフェース
にも適応される。しかし、この種のインターフェースで
は、ユーザは、以後の動作について特定のエンティティ
またはエンティティの領域を、および行うべき指令のＯ
３Ｉカテゴリー（指令規定のカテゴリー・フィールド８
７にリストされている）を、図式に選択して自分の命令
に対する文脈をセットしたいことがある０次に、支援さ
れる指令の全てをリストしたメニューを発生することが
できる。ユーザは予め形成したメニューを使用して一つ
以上の段階に対する指令を（たとえば、指令および段階
をクリックさせて）、または領域全体またはエンティテ
ィクラス全体を（指令だけをクリックさせて）要求する
ことができる。ＥＸＡＭＩＮＥ形式のまたはＣＡＴＥＧ
ＯＲＹ形式の指令については別のメニューがユーザに属
性区画または集合を選択するよう促すことができる。こ
の種のインターフェースを実現するには領域およびエン
ティティ段階の全てのリストおよび領域内のすべての段
階のリストを構成データベースから取り出さなければな
らない、他に、形態データベースがクラスまたは領域に
より支援される指令を格納することができる。

ユーザ・インターフェース情報ファイルはデフォルト値
の情報をも格納することができる６段階またはクラスの
デフォルト値にはユーザによりまたは関連エンティティ
・クラスに対する管理仕様により提供される。これによ
りユーザはデフォルト値を命令内に指定することによっ
てタイプの時間を節約することができる。たとえばユー
ザはＮ０ＤＥ　　ＦＯＯに最も関心を持つことができ「
Ｎ０ＤＥ　　ＦＯＯＪをデフォルト・ノードとして指定
することができる。後に、ユーザはｒｓＨＯＷＲＯＵＴ
ＩＮＧ」のような命令をタイプすることができ、これは
ｒｓＨＯＷ　　Ｎ０ＤＥ　　ＦＯＯＲＯＵＴＩＮＧＪと
解釈されることになる。デフォルト値の同様な用法を図
式環境に利用することができる。ユーザ・インターフェ
ース情報の他の例は提示モジュールを通してユーザが利
用できるオンライン補助ファイルである。補助ファイル
は管理モジュールの現存セットを利用するための補助情
報を備えている。好適実施例では、補助ファイルはモジ
ュールが登録されるときモジュールにより供給される補
助情報から組み立てられる。

供給さた補助情報はモジュールより支援されるエンティ
ティおよびサブエンティティのクラスのテキスト記述お
よびモジュールに支援されるクラスに対する指令を備え
ることができる。加えて、個別指導情報を供給してモジ
ュールおよびその指令に関する初めてのユーザを教育す
ることができる。

上記情報はモジュールに対する管理仕様から求めること
もできるが、補助情報ファイルは管理仕様情報を英語文
に翻訳し、ユーザが管理仕様の構文法を習う必要性を少
なくしている。

４、歴史データ記録 歴史データ記録器機能モジュール１１はエンティティの
ポーリング情報を、最大ポーリング速さフィールドおよ
びデイフォルト・ポーリング速さフィールドに関連する
部分を含む、データ辞書のその部分から使用して、属性
規定５４に規定されたエンティティの各種属性に関連し
てポーリングを開始し、制御することができこれに対す
る応答を歴史データ記録器機能モジュール１１がその歴
史的データ・ファイル２６に格納する。

５、モジュール登録 第５図を参照して、アクセス・モジュール１２は、たと
えば、登録手順に携わっている間、その名前フィールド
からの名前およびコード情報に規定されている名前及び
コード情報およびその管理仕様の表示フィールドに関係
するそのデータ辞書の部分からの情報を含む表示情報を
ユーザ・インターフェイス情報ファイル２９にロードす
る。同様に機能モジュール１１は管理仕様で規定されて
いるコード情報および他の情報をデータ辞書（第４図）
から、およびディスパッチ情報をディスパッチ仕様く第
３Ｅ図）からディスパッチ・テーブル２８にロードする
。

Ｄ、モジュール間およびノード間の通信１、制御機能モ
ジュール 特定の一つの実施例において、オペレータはアクセス・
モジュール１２を直接ディスパッチャ１６から受取る要
求のコピーである従属要求を本質的に発生する制御機能
モジュール１１を通して、制御することができる。この
実施例において、命令を受取る提示モジュール１０は、
ユーザ・インターフェイス情報ファイル２９の精査テー
ブルを使用して命令を精査し、管理仕様で規定されるア
クセス・モジュール１２の要求、エンティティ、および
属性に対するコードに対応するコードを得、これを要求
として提示・機能カーネル１３に伝達する。制ｍ機能モ
ジュール１１は、要求を従属要求として機能・アクセス
・カーネル１４に伝え、ここで、他の従属要求と同じ仕
方でこれを処理する。

従属要求を制御機能モジュール１１から受取るとディス
パッチャ２１はディスパッチャ・テーブル２８のディス
パッチャ情報を使用してアクセス・モジュール１２を呼
び出す。ディスパッチャ・テーブル２８は精査テーブル
をも形成し、これをディスパッチャ２１が使用して適切
な手順に送り、第９Ａ図および第９Ｂ図と関連して以下
に説明するように、要求を処理する。

２、モード間通信 制御装置が分布デジタル・データ処理システムからなる
複合システムを制御する場合、第５図は一般に、提示モ
ジュール１０、情報管理器１５１，２Ｇおよびディスパ
ッチャ１６．２１から戒るカーネル１３゜１４および関
連データ・ファイル２３，２４，２５，２６．２７を含
む機能モジュール１１およびアクセス・モジュール１２
、ディスパッチャ・テーブル２８、ユーザ・インターフ
ェイス情報ファイル２９を含む要素を示しており、これ
ら要素は分布デジタル・データ処理システムの単一ノー
ドの単一プロセスに含まれている０分布デジタル・デー
タ処理システムが提示モジュール１０、機能モジュール
１１およびアクセス・モジュール１２　　異なるプロセ
スまたはノードに備えている場合には制御装置はディス
パッチャ１６．２１を全てのプロセスおよびノードに備
えている。第６図を参照して、一つのノードの一つの１
０セスのディスパッチャ１６　（１）が第２のプロセス
またはノードの機能モジュール１１　（２）で処理しな
ければならない要求を提示モジュール１０（１）から受
取ると、ディスパッチャ１６　（１）は、ｉ能モジュー
ル１１（２）が同じノードの他のプロセスにある場合、
プロセス間通信機構によりまたはノード間通信ａ梢によ
り、要求を他のノードのプロセスまたはノードのディス
パッチャ１６　（２）に伝える。ディスパッチャ１６　
（２）は次に機能モジュールｌＮ２）を選択して要求を
処理する。ディスパッチャ１６（２）はａ能モジュール
１１（２）が発生した応答を受取り、これをプロセス間
通信機Ｉまたノード間通信機構により、ディスパッチャ
１６　（１）に伝え、ディスパッチャ１６　（１）は提
示モジュール１Ｇ（１）が応答をオペレータに表示でき
るようにする。

同様に、ディスパッチャ２１　（２）がｍ能モジュール
１１（２）から他のプロセスまたはノードのアクセス・
モジュール１２　（３）で処理すべき従属要求を受取る
と、従属要求をそれぞれプロセス間通信機構またはノー
ド間通信機構により他のプロセスまたはノードのディス
パッチャ２１　（３）に伝達する。ディスパッチャ２１
　（３）は次に従属要求をアクセス・モジュール１２（
３）に処理するため伝達する。ディスパッチャ２１　（
３）は応答をアクセス・モジュール１２　（３）から受
取り、これをプロセス間通信機構またはノード間通信機
構によりディスパッチャ２１　（２）に伝達し、ディス
パッチャ２１　（２）はこれを機能モジュール１１　（
２）に結合する。

３、要求および従属要求の構造 要求、特に要求と共に含まれているパラメータの構造を
第７Ａ図に示す、ディスバ・ｙチ・テーブル２４の構造
および内容（これはディスパッチ・テーブル２６の構造
および内容と同じである）を第７Ａ図および第７Ｂ図と
関連して説明することにする。今後要求の精査と関連し
て情報管理器１５．２０およびディスパッチャ１６．２
１により行われるプロセスを第９図と関連して記すこと
にする。

第７Ａ図を参照して、ユーザ・インターフェイス情報フ
ァイル２７の内容と関連するオペレータによる動作に応
じて提示モジュール１０により発生することができる。

または制御される複合システムの各種エンティティと関
連してポーリング中に情報管理器１５により発生するこ
とができる、要求が複数のパラメーターを備えている。

要求は全て同じ構造を持っており、初期呼出し識別子、
これは図示してない、の次に第７Ａ図に示すパラメータ
が付いている。上に説明したとおりカーネル１３．１４
は提示・機能局面１６および機能アクセス局面２１を有
する単一デイスバッチャ１６．２１を備えている。

これら局面のどれがそれぞれ要求により有効になるかは
初期呼出し識別子によって決まる。初期呼出し識別子は
機能モジュールまたはアクセス・モジュールへの呼出し
を示すことができ、それぞれディスパッチャの対応する
局面に向けられる。提示モジュールまたは機能モジュー
ルはｍ能モジュルを呼出すことができＩ！＆能モジュー
ルまたはアクセス・モジュールはアクセス・モジュール
を呼出すことができるが、提示モジュールは上に説明し
た「制御機能モジュールＪを通してアクセス・モジュー
ルだけを呼出すことができる。

パラメータはその内容が要求の形式、すなわち要求を処
理する際に行われる動作を識別する動詞フィールド１２
０を備えている。上に注記したように、要求はＩＩ能モ
モジュール１１たはアクセス・モジュール１２に制御さ
れる複合システムのエンティティの状態または条件の変
化を開始させ、このようなエンティティの状ｎまたは条
件、またはその両者に関する情報の返送を開始すること
ができる。

動詞フィールド１２０の内容は機能モジュール１１また
はアクセス・モジュール１２により行われる動作を示す
。

他に要求は入力エンティティ指定フィールド１２１を備
えており、これは制御されている複合システムのエンテ
ィティを識別する。動詞が非作用動詞であれば、たとえ
ば一つ以上の属性の値を示す応答を要求していれば要求
はこれに関連して動詞およびエンティティ・クラスによ
り規定される動作を行うべき一つ以上の属性を指すポイ
ンタを備えた属性ポインタ・フィールド１２２を備えて
いる。

動詞が作用動詞であれば、すなわち動詞が所定のエンテ
ィティの変化を起こせば、要求は属性ポインタ・フィー
ルド１２２を備えていない。

他に、要求は、スケジュール作製の目的で絶対システム
時間、時間間隔規定および時間正確度指定を含む一定の
タイミング情報および要求内の当該時間範囲に関する指
定を備えている時間データ構造を指ずポインタを備えた
入力時間指定子フィールド１２３を備えている。入出力
文脈取り扱いフィールド１２４はその各部が別々の要求
を必要とする複数部動作の分脈で要求を識別する値を備
えている。出力エンティティ指定子フィールド１２６は
エンティティの識別と関連してディスパッチャ１５（ま
たはパラメータが従属要求の一部を形成していればディ
スパッチャ２１）が使用することができるデータ・バッ
ファを指すポインタを備えている。

要求は応答の形成に関連して機能モジュール１１（また
は従属要求の場合にはアクセス・モジュール１２）が使
用することになっている項目スタンプ指定を指すポイン
タをも備えている。最後に随意選択のデータ記述子フィ
ールド１２７は要求を処理する際に使用されるデータを
備え、かつエンティティが応答を構成するデータを格納
するバッファに対する記述子を備えている。各記述子は
それぞれのバッファの開始位置を指すポインタおよびバ
ッファの長さを示す長さ指定子を備えている。

本発明の別の実施例では要求は別のパラメータとしてま
たは上述のパラメータ・フィールドの別の要素として、
限定子フィールドを備えることもできる。

ＷＩＴＨ限定子は、たとえばワイルドカードにより作ら
れるエンティティ・リストをろ過するエンティティ・フ
ィールドと関連させることができる。たとえば、ｒＢＲ
ＩＤＧ＊ＷＩＴＨ５ＴＡＴＵＳ＝’ＯＮ’　　ＡＮＤ　
　ＦＩＬＴＥＲＩＮＧ＝’ＯＦＦ’Ｊはその状態フラグ
をＯＮにろ過フラグをＯＦＦにセットした状態での各ブ
リッジ・クラス・エンティティを指す（この例はＡＮＤ
、ＯＲ，ＮＯＴおよび限定子付きＸＯＨのようなプール
関数の使用法をも例示している）、好適実施例において
は、ＷＩＴＨ限定子を実現するのにすべてのモジュール
および情報管理器をエンティティ・パラメータの各レベ
ル（すなわちグローバル・エンティティ、サブ・エンテ
ィティ、サブ・サブ・エンティティ〉でＷＩＴＨ節の有
無をチエツクするように構成されている。

他の限定子を要求の明確なパラメータとして使用するこ
とができる０例えば、通信限定子は要求の応答を＜ｆ　
ｉ　ｌ　ｅ　ｎａｍｅ＞という名前のファイルに送るｒ
Ｔｏ＜ｆ　ｉ　１　ｅｎａｍｅ＞」限定子、他の要求パ
ラメータを＜ｆｉｌｅｎａｍｅ＞という名前のファイル
から検索するｒＦＲＯＭ＜ｆｉｌ　ｅ　ｎａｍｅ＞」限
定子、管理モジュールの階層を貫く、−径路に沿う一連
の「ホップ」を指定す６　ｒＶＩＡＰＡＴＨＪ　＠電子
（例えば、動作を行う幾つかの装置の間の精密管理モジ
ュールを指定する際に有用）、および動作を行うとき管
理モジュールが使用する特定のネットワーク径路を指定
するｒＶＩＡ　　ＰＯＲＴＪ限定子（た電子ば、アクセ
ス・モジュールが特定のエサ−ネット・ボートを使用す
る診断試験を行うことを指定するのに有用）を備えてい
る。

同様に明確なパラメータ限定子は当該エンティティのグ
ループを指定することができる。

「ＩＮ　　ＤＯＭＡＩＮ＜ｄｏｍａｉｎ　　ｎａｍｅ〉
」限定子は＜ｄｏｍａｉｎ　　ｎａｍｅ＞という名前の
領域の一員にのみ適用するように指定をろ過する。

また、明確なパラメータ限定子はアクセス権が限定され
ている管理サービスの要求者を認証するかまたは認定す
ることができる。ｒＢＹ　　ＡＣＣＯＵＮＴＪ、ｒＢＹ
　　ＰＡＳＳＷＯＲＤＪ、およびｒＢＹ　　ＵＳＥＲＪ
限定子は顧電子名前、パスワード、または要求者のユー
ザ識別子を、これらの目的で指定する例である。

上記に加えて、限定子は指令を実行すべき時刻を指定す
る。一般に、これはＡＴ節で行われる。

ｓｈｏｗ命令の場合、ＡＴ節の構文法は＜ＡＴ−ｃ　１
　ａｕ　ｓ　ｅ＞　：　：　＝”　ＡＴ”＜１１ｍｅ−
ａｒｇ）［”　、”　　＜ｔ　　ｉｍｅ−ａｒｇ＞コで
ある。ここで時間引数＜ｔ　ｉｍｅ−ａｒｇ＞は、たと
えば、開始時刻（’５ＴＡＲＴ＝＜ｔ　ｉｍｅ〉」）、
終了時刻（ｒＥＮＤ＝＜ｔ　ｉｍｅ＞」）、または接続
時間（ｒＤＵＲＡＴＩＯＮ−＜ｔ　ｉｍｅ−１ｅｎｇｔ
ｈ＞」）、反復の周期（ｒＲＥＰＥＲＴ　　ＥＶＥＲＹ
［＝］＜ｔｉｍｅ−１ｅｎｇｔｈ〉」〉、時間の正確さ
（ｒｃＯＮＦＩＤＥＮＣＥ　［＝］＜ｔｉｍｅ−１ｅｎ
ｇｔｈ＞」）　、またはサンプリング割合（ｒＳＡＭＰ
ＬＥ　　ＲＡＴＥ　［＝］＜ｔｉｍｅ−１ｅｎｇｔｈ＞
」）を示すことができる。これら引数は互いに対話して
要求に対する一般的スケジュールおよび関心の範囲を作
り出す、特に、特定の一実施例においては、三つの時間
引数、５ＴＡＲＴ、ＥＮＤ、およびＤＵＲＡＴＩＯＮは
これらの中の二つが期間を規定するように関係している
。したがって期間基準化エンティティ統計を表示すると
きは、これら限定子引数の少なくとも二つを指定しなけ
ればならない。

他の時間限定子をも使用することができる。

たとえば、ＡＴ　ＯＲＢＥＦＯＲＥ＜ｔｉｍｅ＞の時間
限定子は＜ｔｉｍｅ＞で示される時間にまたはその前に
時間スランプ付き情報を要求するものと解釈することが
できる。このような限定子付き要求を受は取ると、引数
モジュールは要求された情報を発生するアクションを絶
えずチエツクする。たとえば他の仲間の行為により、情
報が発生すれば、これは要求者に戻される。その他の場
合には、管理モジュールは時刻（ｔｉｔｌｅ＞になるま
で情報をチエツクし続ける。情報が発生すれば、これは
要求者に戻される。そうでない場合には、時刻＜ｔｉｍ
ｅ＞に、管理モジュールがアクセス・モジュールまたは
エンティティからの情報のボールを強制し、情報を要求
者に戻す。

ＡＴ　ＯＲＢＥＦＯＲＥ　ｔｉｍｅ限定子を電子するに
は、Ｎ。

−時間限定子をも実施することができる。他に、フィー
ルド１２４は処理文脈情報を格納する記憶装置の専用区
画である文脈データ構造を指す取扱ポインタを備えてい
る。取扱いは、例えば、モジュールと情報管理器との間
で文脈情報の通信を行うためのｒノートパッド」として
使用される。

１、時間スタンプ データの各項目は時間スタンプ値を備えている。

ユーザまたは管理モジュールに戻されるデータの場合、
時間スタンプは、データ項目により記述される事象が発
生した瞬間、指令に対して戻されたデータ値に適用され
る瞬間、要求した行為が実際に行われた瞬間、を示す、
歴史的データ・ファイルに格納されている歴史的データ
の場合、時間スタンプは所定のデータ項目が所定の値を
持った瞬間、歴史的データ・ファイルの目的で、時間ス
タンプはキーまたは索引と考えることができる。関心時
間範囲仕様１２３は所定キー又は索引で格納されている
特定の情報片の検索を要求するのに使用することができ
る。

２６関心の範囲 関心時間範囲仕様は、時間指定子フィールド１２３を使
用して要求により供給される０時間指定子を使用して、
「現在権利を所持している値」以外のデータの他の値を
表示し、処理することができ、統計を成る時間期間にわ
たり計算することができる。特定の一実施例においては
、「関心の時間範囲」は要求の時間指定子中の前置詞句
により表わされる。一般に、時間指定子は５ＨＯ１４命
令と共に使用されるが、時間文脈はＭＯＤＩＦＹ形式の
要求および行為にも適用することができる。

関心の時間範囲は、絶対瞬間、一続きの絶対瞬間、時間
間隔（開始時間ｒｓＴＡＲＴ　、および持続時間ｒＤｔ
ｌＲＪ）、瞬間の反復、または時間間隔の反復、によっ
て表わすことができる。

これらはいずれも瞬間、諸瞬間、または時間間隔が反復
する周期性を指定する相対的期間（ｒＥＶＥＲＹ　Ｊ　
）それらと関係させることができる０期間が指定される
と、元の瞬間、または一続きの瞬間、または時間間隔が
ベースとして処理され、このベースに期間が付加される
。たとえば、時間指定ｒ５：００ＥＶＥＲＥＹ　Ｏ：１
５　、は、５：００，５：１５，５：３０，５：４５゜
・・・と同等である。絶対時間瞬間（ｒＵＮＴＩＬ　Ｊ
　）は反復を終結しようとするときを示すのに指定する
ことができる。たとえば、時間指定ｒ　５：ＥＶＥＲＥ
Ｙ　Ｏ：１５υＮＴＩＬ６：００．は５：００，５：１
５，５＋３０，５：４５，６：Ｇｏと同等である０反復
時間間隔を同じようにして指定すルコトができ６．　　
ｒＳＴＡＲＴ５：０００ＵＲ：０５　ＥＶＥＲＹｌ：Ｏ
ＯＪは時間間隔５：００−５：０５，６：Ｇｏ　−６：
０５，７：００−７：０５・・・と同等である。

３、スケジューリング スケジューリング情報も時間指定子フィールド１２３に
より示すことができる。特定のスケジューリング時間は
絶対瞬間または一続きの絶対時間のいずれかで表わすこ
とができる。関心の範囲とは異なり、スケジューリング
時間は時間間隔を含むことができない、その始点および
終点が等しい時間間隔は「瞬間」　（たとえば、（ＴＯ
ＤＡＹ、ＴＯＤＡＹ　）　）に分解する。

時間間隔に適用される規則が幾らかある。過去の時ｒｒ
Ｂ間隔はキーワードＹＥＳＴＥＲＤ＾Ｙ、または過去の
絶対時間により示される始点を備えることができる。同
様に、未来の時間間隔はキーワードｌＯＨＯＲＲＯＭ、
または未来の絶対時間により示される死点を備えること
ができる。また、時間間隔の開始時刻はその終了時刻よ
り早くなければならない。

４、時刻文脈取扱い構造 上に説明したように、関心情報のスケジューリングおよ
び範囲は関連文脈取扱い付き要求により補足することが
できる。取扱いは要求を実行するモジュールにより作ら
れ、続いてサービス提供者との通信に使用される。サー
ビス提供者、たとえば、情報管理器、から呼出しを受け
ると、文脈ブロックが要求時間文脈へのローカル参照と
して発生される。

−ａに、文脈ブロックおよび取扱いは要求の状態の基準
として使用される。初期要求は多数の従属要求を発生す
ることができるので、多数の取扱いおよび文脈ブロック
を単一の要求により作り出すことが可能である６文脈ブ
ロックはサービス提供者により使用される基準であるが
、取扱いはサービス要求者により使用される基準である
。要求／従属要求チェーン内の各プロセス（すなわち、
モジュールまたは情報管理器）はチェーンの局地部分に
関連する文脈ブロックおよび取扱いについてしか知らな
い。

第７Ｂ図を参照すると、特定の一実施例において、要求
者、たとえば、提示モジュール１０により作られた時間
文脈取扱い１７２は、初期要求の時間仕様１２３に関係
する範囲フィールド１７５およびスケジュール・フィー
ルド１７６を備えている。これらフィールドは要求の時
間指定子のデータを補足し、複数の要求および応答が単
一動作に対して存在する場合の現在の状態を決定するの
に使用される。取扱い１７２は文脈ポインタ１７７およ
び状態変数１７８をも備えている。これらデータ項目は
取扱いの状Ｗ！Ａ閏数および基準関数を示すもので、要
求が行われるとき範囲フィールド１７５およびスケジュ
ール・フィールド１７６を用いて作られ、格納される。

単一動作に対して複数の要求および応答が存在する場合
、文脈フィールド１７７は究極的に、文脈ブロックとし
て知られている、別のデータ構造１７４を指すポインタ
を備えることになる。これは、複数の応答を必要とする
初期要求に応じて、サービス提供者、たとえば、情報管
理器の提示・機能曲面１５により作られ、維持される（
機能モジュールおよびアクセス・モジュールも要求に応
じて文脈ブロックを作り、維持することもできる）。

取扱いの状態フィールド１７８は次の三つの値の中の一
つを備えている。　　ｒＦＩＲ３Ｔ　、、ｒＨＯＲＥ、
、またはｒ　ＣＡＮＣＥＬＪで、これらは行うべき更な
る行為を示すフラグとして使用される。最初に作られる
と、取扱い状態はｒＦＩＲ３Ｔ　、にセットされる。

上に説明したように、要求を単一応答で満足させること
ができれば、応答は発生され、要求者に戻される。更に
一般的な場合には、サービス提供者、たとえば、機能モ
ジュール、情報管理器、またはアクセス・モジュールは
一つの回答で要求を満足することができない。たとえば
、要求者は、エンティティのグループを指定するのに、
入力エンティティ・パラメータ１２１にワイルドカード
を使用することができる。各返事は単一エンティティか
らの情報を組込むことができるだけであるから、エンテ
ィティに対して一つづつ、幾つかの返事が必要である。

他の場合には、単一エンティティに対する要求は幾つか
の異なる時間値を持つ時間指定子を備えることができる
。各返事は単一時間値に対する情報を組込むことができ
るだけであるから、時間ごとに一つづつ、幾つかの返事
が必要である。複数の返事を特徴とする請求は、エンテ
ィティまたは複数エンティティについての属性データを
得ること、幾つかのエンティティの属性を修正すること
、および幾つかのエンティティの状態を修正すること、
を含むどんな形式の動作に対するものでもよい。

サービス提供者が要求を処理し、要求が別の返事を持っ
ていることをつぎとめると、これを要求者に示す責任が
ある。その時以来、要求者はサービス提供者が別の返事
をするのを待つ責任がある。

これを行うには、中間プロセス、たとえば、情報管理器
、が発生している要求に関連する情報を貯えておかなけ
ればならない。

この後者の機能は、サービス提供者のディスバッチ・エ
ントリを指すポインタ（下のディスパッチ・テーブルの
標題下の説明を参照）の他に、たとえば、機能モジュー
ルに対する従属要求に関係している取扱いを指す文脈ポ
インタのような、要求に応じて発生した関連専有変数１
７３を備えることができる、文脈ブロック１７４を作る
ことにより達成される。

取扱いおよび文脈ブロックは次のように使用される。サ
ービス提供者は要求者に（１）ポインタ１７７に要求者
の取扱い１７２の、その文脈ブロック１７４を指示させ
、（２〉要求者の取扱い１７２の状態フィールド１７８
をｒＨＯＲＥ、の値にセットする、適切な取扱い修正ル
ーチンを使用して別の返事を所持していることを知らせ
る。返事が要求者に戻ると、要求者はその取扱い状態フ
ィールド内のｒ　ＨＯＲＥ　、状態を見てサービス提供
者がこの要求に対する別の返事を持っていることを知る
。要求者がこれら別の返事を欲しくなければ、要求を取
り消さなければならない（下記を参照）。要求者が別の
返事を欲しければ、パラメータを変えずに要求を反復し
なければならない。

サービス提供者がこれら反復要求（これはｒｈ。

ＲＥＪに等しい取扱い状態フィールド１７８を備えてい
る）を受取ると、適切な取扱いアクセス・ルーチンを使
用してｒ　ＭＯＲＥ　Ｊ状態を探し、検出する。

次にサービス提供者は呼び出しが先に確定した要求の部
分であることを知る。　　（ｒＦＩＲ３Ｔ　、の状態を
持つ取扱いはサービス提供者に関連呼びが要求の最初の
呼出しであることを示すことに注意、）ｒＨＯＲＥ、取
扱い状態を持つ各呼出しについて、サービス提供者は取
扱い文脈フィールド１７７により指摘された文脈ブロッ
ク１７４を検索し、文脈ブロックを使用してその実行を
継続し、別の返事を提供する。サービス提供者に対して
なされる呼出しごとに唯一つの返事が存在する。サービ
ス提供者が取扱いパラメータをｒＨＯＲＥ、状態に保つ
限り、サービス提供者は要求に対する一層多くの返事を
持っている。

サービス提供者が要求者にその最後の返事（たとえば、
要求者の取扱いの中の範囲フィールド１７５およびスケ
ジュール・フィールド１７６により決まる）を戻すと、
要求者の取扱い状態フィールド１７８はｒＦＩＲ３Ｔ　
Ｊ　　（初期設定状Ｂ）の値にセットし戻される。戻し
をこの最後の返事で要求者に対して行うと、要求者はｒ
ＦＩＲ３Ｔ、＋にセットされたその取扱いパラメータ状
態を見、その要求が完全に満足されていることを知る。

要求が単一の返事で満足されるならば、サービス提案者
は文脈を保持せず、ｒ　ＭＯＲＥ　、状態になる取扱い
パラメータの状態を決して発生しないことに注意するこ
と、要求者の取扱いはその初期設定されたｒＦＩＲ８Ｔ
　、の状態に留まり、要求者に要求が完了したことを示
す。

サービス提供者がｒＨＯＲＥＪ状態にある取扱いパラメ
ータを戻すと、要求は反復されるかまたは取消されなけ
ればならない、要求がそうではなくて廃棄されれば、取
扱いおよび文脈ブロックに割当てられた記憶装置のため
に、システム資源が失われることになる。

上の説明について、サービス提供者が従属要求を発生し
なかったとすれば、単一取扱いはサービス要求者と提供
者との通信で充分であることに注意する。しかし、サー
ビス提供者が従属要求を発生したとすれば、二つ以上の
別々の取扱い−呼び出し要求者により発生される初期要
求者の取扱い、およびたとえば情報管理器により作られ
、たとえば、アクセス・モジュールに伝えられる別の取
扱い−が存在することになる。

単一動作に対して複数の要求および応答が存在する場合
には、サービス提供者に対するスケジューリング従属要
求が情報管理器により行われ、時間仕様パラメータ１２
３のスケジュール時間戒分により制御される０時間仕様
により指定される各スケジュール時間に対し情報管理器
はサービス提供者に要求された動作を行わせ応答を発生
させる要求を作り出す。

サービス提供者が要求された動作を完了すると、応答を
発する。情報管理器がサービス提供者が要求された動作
を完了したことを見ると、初期要求について取っである
スケジュール時間文脈を検査する。要求された動作の予
定を組む時間が更に存在すれば、情報管理器は要求者の
取扱い状態をｒＦＩＲ３Ｔ　、にセットせず、ｒＭＯＲ
Ｅ、状態にままにしておく、要求者はその取扱いパラメ
ータが依然ｒＨＯＲＥ、状態にあることを見、要求全部
が完了していないことを知り、残りについて尋ねる０次
に情報管理器は所定のスケジュール時間まで待ち、ディ
スパッチャにサービス提供者への別の呼出しを行わせる
。サービス提供者はこの次の呼出しを、ｒＦＩＲ３Ｔ　
、にセットされたその取扱い状態を戻してからは文脈を
保持していないので、完全に新しい要求の呼出しと区別
することができないことに注意、また、要求者は要求に
対する一層多くの返事を待っているサービス提供者によ
り発生されたｒＨＯＲＥ、の取扱い状態と新しいスケジ
ュール瞬間を準備する情報管理器とを区別しない。

池の実施例では、取扱いアクセス・ルーチンは依頼者に
取扱いパラメータのｒＨＯＲＥＪ状態の発生を確認する
ことができるように増強される。

複数の返事または複数のスケジュールを備えた要求の期
間中、要求者がこの要求に対してサービス提供者からそ
れ以上の返事を欲しくないと決心すれば、要求を取消さ
なければならない、要求を取消そうとする可能な理由に
はそれ以上のデータが有用ではないことを示す例外返事
を受取ること、または所要動作が正しく行われていない
ことを示すエラー条件を受取ること、がある、取消しの
理由は要求者の責任である。取消しは当該動作のスケジ
ューリングおよび範囲を含む、要求のすべての活動を終
結する。

取消しはサービス提供者が要求者にｒＭＯＲＥ。

の取扱いパラメータ状態を戻すときに行うことができる
。要求者は取扱いパラメータ状態をｒＣＡＮＣＥＬ、の
値に変え、呼出しを再発生する適切な取扱い修正ルーチ
ンを使用して取消しを行う。

要求者はこの呼出しに対する他のどんなパラメータをも
変えてはならない、サービス提供者がこの呼出しを受取
ると、予想されたｒＭＯＦｔＥ、状態の代わりにｒｃＡ
ＮｃＥＬＪの状態にある取扱いパラメータを見る。サー
ビス提供者はその文脈を取扱いパラメータから受取り、
その文脈を使用して所要の浄化を行う、この浄化にはそ
れが行っている下位レベルの要求の取消し、すべての処
理の終結、およびシステム資源の返還が含まれる。サー
ビス提供者がその浄化を完了すると、適切な取扱い修正
ルーチンを使用して取扱いパラメータをｒＦＩＲ３Ｔ」
状態に再初期設定して戻す０次にサービス提供者は　　
ＣＡＮＣＥＬＥＤという特殊条件値返戻コードを戻して
要求が順調に取消されたことを示す。

要求者はサービス提供者がｒＦＩＲ３Ｔ、の取扱いパラ
メータ状態を戻してからは要求を取消すことができない
。要求は既に完了しており、取消すサービス提供者の文
脈は存在しない、それ故、上に説明した取消しルーチン
は取扱い状態がｒＭＯＲＥ、でなければエラーを戻さな
い。

Ｆ、ディスパッチ ディスパッチ・テーブル２８は、その一つを第８Ａ図に
示しである複数のデータ構造、およびその一つを第８Ｂ
図に描いであるディスパッチ・エントリを含む一つ以上
のディスパッチ・リスト、を備えている。ディスパッチ
・トリーおよびディスパッチ・リストは、第９図に関連
して以下に説明するように、要求を精査する際に使用さ
れる精査テーブルを本質的に形成している。第８Ａ図を
参照して、ディスパッチ・トリーは複数のエンティティ
・ノード１３０を備えている。エンティティ・ノード１
３０はトリー構造に組織されて精査を補助するが、これ
らは他のデータ＃ｌ造に組織することができる。エンテ
ィティ・ノードはそれと関連して要求を発生することが
できる複合システム内の各種エンティティを識別する。

エンティティ・ノード１３０はそれぞれのディスパッチ
・テーブル１２８に保持されているるディスパッチ・リ
ストのディスパッチ・エントリ１３４（第８Ｂ図〉を指
すポインタを備えている。

「エンティティ・ノード」の語はデータ構造１３０を記
述するのに使用される。というのはこれが上に示したエ
ンティティ・モデルを満足するからである。一般に、デ
ータ構造１３０は、階層構造及びそれに似たその子構造
を備えているため、エンティティ・モデルを満足する。

データ構造１３０を記述するのに使用される「エンティ
ティ・ノードｊの語は、複合システムの要素を記述する
のに使用される「エンティティ」の語と混同してはなら
ない。

エンティティ・ノード１３０は、エンティティ・ノード
１３０がエンティティ・クラスまたはクラス内の段階に
関係するか否かを示すクラス／段階フラグ・フィールド
１４０を含む幾つかのフィールドを備えている。各エン
ティティはクラスの段階であることがあり、クラスはエ
ンティティのエンティティ規定４６（第３Ａ図）で区別
されているクラス名で規定されており、ディスパッチ・
テーブル２４は、第９図とｒＩＩＪ達して下に説明する
ように、クラス及び段階に関連する別のエンティティ・
ノード１３０を備えている。

要求を精査している間、エンティティのクラス名および
段階名およびその属性は第８Ａ図に示す形式のデータ＃
Ｉ造を使用して精査されるが、その構造はクラス名およ
び段階名を精査する際に別々に使用される。クラスまた
は段階の状態はクラス／段階フラグによって示される。

エンティティ・ノード１３０はディスパッチ・テーブル
２８の中の他の各種要素を識別するトリー・リンク・ポ
インタをも備えている。同じクラスの幾つかのエンティ
ティに関係する要求にサービスするモジュールはワイル
カードまたは省略符号により識別することができる。も
しそうなら、これに関連するエンティティ・ノードはフ
ィールド１４１にワイルドカード・ポインタを、または
フィルード１４２に省略符号ポインタを備えている。各
ワイルドカード・ポインタおよび省略符号ポインタは、
以下に記すように、トリー・リンク・エントリから構成
されている。エントリ・ノードが段階のないクラスに関
係していれば、その例を第９図に関連して以下に記述す
るが、フィールド１４３がトリー・リンク・エントリが
ら成る、他のエンティティ・ノードを指すヌル・ポイン
タを備えている。最後に、フィールド１３１はコード・
エントリを備えており、これはエンティティ・ノードば
かりでなくリンク・ポインタにも関連するエンティティ
の段階のクラスまたは名前を識別するコードを備えてい
る。

第８Ａ図のエンティティ・ノード１３０に示したコード
・エントリ・フィールド１３１はコード化リスト内の一
つのエントリである。（リストの残りは図示していない
、）コード化リストは、エンティティの段階のクラスま
たは名前を参照するとき、エンティティの管理仕様（第
３Ａ図から第３Ｄ図までを参照）により規定されるエン
ティティのクラスの名前を備えた連接リストである。各
コード化エントリ１３１はリスト内の次のコード化エン
トリを指すポインタ１５０、クラス・コード／段階各数
値フィールド１５１、およびエントリ・ノード１３０ま
たはディスパッチ・エントリ１３４を指すポインタを備
えたリンク・エントリ１３３を備えているフィールド１
５２を備えている。

コード化エントリ１３１のクラス・コード／段階数値フ
ィールド１５１はクラス・コードかまたは段階名を備え
ている。フィールド１５１の内容は、エンティティ・ノ
ード１３０のクラス／段階フラグ・フィールド１４０が
クラスに関連しているエンティティ・ノードを識別する
ように調節されていればクラス・コードを備えている０
代りに、フィールド１５１の内容は、エンティティ・ノ
ード１３０のクラス／段階フラグ・フィールド１４０が
段階に関連しているエンティティ・ノードを識別するよ
うに調節されていれば段階名を備えている。

第８Ｂ図を参照して、ディスパッチ・リストのディスパ
ッチ・エントリ１３４は要求を処理する特定の手順を識
別するのに使用される。ディスパッチ・リストは一つ以
上のディスパッチ・エントリ１３４の連接リストであり
、各エントリ１３４は要求または従属要求を適切な機能
モジュール１１またはアクセス・モジュール１２に転送
する際に有用な情報を含んでいる。更に詳細に述べれば
、ディスパッチ・エントリ１３４はリスト内の次のディ
スパッチ・エンドトリ１３４を指すポインタ１６０を備
えている。フィールド１６１は機能モジュール１１また
はアクセス・モジュール１２の識別子を備えており、そ
の登録中ディスバッチ・エントリ１３４が発生する。デ
ィスパッチ・エントリ１３４は複合システム内の要求を
処理するための手順、プロセスおよびノードを指す一連
のフィールド１６２から１６４までを備えている。フィ
ールド１６５はディスパッチ・エントリが関係している
動詞を識別し、属性フィールド１６６は管理仕様（第３
Ｂ図）の属性規定フィールド５４により規定される属性
により識別された一組の属性を識別する。最後に、カウ
ント・フィールド１６７はディスパッチャが要求または
従属要求の処理と関連してディスパッチ・エントリ１３
４を使用した回数を識別する。

この背景のもとに、提示モジュール１０からの要求を精
査し発送する際にディスパッチャ１６が行うプロセスを
第９図と関連して述べることにする。ディスパッチャ２
１は機能モジュール１１からの従属要求と関連して同様
なプロセスを行うことがわかるであろう、第９図を参照
して、要求１８０は次のとおりである。

５ｌ（ＯＷ ＮＯＤＢ　＜ｎｏｄｅ　ｎａｌｌｅ　　＞ＲＯＵＴＩＮ
Ｇ ＣＩ　ＲＣＵ　Ｉ　Ｔ　＜　ｒｏｕｔｉｎｇ　ｃｉｃｕ
ｉｔ　ｎａｍｅ　　＞ＣＨＡＲＡＣＴＥＲＩＳＴＩＣ５ これは分布ディジタル・データ処理シルテムと関連して
使用される。要求１８０は、動詞区画１８１、すなわち
５ＨＯＷ、複数のエンティティ・クラスのコードおよび
段階名１８２から１８６から成るエンティティ区画、お
よび複数の属性から成る属性区画１８７を含む、多数の
区画を備えている。この例で、動詞５ＨＯＷは名前の付
いた特性に関係する、要求内で名付けられたエンティテ
ィから応答の発生を開始する。

要求１８０で、エンティティ区画、すなわち、要素１８
２から１８６まで、は多数のクラス／段階対を備えてい
る。特に、要素１８２、ＭＯＤＥ、はクラス・コードで
あり、要素１８３、すなわち、＜ｎｏｄｅ　ｎａＩＩｅ
　＞は、段階名＜ｎｏｄｅ　ｎａｎｅ　＞によりエンテ
ィティ・クラスＮ０ＤＢの段階を識別する。

分布ディジタル・データ処理システム内にノードを識別
する０分布ディジタル・データ処理システムにおいて、
（ｎｏｄｅ　ｎａｍｅ　＞は分布ディジタル・データ処
理システム内のノードを識別する。

その他、要求１８０は更に、エンティティ区画に、段階
を持たないエンティティ・クラス・コード１８４、ＲＯ
ＵＴＩＮＧ、を備えている。他に要求１８０は別のエン
ティティ・クラス・コード、ｅｌＲｃＵＩＴ、を備えて
おり、これは＜ＲＯＵＴＩＮＧ　　ＣＩＲＣＵＩＴ　　
ＮＡＭＥ　　＞により識別される段階を持っている。

管理仕様を描いた第３Ａ図から第３Ｄ図までを参照して
、エンティティに関連する要求の各種要素が管理仕様に
より指定されている。特に、要求の動詞区画１８１は指
令規定５６により規定される指令から取られており、エ
ンティティ・クラス塩およびサブエンティティ・クラス
塩１８２．１８４．１８５はエンティティクラス・コー
ドフィールド４７から取られており、属性区画１８７は
エンティティに対する管理仕様の属性規定５４から取ら
れている。

エンティティおよびサブエンティティの段階名はユーザ
に既知の段階データから（たとえば、構成データベース
を参照して、または自動的に発生したメニューを通して
）取られる。

要求の受領に応じて、ディスパッチャ１６は、エンティ
ティ・ノード１３０（第８図）を使用して、グローバル
・エンティティ・クラス・コード要素１８２から始めて
、まずエンティティ区画内の要素を精査し始める。特に
、第９Ａ図を参照して、ディスパッチャ１６はまず（過
程１９０）クラス・コードと関連しているエンティティ
・ノードを識別するクラス／段階フラグ１４０を備えて
いる根元エンティティ・ノードから始め、ＭＯＤＥのク
ラス・コードを備えたクラス・コード・フィールド１５
１を備えているコード化エントリを含んでいるそのコー
ド化リスト１３１のエントリを探す、ディスパッチャ１
６がディスパッチ・テーブル２８でこのようなエントリ
を見つけることができなければ、ディスパッチャ１６は
ワイルドカード又は省略符号ポインタを探す（下記を参
照）（ワイルドカードまたは省略符号ポインタが見つか
らなければ、要求を受取ったモジュール１０に対してエ
ラーで応答する。） ディスパッチャ１６がこのようなエンティティ・ノード
１３０をディスパッチ・テーブル２８の中でつき止める
と、精査動作の次ぎの過程（過程１９１）に進み、ここ
で、エンティティ要素１８３で指定された段階（ｎｏｄ
ｅ　ｎａＩＩｅ　）と関連するエンティティ・ノード１
３０をつき止めようとする。この動作で、ディスパッチ
ャ１６はコード化エントリ１３１のポインタ・フィール
ド１５２の内容を使用して、段階名と関連しているエン
ティティ・ノードを識別しそのコード化リストがその段
階名エントリを要求１８０のエンティティ要素１８３の
（ｎｏｄｅ　ｎａＩｌｅ　＞に対応しティるコート化エ
ントリを備えているクラス／段階フラグ１４０を持つエ
ンティティ・ノードをつき止める。再び、ディスパッチ
ャ１６がこのようなノードをディスパッチ・テーブル２
８でつき止めることができなければ、ワイルドカードま
たは省略符号ポインタを探す（下記を参照）。

他方、デスバッチャ１６が過程１９１で、デスパッチ・
テーブル２８の中に要素１８３と関連するエンティティ
・ノードをつき止めると、次の過程（過程１９２）に進
み、ここでクラス・コード１８４、ＲＯＵＴＩＮＧ、と
関連するエンティティ・ノードをつき止めようとする。

この動作で、ディスパッチャ１６はコード化エントリ１
３１のフィールド１５２のポインタおよび要求からのエ
ンティティ要素ＲＯ１ＪＴＩ　ＮＧを使用して、クラス
・コードと関連しているエンティティ・ノードを識別し
そのコード化エントリ・リストがＲＯｌＪＴＩＮＧを備
えたクラス・コード・フィールド１５１を備えているコ
ード化エントリ１３１を備えている、クラス／段階フラ
グ１４０を備えたエンティデイ・ノード１３０をつき止
める。この状況においては、エンティティ・クラスＲＯ
ＵＴ　Ｉ　ＮＧは段階の無いエンティティ・クラスであ
るから、コード化エントリ１３１のポインタ・フィール
ド１５２はヌルである。この場合、エンティティ・ノー
ド１３０のヌル・ポインタ・フィールド１４３はクラス
・エンティティＣＩＲＣＵＩＴに関連する第２のエンテ
ィティ・ノード１３０を指す。

過程１９２で、ディスパッチャ１６は過程１９２でつき
止めたＲＯＵＴＩＮＧクラス・エンティティに間通する
エンティティ・ノード１３０のヌル・ポインタを使用し
て、そのクラス／段階フラグ１４０がクラス・コードと
関連していることを示す第２のエンティティ・ノード１
３０およびそのクラス・コード・フィールド１５１がＣ
ＩＲＣＵＩＴを備えているコード化エントリ１３１を備
えているコード化リストをつき止める（過程１９３）、
ディスパッチャがこのようなエンティティ・ノードをつ
き止めることができなければ、ワイルド−カードまたは
省略符号ポインタを探す（下記を参照）。

他方、ディスパッチャ１６が過程１９３でエンティティ
・ノード１３０をつき止めれば、過程１９４に進み、こ
こで段階エンティティ要素（ＲＯｌＪＴＩＮＧ　　ＣＩ
ＲＣＵＩＴ　　ＮＡＭＥ＞を識別するエンティティ・ノ
ード１３０をつき止めようとする。この動作で、ディス
パッチャ１６はコード化エントリ１３１のフィールド１
５２のポインタを使用して、そのクラス／段階フラグ１
４０がこれを段階名に関連しているとして識別しそのコ
ード化リストがその段階名フィールド１５１が要求１８
０の段階エンティティで指定された（ＲＯＵＴＩＮＧ　
　ＣＩＲＣＵＩＴ　　ＮＡＭＥ）を備えている、エンテ
ィティ・ノード１３０をつき止める。ディスパッチャ１
６がこのようなエントリをつき止めることができなけれ
ば、ワイルドカードまたは省略符号ポインタを探す（下
記を参照）。

他方、ディスパッチャ１６が、過程１９４で、段階エン
ティティ要素１８６を識別する段階エンティティ・ノー
ド１３０をつき止めれば、ディスパッチャ１６は要求１
８０のエンティティ区画１８２から１８６までを順調に
精査したことになる。

その後で、ディスパッチャ１６は過程１９４でつき止め
られたコード化エントリ１３１のフィールド１５２のポ
インタｌ）詞要素１８１の動詞、および要求の゛特性要
素１８７の属性を使用して要求の処理に使用すべきディ
スパッチ・エントリ１３４（第８Ｂ図〉を識別する。特
に、過程１９４に続いて、ディスパッチャ１６はコード
化エントリ１３１のフィールド１５２のポインタを使用
してディスパッチ・エントリ１３４のリストを識別する
。その後で、ディスパッチャ１６はその動詞フィールド
１６５の内容が要求１８０の動詞要素１８１、この場合
には５ＨＯＷ、に対応しており、その属性フィールド１
６６の内容が特性要素１８７の属性と対応している、デ
ィスパッチ・エントリ１３４をつき止めようとする。

ディスパッチャ１６が、過程１９５で、このようなディ
スパッチ・エントリ１３４をつき止めれば、手順識別フ
ィールド１６２、プロセス識別フィールド１６３、およ
びノード識別フィールド１６４、の内容を使用して要求
を処理する手順を呼出す、この動作で゛、ディスパッチ
ャ１６は要求を処理用エンティティに効果的に転送する
。第６図に関連して述べたように、フィールド１６３の
プロセス識別子およびフィールド１６４のノード識別子
がディスパッチャに間係する以外の他のプロセスまたは
ノードを識別すれば、ディスパッチャは要求を、処理の
ため、それぞれのフィールド１６３および１６４で識別
された、他のプロセスまたはノードのディスパッチャに
転送する。

上にのべたのはディスパッチ・テーブルのコード化エン
トリの使用法である。ワイルドカードおよび省略符号ポ
インタは別の機能性をテーブルに提供する。ｇ４えば、
一つの管理モジュールは特定のグローバルまたは従属の
エンティティ・クラスのモジュールに対するすべての要
求を取り扱うことができる。ワイルドカードおよび省略
符号ポインタが無ければ、クラスの段階およびサブクラ
スの段階はすべてディスパッチ・テーブルに列挙されて
いることになろう、これを避けるには、ワイルドカード
および省略符号を設け、ディスバッチ仕［３９Ａで仕様
できるようにして一般的方法でどのエンティティ・クラ
スまたは段階が管理モジュールをサービスするかを示す
ようにする。

この様なディスパッチ仕様の一例は、 Ｎ０ＤＤＥ　　ＲＯＵＴＩＮＧ　　ＣＩＲＣＵＩＴであ
り、これはモジュールがＮ０ＤＥクラスのグローバル・
エンティティのすべての場合、サブエンティティ・クラ
スＣＩＲＣＵＩＴのすべての場合能のＣＩＲＣＵＩＴク
ラス・サブエンティティのすべてのサブエンティティに
対しても取り扱うことができることを示している。アス
テリスク（＊）はどんな段階名にも適合し、省略符号（
・・・）は次に続くことがあるサブエンティティの段階
またはサブエンティティのクラス／段階対のすべてに適
合する６例えば、表現 Ｎ０ＤＥ　　ｆｏｏ　　ＲＯＬＪＴＩＮＧ　　ＣＩＲＣ
ＩＪＩＴ　　ｂａｒ　　ＬＩＮＫ　　ｆｒｅｄはデイス
スバッチ仕様に適合する。何故なら「ゝ」がｒｆｏｏ」
に適合し、ｒ　、、、　、がｒｂａｒ　　ＬＩＮＫ　　
ｆｒｅｄＪｉ適合するからである。

第９Ｂ図を参照して、ディスバッチ・テーブル２８のワ
イルドカード・ディスバッチ仕様に入るには、過程１９
１（第９Ａ図）の、Ｎ０ＤＥクラス・エンティティの段
階名に対応する、エンティティ・ノード１３０を修正す
ることになる。ワイルドカード・ポインタ１４１は、そ
の一つがクラス・コードＲＯｔＪＴＩＮＧであるクラス
・コードを含んだ新しいエンティティ・ノード１３０を
指すように変えられる（過程１９６）、クラス・コード
ＲＯＵＴＩＮＧに関係する子ポインタはヌルとなり（過
程１９２（第９Ａ図）と同様）、ヌル・ポインタは、ク
ラス名前ＣＩＲＣＵＩＴに対応する子ポインタを備える
ことになる池の新しいエンティティ・ノード１３０を指
す（過程１９７＞。

この子ポインタは他の新しいエンティティ・ノード１３
０を指すことになり（過程１９８）　、その省略符号ポ
インタはモジュールに対するディスバッチ・エントリを
指す（過程１９９）。

修正テーブルの精査は、過程１９１までは第９Ａ図によ
り説明したものと同である。過程１９１で、ディスパッ
チャ１６は名前、たとえばｒｆ。

Ｏ」を持つＮ０ＤＥクラスの段階を探す、この名前がコ
ード化エントリ（例示目的で三つを示しである）で見つ
かったならば、ディスパッチャはコード化エントリの子
ポインタにしたがって進む。

しかし、名前ｒｆｏｏ」がコード化エントリ（最後のコ
ード化エントリのヌルＮＥＸＴ　　ＥＮＴＲＹポインタ
により示される）の中に見つからなければ、ディスパッ
チャは過程１９１で非ヌル・ワイルドカード・ポインタ
を探す、ワイルドカード・ポインタをつき止めてから、
ディスパッチャは過程１９６に進む。

過程１９６および１９７は第９Ａ図の過程１９２および
１９３と同である。ディスパッチャは過程１９６で（ク
ラス・コードｒＲＯ１ＪＴＩＮＧ。

に対応する）ヌル・ポインタを使用して過程１９７に移
動し、クラス・コードｒＣＩ　ＲＣＵ　Ｉ　Ｔ。

に対応する子ポインタを使用して過程１９８に移動する
。

過程１９８で、ディスパッチャはコード化エントリ（例
示の目的で三つを示しである）の連接リストを探し、ｒ
ｂａｒ」という段階名をつき止める。この名前がコード
化エントリ内に見っがらなければ、ディスパッチャは非
ヌル・ワイルドカード・ポインタを探す、これが見つか
らなければ、ディスパッチャは非ヌル省略符号ポインタ
を探す。

これはつきとめられ、ディスバッチ・エントリまで４ｆ
ｉ断するのに使用される（過程１９９）。ディスバッチ
・エントリの内容は適切なモジュールを呼出するのに使
用される。

ワイルドカードおよび省略符号ポインタによりエンティ
ティ・クラス・コードおよび段階名の一般的適合が可能
になるが、ディスバッチ・テーブルのコード化エントリ
がチエツクされてからに限られる。このようにして、デ
ィスパッチャはエンティティ名の「最も明確な適合」を
探ず、それ故、例えは、最初のモジュールはディスパッ
チ仕様Ｎ０ＤＥ　　　ＲＯＵＴＩＮＧ　　　ＣＩＲＣＵ
ＩＴを備えることができる。これはモジュールがＮ。

ＤＥクラス・グローバル・エンティティの段階ｒＪｏｅ
」に対して、ＲＯＵＴＩ　ＮＧクラス・サブエンティテ
ィのすべてのＣＩＲＣＵＩＴクラス・サブエンティティ
のすべての段階を取り扱うことができることを示してい
る。第２のモジュールはディスパッチ仕様 Ｎ０ＤＥ　　Ｊｏｅ　　ＲＯＵＴＩＮＧ　　ＣＩＲＣＵ
ＩＴ・・・ を備えることができる。これはモジュールがＮ。

ＤＥクラス・グローバル・エンティティの段階ｒＪｏｅ
」に対して、ＲＯｌＪＴＩ　ＮＧクラス・サブエンティ
ティのすべてのＣＩＲＣＵＩＴクラス・サブエンティテ
ィのすべての段階を取り扱うことができることを示して
いる。

「最も明確な適合Ｊの規則に矛盾しないためには、Ｎ０
ＤＥ　　Ｊｏｅ　　ＲＯＵＴＩＮＧ　　ＣＩＲＣＵＩＴ
サブエンティティに対するすべての指令を第２のモジュ
ールに送るべきである。これはディスパッチ・テーブル
機構を用いて達成される。

何故なら、段階名ｒＪｏｅ」は過程１９１でコード化エ
ントリに現れるので、ｒｊｏｅ」はＲＯＵＴＩＮＧ　　
ＣＩＲＣＵＩＴに対する要求の中の段階名であれば、「
ｊＯｅ」コード化エントリが使用されることになり（そ
れが最初にチエツクされるから）、ワイルドカード・ポ
インタが使用されなくなるからである。

ディスパッチ・トリーを正しく精査するには、ディスパ
ッチャはスタックをも使用しなければならない。これが
必要な理由を簡単な例で説明することにする。ディスパ
ッチ仕様 Ｎ０ＤＥ　　ｊｉｍ　　ＤＩＳＫＤＲＩＶＥ−を備えて
いる新しいモジュールを考える。これはモジュールが、
Ｎ０ＤＥクラスのグローバル・エンティティの段ｔｉｌ
ｔ’Ｊｉｍ」に対して、ＤＩＳＤＲＩＶＥクラスのサブ
エンティティのすべての段階を取り扱うことができるこ
とを示している。この仕様は過程１９１で第９Ｂ図と同
様の方法で、コード化エントリに段階名ｒＪｉｍ」を付
加し、続いて新しいエンティティ・コードを付加するこ
とによりトリーに入れられる。これに続いて、要求をグ
ローバル・エンティティ・クラスおよび段階名 Ｎ０ＤＥ　　　Ｊｉｍ を用いて発送すると、ディスパッチャは新しいエンティ
ティ・ノードまで移行する。

しかし、 Ｎ０ＤＥ　　Ｊｉｍ　　ＲＯＵＴＩＮＧ　　ＣＩＲＣＵ
ＩＴ で始まるエンティティ名を持つ要求は、新しいモジュー
ルがＮＵＤＥ段階’ｊｉｍ」に対してＤＩＳＫＤＲＩＶ
Ｅクラスのサブエンティティしか支援しないので、新し
いモジュールからサービスを受けることはできない、そ
れ故、ディスパッチャがクラス名ＲＯＵ’Ｔ’ＩＮＧ　
　ＣＩＲＣＵＩ’Ｔ’が新しいモジュールで支援されな
いことを確認したら、過程１９１に戻り他のコード化エ
ントリまたはワイルドカードまた省略符号ポインタを随
意選択的に使用してｒＮＯＤＥ　　ｊｉｍ　　ＲＯＵＴ
ＩＮＧＣＩＲＣＵＩＴＪ要求にサービスするモジュール
を見つけるｎ＃Ｊを備えなければならない、それ故、デ
ィスパッチャがディスパッチャ・テーブルを横断するに
つれて、ディスパッチャはポインタのスタックを、根元
ノードからｍ断してしまったエンティティ・ノード１３
０のすべてに対して維持する。ポインタはディスパッチ
・テーブルのトリー構造を通して上下に動くにつれてこ
のスタックに押しつけられたりかじき出されたりして適
切なディスパッチ・エントリを見つけようとする。

適合するディスパッチ・エントリが見つからなければ、
エラーが要求者（すなわち、提示モジュールまたはａ能
モジュール〉に戻される。

上に説明したように、制ｇＩｅｘ能モジュールはパスス
ルーとして提示モジュールから直接アクセス・モジュー
ルヘサービスすることができる。このようなパススルー
を実現するには、ディスパッチ・テーブル（これはどん
な要求のどんなエンティティの名前にも適合する）の提
示９機能局面の根元ノードに対する省略符号ポインタは
制御機能モジュールに対するディスパッチ・エントリを
指すべきである、要求を受取ると、制御機能モジュルは
単に同じ要求をディスパッチャの機能アクセス・局面に
発する。この仕方により、提示・機能ディスパッチ・テ
ーブル内のディスバッチ仕様に適合しないすべての要求
の適合のため機能・アクセス・ディスバッチ・テーブル
に伝えられる。これにより提示モジュールの要求がアク
セス・モジュールから利用可能な原始機能にアクセスす
ることができる。

ディスパッチ・テーブルの別の実施例においては、段階
を備えていない二つ以上のクラス・コードを許容するた
め、ヌル・ポインタ・フィールド１４３がコード化エン
トリ１３１のリストと構造的に同様な連接リストの最初
の要素を備えることができる。第２の、「ヌル」リスト
は段階を備えないクラス・コードのコード値を備えるこ
とになる。ヌル・リストはコード・リストの後、ワイル
ドカードをチエツクする前に精査される。

Ｇ、領域および構成 上述のように、構成機能モジュール１１は複合システム
を構成するエンティティを規定する構成データベースを
保持している。オペレータからの適切な命令により、構
成機能モジュール１１は、データ辞書により規定された
エンティティの段階を構成データベースに加え、これら
を構成データベースから削除し、構成データベース内の
規定を変史することができる。上にも記したとおり、領
域機能モジュール１１は梢或データベース内に既に規定
されているエンティティのサブセットを参照する、構成
データベース内の領域エンティティを確立する。オペレ
ータは、提示モジュール１０を通して、特定の領域から
成るエンティティを、複合システムを構成する恐らく無
数の他のエンティティを考慮せずに、制御し、監視する
ことができる。その他に、オペレータは領域内のエンテ
ィティだけに関連して、エンティティごとに提示モジュ
ール１０により要求の発生を開始させることなく、制御
または監視の動作を開始し、これにより複合システムの
制御および監視を簡単化することができる。

領域機能モジュールは、構成データベース内または構成
データベースに加えて領域エンティティを構成するエン
ティティを識別する各領域エンティティ相領域データベ
ースを確立する。Ｗｉ切な要求を受取ると、領域機能モ
ジュール１１はエンティティを領域データベースに加え
、これにより領域にエンティティを加え、エンティティ
を領域データベースから削除し、これにより領域からエ
ンティティを削除し、領域データベースに規定された領
域を構成するエンティティを識別する応答を発生し、領
域データベースを削除し、これにより領域を効果的に削
除する。

第９Ｃ図を参照すると、構成データベースおよび領域デ
ータベース（これらは単一データベースに合体すること
ができる）のフォーマットが構成内の各エンティデイ段
階の、および同様に、領域内の各エンティティ段階の、
フィールドを備えている。

領域データベースは領域の各メンバーに対するエントリ
２３０を備え、エントリまたはサブエンティティの各メ
ンバーの領域名および段１１Ｒ名をリストしている。そ
の他に、領域データベースは領域のメンバーである各エ
ンティティに対するエントリ２３２を備え、各段階名お
よびそれがメンバーである領域をリストしている。領域
機能モジュールはこの情報を領域が修正されるとき更新
し、この情報を利用して領域のメンバーを迅速に決定し
、または代りに、エンティティの領域メンバーを迅速に
決定することができる。

別の実施例では、第１の領域は第２の領域を参照するこ
とにより第２の領域のメンバーを組込むこことができ、
このよにして領域データベースの大きさを小さくしてい
る。他の実施例では、領域データベースはエンティティ
およびサブエンティティの階層と同様の領域の階層を確
立することができ、命令は領域およびサブ領域と同様に
伝えることができる。

構成データベースは、各エンティティおよびサブエンテ
ィティに対する、データベース内に階層的に組織された
、エントリ２３４を備えている。

各エンティティおよびサブエンティティ段階についてフ
ルネームが設けられている。この情報は構成機能モジュ
ールが、たとえばユーザに構成のマツプまたはエンティ
ティの段階名のメニューを（提示モジュールを経由して
）表示する構成を迅速に決定するのに使用することがで
きる。

Ｈ，Ｗ報 上に第１図に関連して説明したように、一つの機能モジ
ュール１１は警報機能モジュール１１を備えているが、
これは、提示モジュール１０からの要求に応じて、警報
条件を確定し、複合システムのエンティティの、たとえ
ば、ユーザ・インターフェース情報ファイル２９に記録
された各種条件を使用して、警報条件の発生を検出する
ことができる。

第１０Ａ図は警報機能モジュール１１の機能組織を示す
、第１０Ａ図を参照して、警報ａ能モジュール１１は、
モジュールから要求を受取り、これを翻訳して一つ以上
の検出器モジュール２０１または一つ以上の規則保守モ
ジュール２０２がこれに応じて動作できるようにする総
合警報モジュール２００を備えている。上に示したよう
に、警報機能モジュールは二つの一般形式の動作、すな
わち、警報条件の保守、および警報条件の検出、を行う
。

警報機能モジュール１１の警報条件の保守の動作は規則
保守モジュール２０２に行われる。このモジュールは、
警報規則ベース２０３により、各警報条件を識別する規
則を保守する。各規則は警報条件の有無を決定するのに
評価しなければならない条件の集合を表わす、特に、規
則保守モジュール２０２は、提示モジュール１０からの
要求に応じて、第１０Ｂ図と関連して以下に説明するよ
うに、規則を発生し、これは警報規則ベース２０３に格
納される。加えて、規則保守モジュール２０２は、提示
モジュール１０からの対応する要求に応じて、警報規則
ベース２０３の中の規則を修正することができ、これに
より、規則によって表わされた警報条件が存在する条件
が修正される。

同様に、警報条件の検出の動作は検出器モジュール２０
１により行われるが、このモジュールは、たとえば、歴
史的データ・ファイル（第５図〉にある条件情報、およ
び警報規則ベース２０３にある警報規則を使用する。第
１０Ｂ図と関連して以下に述べるように、各規則は条件
を識別する条件部分を備えている。検出器モジュール２
０１は、警報条件を検出するのに、たとえば、歴史的デ
ータ・ファイルの内容が各種規則の条件に適合している
か否かを決定する。もし適合していれば、検出器モジュ
ール２０１は警報指示を発生し、総合警報モジュール２
００により通知モジュール２０４を経由して、たとえば
、提示モジュールｌＯに転送し、オペレータに表示する
。

規則保守モジュール２０２により発生される警報規則の
一般形を第１０Ｂ図に示す、第１０Ｂ図を参照して、警
報規則は条件部分２１０を備えており、これは警報の指
示に必要な条件の集合を示す。条件部分は式部分２１２
、関係運算子２１３゜および式数値部分２１４を備えて
いる。関係運算子２１３は式部分２１２を式数値部分２
１４と関係づけ、条件部分２１０が論理的にＴＲＵＥ　
（真）が論理的にＦＡＬＳＥ　（偽〉かに評価するよう
にする０式部分２１２自身が論理的ＴＲＵＥか論理的偽
かに評価すると、関係演算子２１３、および条件部分２
１０の式数値部分２１４が不要であることがわかるであ
らう、いずれの場合においても、条件部分が論理的ＴＲ
ＵＥに評価すれば、警報条件が存在する。

規則はエンティティおよび属性部分２１２、および時間
値部分２１６を備えている。ｒｅｌ−Ｏｐ値部分２１３
は一つの属性の値を一つの数値部分２１４と関連づける
０時間値部分２１６は時間関数を確立し、条件部分２１
０を警報検出器モジュール２０１が使用すべき時間また
は時間間隔を示すことができる。

警報ｆｉ能モモジュール１を設けると、オペレータが動
的にまた必要に応じて警報条件を確定することができる
。Ｖ報条件は制御装置内であらかじめ確定する必要はな
いから、制御装置を広範多様な複合システムを制御し監
視するのに使用することができる、たとえば、制御装置
を、ネヅトワークにより通信する多様な構成のノードを
備えていることがある分布ディジタル・データ処理シス
テムを制御し監視するのに使用する場合には、警報条件
を特定の構成に基づいてオペレータにより確立すること
ができる。その他、複合システムの動作中に新しい警報
条件を発見すれば、規則を警報規則ベース２０３に追加
することにより警報条件を追加することができる。

エンティティの集団に対して制御を行い、管理を行うシ
ステムについて述べるが、このシステムにおいて、エン
ティティが集団とインターフェースして主要情報処理機
能を制御すると共にエンティティは更にシステムとイン
ターフェースして管Ｉｇ！機能を行うことができるよう
にする。このようなシステムは所定の管理関連命令を独
立に翻訳し実行することにより管理機能を行うようにな
っている格納管理モジュールを備えており、カーネルは
命令を翻訳し実行すべきそれぞれのモジュールに命令を
向けるディスバッチ・ポインタのテーブルを格納してお
り、登録器は別のポインタをテーブルに追加することに
より新しい管理モジュールをシステムに登録するのに使
用される。

エンティティの集団に対して制御を行い、管理を行うシ
ステムについて更に述べるが、このシステムにおいて、
エンティティは集団とインターフェースして主要情報処
理機能を制御すると共にエンティティは更にシステムと
インターフェースして管理機能を実行することができる
ようにする。

このような別のシステムは所定の管理関連命令を独立に
翻訳し実行することにより管理機能を行うようになって
いる格納管理モジュールを備えており、カーネルは命令
が翻訳され実行されるそれぞれのモジュールに命令を向
けるディスパッチ・ポインタのテーブルを格納する。

エンティティの集団に対して制御を行い、管理機能を行
うシステムについて更に別に述べるが、このシステムは
所定の管理関連命令を独立に翻訳し実行するようになっ
ている格納管理モジュールを備えており、カーネルは命
令を翻訳し実行すべきそれぞれのモジュールに命令を向
けるディスバッチ・ポインタのテーブルを格納しており
、登録器は別のポインタをテーブルに追加することによ
り新しい管理モジュールをシステムに登録するのに使用
される。

このようなシステムに対する代案はエンティティから一
つ以上の状態情報を要求し、エンティティの管理パラメ
ータを修正し、またはエンティティの自己試験モードを
可能にするようになっている管理モジュールを備えるこ
とができる。格納管理仕様情報は、任意の管理可能なエ
ンティティの属性および動作を表わす共通構文を持つ万
能指定言語にしたがって、エンティティの機能および制
御に関連する属性、およびエンティティの管理機能をリ
ストする。管理仕様情報は更に他のエンティティに従属
するエンティティの属性および動作をリストすることが
できる。管理仕様情報は共通構文の所定のフィールドに
ポーリング情報を備えることができる。ポーリング情報
は属性の値をエンティティから要求すべきデフォルト速
さおよび最大ポーリング遠さを指定するツーイールドを
備えることができる。

システムについて更に述べるが、このシステムにおいて
、管理仕様情報は共通構文の所定のフィールドに区画情
報を備えることができ、区画情報は共通のデータ形式を
持つ属性のグループを表わす、管理仕様情報は共通構文
の所定のフィールドに集合情報を備えることができ、集
合情報はエンティティの管理で関連機能を持つ属性のグ
ループを表わす、管理仕様情報は共通構文の所定フィー
ルドに命令情報を備えることができ、命令情報はエンテ
ィティが行うようになっている管理機能、エンティティ
に対して発すべき命令のＭＷｉ、および受取るべき返事
の１１１１造をリストしている。また発すべき要求の構
造は命令に対する引数をリストするフィールドを備える
ことができる。また、受取るべき返事の構造は要求され
た動作が順調に完了したことを示すのに使用するフィー
ルドを備えることができる。

更に代案を記述するが、この代案では受取るべき返事の
構造が要求された動作を順調に完了させないエラー条件
を示すのに使用されるフィールドを備えることができる
。少なくとも一つの管理モジュールが一つ以上のエンテ
ィティと通信するプロトコルを実施するアクセス・モジ
ュールを備えている。プロトコルはエサーネヅト規格に
適合しており、またはプロトコルはＤＥＣｎｅｔ　　Ｐ
ｈａ　ｓ　ｅ　ＩＶ規格に適合しており、またはプロト
コルはＤＥＣｎｅｔ　　Ｐｈａｓｅ■規格に適合してい
る。

他の代替案を説明するが、これでは各命令が少なくとも
一つの関連エンティティおよび動作をリストするフィー
ルドを備えている。カーネルはそこにリストされたエン
ティティおよび動作に少なくとも基づいて命令を受取り
伝達するディスパッチャを備えている。ディスパッチ・
ポインタのテブルはデータ構造、命令のフィールドに対
応するグラフによる連続データ構造の、指示グラフを備
えることができる。ディスパッチャは命令にリストされ
たエンティティおよび動作にしたがって指示グラフを精
査し、ディスパッチ・ポインタを備えた端末データ構造
をつきとめる精査器を備えている。指示グラフは命令の
特定のフィールドのどんな値にも対応することができる
ワイルドカド・フラグ、および連続データ構造を備える
ことができ、または指示グラフは命令のフィールドのど
んな数の値にも対応することができる省略符号フラグ、
および連続データ構造を備えることができ、または精査
器は、最初フィールドに対する正確な適合を、次にフィ
ールドに対する正確なワイルドカード適合を探すことに
より、命令のフィールドに対する最も正確な適合を決定
する最良適合ユニットを備えることができる。

このようなシステムに対する代替案は、最初フィールド
に対する正確な適合を、次にフィールドに封する省略符
号適合を探すことにより、命令のフィールドに対する最
も正確な適合を決定する最良適合ユニットを備えた精査
器を備えている。指示グラフは、命令の特定のフィール
ドのどんな値にも対応することができるワイルドカード
・フラグおよび連続データ構造、および命令のフィール
ドのどんな数の値にも対応することができる省略符号フ
ラグ、および連続データ構造を備えることができ、精査
器は、最初フィールドに対する正確な適合を、次にフィ
ールドに対するワイルドカード適合を、次いでフィール
ドに対する省略符号適合を、探すことにより、命令のフ
ィールドに対する最も正確な適合を決定する最良適合ユ
ニットを備えている。提示装置はユーザに情報を表示し
、ユーザから命令を受取るのに使用され、命令および情
報は特定の所定のフォーマットで表わされている。

更に別の代替システムは、提示装置から命令を受取り、
情報を提示装置に伝える提示モジュールを使用し、提示
モジュールは、エンティティから受取った情報を提示装
置用の所定フォーマットに変換する変換コード、および
命令を提示装置からディスパッチヤに伝える伝達コード
を含んでいる。

提示モジュールはユーザがシステムと対話するモードを
規定するユーザ・インターフェース情報を備えることが
できる。ユーザ・インターフェース情報はユーザにシス
テムの使い方に関する情報を提供する援助情報を備える
ことができる。ユーザ・インターフェース情報はポツプ
アップ・メニューの内容および命令行精査テーブルを規
定するグラフィク・モード情報を備えることができる。

カネルは更にそれぞれのエンティティから利用できる異
なる管理情報を規定するクラス・データベスを備えるこ
とができる。提示モジュールはデータをクラス・データ
ベースから抜き出し、ユーザに表示する有効命令のメニ
ューを発生ずるメニュー発生ルーチンを備えることがで
きる。メニュ発生ルーチンは、集団の構成に関連する情
報を決定し、ユーザに表示する利用可能なエンティティ
のメニューを発生するようにすることができる。

コンピュータ・ネットワークのメンバーに対して制御を
行い、管理機能を行うシステムについて記述するが、こ
のシステムでは、メンバーはネットワーク内部でインタ
ーフェースして主要情報処理１１能を制御すると共に、
メンバーは更にシステムとインターフェースして管理機
能を行うことができるようにする。このようなシステム
は、所定の管理関連命令を独立に翻訳し実行することに
より管理機能を行うようになっている格納管理モジュー
ル、命令を翻訳し実行すべきをそれぞれのモジュールに
命令を向けるディスバッチ・ポインタのテーブルを格納
するカーネル、別のポインタをテーブルに追加すること
より新しい管理モジュールをシステムに登録するのに使
用される登録器、を備えている。登録器はシステムの動
作中の任意の時刻に新しい管理モジュールを登録するよ
うになっている。このようなシステムに対する代替案は
、記憶装置メンバーが、各記録が関連時間の指示を含ん
でいる、管理機能に関連する記録を格納する、システム
について述べている。命令は時間範囲を指定し、情報管
理器が、可能な場合、記録に含まれている管理情報を検
索することにより命令を満足し、その他の場合には、ネ
ットワークのメンバーから指定された時間範囲に関係す
る情報にアクセスすることにより命令を満足する手段を
備えている。このようなシステムに対する別の代替案は
、少なくとも一つのモジュールが所定の警報条件を識別
する規則を格納するが、規則を発生して格納する規則発
生器および規則の内容に応じて警報条件を検出する警報
条件検出器を備えている。第１のカテゴリの管理モジュ
ールはネットワークのメンバーから示されたデータの機
能操作全行うようになっている機能モジュールを備えて
いる。第２のカテゴリの管理モジュールはネットワクの
メンバと通信するプロトコルを実施するようになってい
るアクセス・モジュールを備えている。提示モジュール
はネットワークのメンバーの主要情報処理機能を使用し
てユーザから命令を受取り、ユーザに情報を伝えるよう
になっている。

記憶装置は更にネットワークのメンバーのグループを規
定する領域指定情報を備えている。カーネルは個々の命
令を適切な管理モジュールに発することによりグループ
のすべてのメンバーに命令を発するようにすることがで
きる。少なくとも一つの管理モジュールは更に自己管理
命令を独立に翻訳し実行することにより自身に対して自
己管理機能を行うようになっている。情報管理器は更に
時間スケジュールを指定する命令に応答するスケジュー
ラを備えている。スケジューラは時間スケジュールにし
たがって恐らくは複数回命令に応じて一続きの従属アク
セスまたは検索をおそらく可能にするのに使用される。

エンティティの集団に対して制御を行い、管理機能を行
うプロセスについて記述するが、このプロセスでは、エ
ンティティが集団にインターフェースして主要情報処理
機能を制御すると共に、エンティティは更に管理Ｒ能を
行うことができるようにする。プロセスの過程は、所定
の管理関連命令を独立に翻訳し実行することにより管理
機能を行うようになっている管理モジュールを設ける段
階、命令を翻訳し実行すべきそれぞれのモジュールに命
令を向けるディスバッチ・ポインタのテーブルを備えた
カーネルを設ける段階、および別のポインタをテーブル
に追加することにより新しい管理モジュールをシステム
に登録する登録器を設ける段階、から構成される。

エンティティの集団に対して制御を行い且つ管理機能を
行うシステムに使用するため、所定の管理関連命令を独
立に翻訳し実行することにより管理機能を行うように格
納されるようになっている、管理モジュールについて述
べるが、これにおいてエンティティは集団内部にインタ
ーフェースして主要情報処理機能を制御すると共に、エ
ンティティは更にシステムとインターフェースして管理
ｌｌ能を行うことができ、システムは複数の管理モジュ
ール、および命令を翻訳し実行すべきそれぞれのモジュ
ールに命令を向けるディスバッチ・ポインタのテーブル
を備えたカーネル、を備えている。モジュールを指し、
モジュールにより翻訳され実行される命令に関連する、
ディスバッチ・ポインタについても述べである。

【図面の簡単な説明】

第１Ａ図は本発明にしたがって構成した制御装置の機能
ブロック図である。 第１Ｂ図は第１Ａ図の記憶装置要素に格納されている情
報のブロック図である。 第２Ａ図は第１Ａ図に示す制御装置の一部の、特に制御
装置を構成するエンティティを規定する部分の、機能ブ
ロック図である。 第２Ｂ図は管理モジュールの構造を示す。 第３Ａ図から第３Ｄ図は第１Ａ図に示す制御装置を構成
する機能モジュール及びアクセス・モジュールにより提
供される管理図を規定する管理仕様を規定しており、第
３Ｅ図は機能モジュール及びアクセス・モジュールに対
するディスパッチ仕様を規定する。 第４図は第３Ａ図から第３Ｄ図に示す管理仕様により規
定される情報を含むデータ辞書の構造を示す。 第５図及び第６図は第１Ａ図に示す制御装置の各種モジ
ュール及びデータ構造を示す機能ブロック図である。 第７Ａ図は第１Ａ図に示す制御装置の提示モジュール及
び機能モジュールにより発生される要求に使用されるパ
ラメータを示す。 第７Ｂ図は第７Ａ図の要求により使用される時間文脈取
扱いおよび文脈ブロックの＃Ｉ造を示す。 第８Ａ図および第８Ｂ図は第１Ａ図に示す制御装置の提
示モジュールおよび機能モジュールからの要求の処理と
関連して第５図及び第６図に示したディスパッチャに使
用されるディスパッチ・テーブルのデータ＃Ｓ″ｉｉを
示す。 第９Ａ図および第９Ｂ図は提示モジュールまたは機能モ
ジュールからの要求を処理する際にその関連ディスバッ
チ・デープルと関連するディスパッチャの動作を示す。 第９Ｃ図は構成データベースおよび領域データベースの
フォーマットを示す。 第１０Ａ図は警報条件を確立し検出するのに使用される
機能モジュールの構造を示し、第１０Ｂ図は警報条件を
確立するのに使用される規則の構造を示す。 １０・・・提示モジュール １１・・・機能モジュール １２・・・アクセス・モジュール １５・・・情報管理器 １７．２２・・・データ記憶装置

Claims (1)

1. 【特許請求の範囲】 １、時間パラメータを指定する命令に応じてエンティテ
   ィの集団について管理情報を検索するシステムであつて
   、 前記管理情報に関係する、各記録が関連時間の指示を含
   んでいる、記録を備えている記憶装置と、 命令に応じて前記記録に含まれている管理情報を検索し
   、または前記エンティティから管理情報にアクセスする
   ものであって、前記時間スケジュールにしたがつて恐ら
   く複数回前記命令に対応する一続きの従属アクセスまた
   は検索を恐らく発するスケジューラを備えている情報管
   理器と から成るシステム。 ２、時間パラメータを指定する命令に応じてコンピュー
   タ・ネットワークのメンバーについて管理情報を検索す
   るシステムであって、前記メンバーが前記ネットワーク
   とインターフェースして主要情報処理機能を制御すると
   共に前記メンバーが更に前記システムとインターフェー
   スして前記管理情報にアクセスすることができるように
   なっているシステムにおいて、 前記管理機能に関連する、各記録が関連時間の指示を含
   んでいる、記録を備えている記録装置と、 命令に応じて前記記録に含まれている管理情報を検索し
   、または前記メンバーから管理情報にアクセスするもの
   であって、前記時間スケジュールにしたがって恐らく複
   数回命令に対応する一続きのアクセスまたは検索を恐ら
   く発生するスケジューラを備えている情報管理器と を備えて成り、 ネットワーク内に発生する事象はネットワークの状態の
   構成要素として処理され、前記記録に格納されるシステ
   ム。 ３、時間パラメータを指定する命令に応じてエンティテ
   ィの集合について管理情報を検索する方法であつて、前
   記エンティティが前記集団とインターフェースして主要
   情報処理機能を制御すると共に前記エンティティが更に
   前記システムとインターフェースして前記管理情報にア
   クセスすることができるようになっているものにおいて
   、 前記管理情報に関連する、各記録が関連時間の指示を含
   んでいる、記録を備えている記憶装置を設ける段階およ
   び 命令に応じて前記記録に含まれている管理情報を検索し
   、または前記エンティティから管理情報にアクセスする
   ものであって、前記時間スケジュールにしたがって恐ら
   く複数回前記命令に対応する一続きの従属アクセスまた
   は検索を発するスケジューラを備えている情報管理器を
   設ける段階 から成る方法。