JPS63201860A - ネツトワーク管理システム - Google Patents

Abstract

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

Description

【発明の詳細な説明】 以下の順序で本発明を説明する。

Ａ、産業上の利用分野 Ｂ、従来技術 Ｃ１発明が解決しようとする問題点 り８問題点を解決するための手段 Ｅ、実施例 Ｆ０発明の効果 Ａ、産業上の利用分野 本発明は、データ処理ネットワーク中の異なるノードに
位置するプロセスの間の通信に関するものである。その
各ノードは、独立の動作をなし得るプロセッサを有し、
また端末装置、メモリ及びＩ１０装置などの他のサービ
スを備えていてもよい。さらに、各プロセッサは多重処
理、多重タスク能力を有していてもよい。より詳しく述
べると、本発明は、プログラムが通信待ち行列のノード
を知ることを不要ならしめることによってネットワ−ク
中の同一または異なるノードにある処理装置間の、待ち
行列に基づく通信を容易にすることにある。本発明に係
る記述においては、プロセス間通信（ＩＰＣ）待ち行列
位置透過伝達機構が、分散サービス環境中で実施される
ものとして説明される。

Ｂ、従来技術 Ｍ、Ｊ、Ｂａｃｈ著、Ｔｈｅ　Ｄｅｓｉｇｎ　ｏｆ　ｔ
ｈｅ　ＵＮＩＸＯｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ　（
ＵＮＩＸは米国におけるＡＴ＆Ｔベル研究所の商標）、
　Ｐｒｅｎｔｉｃｅ−Ｈａｌｌ　１９８６の３５６〜３
６７ページには、システム在駐カーネル中でメツセージ
待ち行列のアレイを呼び出すキーによってメツセージ取
得（ＭＳＧＧＥＴ）システム・コールを呼び出し、その
特定のキーに対応する一致エントリが見出されない場合
に、新しい待ち行列構造を割振るとともにユーザにその
識別子を戻すことによって、プロセス間通信（ＩＰＣ）
が行なわれることが開示されている。そして、メツセー
ジを送り受は取るためのシステム・コールＭＳＧＳＮＤ
及びＭＳＧＲＣＶに関連するアルゴリズムが開示されて
いる。しかし、その文献には、ネットワークの異なるノ
ードに位置する処理装置間のプロセス間通信を容易なら
しめることの記述も示唆もない。

ＩＢＭ　ＲＴ　Ｐｅｒｓｏｎａｌ　Ｃｏｍｐｕｔｅｒ　
Ｔｅｃｈｎｏｌｏｇｙ（型式番号５Ａ２３−１０５７）
にはＩＢＭ　　ＲＴ　（ＲＴは米国におけるＩＢＭ社の
商標である）パーソナル・コンピュータが記述されてい
る。それには拡張対話型実行（Ａｄｖａｎｃｅｄ　Ｉｎ
ｔｅｒａｃｔｉｖｅ　Ｅｘｅｃｕｔｉｖｅ　：ＡＩＸ　
（ＡＩＸは米国におけるＩＢＭ社の商標である））オペ
レーティング・システムが、ＡＴ＆ＴのＵＮＩＸシステ
ムＶの概念の拡張であるとして開示されている。

このＡＩＸカーネルは、アプリケーション・プログラム
及びコマンドのためのオペレーティング環境を与える。

尚、ＡＩＸのより詳しい説明については、ＡＩＸ　Ｏｐ
ｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ　ＴｅｃｈｎｉｃａｌＲ
ｅｆｅｒｅｎｃｅ　（型式番号５Ｖ２１−８００９）を
参照されたい。この技術は、複数のＩＢＭ　　ＲＴ　　
ＰＣシステムが通信ネットワークのノードとなることを
可能ならしめ、且ついくつかの追加的な特徴を与えるよ
うに拡張されたものである。

そのような特徴の１つとしてネットワークに亘る分散処
理がある。そのような分散サービス環境は、通信リンク
またはネットワークによって接続された２またはそれ以
上のノードを有する。ネットワークは、ローカル・エリ
ア・ネットワーク（ＬＡＮ）　、または他のノードまた
は他のネットワークに対する遠隔処理接続を有する広域
（ｗｉｄｅａｒｅａ）ネットワーク（ＶＡＮ）のどちら
かでよい。

分散サービスの主要な目的は、ＡＩＸオペレーティング
・システムのファイル・システム及びプロセス間通信（
ＩＰＣ）サービスを用いるアプリケーションのために構
内／遠隔透過伝達機構を与えることにある。

Ｃ０発明が解決しようとする問題点 本発明の目的は、ノード位置透過伝達機構と、待ち行列
の名前を衝突させる割当てを防止するための手段と、１
つの待ち行列上で所与のサービス供給者から複数の顧客
へメツセージを切換える（ｄｅｍｕｌｔｉｐｌｅｘｉｎ
ｇ）ことを可能ならしめる手段をもつ効率的なメツセー
ジ待ち行列処理システムを提供することにある。

Ｄ０問題点を解決するための手段 本発明は１通信リンクを介して接続された少くとも２つ
のシステムを含むネットワーク中の異なるノードにある
プロセス間の通信を容易ならしめるものである。その各
ノードは、多重処理及び多重タスク動作をなしうるプロ
セッサを有する。尚、前述のように、各ノード・プロセ
ッサは独立（ｓｔａｎｄａｌｏｎｅ）モードでも同様に
動作し得るものでもよい。

