JPS63205747A - 通信方法及びデータ処理システム - Google Patents

Abstract

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

Description

【発明の詳細な説明】 ん　産業上の利用分野 本発明はネットワークを介して接続されたデータ処理シ
ステムのためのオペレーティング・システムの改良、よ
り具体的には各処理システムが同じオペレーティング・
システムの異なったバージョンを走行させている時に処
理システム間で通信を行なう方式に関する。

Ｂ、従来技術 以下説明する本発明はＵＮＩＸ（ＡＴＴの商標）オペレ
ーティング・システムのバージョンにおいてインプリメ
ントされたが、ＵＮＩＸオペレーティング・システムと
類似の特性を有する他のオペレーティング・システムに
おいて使用する事も可能である。ＵＮＩＸオペレーティ
ング・システムはベル電話研究所により、ディジタル・
イクイプメント・コーポレーション（ＤＥＣ）ｃ７）ミ
ニコンピユータ上で使用するために開発されたが、広範
囲のミニコンピユータ及び、近年はマイクロコンピュー
タのためのポピユラーなオペレーティング−システムに
なっている。この−膜性の１つの理由は、ＵＮＩＸオペ
レーティング拳シスナシステムンブリ言語ではなくＣプ
ログラミング言語（これもベル電話研究所で開発された
）で書かれており、プロセッサ特有でない事である。従
って種々の機械のためにＣのコンパイラを書けば、ＵＮ
ＩＸオペレーティング・システムを１つの機械から他の
機械へ移植する事ができる。従ってＵＮＩＸオペレーテ
ィング・システム環境のために書かれたアプリケーショ
ン・プログラムも１つの機械から他の機械へ移植可能で
ある。ＵＮＩＸオペレーティング１システムに関するこ
れ以上の情報については、ウェスタン・エレクトリック
社１９８３年１月発行の「ＵＮ　Ｉ　Ｘ　　Ｓｙｓｔｅ
ｍ、　Ｕｓｅｒｓ　Ｍａｎｕａｌ。

Ｓｙｓｔｅｍ　ＶＪを参照されたい。ＵＮＩＸオペレー
ティング・システムの良好な概説は、　Ｂｒ１ａｎ　Ｗ
。

Ｋｅｒｎｉｇｈａｎ及びＲ□ｂ　Ｐｉｋｅにより、Ｐｒ
ｅｎｔｉｃｅ−Ｈａｌ１発行（１９８４年）の［Ｔｈｅ
　ＵｎｉｘＰｒｏｇｒａｍｍｉｎｇ　Ｅｎｖｉｒｏｎｍ
ｅｎｔ　Ｊ　に与えられる。ＵＮＩＸオペレーティング
・システムの設計についてのより詳細な説明は、Ｐｒｅ
ｎｔｉｃｅ−Ｈａｌ　１発行（１９８６年）、Ｍａｕｒ
ｉｃｅ　Ｊ、Ｂａｃｈ著１［Ｄｅｓｉｇｎ　　ｏｆ　　
ｔｈｅ　Ｕｎｉｘ　ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ　
Ｊに見い出される。

ＡＴ＆Ｔのベル研究所は多数の団体にＵＮＩＸオペレー
ティング・システムを使用するライセンスを与えており
、現在ではいくつかのバージョンが利用可能である。Ａ
Ｔ＆Ｔからの最新のバージョンはバージョン５２である
。ＵＮＩＸオペレーティング・システムのバークレイ・
バージョンとして知られる他のバージョンは、カリフォ
ルニア大学バークレイ分校によって開発された。パーソ
ナル・コンピュータ用の著名なＭＳ−ＤＯ８及びＰＣ−
ＤＯＳオペレーティング・システムの発行元であるマイ
クロソフトはＸＥＮＩＸ（マイクロソフト社の商標）と
して知られるバージョンを有している。ＩＢＭ　　ＲＴ
　　ＰＣ（ＩＢＭ社の商標）　（ＲＩＳＣテクノロジー
のパーソナル・コンピュータ）の発表時に、ＩＢＭ社は
ＡＩＸ（ＩＢＭ社の商標）と呼ばれる新しいオペレーテ
ィング・システムをリリースした。これはＡＴ＆ＴのＵ
ＮＩＸオペレーティング・システムのバージョン５．２
とアプリケーションΦインターフェース・レベルで一般
に互換性があシ、且つＵＮＩＸＮＩＸオペレーテイング
テム、バージョン５．２に対する拡張を含んでいる。Ａ
ＩＸオペレーティング・システムについてのこれ以上の
情報については、ＩＢＭ社発行、「ＡＩＸ　　Ｏｐｅｒ
ａｔｉｎｇ　　Ｓｙｓｔｅｍ　　ＴｅｃｈｎｉｃａｌＲ
ｅｆｅｒｅｎｃｅ　Ｊ第５版（Ｎｏｖ、１９８５）を参
照されたい。

