JP3860587B2 - マルチプロセッサ装置 - Google Patents

Description

本発明は、アプリケーションプロセスに対して、システムに結合した端末とのデータ送受信機能を提供する疎結合マルチプロセッサシステムにおいて、各プロセッサ内のアプリケーションプロセスからのデータ送受信処理を可能とするマルチプロセッサ装置に関する。

従来の疎結合マルチプロセッサシステムにおいては、システムジェネレーション時に、システムに結合する端末とプロセッサとの関係を定義したテーブルを作成していた。そして、システム始動時に当該テーブルを各プロセッサの主記憶装置にロードし、アプリケーションプロセスが発行した送信システムコール処理時に、前記ロード情報を参照することによりプロセッサを決定していた。そのため、例えばプロセッサの負荷分散の目的などから、端末が結合するプロセッサを動的に変更することはできなかった。

また、端末が結合するプロセッサを動的に変更するように構成された疎結合マルチプロセッサシステムも従来より存在した。但し、この場合、プロセッサに結合した端末との送受信処理が可能なアプリケーションプロセスは、当該プロセッサ上で動作するものに限られていた。

疎結合マルチプロセッサシステムにおける端末利用を実現する上で、端末結合処理の性能とデータ送受信処理の性能とを同時に高めることはできない。したがって、業務の運用に応じたトレードオフが必要となる。問題は、この二者択一をシステムが行うのかユーザが行うのかという点である。

まず、システムが二者択一を行う方法としては、端末の運用定義による方法や、結合時にアプリケーションプロセスがパラメータで指定する方法などがある。しかし、システムプログラムの処理論理が複雑になるという点およびシステムプログラムが２本立てとなり煩雑であるという点で現実的ではない。

他方、ユーザが二者択一する場合、自身の業務の運用に合わせていずれかを選択するだけであるから問題は少ない。以上述べたように、システムがユーザの業務の運用上の要件を満たしつつ端末共用を実現することは困難である。

さらに、端末が結合したプロセッサで障害発生時に、当該端末をバックアッププロセッサに引き継ぎ、なおかつ、各プロセッサから引き継いだ端末を共用できる機能は従来存在しなかった。

なお、従来から、動的にネットワークアドレスを変換する技術や（特許文献１参照）、端末からの入力電文をどのように複数ホストに振り分けるかという課題を解決しようとする技術（特許文献２参照）などがある。
特開平０３−２５４５４０号公報 特開平０２−０２８８６６号公報

しかしながら、疎結合マルチプロセッサシステムにおいて、端末がシステムと結合する場合、結合するプロセッサの決定論理は、ジェネレーション時に定義する手法や、運用時
の各プロセッサの負荷状況に応じて選択する手法など、複数の手法を組み合わせて利用できることが、業務設計の柔軟性を向上させる上で望ましい。

同じく、業務設計の柔軟性の向上の観点からいって、システムに結合した端末を、システムを構成する各プロセッサ内のアプリケーションプロセスから共用できるようにすることが望ましい。

さらに、フォルトトレラントコンピュータとして疎結合マルチプロセッサシステムを利用する場合、結合端末を障害プロセッサからバックアッププロセッサに引き継ぐ前と後で、アプリケーションプロセスが実行する送受信システムコールのインタフェースが不変であることが望ましい。

しかし、従来のマルチプロセッサシステムで、上述の要件を全て満足するものは存在しなかった。そこで、本発明の目的は、各プロセッサ内のアプリケーションプロセスからデータ送受信処理を行うことができるとともに、端末を結合するプロセッサを動的に変更可能として、前記各プロセッサ内のアプリケーションプロセスから端末を共用することができ、常時運用を可能として、ネットワーク装置における宛先管理、故障対処および業務処理に好適に使用することができるマルチプロセッサ装置を提供することにある。

本発明は、上記目的を達成するために、アプリケーションプロセス部、通信処理サーバプロセス部、および通信アクセス法プロセス部を有するマルチプロセッサが入出力バスに複数個並列的に結合される疎結合マルチプロセッサシステムにおいて、前記通信処理サーバプロセス部が、前記アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定される、プロセッサ識別信号とプロセッサ内に記憶される端末管理テーブルにおける配列番号とを含むマルチプロセッサシステム内で一意的な、通信識別子からプロセッサ識別番号を取り出すとともに、該プロセッサ識別番号により決定されるプロセッサに対して、当該プロセッサ内の通信処理サーバプロセスで端末への送信処理を実行させるべく送信データを回送するようにすることにより、各プロセッサ内のアプリケーションプロセスからデータ送受信処理を行うことができるとともに、端末を結合するプロセッサを動的に変更可能として、前記各プロセッサ内のアプリケーションプロセスから端末を共用することができ、常時運用を可能とするマルチプロセッサ装置とした。

図２は、本発明によるマルチプロセッサシステムの原理構成を示している。図２に示すシステムは、端末１Ａ、１Ｂ、１Ｃおよび１Ｄと、疎結合マルチプロセッサシステム６とで構成されている。疎結合マルチプロセッサシステム６は、プロセッサ９Ａ、９Ｂおよび９Ｃを有し、これら各プロセッサ９Ａ、９Ｂ、９Ｃは、それぞれ、アプリケーションプロセス実行部、通信処理サーバプロセス実行部、および通信アクセス法プロセス実行部を有する。前記端末１Ａ、１Ｂ、１Ｃおよび１Ｄは、交換網２を介してプロセッサ９Ａ、９Ｂおよび９Ｃに接続されている。

前記通信処理サーバプロセス実行部は、アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定される通信識別子からプロセッサ識別番号を取り出すとともに、該プロセッサ識別番号により決定されるプロセッサに対して、当該プロセッサ内の通信処理サーバプロセスで端末への送信処理を実行させるべく送信データを回送する。前記通信識別子は、プロセッサ識別信号とプロセッサ内に記憶される端末管理テーブルにおける配列番号とを含んでマルチプロセッサシステム内で一意的に定義される。

通信処理サーバプロセス実行部は、通信識別子採番部、通信識別子通知部およびプロセッサ識別番号取得部を具備していてもよい。前記通信識別子採番部は、端末のプロセッサとの結合時に、プロセッサ識別信号とプロセッサ内の端末管理テーブルにおける配列番号とを組み合わせて得られるマルチプロセッサシステム内での一意的な番号を通信識別子として採番する。前記通信識別子通知部は、アプリケーションプロセスに対して、端末結合の処理結果の通知時に、通信識別子を通知する。前記プロセッサ識別番号取得部は、アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定された通信識別子からプロセッサ識別番号を取り出す。

また、前記疎結合マルチプロセッサシステム６は、１個のプロセッサに待機属性を、残りのプロセッサに現用属性を付与し、待機プロセッサは現用プロセッサの障害時にバックアップ用として動作するようにし、各プロセッサには所定の論理プロセッサ名を付与し、待機プロセッサが障害現用プロセッサをバックアップする際に現用プロセッサの論理プロセッサ名を引き継ぐとともに、プロセッサ識別番号として論理プロセッサ名リストの配列番号を割り当てることにより、待機プロセッサが現用プロセッサに結合していた端末を引き継いだ後でも、端末と通信識別子との関係を不変とするようにしてもよい。