異なるノードに位置づけられたプロセスは、その実際の
ノード位置が、通信を開始するプログラムにとって未知
であるようなＩＰＣ待ち行列を使用する他のプロセスと
通信可能であるようになされている。本発明は、ＡＩＸ
　　ＩＰＣメツセージ機構を、異なるノードにおける待
ち行列間で送受信をなし得るように拡張することにより
、同一のＡＩＸシステム中のプロセス間の通信のための
ＡＩＸ　　ＩＰＣメツセージ待ち行列機構よりも進歩し
ている。ＡＩＸは、メツセージ取得（ｍｓｇｇｅｔ）、
メツセージ送信（ｍｓｇｓｎｄ）及びメツセージ受信（
ｍｓｇｒｃｖ）システム・コールを使用してＩＰＣをサ
ポートする。メツセージ取得は、メツセージ待ち行列を
見出しあるいは作成し、その識別子ＭＳＱＩＤを戻すた
めに使用される。そしてそれ以降のメツセージ送信及び
メツセージ受信コールは、ターゲット待ち行列を識別す
るためにこのＭＳＱＩＤを使用する。

本発明は、入カキ−を特定の待ち行列の実際のキーとノ
ード位置と相関させるための予定のカーネル在駐テーブ
ル中のルック・アップ機能に対する引数として特定の待
ち行列のキーを使用するようにするために、Ａ　Ｉ　Ｘ
　ｍｓｇｇｅｔシステム・コールに対して修正を加える
ことから進む。メツセージを配置すべき待ち行列のノー
ド位置及びキーは、通信しているプロセスに透過的であ
る。

待ち行列が遠隔ノードにあるとき、２つのノードは、待
ち行列要素情報を渡すために、それらの間に確立された
通信リンクを使用する。本発明の好適な実施例は、ＩＢ
Ｍシステム・ネットワーク・アーキテクチャ（ＳＮＡ）
レベル６．２の拡張プログラム間通信を利用する。

ＩＰＣメツセージ待ち行列は、その待ち行列が作成され
たときに割振られたキー、すなわち数値によって識別さ
れる。特定の待ち行列にアクセスを所望する任意のプロ
セスは、参照が、実際の待ち行列識別子に対して確定的
（ｒｅｓｏｌｖｅｄ）であり得るような方法でキーを参
照しなくてはならない。

後で述べるように、本発明に係る方法の好適な実施例は
、分散サービス機能が設けられているオペレーティング
・システム・レベルで実施される。

本発明は、ネットワーク中の各システム・ノードが、キ
ーのための自己のＩＰＣ待ち行列プロファイル名称空間
をもつべきことを要求する。そして、アプリケーション
のコールからノード固有キーが、ノード固有キーを、呼
出し手によって与えられた待ち行列名に関連づけるライ
ブラリ・ルーチンに戻される。

一７＝ 本発明はまた、各システムのカーネルに在駐するキー・
マツピング・テーブル（ＫＭＴ）をも必要とする。キー
・マツピング・テーブル中の各エントリは、特定の待ち
行列を照会する居所キーと、その待ち行列が実際に在駐
するノードと、その待ち行列が実際に在駐するノードで
使用されるキーを含む。ＫＭＴはシステムのスタート・
アップ時に各ノードのカーネルにロードされる。

ＫＴＭデータは、ネットワークを監視するネットワーク
管理者によって保守される。そして、ＫＭＴに対する変
更は必要に応じてネットワーク管理者によってなされる
。この管理オペレータの関与するのは、アプリケーショ
ン・インターフェースでメツセージ待ち行列の透過性を
許容することである。

前述のＭ、Ｊ、Ｂａｃｈの書物に記述されているような
従来技術においては、プロセスはメツセージ待ち行列を
利用してメツセージを送受することによって通信する。

その呼プロセスは、受信するプロセスがメツセージを見
出すことを期待する待ち行列を識別しなくてはならない
。単独 （ｓｔａｎｄａｌｏｎｅ）多重処理システムにおいては
、すべての待ち行列の位置が既知である。しかし、分散
サービスをもつネットワーク環境においては、プロセス
が、同一または異なるノードにあるメツセージ待ち行列
を介して他のノードにあるプロセスと通信することが望
ましい。このとき、各プロセスがネットワーク中のすべ
てのメツセージ待ち行列の位置情報を暗黙的に知ってい
ることが必要とされるのであれば、そのことは許容し得
ないであろう。すなわち、もしこれが要求されるなら、
各呼プロセスは、実際のメツセージ待ち行列位置が変わ
るたび毎にその変更を知る必要があることになるからで
ある。

本発明はこの問題を、プロセッサ・ノードの待ち行列キ
ーを、メツセージ待ち行列の実際のキー及びノードと相
関させるカーネル在駐テーブルを設けることによって解
決する。これらのテーブルは、ネットワーク管理者によ
って、メツセージ待ち行列の実際のノード位置における
変更を反映するように変更することができる。しかし、
呼プロセスによって供給される入力パラメータは変わら
ない。それゆえ、メツセージ待ち行列の実際のノード位
置はアプリケーション・プログラム・インターフェース
で透過性である。

メツセージ待ち行列の実際の識別子に対するアドレス確
定（ｒｅｓｏｌｕｔｉｏｎ）がカーネル・レベルで生じ
る。ＫＭＴは入力としてキーを受は取り、所望の待ち行
列のキーとノードＩＤを与える。各ノードのカーネルを
そのように相関させたことにより、システム・コール・
ルーチンは通信を開始したプロセスによって与えられる
キーを受は取り、それに対応するキーとノードへ進む。