本発明は、複数のプロセッサがネットワーク状に相互接
続された分散型データ処理システムに関する。実際にイ
ンプリメントされた時、本発明はＩＢＭのシステム・ネ
ットワーク・アーキテクチャ（ＳＮＡ）、より具体的に
はＳＮＡ　　ＬＵ６．２の拡張プログラム間通信機能（
ＡＰＰＣ）により相互接続された複数のＩＢＭ　ＲＴ　
　ＰＣ上で走行する。５ＮＡＬＵ６．２について述べた
文献としては、［ＡｎＩｎｔｒｏｄｕｃｔｉｏｎ　　ｔ
ｏ　Ａｄｖａｎｃｅｄ　Ｐｒｏｇｒａｍ−Ｔｏ−Ｐｒｏ
ｇｒａｍ　Ｃｏｍｍｕｎｉｃａｔｉｏｎ（ＡＰＰＣ）Ｊ
ＩＢＭＩＢＭ社発行２４−１５８４”０（Ｊｕｌｙ　１
９８３）及び「ＩＢＭ　ＲＴ　　ＰＣＳＮＡ　Ａｃｃｅ
ｓｓ　ＭｅｔｈｏｄＧｕｉｄｅ　ａｎｄ　　Ｒｅｆｅｒ
ｅｎｃｅＪ　ＩＢＭ社発行（Ａｕｇｕａｔ１５．１９　
Ｂ　６）がある。

ＳＮＡのこのＲＴ　ＰＣへのインプリメンテーションは
、リンク・レベルとしてイーサネット（ゼロックス社の
商標）又は５ＤＬＣを使用できる。

イーサネット・ローカル・エリアφネットワークヲ含む
ローカル−エリア・ネットワークの簡単な説明は、Ｒｏ
ｂｅｒｔ　Ｊ、Ｂｒａｄｙ（Ｐｒｅｎｔｉｃｅ−ＨｇＩ
２社）発行、Ｌａｒｒｙ　Ｅ、　Ｊｏｒｄａｎ及びＢｒ
ｕｃｅＣｈｕｒｃｈｉｌｌ著、「Ｃｏｍｍｕｎｉｃａｔ
ｉｏｎｓ　　ａｎｄＮｅｔｗｏｒｋｉｎｇ　ｆｏｒ　　
ｔｈｅ　　ＩＢＭ　ＰＣＪＫ見い出すレる。コンピュー
タのための通信システム％ＫＳＮＡ及び５ＤＬＣの決定
的な解説は、Ａｄｄｉｓｏｎ−Ｗｅ　ｓ　ｌ　ｅ　ｙ発
行（１９７Ｂ）、Ｒ，Ｊ、　Ｃｙｐｓｅｒ著、［Ｃｏｍ
ｍｕｎｉｃａｔｉｏｎｓ　　Ａｒｃｈｉｌｅｅｔｕｒ＠
　ｆｏｒＤｉｓｔｒｉｂｕｔｅｄ　Ｓｙｓｔｅｍｓ　Ｊ
に兄い出される。

しかし、本発明は、イーサネット・ローカル・エリア・
ネットワーク又はＩＢＭのＳＮＡ以外の他のネットワー
クに接続されたＩＢＭ　ＲＴ　　ＰＣ以外の別のコンピ
ュータを用いて実施する事もできる。

以前に述べたように、本発明は通信ネットワーク中の分
散データ処理システムに関する。この環境において、ネ
ットワーク中のノードの各プロセッサは、ファイルがど
のノードに存在していようと、ネットワーク中の全ての
ファイルに潜在的にアクセスし得る。第１図に示すよう
に、分散ネットワーク環境１は、通信リンク又はネット
ワーク６を介して接続された２つ以上のノードＡ、Ｂ及
びＣより構成され得る。ネットワーク６はローカル・エ
リア・ネットワーク（ＬＡＮ）でも又広域ネットワーク
（ＷＡＮ）でもよい。後者はシステムのＳＮＡネットワ
ーク又は他のノードへの交換又は専用回線のテレプロセ
シング（ＴＰ）接［−含む。どのノードＡ、Ｂ又はＣに
も、前述のＩＢＭＲＴ　　ＰＣのような処理システム１
０Ａ、ＩＯＢ又は１０Ｃが存在しうる。これらのシステ
ム１０Ａ、１０Ｂ及びＩＯＣの各々は、シングル・ユー
ザー・システムテモ又マルチ番ユーザー・システムでモ
ヨいが、ネットワーク６を用いてネットワーク中の遠隔
のノードにあるファイルにアクセスする能力を有してい
る。例えばローカル◆ノードＡの処理システム１０Ａは
遠隔ノードＢ及びＣのファイル５Ｂ及び５Ｃにアクセス
できる。

本明細書中で用語「サーバー」はファイルが恒久的に記
憶されているノードを示すために使われ、用語「クライ
アント」はそのファイルをアクセスするプロセスを有す
る他のノードを意味するために使われる。しかし、「サ
ーバー」という用語は或ルローカル令エリア・ネットワ
ーク・システムで使われているように専用のサーバーを
意味するものではない。本発明がインプリメントされて
いる分散型サービス・システムは真の分散型システムで
あって、システム中の異なったノードで多様なアプリケ
ーションが走行する事が可能であシ、それはシステム中
のどこにあるファイルにもアクセスできる。

ｔＪＮＩＸオペレーティング・システム環境において分
散型データ処理システムを支援する他の方式は公知であ
る。例えばサンφマイクロシステムズはネットワーク・
ファイル・システム（ＮＦＳ）をリリースしており、ベ
ル研究所はリモート・ファイル拳システム（ＲＦＳ）を
開発している。す７１１　？イクロシステムズのＮＦＳ
は、　Ｓ、　ＪＫｌｅｉｎ。

