JPH02220166A - 通信方法とシステム - Google Patents

Abstract

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

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 この発明は、−船釣にはネットワーク通信システムに関
し、より詳しくは、ユーザーが、そのユーザーのノード
で利用可能な言語で眺めるようにするための、プログラ
ムからユーザーへの通信を送るための方法に関する。

Ｂ、従来の技術 世界中にコンピュータ製品を販売するための熾烈な競争
において、ハードウェア及びソフトウェア製品が、比較
的にユーザー・フレンドリであるということが、易者と
敗者を分ける重要な要因になってきている。従って、国
際的な、多言語的な市場では、ユーザーと自分の国の言
語で通信できるようにする製品の能力が、重要な関心事
となりはじめている。

この、場合によっては固有言語的支援（ＮＬＳ）とも呼
ばれる事項にとって基本的であるのは、通常メツセージ
またはスクリーンの形式でプログラムがユーザーに通信
するテキスト内容を、別の言語内容に容易に翻訳可能な
個別のファイルまたはデータ・セットとして定義するよ
うにすることである。このソース・オブジェクトは次に
、もし必要なら、特殊なプログラムによって、ユーザー
用のオブジェクト・コード・フォーマットに変換するた
めに処理される。

ＮＬＳ支援の最も簡単な形式は、ユーザーがある言語を
選択したときに、言語オブジェクトがメモリにロードさ
れ、それが導入時の特定のデフオールドに置き代わるよ
うな単一ユーザー製品において生じる。このプログラム
はそれから、ユーザーと通信するときに、その言語オブ
ジェクトの内容を使用する。

しかし、特に、製品が対話的である時に、複数ユーザー
を同時に支援するマルチ・タスキング製品において、高
度のレベルの複雑さが生じる。この場合、プログラムは
、各ユーザー毎に、どの言語を使用するべきかを追跡し
なくてはならず、また、効率のため、ページング可能な
メモリ中に言語オブジェクトを保持しなくてはならない
。

これらのどの場合にも、プログラムが提供しなくてはな
らないＮＬＳ機能は、かなり単純である。

その設備は、ユーザーのために必要とされる言語オブジ
ェクトを、製品ベンダ、外部の団体、または顧客自身の
翻訳から獲得することができなくてはならず、また、そ
の言語オブジェクトを、製品の「有効化」を通じて、プ
ログラムに利用可能にすることができるものでなくては
ならない。各ユーザーはまた、プログラムがセツション
で使用してほしいと望む言語を選択することができなく
てはなちない。

しかし、ネットワーク製品の場合、その解決策はあまり
明快でない。例えば、英国と、フランスと、ドイツにそ
れぞれある”Ｅ”、”Ｆ”、”Ｇ”というノードからな
る小さいネットワークを考慮し、それぞれがその自国の
言語でのみイネーブルされていると仮定する。

このとき、ノード”Ｆ”と”Ｇ”の間の通信リンクが突
然動作不能になり、その間、ノード”Ｅ”における英語
を話すユーザーがそのネットワークを通じてノード゛Ｇ
”のアプリケーションを使用していると仮定する。この
とき、ノード”Ｆ”は、ノード”Ｅ”のユーザーに、リ
ンクが動作不能になったことを通知しなくてはならない
が、ノード“Ｆ”は英語にイネーブルされおらず、ノー
ド”Ｅ”のユーザーは、フランス語が分からない。

明らかに、ユーザーがネットワークに入ってゆくノード
は、ユーザーが使用しようとする言語をサポートしてい
なくてはならず、さもないと、ユーザーは、言語を選択
することができないことになる。そのノードがユーザー
の言語をサポートしていないとき、ユーザーは、設備が
その言語を導入するように要求することができ、その設
備は、自己の翻訳を与えるという点にすら、非ネットワ
ーク製品の場合と同様に正確に応答することができる。

しかし、非ネットワーク製品とは異なり、プログラムか
らユーザーへのネットワーク製品のための通信を与える
というタスクは、２つ以上の設備に関与し、大型のネッ
トワークは、数百乃至数千の設備からなることがあり、
そのうちのどれも、−度にまたは別の時点でユーザーと
通信する必要が生じてくるかもしれない。

Ｃ０発明が解決しようとする課題 この発明の目的は、ユーザーが、そのユーザーのノード
で利用可能な言語で眺めることができるように、プログ
ラムからユーザーへの通信を送るための方法を提供する
ことにある。

００課題を解決するための手段 この発明の方法は、ネットワーク中の各ノードの言語能
力を決定し、所与のノードのユーザーに、標準化された
、プログラム可読なフォーマットでプログラム・メッセ
ージを送信し、そのメツセージを、受信ノードでデコー
ドし、そのメツセージを、そのノードがイネーブルされ
ている言語で表示する段階からなるものである。

Ｅ、実施例 以下の章で説明されるネットワーク製品においてＮＳＬ
サポートを与えるための方法は、末端ユーザーと設備の
両方のための製品のユーザー・フレンドリ度を最適化す
ることに指向されている。

この方法は、各設備に、その局所サイトでネットワーク
に入るユーザーの言語の必要性だけに感応すればよいよ
うにするものである。それと同時に、この方法は、ネッ
トワーク中の各ユーザーに、ネットワーク中のめいめい
のユーザーが自分の言語で話しているかのように、すな
わち、ネットワーク全体が単一のシステムであるかのよ
うに感じさせるものである。この方法によれば、発行側
のノード”Ｆ”がフランス語にのみイネーブルされてい
ても、ノード”Ｅ”におけるユーザーは英語で自分のメ
ツセージを受は取ることが可能となる。この発明の中核
にあるのは、いわゆる「エンコードされたメツセージ」
であり、これは言語テキストを除く、メツセージを構成
するための本質的なすべての成分を含む。そのエンコー
ドされたメツセージの厳密なフォーマットは、それが製
品にとって標準化されており、ある別のノードが局所言
語オブジェクトのうちの１つと相俟って、適当なメツセ
ージを構成するようにするために、１つのノードからそ
の別のノードへ通信されなくてはならない全ての情報を
含む限りは重要でない。次に示すサンプル・フォーマッ
トは、幾つかの固定長フィールドと、それに続く、メツ
セージ変数に置換されるべき値を記述するオプションの
フィールドを利用するものである。

固定長フィールド（常に存在する） ここで、Ｍｓｇ＃　＝メツセージ番号 Ｖｅｒ＃　＝メツセージ・バージョンまたはフォーマッ
ト番号 モジュール＝　（いくつかの製品のメツセージ・フォー
マットで使用される）メツセージを発行するプログラム
・モジュールを識別するキャラクタ・ストリング ＃Ｖａｒｓ　＝置換値の数 置換値は、もしあるなら、次のようなフォーマットでお
のおの連続的に続く。

ここで、＃Ｃｈａｒｓ　＝置換データ・フィールドのフ
ラグ＝出力形式が言語依存性（＊）をもつ置換データを
識別する役目を果たす一組のフラグ データ＝置換データ（もし言語依存 性がないなら最終出力形式） （＊）−実現構成によっては、＃Ｃｈａｒｓ及びフラグ
は単一のフィールドでもよい、というのは１．特殊デー
タ・タイプを表示するために、特殊な長さ値を使用する
ことができるからである。

さて、ここで、ネットワーク製品が、単一のリリースを
有しサービスをまだ適用されてないような新しい製品で
あるような簡単なケースから始めるとしよう。もしノー
ド”Ｆ”がローカル・ユーザーにメツセージを発行して
いるなら、ノード”Ｆ”は単に、そのユーザーによって
使用されつつある言語でメツセージのオブジェクト・コ
ード・イメージを調べ、そのメツセージを構成し、それ
をユーザーに表示するに過ぎない。メツセージを表示す
る間に、ノード“Ｆ”は、もし置換引数があるならそれ
を出力形式に変換し、それらをメツセージ長さ（＊） 中の適当な位置に配置する。

しかし、ノード”Ｅ”にいる遠隔ユーザーに対してメツ
セージを発行する時、ノード”Ｆ”は、代わりにエンコ
ードされたメツセージを構成することになる。ノード″
Ｅ“は、エンコードされたメツセージを受は取ると、そ
のユーザーによって使用されつつある言語でメツセージ
のオブジェクト・コード・イメージを調べ、そのメツセ
ージを構成し、それをユーザーに表示する。メツセージ
を表示する間に、ノード”Ｅ”は、メツセージ中の置換
変数を置き換えるために、エンコードされたメツセージ
中の置換変数を使用する。

はとんどの場合、発行側のノード（この場合ノード”Ｆ
”）が、メツセージを構成する時点でメツセージ引数を
出力形式に変換するのがより効率的である。受信側のノ
ードは単に引数をそのメツセージ中にコピーしながらメ
ツセージを構成すればよく、すると変換は既に完了して
いることになる。

しかし、出力形式が値を表現する言語に依存するような
タイプの引数が存在する。この例とじて１つはタイムス
タンプがあり、別のものとして特にネットワーク製品に
おける２次メツセージのテキストがある。たいていの言
語依存引数においては、言語依存的であるのは表示フォ
ーマットのみである。タイムスタンプの場合などのデー
タ自体は、固定的である。従って、その引数の生のデー
タを、受信側のノードに引数中のデータのタイプに対し
て注意させるフラグをつけて固定フォーマットでエンコ
ードされたメツセージ中に配置することができる。受信
側のノードは、そのフラグを認識すると、メツセージ構
成の間に引数をメツセージ変数と置換する時にユーザー
言語の規約に従いその引数をフォーマットすることがで
きる。エンコードされたメツセージにおけるそのような
引数データの厳密なフォーマットは、その製品について
標準化されている限り重要ではない。