さらに、このようなマルチプロセッサ装置を、以下に述べるネットワーク装置におけるフロントエンドプロセッサシステム（以下、「ＦＥＰシステム」と称する）として用いてもよい。具体的には、ネットワークを介して１個以上のホストプロセッサ（以下、「ホスト」と称する）に結合され且つ交換網経由で複数個の端末に接続されるＦＥＰシステムを設け、該ＦＥＰシステムにより、前記端末からのダイアリングに対し当該端末を接続するホストプロセッサおよびそのホストプロセッサ内のネットワークノードの管理および接続の実行、前記通信処理アプリケーション実行手段により実行される通信処理アプリケーションによる指定された端末に対応して接続宛先名として登録されているネットワークノードの参照、および該通信処理アプリケーションによる指定端末の接続宛先名の変更更新を行って、通信処理アプリケーションおよび通信アクセス法の処理を実行することにより、端末からダイアリングした際に、前記端末が接続される交換網とホストが結合されるネットワークとの間で、システムの運用状況に応じて、柔軟に且つ適切に宛先管理、故障対処および業務処理を行うことが可能なネットワーク装置である。

図１は、上記のようなネットワークシステムの原理構成を示している。図１に示すシステムは、端末１Ａ、１Ｂ、交換網２、ＦＥＰシステム３、回線／ネットワーク４およびホスト５を有している。

端末１Ａおよび１Ｂは、ユーザすなわちオペレータにより操作される複数の端末であり、この図１では、２個の端末１Ａおよび１Ｂが図示されている。交換網２は、複数の端末１Ａおよび１ＢをＦＥＰシステム３に接続する。

ＦＥＰシステム３は、回線／ネットワーク４を介してホスト５に結合されている。図１では、１個のホスト５のみが示されているが、ホスト５は複数個設けられていてもよい。
ホスト５は、通信処理アプリケーションを実行するための通信処理アプリケーション実行部５１、通信処理サーバを実行するための通信処理サーバ部５２および通信アクセス法の処理を実行するための通信アクセス法処理部５３を有している。通常、ＦＥＰシステム３の通信処理アプリケーション実行部３１は、そのパフォーマンスについてはホスト５の通信処理アプリケーション実行部５１よりも小規模でよい。

ＦＥＰシステム３も、通信処理アプリケーションを実行するための通信処理アプリケーション実行部３１、通信処理サーバを実行するための通信処理サーバ部３２および通信アクセス法の処理を実行するための通信アクセス法処理部３３を有している。通常、ＦＥＰ
システム３の通信処理アプリケーション実行部３１は、パフォーマンスについてはホスト５の通信処理アプリケーション実行部５１よりも小規模でよい。

ＦＥＰシステム３は、前記端末１Ａ、１Ｂからのダイアリングに対し当該端末を接続するプロセッサおよびネットワークノードの管理および接続の実行、前記通信処理アプリケーション実行部３１により実行される通信処理アプリケーションによる指定された端末に対応して接続宛先名として登録されているネットワークノードの参照、および該通信処理アプリケーションによる指定端末の接続宛先名の変更更新を行うことができる。

なお、ＦＥＰシステム３は、接続ノード管理部、宛先名参照部、宛先名変更部、接続処理実行部および運用情報取得部を有していてもよい。この場合、典型的には、前記宛先名参照部、宛先名変更部および運用情報取得部は、通信処理アプリケーション実行部３１に設けられ、前記接続ノード管理部および接続処理実行部は、通信アクセス法処理部３３に設けられる。そして、通信処理アプリケーション実行部３１と通信アクセス法処理部３３とは、通信処理サーバ部３２を介して結合される。

前記接続ノード管理部は、端末単位に、当該端末をどのプロセッサの、どのネットワークノードに接続するかを示すノード管理テーブルを保持し、前記端末からＦＥＰシステムにダイアリングした際に、当該端末をどのプロセッサの、どのネットワークノードに接続するかを管理する。

前記宛先名参照部は、ＦＥＰシステム内で動作する通信処理アプリケーションが、端末名を指定して宛先名参照のシステムコールを発生した際に、前記ノード管理テーブルにおいて指定端末の接続宛先名として登録されているネットワークノード名を前記通信処理アプリケーションに通知する。

前記宛先名変更部は、前記通信処理アプリケーションが、端末名とネットワークノード名を指定して宛先名変更のシステムコールを発生した際に、前記ノード管理テーブルにおける指定端末の接続宛先名を、指定ネットワークノード名に更新する。

前記接続処理実行部は、端末からＦＥＰシステムにダイアリングした際に、前記接続ノード管理テーブルを参照して接続ネットワークノードを決定し当該ノードに接続要求を伝達する。

前記運用情報取得部は、前記通信処理アプリケーションが、端末の接続宛先名を変更するために利用する運用情報を取得する。さらに、前記運用情報取得部は、ホストの運用スケジュールを参照し、且つ前記接続ノード管理部は、該当ホストの前記運用スケジュールに基づき、ホスト稼働時には端末の接続ノードを該当ホスト内のネットワークノードとし、ホスト停止時には前記該当ホストを代行し得る他のホスト内のネットワークノードとして宛先を変更するようにしてもよい。

また、前記運用情報取得部は、ホストの運用スケジュールを参照し、且つ前記接続ノード管理部は、該当ホストの前記運用スケジュールに基づき、ホスト稼働時には端末の接続ノードを該当ホスト内のネットワークノードとし、ホスト停止時にはそのＦＥＰシステム内で実行される通信処理アプリケーションを前記端末に接続されるネットワークノードとして宛先を変更するようにしてもよい。

前記運用情報取得部は、そのＦＥＰシステム内で動作する通信処理アプリケーションが、ホスト内で動作する通信処理アプリケーションと相互に通信を行うことにより運用スケジュールを決定するようにしてもよい。

本発明によるマルチプロセッサシステム６では、通信処理サーバプロセスにより、端末結合時に、プロセッサ識別番号と端末管理テーブル内の配列番号の２つの情報を組み合わせたものとして構造化した通信識別子を動的に割り当て、当該マルチプロセッサシステム内で一意的に定義されるこの通信識別子をアプリケーションプロセスに通知し、該アプリケーションプロセスによる結合端末に対する送信システムコール時に、結合端末毎に対応して指定した通信識別子に基づいてプロセッサを決定し、当該プロセッサに送信データを回送することにより、送信処理を実行するので、プロセッサで異常が発生し、端末をバックアッププロセッサに引き継いだ際にも、送信システムコールのインタフェースの普遍性が保証される。