”Ｖｎｏｄｅｓ　：　Ａｎ　Ａｒｃｈｉｔｅｃｔｕｒｅ
　　ｆｏｒＭｕｌｔｉｐｌｅＦｉｌｅ　Ｓｙｓｔｅｍ　
Ｔｙｐｅｓ　　ｉｎ　Ｓｕｎ　　ＵＮＩＸ’。

Ｃｏｎｆｅｒｅｎｃｅ　　Ｐｒｏｃｅｅｄｉｎｇｓ、　
ＵＳＥＮＩＸ　１９８６　　Ｓｕｍｍｅｒ　Ｔｅｃｈｎ
ｉｃａｌ　　Ｃｏｎｆｅｒｅｎｃｅａｎｄ　Ｅｘｈｉｂ
ｉｔｉｏｎｌｐｐ、２３８−２４７　：　Ｒｕｓｓｅｌ
Ｓａｎｄｂｅｒｇ　ｅｔａｌｏ、”　Ｄｅｓｉｇｎ　　
ａｎｄＩｍｐｌｅｍｅｎｔａｔｉｏｎ　ｏｆ　　ｔｈｅ
　　Ｓｕｎ　ＮｅｔｗｏｒｋＦｉ　ｌｅｓｙｓｔｅｍ”
、Ｃｏｎｆｅｒｅｎｃｅ　Ｐｒｏｃｅｅｄｉｎｇｓ％Ｕ
ＳＥＮＩＸ　　１９８５、ｐｐ、１１９−１３０；　　
ＤａｎＷａｌｓｈ　ｅｔ　　ａｌ、　”Ｏｖｅｒｖｉｅ
ｗ　ｏｆ　　ｔｈｅ　　ＳｕｎＮｅｔｗｏｒｋ　Ｆｉｌ
ｅ　　Ｓｙｓｔｅｍ”、ｐｐ、　　１１７−１２４；Ｊ
ｏ　　Ｍｅｉ　　Ｃｈａｎｇ、”　５ｔａｔｕｓ　　Ｍ
ｏｎ１ｔｏｒＰｒｏｖｉｄｅｓ　　Ｎｅｔｗｏｒｋ　　
Ｌｏｃｋｉｎｇ　　５ｅｒｖｉｃｅｆｏｒ　　ＮＦＳ”
　；　　Ｊｏ　　Ｍｅｉ　　Ｃｈａｎｇ％　”Ｓｕｎ　
Ｎｅｔ”、ｐｐ、　７１−７５　；及びＢｒａｄｌｅｙ
　Ｔａｙｌｏｒ。

５ｅｃｕｒｅ　　Ｎｅｔｗｏｒｋｉｎｇ　　ｉｎ　　ｔ
ｈｅ　　ＳｕｎＥｎｖｉｒｏｎｍｅｎｔ”、ｐｐ、２８
−３６　　を含む一連の刊行物に記載されている。ＡＴ
＆ＴのＲＦＳは、Ａｎｄｒｅｗ　Ｐ、Ｒｉｆｋｉｎ　ｅ
ｔ　ａｌ、、”　ＲＦＳＡｒｃｈｉｔｅｃｔｕｒａｌ　
Ｏｖｅｒｖｉｅｗ”、ＵＳＥＮＩＸＣｏｎｆｅｒｅｎｃ
ｅ　　ＰｒｏｃｅｅｄｉｎｇｓｌＡｔｌａｎｔａｌＧｅ
ｏｒｇｉａ（Ｊｕｎｅ　　１９８６）、ｐｐ、１−１２
　：Ｒ４ｃｈａｒｄ　Ｈａｍｉｌｔｏｎ　　ｅｔ　ａｌ
、、ＡｎＡｄｍｉｎｉｓｔｒａｔｏｒ’ｓ　Ｖｉｅｗ　
ｏｆ　　ＲｅｍｏｔｅＦｉｌｅ　　Ｓｈａｒｉｎｇ”、
ｐｐ、　１−９：Ｔｏｍ　Ｈｏｕｇｈｔｏｎｅｔ　ａｌ
、、”Ｆｉｌｅ　　Ｓｙｓｔｅｍｓ　５ｗ１ｔｃｈ″ｓ
　ＰＰ。

１−２；及びＤａｖｉｄ　Ｊ、　０１ａｎｄｅｒ　　ｅ
ｔ　ａｌｏ、”Ａ　　Ｆｒａｍｅｗｏｒｋ　　ｆｏｒ　
　Ｎｅｔｗｏｒｋｉｎｇ　　ｉｎＳｙｓｔｅｍ　Ｖ”、
ｐｐ、１−８を含む一連の刊行物に記載されている。

上記の分散システムは、既存のオペレーティング・シス
テムに付加された拡張部によって分散機能が提供されて
いる。典型的には、同じソフトウェア・プログラムは異
なったバージョン及びリリース・レベルを有する事があ
る。ソフトウェア、・プログラムの製造業者は、最初に
、ある１組の機能を実行するように設計された第ルベル
のプログラムをリリースする。後に製造業者が付加的な
機能を提供したいと思うと、製造業者はソフトウェア・
プログラムの次のバージョンをリリースする。