しかし、それ自体が別のメツセージであるようなメツセ
ージ引数の場合、２次的メツセージのオブジェクト・コ
ード・イメージが突き止められなくてはならず、そのメ
ツセージは構成されなくてはならす、その構成されたメ
ツセージは、１次メツセージ中の変数に置き換えられな
くてはならない。このことはすべて、すべてのテキスト
がユーザーの言語で示されることを保証するために、こ
の例ではノード”Ｅ”である、受信ノードで生じなくて
はならない。この場合、エンコードされたメツセージ中
の引数のデータ部分自体が別のエンコードされたメツセ
ージ中にあり、受信側ノードにデータ・タイプを報知す
るために再びフラグが使用される。この構成は、プログ
ラム中の再帰的処理に好適に役立つものである。

別のメツセージ内に引数として埋めこまれたメツセージ
は、通常、長さが限定された単一出力ラインに限定され
た特殊なりラスのメツセージに属する。しかし、それら
は実際のメツセージであり、それらは自身の置換引数を
もつことができる。それらは、しばしば、メニュー画面
の限定され°たメツセージ表示領域内にそれ自体で表示
される。例示するなら、ノード”Ｆ”は、ノード”Ｅ”
のユーザーに次のようなメツセージを送ることができる
。

Ｔｈｅ　Ｆ　ｔｏ　Ｇ　１ｉｎｋ　ｈａｓ　ｇｏｎｅ　
ｄｏｗｎこの伝送を受信すると、ノード”Ｅ”はそのメ
ツセージ表示領域に表示された上記メツセージをもつメ
ニューを上記ユーザーに表示することができる。ノード
”Ｅ”は次に、ノード”Ｅ”のシステム・オペレータに
、上記メツセージを引数として使用する次のようなメツ
セージを使用することができる。

ＤＶＭＭＳＧ９９９１５ｅｓｓｉｏｎ　４５　ｈａｓ　
ｅｎｄｅｄ　ｂｅｃａｕｓｅ″Ｔｈｅ　Ｆ　ｔｏ　Ｇ　
１ｉｎｋ　ｈａｓｇｏｎｏ　ｄｏｗｎもし、ノード“Ｆ
”がノード”Ｅ“にエンコードされた形式のメツセージ
を送るなら、ノード”Ｅ”はそのユーザーに対してその
ユーザーの言語で、オペレータに対してはオペレータの
言語でメツセージを与える。そのとき、めいめいは、ノ
ード”Ｅ”がイネーブルされている言語を使用している
ことが必要なだけである。

ここで、製品のベンダが、新しいメツセージが定義され
た製品の新しいリリースを提供すると仮定しよう。もし
ノード”Ｅ”、”Ｆ”及び”Ｇ”が同時にこの新しいリ
リースに移行するならシナリオは変わらない。しかし、
ノード”Ｆ”がこの新しいリリースに移行し、ノード”
Ｅ”はそうではないと仮定しよう。それでも、ノード”
Ｆ”がノード”Ｅ”に送るメツセージが最初のリリース
で定義されていたものであるなら問題はない。しかし、
メツセージが新しいリリースで定義された新しいもので
あるなら、そのメツセージは、ノード”Ｅ”の言語オブ
ジェクト中で定義されていないため、ノード”Ｅ゛はエ
ンコードされたメツセージをデコードすることができな
い、ということになる。

この状況は、次のようにして処理することができる。

（１）言語オブジェクト中に定義された各メツセージに
、あるいは少なくとも各ネットワーク・メツセージに「
互換性レベル」を関連付け、後のリリースで定義された
メツセージについてはレベルが高位または下位になるよ
うにして、その製品の所与のリリース中に定義されてい
る全てのメツセージにつきレベルが同一であるようにす
る（ここでは、説明の便宜上、後のリリースで追加され
たメツセージについてはレベルが増分されるようにする
ものと仮定する）。

（２）ある設備の言語オブジェクトの最高の互換性レベ
ル、すなわち最も最近の製品に定義されたメツセージの
互換性レベルを、その設備の互換性レベルであると考え
る。

（３）設備に特定の「ネットワーク」言語に対処する。

これは、設備がその製品をイネーブルしたなんらかの言
語でよいが、ユーザーがそのローカル・サイトでネット
ワークに入る設備特定のデフオールドである必要はない
。

互換性レベルが言語ソース・オブジェクトに関連付けら
れる様式は、その互換性レベルがそのメツセージのオブ
ジェクト・コード・イメージとともに格納され、メツセ
ージに関連付けられた最高位の互換性レベルが、その言
語オブジェクトを使用したプログラムによるアクセスの
ためのフィールド中に配置されている限り、重要ではな
い。もしそのオブジェクト・コードを作成するためにそ
の言語ソース・オブジェクトを処理するプログラムが、
任意の順序でメツセージを処理するのに十分なだけ洗練
されているなら、例えば、互換性レベルは、単に新しい
メツセージ定義の前に制御ラインをコーディングするだ
けで新しいメツセージの組全体に確立することができる
。さもなくば、互換性レベルは、各メツセージにつき個
別に確立する必要があろう。もしメツセージが、ユーザ
ーの言語中のネットワークの°どこにも定義されていな
いなら、ユーザーの言語中でメツセージを発行すること
は物理的に不可能である。、「ネットワーク」言語は、
そのような状況が生じた時に使用すべき共通の言語に設
備が合意するところの妥協である。選択されたその言語
が最も広くサポートされているキャラクタ・セットを用
いてそのネットワークの文脈で最も広く理解されている
言語である、ということはありそうなことである。

ノード“Ｅ”におけるユーザーがネットワークを通じて
ノード”Ｇ”のアプリケーションと対話的セツションを
開輸する時、ノード”Ｅ“は、そのユーザー言語を識別
する情報を含む、制御ブロックをセットアツプする。ノ
ード“Ｅ”は次に、セツション開始パケットをノード”
Ｆ”に送信し、とりわけノード”Ｆ“に自己の互換性レ
ベルを配置する。ノード”Ｆ”は、自己の制御ブロック
中に、別のものとともに、ノード”Ｅ”の互換性レベル
をセーブし、そのパケットをノード“Ｇ“に送信する。

ノード”Ｇ”はまた、そのセツションのための制御ブロ
ックをセットアツプし、ユーザーのノード、すなわちノ
ード“Ｅ”の互換性レベルと、他に必要な全てのものと
をセーブする。ノード”Ｆ”及び”Ｇ”の間の通信リン
クが不能になった時、ユーザーが遠隔サイトにいること
を確認すると、通信リンクはそのネットワーク言語中の
適当なメツセージを調べて、そのメツセージの互換性レ
ベルをユーザーの設備の互換性レベルと比較する。もし
そのメツセージの互換性レベルがユーザー設備の互換性
レベルよりも高いなら、ノード”Ｆ”はそのネットワー
ク言語中にそのメツセージを構成し、それをユーザーに
送る。というのは、そのユーザー設備は、そのメツセー
ジに対して下位レベルにあるからである。そうでなけれ
ば、ノード“Ｆ“がエンコードされたメツセージを構成
してそれをノード”Ｅ“に送る。ノード”Ｆ“がノード
”Ｅ”に送るメツセージ・パケットに含まれているのは
、そのパケットのデータ・フィールドがエンコードされ
ているかどうかの表示である。

もしノード”Ｆ”がノード”Ｅ”のユーザーに送るメツ
セージが置換引数としての２次メツセージを要求するな
ら、ノード”Ｆ”はまた、その２次メツセージをも調べ
て、１次メツセージのエンコード形式が使用されている
とすると、ノード“Ｅ”がそのメツセージのエンコード
された形式を受は取るための互換性を有するかどうかの
同様の決定を行わなくてはならない。もしノード”Ｅ“
がその両方のメツセージと互換性があるなら、ノード”
Ｆ”は、ノード”Ｅ”に埋めこみエンコード・メツセー
ジの存在に対する注意を喚起するためのフラグを使用し
て、前述したようにエンコードされたメツセージを構成
する。

もしノード”Ｅ”が１次メツセージとは互換性を有する
けれども２次メツセージとは互換性を有さないなら、ノ
ード”Ｆ”は、そのネットワーク言語中で２次メツセー
ジを構成し、それを引数として１次メツセージ中に含め
ることになる。この場合フラグは必要でない。というの
は、その引数は既に出力形式であるからである。もしノ
ード”Ｅ”が１次メツセージと互換性をもたないならば
、ノード”Ｆ”はそのメツセージ全体を構成することに
なる。ノード“Ｆ”が、エンコードされていないメツセ
ージ内にエンコー′ドされたメツセージを埋めこむこと
はない。