また、上記のようなネットワークシステムでは、通信処理アプリケーションを組み込んだＦＥＰシステム３を１組または複数個のホスト５に結合するとともに、業務実行時に、端末１Ａ、１Ｂからネットワーク内のノードへの接続をする場合、常にＦＥＰシステム３にダイアリングするだけで、ＦＥＰシステム３からその時点で有効なネットワークノードに対して接続要求を振り分け、端末１Ａ、１Ｂを有効なノードに接続する。このようなネットワークシステムによれば、通信処理アプリケーションを組み込んだＦＥＰシステムを１組または複数個のホストに結合するとともに、業務実行時に、複数個の端末からネットワーク内のノードへの接続をする場合、常にＦＥＰシステムにダイアリングするだけで、ＦＥＰシステムからその時点で有効なネットワークノードに対して接続要求を振り分け、端末を有効なノードに接続するようにして、端末からダイアリングした際に、前記端末が接続される交換網とホストプロセッサが結合されるネットワークとの間で、システムの運用状況に応じて、柔軟に且つ適切に宛先管理、故障対処および業務処理を行うことを可能とするネットワーク装置を提供することができる。

本発明によれば、通信処理サーバプロセスにより、端末結合時に、プロセッサ識別番号と端末管理テーブル内の配列番号の２つの情報を組み合わせたものとして構造化した通信識別子を動的に割り当て、当該マルチプロセッサシステム内で一意的に定義されるこの通信識別子をアプリケーションプロセスに通知し、該アプリケーションプロセスによる結合端末に対する送信システムコール時に、結合端末毎に対応して指定した通信識別子に基づいてプロセッサを決定し、当該プロセッサに送信データを回送するようにして、各プロセッサ内のアプリケーションプロセスからデータ送受信処理を行うことができるとともに、端末を結合するプロセッサを動的に変更可能として、前記各プロセッサ内のアプリケーションプロセスから端末を共用することができ、常時運用を可能として、前記ネットワーク装置における宛先管理、故障対処および業務処理に好適に使用することができるマルチプロセッサ装置を提供することができる。

《実施例１》
ネットワーク装置の具体的な実施例として、第１の実施例によるネットワーク装置について図面を参照して説明する。

図３は、第１の実施例によるネットワーク装置の構成を示している。図３のネットワーク装置は、端末１Ａ、１Ｂ…、交換網２、ＦＥＰシステム３、回線／ネットワーク４、ホスト５Ａ…を有している。

端末１Ａ、１Ｂ…は、交換網２を介してＦＥＰシステム３に接続される。ＦＥＰシステム３は、高速ＬＡＮ（ローカルエリアネットワーク）回線またはネットワーク回線により構成される回線／ネットワーク４を介して１個以上のホスト５Ａ…に結合されている。

ホスト５Ａ…は、各々通信処理アプリケーションを実行するための通信処理アプリケーション実行部５１、通信処理サーバ処理を実行するための通信処理サーバ部５２および通信アクセス法の処理を実行するための通信アクセス法処理部５３を有している。

ＦＥＰシステム３も、通信処理アプリケーションを実行するための通信処理アプリケーション実行部３１、通信処理サーバ処理を実行するための通信処理サーバ部３２および通信アクセス法の処理を実行するための通信アクセス法処理部３３を有している。通常、ＦＥＰシステム３の通信処理アプリケーション実行部３１は、パフォーマンスについてはホスト５の通信処理アプリケーション実行部５１よりも小規模でよい。

通信アクセス法処理部３３は、ノード管理テーブル３４を保持している。ノード管理テーブル３４は、端末毎に、端末名、端末ネットワークアドレス、定義指定ノード名（とその有効フラグ）、およびアプリケーション指定ノード名（とその有効フラグ）が登録される。

ＦＥＰシステム３は、前記端末１Ａ、１Ｂ…からのダイアリングに対し当該端末を接続するプロセッサおよびネットワークノードの管理および接続の実行、前記通信処理アプリケーション実行部３１により実行される通信処理アプリケーションによる指定された端末に対応して接続宛先名として登録されているネットワークノードの参照、および該通信処理アプリケーションによる指定端末の接続宛先名の変更更新を行うことができる。

この図３の実施例におけるＦＥＰシステム３及びその周辺部分を、図４にさらに詳細に示す。図４においては、ホスト５Ａ、５Ｂ、および端末１Ａ、１Ｂ、１Ｃが示されている。

図４に示すように、ＦＥＰシステム３の通信処理アプリケーション実行部３１は、運用情報取得部３５、宛先ノード名参照部３６および宛先ノード名変更部３７を有しており、ＦＥＰシステム３の通信アクセス法処理部３３は、ノード管理テーブル３４を保持するとともに、接続ノード管理部３８および接続処理実行部３９を有している。

運用情報取得部３５は、前記通信処理アプリケーションが、端末１Ａ…の接続宛先名を変更するために利用する運用情報（各ホストの運用スケジュール）を取得する。このとき、運用情報取得部３５は、ホスト５Ａ…の運用スケジュールを参照することで取得しても良いし、そのＦＥＰシステム内で動作する通信処理アプリケーションがホスト内で動作する通信処理アプリケーションと相互に通信を行うことにより運用スケジュールを決定し取得しても良い。宛先ノード名参照部３６は、ＦＥＰシステム３内で動作する通信処理アプリケーションが、端末名を指定して宛先名参照のシステムコールを発生した際に、ノード管理テーブル３４において指定端末の接続宛先名として登録されているネットワークノード名を前記通信処理アプリケーションに通知する。

宛先ノード名変更部３７は、前記通信処理アプリケーションが、端末名とネットワークノード名を指定して宛先名変更のシステムコールを発生した際に、ノード管理テーブル３４における指定端末の接続宛先名を、指定ネットワークノード名に更新する。

接続ノード管理部３８は、端末単位に、当該端末をどのプロセッサの、どのネットワークノードに接続するかを示すノード管理テーブル３４を用い、前記端末１Ａ…からＦＥＰシステム３にダイアリングした際に、当該端末をどのプロセッサの、どのネットワークノードに接続するかを管理する。

接続処理実行部３９は、端末１Ａ…からＦＥＰシステム３にダイアリングした際に、ノード管理テーブル３４を参照して接続ネットワークノードを決定し当該ノードに接続要求を伝達する。

なお、前記運用情報取得部３５は、ホスト５Ａ…の運用スケジュールを参照し、且つ前記接続ノード管理部３８は、該当ホスト５Ａ…の前記運用スケジュールに基づき、ホスト稼働時には端末の接続ノードを該当ホスト５Ａ…内のネットワークノードとし、ホスト停止時には前記該当ホスト５Ａ…を代行し得る他のホスト内のネットワークノードとして宛先を変更するようにしてもよい。

また、前記運用情報取得部３５は、ホスト５Ａ…の運用スケジュールを参照し、且つ前記接続ノード管理部３８は、該当ホスト５Ａ…の前記運用スケジュールに基づき、ホスト稼働時には端末の接続ノードを該当ホスト５Ａ…内のネットワークノードとし、ホスト停止時にはそのＦＥＰシステム３内で実行される通信処理アプリケーションを前記端末に接続されるネットワークノードとして宛先を変更するようにしてもよい。

さらに、前記運用情報取得部３５は、そのＦＥＰシステム内で動作する通信処理アプリケーションが、ホスト内で動作する通信処理アプリケーションと相互に通信を行うことにより運用スケジュールを決定するようにしてもよい。

図３および図４において、先に述べたように、ホスト５Ａ…とＦＥＰシステム３は、例えば高速ＬＡＮ回線からなる回線／ネットワーク４で接続されている。端末１Ａ…は、ＦＥＰシステム３と交換網２経由で接続され、ホスト５Ａ…に例えばファイル転送を行う。