このとき、もしその識別子をもつメツセージ待ち行列が
そのノードの待ち行列ヘッダ・テーブル中で見出されな
かったなら、新しいメツセージ待ち行列が作成され、も
し呼出し者（ｃａｌｌｅｒ）が、待ち行列が作成される
べきことを要求したなら、そのメツセージ待ち行列の識
別子が呼出しノードのカーネルに戻される。呼出しノー
ドのカーネルにおいて、実際のノード位置とメツセージ
待ち行列識別子を含む新しい代理（ｓｕｒｒｏｇａｔｅ
）待ち行列ヘッダ・エントリが構成される。次にアプリ
ケーションは、自己のメツセージを、意図するメツセー
ジ待ち行列に配置することが可能となる。

Ｅ、実施例 第１図は、本発明が実施されるネットワークを示す概要
図である。ネットワーク１０は、通信リンク３０を介し
て接続された複数のノードＡ、　Ｂ及びＣを有するもの
として示されている。各ノードＡ、Ｂ、Ｃはそれぞれが
、単独システムまたはネットワーク１０の一部として動
作し得る多重タスク、多重処理能力をもつ少くとも１つ
のプロセッサ４０を含む。尚、第１図において参照番号
４０は、各ノードＡ、Ｂ、Ｃでそれぞれ４０Ａ、４０Ｂ
、４０Ｇとして示され、これは参照番号４２以下につい
ても同様である。図示されているように、通信ネットワ
ーク３０はローカル・エリア・ネットワーク（ＬＡＮ）
または広域ネットワーク（ＶＡＮ）のどちらでもよいが
、好適な実施例はノードＡ、Ｂ及びＣの間で通信リンク
を確立するためのＩＢＭシステム・ネットワーク・アー
キテクチャ（ＳＮＡ）を利用する。各ノードは、ユーザ
・アプリケーション４２が走ることになる少くとも１つ
のプロセッサ４０を有する。プロセッサ４０の内部には
、好適にはＩＢＭのＡＩＸであるオペレーティング・シ
ステム（０，Ｓ、）４６の制御の下にあるプロセス４４
がある。

各プロセッサ４０には、番号４８として示されているさ
まざまな記憶媒体が接続されている。尚、図示されてい
ないけれどもネットワーク構成１０によって意図されて
いるものとして、ネットワーク中の各プロセッサに接続
可能な他のさまざまな端末、記憶及び周辺Ｉ１０装置が
ある。各プロセッサ４０のオペレーティング・システム
４６の内部にはカーネル５０がある。

各独立ノードＡ、Ｂ、Ｃは、所与のタスクを実行するた
めに、互いのノードで利用可能な資源を共有するために
互いに協働することができる。そのような分散サービス
環境においては、本発明によって与えられるメツセージ
待ち行列位置の透過性を通じて処理する効率的なメツセ
ージの能力を利用するためにユーザはわずかの対話しか
必要としない。また資源を共有することにより、ネット
ワーク中の各ノードで情報を複写する必要性が減少され
る。

通信待ち行列のノード位置がユーザ・プログラムに対し
て透過的であるがゆえに、プロセス間の通信はより効率
的になり、ユーザが通信の詳細に払うべき注意はより少
なくなる。尚、所与の待ち行列の実際のノード位置は変
わり得るけれども、所与のノードのユーザは、待ち行列
の位置を追従する責任から解放される。ネットワーク管
理者の１つの任務は、待ち行列のキーと位置を相関させ
るプロフィールの最新のセットを維持することと、適当
な相関情報をネットワークにおける各ノードのカーネル
５０中のＫＭＴにロードすることである。

ネットワーク構成１０中の各プロセッサ・ノードのオペ
レーティング・システム４６には、予定の待ち行列に必
要な情報を維持するディレクトリ・サービス機能が含ま
れている。これらの機能には、ＩＰＣキーの作成、キー
位置の定義、特定のメツセージ待ち行列のためのキーに
対する外部ＩＰＣ待ち行列名の決定、及びメツセージが
到来するノードからのネットワーク位置及び遠隔待ち行
列の戻しがある。

待ち行列プロファイル・レコードのフォーマットが第１
図の参照番号５２で示されており、アプリケーションの
導入プログラムによってコールされるライブラリ・ルー
チン作成ＮＰＣ−ＰＲＯＦの実行の結果として作成され
る。このプログラムは、長さ１４キヤラクタまでの待ち
行列名（ＱＮＡＭＥ）を供給し、ライブラリ・ルーチン
がプロファイル・レコードを作成し、そのノードに固有
の数字ＩＮＫＥＹ値を割当てる。システムのスタート・
アップ時に、システムはプロファイルを読み、第２図に
示すようなエントリをもっＫＭＴを作成する。

ＫＭＴは、ライブラリ・ルーチンによって割当てられる
局所キー（ＬＫＥＹ）と、実際のキー（ＲＫＥＹ）と、
ＬＫＥＹによって指定される待ち行列のためのノード（
ＲＮＯＤＥ）を含む。

第３図は、待ち行列ヘッダ・レコードのフォーマットを
示す。スタート・アップ時にサーバー・プロセスがＩＰ
ＣＰＲＯＦを見出すために待ち行列名を入力し、その待
ち行列に関連するキーを受は取る。サーバー・プロセス
は次にキーを与えるシステム・コール、ｍｓｇｇｅｔを
発行し、ｍｓｇｇａｔが待ち行列を作成する。