また、全てのネットワーク・トラフィックが対話的であ
る必要はない。もしノード”Ｅ″におけるユーザーがネ
ットワークを通じてノード“Ｇ”にいるユーザーにメツ
セージまたはファイルを送信しているなら、そのトラフ
ィックを処理しているノードは、上述の様式では制御ブ
ロックを維持しないことになる。この場合、ユーザーの
言語を識別する情報と、ノード”Ｅ”の互換性レベルの
両方が、ネットワークを通じて送られるパケットの制御
データ部分に格納されることになる。そのユーザーにメ
ツセージを送り返す必要のあるノードは、それらのパケ
ットのうちの１つがらノード”Ｅ”の互換性レベルを取
得し、そのメツセージを含むパケットとしてノード”Ｅ
”に言語識別情報を戻すことになる。これらの状況のお
のおのにおいて、ユーザーのローカル・ノードのみしか
、ユーザーが使用しつつある言語に関与しない。それゆ
え、ユーザーの言語を識別する情報は、そのユーザーの
ローカル・ノードにおけるユーザーの言語に関連付けら
れた単一の数でよい。その単一の数は、制御ブロック及
びネットワーク・パケット中で最小量のスペースしか必
要ヒせず、それと同一の数が、別のノードの異なる言語
のために使用されているかどうかに構わない。

低いレベルのノードでネットワークに入るユーザーのみ
しか、別のノードの新しいネットワーク言語で示された
メツセージのうちの幾つかを眺める必要はない、という
ことに留意されたい。というのは、製品の最も新しいリ
リースを走らせているノードは、ネットワーク中のエン
コードされた形式の任意のメツセージとの互換性を有す
るからである。それゆえ、この方法は、すべてのノード
をして製品の最新のリリースへと移行させる動機付けを
与えることになる。

ここで、製品サービスまたは設備の変更などの、リリー
ス間のネットワーク製品に追加されるメツセージについ
て考慮してみよう。これらのメツセージには、サービス
され、または変更されつつある製品のリリースに適応す
る互換性レベルを割当てることができ、これは厳密にロ
ーカル・サイトで発行されるメツセージに対しては常に
うまく行くものである。それはまた、その製品のそのリ
リースまたはその後のリリースを走らせている設備がす
べて、その言語オブジェクトに対するサービスまたは変
更を導入する予定である限り、ネットワーク・メツセー
ジに対してもうまくゆくものである。

しかし、多くの場合、すべての設゛備がサービスの適用
を受けることを選択する訳ではないし、すべての設備に
、別の設備によって書かれた変更を進んで受は入れるよ
うに期待することはできない。

その言語オブジェクトに対するそのようなサービスまた
は変更を受けることを選択しない設備でネットワークに
入るユーザーは、追加されたメツセージを眺めることは
決してない。というのは、そのユーザーのローカル・ノ
ードは、たとえそれらのメツセージがその言語オブジェ
クトで定義されていないとしても、ネットワークの他の
箇所には、それらのメツセージをエンコードされた形式
で受は取ることに適合性を有するように見えるからであ
る。

製品のベンダによって提供されたサービスの場合、これ
らのメツセージは、厳密に製品のリリースで定義された
ように（それは、ベンダが、内容が累積的であるような
置換言語オブジェクトを積極的に配布するならば、であ
るが）これらのメツセージがうまくゆくように、互換性
スキーム中に混合することができる。

例えば、複数のメツセージにそれぞれ１及び２の互換性
レベルが割当てられてなる製品のリリースが存在すると
仮定しよう。するとベンダはサービス配布処理を通じて
その製品の幾つかの新しい機能を配布することを選択す
る。その理由は、新しい機能の量が、新しいリリースを
理由付けするに十分なだけ大きくない、ということであ
る。その新しいメツセージに３という互換性レベルを割
当てることによって、ベンダは、コードの変更とともに
、言語オブジェクトの完全な代替を配布するのである。

新しい機能を導入することを選択した設備は、３という
互換性レベルを有することになり、その言語オブジェク
トは、互換性レベル１の全てのメツセージと、互換性レ
ベル２の全てのメツセージと、互換性レベル３の全ての
メツセージを含むことになる。このことは、設備が最初
のリリースの製品を走らせている場合にも当てはまる。

言語互換性レベルは、機能的には製品リリース・レベル
とは独立である。実際、製品の次のリリースで追加され
るメツセージは、現在リリース３であるとすると、４と
いう互換性レベルを割当てられることになる。

しかし、上述の状況は、サービス処理が主として問題の
ためのコード訂正を与えるためのものであるがゆえに、
典型的でない。コードの修正に伴い、製品のあるリリー
スにメツセージが付与される時、特にベンダのサービス
組織が開発組織から離れているならば、ベンダが新しい
互換性レベルと分配累積言語オブジェクトを割り振らな
くてはならない、ということは負担が大きい、。さらに
、設備の変更をこのようにして処理することは実質的に
不可能である。

この状況は、製品の互換性レベルに任意の数の限界をセ
ットしておき、その限界を外れる互換性レベルを、リリ
ースの間に製品に追加される各メツセージに注意深く付
与し、以て遠隔サイトがそのメツセージをエンコード形
式で受は取ることに決して適合性を有さないようにする
ことによって処理することができる。もし製品によって
サポートされる最高位の互換性レベルが例えば１２５で
あるなら、リリースの間にその製品に追加される任意の
メツセージには１２６という互換性レベルを割当てるこ
とができるが、その言語ソース・オブジェクトを処理す
るプログラムは、その設備の互換性レベルを決定する時
は、その１２６という値を考慮しない。その結果、リリ
ースの間に製品に追加されるメツセージは、遠隔サイト
に対してメツセージを発行しつつあるノードのネットワ
ーク言語で発行される。というのは、遠隔設備の互換性
レベルは常に１２６よりも小さいからである。

製品サービスを通じて製品に追加されるメツセージは、
製品の次のリリースにおける互換性スキーム中で捕捉す
ることができ、以に製品の開発組織の範囲にそのメツセ
ージを維持することによって互換性スキームを管理可能
なものに維持する。

サービスまたは設備変更を通じて、リリースの間に言語
オブジェクトに追加されるメツセージを発行するノード
は、常にそのネットワーク言語で遠隔サイトにそのメツ
セージを発行することを義務付けられるが、それと同一
のメツセージを互換性スキーム中に含められてなる後の
リリースを走らせるノードはそうではない。

既存の互換性レベルでメツセージを追加すること、新し
い互換性レベルでメツセージを追加して言語オブジェク
トを累積的言語オブジェクトで置き換えること、及び遠
隔サイトがメツセージをエンコードされた形式で受信す
ることに適合性をもたないようにメツセージを追加する
こと、という３つの代替策のうちでどれが、サービスに
関連して製品のベンダがメツセージを追加するために使
用する最良の策であるか、ということは、ベンダのサー
ビス組織と方針に依存することになろう。

しかし、おそらく、設備の変更に伴ってメツセージを追
加するためには、その第３番目の施策が最善であると思
われる。

ここで１、製品がＮＬＳのサポートを開始するリリース
の前に、１つのまたはそれ以上のリリースが存在し、製
品ベンダが、製品のＮＬＳなし及びＮＬＳサポート・リ
リースの両方を同一のネットワークに共存させることを
望んでいると仮定する。

このサポートは、その製品のネットワーク・パケットの
アーキテクチャが、衝突あるいはＮＬＳサポート以前の
コードに対する必要なく、ＮＬＳサポート以前及びＮＬ
Ｓサポートの両方の情報の必要性に適合することができ
る限り、提供することができる。そこで、次のことを考
慮してみる。

（１）上記例におけるノード”Ｅ”などのＮＬＳサポー
ト・ユーザー・ノードは、別のＮＬＳサポート・ノード
に、自分がＮＬＳをサポートする能力があることを知ら
せなくてはならない。ＮＬＳサポート以前のリリースに
よって使用されていないフラグは、それが常にＮＬＳサ
ポート以前のリリースによって既知の値に初期化されて
いる限り、この目的には理想的である。

（２）ＮＬＳサポート・ノードは、別のＮＬＳサポート
・ノードに、その設備互換性レベルを通信することがで
きなくてはならず、使用されるそのフィールドは、新し
いものであれ古いものであれ、ＮＬＳサポート以前のリ
リースによるそれと同一のフィールドの既存の使用と衝
突してはならない。

（３）場合によっては、ＮＬＳサポート・ノードは、ネ
ットワーク・パケット中のユーザーの言語識別情報を記
憶することができなくてはならず、これにより、別のＮ
ＬＳサポート・ノードは、エンコードされたメツセージ
を戻すときにユーザーのノードにその情報を戻すことが
できる。前述のように、この必要条件は、ユーザーがセ
ツションに係わっておらず、寧ろメツセージ、ファイル
、コマンドまたはそれと同様なデータを遠隔サイトに送
っているか、または応答を受信することができないとき
に発生する。このときも、この情報のために使用されて
いるフィールドは、ＮＬＳサポート以前のリリースによ
る同一のフィールドの既存の使用と衝突してはならない
。

（４）ＮＬＳサポート・ノードがやはりＮＬＳをサポー
トす甚ユーザー・ノードにエンコード°されたメツセー
ジを送信する時、ＮＬＳサポート・ノードは、そのメツ
セージがエンコードされていることを示すことができな
くてはならない。もしＮＬＳサポート以前のリリースに
よっである不使用フラグが既知の値に常に初期化される
なら、そのようなフラグはやはり理想的であるが、この
ことは、まずデータがエンコードされたメツセージであ
るに十分な長さであることを検証した後エンコードされ
たメツセージ中のフィールドから決定することもできる
。