また、ＦＥＰシステム３の通信処理アプリケーション実行部３１で実行される通信処理アプリケーションは、ホスト５Ａ…で実行される通信処理アプリケーションとの間で通信して、ホストマシンの稼働状況を取得する。

ＦＥＰシステム３内で動作する通信アクセス法処理部３３は、端末単位で接続ノード名を記述したネットワーク定義を展開し、ノード管理テーブル３４としてＦＥＰシステム３の主記憶域内に保持する。このノード管理テーブル３４には、ネットワーク定義で指定されたノード名と通信処理アプリケーションが指定するノード名との２つの宛先を管理する。通信処理アプリケーションがノード名の変更要求を出していない場合、端末１Ａ…からのダイアリング時には、ノード管理テーブル３４に格納されたネットワーク定義で指定されたノードに振り分けられる。

これに対して、通信処理アプリケーションがノード名の変更要求を発行している場合には、この名前をノード管理テーブル３４内の、通信処理アプリケーション指定欄に反映しておく。そして、端末１Ａ…からのダイアリング時には、ノード管理テーブル３４内に通信処理アプリケーションが指定した名前が格納されていることから、これを優先的に採用して当該ノードに振り分ける。

ＦＥＰシステム３内の通信処理アプリケーションは、ホスト５Ａ…が停止する前に、宛先ノード名を当該ＦＥＰシステム３自体に変更しておく。そして、ホスト５Ａ…が稼働状態となったのを契機に、宛先ノード名をホスト５Ａ…内のノードに変更する。

ＦＥＰシステム３内の通信処理アプリケーションは、宛先ノードが当該ＦＥＰシステム３自体となっている場合、端末１Ａ…から転送されるファイルを一時的に蓄積しておく。そして、ホストマシンが稼働状態となり、転送指示を受けたときに、一括してホスト５Ａ…に転送する。

なお、宛先ノードが当該ＦＥＰシステム３自体となっている場合に、ＦＥＰシステム３内の通信処理アプリケーションが、端末１Ａ…から転送されるデータを、ホストに代わって処理することが可能であれば、端末１Ａ…から転送されるファイルをホストマシンに代わって処理するようにしてもよい。

図３に示す経路Ｐ１は、稼働状態を判断するための相互の通信を、経路Ｐ２は、稼働状況の変化に応じて発行される宛先切換え指示が端末管理テーブルに反映される様子を、そして経路Ｐ３およびＰ４は、接続時に端末管理テーブルを参照して、実際に有効な宛先に接続される様子をそれぞれ示している。

図５、図６、図７、図８および図９は、接続ノード管理部３８、宛先ノード名参照部３６、宛先ノード名変更部３７、接続処理実行部３９および運用情報取得部３５のそれぞれの動作を詳細に示すフローチャートである。

図５に示す接続ノード管理部３８の処理は次のように行われる。処理が開始されると、ＩＰＬ（イニシャルプログラムローダ）処理を行うか否かが判定され（ステップＳ１１）、「真」である場合には、システムファイルから交換端末定義情報を読み出す（ステップＳ１２）。次に、交換端末定義情報のシンタクスチェックおよびセマンティック等の定義チェック処理が行われ（ステップＳ１３）、このチェック処理の結果が判定されて（ステップＳ１４）、「真」である場合には、ＦＥＰシステム３の主記憶域に交換端末数分のノード管理テーブル領域が獲得され、先に読み出された定義情報が反映されて（ステップＳ１５）、処理が終了する。

ステップＳ１１で、「偽」であると判定されたときは、宛先ノード名の参照または変更依頼であるか否かが判定され（ステップＳ１６）、「真」であると判定されたときは、依頼端末名をキーとしてノード管理テーブル３４の検索が行われる（ステップＳ１７）。次に、検索が成功したか否かが判定され（ステップＳ１８）、「真」であれば、参照依頼か否かが判定される（ステップＳ１９）。ステップＳ１９で「真」であると判定された場合には、アプリケーション指定ノードが有効であるか否かが判定され（ステップＳ２０）、「真」であると判定された場合には、アプリケーション指定ノード名を出力情報領域に格納して（ステップＳ２１）、処理を終了する。

ステップＳ２０で、「偽」であると判定された場合には、定義指定ノード名を出力情報領域に格納して（ステップＳ２２）、処理を終了する。ステップＳ１９で、「偽」、すなわち変更依頼であると判定された場合には、変更ノード名はバイナリでゼロであるか否かが判定され（ステップＳ２３）、「真」であれば、さらに指定ノード名は有効であるか否かが判定される（ステップＳ２４）。ステップＳ２４で、「真」であると判定された場合には、ノード管理テーブルのアプリケーション指定有効フラグをオンとし（ステップＳ２５）、さらにアプリケーション指定ノード名をノード管理テーブル３４に格納して（ステップＳ２６）、処理を終了する。

ステップＳ２３で「偽」であると判定されたときは、ノード管理テーブル３４のアプリケーション指定有効フラグをオフとして（ステップＳ２７）、処理を終了する。
ステップＳ１４、Ｓ１６、Ｓ１８およびＳ２４で、「偽」と判定された場合はエラーであるので、復帰値を異常として（ステップＳ２８）、処理を終了する。図６に示す宛先ノード名参照部３６の処理は次のように行われる。

処理が開始されると、接続ノード管理部３８に宛先ノード名の参照を依頼し（ステップＳ３１）、正常復帰か否かが判定され（ステップＳ３２）、「真」であれば、出力ノード
名を通信処理アプリケーションに通知して（ステップＳ３３）、処理を終了する。ステップＳ３２において、「偽」であると判定された場合には、異常復帰の詳細なコードを付加してアプリケーションに異常終了を通知し（ステップＳ３４）、処理を終了する。

図７に示す宛先ノード名変更部３７の処理は次のように行われる。処理が開始されると、接続ノード管理部３８に宛先ノード名の変更を依頼し（ステップＳ４１）、正常復帰か否かが判定され（ステップＳ４２）、「真」であれば、通信処理アプリケーションに正常終了を通知して（ステップＳ４３）、処理を終了する。ステップＳ４２において、「偽」であると判定された場合には、異常復帰の詳細なコードを付加してアプリケーションに異常終了を通知し（ステップＳ４４）、処理を終了する。

図８に示す接続処理実行部３９の処理は次のように行われる。処理が開始されると、ダイアリング受付時の端末のアドレスをキーとしてノード管理テーブルの検索を行い（ステップＳ５１）、アプリケーション指定ノードは有効か否かが判定され（ステップＳ５２）、「真」であれば、指定ノード名からアドレスを求めて、当該ノードに接続要求を通知して（ステップＳ５３）、処理を終了する。ステップＳ５２において、「偽」であると判定された場合には、定義ノード名からアドレスを求めて当該ノードに接続要求を通知し（ステップＳ５４）、処理を終了する。