第３＠中の待ち行列ヘッダ・レコードは、特定の待ち行
列が、待ち行列ヘッダ・テーブルが在駐するノードに対
して局所的（Ｌ）であるか、あるいは遠隔（Ｒ）に位置
しているかを示す表示子を含む。待ち行列ヘッダ・テー
ブル・エントリの残りのフォーマットは局所／遠隔表示
子の関数である。すなわち、もし待ち行列が局所的であ
るなら、ＬＫＥＹが局所持ち行列エントリを含み、ＬＭ
ＴＹＰＥはその待ち行列のために最も新しく使用された
メツセージ・タイプ表示子の値である。

遠隔待ち行列の場合、ＲＭＯＤＥがそのノードＩＤを含
み、ＲＭＯＤＥ　　ＭＳＱＩＤが遠隔ノードにおけるメ
ツセージ待ち行列ＩＤを含む。ＲＮＯＤＥ　　ＢＯＯＴ
ＣＮＴというフィールドは、遠隔ノードの電力サイクル
状況をあられす数を含む。

第４図は、メツセージ待ち行列エントリの内容を示す。

ＭＴＹＰＥはメツセージのメツセージ・タイプであり、
ＭＳＧＰＴＲは、メツセージ・テキストに対するポイン
タである。

第５図は、本発明に基づきＩＰＣの間に実行される論理
をあられすフローチャートである。これにおいて、ノー
ドＬＯＣＮＯＤＥでのプロセスが通信を開始したとき、
プロセスは、ブロック８０で示される入力としてＬＫＥ
Ｙを与えるｍｓｇｇｅｔシステム・コールを発行する。

そのキーは、ＬＯＧＭＯＤＥのカーネル在駐ＫＭＴにお
けるルックアップ関数に対する引数である。そして、ブ
ロック８２でＫＭＴが検索される。ブロック８４で一致
が見出されると、ブロック８６でＩＰＣ論理が、ＬＯＣ
ＮＯＤＥとＲＥＭＮＯＤＥの間に通信リンりが存在する
かどうかを判断する（この説明では、ＲＮＯＤＥがＲＥ
ＭＮＯＤＥ（７）ためノノードＩＤを含むものと仮定す
る）。もし通信リンクが存在しないなら、ブロック８８
で通信リンクが確立され、ブロック９０で、ＫＭＴ中で
見出された相関キーＲＫＥ、Ｙが関連するノードＲＥＭ
ＮＯＤＥに送られる。

もしＫＭＴ中で、ｍｓｇｇｅｔをコールするために使用
されるＬＫＥＹのためのエントリが見出されなかったな
ら、メツセージ待ち行列はブロック９２で局所的である
とみなされ、慣用的な方法で通信が行なわれる。

ブロック９４で、ＲＥＭＮＯＤＥのｍｓｇｇｅｔ　トラ
ンザクション・プログラムがＲＫＥＹを受は取り、ブロ
ック９６でＲＥＭＮＯＤＥにおける待ち行列ヘッダを検
索する。このとき、ブロック９８で一致が見出されない
なら、エラー条件が存在し、そこのことはブロック１０
０で表示される。もしＲＥＭＮＯＤＥの待ち行列ヘッダ
がエントリ一致ＲＫＥＹを含むなら、ブロック１０２で
ＲＥＭＮ○ＤＥのブート・カウントであるＲＮＯＤＥ　
　ＢＯＯＴＣＮＴとともにＭＳＱＩＤがＬＯＧＭＯＤＥ
に戻される。

次にブロック１０４で示すようにＬＯＣＮＯＤＥに戻っ
て、Ｒフォーマット待ち行列ヘッダ・エントリ（第３図
参照）がＬＯＣＮＯＤＥ待ち行列ヘッダ・リストに追加
され、局所ノードＭＳＱＩＤが呼出し手に戻される。呼
プロセスは次にｍ５ｇ５ｎｄを実行し、第５Ｂ図に示す
論理が適用される。

第５Ｂ図を参照すると、ＬＯＧＭＯＤＥにおいて、ＭＳ
ＱＩＤ　（ブロック１１０）が、ＬＯ（？：Ｎ０ＤＥ待
ち行列ヘッダ・リストにインデックスするために使用さ
れる（ブロック１１２）。ブロック１１４で、ＲＥＭＮ
ＯＤＥ　（待ち行列ヘッダ中のＲＮＯＤＥ）が既にＬＯ
ＧＭＯＤＥと接続されているかどうかの判断がなされる
。もしそうでなければ、ブロック１１６で接続が確立さ
れ、ＬＯＧＭＯＤＥのｎ１５ｇ５ｎｄがメツセージ・テ
キストＭＳＱＩＤ　　ＲＮＯＤＥ　　ＢＯＯＴＣＮＴと
ＭＴＹＰＥのＲＥＭＮＯＤＥへの送信を行なわせる（ブ
ロック１１８）。

ＲＥＭＮＯＤＥでは、ブロック１２０でそのｍ５ｇ５ｎ
ｄ　トランザクション・プログラムがＭＳＱＩＤとＢＯ
ＯＴＣＮＴとＭＴＹＰＥを受は取る。ＲＥＭＮＯＤＥは
このデータを受は取り、ブロック１２２で先ず受は取っ
たデータと、ＲＥＭＭＯＤＥにおける現在のブート・カ
ウントとを比較する。