ここで、前述の例と同様に、その製品によってサポート
される最も低い互換性レベルが１であると仮定する。ノ
ード”Ｅ“におけるユーザーがネットワークを通じてノ
ード”Ｇ”にあるアプリケーションとの対話的セツショ
ンを開始する時、ノード”Ｅ″はノード”Ｆ”にセツシ
ョン開始パケットを送る。ノード”Ｆ”がＮＬＳをサポ
ートすると仮定すると、ノード”下”は、ユーザー・ノ
ードであるノード”Ｅ“がＮＬＳをサポートするかどう
かを決定するために、まずそのセツション開始パケット
中のｒＮＬＳフラグ」を検査する。そして、もしそうな
ら、ノード”Ｆ“は、そのセツションのためにノード”
Ｆ”がセットアツプする制御ブロックにノ−ド”Ｅ”の
互換性レベルを記録し、そのセツション開始パケットを
ノード”Ｇ”に送る。その結果は前述の例で説明した通
りである。

しかし、もしノード”Ｅ”がＮＬＳをサポートしないな
ら、ノード”Ｆ”は制御ブロックにゼロを配置する。こ
こには、さもなければノード２Ｅ”の互換性レベルが記
録されるところである。こうしてノード”Ｅ＠を、ゼロ
の互換性レベルをもつものとして効率的に処理すること
になる。そうして、前述のように、ノード゛Ｆ”はノー
ド”Ｇ“にセツション開始パケットを送る。ゼロは、ど
のメツセージの最低互換性レベルよりも低いので、ＮＬ
Ｓサポート・ノードによってノード”Ｅ”にあるユーザ
ーに送られるどのメツセージも常にＮＬＳサポート・ノ
ードのネットワーク言語で記述されることになる。とい
うのは、ノード“Ｅ”はエンコードされた形式のメツセ
ージに対して適合的であるようには決して知覚されない
からである。

しかし、もしノード”Ｆ”がＮＬＳサポート以前のノー
ドであるなら、ノード”Ｆ”は、その制御ブロックをセ
ットアツプしてセツション開始パケ・ントをノード”Ｇ
”に送るだけである。このとき、ノード“Ｆ”はｒＮＬ
Ｓフラグ」について知らないし、互換性レベルを探しも
しない。ノード”Ｆ”がどこかのノードにいるユーザー
に送るメツセージは、ノード”Ｆ”が常に使用している
言語であり、ＮＬＳサポート・ノードが、メツセージが
エンコードされているかどうかを決定するために使用す
るフラグは、ＮＬＳサポート以前のノードであることを
示すことなく、メツセージがエンコードされた形式では
ないことを示す。

ユーザーが、遠隔ノードにある別のユーザーにメツセー
ジまたはファイルを送る場合などのような、非セツショ
ン状態の時は、ＮＬＳサポート・ノードはユーザーにメ
ツセージを返す必要があるときのみｒＮＬＳフラグ」を
検査し、ユーザーのノードがＮＬＳをサポートしないな
ら常にそのネットワーク言語でメツセージを発行する。

もしＮＬＳサポート以前のノードがそれと同一の状況に
ある時ユーザーにメツセージを返す必要があるなら、Ｎ
ＬＳサポート以前のノードは、自分が常に使用している
言語でそうするだけである。

もしネットワーク製品が、メニュー画面などの画面を利
用するなら、翻訳のために必要な拡張スペースを与える
べく、ＮＬＳサポート以前のリリースの画面がＮＬＳサ
ポート・リリースのために再設計されなくてはならない
、ということは十分あり得る。また、これらの画面上の
メツセージ表示領域が、翻訳によって生じるより長いメ
ツセージを収容するために、サイズを増大させなくては
ならない、ということもありそうなことである。

もしある製品が、画面のイメージをネットワークを通じ
て伝送するなら、ここで説明したメツセージのための方
法は、単に各画面イメージに画面番号を割当てることに
よって容易に画面イメージに適用することができる。画
面イメージのエンコードされた形式は、画面上に表示す
べきメツセージを前述の２次メツセージのように処理す
ることができる点までも、メツセージのエンコードされ
た形式に同一であり得る。

しかし、特にメニュー画面の場合しばしばそうであるけ
れども、もしその製品の画面が厳密にローカル・・サイ
トで処理され、その製品のＮＬＳサポート・リリースが
ＮＬＳリリースと共存することになっているなら、その
ＮＬＳサポート・リリースは、ＮＬＳサポート以前の画
面のメツセージ表示領域に適合するＮＬＳサポート以前
のノードにいるユーザーにメツセージを発行することが
できなくてはならない。

この状況は、各ＮＬＳサポート・ノードに、いわゆる「
対応メツセージ」を提供することによって解決すること
ができる。これは、ＮＬＳサポート以前のメツセージ及
び画面にしようされた言語で表現された非翻訳メツセー
ジであって、ＮＬＳサポート以前の画面にはまり込むも
のである。

以前に、特殊なりラスのメツセージが、−船釣に画面の
メツセージ表示領域に表示するために使用されると述べ
た。ここで、これらのメツセージには、７０００乃至７
９９９の内部メツセージ番号が割当てられてなる、と仮
定しよう。もしノード“Ｆ゛がメツセージ７０５０をノ
ード”Ｅ”のユーザーに発行する必要があり、ノード”
Ｅ“が、ＮＬＳサポート・ノードであるなら、ノード”
Ｆ“は、ノード”Ｅ”がエンコードされた形式でメツセ
ージ７０５０を受は取ることに互換性を有するかどうか
に依存して、メツセージ７０５０をエンコードされた形
式またはそのネットワーク言語のどちらかの形式で伝送
する。別法として、ノード”Ｅ”が、ユーザーの言語で
示されている画面のメツセージ表示領域内でユーザーに
メツセージを表示し、メツセージがそれにはまり込むよ
うにするのもある。

というのは、画面はＮＬＳサポートのために設計されて
いることになるからである。

しかし、ノード”Ｅ”がＮＬＳサポート以前のノードで
あるなら、ノード”Ｆ”のネットワーク言語で書かれた
メツセージ７０５０は、ノード“Ｅ”によって使用され
つつあるＮＬＳサポート以前の画面のメツセージ表示領
域にはまり込むことはできない。それゆえ、ノード”Ｆ
”は、その代わりにメツセージ７０５０の「対応メツセ
ージ」を発行することになる。７０００乃至７９９９の
範囲にある定義された各メツセージは、対応メツセージ
をもち、その意味は、対応するメツセージの意味と同一
である。

対応メツセージには、容易に導出される内部メツセージ
番号が割当てられていなくてはならない。

例えば、もし対応メツセージに８０００乃至８９９９の
内部メツセージ番号が割当てられるなら、メツセージ７
０５０のための対応メツセージは、そのメツセージ番号
に単に１０００を加えることによって得られる。

対応メツセージは翻訳されないので、任意の設備にはそ
れらが１組あればよい。このことは、ネットワーク言語
の仕様を「コンパイル」時間で生じさせる（すなわち、
それらをオブジェクト・コードに変換するために、言語
ソース・オブジェクトを処理するプログラムに対するオ
プションとして）ことによって達成することができる。

そのプログラムは、ネットワーク言語のソース・オブジ
ェクトをコンパイルするときはオブジェクト・コード中
の、例えば８０００乃至８９９９と番号を振られた対応
メツセージを含み、ネットワーク言語として識別されな
かった言語のソース・コードをコンパイルするときには
、それらを除外する。

ベンダ・プログラムが、モニタ・プログラムまたはコマ
ンドを介して統計を集計し処理するために書かれたプロ
グラムなどの、ユーザーが書いたアプリケーションに対
してメツセージを通信することができることが有用なこ
とがある。このことは、ユーザーにそのメツセージを表
示することの代わりに、またはそれに追加して行うこと
ができる。

このタイプの通信の問題は、ユーザー・アプリケーショ
ンが、通常置換値の形式である、必要なデータを抽出す
るために、そのメツセージの言語テキストをふるいにか
けなくてはならない、ということである。その作業は、
メツセージが単一の言語であるときでも十分に困難であ
るが、製品が多重言語をサポートしているときにはさら
に困難である。

この問題は、仮想のオペレーティング・システムによっ
て与えられる伝送設備の特性が考慮される限り、これら
のユーザーが書いたアプリケーションとの言語独立なイ
ンターフェースを提供することによって解決することが
できる。

例えば、ユーザーが書いた言語に言語独立なメツセージ
を伝送するために利用可能な唯一の方法が、オペレーテ
ィング・システムの通常の表示設備であるなら、エンコ
ードされたメツセージは、完全に表示可能なキャラクタ
からなっていなくてはならない。これは、ハードフェア
のエラーを防止するため通常、オペレーティング・シス
テムが、表示不可能なキャラクタをブランクに変換する
からである。

例示のため、数字°２１°をＥＢＣＤＩＣ規格を使用す
るコンピュータで表現することを考えてみよう。

表示可能形式（１６進）：Ｘ’Ｆ２Ｆ１°　（２キヤラ
クタが必要） ２進形式（１６進）：Ｘ’１５′　（１キャラク夕が必
要） プログラムは通常、内部の数及びフラグのために２進形
式を使用するので、ベンダ・プログラムによってエンコ
ードされたメツセージが構成されるときは変換を行う必
要があるかもしれず、その変換は、採用されるプログラ
ム言語に応じて、ユーザーが書いたアプリケーションに
よって逆に実行する必要があるかもしれない。