図９に示す運用情報取得部３５の処理は次のように行われる。処理が開始されると、接続ノード変更契機か否かが判定され（ステップＳ６１）、「真」であれば、運用情報から接続ノード名を取得する（ステップＳ６２）。さらに、宛先ノード名変更部３７により接続先ノード名を取得し（ステップＳ６３）、変更処理が正常に完了したか否かが判定され（ステップＳ６４）、「真」であれば処理を終了する。ステップＳ６４で、「偽」と判定された場合には、異常処理が行われて（ステップＳ６５）、処理を終了する。ステップＳ６１で、「偽」であると判定された場合には、そのまま処理を終了する。

従来のネットワーク装置においては、交換網経由の端末からダイアリングを行ってネットワーク内のノードと接続する場合、端末の結合宛先が、定義により固定的に決められているか、または、次のいずれかの方法を用いて端末の結合宛先を切替えるかしていた。（ａ）端末オペレータが、運用スケジュールを意識して、ネットワーク内の所定の結合ノードに対してダイアリングする。（ｂ）端末の内部に、所定の運用スケジュールに基づいて接続する宛先を切替えてダイアリングするようなプログラムを組み込むことによって、宛先を動的に切替える。

交換網経由で接続された端末からダイアリングして、接続ノードを切り替える業務の運用においては、前記（ａ）の方法では、端末オペレータが、運用スケジュールを意識してダイアリングする必要があった。このような方法では、運用スケジュールが複雑になった場合、端末オペレータの負担が重くなるという欠点があった。

また、前記（ｂ）の方法では、端末内に宛先切り替え用のプログラムを組み込む必要があった。この場合、業務の運用で使用する全ての交換網経由の端末内に、宛先切り替え用のプログラムを組み込まなければならないため、運用スケジュールの変更・変化に対処する場合、コストがかさむという弊害があった。

《実施例２》
次に、マルチプロセッサ装置の具体的な実施例として、第２の実施例によるマルチプロセッサ装置について図面を参照して説明する。

〈システム構成〉
図１０は、第２の実施例によるマルチプロセッサ装置の構成を示している。
図１０のマルチプロセッサ装置は、端末１Ａ、１Ｂ、１Ｃおよび１Ｄと、疎結合マルチプロセッサシステム６とで構成されている。疎結合マルチプロセッサシステム６は、回線アダプタ７Ａ、７Ｂ、ＩＯ（入出力）バス８およびプロセッサ９Ａ、９Ｂ、９Ｃを有する。

回線アダプタ７Ａは、端末１Ａおよび１Ｂに接続され、回線アダプタ７Ｂは、端末１Ｃおよび１Ｄに接続される。これら回線アダプタ７Ａおよび７Ｂは、ＩＯバス８に接続され、ＩＯバス８には、プロセッサ９Ａ、９Ｂおよび９Ｃが接続される。

各プロセッサ９Ａ、９Ｂ、９Ｃは、それぞれ、アプリケーションプロセス実行部９１Ａ、９１Ｂ、９１Ｃ、通信処理サーバプロセス実行部９２Ａ、９２Ｂ、９２Ｃ、および通信アクセス法プロセス実行部９３Ａ、９３Ｂ、９３Ｃを有する。前記通信処理サーバプロセス実行部９２Ａ、９２Ｂ、９２Ｃは、アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定される通信識別子からプロセッサ識別番号を取り出すとともに、該プロセッサ識別番号により決定されるプロセッサに対して、当該プロセッサ内の通信処理サーバプロセスで端末への送信処理を実行させるべく送信データを回送する。前記通信識別子は、プロセッサ識別信号とプロセッサ内に記憶される端末管理テーブルにおける配列番号とを含み、マルチプロセッサシステム内で一意的に定義される。

通信処理サーバプロセス実行部９２Ａ、９２Ｂ、９２Ｃは、それぞれ、通信識別子採番部９４Ａ、９４Ｂ、９４Ｃ、通信識別子通知部９５Ａ、９５Ｂ、９５Ｃおよびプロセッサ識別番号取得部９６Ａ、９６Ｂ、９６Ｃを具備している。

通信識別子採番部９４Ａ、９４Ｂ、９４Ｃは、端末のプロセッサとの結合時に、プロセッサ識別信号とプロセッサ内の端末管理テーブルにおける配列番号とを組み合わせて得られるマルチプロセッサシステム内での一意的な番号を通信識別子として採番する。

通信識別子通知部９５Ａ、９５Ｂ、９５Ｃは、アプリケーションプロセスに対して、端末結合の処理結果の通知時に、通信識別子を通知する。プロセッサ識別番号取得部９６Ａ、９６Ｂ、９６Ｃは、アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定された通信識別子からプロセッサ識別番号を取り出す。

ＩＯバス８は、プロセッサ９Ａ〜９Ｃと回線アダプタ７Ａ、７Ｂとの間のデータの入出力で使用される。すなわち、図１０に示しているのは、複数のプロセッサ９Ａ、９Ｂ、９Ｃと（ＬＡＮ）回線アダプタ７Ａ、７ＢとをＩＯバス８で疎結合したマルチプロセッサシステム６である。回線アダプタ７Ａ、７Ｂには、任意のプロセッサ９Ａ、９Ｂ、９Ｃからアクセスすることができる。

さらに、各プロセッサ９Ａ、９Ｂ、９Ｃ上に、アプリケーションプロセス実行部９１Ａ、９１Ｂ、９１Ｃ、通信サーバプロセス実行部９２Ａ、９２Ｂ、９２Ｃおよび通信アクセス法プロセス実行部９３Ａ、９３Ｂ、９３Ｃがそれぞれ各対応して設けられる。各アプリケーションプロセスが発生する送受信システムコールは、当該プロセッサ上の通信処理サーバプロセスが受け付ける。そして、端末が結合しているプロセッサの位置に応じて、そのプロセッサ自身が通信アクセス法プロセスを使用して処理するのか、他のプロセッサ上の通信処理サーバプロセスに処理を依頼するのかを決定して分岐処理を行う。

図１０に破線で示すコネクションＰＡ、ＰＣおよびＰＤは、論理的な結合関係の例を示
し、このような結合関係は、コネクション、セッションまたは通信パス等と称される。これらコネクションＰＡ、ＰＣおよびＰＤによる各端末１Ａ〜１Ｄと各プロセッサ９Ａ〜９Ｃとの論理的な結合関係は、端末１Ａはプロセッサ９Ａに結合され、端末１Ｂはシステムと未結合であり、端末１Ｃはプロセッサ９Ｃに結合され、端末１Ｄはプロセッサ９Ａに結合されている。

データフローＦ１は、端末１Ａがプロセッサ９Ａと結合した場合の結合時のデータの流れを示し、データフローＦ２は、プロセッサ９Ｂ内のアプリケーションプロセスが、端末１Ｃに対してデータ送信システムコールを実行したときのデータの流れを示す。各プロセッサ９Ａ、９Ｂおよび９Ｃの論理プロセッサ名はそれぞれＰＭ０１、ＰＭ０２およびＰＭ０３とする。

〈通信識別子の採番〉
通信識別子の採番は、図１１および図１２に、発呼による端末結合時のデータフローおよび着呼による端末結合時のデータフローをそれぞれ示すように、アプリケーションプロセスからの発呼要求または端末からアプリケーションプロセスへの着呼通知を契機とした端末結合処理において実行される。