典型的な場合、ソフトウェア・プログラムに対する主要
な変更は新しいバージョン・レベ／Ｌ／によって示され
、プログラムの全体的な機能に影響を与えない小さな変
更は同じバージヨン・レベル内の新しいリリース・レベ
ルによって示される。例えば既存のソフトウェア・プロ
グラムに対して付加的な機能が付加された場合、そのソ
フトウェア・プログラムはバージョン２と呼ばれる。も
しバージョン２がＩＪ　ＩＪ−スされた後に、以前のプ
ログラム中に発見された小さなエラーを訂正するように
再び更新が行なわれると、それはバージョン２、リリー
ス２のプログラムになる。しかし本明細書ではバージヨ
ン・レベル及びリリース曇レベルという用語は、単にソ
フトウェア・プログラムの次のレベルを示すために使用
され、これは互いに他方の用語で置き換える事ができる
。

分散システムが提供しなければならない機能をネットワ
ーク中のノードが利用するために、各ノードは、分散サ
ービスを提供するオペレーティング・システムを走行さ
せなければならない。他のプログラムと同様に、分散サ
ービス・プログラムも時の経過と共に付加的機能を提供
し、その結果、同じプログラムの種々のバージョン及び
リリースのレベルを生じる事が予想される。

Ｃ１発明が解決しようとする問題点 オペレーティング・システムに対する拡張部を通じて分
散機能を提供するプログラムの異なったバージヨン・レ
ベルのものをノードの各々が所有している場合、分散環
境において問題が生じる。

例えば第１のノードが最新バージョンを有している場合
、それは古いバージョンを有する第２０ノードができな
い機能を実行できる。従って第２のノードはこの高レベ
ルの機能に関係した第１のノードからのメツセージを認
識できない。第１０ノードがこの事全知っていれば、第
１のノードはその高い機能レベルで第２のノードと通信
しようと試みなかったであろう。

２つ以上の処理システムの間で異なった通信プロトコル
を取り扱うために使われている１つの方法は、ネットワ
ーク中の各ノード毎に構成（ｃｏｎｆｉｇｕｒａｔｉｏ
ｎ　）テーブルを設ける事である。

構成テーブルはネットワーク中の他のノードに関するプ
ロトコル情報を含んでいる。処理システムはそのテーブ
ルにアクセスして他のノードの通信プロトコルを知る事
ができる。この方法にはいくつかの問題点がある。第１
に、ネットワーク中の他のノードのプロトコルが変更さ
れると構成テーブルに更新を行なうためにシステム管理
者が必要である。さらに、更新を行なうノードば、他の
どのノードがこの変更の通知を必要としているかを知ら
ないかもしれない。ネットワークが非常に大きく、全て
のノードが同じシステム管理者の下にあるわけではない
事もあり得る。また、テーブルは処理システム中に余分
の記憶域を占める。さらに、他のノードと通信全始める
前にテーブルをチェックするのは時間がかかる。

この問題を解決するためのもう１つの方法は、全てのノ
ードに同時に同じバージョンを導入する事である。しか
し、大規模なネットワーク全体を同時に更新するように
要求する事は現実的でない。

従って、ネットワークはノードが種々のバージョン及ヒ
リリースのオペレーティング・システムを走行させてい
るものと予期でき、ノードに属する各々の接続は、異な
ったバージョン又はリリースの分散サービス・プログラ
ムを走行させるノードへの接続であるかもしれない。

従って本発明の目的は、分散機能のための異なったバー
ジョンのオペレーティング会システムを有するノード間
で効果的に通信を行なう事である。

本発明の他の目的は、受信側ノードが理解できるプロト
コルに適合する接続を介してメツセージが送られる事を
保証する事である。

本発明の他の目的は、初期のバージョンを廃する事なく
且つ新しいバージョンの新規な付加機能を制限する事な
しに、ある範囲の・く−ジョン・レベルがネットワーク
中に共存する事を可能にする事である。

Ｄ０問題点を解決するための手段 本発明のシステム及び方法は、ネットワーク中の２つの
ノードが両者によって理解される通信プロトコルを通じ
て互いに通信する事を可能にする。

与えられたバージヨン・レベルの通信プログラムは、そ
の特定のバージヨン・レベルに関する通信プロトコルを
定める。もしネットワーク中のノードが以前のバージヨ
ン・レベルを支援するプログラムを走行させているなら
ば、そのノードは支援されたバージヨン・レベルの範囲
によって決まる通信規約の組を有する。

本発明のシステム及び方法は、ネットワーク中の他のノ
ードとの会話中に使用される通信規約の綴金動的に決定
する。通信規約の組は２つのノードの間の最初の通信の
間に動的に決定される。さらに、動的決定によシ、両者
のノードがその時点で共通に有している最も高い通信プ
ロトコルを使用する事が可能になる。

他ノードへの接続で用いられるプロトコル番号、即ちバ
ージヨン・レベルを得るために、２つのノードのうち１
つが接続についての会話を開始する。

会話を開始するために送られたメツセージと共に、ノー
ドはそのノードが使用できる最高及び最低のプロトコル
番号を送信する。これは第１のノードに受は入れ可能な
通信規約の組を表わす。