しかし、場合によっては、オペレーティング・システム
が、１つのアドレス空間から別のアドレス空間へデータ
を転送するための別の方法を提供し、ベンダの製品が、
そのエンコードそれたメツセージをユーザーが書いたア
プリケーションに通信するためにこの別の方法を利用す
ることができることがある。ＩＢＭ仮想マシン（ＶＭ）
オペレーティング・システムによって提供されるこの特
殊なメツセージ機能は、その名称が意味するところに違
い、その目的がなんらメツセージを扱うものではないに
せよ、良好な例である。

ＶＭの特殊メツセージ機能は、１２９キヤラクタの２進
データを１つの仮想マシンから別の仮想マシン上で走る
プログラムに伝送することを可能ならしめる機能をもつ
。しかし、小さいけれども１つの奇妙な点があって、そ
れは、Ｘ°１５°というキャラクタが、１つのコマンド
が終了し、別のコマンドがそれに続くことを意味すると
解釈される、ということである。従って、Ｘ゛１５°が
あられれる度毎に、それは、エンコードされたメツセー
ジを伝送するべくこの機能を利用するために、エンコー
ドされたメツセージ中に他にあられれないような別のキ
ャラクタに変換されなくてはならない。

また、２５５　（Ｘ’ＦＦ’）という数は、ベンダの製
品のエンコードされたメツセージ中のメツセージ番号に
しか現れない、ということも述べておきたい。この場合
、単に、エンコードされたメツセージ中のメツセージ番
号の発生毎にそれを２倍して、Ｘ°１５°の発生毎にそ
れをＸ’ＦＦ’に変換するだけでＶＭの特殊メツセージ
機能を使用することができる。すると、ユーザーが書い
たアプリケーションは、まずＸ’ＦＦ’が現れるとそれ
をＸ゛１５゛に変換し、各メツセージ番号を２で割る必
要がある。しかし、この手続きは、表示可能なキャラク
タをバイナリに変換するよりもはるかに複雑でないであ
ろう。

ここで述べた方法は、単一製品の単一要素に限定される
ものではなく、単一の製品に限定されるものでもない。

この例では、ユーザーのノードであるノード”Ｅ”は、
データベース・コマンドのシンタックスをチエツクし、
それを、この例ではノード”Ｇ”などのメインフレーム
・コンピュータ上で走るデータベース・マネジャのため
の内部形式に配置する機能をもつアプリケーションを走
らせるワークステーションまたはデスクトップ・コンピ
ュータのような簡単なものでよい。データベース・マネ
ジャがネットワークを通じてユーザーに発行することが
できるこれらのメツセージは、デスクトップ・アプリケ
ーションのシンタックス・エラー・メツセージとともに
言語オブジェクト中に定義することができ、以てコマン
ドのシンタックス・チエツクと言語的配應の両方がメイ
ンレームからデスクトップへオフロードされることにな
る。

さて、マルチタスク管理システムの制御のもとで次のよ
うな要素が機能する小さいネットワーク製品のモデルを
考えてみよう。

（１）ネットワーク・マネジャー・タスク（Ａ）セツシ
ョン開始パケット、セツション終了パケット、及びコマ
ンドまたはメツセージを含む非対話的パケットを有する
ネットワーク制御パケットの処理（制御フラグは、ネッ
トワーク・マネジャ・タスクがそれを処理するべきであ
ることを−示すためにネットワーク制御パケットで常に
セットされている）。

（Ｂ）データの流れを最適化し、セツションの間にネッ
トワーク・マネジャ制御の必要性をなくすために、対話
的セツションの開始の間のリンケージをセットアツプし
、セツションが非ローカル・ユーザーに関連する時に適
用される、中間的、またはアプリケーション制御ブロッ
クをセットアツブすること。

（ｃ）セツションの終了の間に上述の処理を反転するこ
と。

（Ｄ）非対話的コマンドまたはメツセージを含むパケッ
トをその宛先に経路指示すること。

（２）書き手（書き込み）のタスク ＜Ａ）オペレーティング・システムの通常のメツセージ
表示機能を使用して非対話的ユーザーにメツセージを表
示すること。

（Ｂ）特殊フラグが、そのメツセージを含むバッファ中
でセットされている時オペレーティング・システムによ
って与えられると想定される特殊な機能を使用してユー
ザーが書いたアプリケーションにデータを伝送すること
。

（３）コマンド・プロセッサ・タスク （Ａ）非対話的ユーザーによって入力されたコマンドを
処理すること。

（４）ユーザー・インターフェース・タスク（Ａ）対話
的ユーザーがネットワークを通じて確立し対話的セツシ
ョンに人、るための表示ユニットの制御 （Ｂ）メニュー画面を表示し、その上でのユーザー選択
を処理し、ユーザーがセツションの選択を行った時その
セツション開始パケットを作成すること。

（５）アプリケーション・インターフェース・タスク （Ａ）ネットワーク製品と、対話的ユーザーによって使
用されているアプリケーションの間のインターフェース
を与えること （Ｂ）通常のユーザー・サインオフに従い、ユーザーに
関してそのネットワーク製品との接続をアプリケーショ
ンが切断するとき、セツション終了バケ・シトを作成す
る （６−）メ―ンセージ・ハンドラ （Ａ）非対話的ユーザーに対する表示に差し向けられた
メツセージの位置を構成し処理するだめのサブルーチン
として呼ばれる （Ｂ）非対話的ユーザーに対する表示のために遠隔す゛
イトから受信したエンコードされたメツセージをデコー
ドしそれを表示のためユーザーの言語で構成するために
、書き手のタスクによってサブルーチンとして呼び出さ
れる （ｃ）呼び出し側のルーチンによって指定された領域中
に対話的ユーザー・メツセージを構成するためにサブル
ーチンとして呼び出される（７）通信ライン・ドライバ
・タスク （Ａ）その製品の別の装置と通信するために使用される
特定の通信ラインの制御（対応タスクが、別の設備にあ
るそのと同一の通信ラインを制御する） （Ｂ）ラインが動作不能になったと決定された時に通信
ラインを利用する各対話的セツション毎にシッション終
了パケットを制御すること（８）割り込みハンドラ （Ａ）主として、コマンドが非対話的ユーザーによって
入力されたときコマンド・バッファの構成を示すために
モデル中に含まれている このモデル・ネットワーク製品は、サポートされた言語
のテーブルの存在を想定し、それは次のように見えるか
もしれない。

！アドレス１！言語１を識別するストリンク゛！十−−
−噛一−−−−−−＋−−−−−−−−−−−−−−−
−−−−−−−−＋！アドレス２！言語２を識別するス
トリンク゛！＋−−−−−−−−−−−＋−−−−−−
−＝−−一−−−−−−−−−−−−＋！アドレスｎ！
言語ｎを識別するストリンク゛！ここで、このテーブル
は、このモデル・ネットワーク言語によってサポートさ
れた各言語毎にエントリを含み、ｎ個のエントリがある
、と仮定されている。さらに、各エントリ中のアドレス
・フィールドは、識別された言語の言語オブジェクトの
ベース・アドレスまたはゼロを含み、ゼロはその設備が
その言語に対してイメーブルされていないことを示す。

ストリングとは単に、対話的メニューまたは、非対話的
コマンドのシンタックス上で言語を記述することができ
るキャラクタ・ストリングである。

このテーブルを用いると、もし言語番号または言語を識
別するストリングが既知なら、所与の言語のベース・ア
ドレスを直ちに得ることができる。

このモデルでは、その設備のデフオールド言語及びその
バックアップ・ネットワーク言語が、テーブル中以外に
も、効率的配置のため別のメモリ位置に格納されている
と仮定されている。

亙量的立ヱ之１之 このネットワーク製品によって制御される表示ユニ、ッ
トがオンに切替られる時、その表示ユニットのためのユ
ーザー・インターフェース・タスクに制御が与えられ、
ユーザー・インターフェース・タスクは、その設備のデ
フオールド言語でメニューを表示する。ユーザーは次に
、メニュー上のオプションを使用して言語を選択し、ま
たはセツションを選択する。ユーザー・インターフェー
ス・タスクは、とりわけ、その表示装置で現在使用され
つつある言語を一意的に識別する数を含むユーザー制御
ブロックを維持する。

ここで、ユーザー・インターフェース・タスクのフロー
チャート（第４図）を参照すると、このタスクは、表示
する直前のメニュー画面上のメツセージ表示領域にコピ
ーすることになるメツセージ領域をクリアする（ボック
ス１）。初期化（ボックス２）に際して、タスクはユー
ザー制御ブロックにデフオールド言語番号を配置しくボ
ックス３）、画面イメージを記憶するためのバッファを
獲得しくボックス２６）、サポートされている言語テー
ブル中の言語を突き止めるためにユーザー制御ブロック
中の言語番号を使用し、それを画面バッファ中にコピー
する（ボックス１８）。最後に、タスクは、ボックス１
でクリアしたメツセージ領域を画面イメージのメツセー
ジ表示領域にコピーし、メニューを表示する（ボックス
１９）。

ユーザーが画面上で変更を行ったためにユーザー・イン
ターフェース・タスクが制°御を入手した時（ボックス
５）、ユーザー・インターフェース・タスクは、ユーザ
ーが言語を変更したかどうかを最初にチエツクする（ボ
ックス８）。もしそうであり示された言語が可用である
なら（ボックス１０及び１１）、タスクはユーザー制御
ブロック中で言語を識別する番号を記憶する（ボックス
１４）。