もしそれらが一致しないならエラー条件が存在し、その
ことはブロック１２４でＬＯＣＮＯＤＥに戻される。一
方、それらのカウント値が一致するとき、ＲＥ　Ｍ　Ｎ
　ＯＤ　Ｅ　ｍ５ｇ５ｎｄ　トランザクション・プログ
ラムが、待ち行列ヘッダを選択し、ＭＴＹＰＥとともに
そのメツセージ待ち行列上にメツセージ・テキスト・ポ
インタ、ＭＳＧＰＴＲを配置するためにＭＳＱＩＤを使
用する（ブロック１２６）。ブロック１２８でＲＥＭＮ
ＯＤＥは、ＬＯＧＭＯＤＥに応答し、呼出し者（ｃａｌ
ｌｅｒ）に、成功裡に完了したという状況を戻す。

第５Ｃ図は、ｍｓｇｒｃｖシステム・コールの動作をあ
られすフローチャートである。ＬＯＧＮＯＤＥにおいて
、ブロック１４０でｍｓｇｒｃｖはＭＳＱＩＤとＭＴＹ
ＰＥを受は取る。ｍｓｇｒｃｖは、その待ち行列ヘッダ
・リストへインデックスし正しい待ち行列ヘッダを見出
すためにＭＳＱＩＤを使用する。

またＩ１８ｇｒｅＶは、そのヘッダに含まれているＲＮ
ＯＤＥ情報を使用して、ブロック１４４でＲＥＭＮＯＤ
Ｅとの接続（リンク）が存在しているかどうかを判断し
、もしそうでなければ、ブロック１４６で接続を確立す
る。ブロック１４８では、その確立されたリンクを介し
てＭＳＱＩＤと、ＲＮＯＤＥ　　ＢＯＯＴＣＮＴと、Ｍ
ＴＹＰＥがＲＥＭＮＯＤＥに送られる。

ＲＥＭＮＯＤＥのｍｓｇｒｃｖ　トランザクション・プ
ログラムがブロック１５０でこの情報を受は取った後、
そのプログラムは受は取ったブート・カウント値と現在
のブート・カウント値を比較する（ブロック１５２）。

もしそれらのブート・カウント値が一致しないのならブ
ロック１５４でエラー条件が表示されＬＯＧＭＯＤＥに
戻される。

ブート・カウント値が一致したとき、ブロック−２０＝ １５６でＲＥＭＮＯＤＥのｍｓｇｒｃｖ　トランザクシ
ョン・プログラム論理が待ち行列ヘッダを選択するため
に、受は取ったＭＳＱＩＤを使用する。論理は次に、ブ
ロック１５８で一致するＭＴＹＰＥをもつメツセージが
あるか否かを判断するために待ち行列のメツセージ・エ
ントリをチェックする。

もしＲＥＭＮＯＤＥのメツセージ待ち行列上に一致する
ＭＴＹＰＥをもつメツセージが存在しないのなら、論理
はブロック１６０でメツセージが到来するのを待つ。も
し一致するＭＴＹＰＥをもつメツセージが見出されたな
ら、ブロック１６２で、上記の既に確立された同一の通
信リンクによりメツセージ・テキスト・ポインタがＬＯ
ＣＮＯＤＥに戻される。ブロック１６４で、ＬＯＧＮＯ
ＤＥは呼出し手にメツセージ・テキストを戻す。

第６図は、第５Ａ、５Ｂ、５Ｃ図に関連する論理を、特
定の仮設的環境を使用して説明する図である。ここでユ
ーザが会議室を予定する（ｓｃｈｅｄｕｌｅｒ）ために
コールするシェル・コマンド・プログラムがＬＯＧＮＯ
ＤＥに存在すると仮定しよう。このシェル・コマンドは
、スケジューラ・デーモン（ｄａｅｍｏｎ）　　Ｎ　Ｐ
　Ｃメツセージ待ち行列のためにＭＳＱＩＤを入手する
べくそのＬＫＥＹ７１０００のためにｍｓｇｇｅｔを発
行する。また、ネットワーク管理者が、ＬＯＧＭＯＤＥ
からの会議室の要求がＲＥＭＮＯＤＥ中のデーモンによ
ってサービスされるべきであると決定し、ＲＥＭＮＯＤ
Ｅ中のデーモンの待ち行列のためのキーが６７０００で
あると仮定する。この情報は、ＬＯＣＮＯＤＥのカーネ
ルＩＰＣＫＭＴ中にロードされている。

動作のシーケンスは次のとおりである。

（１）　ｇｅｔ　ｒｏｏｍがキー７１０００でＭＳＧＧ
ＥＴをコール。

（２）ＭＳＧＯＥＴがキー７１０００のためのＬＯＣＮ
ＯＤＥ　　ＫＥＹを参照する。

（３）ＫＭＴは、キー７１０００がＲＮＯＤＥ　　ＲＥ
ＭＮＯＤＥ中でＲＫＥＹ６７０００に再マツプされたこ
とを表示する。

（４）ＭＳＧＧＥＴは今やＲＥＭＮＯＤＥ中でキー６７
０００を探すべきことを知っている。

（５）ＭＳＧＧＥＴはＲＥＭＮＯＤＥとＳＮＡ接続を見
出し、あるいは確立し、キー６７０００のためのＭＳＱ
ＩＤを要求するネットワーク・メツセージを送る。

（６）ＲＥＭＮＯＤＥ中のＭＳＧＧＥＴトランザクショ
ン・プログラムは、キーが６７０００である待ち行列の
ためのメツセージ待ち行列ヘッダを探し出す。この場合
ＭＳＱＩＤは２である。

（７）ＲＥＭＮＯＤＥ中のＭＳＧＧＥＴトランザクショ
ン・プログラムは、ＬＯＣＮＯＤＥ中のＭＳＧＧＥＴに
、ＭＳＱＩＤが２であることを述べるネットワーク応答
を送る。