図１３に通信識別子の採番処理のフローチャートを示す。通信処理サーバプロセスは、通信アクセス法プロセスに結合処理を依頼する前に、自プロセッサ内の端末管理テーブルリストから空きエントリを検索する（ステップＳ７１）。そして、検索が成功したか否かが判定され（ステップＳ７２）、「真」であれば、検索されたエントリの配列番号が取得され（ステップＳ７３）、当該エントリの配列番号と論理プロセッサ名リスト内の自プロセッサの配列番号とを組み合わせた番号を通信識別子として採番した後（ステップＳ７４）、端末管理テーブルに格納して（ステップＳ７５）、処理を終了する。

ステップＳ７２において、「偽」と判定された場合、すなわち端末管理テーブルリストに空きエントリがない場合は、端末管理テーブルリストを拡張し、拡張部の先頭エントリを取得して（ステップＳ７６）、ステップＳ７４の処理を行う。

このようにして採番された通信識別子は、図１１および図１２に示されるように、通信アクセス法に結合依頼する際に、利用者要求識別子として指定される。
〈通信識別子の通知〉
図１１および図１２に示されるように、通前記結合処理の結果は、通信アクセス法プロセスから通信処理サーバプロセスに対して、結合依頼とは非同期に通知される。さらに、通信処理サーバプロセスは、通信識別子と共に結合処理結果をアプリケーションプロセスに通知する。

図１４に通信識別子の通知処理のフローチャートを示す。通信処理サーバプロセスは、このとき処理結果に付加して通知される通信識別子をキーとして、端末管理テーブルを検索することにより、結合に成功したか否かを判定する（ステップＳ８１）。そして、ステップＳ８１の判定結果が「真」、すなわち結合結果が正常の場合、処理結果データ内通信識別子に、端末管理テーブル内の通信識別子を格納して（ステップＳ８２）、アプリケーションプロセスに、通信識別子とともに処理結果データを通知することにより（ステップＳ８３）、処理が正常に完了したことを通知して処理を終了する。ステップＳ８１で、「偽」と判定された場合、すなわち異常の場合、処理結果データ内通信識別子を無効化するため、端末管理テーブル内の通信識別子をゼロクリアし（ステップＳ８４）、端末管理テーブルをリストから削除して（ステップＳ８５）、アプリケーションプロセスに、エラーの原因を付加して処理結果データを通知することにより（ステップＳ８３）、処理が異常終了したことを通知して処理を終了する。

〈プロセッサ識別番号の取得〉
図１５にデータ送信時のデータフローを示すように、アプリケーションプロセスは、送信システムコール実行時に、結合端末に対応する通信識別子を指定し、論理プロセッサ識別番号を取得する。

図１６に論理プロセッサ識別番号の取得処理のフローチャートを示す。当該送信要求を受け付けた通信処理サーバプロセスは、指定された通信識別子のプロセッサ識別番号の有効性をチェックする（ステップＳ９１）。そして、ステップＳ９１が「真」、すなわち通信識別子の論理プロセッサ識別番号が正常である時は、通信識別子内のプロセッサ識別番号からプロセッサの位置を決定する。このとき、プロセッサ識別番号は自プロセッサの値に等しいか否かを調べ（ステップＳ９２）、「真」、すなわち当該プロセッサがそのプロセッサ自体である場合は、通信アクセス法プロセスに送信依頼して（ステップＳ９３）、処理を終了する。また、ステップＳ９２が「偽」、つまり当該プロセッサが他プロセッサである場合、他プロセッサ内の通信処理サーバプロセスに対して、送信データを回送することで送信処理を依頼し（ステップＳ９４）、処理を終了する。ステップＳ９１で「偽」、すなわちプロセッサ識別番号が無効である時はアプリケーションプロセスにその旨を通知して（ステップＳ９５）、処理を終了する。

図１７は、論理プロセッサ名リスト、プロセッサ９Ａ、９Ｃの端末管理テーブルリストおよび端末１Ａ、１Ｃ、１Ｄの管理テーブルの関係を模式的に示している。
論理プロセッサ名リストは、それぞれ論理プロセッサ名、物理的なプロセッサの識別情報およびその他の管理情報が格納された複数の配列からなり、図１７においては、配列０が未使用状態、配列１には、論理プロセッサ名としてＰＭ０１、物理的なプロセッサの識別情報としてプロセッサ９Ａを示す情報が格納され、配列２には、論理プロセッサ名としてＰＭ０２、物理的なプロセッサの識別情報としてプロセッサ９Ｂを示す情報が格納され、配列３には、論理プロセッサ名としてＰＭ０３、物理的なプロセッサの識別情報としてプロセッサ９Ｃを示す情報が格納されている。

プロセッサ９Ａの端末管理テーブルリストは、配列０、３および４が未使用であり、配列１には端末１Ａの管理テーブルが格納され、配列２には端末１Ｄの管理テーブルが格納されている。端末１Ａの管理テーブルには、通信識別子「０１０００００１」と他の管理情報とが格納されている。通信識別子「０１ ０００００１」の「０１」は論理プロセッ
サ名リストの配列番号であり、「０００００１」は端末管理テーブルリストの配列番号である。端末１Ｄの管理テーブルには、通信識別子「０１ ０００００２」と他の管理情報
とが格納されている。通信識別子「０１ ０００００２」の「０１」は論理プロセッサ名
リストの配列番号であり、「０００００２」は端末管理テーブルリストの配列番号である。

プロセッサ９Ｃの端末管理テーブルリストは、配列０、２〜４が未使用であり、配列１には端末１Ｃの管理テーブルが格納されている。端末１Ｃの管理テーブルには、通信識別子「０３ ０００００１」と他の管理情報とが格納されている。通信識別子「０３ ０００００１」の「０３」は論理プロセッサ名リストの配列番号であり、「０００００１」は端末管理テーブルリストの配列番号である。

〈プロセッサで異常発生時の端末の引き継ぎ〉
このようなシステムでは、あるプロセッサで異常が発生したときのバックアップを有効に行うことができる。

すなわち、上述した疎結合マルチプロセッサシステム６は、１個のプロセッサに待機属
性を、残りのプロセッサに現用属性を付与し、待機プロセッサは現用プロセッサの障害時にバックアップ用として動作するようにし、各プロセッサには所定の論理プロセッサ名を付与し、待機プロセッサが障害現用プロセッサをバックアップする際に現用プロセッサの論理プロセッサ名を引き継ぐとともに、プロセッサ識別番号として論理プロセッサ名リストの配列番号を割り当てることにより、待機プロセッサが現用プロセッサに結合していた端末を引き継いだ後でも、端末と通信識別子との関係を不変とすることができる。

あるプロセッサで異常が発生した場合、アダプタ内のプロセスとバックアッププロセッサ内の通信アクセス法プロセスとの間の論理的関係を引き継ぐ。さらに、通信アクセス法プロセスと通信処理サーバプロセスとの間の論理的関係も引き継ぐ。これにより、端末を異常が発生したプロセッサからバックアッププロセッサに引き継ぐ。