第２のノードも、第２のノードに受は入れ可能な通信規
約の第２の組を表わすプロトコル番号の第２の組によっ
て定義される特定のバージヨン・レベル全走行させてい
る。第１のノードから第１の組の通信規約を受は取る時
、第２のノードは、２つのノードが何かのプロトコル番
号を共通に有しているか否かを判定する。もし第１及び
第２のノードが少なくとも１つのプロトコル番号を共通
に有していれば、第２のノードは２つのノードが共通に
有しているプロトコル番号のうち最高のものを返す。次
に２つのノードは、その両者に共通の最高のプロトコル
番号によって示される通信規約を用いて互いに通信する
。

もしプロトコル番号が両ノードに共通でなければ、第２
のノードは両ノードに共通の通信規約が存在しない事を
示す返答を第１のノードに返す。

次に第２のノードは第１のノードとの会話を打ち切る。

Ｅ、実施例 クライアントが遠隔のサーバー上にあるファイルをオー
プンしようとする時、それはサー・く−との接続を確立
するためにネットワーク・トランスポート機構を使用す
る。その後のこのファイルに関するトランザクション（
例えば読取り、書込み等）はこの接続上を流れる。各ノ
ードはノード・テーブルを含んでいる。ノードはそのノ
ード拳テーブル中のエン）ＩＪｔ−使用して、遠隔ノー
ドへの既存の接続に関する情報を記録する。

ネットワーク中の１つのノードが他のノードに要求でき
る動作の数は限られている。それらの動作はｄｆｓ動作
と呼ばれる。ノードが他のノードに要求を行なう時、次
のような動作が起きる。第１にどのｄｆｓ動作が要求さ
れているかを特定しそしてその要求に適したパラメータ
を伝達するメツセージを、要求側ノードが送信する。次
に、受信側ノードが要求を受は取り、特定された動作を
行なう。最後に、受信側ノ・−ドが、ｄｆｓ動作に適し
た返信パラメータを伝達するメツセージを送信する。こ
の通信パターンは遠隔手続き呼出しと呼ばれる。

次の用語が、ネットワーク環境に言及する時に典型的に
使用される。２つのノード間の接続は、ネットワーク中
のそれらのノードの間の通信を確立する。会話は、既存
の接続上の２つのプロセスの間の通信セツションである
。

２つのノードが接続を介して通信する時、それらはある
形のプロトコルを使用する。通信は、他のノードで何ら
かのタスクを実行するために使われる遠隔手続き呼出し
くｒｐｃ）でも、又ｒｐｅよりも複雑なものでもよい。

通信は、長い読取り要求を伝送する時に使われる対話（
ｄｉａｌｏｇ）でもよい。全ての場合において、関与す
るノードは、他のノードの分散サービスのバージョン／
リリースによって何のサービスが提供され得るかを知る
必要がある。遠隔のノードに伝達される制御及びデータ
・フィールドの形式は、受信側によって予期される形式
に一致する必要がある。分散サービス・プログラムの複
数リリース及びバージョン間で互換性を維持するのを助
けるために、後のＩＪ　ＩＪ−スは初期のリリースの全
て又は一部のプロトコルをサポートし得る。

本発明のシステム及び方法は、２つのノード間の接続を
介する通信を、両者のノードがサポートできる最高のバ
ージョン、及びＩＪ　ＩＪ−スに基づかせる。ノードは
、バージョン／リリース協議を用いて、互いに通信する
時に使うプロトコルを決定する。バージョン／リリース
協議は、接続を介して送信されるメツセージが、受信側
ノードの理解するプロトコルに適合する事を保証するた
めに使われる。

約束上、バージョン及びリリースの番号がプロトコル番
号を定義するために使用される。プロトコル番号は、バ
ージョン２の場合は「２」又バージョン３リリース２の
場合は「３．２Ｊのように数字で表現できる。このプロ
トコル番号はプログラムの特定のバージョン／リリース
・レベルに適用可能な通信規約を定める。２，２．１．
！１．４等のプロトコル番号のグループは、ノードにお
ける処理システムが適合できる通信規約の組を定める。

以前に述べたように、リリース間の互換性を維持するた
めに後のバージヨン・レベルが初期のリリースのプロト
コルを支援できる時にこの状況が起きる。

ネットワーク３を介して接続されたいくつかの処理シス
テムｐ、、Ｂ、Ｃ，Ｄ、Ｆ：ｆｒ示す第２図、及び第６
図の流れ図を参照して、以下本発明の良好な実施例を説
明する。

ノードＡがノードＢと通信する事を望むと、要求側ノー
ドＡは最初に、ステップ２０で、ノードＡとノードＢと
の間に既に接続が存在するか否かを判定する。接続が存
在していれば、要求側ノードＡは以下説明するようにノ
ードＢに関して、ノード・テーブル１２中の、以前に協
議されたバージョン−レベル値を引き出す（ステップ２
５）。

ノード・テーブル１２中に記録されたバージヨン・レベ
ルは２つのノードの間の通信規約として使用される。

接続が既に存在していなければ、要求側ノードは接続に
関する会話を開始し、他ノードにバージョン／リリース
（Ｖ／Ｒ）遠隔手続き呼出しを送る。