この新しい言語は、論理がボックス１８を通じて流れて
行くので、次にメニューが表示される時に使用される。

ユーザーがセツションを選択する時（ボックス１５）、
ユーザー・インターフェース・タスクは、セ・シション
開始パケットを作成し、そこではＮＬＳフラグがセット
され、ローカル・ノードの互換性レベルが配置される（
ボックス１６）。ユーザー・インターフェース・タスク
は、次に、そのパケットをネットワーク・マネジャに対
して「通知」する。このことは単に、そのパケットがネ
ットワーク・マネジャのための作業の一部として待ち行
列に入れられることを意味するに過ぎない。ネットワー
ク・マネジャは、その作業の一部を処理するために、マ
ルチ・タスク・管理プログラムによって最終的にはディ
スパッチされることになる。

さて、上述のニー゛ザーがノード”Ｅ゛にあり、ノード
“Ｇ”にあるアプリケーションとのセツションを選択し
たとしよう。ネットワーク・マネジャのフローチャート
（第５図）を眺めると、タスクは、ローカル・ノードが
ノード”Ｅ”であるために、パケットの宛先であるノー
ド”Ｇ”がローカルでないことを見て取ることになる。

それゆえ、タスクは、ノード”Ｇ”が定義されている、
すなわち”Ｇ”と称する宛先ノードにそれを搬送するた
めにノード”Ｅ”がパケットをノード”Ｆ”に送ること
を確認する（ボックス３）。論理は次に、ボ・ンクス４
．８．９．１０及び１４を通ってボックス１５に到達し
、そこでタスクは、ユーザー・インターフェース・タス
クと、ノード”Ｆ”との通信を処理するライン・ドライ
バ・タスクとの間のいくらかのリンケージをセットアツ
プし、以てこれら２つのタスクが、セツションが活動的
である間に違いに通知できるようにする。最後に、タス
クは、セツション開始パケットでライン・ドライバ・タ
スクに通知する（ボックス１９）。

ライン・ドライバ・タスクのためのフローチャ−ト（第
９図）を参照すると、タスクは、そのパケットの宛先が
ノード“Ｇ”であってノード”Ｅ“ではないので（ボッ
クス１）、パケット中のデータをノード°Ｆ“に送ろう
と試みる（ボックス２）。

それが成功すると（ボックス３）、タスクは単に、ロー
カル・サイトのデータのために使用されていたバッファ
を解放する（ボックス４）。

ところで、ノード”Ｆ”でのライン・ドライバ・タスク
は、入来データを処理するようにディスパッチされ（ボ
ックス１）、ノード“Ｆ”でデータを入れるためのバッ
ファを獲得し、それを受信しようと試みる（ボックス８
）。それが成功すると（ボックス９）、パケット中の制
御フラグがセットされ（ボックス１０）、それがノード
”Ｆ“のネットワーク・マネジャに通知されることが見
て取れよう（ボックス１１）。

ノー戸Ｆ“でのネットワーク・マネジャ論理は、ボック
ス１１．３．４．９．１０及び１４を通ってボックス１
６に到達し、そこで、タスクは、ノード”Ｆ”がセツシ
ョン開始パケットの出発点（オリジン）ではなく宛先で
もない、という事実により、中間制御ブロックをセット
アツプする。タスクは、その制御ブロック中にゼロとい
う互換性レベルを配置し、このことは、そのユーザーの
ノードがＮＬＳをサポートしておらず、２つのライン・
ドライバ、すなわち１つはノード”Ｅ”との通信を制御
するものであり、もう１つはノード”Ｇ”との通信を制
御するものである、の間のリンケージをセットアツプす
る。しかし、パケット中でＮＬＳフラグがセットされて
いるのを見出すと（ボックス１７）、タスクは互換性レ
ベルを、パケットに示されている互換性レベルに変更す
る（ボックス１８）。

最後に、タスクは、そのパケットを、ノード”Ｇ”との
通信を処理するライン・ドライバに通知する（ボックス
１９）。

ノード＠　Ｆ　ＩＩ及びノード”Ｇ”の間のライン・ド
ライバは、ノード”Ｅ”及びノード”Ｆ“の間のライン
・ドライバと同じことをするので、パケットはノード“
Ｇ”でネットワーク・マネジャに通知されて終了するこ
とになる。

ノード”Ｇ”のネットワーク・マネジャが、それがセツ
ション開始パケットの宛先であることを見出した時（ボ
ックス１）、ネットワーク・マネジャはネットワーク・
マネジャの第２のフローチャート上のＡ点に進む（第６
図）。この論理は次に、ボックス１．３及び５を通って
ボ・ンクス６に到達し、ここでユーザーによって要求さ
れたアプリケーションがノード”Ｇ”で専用であること
をチエツクされる。

要求されたアプリケーションが専用であることを見出す
と（ボックス７）、タスクはそのセツション（ボックス
９）及び、入来ライン・ドライバとアプリケーション・
インターフェース・タスクの間のリンケージ（連結）の
ためのアプリケーション制御ブロックをセットアツプす
る。ユーザーはノード°Ｇ“に位置しておらず（ボック
ス１０）、ＮＬＳフラグはパケット中でセットされてい
るので、タスクは制御ブロック中の互換性レベルを、セ
ツション開始パケットによって示されている互換性レベ
ルに変更する（ボックス１３）。最後に、タスクは、そ
のパケットをアプリケーション・インターフェース・タ
スクに通知する（ボックス１４）。

アプリケーション・インターフェース・タスクのフロー
チャート（第８図））を参照すると、タスクは、セツシ
ョン開始パケットを通知されたことを見出すと（ボック
ス１．２及び４）、アプリケーションとの接続をそのよ
うに確立する（ボックス５）。

この時点で、対話的セツションがネットワーク・マネジ
ャ制御なしで進むためのすべてのリンケージが確立され
ており、ネットワーク製品は単にユーザーとアプリケー
ションの間の通路として動作するに過ぎない。ネットワ
ーク製品自体がユーザーと通信する必要がある次の時は
、正常動作であれ異常動作であれ、セツションが完了す
る時である。

対話的セツションを終了するために、セツション終了バ
ケ・ントが上述のセツション開始の場合と同様の様式で
ネットワークを通じて渡される。但し異なるのは、さま
ざまなノードにおけるネットワーク・マネジャ・タスク
がリンケージ及び制御ブロック・セットアツプに関連し
て、手続きが反対であるということである。ユーザー・
ノードに送られつつあるセツション終了パケットがメツ
セージを含む可能性はきわめて大きいが、アプリケーシ
ョン・ノードに送られつつあるパケットは、セツション
が異常終了されつつある時にのみ必要なものであって、
メツセージを含む可能性は小さい。

兆刀１律しＶＬ区且 ここで非対話的状況について考應してみよう。

割り込みハンドラのフローチャート（第２図）を参照す
ると、非対話的ユーザーがコマンドを入力する時、割り
込みハンドラがコマンド・パケットをセットアツプする
。このコマンド・パケットのデータ・フィールドは、ユ
ーザーによって入力されたコマンドを含み、それはコマ
ンド・プロセッサに通知される。

コマンド・プロセッサのフローチャート（第３図）を参
照すると、コマンドがローカル・サイトに入る時（ボッ
クス１）、タスクは最初にユーザーが何らかのコマンド
応答のための言語を示唆しているかどうかを調べるため
にコマンド・テキストをチエツクする（ボックス２）（
コマンド・シンタックスがこのこと及びそのコマンドを
実行すべきノード名の記述を可能ならしめると仮定する
。

さらに、フローチャートには示されていないけれども、
コマンド・シンタックスは、その応答が、このモデルの
下層オペレーティング・システムによって提供されると
予定される特殊機能を介して言語独立的な形式であるよ
うにする、という仕様も用意することができるものであ
る）。

もし言語が記述されているなら（ボックス３）、その設
備がその言語にイネーブルされているかどうかを見出す
ために、サポートされた言語のテーブルでその言語が検
索される（ボックス４．５及び７）。もしそうなら、コ
マンド・パケット中の言語フィールドが、ユーザー指定
言語を識別する番号を含むように変更され、その言語オ
プションがコマンド・テキストから外され、パケットの
長さフィールドがそれに従って変更される（ボックス９
）。

次に、タスクは、コマンド・テキストの宛先オプション
をチエツクする。これは、コマンドを実行すべき宛先を
ユーザーが入力したかどうか、ということである（ボッ
クス９）。もしそうなら、パケット・へ−シダ中のノー
ド宛先フィールドがローカル・ノード名からコマンドに
記述された名前に変更され、コマンド・テキスト及びパ
ケットの長さフィールドが上述のように言語オプション
に対して調節される（ボックス１１及び１２）。この宛
先フィールドは、次にボックス１３でチエツクされ、も
しそのコマンドが遠隔サイトで実行されるべきであるな
らネットワーク・マネジャにそのパケットが通知される
（ボックス１４）。

最後に、遠隔サイトで実行されるべきコマンドが、それ
が有効である限りにおいて実行される（ボックス１５．
１６．１８及び１９）。尚、そのローカル・サイトで発
生しなかったコマンド（ボックス１）が、そのローカル
・サイトで実行される、ということに留意されたい。こ
れは、既にローカル・サイト宛として決定されたコマン
ド・パケットによりネットワーク・マネジャによってコ
マンド・プロセッサが通知された時に、このモデルのネ
ットワーク製品においてこのことのみが起こることにな
る、という理由による。