ここで、あるプロセッサで異常が発生したことを認識した通信処理サーバプロセスは、異常終了したプロセッサの論理プロセッサ名に対応するエントリとバックアップとを対応付ける。そして、それまでバックアッププロセッサに付与されていた論理プロセッサ名に対応するエントリは、当該プロセッサを閉塞状態として管理する。これにより、論理プロセッサ名対応の配列番号は不変となるので、論理プロセッサ名と当該論理プロセッサに結合した端末との関係は不変となり、アプリケーションプロセッサは、論理プロセッサを意識して処理を組むことで、あるプロセッサで異常が発生しても、処理を継続して行うことができる。

この場合の、プロセッサ９Ａに障害が発生した場合の具体的な処理の一例を、図１８〜図２２を参照して説明する。プロセッサ９Ａに障害が発生する前の状態では、図１８に示すように、端末１ＡはコネクションＰＡを介してプロセッサ９Ａに接続され、端末１ＤはコネクションＰＤを介して同様にプロセッサ９Ａに接続されている。

このときの論理プロセッサ名リストは、図２０に示すように、それぞれ論理プロセッサ名、物理的なプロセッサの識別情報、プロセッサの状態、現用待機属性およびその他の管理情報が格納された複数の配列からなる。すなわち、ここでは、管理情報として、プロセッサの状態および現用待機属性が図１７の例に追加されている。図２０においては、配列０が未使用状態であり、配列１には、論理プロセッサ名としてＰＭ０１、物理的なプロセッサの識別情報としてプロセッサ９Ａ、プロセッサの状態として活性状態、現用待機属性として現用を示す情報がそれぞれ格納されている。同様に配列２には、論理プロセッサ名としてＰＭ０２、物理的なプロセッサの識別情報としてプロセッサ９Ｂ、プロセッサの状態として活性状態、現用待機属性として現用を示す情報が格納され、配列３には、論理プロセッサ名としてＰＭ０３、物理的なプロセッサの識別情報としてプロセッサ９Ｃ、プロセッサの状態として活性状態、現用待機属性として待機を示す情報が格納されている。すなわち、この場合は、プロセッサ９Ｃがバックアップに用いられる待機プロセッサとなっている。

この状態でプロセッサ９Ａに障害が発生すると、図２１に示すように、配列１に格納される情報が、論理プロセッサ名としてＰＭ０１、物理的なプロセッサの識別情報としてプロセッサ９Ｃ、プロセッサの状態として活性状態、現用待機属性として現用を示す情報に変更される。配列２は、論理プロセッサ名としてＰＭ０２、物理的なプロセッサの識別情報としてプロセッサ９Ｂ、プロセッサの状態として活性状態、現用待機属性として現用を示す情報が格納されたままであり、配列３は、論理プロセッサ名としてＰＭ０３、物理的なプロセッサの識別情報はなし、プロセッサの状態として閉塞状態、現用待機属性もなしの状態に変わる。

このことにより、障害の発生したプロセッサ９Ａの論理プロセッサ番号はプロセッサ９
Ｃに引き継がれて、図１９に示すように、障害の発生したプロセッサ９Ａの機能はプロセッサ９Ｃが肩代わりすることになり、端末１ＡはコネクションＰＡを介してプロセッサ９Ｃに接続され、端末１ＤはコネクションＰＤを介してプロセッサ９Ｃに接続される。このときプロセッサ９Ａは、障害発生状態にあるが、ソフトウェア障害の場合には再ＩＰＬを実施して、プロセッサの再立ち上げを行い、プロセッサを復旧する。ハードウェア障害のときは、オペレータにプロセッサモジュールの交換等を促し、障害復旧を行う。

このようにしてプロセッサ９Ａの障害が復旧されると、図２２に示されるように、配列３は、論理プロセッサ名としてＰＭ０３、物理的なプロセッサの識別情報としてプロセッサ９Ａ、プロセッサの状態として活性状態、現用待機属性として待機を示す情報が格納された状態となり、プロセッサ９Ａが次のバックアップ用待機プロセッサとして待機状態となる。

なお、アプリケーションプロセスが、システムに結合した端末に対するデータ送信用のシステムコールを実行する場合、当該結合端末に対応する通信識別子を指定する必要がある。ところで、当該通信識別子は、結合処理を実行したアプリケーションプロセスにのみ通知される。したがって、他のアプリケーションプロセス、特に端末が結合していないＰＭ内のアプリケーションプロセスは、何らかの方法で通信識別子を取得する必要がある。この場合の通信識別子を取得するには種々の方法があるが、例えば結合処理を実行したアプリケーションプロセスが、全プロセスに対して通信識別子をブロードキャストすればよい。この場合、端末切断時にも、通信識別子を無効化するためにブロードキャストが必要である。

従来の疎結合マルチプロセッサシステムにおいては、システムジェネレーション時に、システムに結合する端末とプロセッサとの関係を定義したテーブルを作成していた。そして、システム始動時に当該テーブルを各プロセッサの主記憶装置にロードし、アプリケーションプロセスが発行した送信システムコール処理時に、前記ロード情報を参照することによりプロセッサを決定していた。そのため、例えばプロセッサの負荷分散の目的などから、端末が結合するプロセッサを動的に変更することはできなかった。

また、端末が結合するプロセッサを動的に変更するように構成された疎結合マルチプロセッサシステムも従来より存在した。但し、この場合、プロセッサに結合した端末との送受信処理が可能なアプリケーションプロセスは、当該プロセッサ上で動作するものに限られていた。

疎結合マルチプロセッサシステムにおける端末利用を実現する上で、端末結合処理の性能とデータ送受信処理の性能とを同時に高めることはできない。したがって、業務の運用に応じたトレードオフが必要となる。問題は、この二者択一をシステムが行うのかユーザが行うのかという点である。

まず、システムが二者択一を行う方法としては、端末の運用定義による方法や、結合時にアプリケーションプロセスがパラメータで指定する方法などがある。しかし、システムプログラムの処理論理が複雑になるという点およびシステムプログラムが２本立てとなり煩雑であるという点で現実的ではない。

他方、ユーザが二者択一する場合、自身の業務の運用に合わせていずれかを選択するだけであるから問題は少ない。以上述べたように、システムがユーザの業務の運用上の要件を満たしつつ端末共用を実現することは困難である。

さらに、端末が結合したプロセッサで障害発生時に、当該端末をバックアッププロセッ
サに引き継ぎ、なおかつ、各プロセッサから引き継いだ端末を共用できる機能は従来存在しなかった。

しかしながら、疎結合マルチプロセッサシステムにおいて、端末がシステムと結合する場合、結合するプロセッサの決定論理は、ジェネレーション時に定義する手法や、運用時の各プロセッサの負荷状況に応じて選択する手法など、複数の手法を組み合わせて利用できることが、業務設計の柔軟性を向上させる上で望ましい。

同じく、業務設計の柔軟性の向上の観点からいって、システムに結合した端末を、システムを構成する各プロセッサ内のアプリケーションプロセスから共用できるようにすることが望ましい。