要求側ノードが使用できる最高及び最低のプロトコル番
号（即チハーション／リリース・レベル）がバージョン
／リリース遠隔手続き呼出しで他ノードへ伝達される（
ステップ６０）。例えばシステムＡが要求側システムで
あるとすると、システムＡはネットワーク中の他のシス
テムに９〜５の値を送信する。他のノード（応答側ノー
ドと呼ぶ）はバージョン／リリース遠隔手続き呼び出し
を受は取り（ステップ３５）、要求側ノードのバージヨ
ン・レベル値の範囲が応答側ノードの支援できる値の範
囲と交わるか否かを判定する（ステップ４０）。２つの
値の集合の間に交わりが存在すれば、応答側ノードは両
者に共通の最高のレベルを見つけ（ステップ４５）、そ
してその値を要求側ノードに返す（ステップ５０）。も
し他のノードのプロトコル番号、即ち通信規約の組の範
囲が、要求側のプロトコル番号の範囲と交わらないなら
ば、返される値はゼロである（ステップ５５）。

ゼロという値はプロトコルの空集合、即ち両ノードに共
通の通信規約が存在しない事を意味する。

２つの範囲の間の交わりを決定し両者に共通の最大値を
見つけ出す事（第３図のステップ４０及び４５）に関係
した付加的なステップが第４図に例示されている。ステ
ップ４１に示されているように、応答側ノードは要求側
の最高のバージヨン・レベルが応答側のシステムの最高
のバージヨン・レベル以上か否かを判定する。例えば第
２図のシステムＥがシステムＡのバージョン／リリース
ｒｐｅに応答しているとすると、要求側システムＡ　（
Ｄ　最高のレベルはシステムＥの最高のレベル以上であ
る。というのはレベル９はレベル７よリモ太きいからで
ある。

この場合、応答側システムＥの次のステップはシステム
Ｅの最高のレベルが要求側システムＡの最低のレベル以
上か否かを判定する小である（ステラ７’４２）。シス
テムＥのレベル７はシステムＡのレベル５よりも大きい
ので、応答側システムＥの最高のレベル（この場合は７
）が要求側システムＡに返される（ステップ４３）。

システムＡがシステムＢと会話を開始したならば、応答
側システムＢはステップ４２で応答側システムＢの最高
レベルが要求側の最低レベル以上でないと判定する。こ
の場合、システムＢの最高のレベルはレベル４であり、
システムＡの最低のレベルは５である。応答側システム
Ｂはゼロの値を返すか又は各システムの通信規約の集合
の間に交わりが存在しない事を要求側システムに知らせ
る何らかの指示を返す（ステップ５５）。言い換えると
、要求側システムＡの通信規約の第１の集合（レベル５
〜９）と応答側システムＢの通信規約の第２の集合（レ
ベル４）との間の交わりは、システムＡ及びシステムＢ
に共通の通信規約を含まない。

第４図のステップ４１に戻って、もしシステムＢがシス
テムＣと会話を開始し、システムＣにバージョン／リリ
ースｒｐｃｅ送ると、要求側システムＢの最高レベル（
レベル４）ｕ応答ｆｌｌｌシステムＣの最高レベル（こ
の場合はレベル１２）以上ではない。ステップ４７で応
答側システムＣは要求側システムＢの最高レベル（レベ
ル４）が応答側システムＣの最低レベル（レベル５）以
上か否かを判定する。レベル４はレベル５以上ではない
ので、応答側システムＣは要求側システムにゼロを返す
。これは２組の通信規約の間の交わりが両システムに共
通の通信規約を含まない事を意味する。

再びステップ４１に戻ると、もしシステムＡがシステム
Ｃと会話を開始するならば、要求側システムＡの最高レ
ベル（レベル９　）　ハ応答（１１１システムＣの最高
レベル（レベル１２）以上ではない。

ステップ４７では、要求側システムＡの最高レベル（レ
ベル９）ハ応答ｆｔ１ｌシステムＣの最低レベル（レベ
ル５）よりも大きい。従って応答側システムＣｔ［求側
システムの最高レベル（レベル９）を返す（ステップ４
９）。

第６図を参照すると、上記のようにして決定された最高
共通値又はゼロが要求側ノードに返される（ステップ６
０）。次に要求側ノードは、応答側ノードがバージョン
／リリースｒｐｃを認識したか否かを判定する（ステッ
プ６５）。もしそうであってゼロが返されたならば（ス
テップ７０）、応答側ノードとの通信は確立できず、会
話は終了する（ステップ９０）。もしゼロ以外の値が返
されたならば、その値はノード・テーブルに記録される
（ステップ７２）。これは現在の接続中に同じノードと
他の会話が開始される場合に使われる（ステップ２５）
。返すｔ”Ｌ　タハージョン・レベルが２つのノード間
の通信プロト、コルとして使われる（ステップ７４）。

応答側ノードがバージョン／リリースｒｐｃ　ｆ認識し
たか否かをステップ６５で判定する理由を詳細に説明す
る。最初のバージョン／リリースのプログラムは、ここ
で述べた協議方法を完全に実施する必要がない。最初の
リリースは他の端末にオケるシステムの実際のバージヨ
ン・レベルヲ知る必要がないが、他のシステムがあまり
に進歩しすぎて最初のバージョン／リリースのシステム
と話す事さえできない事を知らされる方式が必要である
。それにもかかわらず、後のバージョン／リリースのシ
ステムは、それらがリリースルベルのシステムと話して
いる事を発見する方法が必要である。