（８）ＭＳＧＧＥＴは、待ち行列ヘッダのリストにエン
トリを追加する。ヘッダ・エントリはとりわけＲＮＯＤ
Ｅ中（７１ＲＥＭＭＯＤＥと、２であるＲＮＯＤＥ　　
ＭＳＱＩＤと、これが遠隔待ち行列ヘッダのための局所
“代理”であることを記述するタグＲとを含む。この例
では、遠隔待ち行列のための代理ヘッダは、ＬＯＧＭＯ
ＤＥの待ち行列へラダ・リストのスロット１にあり、従
ってＬＯＧＮＯＤＥ　　ＭＳＱＩＤは１である。

（９）ＭＳＧＧＥＴは呼出し者にＭＳＱＩＤ＝１を戻す
。

（１０）　ｇｅｔ　−ｒｏｏｍは、会議室デーモンにＩ
ＰＣメツセージを送るためにこのＭＳＱＩＤを使用する
。

以下に示すのは、第５Ａ、５Ｂ、５Ｃ及び６図に関連し
て説明した論理フローチャートの擬似コード表現である
。

フラグ ｏｕｔｐｕｔ：　ｍ５ｑｉｄ 入カキ−のためのマツピング・テーブル上を走らせるｉ
ｆ（（入カキ−のためのマツピングが存在しない）ｏｒ
　　（入カキ−が局所ノードの別のキーをマツプ））戻
す ｅｌｓｅ　／”キーは遠隔ノードのキーをマツプＩ／応
答を待つ 応答が受信されたとき 代理待ち行列ヘッダを割振り 戻されたｍ５ｑｉｄを待ち行列ヘッダに格納この代理待
ち行列ヘッダのための局所ｍ５ｑｉｄを戻すｍｓｇｇｅ
ｔ　ｏｆ−１ｏｃａｌ　ｑｕｅｕｅｉｎｐｕｔ：キー フラグ ｏｕｔｐｕｔ：　ｍ５ｑｉｄ この待ち行列のためのメツセージ待ち行列ｉｄを戻す５
ＧＳＮＤ ｉｎｐｕｔ：　ｍａｑｉｄ フラグ 待ち行列ヘッダを探し出すためｍａｑｉｄを使用ｉｆ　
（ヘッダは代理待ち行列のためのもの）代理待ち行列ヘ
ッダからノード名と遠隔ｍａｑｉｄを抽出応答を待つ 応答が受は取られたとき呼出し者に戻るｅｌｓｅ　／”
ヘッダは居所持ち行列のためのものである＊／手続ｍａ
ｑｓｎｄ−ｔｏ　１ｏｃａｌ　ｑｕｅｕｅをコールメツ
セージ・テキストの長さ フラグ 呼出し者が待ち行列に書き込むべき許可を有しているか
どうか調べるためチェック ｗｈｉｌｅ　（メツセージを格納するに十分なスペース
がない）利用可能な十分なスペースがあるまで待つメツ
セージ・テキストを待ち行列にコピーメツセージを保持
するバッファへのポインタメツセージ・フラグを保持す
るバッファの長さバッファの長さ ｏｕｔｐｕｔ：メツセージ・バッファ中ヘコビーされた
メツセージのサイズ 待ち行列ヘッダを探し出すためｍ５ｑｉｄを使用ｉｆ　
（ヘッダが遠隔待ち行列のためのもの）代理待ち行列ヘ
ッダからノード名と遠隔ｍ５ｑｉｄを抽出手続 手続ｍｓｇｒｃｖ　ｆｒｏｍ−１ｏｃａｌ　ｑｕｅｕｅ
を実行することを要求するメツセージを遠隔ノードに送
り、その結果を戻す応答を待つ 応答が受信されたとき 呼出し者にメツセージをコピー ｅｌｓｅ　／”ヘッダは局所持ち行列のためのものであ
る１／手続ｍｓｇｒｃｖ　ｆｒｏｍ　１ｏｃａｌ　ｑｕ
ｅｕｅをコールｍｓｇｒｃｖ　ｆｒｏｍユｏｃａｌ　ｑ
ｕｅｕｅメツセージのサイズ 呼出し者が待ち行列から読み取る許可を有しているかど
う力翫調べるためチェック 待ち行列からメツセージを削除 ｅｌｓｅ　／”待ち行列上にメツセージなし＊／休止（
メツセージが待ち行列上に到来するまで）ｌｏｏｐへ 待ち行列の割当ては、″よく知られた″待ち行列、すな
わち多くの依頼人によって使用されると考えられる待ち
行列には複写キーが作成されなｌ、Ｎように管理されな
くてはならない。本発明しこよれば、割当てキーの外部
登録の必要なしでアプリケーション・プロジェクトの作
成者が大域約１こ固有のキーを作成することを可能なら
しめる方策カー与えられる。この方策の主要な要素は、
待ち行列プロファイル（第１図、参照番号５２）のエン
ドミノ中で１４個のキャラクタの文字数字（ａｌｐｈａ
ｎｕｍｅｒｉｃ）−２８＝ 待ち行列名を使用することである６ アプリケーシヨンの開発者は、一意的に表現するための
１４個のキャラクタの名前を選択する。

各待ち行列プロファイル・エントリは第１図に示されて
いるように、ＱＮＡＭＥ、ＬＫＥＹ、ＲＮＯＤＥ、ＲＫ
ＥＹというフィールドをもつ。