さらに、フォルトトレラントコンピュータとして疎結合マルチプロセッサシステムを利用する場合、結合端末を障害プロセッサからバックアッププロセッサに引き継ぐ前と後で、アプリケーションプロセスが実行する送受信システムコールのインタフェースが不変であることが望ましい。

従来のマルチプロセッサシステムで、上述の要件を全て満足するものは存在しなかったが、上述の第２の実施例のマルチプロセッサ装置によれば、これらの要望を全て満たすことができるようになる。

したがって、この実施例のマルチプロセッサ装置では、前述のように通信識別子を構造化し、システムコール時にアプリケーションプロセスが、結合端末対応に指定する通信識別子からプロセッサ識別番号を取り出すことで、端末が結合しているプロセッサの特定が可能となる。さらに、プロセッサ番号として、論理プロセッサ名リスト内の配列番号を割り当てていることにより、プロセッサで異常が発生し、端末をバックアッププロセッサに引き継いだ際にも、送信システムコールのインタフェースの普遍性が保証される。

さらに、このように構成した、マルチプロセッサシステムを、先に述べた第１の実施例のネットワーク装置におけるＦＥＰシステムとして用いることができる。
この場合、具体的には例えば図３に示すＦＥＰシステム３を図１０に示される疎結合マルチプロセッサシステム６で構成することになり、第１の実施例のネットワーク装置を一層有効に構成することができる。

本発明に係るネットワーク装置の構成を示す原理図である。 本発明に係るマルチプロセッサ装置の構成を示す原理図である。 本発明の実施例１に係るネットワーク装置の構成を示すブロック図である。 図３のネットワーク装置の要部の構成を詳細に示すブロック図である。 図４のネットワーク装置の接続ノード管理部の動作を説明するためのフローチャートである。 図４のネットワーク装置の宛先ノード名参照部の動作を説明するためのフローチャートである。 図４のネットワーク装置の宛先ノード名変更部の動作を説明するためのフローチャートである。 図４のネットワーク装置の接続処理実行部の動作を説明するためのフローチャートである。 図４のネットワーク装置の運用情報取得部の動作を説明するためのフローチャートである。 本発明の実施例２に係るマルチプロセッサ装置の構成を示すブロック図である。 図１０のマルチプロセッサ装置の動作を模式的に説明するための発呼による端末結合時のデータフロー図である。 図１０のマルチプロセッサ装置の動作を模式的に説明するための着呼による端末結合時のデータフロー図である。 図１０のマルチプロセッサ装置の通信識別子の採番処理の動作を説明するためのフローチャートである。 図１０のマルチプロセッサ装置の通信識別子の通知処理の動作を説明するためのフローチャートである。 図１０のマルチプロセッサ装置の動作を模式的に説明するためのデータ送信時のデータフロー図である。 図１０のマルチプロセッサ装置の論理プロセッサ識別番号取得処理の動作を説明するためのフローチャートである。 図１０のマルチプロセッサ装置に用いられるテーブルを模式的に説明するための図である。 図１０のマルチプロセッサ装置のプロセッサ障害発生時の動作を説明するための模式図である。 図１０のマルチプロセッサ装置のプロセッサ障害バックアップ時の動作を説明するための模式図である。 図１０のマルチプロセッサ装置のプロセッサ障害発生時の動作を説明するための障害発生前の論理プロセッサ名リストの模式図である。 図１０のマルチプロセッサ装置のプロセッサ障害発生時の動作を説明するための障害発生時の論理プロセッサ名リストの模式図である。 図１０のマルチプロセッサ装置のプロセッサ障害発生時の動作を説明するための障害復旧時の論理プロセッサ名リストの模式図である。

符号の説明

１Ａ，１Ｂ，１Ｃ，１Ｄ 端末
２ 交換網
３ フロントエンドプロセッサ（ＦＥＰ）システム
４ ネットワーク
５，５Ａ，５Ｂ ホスト（プロセッサ）
６ 疎結合マルチプロセッサシステム
７Ａ，７Ｂ 回線アダプタ
８ 入出力（ＩＯ）バス
９Ａ，９Ｂ，９Ｃ プロセッサ
３１，５１ 通信処理アプリケーション実行部
３２，５２ 通信処理サーバ部
３３，５３ 通信アクセス法処理部
３４ ノード管理テーブル
３５ 運用情報取得部
３６ 宛先ノード名参照部
３７ 宛先ノード名変更部
３８ 接続ノード管理部
３９ 接続処理実行部
９１Ａ，９１Ｂ，９１Ｃ アプリケーションプロセス実行部
９２Ａ，９２Ｂ，９２Ｃ 通信処理サーバプロセス実行部
９３Ａ，９３Ｂ，９３Ｃ 通信アクセス法プロセス実行部

Claims (3)

1. アプリケーションプロセスを実行するためのアプリケーションプロセス手段、通信処理サーバプロセスを実行するための通信処理サーバプロセス手段、および通信アクセス法プロセスを実行するための通信アクセス法プロセス手段を有するマルチプロセッサが入出力バスに複数個並列的に結合される疎結合マルチプロセッサシステムにおいて、
   前記通信処理サーバプロセス手段は、プロセッサ識別信号とプロセッサ内に記憶される端末管理テーブルにおける配列番号とを含んでマルチプロセッサシステム内で一意的に定義され且つ前記アプリケーションプロセスによるデータ送信のシステムコールの実行時に送信先端末に対応して指定される、通信識別子からプロセッサ識別番号を取り出すとともに、該プロセッサ識別番号により決定されるプロセッサに対して、当該プロセッサ内の通信処理サーバプロセスで端末への送信処理を実行させるべく送信データを回送する手段を具備することを特徴とするマルチプロセッサ装置。
2. 前記通信処理サーバプロセス手段は、
   端末のプロセッサとの結合時に、プロセッサ識別信号とプロセッサ内の端末管理テーブルにおける配列番号とを組み合わせて得られるマルチプロセッサシステム内での一意的な番号を通信識別子として採番する通信識別子採番手段と、
   アプリケーションプロセスに対して、端末結合の処理結果が正常の場合に、この端末結合の処理結果とともに前記通信識別子採番手段により採番された通信識別子を通知し、端末結合の処理結果が異常の場合には、前記通信識別子採番手段により採番された通信識別子を無効化してその端末結合の処理結果を通知する通信識別子通知手段と、
   アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定された通信識別子からプロセッサ識別番号を取り出すプロセッサ識別番号取得手段と
   を具備することを特徴とする請求項１に記載のマルチプロセッサ装置。
3. 前記疎結合マルチプロセッサシステムは、
   １個のプロセッサに待機属性を、残りのプロセッサに現用属性を付与し、待機プロセッサは現用プロセッサの障害時にバックアップ用として動作するマルチプロセッサシステムであって、
   各プロセッサには所定の論理プロセッサ名を付与し、待機プロセッサが障害現用プロセッサをバックアップする際に現用プロセッサの論理プロセッサ名及び前記プロセッサ識別番号を引き継ぐことにより、待機プロセッサが現用プロセッサに結合していた端末を引き継いだ後でも、端末と前記通信識別子との関係を不変とすることを特徴とする請求項１に記載のマルチプロセッサ装置。

Images