最初のバージョン／リリースのシステムに関ｆる動作ル
ールを以下説明する。最初に、接続を確立する時、最初
のバージョン／リリースのシステムは、そのバージョン
／リリースを遠隔のノードに通知するために遠隔手続き
呼び出しくｒｐｃ）を開始しない。後のバージョン／リ
リースは、バージョン／リリースｒｐｃｅ最初に送らな
いシステムから通常のｒｐｃ要求を受は取り始めると、
リリース１のシステムと話している事を知る。例えばシ
ステムＤが、システムＣと会話を開始するために第２図
の矢印６により示されるように通常のｒｐｃｅ送信する
。システムＣがこの通常のｒｐｃを受は取る時、システ
ムＣはレベル１のシステムと話している事を知る。

第２に、バージョン１のシステム力、バージョン／リリ
ース情報の要求のために予約されているｒｐｃ　　ｏｐ
コード（遠隔手続き呼出しオペレーション・コード）を
受は取ると、「ｏｐコード認識不可」エラーを返す。こ
の返答を受は取った後のバージョンのシステムハ、リリ
ース１のシステムと話していると推定する事ができる。

例えばシステムＤが矢印１に示すようにシステムＣから
バージョン／リリースｒｐｃ’（ｚ受は取ると、システ
ムＤは矢印２に示すようにｒｏｐコード認識不可」で応
答する。システムＣは、システムＤかう「ｏｐコード認
識不可」メツセージを受は取ると、システムＤがバージ
ョン１のシステムである事を知る。

第３に、後のバージョンのシステムが非常に進んでいて
、リリース１のシステムとどのようにして通信すればよ
いのかを知らない場合、後のバージョンのシステムはリ
リース１のシステムからの全ての要求に対してｒｏｐコ
ード認識不可」で返答する。例えば矢印乙に示すように
システムＤがシステムＣに通常のｒｐｅ送信を行なうの
に対して、システムＣは矢印４に示すようにシステムＤ
にｒｏｐコード認識不可」のメツセージを返す。

従って、第３図のステップ６５で、応答側ノードがバー
ジョン／リリースｒｐｅを認識できないならば、要求側
ノードは応答側ノードがバージヨン・レベル１である事
を知る（ステップ８０）。

次に要求側ノードは、要求側ノードがバージョン１と通
信できるか否かを判定する（ステップ８２）。

もしできなければそれ以上の会話は確立できず、会話は
終了する（ステップ９０）。もし要求側ノードがバージ
ョン１と通信できるならば、要求側ノードは、第２図の
ノード・テーブル１２に、応答側ノードのレベルに関し
て１の値を記録する。

次に要求側ノードはレベル１のプロトコルを用いて応答
側ノードと通信する（ステップ８６）。

要求側システムによる値の範囲の送信及びその範囲内の
共通最高値又はゼロの返信より成るこの通信はネットワ
ーク番トラフィックを要するが、この通信は１度実行す
るだけでよい事が重要である。協議後、返された値は他
の接続情報１４と共に要求側ノードのノード・テーブル
１２中に記憶される。

下記の例は上述の良好な実施例を説明する。例えば、バ
ージョン５の通信プログラムにおいて新しいファイル・
デッドロック検出アルゴリズムを提供する変更が導入さ
れたと仮定する。システムＡは、バージョン５のデッド
ロック検出アルゴリズムをサポートする全ての以前のリ
リースをサポートするバージョン９を走行させている。

システムＢにおいてファイルをオープンするために、シ
ステムＡはシステムＢのトランザクション・プログラム
にｒｐｃ’！ｒ用意する。もしＡとＢとの間に現在、接
続が存在すれば、接続を確立するために使われるｒｐｃ
は起動する必要がない。ノード・テーブル（これは接続
に関する情報を保持する構造である）は、以前に確立さ
れた接続において使われる以前に協議されたバージョン
／リリースを含んでいる。システムＡとシステムＢとの
間に現在、接続が存在しなければ、システムＡは、接続
分確立しバージョン／リリース協議を行なうためにｒｐ
ｃ’に行なう。システムＡは、システムＡが通信する方
法を知っている最高及び最低のバージョンを表わす値５
及び９をシステムＢに伝える。

もしシステムＢがバージョン４であれば、システムＡと
システムＢとの間には共通のプロトコルが存在しないの
で、その事を示す値が返される。この低いバージヨン・
レベルを有するノードと接続が存在するならば、プツト
ロック検出アルゴリズムは使用されないであろう。もし
システムＡがシステムＥと会話を開始すると、返される
値は７であろう。というのはシステムＥはバージヨン・
レベル７を有するからである。もしシステムＡが、バー
ジョンΦレベル１２を有スるシステムＣ（これはバージ
ョン５までのプロトコルをサポートできる）と会話を開
始すると、協議された値は９になるであろう。その結果
、システムＡとシステムＣ又はシステムＥとの間の通信
はこの例のデッドロック検出アルゴリズムを利用できる
。というのはそれらのノードはこの機能をサポートする
に充分に高いバージヨン・レベルを有しているからであ
る。