ライブラリールーチンｃｒｅａｔｅ　ｉｐｃ　ｐｒｏｆ
　（Ｑ　ＮＡＭＥ、ＬＫＥＹ、ＲＫＥＹ、ＮＩＣＫＮＡ
ＭＥ）が待ち行列プロファイルを作成する。すなわち、
呼出し者が名前を与え、このルーチンが待ち行列プロフ
ァイル・エントリを作成し、それに固有の局所キーを割
当て、その局所キーを呼出し者に戻す。その後ネットワ
ーク管理者がＲＮＯＤＥ及びＲＫＥＹのためのデータを
与える。

さて、分散アプリケーションがサーノベ・デーモンとサ
ーバの要求を作成するコマンド・プログラムから成って
いると仮定する。サーバは特定のネットワーク・ノード
上に在駐し、コマンド・プログラムはネットワークのい
くつかのノードのどれかで実行することがきる。そのよ
うなアプリケージョンの導入及び動作は次の例によって
示される。

すなわち、デーモンが走るべき位置でアプリケーション
の導入プログラムがｃｒｅａｔｅ　ｉｐｃ　ｐｒｏｆ（
３）をコールし、”Ａ　ＣＭＥｓｆｗｒＯ３２６８６”
という待ち行列名を与える。ｃｒｅａｔｅ　ｉｐｃ　ｐ
ｒｏｆ　（３）によって作成されるプロファイルは次の
ものを含む二基　　　前　　“ＡＣＭＥｓｆｗｒＯ３２
６８６”局所キー　　０ｘ３００００−ＯｘＦＦＦＦＦ
の範囲からｃｒｅａｔｅ　ｉｐｃ　ｐｒｏｆ（３）によ
って選択され、このノードにおける他のいかなるプロフ
ァイルとも衝突しない値。

遠隔ノード　　　　空文字 遠隔キー　　　　０ コマンド・プログラムが走るべき各位置で、アプリケー
ションの導入プログラムはｃｒｅａｔｅ　１ｐｃ−ｐｒ
ｏｆ　（３）をコールし、”ＡＣＭＥｓｆｗｒＯ３２６
８６”の待ち行列名を与える。ｃｒｅａｔｅ　ｉｐｃ　
ｐｒｏｆ（３）によって作成されるプロファイルは次の
ものを含む： 名　　　前　　“ＡＣＭＥｓｆｗｒＯ３２６８６”局所
キー　　ｃｒｅａｔｅ　ｉｐｃ　ｐｒｏｆ（３）によっ
て０ｘ３００００−ＯｘＦＦＦＦＦの範囲から選択され
、このノードにおける他のいかなるプロファイルとも衝
突しない値。

ネットワーク管理者は、次のものを含むようにコマンド
・ノードにおけるプロファイルを変更するように指令さ
れる： 遠隔ノード　　デーモンのノード 遠隔キー　　デーモンのノードにおける待ち行列の局所
キー デーモンがスタート・アップするとき、デーモンはｆｉ
ｎｄ　ｉｐｃ　ｐｒｏｆ（３）をコールして、待ち行列
名“ＡＣＭＥｓｆｗｒＯ３２６８Ｂ”を与えてその名前
に関連するキーを見出す。デーモンは次にその待ち行列
のためのＩＤを入手するためにｍｓｇｇｅｔ（キー、０
）をコールする。

この１４キヤラクタの待ち行列名はソフトウェア開発者
に、待ち行列名を選択する際のきわめて大きい自由度を
与える。すなわち、これにおいては、アプリケーション
開発者らの間で打合わせがなくとも、ある開発者によっ
て注意深く選択された名前が、別の開発者によって選択
された名前と衝突することはきわめて起こり難いことで
ある。

しかし、慎重な開発者といえども衝突が生じるような場
合を有する設計を選択することが全くないとは言えない
。そのような衝突を扱うための例示的な方策とし、では
次のようなものがある７申好適な待ち行列名がアプリケ
ーション・プログラム中に固定的にコード化されるが、
デーモンとコマンド・プログラムの両方上でコマンド引
数によって無効（ｏｖｅｒｒｉｄｅ）ストリングを供給
することもできる。

＊デーモンまたはコマンド・プログラムが導入されたと
き、そのデーモンまたはコマンド・プログラムは、必要
な待ち行列プロファイルを作成するためにｃｒｅａｔｅ
　ｉｐｃ　ｐｒｏｆ（３）　を使用する。もし名前の衝
突のためその作成が失敗したなら、管理者が固有の待ち
行列を入力するよう促される。導入プログラムは次にプ
ロファイルを作成するためにこの待ち行列名を使用する
。

傘導入プログラムまたは文書は管理者に、デーモン及び
コマンド・プログラムが常に待ち行列名引数で呼び出さ
れていることを確認するよう指令する。

次に正しいメツセージの経路指定（ｒｏｕｔｉｎｇ）を
保証するために実施される技術について説明する。

上述のＢａｃｈの文献に述べられているような単独アプ
リケーションにおいては、カーネルに所与のタイプの最
初のメツセージを戻させるようにＭＴＹＰＥパラメータ
が適宜セットされる。もし待ち行列上にこのタイプを満
足するメツセージが存在しないなら、カーネルはプロセ
スを休眠させる。複数のプロセスが１つのメツセージ待
ち行列上で多重チャネルをセット・アップすることがで
き、以て各プロセスが、カーネルが適正な順序を維持し
　、つつ到来する特定タイプのメツセージを順に抽出す
ることになる。