メツセージ・ハンドラ　１　メツセージの構成び配置） まず最初に非対話的メツセージのモデル化されたメツセ
ージ・ハンドラについて見て、そのようなメツセージの
構成及び配置のために呼び出される時、その入力は次の
ものからなる：　（１）メツセージの番号プラスそのバ
ージョンまたはフォーマット番号 （２）呼び出し側モジュールの名前を識別するキャラク
タ・ストリング （３）渡される置換引数の数 （４）各置換引数毎に、そのアドレス、プラス、数、キ
ャラクタ、タイムスタンプ、またはエンコ−ドされたメ
ツセージなどのそのデータ・タイプを示すフラグ（タイ
ムスタンプ引数は、言語独立的な形式であり、１次メツ
セージにおいて２次メツセージが必要である時にエンコ
ードされたメツセージ引数が仕様されることになる。す
なわち、エンコードされたメツセージ引数は、エンコー
ドされた形式の２次メツセージである）。

（５）もしパケットがコマンド・パケットとして使用さ
れていたなら含むような全ての情報をその見出し部分が
含むバッファ（パケット）のアドレス １次メツセージを処理するためのメツセージ・ハンドラ
のためのフローチャート（第ＬｏｒｌＡ）を参照すると
、メツセージ・ハンドラは最初に、そのメツセージがロ
ーカルまたは遠隔のどちらのユーザーに行くべきかを決
定するために、第５の入力引数のオリジン・フィールド
中のノード名を見る（ボックス１）。そしてもしそのメ
ツセージがローカル・ユーザーへと向かうなら、そのメ
ツセージ・ハンドラは、サポートされた言語テーブル中
でユーザーの言語を突き止めるためにバッファ中の言語
フィールドからの言語番号を使用しくボックス２）、そ
の言語のベース・アドレスを取得する。そうでなければ
、メツセージは、ネットワーク言語のベース・アドレス
を使用する（ボ・ンクス３）。

どちらにしても、メツセージ・ハンドラは、メツセージ
の内部オブジェクト・イメージを突き止め（ボックス４
）、そのメツセージが言語オブジェクト中に定義されて
いることを推定すると（ボックス５）、バッファを獲得
して非対話的メツセージを収めるためにそれをセットア
ツプする（ボックス６）。バッファ・ヘッダをセットア
ツプする際に、メツセージ・ハンドラは、非対話コマン
ドを含むバッファのためにセットアツプされている入力
バッファ中の状態から宛先とオリジン・フィールドを逆
転する。

もし特殊フラグが入力バッファにおいてセットされてい
るなら（ボックス７）、それはメツセージを入れるため
のバッファにおいてもセットされ（ボックス８）、その
メツセージは、エンコードされた形式でそのバッファの
データ領域に構成される（ボックス１４）。そうでない
なら、メツセージは、ボックス２または３で決定された
言語で構成される（ボックス１１）が、またはエンコー
ドされた形式で構成される（ボックス１４）。もしメツ
セージが遠隔ユーザーに向かうなら、メツセージ・ハン
ドラは、入力バッファのフラグ・フィールドにセットさ
れているＮＬＳフラグによって、遠隔サイトがＮＬＳを
サポートしているかどうかを知り（ボックス９）、「エ
ンコード済み」フラグをセットして（ボックス１３）、
遠隔サイトの互換性レベル（バッファ中のＣＬフィール
ド）が少なくとも、そのオブジェクト・イメージで示さ
れたメツセージの互換性レベル程度に高い時のみそのメ
ツセージをエンコードする。

メツセージ・ハンドラは、最終的に、そのメツセージを
含むパケット中の長さフィールドをセットし、メツセー
ジがローカルまたは遠隔のどちらのユーザーに向かって
いるかに応じて（ボックス１　Ｂ）　、ＩＪき込みタス
ク（ボックス１８）またはネットワーク・マネジャ（ボ
ックス１７）のどちらかに通知する。

メツセージ・ハンドラがメツセージを構成（ボックス１
１）またはエンコード（ボックス１４）するとき、メツ
セージ・ハンドラは、パラメータ・リスト中に呼び出し
側によって提供された置換引数を使用する。

書き込みタスク 次に書き込みタスクのフローチャート（第１１図）を参
照すると、そのタスクはまず、パケット中の「エンコー
ド済み」フラグのセ・ントによって示される、到来メツ
セージがエンコードされた形式であるかどうかを調べる
ためのチエツクを行う。そしてもしそれがエンコードさ
れていないなら、タスクは、メツセージ・パケット中の
特殊フラグのセット状態（ボックス３）に応じて、非対
話的ユーザーにメツセージを表示する（ボックス５）か
、このモデルのためにオペレーティング・システムによ
って提供されることが想定されている機能を使用してユ
ーザーが書いたアプリケーションにそのメツセージを送
る（ボックス４）のどちらかを行う。そうでないなら、
タスクは、１次メツセージ・デコーディング・エントリ
・ポイント（ボックス２）で、メツセージ・ハンドラに
対するエンコードされたメツセージを含むパケットを手
放す（ボックス２）。

メツセージ・ハンドラ　１　メツセージ・デコーディン
グ） メツセージ・ハンドラの１次メツセージ・デコーディン
グ・エントリ・ポイントのためのフローチャート（第１
２図）を参照すると、メツセージ・ハンドラに対する唯
一の入力が、エンコードされたメツセージを含むパケッ
トのアドレスである。

というのは、そのパケット自体が知る必要のあるもの以
外の全てを含んでいるからである。メツセージ・ハンド
ラは、単にそのメツセージのオブジェ−クト・イメージ
を検索して、「エンコード済み」フラグがセットされて
いないことを除いては、エンコードされたメツセージを
含むパケットの見出しにその見出しが同一である別のパ
ケットのデータ・フィールド中にそのメツセージを構成
する。

メツセージ・ハンドラは次に、その新しいパケットを書
き込みタスクに送付する。

この場合にメツセージ・ハンドラがそのメツセージを構
成する時、メツセージ・ハンドラは、エンコードされた
メツセージ中に与えられた置換引数を使用する。

メツセージ・ハンドラ　　話的メツセージ）メニュー画
面上に表示されるメツセージは、非対話的ユーザーに表
示されるメツセージよりも簡単である。対話的メツセー
ジのためのこのモデル化されたメツセージ・ハンドラに
対する入力は、次のものからなる。

（１）エンコードされた形式のメツセージ自体（２）メ
ツセージが正しい形式で配置されるべき箇所の「ターゲ
ット」領域のアドレス （３）メツセージがローカルまたは遠隔のどちらのユー
ザーに向かうかの表示 （４）メツセージがローカルまたは遠隔のどちらのユー
ザーに向かうかに応じて、次のうちの１つである引数： （ａ）ローカル・ユーザーの場合の言語番号（ｂ）遠隔
ユーザーの場合の互換性レベルまたはゼロ （５）セツション終了パケットであり得る、バッファの
アドレス モデル化されたメツセージ・ハンドラの出力は、対話的
ユーザーのために呼ばれた時、次のようである。

（１）「データ・ント」領域中の適正な形式のメツセー
ジ （２）入力バッファの長さフィールドに配置されたメッ
セージ長 （３）入力バッファ中のフラグ・フィールドでセットま
たはリセットされている「エンコード済み」フラグ 対話的メツセージ処理のためのフローチャート（第１３
図）を参照すると、メツセージ・ハンドラは、出力「タ
ーゲット」領域をクリアする前に入力引数を抽出する。

それゆえ、「ターゲット」領域は、メツセージ・ハンド
ラに入力引数を渡すために使用されたのと同一の領域で
あり得る（ボックス１）。

ボックス２では、メツセージ・ハンドラが、そのメツセ
ージがローカルまたは遠隔のどちらのユーザーに向かっ
ているのかをチエツクする。ローカル・ユーザーの場合
、メツセージ・ハンドラは第４番目の入力引数が言語番
号であることを知っており、メツセージ・ハンドラは、
サポートされた言語のテーブル中でそのユーザーの言語
を突き止めるためにこれを使用し、ボックス３でそのペ
ース・アドレスを取得する。

しかし、遠隔ユーザーの場合、メツセージ・ハンドラは
、代わりにネットワーク言語のベース・アドレスを使用
する（ボックス４）。このことは、第４番目の入力引数
が互換性レベルとして解釈されるべきであり、それがゼ
ロであることは、その遠隔ノードがＮＬＳをサポートし
ていないことを示すことを物語っている。もしその遠隔
ノードがＮＬＳをサポートしないなら（ボックス５）、
メツセージ・ハンドラは、ボックス１でエンコードされ
たメツセージ引数から取得したメツセージ番号を、ユー
ザーのノードのＮＬＳサポート以前のメニューのメツセ
ージ表示領域にはまり込むことを保証するために、その
メツセージの対応メツセージの番号に変更する（ボック
ス６）。