次に、初期のリリースにおける下位レベルの機能が後の
リリースによってサポートされない場合に要求側ノード
がその下位レベルの機能を使用できるようにする本発明
の他の実施例を以下説明する。これは要求側ノードが１
つの機能に関して応答側ノードと第ルベルで通信し、次
に異なった機能に関して他のレベルで同じ応答側ノード
と通信する事を可能にする。この実施例では、応答側ノ
ードは、以前の実施例の最高レベルの代りに、応答側ノ
ードによりサポートされるバージョン／ＩＪ　ＩＪ−ス
範囲を返す。次に要求側ノードは、所定の動作のための
通信プロトコルに関してその範囲内のどのレベルが使わ
れるかを決定する。

例えばファイルの名前の変更の機能を考える。

バージョン５のプログラムハ、リンク・システム・コー
ルを用いてファイルを別の名前に再リンクし次にアンリ
ンク・システム・コールを用いて古い名前をアンリンク
する事によりファイルの名前の変更を行なう事が可能で
あると仮定する。さらに、バージョン６のプログラムは
バージョン５のプログラムの２段階プロセスを避け、名
前変更システム・コールを用いて１ステツプで名前を変
更できるものと仮定する。バージョン５の機能又はバー
ジョン６の機能のどちらかが起動されるかに依存して異
なったｒｐｃが用いられる。しかし、要求側ノードのユ
ーザーが、ファイルの名前を変更しようとする毎にリン
ク及びアンリンクの２つのシステム・コールを自動的に
送信するプログラムΦセットアツプを有しているならば
、バージョン６の機能を含むようにユーザーのプログラ
ムを書き換えるよりはファイルの名前を変更するために
バージョン５のプログラムを使用する方がユーザーにと
って便利である。

上記の例を用いて続けると、他の機能はユーザーにファ
イルの属性を要求する事を可能にしていると仮定する。

そのような属性は、ファイルのサイズ、ファイルの所有
者、最後のアクセスの時刻、ファイルのユーザーＩＤ、
ファイルのグループＩＤ等を含み得る。ファイルの属性
を要求するために使われるｒｐｃは、バージョン５のプ
ログラムにおいては属性の長いリストを有するファイル
の完全なステータスを常に返すかもしれない。一方プロ
グラムに対するバージョン６の更新は、バージョン５に
関して使われたのと同じｒｐｃｋ用いて属性のサプセツ
）ｆ要求する小金可能にするかもしれない。サブセット
要求を伴なうｒｐｃがバージョン５に送られると、バー
ジョン５のプログラムはこの波長機能を認識しないので
、属性のサブセットは返されないであろう。

上記２つの例を組み合せると、要求側ノードは、リンク
及びアンリンクによるファイルの名前変更等の第１の機
能についてはバージョン５のプロトコルで応答側ノード
と通信し、そしてファイルの属性の要求のような第２の
機能についてはバージョン乙のプロトコルを用いて同じ
応答側ノードと通信できる。

１０発明の効果 本発明を用いれば、分散機能に関して異なったバージョ
ンのオペレーティング番システムヲ有スるノード間で効
果的に通信を行なう事ができる。

【図面の簡単な説明】

第１図は典型的な分散型データ処理システムの図、 第２図は各ノードが別々のバージョンｅレベルの通信プ
ログラムを走行させている分散型データ処理システムの
図、 第３Ａ図、第３Ｂ図は２つのノードの間のバージョン／
リリース協議の過程を示す流れ図、第４図は両ノードに
共通の最高のバージヨン・レベル全決定する過程の流れ
図である。 出願人　　インターナショカル・ビジネス・マシーンズ
・コーポレーション７−Ｆ・テープ、シ、１２ 庇、答Ｉ別ノード 第３Ｂ図

Claims (4)

【特許請求の範囲】
1. （１）第１のノードと第２のノードとの間で通信を行な
   うためのシステムであつて、 上記第１のノードに適用可能な第１の組の通信規約と、 上記第２のノードに適用可能な第２の組の通信規約と、 上記第１の組及び第２の組に共通の少なくとも１つの通
   信規約を決定する手段と、 上記共通の通信規約を用いて第１のノードと第２のノー
   ドとの間で通信を行なう手段とを有する通信システム。
2. （２）第１の組の通信規約を自局で処理できる第１のノ
   ードと第２の組の通信規約を自局で処理できる第２のノ
   ードとの間で通信を行なう方法であつて、 上記第１のノードから第２のノードへ、上記第１の組を
   表わす情報を送信し、 上記第２のノードにおいて、上記第１の組及び第２の組
   に共通の少なくとも１つの要素を決定し、上記１つの要
   素を表わす情報を上記第２のノードから第１のノードへ
   返送し、 上記１つの要素に相当する通信規約を用いて上記第１の
   ノードと第２のノードとの間で通信を行なう通信方法。
3. （３）通信ネットワークに接続して他ノードと通信を行
   なう機能を有するデータ処理システムであつて、 自局で処理できる通信規約の組を表わす情報を送信する
   手段と、 他ノードから送信されてきた通信規約の組を表わす情報
   を、自局で処理できる通信規約の組を表わす情報と比較
   して、共通要素を見い出す手段と、上記共通要素に対応
   する通信規約を用いて上記他ノードと通信する手段とを
   有する データ処理システム。
4. （４）上記通信規約の組を表わす情報が通信用プログラ
   ムのバージヨン・レベルの数字である特許請求の範囲第
   （３）項記載のデータ処理システム。