分散サービス・ネットワーク環境においては、しかし、
複数の要求者が同時に同一のサーバを扱うことが可能で
ある。本発明は、メツセージ・タイプを用いて応答メツ
セージのデマルチプレクス機能を与える。

ＭＴＹＰＥ値は、メツセージ待ち行列ヘッダ（第３図）
中に３２ビツトのＭＴＹＰＥ値を与えることによって一
意的であるように割当てられる。

この値は、最も新しく使用されたＭＴＹＰＥ値に対応す
る。メツセージ制御（ｍｓｇｃｔ　１　）のための新し
いコマンドは、待ち行列のメツセージ・タイプの現在の
値を戻させる。ＭＴＹＰＥはプロセスに戻される度毎に
（第５Ｂ図、ブロック１２８）直ちにインクレメントさ
れる。

尚、要求及び応答が同一の待ち行列を流れる方がより効
率的であるので、双方向待ち行列を切換する際にＭＴＹ
ＰＥのために確立された規約がさらにネットワークの処
理能力を高める。

例えば、次のような筋書きにより、起こり得る問題が描
き出される。すなわち、待ち行列を作成するプロセス中
でサーバがパワー・オンすると、その待ち行列の識別情
報が最初の待ち行列ヘッダ・スロットに入る。そして依
頼人がｍｓｇｇｅｔを行い、ＭＳＱＩＤを受は取る。と
ころでサーバは電源サイクルを通過する。その少し後に
サーバにおけるプロセスが別の待ち行列を作成し、その
識別情報を最初の待ち行列ヘッダ・スロットに入れる。

依頼人のプロセスは次にもとのＭＳＱＩＤを用いてｍ５
ｇ５ｎｄを行う。すると、依頼人からのメツセージは依
頼人が期待した待ち行列には行かない。

本発明によれば、依頼人がメツセージを送る度毎にブー
ト・カウントの比較が行なわれるためにこの問題が回避
される。そしてもしブート・カウントが等しくないなら
、依頼人はエラー条件を通知される。ここで第５Ｂ図の
ブロック１２２，１２４、及び第５Ｃ図のブロック１５
２，１５４を再度参照されたい。

各ノードは、そのルート・デバイス・スーパー・ブロッ
ク（第１図参照番号５４）に、サーバのパワー・オン状
態を示すカウンタ＋　ＢＯＯＴＣＮＴを有する。このカ
ウンタは、サーバがパワー・オフされ再びオンにされる
度毎にインクレメントされる。このカウント値は第５Ｂ
図及び第５Ｃ図に述べられているようなメツセージ動作
に使用され、そのメツセージ動作は、サーバが、メツセ
ージ待ち行列識別子を発行したときと同じ状態にあるこ
とを保証するためにメツセージ待ち行列識別子を使用す
る。

Ｆ０発明の効果 要約すると、本発明は、多重ノード・ネットワーク中の
任意のノードにあるプロセッサ間のプロセス間通信のた
めの、カーネル・レベルで動作可能な手段を与える。そ
して通信は、ネットワーク中の任意のノードにある、キ
ーで識別されたメツセージ待ち行列上に配置されたメツ
セージを通じてなされる。

アプリケーション・レベルでは、メツセージ待ち行列ノ
ード位置を知る必要がない。というのは、上述したキー
・マツピング・テーブルとそれの使用により、メツセー
ジ処理システム・コールによって使用するための実際の
メツセージ待ち行列アドレスへの、アプリケーション供
給キーの確定が可能となるからである。また、メツセー
ジ伝達の完全性は、必要なシステム・コールにおけるブ
ート・カウント比較ステップによって向上される。

さらに、異なるノードのためのメツセージの多重化は、
待ち行列のヘッダ・エントリ中により記述的なＭＴＹＰ
Ｅを与えることによって促進される。

さらにまた、上述した命名規約により、衝突、すなわち
分散サービス・ネットワーク環境中の異なるアプリケー
ション及びメツセージ待ち行列によって同一の名前が使
用されることの虞れが実質的に解消される。

【図面の簡単な説明】

第１図は、本発明が実施される複数のノードをもつネッ
トワークをあられす概要図、 第２図は、ＫＭＴのフォーマットを示す図、第３図は、
待ち行列ヘッダ・レコードのエントリを示す図、 第４図は、メツセージ待ち行列エントリのフォーマット
を示す図、 第５Ａ、５Ｂ及び５Ｃ図は、プロセス間通信の動作の論
理フローチャート、 第６図は、ある仮設的な値を与えた場合のプロセス間通
信の例を示す図である。 出願人　　インターナショナル・ビジネス・マシーンズ
・コーポレーション 代理人　　弁理士　　山　　本　　仁　　朗（外１名）

Claims (1)

1. 【特許請求の範囲】 ターゲット待ち行列上で通信トランザクションを要求す
   るユーザ・アプリケーション内では未知のノード位置に
   おいて、キーにより識別されるメッセージ待ち行列によ
   りネットワークにおけるノードでユーザ・アプリケーシ
   ョンを実行するプロセス間通信のためのネットワーク管
   理システムであって、 第１のアプリケーション供給ノードに固有のターゲット
   待ち行列キーと、第２のノードに固有であって該ターゲ
   ット待ち行列に関連づけられたキーとを相関させる各ノ
   ードにおけるアドレス確定テーブルと、 上記テーブルにアクセスし、要求された通信トランザク
   ションを完了する際に使用するためのターゲット待ち行
   列アドレスを構成するための、各ノードにおける手段、 とを具備するネットワーク管理システム。