どの場合にも、メツセージ・ハンドラは次に、適切な言
語のメツセージの内部オブジェクト・イメージを検索す
る（ボックス７）。そのメツセージが言語オブジェクト
中に定義されていると仮定すると（ボックス８）、メツ
セージ・ハンドラは、ベース・アドレスによって示され
ている言語でメツセージを構成する（ボックス８）か、
単にエンコードされたメツセージを「ターゲット」領域
中にコピーして（ボックス１４）、それに従いバッファ
中の・「エンコード済み」フラグをリセットまたはセッ
トする。メツセージ・ハンドラがエンコードされたメツ
セージをその位置にコピーする唯一の時は、そのメツセ
ージが、互換性レベルが少なくともそのメツセージのオ
ブジェクト・イメージによって示されるそのメツセージ
の互換性レベルと同等の高さであるＮＬＳサポート・ノ
ードにいる遠隔ユーザーに向かう時である。

メツセージ セツション開始パケットがノード“Ｇ”にあるネットワ
ーク・マネジャに到達した時、ユーザーによって要求さ
れたアプリケーションが専用でないことが分かったとす
る。ネットワーク・マネジャのフローチャート（第６図
）を参照すると、タスクは、ボックス７でこのことを判
断し、対話的メツセージ処理のためにメツセージ・ハン
ドラを呼び出す準備のためにエンコードされたメツセー
ジをセットアツプする。

ｒＢ、で始まるネットワーク・マネジャのフローチャー
ト（第６図）を参照すると、その互換性レベルのメツセ
ージ引数値は初期的にはゼロであると仮定し、このこと
はオリジンがＮＬＳサポート以前のノードであることを
示唆する。もしユーザーのノードがＮＬＳをサポートす
ることを示唆するようにＮＬＳフラグがセットされてい
るなら（ボックス３）、互換性レベルは、セツション開
始パケット中で示されている互換性レベルに変更される
（ボックス４）。

もしユーザーが遠隔ノードに位置しているなら（ボック
ス５）、エンコードされたメツセージ自体がパケットの
データ領域にコピーされ、その長さがパケットの長さフ
ィールドに配置され、「エンコード済み」フラグがセッ
トされる（ボックス８）。次にそのパケットは、ユーザ
ー・インターフェース・タスクに送られる（ボックス９
）。

しかし、遠隔ユーザーの場合、そのパケットのデータ領
域中に対話的メツセージを構成するためにメツセージ・
ハンドラが呼び出される（ボックス６）。そのパケット
・アドレスは、第５の引数としてメツセージ・ハンドラ
に与えられ、決定される互換性レベル（またはゼロ）は
、第４の引数として与えられる。それゆえ、メツセージ
・ハンドラは、そのメツセージを適切な形式でパケット
のデータ領域中に配置し、「エンコード済み」フラグは
適切にセットまたはリセットされる。そのパケットは次
に、ユーザーのノードに戻る通信を処理するライン・ド
ライバに単に送られる（ボックス７）。

ネットワーク・マネジャ・タスクのおのおのはもちろん
、そのセツションのためにセットアツプされたリンケー
ジ上でクリーンアップ動作を実行し、そのパケットを次
の宛先に転送し、そのパケットは最終的に、対話的ユー
ザーの表示ユニットを扱うユーザー・インターフェース
・タスクに送られることになる。

ここで再度ユーザー・インターフェース・タスクのフロ
ーチャート（第４図）を参照すると、パケットはボック
ス４でセツション終了パケットであると判断され、ボッ
クス２１でメツセージを含むと判断される。もし「エン
コード済み」フラグのセット状態によって示されるよう
に、そのメツセージがエンコードされているなら（ボッ
クス２２）、メツセージ・ハンドラは、ボックス１でク
リアされたメツセージ領域中に対話−的メッセージを構
成するために呼び出される。しかし、このとき、ユーザ
ー制御ブロック中の言語番号は第４番目の引数として使
用され、そのメツセージは、ユーザーが使用中のいかな
る言語においても構成される。

ライン・ドライバ・タスクのフローチャート（第９図）
を参照すると、もし通信ラインが故障であると検出され
たなら（ボックス３または９）、バッファのオリジン・
フィールドは、メツセージ・ハンドラをして１次メツセ
ージをローカル・オペレ°−夕に送らせるべくローカル
・システムに指示するように変更され、メツセージ・ハ
ンドラが、そのメツセージの構成及び配置のために呼び
出される（ボックス１５）。このとき、ユーザー識別子
が変更可能であり、特殊フラグをセットしてもよく、言
語番号さえも変更することができ、メツセージを関連す
る全てのユーザーに送るために必要な回数がどうであれ
メツセージ・ハンドラを再度呼び出すことができる。

次にセツション終了パケットのデータ領域中の対話的メ
ツセージを戻すためにメツセージ・ハンドラを呼び出す
準備のために、エンコード・エラー・メツセージがセッ
トアツプされる（ボックス１６）。タスクは次に、その
特定のライン・ドライバにリンクされた全ての制御ブロ
ックに亙って進み、その各々につきセツション終了パケ
ットを作成し、ユーザー・ノード宛のパケット毎にメツ
セージ・ハンドラを呼びだし、それをネットワーク・マ
ネジャに送る（ボックス１７．１８．１９．２０及び２
１）。

ボックス２０では、メツセージ・ハンドラは、入力引数
のうちの１つからユーザーがローカルまたは遠隔のどち
らであるかを知る。言語番号または互換性レベル（ある
いはゼロ）のうちの１つであるその引数は、そのセツシ
ョンに関連する制御ブロック、すなわちユーザー制御ブ
ロック、中間制御ブロックまたはアブ６リケーシヨン制
御ブロツクのどれかから得られる。

非対話的コマンドを伝送しようと試みる間に、もしライ
ン・ドライバがラインが動作不能であると決定したなら
ば（ボックス６）、ライン・ドライバは、メツセージ・
ハンドラに対する第５の引数としてコマンド・バッファ
自体を使用することによって非対話的ユーザーに１次メ
ツセージを送り戻すためにメツセージ・ハンドラを呼び
出す（ボックス７）。

Ｆ１発明の効果 本発明によれば、ネットワーク製品にＮＬＳサポートを
提供する方法が与えられ、これは、エンド・ユーザーに
システムの単一システム・イメージの外観を与えること
によってエンド・ユーザーのユーザー・フレンドリの程
度を最適化し、言語サポートに関して別の設備からの独
立性を保持することによりやはり設備のユーザー・フレ
ンドリの程度を最適化し、遠隔サイトにいるユーザーに
メツセージ及び画面を通信するためにネットワークを介
して伝送しなくてはならないデータの量を最小にするも
のである。さらに、この方法は、同一のネットワーク中
に、ＮＬＳサポート以前のノードを含む異なる製品リリ
ースの共存を可能ならしめ、また、サービスまたは設備
の変更を通じてリリース間の画面またはメツセージの追
加を可能ならしめる。さらにまた、この方法は、ベンダ
の製品とユーザーが書いたアプリケーションとの間の言
語独立なメツセージ・インターフェースを与える。

【図面の簡単な説明】

第１図は、この発明の好適な実施例のサンプル・ネット
ワーク・パケットを示す図、 第２図は、割り込みハンドラ・モジュールのフローチャ
ートを示す図、 第３図は、コマンド・プロセッサ・タスクのフローチャ
ートを示す図、 第４図は、ユーザー・インターフェース・タスクのフロ
ーチャートを示す図、 第５図、第６図及び第７図は、ネットワーク・マネジャ
・タスクのフローチャートを示す図、第８図は、アプリ
ケーション・インターフェース・タスクのフローチャー
トを示す図、第９図は、ライン・ドライバ・タスクのフ
ローチャートを示す図、 第１０図は、１次メツセージ配置サブルーチンのフロー
チャートを示す図、 第１１図は、書き込みタスクのフローチャートを示す図
、 第１２図は、１次メ・νセージ・デコーディング・サブ
ルーチンのフローチャートを示す図、第１３図は、対話
的メツセージ解決のフローチャートを示す図、 第１４図は、サンプル・ユーザー制御ブロックを示す図
、 第１５図は、サンプル・中間制御ブロックを示す図、 第１６図は、サンプル・アプリケーション制御ブロック
を示す図である。 Ｉ！ＩＩＩ図 サンプル・ネットワーク・パケット 第１４図サンプル・ユーザー制御ブロック出願人　イン
ターナショナル・ビジネス・マシーンズ・コーポレーシ
ョン

Claims (2)

【特許請求の範囲】
1. （１）多重言語ネットワークにおける通信の方法であっ
   て、 （ａ）上記ネットワーク中の各ノードの言語能力を決定
   する段階と、 （ｂ）標準化された、プログラムが可読なフォーマット
   で所与のノードのユーザーにプログラム・メッセージを
   伝送する段階と、 （ｃ）上記メッセージを受信するノードで上記メッセー
   ジをデコードする段階と、 （ｄ）上記ノードがイネーブルされている言語で上記メ
   ッセージを表示する段階を有する、 通信方法。
2. （２）（ａ）システム中の各ノードがイネーブルされて
   いる言語を追従するための記憶手段と、 （ｂ）特定のノード宛のプログラム・メッセージの宛先
   を感知するための感知手段と、 （ｃ）識別子及び制御情報を含み、適当なフォーマット
   のメッセージを伝送するための伝送手段と、（ｄ）上記
   メッセージの性質を決定するための受信手段と、 （ｅ）上記受信したノードにおいて、該受信したノード
   の言語で画面及び上記メッセージを表示するための表示
   手段とを具備する、 ネットワーク・コンピュータ・システム。