JP3599364B2 - ネットワーク装置 - Google Patents
ネットワーク装置 Download PDFInfo
- Publication number
- JP3599364B2 JP3599364B2 JP31553093A JP31553093A JP3599364B2 JP 3599364 B2 JP3599364 B2 JP 3599364B2 JP 31553093 A JP31553093 A JP 31553093A JP 31553093 A JP31553093 A JP 31553093A JP 3599364 B2 JP3599364 B2 JP 3599364B2
- Authority
- JP
- Japan
- Prior art keywords
- processor
- terminal
- communication
- host
- name
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0062—Provisions for network management
- H04Q3/0075—Fault management techniques
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
- H04Q11/0407—Selecting arrangements for multiplex systems for time-division multiplexing using a stored programme control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13521—Indexing scheme relating to selecting arrangements in general and for multiplex systems fault management
Description
【０００１】
【産業上の利用分野】
本発明は、交換網経由の端末からダイアリングを行ってネットワーク内のノードと接続して業務を行う運用形態において、端末側では、接続するノードの宛先を意識することなく、システムが運用情報に基づいて動的に宛先を切替えることを可能とするネットワーク装置、およびアプリケーションプロセスに対して、システムに結合した端末とのデータ送受信機能を提供する疎結合マルチプロセッサシステムにおいて、各プロセッサ内のアプリケーションプロセスからのデータ送受信処理を可能とするマルチプロセッサ装置に関する。
【０００２】
【従来の技術】
従来のネットワーク装置においては、交換網経由の端末からダイアリングを行ってネットワーク内のノードと接続する場合、端末の結合宛先が、定義により固定的に決められているか、または、次のいずれかの方法を用いて端末の結合宛先を切替えるかしていた。
【０００３】
（ａ） 端末オペレータが、運用スケジュールを意識して、ネットワーク内の所定の結合ノードに対してダイアリングする。
（ｂ） 端末の内部に、所定の運用スケジュールに基づいて接続する宛先を切替えてダイアリングするようなプログラムを組み込むことによって、宛先を動的に切替える。
【０００４】
【発明が解決しようとする課題】
上述したように、交換網経由で接続された端末からダイアリングして、接続ノードを切り替える業務の運用においては、前記（ａ） の方法では、端末オペレータが、運用スケジュールを意識してダイアリングする必要があった。このような方法では、運用スケジュールが複雑になった場合、端末オペレータの負担が重くなるという欠点がある。
【０００５】
また、前記（ｂ） の方法では、端末内に宛先切り替え用のプログラムを組み込む必要があった。この場合、業務の運用で使用する全ての交換網経由の端末内に、宛先切り替え用のプログラムを組み込まなければならないため、運用スケジュールの変更・変化に対処する場合、コストがかさむという弊害がある。
【０００６】
そこで、本発明では、端末からダイアリングした際に、前記端末が接続される交換網とホストプロセッサが結合されるネットワークとの間で、システムの運用状況に応じて、柔軟に且つ適切に宛先管理、故障対処および業務処理を行うことを可能とするネットワーク装置を提供することを目的としている。
【０００８】
【課題を解決するための手段】
本発明は、上記目的を達成するために、ネットワークを介して１個以上のホストプロセッサ（以下、「ホスト」と称する）に結合され且つ交換網経由で複数個の端末に接続されるフロントエンドプロセッサシステム（以下、「ＦＥＰシステム」と称する）を設け、該ＦＥＰシステムにより、前記端末からのダイアリングに対し当該端末を接続するホストプロセッサおよびそのホストプロセッサ内のネットワークノードの管理および接続の実行、前記通信処理アプリケーション実行手段により実行される通信処理アプリケーションによる指定された端末に対応して接続宛先名として登録されているネットワークノードの参照、および該通信処理アプリケーションによる指定端末の接続宛先名の変更更新を行って、通信処理アプリケーションおよび通信アクセス法の処理を実行することにより、端末からダイアリングした際に、前記端末が接続される交換網とホストが結合されるネットワークとの間で、システムの運用状況に応じて、柔軟に且つ適切に宛先管理、故障対処および業務処理を行うことが可能なネットワーク装置とした。
【０００９】
図１は、本発明によるネットワークシステムの原理構成を示している。図１に示すシステムは、端末１Ａ、１Ｂ、交換網２、ＦＥＰシステム３、回線／ネットワーク４およびホスト５を有している。
【００１０】
端末１Ａおよび１Ｂは、ユーザすなわちオペレータにより操作される複数の端末であり、この図１では、２個の端末１Ａおよび１Ｂが図示されている。
交換網２は、複数の端末１Ａおよび１ＢをＦＥＰシステム３に接続する。
【００１１】
ＦＥＰシステム３は、回線／ネットワーク４を介してホスト５に結合されている。図１では、１個のホスト５のみが示されているが、ホスト５は複数個設けられていてもよい。
【００１２】
ホスト５は、通信処理アプリケーションを実行するための通信処理アプリケーション実行部５１、通信処理サーバを実行するための通信処理サーバ部５２および通信アクセス法の処理を実行するための通信アクセス法処理部５３を有している。通常、ＦＥＰシステム３の通信処理アプリケーション実行部３１は、そのパフォーマンスについてはホスト５の通信処理アプリケーション実行部５１よりも小規模でよい。
【００１３】
ＦＥＰシステム３も、通信処理アプリケーションを実行するための通信処理アプリケーション実行部３１、通信処理サーバを実行するための通信処理サーバ部３２および通信アクセス法の処理を実行するための通信アクセス法処理部３３を有している。通常、ＦＥＰシステム３の通信処理アプリケーション実行部３１は、パフォーマンスについてはホスト５の通信処理アプリケーション実行部５１よりも小規模でよい。
【００１４】
ＦＥＰシステム３は、前記端末１Ａ、１Ｂからのダイアリングに対し当該端末を接続するプロセッサおよびネットワークノードの管理および接続の実行、前記通信処理アプリケーション実行部３１により実行される通信処理アプリケーションによる指定された端末に対応して接続宛先名として登録されているネットワークノードの参照、および該通信処理アプリケーションによる指定端末の接続宛先名の変更更新を行うことができる。
【００１５】
なお、ＦＥＰシステム３は、接続ノード管理部、宛先名参照部、宛先名変更部、接続処理実行部および運用情報取得部を有していてもよい。この場合、典型的には、前記宛先名参照部、宛先名変更部および運用情報取得部は、通信処理アプリケーション実行部３１に設けられ、前記接続ノード管理部および接続処理実行部は、通信アクセス法処理部３３に設けられる。そして、通信処理アプリケーション実行部３１と通信アクセス法処理部３３とは、通信処理サーバ部３２を介して結合される。
【００１６】
前記接続ノード管理部は、端末単位に、当該端末をどのプロセッサの、どのネットワークノードに接続するかを示すノード管理テーブルを保持し、前記端末からＦＥＰシステムにダイアリングした際に、当該端末をどのプロセッサの、どのネットワークノードに接続するかを管理する。
【００１７】
前記宛先名参照部は、ＦＥＰシステム内で動作する通信処理アプリケーションが、端末名を指定して宛先名参照のシステムコールを発生した際に、前記ノード管理テーブルにおいて指定端末の接続宛先名として登録されているネットワークノード名を前記通信処理アプリケーションに通知する。
【００１８】
前記宛先名変更部は、前記通信処理アプリケーションが、端末名とネットワークノード名を指定して宛先名変更のシステムコールを発生した際に、前記ノード管理テーブルにおける指定端末の接続宛先名を、指定ネットワークノード名に更新する。
【００１９】
前記接続処理実行部は、端末からＦＥＰシステムにダイアリングした際に、前記接続ノード管理テーブルを参照して接続ネットワークノードを決定し当該ノードに接続要求を伝達する。
【００２０】
前記運用情報取得部は、前記通信処理アプリケーションが、端末の接続宛先名を変更するために利用する運用情報を取得する。
さらに、前記運用情報取得部は、ホストの運用スケジュールを参照し、且つ前記接続ノード管理部は、該当ホストの前記運用スケジュールに基づき、ホスト稼働時には端末の接続ノードを該当ホスト内のネットワークノードとし、ホスト停止時には前記該当ホストを代行し得る他のホスト内のネットワークノードとして宛先を変更するようにしてもよい。
【００２１】
また、前記運用情報取得部は、ホストの運用スケジュールを参照し、且つ前記接続ノード管理部は、該当ホストの前記運用スケジュールに基づき、ホスト稼働時には端末の接続ノードを該当ホスト内のネットワークノードとし、ホスト停止時にはそのＦＥＰシステム内で実行される通信処理アプリケーションを前記端末に接続されるネットワークノードとして宛先を変更するようにしてもよい。
【００２２】
前記運用情報取得部は、そのＦＥＰシステム内で動作する通信処理アプリケーションが、ホスト内で動作する通信処理アプリケーションと相互に通信を行うことにより運用スケジュールを決定するようにしてもよい。
【００２３】
アプリケーションプロセス部、通信処理サーバプロセス部、および通信アクセス法プロセス部を有するマルチプロセッサが入出力バスに複数個並列的に結合される疎結合マルチプロセッサシステムにおいて、前記通信処理サーバプロセス部が、前記アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定される、プロセッサ識別信号とプロセッサ内に記憶される端末管理テーブルにおける配列番号とを含むマルチプロセッサシステム内で一意的な、通信識別子からプロセッサ識別番号を取り出すとともに、該プロセッサ識別番号により決定されるプロセッサに対して、当該プロセッサ内の通信処理サーバプロセスで端末への送信処理を実行させるべく送信データを回送するようにすることにより、各プロセッサ内のアプリケーションプロセスからデータ送受信処理を行うことができるとともに、端末を結合するプロセッサを動的に変更可能として、前記各プロセッサ内のアプリケーションプロセスから端末を共用することができ、常時運用を可能とするマルチプロセッサ装置を、先に述べたネットワーク装置におけるＦＥＰシステムとして用いてもよい。
【００２４】
図２は、本発明によるマルチプロセッサシステムの原理構成を示している。図２に示すシステムは、端末１Ａ、１Ｂ、１Ｃおよび１Ｄと、疎結合マルチプロセッサシステム６とで構成されている。疎結合マルチプロセッサシステム６は、プロセッサ９Ａ、９Ｂおよび９Ｃを有し、これら各プロセッサ９Ａ、９Ｂ、９Ｃは、それぞれ、アプリケーションプロセス実行部、通信処理サーバプロセス実行部、および通信アクセス法プロセス実行部を有する。前記端末１Ａ、１Ｂ、１Ｃおよび１Ｄは、交換網２を介してプロセッサ９Ａ、９Ｂおよび９Ｃに接続されている。
【００２５】
前記通信処理サーバプロセス実行部は、アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定される通信識別子からプロセッサ識別番号を取り出すとともに、該プロセッサ識別番号により決定されるプロセッサに対して、当該プロセッサ内の通信処理サーバプロセスで端末への送信処理を実行させるべく送信データを回送する。前記通信識別子は、プロセッサ識別信号とプロセッサ内に記憶される端末管理テーブルにおける配列番号とを含んでマルチプロセッサシステム内で一意的に定義される。
【００２６】
通信処理サーバプロセス実行部は、通信識別子採番部、通信識別子通知部およびプロセッサ識別番号取得部を具備していてもよい。前記通信識別子採番部は、端末のプロセッサとの結合時に、プロセッサ識別信号とプロセッサ内の端末管理テーブルにおける配列番号とを組み合わせて得られるマルチプロセッサシステム内での一意的な番号を通信識別子として採番する。前記通信識別子通知部は、アプリケーションプロセスに対して、端末結合の処理結果の通知時に、通信識別子を通知する。前記プロセッサ識別番号取得部は、アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定された通信識別子からプロセッサ識別番号を取り出す。
【００２７】
また、前記疎結合マルチプロセッサシステム６は、１個のプロセッサに待機属性を、残りのプロセッサに現用属性を付与し、待機プロセッサは現用プロセッサの障害時にバックアップ用として動作するようにし、各プロセッサには所定の論理プロセッサ名を付与し、待機プロセッサが障害現用プロセッサをバックアップする際に現用プロセッサの論理プロセッサ名を引き継ぐとともに、プロセッサ識別番号として論理プロセッサ名リストの配列番号を割り当てることにより、待機プロセッサが現用プロセッサに結合していた端末を引き継いだ後でも、端末と通信識別子との関係を不変とするようにしてもよい。
【００２９】
【作用】
本発明によるネットワークシステムでは、通信処理アプリケーションを組み込んだＦＥＰシステム３を１組または複数個のホスト５に結合するとともに、業務実行時に、端末１Ａ、１Ｂからネットワーク内のノードへの接続をする場合、常にＦＥＰシステム３にダイアリングするだけで、ＦＥＰシステム３からその時点で有効なネットワークノードに対して接続要求を振り分け、端末１Ａ、１Ｂを有効なノードに接続する。
【００３０】
本発明によるマルチプロセッサシステム６では、通信処理サーバプロセスにより、端末結合時に、プロセッサ識別番号と端末管理テーブル内の配列番号の２つの情報を組み合わせたものとして構造化した通信識別子を動的に割り当て、当該マルチプロセッサシステム内で一意的に定義されるこの通信識別子をアプリケーションプロセスに通知し、該アプリケーションプロセスによる結合端末に対する送信システムコール時に、結合端末毎に対応して指定した通信識別子に基づいてプロセッサを決定し、当該プロセッサに送信データを回送することにより、送信処理を実行するので、プロセッサで異常が発生し、端末をバックアッププロセッサに引き継いだ際にも、送信システムコールのインタフェースの普遍性が保証される。
【００３１】
【実施例】
《実施例１》
次に、本発明に係るネットワーク装置の具体的な実施例を図面を参照して説明する。
【００３２】
図３は、本発明の第１の実施例によるネットワーク装置の構成を示している。図３のネットワーク装置は、端末１Ａ、１Ｂ…、交換網２、ＦＥＰシステム３、回線／ネットワーク４、ホスト５Ａ…を有している。
【００３３】
端末１Ａ、１Ｂ…は、交換網２を介してＦＥＰシステム３に接続される。
ＦＥＰシステム３は、高速ＬＡＮ（ローカルエリアネットワーク）回線またはネットワーク回線により構成される回線／ネットワーク４を介して１個以上のホスト５Ａ…に結合されている。
【００３４】
ホスト５Ａ…は、各々通信処理アプリケーションを実行するための通信処理アプリケーション実行部５１、通信処理サーバ処理を実行するための通信処理サーバ部５２および通信アクセス法の処理を実行するための通信アクセス法処理部５３を有している。
【００３５】
ＦＥＰシステム３も、通信処理アプリケーションを実行するための通信処理アプリケーション実行部３１、通信処理サーバ処理を実行するための通信処理サーバ部３２および通信アクセス法の処理を実行するための通信アクセス法処理部３３を有している。通常、ＦＥＰシステム３の通信処理アプリケーション実行部３１は、パフォーマンスについてはホスト５の通信処理アプリケーション実行部５１よりも小規模でよい。
【００３６】
通信アクセス法処理部３３は、ノード管理テーブル３４を保持している。ノード管理テーブル３４は、端末毎に、端末名、端末ネットワークアドレス、定義指定ノード名（とその有効フラグ）、およびアプリケーション指定ノード名（とその有効フラグ）が登録される。
【００３７】
ＦＥＰシステム３は、前記端末１Ａ、１Ｂ…からのダイアリングに対し当該端末を接続するプロセッサおよびネットワークノードの管理および接続の実行、前記通信処理アプリケーション実行部３１により実行される通信処理アプリケーションによる指定された端末に対応して接続宛先名として登録されているネットワークノードの参照、および該通信処理アプリケーションによる指定端末の接続宛先名の変更更新を行うことができる。
【００３８】
この図３の実施例における主としてＦＥＰシステム３部分を図４にさらに詳細に示す。図４においては、ホスト５Ａ、５Ｂ、および端末１Ａ、１Ｂ、１Ｃが示されている。
【００３９】
図４に示すように、ＦＥＰシステム３の通信処理アプリケーション実行部３１は、運用情報取得部３５、宛先ノード名参照部３６および宛先ノード名変更部３７を有しており、ＦＥＰシステム３の通信アクセス法処理部３３は、ノード管理テーブル３４を保持するとともに、接続ノード管理部３８および接続処理実行部３９を有している。
【００４０】
運用情報取得部３５は、前記通信処理アプリケーションが、端末１Ａ…の接続宛先名を変更するために利用する運用情報（各ホストの運用スケジュール）を取得する。このとき、運用情報取得部３５は、ホスト５Ａ…の運用スケジュールを参照することで取得しても良いし、そのＦＥＰシステム内で動作する通信処理アプリケーションがホスト内で動作する通信処理アプリケーションと相互に通信を行うことにより運用スケジュールを決定し取得しても良い。宛先ノード名参照部３６は、ＦＥＰシステム３内で動作する通信処理アプリケーションが、端末名を指定して宛先名参照のシステムコールを発生した際に、ノード管理テーブル３４において指定端末の接続宛先名として登録されているネットワークノード名を前記通信処理アプリケーションに通知する。
【００４１】
宛先ノード名変更部３７は、前記通信処理アプリケーションが、端末名とネットワークノード名を指定して宛先名変更のシステムコールを発生した際に、ノード管理テーブル３４における指定端末の接続宛先名を、指定ネットワークノード名に更新する。
【００４２】
接続ノード管理部３８は、端末単位に、当該端末をどのプロセッサの、どのネットワークノードに接続するかを示すノード管理テーブル３４を用い、前記端末１Ａ…からＦＥＰシステム３にダイアリングした際に、当該端末をどのプロセッサの、どのネットワークノードに接続するかを管理する。
【００４３】
接続処理実行部３９は、端末１Ａ…からＦＥＰシステム３にダイアリングした際に、ノード管理テーブル３４を参照して接続ネットワークノードを決定し当該ノードに接続要求を伝達する。
【００４４】
なお、前記運用情報取得部３５は、ホスト５Ａ…の運用スケジュールを参照し、且つ前記接続ノード管理部３８は、該当ホスト５Ａ…の前記運用スケジュールに基づき、ホスト稼働時には端末の接続ノードを該当ホスト５Ａ…内のネットワークノードとし、ホスト停止時には前記該当ホスト５Ａ…を代行し得る他のホスト内のネットワークノードとして宛先を変更するようにしてもよい。
【００４５】
また、前記運用情報取得部３５は、ホスト５Ａ…の運用スケジュールを参照し、且つ前記接続ノード管理部３８は、該当ホスト５Ａ…の前記運用スケジュールに基づき、ホスト稼働時には端末の接続ノードを該当ホスト５Ａ…内のネットワークノードとし、ホスト停止時にはそのＦＥＰシステム３内で実行される通信処理アプリケーションを前記端末に接続されるネットワークノードとして宛先を変更するようにしてもよい。
【００４６】
さらに、前記運用情報取得部３５は、そのＦＥＰシステム内で動作する通信処理アプリケーションが、ホスト内で動作する通信処理アプリケーションと相互に通信を行うことにより運用スケジュールを決定するようにしてもよい。
【００４７】
図３および図４において、先に述べたように、ホスト５Ａ…とＦＥＰシステム３は、例えば高速ＬＡＮ回線からなる回線／ネットワーク４で接続されている。端末１Ａ…は、ＦＥＰシステム３と交換網２経由で接続され、ホスト５Ａ…に例えばファイル転送を行う。
【００４８】
また、ＦＥＰシステム３の通信処理アプリケーション実行部３１で実行される通信処理アプリケーションは、ホスト５Ａ…で実行される通信処理アプリケーションとの間で通信して、ホストマシンの稼働状況を取得する。
【００４９】
ＦＥＰシステム３内で動作する通信アクセス法処理部３３は、端末単位で接続ノード名を記述したネットワーク定義を展開し、ノード管理テーブル３４としてＦＥＰシステム３の主記憶域内に保持する。このノード管理テーブル３４には、ネットワーク定義で指定されたノード名と通信処理アプリケーションが指定するノード名との２つの宛先を管理する。通信処理アプリケーションがノード名の変更要求を出していない場合、端末１Ａ…からのダイアリング時には、ノード管理テーブル３４に格納されたネットワーク定義で指定されたノードに振り分けられる。
【００５０】
これに対して、通信処理アプリケーションがノード名の変更要求を発行している場合には、この名前をノード管理テーブル３４内の、通信処理アプリケーション指定欄に反映しておく。そして、端末１Ａ…からのダイアリング時には、ノード管理テーブル３４内に通信処理アプリケーションが指定した名前が格納されていることから、これを優先的に採用して当該ノードに振り分ける。
【００５１】
ＦＥＰシステム３内の通信処理アプリケーションは、ホスト５Ａ…が停止する前に、宛先ノード名を当該ＦＥＰシステム３自体に変更しておく。そして、ホスト５Ａ…が稼働状態となったのを契機に、宛先ノード名をホスト５Ａ…内のノードに変更する。
【００５２】
ＦＥＰシステム３内の通信処理アプリケーションは、宛先ノードが当該ＦＥＰシステム３自体となっている場合、端末１Ａ…から転送されるファイルを一時的に蓄積しておく。そして、ホストマシンが稼働状態となり、転送指示を受けたときに、一括してホスト５Ａ…に転送する。
【００５３】
なお、宛先ノードが当該ＦＥＰシステム３自体となっている場合に、ＦＥＰシステム３内の通信処理アプリケーションが、端末１Ａ…から転送されるデータを、ホストに代わって処理することが可能であれば、端末１Ａ…から転送されるファイルをホストマシンに代わって処理するようにしてもよい。
【００５４】
図３に示す経路Ｐ１は、稼働状態を判断するための相互の通信を、経路Ｐ２は、稼働状況の変化に応じて発行される宛先切換え指示が端末管理テーブルに反映される様子を、そして経路Ｐ３およびＰ４は、接続時に端末管理テーブルを参照して、実際に有効な宛先に接続される様子をそれぞれ示している。
【００５５】
図５、図６、図７、図８および図９は、接続ノード管理部３８、宛先ノード名参照部３６、宛先ノード名変更部３７、接続処理実行部３９および運用情報取得部３５のそれぞれの動作を詳細に示すフローチャートである。
【００５６】
図５に示す接続ノード管理部３８の処理は次のように行われる。
処理が開始されると、ＩＰＬ（イニシャルプログラムローダ）処理を行うか否かが判定され（ステップＳ１１）、「真」である場合には、システムファイルから交換端末定義情報を読み出す（ステップＳ１２）。次に、交換端末定義情報のシンタクスチェックおよびセマンティック等の定義チェック処理が行われ（ステップＳ１３）、このチェック処理の結果が判定されて（ステップＳ１４）、「真」である場合には、ＦＥＰシステム３の主記憶域に交換端末数分のノード管理テーブル領域が獲得され、先に読み出された定義情報が反映されて（ステップＳ１５）、処理が終了する。
【００５７】
ステップＳ１１で、「偽」であると判定されたときは、宛先ノード名の参照または変更依頼であるか否かが判定され（ステップＳ１６）、「真」であると判定されたときは、依頼端末名をキーとしてノード管理テーブル３４の検索が行われる（ステップＳ１７）。次に、検索が成功したか否かが判定され（ステップＳ１８）、「真」であれば、参照依頼か否かが判定される（ステップＳ１９）。ステップＳ１９で「真」であると判定された場合には、アプリケーション指定ノードが有効であるか否かが判定され（ステップＳ２０）、「真」であると判定された場合には、アプリケーション指定ノード名を出力情報領域に格納して（ステップＳ２１）、処理を終了する。
【００５８】
ステップＳ２０で、「偽」であると判定された場合には、定義指定ノード名を出力情報領域に格納して（ステップＳ２２）、処理を終了する。
ステップＳ１９で、「偽」、すなわち変更依頼であると判定された場合には、変更ノード名はバイナリでゼロであるか否かが判定され（ステップＳ２３）、「真」であれば、さらに指定ノード名は有効であるか否かが判定される（ステップＳ２４）。ステップＳ２４で、「真」であると判定された場合には、ノード管理テーブルのアプリケーション指定有効フラグをオンとし（ステップＳ２５）、さらにアプリケーション指定ノード名をノード管理テーブル３４に格納して（ステップＳ２６）、処理を終了する。
【００５９】
ステップＳ２３で「偽」であると判定されたときは、ノード管理テーブル３４のアプリケーション指定有効フラグをオフとして（ステップＳ２７）、処理を終了する。
【００６０】
ステップＳ１４、Ｓ１６、Ｓ１８およびＳ２４で、「偽」と判定された場合はエラーであるので、復帰値を異常として（ステップＳ２８）、処理を終了する。
図６に示す宛先ノード名参照部３６の処理は次のように行われる。
【００６１】
処理が開始されると、接続ノード管理部３８に宛先ノード名の参照を依頼し（ステップＳ３１）、正常復帰か否かが判定され（ステップＳ３２）、「真」であれば、出力ノード名を通信処理アプリケーションに通知して（ステップＳ３３）、処理を終了する。ステップＳ３２において、「偽」であると判定された場合には、異常復帰の詳細なコードを付加してアプリケーションに異常終了を通知し（ステップＳ３４）、処理を終了する。
【００６２】
図７に示す宛先ノード名変更部３７の処理は次のように行われる。
処理が開始されると、接続ノード管理部３８に宛先ノード名の変更を依頼し（ステップＳ４１）、正常復帰か否かが判定され（ステップＳ４２）、「真」であれば、通信処理アプリケーションに正常終了を通知して（ステップＳ４３）、処理を終了する。ステップＳ４２において、「偽」であると判定された場合には、異常復帰の詳細なコードを付加してアプリケーションに異常終了を通知し（ステップＳ４４）、処理を終了する。
【００６３】
図８に示す接続処理実行部３９の処理は次のように行われる。
処理が開始されると、ダイアリング受付時の端末のアドレスをキーとしてノード管理テーブルの検索を行い（ステップＳ５１）、アプリケーション指定ノードは有効か否かが判定され（ステップＳ５２）、「真」であれば、指定ノード名からアドレスを求めて、当該ノードに接続要求を通知して（ステップＳ５３）、処理を終了する。ステップＳ５２において、「偽」であると判定された場合には、定義ノード名からアドレスを求めて当該ノードに接続要求を通知し（ステップＳ５４）、処理を終了する。
【００６４】
図９に示す運用情報取得部３５の処理は次のように行われる。
処理が開始されると、接続ノード変更契機か否かが判定され（ステップＳ６１）、「真」であれば、運用情報から接続ノード名を取得する（ステップＳ６２）。さらに、宛先ノード名変更部３７により接続先ノード名を取得し（ステップＳ６３）、変更処理が正常に完了したか否かが判定され（ステップＳ６４）、「真」であれば処理を終了する。ステップＳ６４で、「偽」と判定された場合には、異常処理が行われて（ステップＳ６５）、処理を終了する。ステップＳ６１で、「偽」であると判定された場合には、そのまま処理を終了する。
【００６５】
《実施例２》
次に、本発明に係るマルチプロセッサ装置の具体的な実施例を図面を参照して説明する。
【００６６】
〈システム構成〉
図１０は、本発明の第２の実施例によるマルチプロセッサ装置の構成を示している。
【００６７】
図１０のマルチプロセッサ装置は、端末１Ａ、１Ｂ、１Ｃおよび１Ｄと、疎結合マルチプロセッサシステム６とで構成されている。疎結合マルチプロセッサシステム６は、回線アダプタ７Ａ、７Ｂ、ＩＯ（入出力）バス８およびプロセッサ９Ａ、９Ｂ、９Ｃを有する。
【００６８】
回線アダプタ７Ａは、端末１Ａおよび１Ｂに接続され、回線アダプタ７Ｂは、端末１Ｃおよび１Ｄに接続される。これら回線アダプタ７Ａおよび７Ｂは、ＩＯバス８に接続され、ＩＯバス８には、プロセッサ９Ａ、９Ｂおよび９Ｃが接続される。
【００６９】
各プロセッサ９Ａ、９Ｂ、９Ｃは、それぞれ、アプリケーションプロセス実行部９１Ａ、９１Ｂ、９１Ｃ、通信処理サーバプロセス実行部９２Ａ、９２Ｂ、９２Ｃ、および通信アクセス法プロセス実行部９３Ａ、９３Ｂ、９３Ｃを有する。
前記通信処理サーバプロセス実行部９２Ａ、９２Ｂ、９２Ｃは、アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定される通信識別子からプロセッサ識別番号を取り出すとともに、該プロセッサ識別番号により決定されるプロセッサに対して、当該プロセッサ内の通信処理サーバプロセスで端末への送信処理を実行させるべく送信データを回送する。前記通信識別子は、プロセッサ識別信号とプロセッサ内に記憶される端末管理テーブルにおける配列番号とを含み、マルチプロセッサシステム内で一意的に定義される。
【００７０】
通信処理サーバプロセス実行部９２Ａ、９２Ｂ、９２Ｃは、それぞれ、通信識別子採番部９４Ａ、９４Ｂ、９４Ｃ、通信識別子通知部９５Ａ、９５Ｂ、９５Ｃおよびプロセッサ識別番号取得部９６Ａ、９６Ｂ、９６Ｃを具備している。
【００７１】
通信識別子採番部９４Ａ、９４Ｂ、９４Ｃは、端末のプロセッサとの結合時に、プロセッサ識別信号とプロセッサ内の端末管理テーブルにおける配列番号とを組み合わせて得られるマルチプロセッサシステム内での一意的な番号を通信識別子として採番する。
【００７２】
通信識別子通知部９５Ａ、９５Ｂ、９５Ｃは、アプリケーションプロセスに対して、端末結合の処理結果の通知時に、通信識別子を通知する。
プロセッサ識別番号取得部９６Ａ、９６Ｂ、９６Ｃは、アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定された通信識別子からプロセッサ識別番号を取り出す。
【００７３】
ＩＯバス８は、プロセッサ９Ａ〜９Ｃと回線アダプタ７Ａ、７Ｂとの間のデータの入出力で使用される。
すなわち、図１０に示しているのは、複数のプロセッサ９Ａ、９Ｂ、９Ｃと（ＬＡＮ）回線アダプタ７Ａ、７ＢとをＩＯバス８で疎結合したマルチプロセッサシステム６である。回線アダプタ７Ａ、７Ｂには、任意のプロセッサ９Ａ、９Ｂ、９Ｃからアクセスすることができる。
【００７４】
さらに、各プロセッサ９Ａ、９Ｂ、９Ｃ上に、アプリケーションプロセス実行部９１Ａ、９１Ｂ、９１Ｃ、通信サーバプロセス実行部９２Ａ、９２Ｂ、９２Ｃおよび通信アクセス法プロセス実行部９３Ａ、９３Ｂ、９３Ｃがそれぞれ各対応して設けられる。各アプリケーションプロセスが発生する送受信システムコールは、当該プロセッサ上の通信処理サーバプロセスが受け付ける。そして、端末が結合しているプロセッサの位置に応じて、そのプロセッサ自身が通信アクセス法プロセスを使用して処理するのか、他のプロセッサ上の通信処理サーバプロセスに処理を依頼するのかを決定して分岐処理を行う。
【００７５】
図１０に破線で示すコネクションＰＡ、ＰＣおよびＰＤは、論理的な結合関係の例を示し、このような結合関係は、コネクション、セッションまたは通信パス等と称される。これらコネクションＰＡ、ＰＣおよびＰＤによる各端末１Ａ〜１Ｄと各プロセッサ９Ａ〜９Ｃとの論理的な結合関係は、端末１Ａはプロセッサ９Ａに結合され、端末１Ｂはシステムと未結合であり、端末１Ｃはプロセッサ９Ｃに結合され、端末１Ｄはプロセッサ９Ａに結合されている。
【００７６】
データフローＦ１は、端末１Ａがプロセッサ９Ａと結合した場合の結合時のデータの流れを示し、データフローＦ２は、プロセッサ９Ｂ内のアプリケーションプロセスが、端末１Ｃに対してデータ送信システムコールを実行したときのデータの流れを示す。各プロセッサ９Ａ、９Ｂおよび９Ｃの論理プロセッサ名はそれぞれＰＭ０１、ＰＭ０２およびＰＭ０３とする。
【００７７】
〈通信識別子の採番〉
通信識別子の採番は、図１１および図１２に、発呼による端末結合時のデータフローおよび着呼による端末結合時のデータフローをそれぞれ示すように、アプリケーションプロセスからの発呼要求または端末からアプリケーションプロセスへの着呼通知を契機とした端末結合処理において実行される。
【００７８】
図１３に通信識別子の採番処理のフローチャートを示す。
通信処理サーバプロセスは、通信アクセス法プロセスに結合処理を依頼する前に、自プロセッサ内の端末管理テーブルリストから空きエントリを検索する（ステップＳ７１）。そして、検索が成功したか否かが判定され（ステップＳ７２）、「真」であれば、検索されたエントリの配列番号が取得され（ステップＳ７３）、当該エントリの配列番号と論理プロセッサ名リスト内の自プロセッサの配列番号とを組み合わせた番号を通信識別子として採番した後（ステップＳ７４）、端末管理テーブルに格納して（ステップＳ７５）、処理を終了する。
【００７９】
ステップＳ７２において、「偽」と判定された場合、すなわち端末管理テーブルリストに空きエントリがない場合は、端末管理テーブルリストを拡張し、拡張部の先頭エントリを取得して（ステップＳ７６）、ステップＳ７４の処理を行う。
【００８０】
このようにして採番された通信識別子は、図１１および図１２に示されるように、通信アクセス法に結合依頼する際に、利用者要求識別子として指定される。
〈通信識別子の通知〉
図１１および図１２に示されるように、通前記結合処理の結果は、通信アクセス法プロセスから通信処理サーバプロセスに対して、結合依頼とは非同期に通知される。さらに、通信処理サーバプロセスは、通信識別子と共に結合処理結果をアプリケーションプロセスに通知する。
【００８１】
図１４に通信識別子の通知処理のフローチャートを示す。
通信処理サーバプロセスは、このとき処理結果に付加して通知される通信識別子をキーとして、端末管理テーブルを検索することにより、結合に成功したか否かを判定する（ステップＳ８１）。そして、ステップＳ８１の判定結果が「真」、すなわち結合結果が正常の場合、処理結果データ内通信識別子に、端末管理テーブル内の通信識別子を格納して（ステップＳ８２）、アプリケーションプロセスに、通信識別子とともに処理結果データを通知することにより（ステップＳ８３）、処理が正常に完了したことを通知して処理を終了する。ステップＳ８１で、「偽」と判定された場合、すなわち異常の場合、処理結果データ内通信識別子を無効化するため、端末管理テーブル内の通信識別子をゼロクリアし（ステップＳ８４）、端末管理テーブルをリストから削除して（ステップＳ８５）、アプリケーションプロセスに、エラーの原因を付加して処理結果データを通知することにより（ステップＳ８３）、処理が異常終了したことを通知して処理を終了する。
【００８２】
〈プロセッサ識別番号の取得〉
図１５にデータ送信時のデータフローを示すように、アプリケーションプロセスは、送信システムコール実行時に、結合端末に対応する通信識別子を指定し、論理プロセッサ識別番号を取得する。
【００８３】
図１６に論理プロセッサ識別番号の取得処理のフローチャートを示す。
当該送信要求を受け付けた通信処理サーバプロセスは、指定された通信識別子のプロセッサ識別番号の有効性をチェックする（ステップＳ９１）。そして、ステップＳ９１が「真」、すなわち通信識別子の論理プロセッサ識別番号が正常である時は、通信識別子内のプロセッサ識別番号からプロセッサの位置を決定する。このとき、プロセッサ識別番号は自プロセッサの値に等しいか否かを調べ（ステップＳ９２）、「真」、すなわち当該プロセッサがそのプロセッサ自体である場合は、通信アクセス法プロセスに送信依頼して（ステップＳ９３）、処理を終了する。また、ステップＳ９２が「偽」、つまり当該プロセッサが他プロセッサである場合、他プロセッサ内の通信処理サーバプロセスに対して、送信データを回送することで送信処理を依頼し（ステップＳ９４）、処理を終了する。ステップＳ９１で「偽」、すなわちプロセッサ識別番号が無効である時はアプリケーションプロセスにその旨を通知して（ステップＳ９５）、処理を終了する。
【００８４】
図１７は、論理プロセッサ名リスト、プロセッサ９Ａ、９Ｃの端末管理テーブルリストおよび端末１Ａ、１Ｃ、１Ｄの管理テーブルの関係を模式的に示している。
【００８５】
論理プロセッサ名リストは、それぞれ論理プロセッサ名、物理的なプロセッサの識別情報およびその他の管理情報が格納された複数の配列からなり、図１７においては、配列０が未使用状態、配列１には、論理プロセッサ名としてＰＭ０１、物理的なプロセッサの識別情報としてプロセッサ９Ａを示す情報が格納され、配列２には、論理プロセッサ名としてＰＭ０２、物理的なプロセッサの識別情報としてプロセッサ９Ｂを示す情報が格納され、配列３には、論理プロセッサ名としてＰＭ０３、物理的なプロセッサの識別情報としてプロセッサ９Ｃを示す情報が格納されている。
【００８６】
プロセッサ９Ａの端末管理テーブルリストは、配列０、３および４が未使用であり、配列１には端末１Ａの管理テーブルが格納され、配列２には端末１Ｄの管理テーブルが格納されている。端末１Ａの管理テーブルには、通信識別子「０１０００００１」と他の管理情報とが格納されている。通信識別子「０１ ０００００１」の「０１」は論理プロセッサ名リストの配列番号であり、「０００００１」は端末管理テーブルリストの配列番号である。端末１Ｄの管理テーブルには、通信識別子「０１ ０００００２」と他の管理情報とが格納されている。通信識別子「０１ ０００００２」の「０１」は論理プロセッサ名リストの配列番号であり、「０００００２」は端末管理テーブルリストの配列番号である。
【００８７】
プロセッサ９Ｃの端末管理テーブルリストは、配列０、２〜４が未使用であり、配列１には端末１Ｃの管理テーブルが格納されている。端末１Ｃの管理テーブルには、通信識別子「０３ ０００００１」と他の管理情報とが格納されている。通信識別子「０３ ０００００１」の「０３」は論理プロセッサ名リストの配列番号であり、「０００００１」は端末管理テーブルリストの配列番号である。
【００８８】
〈プロセッサで異常発生時の端末の引き継ぎ〉
このようなシステムでは、あるプロセッサで異常が発生したときのバックアップを有効に行うことができる。
【００８９】
すなわち、上述した疎結合マルチプロセッサシステム６は、１個のプロセッサに待機属性を、残りのプロセッサに現用属性を付与し、待機プロセッサは現用プロセッサの障害時にバックアップ用として動作するようにし、各プロセッサには所定の論理プロセッサ名を付与し、待機プロセッサが障害現用プロセッサをバックアップする際に現用プロセッサの論理プロセッサ名を引き継ぐとともに、プロセッサ識別番号として論理プロセッサ名リストの配列番号を割り当てることにより、待機プロセッサが現用プロセッサに結合していた端末を引き継いだ後でも、端末と通信識別子との関係を不変とすることができる。
【００９０】
あるプロセッサで異常が発生した場合、アダプタ内のプロセスとバックアッププロセッサ内の通信アクセス法プロセスとの間の論理的関係を引き継ぐ。さらに、通信アクセス法プロセスと通信処理サーバプロセスとの間の論理的関係も引き継ぐ。これにより、端末を異常が発生したプロセッサからバックアッププロセッサに引き継ぐ。
【００９１】
ここで、あるプロセッサで異常が発生したことを認識した通信処理サーバプロセスは、異常終了したプロセッサの論理プロセッサ名に対応するエントリとバックアップとを対応付ける。そして、それまでバックアッププロセッサに付与されていた論理プロセッサ名に対応するエントリは、当該プロセッサを閉塞状態として管理する。これにより、論理プロセッサ名対応の配列番号は不変となるので、論理プロセッサ名と当該論理プロセッサに結合した端末との関係は不変となり、アプリケーションプロセッサは、論理プロセッサを意識して処理を組むことで、あるプロセッサで異常が発生しても、処理を継続して行うことができる。
【００９２】
この場合の、プロセッサ９Ａに障害が発生した場合の具体的な処理の一例を、図１８〜図２２を参照して説明する。
プロセッサ９Ａに障害が発生する前の状態では、図１８に示すように、端末１ＡはコネクションＰＡを介してプロセッサ９Ａに接続され、端末１ＤはコネクションＰＤを介して同様にプロセッサ９Ａに接続されている。
【００９３】
このときの論理プロセッサ名リストは、図２０に示すように、それぞれ論理プロセッサ名、物理的なプロセッサの識別情報、プロセッサの状態、現用待機属性およびその他の管理情報が格納された複数の配列からなる。すなわち、ここでは、管理情報として、プロセッサの状態および現用待機属性が図１７の例に追加されている。図２０においては、配列０が未使用状態であり、配列１には、論理プロセッサ名としてＰＭ０１、物理的なプロセッサの識別情報としてプロセッサ９Ａ、プロセッサの状態として活性状態、現用待機属性として現用を示す情報がそれぞれ格納されている。同様に配列２には、論理プロセッサ名としてＰＭ０２、物理的なプロセッサの識別情報としてプロセッサ９Ｂ、プロセッサの状態として活性状態、現用待機属性として現用を示すを示す情報が格納され、配列３には、論理プロセッサ名としてＰＭ０３、物理的なプロセッサの識別情報としてプロセッサ９Ｃ、プロセッサの状態として活性状態、現用待機属性として待機を示すを示す情報が格納されている。すなわち、この場合は、プロセッサ９Ｃがバックアップに用いられる待機プロセッサとなっている。
【００９４】
この状態でプロセッサ９Ａに障害が発生すると、図２１に示すように、配列１に格納される情報が、論理プロセッサ名としてＰＭ０１、物理的なプロセッサの識別情報としてプロセッサ９Ｃ、プロセッサの状態として活性状態、現用待機属性として現用を示す情報に変更される。配列２は、論理プロセッサ名としてＰＭ０２、物理的なプロセッサの識別情報としてプロセッサ９Ｂ、プロセッサの状態として活性状態、現用待機属性として現用を示すを示す情報が格納されたままであり、配列３は、論理プロセッサ名としてＰＭ０３、物理的なプロセッサの識別情報はなし、プロセッサの状態として閉塞状態、現用待機属性もなしの状態に変わる。
【００９５】
このことにより、障害の発生したプロセッサ９Ａの論理プロセッサ番号はプロセッサ９Ｃに引き継がれて、図１９に示すように、障害の発生したプロセッサ９Ａの機能はプロセッサ９Ｃが肩代わりすることになり、端末１ＡはコネクションＰＡを介してプロセッサ９Ｃに接続され、端末１ＤはコネクションＰＤを介してプロセッサ９Ｃに接続される。このときプロセッサ９Ａは、障害発生状態にあるが、ソフトウェア障害の場合には再ＩＰＬを実施して、プロセッサの再立ち上げを行い、プロセッサを復旧する。ハードウェア障害のときは、オペレータにプロセッサモジュールの交換等を促し、障害復旧を行う。
【００９６】
このようにしてプロセッサ９Ａの障害が復旧されると、図２２に示されるように、配列３は、論理プロセッサ名としてＰＭ０３、物理的なプロセッサの識別情報としてプロセッサ９Ａ、プロセッサの状態として活性状態、現用待機属性として待機を示すを示す情報が格納された状態となり、プロセッサ９Ａが次のバックアップ用待機プロセッサとして待機状態となる。
【００９７】
なお、アプリケーションプロセスが、システムに結合した端末に対するデータ送信用のシステムコールを実行する場合、当該結合端末に対応する通信識別子を指定する必要がある。ところで、当該通信識別子は、結合処理を実行したアプリケーションプロセスにのみ通知される。したがって、他のアプリケーションプロセス、特に端末が結合していないＰＭ内のアプリケーションプロセスは、何らかの方法で通信識別子を取得する必要がある。この場合の通信識別子を取得するには種々の方法があるが、例えば結合処理を実行したアプリケーションプロセスが、全プロセスに対して通信識別子をブロードキャストすればよい。この場合、端末切断時にも、通信識別子を無効化するためにブロードキャストが必要である。
【００９８】
従来の疎結合マルチプロセッサシステムにおいては、システムジェネレーション時に、システムに結合する端末とプロセッサとの関係を定義したテーブルを作成していた。そして、システム始動時に当該テーブルを各プロセッサの主記憶装置にロードし、アプリケーションプロセスが発行した送信システムコール処理時に、前記ロード情報を参照することによりプロセッサを決定していた。そのため、例えばプロセッサの負荷分散の目的などから、端末が結合するプロセッサを動的に変更することはできなかった。
【００９９】
また、端末が結合するプロセッサを動的に変更するように構成された疎結合マルチプロセッサシステムも従来より存在した。但し、この場合、プロセッサに結合した端末との送受信処理が可能なアプリケーションプロセスは、当該プロセッサ上で動作するものに限られていた。
【０１００】
疎結合マルチプロセッサシステムにおける端末利用を実現する上で、端末結合処理の性能とデータ送受信処理の性能とを同時に高めることはできない。
したがって、業務の運用に応じたトレードオフが必要となる。問題は、この二者択一をシステムが行うのかユーザが行うのかという点である。
【０１０１】
まず、システムが二者択一を行う方法としては、端末の運用定義による方法や、結合時にアプリケーションプロセスがパラメータで指定する方法などがある。しかし、システムプログラムの処理論理が複雑になるという点およびシステムプログラムが２本立てとなり煩雑であるという点で現実的ではない。
【０１０２】
他方、ユーザが二者択一する場合、自身の業務の運用に合わせていずれかを選択するだけであるから問題は少ない。
以上述べたように、システムがユーザの業務の運用上の要件を満たしつつ端末共用を実現することは困難である。
【０１０３】
さらに、端末が結合したプロセッサで障害発生時に、当該端末をバックアッププロセッサに引き継ぎ、なおかつ、各プロセッサから引き継いだ端末を共用できる機能は従来存在しなかった。
【０１０４】
しかしながら、疎結合マルチプロセッサシステムにおいて、端末がシステムと結合する場合、結合するプロセッサの決定論理は、ジェネレーション時に定義する手法や、運用時の各プロセッサの負荷状況に応じて選択する手法など、複数の手法を組み合わせて利用できることが、業務設計の柔軟性を向上させる上で望ましい。
【０１０５】
同じく、業務設計の柔軟性の向上の観点からいって、システムに結合した端末を、システムを構成する各プロセッサ内のアプリケーションプロセスから共用できるようにすることが望ましい。
【０１０６】
さらに、フォルトトレラントコンピュータとして疎結合マルチプロセッサシステムを利用する場合、結合端末を障害プロセッサからバックアッププロセッサに引き継ぐ前と後で、アプリケーションプロセスが実行する送受信システムコールのインタフェースが不変であることが望ましい。
【０１０７】
従来のマルチプロセッサシステムで、上述の要件を全て満足するものは存在しなかったが、上述の本発明の第２の実施例のマルチプロセッサ装置によれば、これらの要望を全て満たすことができるようになる。
【０１０８】
したがって、この実施例のマルチプロセッサ装置では、前述のように通信識別子を構造化し、システムコール時にアプリケーションプロセスが、結合端末対応に指定する通信識別子からプロセッサ識別番号を取り出すことで、端末が結合しているプロセッサの特定が可能となる。さらに、プロセッサ番号として、論理プロセッサ名リスト内の配列番号を割り当てていることにより、プロセッサで異常が発生し、端末をバックアッププロセッサに引き継いだ際にも、送信システムコールのインタフェースの普遍性が保証される。
【０１０９】
さらに、このように構成した、マルチプロセッサシステムを、先に述べた本発明の第１の実施例のネットワーク装置におけるＦＥＰシステムとして用いることができる。
【０１１０】
この場合、具体的には例えば図３に示すＦＥＰシステム３を図１０に示される疎結合マルチプロセッサシステム６で構成することになり、第１の実施例のネットワーク装置を一層有効に構成することができる。
【０１１１】
【発明の効果】
以上説明したように、本発明によれば、通信処理アプリケーションを組み込んだＦＥＰシステムを１組または複数個のホストに結合するとともに、業務実行時に、複数個の端末からネットワーク内のノードへの接続をする場合、常にＦＥＰシステムにダイアリングするだけで、ＦＥＰシステムからその時点で有効なネットワークノードに対して接続要求を振り分け、端末を有効なノードに接続するようにして、端末からダイアリングした際に、前記端末が接続される交換網とホストプロセッサが結合されるネットワークとの間で、システムの運用状況に応じて、柔軟に且つ適切に宛先管理、故障対処および業務処理を行うことを可能とするネットワーク装置を提供することができる。
【０１１２】
さらに、本発明によれば、通信処理サーバプロセスにより、端末結合時に、プロセッサ識別番号と端末管理テーブル内の配列番号の２つの情報を組み合わせたものとして構造化した通信識別子を動的に割り当て、当該マルチプロセッサシステム内で一意的に定義されるこの通信識別子をアプリケーションプロセスに通知し、該アプリケーションプロセスによる結合端末に対する送信システムコール時に、結合端末毎に対応して指定した通信識別子に基づいてプロセッサを決定し、当該プロセッサに送信データを回送するようにして、各プロセッサ内のアプリケーションプロセスからデータ送受信処理を行うことができるとともに、端末を結合するプロセッサを動的に変更可能として、前記各プロセッサ内のアプリケーションプロセスから端末を共用することができ、常時運用を可能として、前記ネットワーク装置における宛先管理、故障対処および業務処理に好適に使用することができるマルチプロセッサ装置を提供することができる。
【図面の簡単な説明】
【図１】本発明に係るネットワーク装置の構成を示す原理図である。
【図２】本発明に係るマルチプロセッサ装置の構成を示す原理図である。
【図３】本発明の実施例１に係るネットワーク装置の構成を示すブロック図である。
【図４】図３のネットワーク装置の要部の構成を詳細に示すブロック図である。
【図５】図４のネットワーク装置の接続ノード管理部の動作を説明するためのフローチャートである。
【図６】図４のネットワーク装置の宛先ノード名参照部の動作を説明するためのフローチャートである。
【図７】図４のネットワーク装置の宛先ノード名変更部の動作を説明するためのフローチャートである。
【図８】図４のネットワーク装置の接続処理実行部の動作を説明するためのフローチャートである。
【図９】図４のネットワーク装置の運用情報取得部の動作を説明するためのフローチャートである。
【図１０】本発明の実施例２に係るマルチプロセッサ装置の構成を示すブロック図である。
【図１１】図１０のマルチプロセッサ装置の動作を模式的に説明するための発呼による端末結合時のデータフロー図である。
【図１２】図１０のマルチプロセッサ装置の動作を模式的に説明するための着呼による端末結合時のデータフロー図である。
【図１３】図１０のマルチプロセッサ装置の通信識別子の採番処理の動作を説明するためのフローチャートである。
【図１４】図１０のマルチプロセッサ装置の通信識別子の通知処理の動作を説明するためのフローチャートである。
【図１５】図１０のマルチプロセッサ装置の動作を模式的に説明するためのデータ送信時のデータフロー図である。
【図１６】図１０のマルチプロセッサ装置の論理プロセッサ識別番号取得処理の動作を説明するためのフローチャートである。
【図１７】図１０のマルチプロセッサ装置に用いられるテーブルを模式的に説明するための図である。
【図１８】図１０のマルチプロセッサ装置のプロセッサ障害発生時の動作を説明するための模式図である。
【図１９】図１０のマルチプロセッサ装置のプロセッサ障害バックアップ時の動作を説明するための模式図である。
【図２０】図１０のマルチプロセッサ装置のプロセッサ障害発生時の動作を説明するための障害発生前の論理プロセッサ名リストの模式図である。
【図２１】図１０のマルチプロセッサ装置のプロセッサ障害発生時の動作を説明するための障害発生時の論理プロセッサ名リストの模式図である。
【図２２】図１０のマルチプロセッサ装置のプロセッサ障害発生時の動作を説明するための障害復旧時の論理プロセッサ名リストの模式図である。
【符号の説明】
１Ａ，１Ｂ，１Ｃ，１Ｄ…端末
２…交換網
３…フロントエンドプロセッサ（ＦＥＰ）システム
４…ネットワーク
５，５Ａ，５Ｂ…ホスト（プロセッサ）
６…疎結合マルチプロセッサシステム
７Ａ，７Ｂ…回線アダプタ
８…入出力（ＩＯ）バス
９Ａ，９Ｂ，９Ｃ…プロセッサ
３１，５１…通信処理アプリケーション実行部
３２，５２…通信処理サーバ部
３３，５３…通信アクセス法処理部
３４…ノード管理テーブル
３５…運用情報取得部
３６…宛先ノード名参照部
３７…宛先ノード名変更部
３８…接続ノード管理部
３９…接続処理実行部
９１Ａ，９１Ｂ，９１Ｃ…アプリケーションプロセス実行部
９２Ａ，９２Ｂ，９２Ｃ…通信処理サーバプロセス実行部
９３Ａ，９３Ｂ，９３Ｃ…通信アクセス法プロセス実行部
【産業上の利用分野】
本発明は、交換網経由の端末からダイアリングを行ってネットワーク内のノードと接続して業務を行う運用形態において、端末側では、接続するノードの宛先を意識することなく、システムが運用情報に基づいて動的に宛先を切替えることを可能とするネットワーク装置、およびアプリケーションプロセスに対して、システムに結合した端末とのデータ送受信機能を提供する疎結合マルチプロセッサシステムにおいて、各プロセッサ内のアプリケーションプロセスからのデータ送受信処理を可能とするマルチプロセッサ装置に関する。
【０００２】
【従来の技術】
従来のネットワーク装置においては、交換網経由の端末からダイアリングを行ってネットワーク内のノードと接続する場合、端末の結合宛先が、定義により固定的に決められているか、または、次のいずれかの方法を用いて端末の結合宛先を切替えるかしていた。
【０００３】
（ａ） 端末オペレータが、運用スケジュールを意識して、ネットワーク内の所定の結合ノードに対してダイアリングする。
（ｂ） 端末の内部に、所定の運用スケジュールに基づいて接続する宛先を切替えてダイアリングするようなプログラムを組み込むことによって、宛先を動的に切替える。
【０００４】
【発明が解決しようとする課題】
上述したように、交換網経由で接続された端末からダイアリングして、接続ノードを切り替える業務の運用においては、前記（ａ） の方法では、端末オペレータが、運用スケジュールを意識してダイアリングする必要があった。このような方法では、運用スケジュールが複雑になった場合、端末オペレータの負担が重くなるという欠点がある。
【０００５】
また、前記（ｂ） の方法では、端末内に宛先切り替え用のプログラムを組み込む必要があった。この場合、業務の運用で使用する全ての交換網経由の端末内に、宛先切り替え用のプログラムを組み込まなければならないため、運用スケジュールの変更・変化に対処する場合、コストがかさむという弊害がある。
【０００６】
そこで、本発明では、端末からダイアリングした際に、前記端末が接続される交換網とホストプロセッサが結合されるネットワークとの間で、システムの運用状況に応じて、柔軟に且つ適切に宛先管理、故障対処および業務処理を行うことを可能とするネットワーク装置を提供することを目的としている。
【０００８】
【課題を解決するための手段】
本発明は、上記目的を達成するために、ネットワークを介して１個以上のホストプロセッサ（以下、「ホスト」と称する）に結合され且つ交換網経由で複数個の端末に接続されるフロントエンドプロセッサシステム（以下、「ＦＥＰシステム」と称する）を設け、該ＦＥＰシステムにより、前記端末からのダイアリングに対し当該端末を接続するホストプロセッサおよびそのホストプロセッサ内のネットワークノードの管理および接続の実行、前記通信処理アプリケーション実行手段により実行される通信処理アプリケーションによる指定された端末に対応して接続宛先名として登録されているネットワークノードの参照、および該通信処理アプリケーションによる指定端末の接続宛先名の変更更新を行って、通信処理アプリケーションおよび通信アクセス法の処理を実行することにより、端末からダイアリングした際に、前記端末が接続される交換網とホストが結合されるネットワークとの間で、システムの運用状況に応じて、柔軟に且つ適切に宛先管理、故障対処および業務処理を行うことが可能なネットワーク装置とした。
【０００９】
図１は、本発明によるネットワークシステムの原理構成を示している。図１に示すシステムは、端末１Ａ、１Ｂ、交換網２、ＦＥＰシステム３、回線／ネットワーク４およびホスト５を有している。
【００１０】
端末１Ａおよび１Ｂは、ユーザすなわちオペレータにより操作される複数の端末であり、この図１では、２個の端末１Ａおよび１Ｂが図示されている。
交換網２は、複数の端末１Ａおよび１ＢをＦＥＰシステム３に接続する。
【００１１】
ＦＥＰシステム３は、回線／ネットワーク４を介してホスト５に結合されている。図１では、１個のホスト５のみが示されているが、ホスト５は複数個設けられていてもよい。
【００１２】
ホスト５は、通信処理アプリケーションを実行するための通信処理アプリケーション実行部５１、通信処理サーバを実行するための通信処理サーバ部５２および通信アクセス法の処理を実行するための通信アクセス法処理部５３を有している。通常、ＦＥＰシステム３の通信処理アプリケーション実行部３１は、そのパフォーマンスについてはホスト５の通信処理アプリケーション実行部５１よりも小規模でよい。
【００１３】
ＦＥＰシステム３も、通信処理アプリケーションを実行するための通信処理アプリケーション実行部３１、通信処理サーバを実行するための通信処理サーバ部３２および通信アクセス法の処理を実行するための通信アクセス法処理部３３を有している。通常、ＦＥＰシステム３の通信処理アプリケーション実行部３１は、パフォーマンスについてはホスト５の通信処理アプリケーション実行部５１よりも小規模でよい。
【００１４】
ＦＥＰシステム３は、前記端末１Ａ、１Ｂからのダイアリングに対し当該端末を接続するプロセッサおよびネットワークノードの管理および接続の実行、前記通信処理アプリケーション実行部３１により実行される通信処理アプリケーションによる指定された端末に対応して接続宛先名として登録されているネットワークノードの参照、および該通信処理アプリケーションによる指定端末の接続宛先名の変更更新を行うことができる。
【００１５】
なお、ＦＥＰシステム３は、接続ノード管理部、宛先名参照部、宛先名変更部、接続処理実行部および運用情報取得部を有していてもよい。この場合、典型的には、前記宛先名参照部、宛先名変更部および運用情報取得部は、通信処理アプリケーション実行部３１に設けられ、前記接続ノード管理部および接続処理実行部は、通信アクセス法処理部３３に設けられる。そして、通信処理アプリケーション実行部３１と通信アクセス法処理部３３とは、通信処理サーバ部３２を介して結合される。
【００１６】
前記接続ノード管理部は、端末単位に、当該端末をどのプロセッサの、どのネットワークノードに接続するかを示すノード管理テーブルを保持し、前記端末からＦＥＰシステムにダイアリングした際に、当該端末をどのプロセッサの、どのネットワークノードに接続するかを管理する。
【００１７】
前記宛先名参照部は、ＦＥＰシステム内で動作する通信処理アプリケーションが、端末名を指定して宛先名参照のシステムコールを発生した際に、前記ノード管理テーブルにおいて指定端末の接続宛先名として登録されているネットワークノード名を前記通信処理アプリケーションに通知する。
【００１８】
前記宛先名変更部は、前記通信処理アプリケーションが、端末名とネットワークノード名を指定して宛先名変更のシステムコールを発生した際に、前記ノード管理テーブルにおける指定端末の接続宛先名を、指定ネットワークノード名に更新する。
【００１９】
前記接続処理実行部は、端末からＦＥＰシステムにダイアリングした際に、前記接続ノード管理テーブルを参照して接続ネットワークノードを決定し当該ノードに接続要求を伝達する。
【００２０】
前記運用情報取得部は、前記通信処理アプリケーションが、端末の接続宛先名を変更するために利用する運用情報を取得する。
さらに、前記運用情報取得部は、ホストの運用スケジュールを参照し、且つ前記接続ノード管理部は、該当ホストの前記運用スケジュールに基づき、ホスト稼働時には端末の接続ノードを該当ホスト内のネットワークノードとし、ホスト停止時には前記該当ホストを代行し得る他のホスト内のネットワークノードとして宛先を変更するようにしてもよい。
【００２１】
また、前記運用情報取得部は、ホストの運用スケジュールを参照し、且つ前記接続ノード管理部は、該当ホストの前記運用スケジュールに基づき、ホスト稼働時には端末の接続ノードを該当ホスト内のネットワークノードとし、ホスト停止時にはそのＦＥＰシステム内で実行される通信処理アプリケーションを前記端末に接続されるネットワークノードとして宛先を変更するようにしてもよい。
【００２２】
前記運用情報取得部は、そのＦＥＰシステム内で動作する通信処理アプリケーションが、ホスト内で動作する通信処理アプリケーションと相互に通信を行うことにより運用スケジュールを決定するようにしてもよい。
【００２３】
アプリケーションプロセス部、通信処理サーバプロセス部、および通信アクセス法プロセス部を有するマルチプロセッサが入出力バスに複数個並列的に結合される疎結合マルチプロセッサシステムにおいて、前記通信処理サーバプロセス部が、前記アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定される、プロセッサ識別信号とプロセッサ内に記憶される端末管理テーブルにおける配列番号とを含むマルチプロセッサシステム内で一意的な、通信識別子からプロセッサ識別番号を取り出すとともに、該プロセッサ識別番号により決定されるプロセッサに対して、当該プロセッサ内の通信処理サーバプロセスで端末への送信処理を実行させるべく送信データを回送するようにすることにより、各プロセッサ内のアプリケーションプロセスからデータ送受信処理を行うことができるとともに、端末を結合するプロセッサを動的に変更可能として、前記各プロセッサ内のアプリケーションプロセスから端末を共用することができ、常時運用を可能とするマルチプロセッサ装置を、先に述べたネットワーク装置におけるＦＥＰシステムとして用いてもよい。
【００２４】
図２は、本発明によるマルチプロセッサシステムの原理構成を示している。図２に示すシステムは、端末１Ａ、１Ｂ、１Ｃおよび１Ｄと、疎結合マルチプロセッサシステム６とで構成されている。疎結合マルチプロセッサシステム６は、プロセッサ９Ａ、９Ｂおよび９Ｃを有し、これら各プロセッサ９Ａ、９Ｂ、９Ｃは、それぞれ、アプリケーションプロセス実行部、通信処理サーバプロセス実行部、および通信アクセス法プロセス実行部を有する。前記端末１Ａ、１Ｂ、１Ｃおよび１Ｄは、交換網２を介してプロセッサ９Ａ、９Ｂおよび９Ｃに接続されている。
【００２５】
前記通信処理サーバプロセス実行部は、アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定される通信識別子からプロセッサ識別番号を取り出すとともに、該プロセッサ識別番号により決定されるプロセッサに対して、当該プロセッサ内の通信処理サーバプロセスで端末への送信処理を実行させるべく送信データを回送する。前記通信識別子は、プロセッサ識別信号とプロセッサ内に記憶される端末管理テーブルにおける配列番号とを含んでマルチプロセッサシステム内で一意的に定義される。
【００２６】
通信処理サーバプロセス実行部は、通信識別子採番部、通信識別子通知部およびプロセッサ識別番号取得部を具備していてもよい。前記通信識別子採番部は、端末のプロセッサとの結合時に、プロセッサ識別信号とプロセッサ内の端末管理テーブルにおける配列番号とを組み合わせて得られるマルチプロセッサシステム内での一意的な番号を通信識別子として採番する。前記通信識別子通知部は、アプリケーションプロセスに対して、端末結合の処理結果の通知時に、通信識別子を通知する。前記プロセッサ識別番号取得部は、アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定された通信識別子からプロセッサ識別番号を取り出す。
【００２７】
また、前記疎結合マルチプロセッサシステム６は、１個のプロセッサに待機属性を、残りのプロセッサに現用属性を付与し、待機プロセッサは現用プロセッサの障害時にバックアップ用として動作するようにし、各プロセッサには所定の論理プロセッサ名を付与し、待機プロセッサが障害現用プロセッサをバックアップする際に現用プロセッサの論理プロセッサ名を引き継ぐとともに、プロセッサ識別番号として論理プロセッサ名リストの配列番号を割り当てることにより、待機プロセッサが現用プロセッサに結合していた端末を引き継いだ後でも、端末と通信識別子との関係を不変とするようにしてもよい。
【００２９】
【作用】
本発明によるネットワークシステムでは、通信処理アプリケーションを組み込んだＦＥＰシステム３を１組または複数個のホスト５に結合するとともに、業務実行時に、端末１Ａ、１Ｂからネットワーク内のノードへの接続をする場合、常にＦＥＰシステム３にダイアリングするだけで、ＦＥＰシステム３からその時点で有効なネットワークノードに対して接続要求を振り分け、端末１Ａ、１Ｂを有効なノードに接続する。
【００３０】
本発明によるマルチプロセッサシステム６では、通信処理サーバプロセスにより、端末結合時に、プロセッサ識別番号と端末管理テーブル内の配列番号の２つの情報を組み合わせたものとして構造化した通信識別子を動的に割り当て、当該マルチプロセッサシステム内で一意的に定義されるこの通信識別子をアプリケーションプロセスに通知し、該アプリケーションプロセスによる結合端末に対する送信システムコール時に、結合端末毎に対応して指定した通信識別子に基づいてプロセッサを決定し、当該プロセッサに送信データを回送することにより、送信処理を実行するので、プロセッサで異常が発生し、端末をバックアッププロセッサに引き継いだ際にも、送信システムコールのインタフェースの普遍性が保証される。
【００３１】
【実施例】
《実施例１》
次に、本発明に係るネットワーク装置の具体的な実施例を図面を参照して説明する。
【００３２】
図３は、本発明の第１の実施例によるネットワーク装置の構成を示している。図３のネットワーク装置は、端末１Ａ、１Ｂ…、交換網２、ＦＥＰシステム３、回線／ネットワーク４、ホスト５Ａ…を有している。
【００３３】
端末１Ａ、１Ｂ…は、交換網２を介してＦＥＰシステム３に接続される。
ＦＥＰシステム３は、高速ＬＡＮ（ローカルエリアネットワーク）回線またはネットワーク回線により構成される回線／ネットワーク４を介して１個以上のホスト５Ａ…に結合されている。
【００３４】
ホスト５Ａ…は、各々通信処理アプリケーションを実行するための通信処理アプリケーション実行部５１、通信処理サーバ処理を実行するための通信処理サーバ部５２および通信アクセス法の処理を実行するための通信アクセス法処理部５３を有している。
【００３５】
ＦＥＰシステム３も、通信処理アプリケーションを実行するための通信処理アプリケーション実行部３１、通信処理サーバ処理を実行するための通信処理サーバ部３２および通信アクセス法の処理を実行するための通信アクセス法処理部３３を有している。通常、ＦＥＰシステム３の通信処理アプリケーション実行部３１は、パフォーマンスについてはホスト５の通信処理アプリケーション実行部５１よりも小規模でよい。
【００３６】
通信アクセス法処理部３３は、ノード管理テーブル３４を保持している。ノード管理テーブル３４は、端末毎に、端末名、端末ネットワークアドレス、定義指定ノード名（とその有効フラグ）、およびアプリケーション指定ノード名（とその有効フラグ）が登録される。
【００３７】
ＦＥＰシステム３は、前記端末１Ａ、１Ｂ…からのダイアリングに対し当該端末を接続するプロセッサおよびネットワークノードの管理および接続の実行、前記通信処理アプリケーション実行部３１により実行される通信処理アプリケーションによる指定された端末に対応して接続宛先名として登録されているネットワークノードの参照、および該通信処理アプリケーションによる指定端末の接続宛先名の変更更新を行うことができる。
【００３８】
この図３の実施例における主としてＦＥＰシステム３部分を図４にさらに詳細に示す。図４においては、ホスト５Ａ、５Ｂ、および端末１Ａ、１Ｂ、１Ｃが示されている。
【００３９】
図４に示すように、ＦＥＰシステム３の通信処理アプリケーション実行部３１は、運用情報取得部３５、宛先ノード名参照部３６および宛先ノード名変更部３７を有しており、ＦＥＰシステム３の通信アクセス法処理部３３は、ノード管理テーブル３４を保持するとともに、接続ノード管理部３８および接続処理実行部３９を有している。
【００４０】
運用情報取得部３５は、前記通信処理アプリケーションが、端末１Ａ…の接続宛先名を変更するために利用する運用情報（各ホストの運用スケジュール）を取得する。このとき、運用情報取得部３５は、ホスト５Ａ…の運用スケジュールを参照することで取得しても良いし、そのＦＥＰシステム内で動作する通信処理アプリケーションがホスト内で動作する通信処理アプリケーションと相互に通信を行うことにより運用スケジュールを決定し取得しても良い。宛先ノード名参照部３６は、ＦＥＰシステム３内で動作する通信処理アプリケーションが、端末名を指定して宛先名参照のシステムコールを発生した際に、ノード管理テーブル３４において指定端末の接続宛先名として登録されているネットワークノード名を前記通信処理アプリケーションに通知する。
【００４１】
宛先ノード名変更部３７は、前記通信処理アプリケーションが、端末名とネットワークノード名を指定して宛先名変更のシステムコールを発生した際に、ノード管理テーブル３４における指定端末の接続宛先名を、指定ネットワークノード名に更新する。
【００４２】
接続ノード管理部３８は、端末単位に、当該端末をどのプロセッサの、どのネットワークノードに接続するかを示すノード管理テーブル３４を用い、前記端末１Ａ…からＦＥＰシステム３にダイアリングした際に、当該端末をどのプロセッサの、どのネットワークノードに接続するかを管理する。
【００４３】
接続処理実行部３９は、端末１Ａ…からＦＥＰシステム３にダイアリングした際に、ノード管理テーブル３４を参照して接続ネットワークノードを決定し当該ノードに接続要求を伝達する。
【００４４】
なお、前記運用情報取得部３５は、ホスト５Ａ…の運用スケジュールを参照し、且つ前記接続ノード管理部３８は、該当ホスト５Ａ…の前記運用スケジュールに基づき、ホスト稼働時には端末の接続ノードを該当ホスト５Ａ…内のネットワークノードとし、ホスト停止時には前記該当ホスト５Ａ…を代行し得る他のホスト内のネットワークノードとして宛先を変更するようにしてもよい。
【００４５】
また、前記運用情報取得部３５は、ホスト５Ａ…の運用スケジュールを参照し、且つ前記接続ノード管理部３８は、該当ホスト５Ａ…の前記運用スケジュールに基づき、ホスト稼働時には端末の接続ノードを該当ホスト５Ａ…内のネットワークノードとし、ホスト停止時にはそのＦＥＰシステム３内で実行される通信処理アプリケーションを前記端末に接続されるネットワークノードとして宛先を変更するようにしてもよい。
【００４６】
さらに、前記運用情報取得部３５は、そのＦＥＰシステム内で動作する通信処理アプリケーションが、ホスト内で動作する通信処理アプリケーションと相互に通信を行うことにより運用スケジュールを決定するようにしてもよい。
【００４７】
図３および図４において、先に述べたように、ホスト５Ａ…とＦＥＰシステム３は、例えば高速ＬＡＮ回線からなる回線／ネットワーク４で接続されている。端末１Ａ…は、ＦＥＰシステム３と交換網２経由で接続され、ホスト５Ａ…に例えばファイル転送を行う。
【００４８】
また、ＦＥＰシステム３の通信処理アプリケーション実行部３１で実行される通信処理アプリケーションは、ホスト５Ａ…で実行される通信処理アプリケーションとの間で通信して、ホストマシンの稼働状況を取得する。
【００４９】
ＦＥＰシステム３内で動作する通信アクセス法処理部３３は、端末単位で接続ノード名を記述したネットワーク定義を展開し、ノード管理テーブル３４としてＦＥＰシステム３の主記憶域内に保持する。このノード管理テーブル３４には、ネットワーク定義で指定されたノード名と通信処理アプリケーションが指定するノード名との２つの宛先を管理する。通信処理アプリケーションがノード名の変更要求を出していない場合、端末１Ａ…からのダイアリング時には、ノード管理テーブル３４に格納されたネットワーク定義で指定されたノードに振り分けられる。
【００５０】
これに対して、通信処理アプリケーションがノード名の変更要求を発行している場合には、この名前をノード管理テーブル３４内の、通信処理アプリケーション指定欄に反映しておく。そして、端末１Ａ…からのダイアリング時には、ノード管理テーブル３４内に通信処理アプリケーションが指定した名前が格納されていることから、これを優先的に採用して当該ノードに振り分ける。
【００５１】
ＦＥＰシステム３内の通信処理アプリケーションは、ホスト５Ａ…が停止する前に、宛先ノード名を当該ＦＥＰシステム３自体に変更しておく。そして、ホスト５Ａ…が稼働状態となったのを契機に、宛先ノード名をホスト５Ａ…内のノードに変更する。
【００５２】
ＦＥＰシステム３内の通信処理アプリケーションは、宛先ノードが当該ＦＥＰシステム３自体となっている場合、端末１Ａ…から転送されるファイルを一時的に蓄積しておく。そして、ホストマシンが稼働状態となり、転送指示を受けたときに、一括してホスト５Ａ…に転送する。
【００５３】
なお、宛先ノードが当該ＦＥＰシステム３自体となっている場合に、ＦＥＰシステム３内の通信処理アプリケーションが、端末１Ａ…から転送されるデータを、ホストに代わって処理することが可能であれば、端末１Ａ…から転送されるファイルをホストマシンに代わって処理するようにしてもよい。
【００５４】
図３に示す経路Ｐ１は、稼働状態を判断するための相互の通信を、経路Ｐ２は、稼働状況の変化に応じて発行される宛先切換え指示が端末管理テーブルに反映される様子を、そして経路Ｐ３およびＰ４は、接続時に端末管理テーブルを参照して、実際に有効な宛先に接続される様子をそれぞれ示している。
【００５５】
図５、図６、図７、図８および図９は、接続ノード管理部３８、宛先ノード名参照部３６、宛先ノード名変更部３７、接続処理実行部３９および運用情報取得部３５のそれぞれの動作を詳細に示すフローチャートである。
【００５６】
図５に示す接続ノード管理部３８の処理は次のように行われる。
処理が開始されると、ＩＰＬ（イニシャルプログラムローダ）処理を行うか否かが判定され（ステップＳ１１）、「真」である場合には、システムファイルから交換端末定義情報を読み出す（ステップＳ１２）。次に、交換端末定義情報のシンタクスチェックおよびセマンティック等の定義チェック処理が行われ（ステップＳ１３）、このチェック処理の結果が判定されて（ステップＳ１４）、「真」である場合には、ＦＥＰシステム３の主記憶域に交換端末数分のノード管理テーブル領域が獲得され、先に読み出された定義情報が反映されて（ステップＳ１５）、処理が終了する。
【００５７】
ステップＳ１１で、「偽」であると判定されたときは、宛先ノード名の参照または変更依頼であるか否かが判定され（ステップＳ１６）、「真」であると判定されたときは、依頼端末名をキーとしてノード管理テーブル３４の検索が行われる（ステップＳ１７）。次に、検索が成功したか否かが判定され（ステップＳ１８）、「真」であれば、参照依頼か否かが判定される（ステップＳ１９）。ステップＳ１９で「真」であると判定された場合には、アプリケーション指定ノードが有効であるか否かが判定され（ステップＳ２０）、「真」であると判定された場合には、アプリケーション指定ノード名を出力情報領域に格納して（ステップＳ２１）、処理を終了する。
【００５８】
ステップＳ２０で、「偽」であると判定された場合には、定義指定ノード名を出力情報領域に格納して（ステップＳ２２）、処理を終了する。
ステップＳ１９で、「偽」、すなわち変更依頼であると判定された場合には、変更ノード名はバイナリでゼロであるか否かが判定され（ステップＳ２３）、「真」であれば、さらに指定ノード名は有効であるか否かが判定される（ステップＳ２４）。ステップＳ２４で、「真」であると判定された場合には、ノード管理テーブルのアプリケーション指定有効フラグをオンとし（ステップＳ２５）、さらにアプリケーション指定ノード名をノード管理テーブル３４に格納して（ステップＳ２６）、処理を終了する。
【００５９】
ステップＳ２３で「偽」であると判定されたときは、ノード管理テーブル３４のアプリケーション指定有効フラグをオフとして（ステップＳ２７）、処理を終了する。
【００６０】
ステップＳ１４、Ｓ１６、Ｓ１８およびＳ２４で、「偽」と判定された場合はエラーであるので、復帰値を異常として（ステップＳ２８）、処理を終了する。
図６に示す宛先ノード名参照部３６の処理は次のように行われる。
【００６１】
処理が開始されると、接続ノード管理部３８に宛先ノード名の参照を依頼し（ステップＳ３１）、正常復帰か否かが判定され（ステップＳ３２）、「真」であれば、出力ノード名を通信処理アプリケーションに通知して（ステップＳ３３）、処理を終了する。ステップＳ３２において、「偽」であると判定された場合には、異常復帰の詳細なコードを付加してアプリケーションに異常終了を通知し（ステップＳ３４）、処理を終了する。
【００６２】
図７に示す宛先ノード名変更部３７の処理は次のように行われる。
処理が開始されると、接続ノード管理部３８に宛先ノード名の変更を依頼し（ステップＳ４１）、正常復帰か否かが判定され（ステップＳ４２）、「真」であれば、通信処理アプリケーションに正常終了を通知して（ステップＳ４３）、処理を終了する。ステップＳ４２において、「偽」であると判定された場合には、異常復帰の詳細なコードを付加してアプリケーションに異常終了を通知し（ステップＳ４４）、処理を終了する。
【００６３】
図８に示す接続処理実行部３９の処理は次のように行われる。
処理が開始されると、ダイアリング受付時の端末のアドレスをキーとしてノード管理テーブルの検索を行い（ステップＳ５１）、アプリケーション指定ノードは有効か否かが判定され（ステップＳ５２）、「真」であれば、指定ノード名からアドレスを求めて、当該ノードに接続要求を通知して（ステップＳ５３）、処理を終了する。ステップＳ５２において、「偽」であると判定された場合には、定義ノード名からアドレスを求めて当該ノードに接続要求を通知し（ステップＳ５４）、処理を終了する。
【００６４】
図９に示す運用情報取得部３５の処理は次のように行われる。
処理が開始されると、接続ノード変更契機か否かが判定され（ステップＳ６１）、「真」であれば、運用情報から接続ノード名を取得する（ステップＳ６２）。さらに、宛先ノード名変更部３７により接続先ノード名を取得し（ステップＳ６３）、変更処理が正常に完了したか否かが判定され（ステップＳ６４）、「真」であれば処理を終了する。ステップＳ６４で、「偽」と判定された場合には、異常処理が行われて（ステップＳ６５）、処理を終了する。ステップＳ６１で、「偽」であると判定された場合には、そのまま処理を終了する。
【００６５】
《実施例２》
次に、本発明に係るマルチプロセッサ装置の具体的な実施例を図面を参照して説明する。
【００６６】
〈システム構成〉
図１０は、本発明の第２の実施例によるマルチプロセッサ装置の構成を示している。
【００６７】
図１０のマルチプロセッサ装置は、端末１Ａ、１Ｂ、１Ｃおよび１Ｄと、疎結合マルチプロセッサシステム６とで構成されている。疎結合マルチプロセッサシステム６は、回線アダプタ７Ａ、７Ｂ、ＩＯ（入出力）バス８およびプロセッサ９Ａ、９Ｂ、９Ｃを有する。
【００６８】
回線アダプタ７Ａは、端末１Ａおよび１Ｂに接続され、回線アダプタ７Ｂは、端末１Ｃおよび１Ｄに接続される。これら回線アダプタ７Ａおよび７Ｂは、ＩＯバス８に接続され、ＩＯバス８には、プロセッサ９Ａ、９Ｂおよび９Ｃが接続される。
【００６９】
各プロセッサ９Ａ、９Ｂ、９Ｃは、それぞれ、アプリケーションプロセス実行部９１Ａ、９１Ｂ、９１Ｃ、通信処理サーバプロセス実行部９２Ａ、９２Ｂ、９２Ｃ、および通信アクセス法プロセス実行部９３Ａ、９３Ｂ、９３Ｃを有する。
前記通信処理サーバプロセス実行部９２Ａ、９２Ｂ、９２Ｃは、アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定される通信識別子からプロセッサ識別番号を取り出すとともに、該プロセッサ識別番号により決定されるプロセッサに対して、当該プロセッサ内の通信処理サーバプロセスで端末への送信処理を実行させるべく送信データを回送する。前記通信識別子は、プロセッサ識別信号とプロセッサ内に記憶される端末管理テーブルにおける配列番号とを含み、マルチプロセッサシステム内で一意的に定義される。
【００７０】
通信処理サーバプロセス実行部９２Ａ、９２Ｂ、９２Ｃは、それぞれ、通信識別子採番部９４Ａ、９４Ｂ、９４Ｃ、通信識別子通知部９５Ａ、９５Ｂ、９５Ｃおよびプロセッサ識別番号取得部９６Ａ、９６Ｂ、９６Ｃを具備している。
【００７１】
通信識別子採番部９４Ａ、９４Ｂ、９４Ｃは、端末のプロセッサとの結合時に、プロセッサ識別信号とプロセッサ内の端末管理テーブルにおける配列番号とを組み合わせて得られるマルチプロセッサシステム内での一意的な番号を通信識別子として採番する。
【００７２】
通信識別子通知部９５Ａ、９５Ｂ、９５Ｃは、アプリケーションプロセスに対して、端末結合の処理結果の通知時に、通信識別子を通知する。
プロセッサ識別番号取得部９６Ａ、９６Ｂ、９６Ｃは、アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定された通信識別子からプロセッサ識別番号を取り出す。
【００７３】
ＩＯバス８は、プロセッサ９Ａ〜９Ｃと回線アダプタ７Ａ、７Ｂとの間のデータの入出力で使用される。
すなわち、図１０に示しているのは、複数のプロセッサ９Ａ、９Ｂ、９Ｃと（ＬＡＮ）回線アダプタ７Ａ、７ＢとをＩＯバス８で疎結合したマルチプロセッサシステム６である。回線アダプタ７Ａ、７Ｂには、任意のプロセッサ９Ａ、９Ｂ、９Ｃからアクセスすることができる。
【００７４】
さらに、各プロセッサ９Ａ、９Ｂ、９Ｃ上に、アプリケーションプロセス実行部９１Ａ、９１Ｂ、９１Ｃ、通信サーバプロセス実行部９２Ａ、９２Ｂ、９２Ｃおよび通信アクセス法プロセス実行部９３Ａ、９３Ｂ、９３Ｃがそれぞれ各対応して設けられる。各アプリケーションプロセスが発生する送受信システムコールは、当該プロセッサ上の通信処理サーバプロセスが受け付ける。そして、端末が結合しているプロセッサの位置に応じて、そのプロセッサ自身が通信アクセス法プロセスを使用して処理するのか、他のプロセッサ上の通信処理サーバプロセスに処理を依頼するのかを決定して分岐処理を行う。
【００７５】
図１０に破線で示すコネクションＰＡ、ＰＣおよびＰＤは、論理的な結合関係の例を示し、このような結合関係は、コネクション、セッションまたは通信パス等と称される。これらコネクションＰＡ、ＰＣおよびＰＤによる各端末１Ａ〜１Ｄと各プロセッサ９Ａ〜９Ｃとの論理的な結合関係は、端末１Ａはプロセッサ９Ａに結合され、端末１Ｂはシステムと未結合であり、端末１Ｃはプロセッサ９Ｃに結合され、端末１Ｄはプロセッサ９Ａに結合されている。
【００７６】
データフローＦ１は、端末１Ａがプロセッサ９Ａと結合した場合の結合時のデータの流れを示し、データフローＦ２は、プロセッサ９Ｂ内のアプリケーションプロセスが、端末１Ｃに対してデータ送信システムコールを実行したときのデータの流れを示す。各プロセッサ９Ａ、９Ｂおよび９Ｃの論理プロセッサ名はそれぞれＰＭ０１、ＰＭ０２およびＰＭ０３とする。
【００７７】
〈通信識別子の採番〉
通信識別子の採番は、図１１および図１２に、発呼による端末結合時のデータフローおよび着呼による端末結合時のデータフローをそれぞれ示すように、アプリケーションプロセスからの発呼要求または端末からアプリケーションプロセスへの着呼通知を契機とした端末結合処理において実行される。
【００７８】
図１３に通信識別子の採番処理のフローチャートを示す。
通信処理サーバプロセスは、通信アクセス法プロセスに結合処理を依頼する前に、自プロセッサ内の端末管理テーブルリストから空きエントリを検索する（ステップＳ７１）。そして、検索が成功したか否かが判定され（ステップＳ７２）、「真」であれば、検索されたエントリの配列番号が取得され（ステップＳ７３）、当該エントリの配列番号と論理プロセッサ名リスト内の自プロセッサの配列番号とを組み合わせた番号を通信識別子として採番した後（ステップＳ７４）、端末管理テーブルに格納して（ステップＳ７５）、処理を終了する。
【００７９】
ステップＳ７２において、「偽」と判定された場合、すなわち端末管理テーブルリストに空きエントリがない場合は、端末管理テーブルリストを拡張し、拡張部の先頭エントリを取得して（ステップＳ７６）、ステップＳ７４の処理を行う。
【００８０】
このようにして採番された通信識別子は、図１１および図１２に示されるように、通信アクセス法に結合依頼する際に、利用者要求識別子として指定される。
〈通信識別子の通知〉
図１１および図１２に示されるように、通前記結合処理の結果は、通信アクセス法プロセスから通信処理サーバプロセスに対して、結合依頼とは非同期に通知される。さらに、通信処理サーバプロセスは、通信識別子と共に結合処理結果をアプリケーションプロセスに通知する。
【００８１】
図１４に通信識別子の通知処理のフローチャートを示す。
通信処理サーバプロセスは、このとき処理結果に付加して通知される通信識別子をキーとして、端末管理テーブルを検索することにより、結合に成功したか否かを判定する（ステップＳ８１）。そして、ステップＳ８１の判定結果が「真」、すなわち結合結果が正常の場合、処理結果データ内通信識別子に、端末管理テーブル内の通信識別子を格納して（ステップＳ８２）、アプリケーションプロセスに、通信識別子とともに処理結果データを通知することにより（ステップＳ８３）、処理が正常に完了したことを通知して処理を終了する。ステップＳ８１で、「偽」と判定された場合、すなわち異常の場合、処理結果データ内通信識別子を無効化するため、端末管理テーブル内の通信識別子をゼロクリアし（ステップＳ８４）、端末管理テーブルをリストから削除して（ステップＳ８５）、アプリケーションプロセスに、エラーの原因を付加して処理結果データを通知することにより（ステップＳ８３）、処理が異常終了したことを通知して処理を終了する。
【００８２】
〈プロセッサ識別番号の取得〉
図１５にデータ送信時のデータフローを示すように、アプリケーションプロセスは、送信システムコール実行時に、結合端末に対応する通信識別子を指定し、論理プロセッサ識別番号を取得する。
【００８３】
図１６に論理プロセッサ識別番号の取得処理のフローチャートを示す。
当該送信要求を受け付けた通信処理サーバプロセスは、指定された通信識別子のプロセッサ識別番号の有効性をチェックする（ステップＳ９１）。そして、ステップＳ９１が「真」、すなわち通信識別子の論理プロセッサ識別番号が正常である時は、通信識別子内のプロセッサ識別番号からプロセッサの位置を決定する。このとき、プロセッサ識別番号は自プロセッサの値に等しいか否かを調べ（ステップＳ９２）、「真」、すなわち当該プロセッサがそのプロセッサ自体である場合は、通信アクセス法プロセスに送信依頼して（ステップＳ９３）、処理を終了する。また、ステップＳ９２が「偽」、つまり当該プロセッサが他プロセッサである場合、他プロセッサ内の通信処理サーバプロセスに対して、送信データを回送することで送信処理を依頼し（ステップＳ９４）、処理を終了する。ステップＳ９１で「偽」、すなわちプロセッサ識別番号が無効である時はアプリケーションプロセスにその旨を通知して（ステップＳ９５）、処理を終了する。
【００８４】
図１７は、論理プロセッサ名リスト、プロセッサ９Ａ、９Ｃの端末管理テーブルリストおよび端末１Ａ、１Ｃ、１Ｄの管理テーブルの関係を模式的に示している。
【００８５】
論理プロセッサ名リストは、それぞれ論理プロセッサ名、物理的なプロセッサの識別情報およびその他の管理情報が格納された複数の配列からなり、図１７においては、配列０が未使用状態、配列１には、論理プロセッサ名としてＰＭ０１、物理的なプロセッサの識別情報としてプロセッサ９Ａを示す情報が格納され、配列２には、論理プロセッサ名としてＰＭ０２、物理的なプロセッサの識別情報としてプロセッサ９Ｂを示す情報が格納され、配列３には、論理プロセッサ名としてＰＭ０３、物理的なプロセッサの識別情報としてプロセッサ９Ｃを示す情報が格納されている。
【００８６】
プロセッサ９Ａの端末管理テーブルリストは、配列０、３および４が未使用であり、配列１には端末１Ａの管理テーブルが格納され、配列２には端末１Ｄの管理テーブルが格納されている。端末１Ａの管理テーブルには、通信識別子「０１０００００１」と他の管理情報とが格納されている。通信識別子「０１ ０００００１」の「０１」は論理プロセッサ名リストの配列番号であり、「０００００１」は端末管理テーブルリストの配列番号である。端末１Ｄの管理テーブルには、通信識別子「０１ ０００００２」と他の管理情報とが格納されている。通信識別子「０１ ０００００２」の「０１」は論理プロセッサ名リストの配列番号であり、「０００００２」は端末管理テーブルリストの配列番号である。
【００８７】
プロセッサ９Ｃの端末管理テーブルリストは、配列０、２〜４が未使用であり、配列１には端末１Ｃの管理テーブルが格納されている。端末１Ｃの管理テーブルには、通信識別子「０３ ０００００１」と他の管理情報とが格納されている。通信識別子「０３ ０００００１」の「０３」は論理プロセッサ名リストの配列番号であり、「０００００１」は端末管理テーブルリストの配列番号である。
【００８８】
〈プロセッサで異常発生時の端末の引き継ぎ〉
このようなシステムでは、あるプロセッサで異常が発生したときのバックアップを有効に行うことができる。
【００８９】
すなわち、上述した疎結合マルチプロセッサシステム６は、１個のプロセッサに待機属性を、残りのプロセッサに現用属性を付与し、待機プロセッサは現用プロセッサの障害時にバックアップ用として動作するようにし、各プロセッサには所定の論理プロセッサ名を付与し、待機プロセッサが障害現用プロセッサをバックアップする際に現用プロセッサの論理プロセッサ名を引き継ぐとともに、プロセッサ識別番号として論理プロセッサ名リストの配列番号を割り当てることにより、待機プロセッサが現用プロセッサに結合していた端末を引き継いだ後でも、端末と通信識別子との関係を不変とすることができる。
【００９０】
あるプロセッサで異常が発生した場合、アダプタ内のプロセスとバックアッププロセッサ内の通信アクセス法プロセスとの間の論理的関係を引き継ぐ。さらに、通信アクセス法プロセスと通信処理サーバプロセスとの間の論理的関係も引き継ぐ。これにより、端末を異常が発生したプロセッサからバックアッププロセッサに引き継ぐ。
【００９１】
ここで、あるプロセッサで異常が発生したことを認識した通信処理サーバプロセスは、異常終了したプロセッサの論理プロセッサ名に対応するエントリとバックアップとを対応付ける。そして、それまでバックアッププロセッサに付与されていた論理プロセッサ名に対応するエントリは、当該プロセッサを閉塞状態として管理する。これにより、論理プロセッサ名対応の配列番号は不変となるので、論理プロセッサ名と当該論理プロセッサに結合した端末との関係は不変となり、アプリケーションプロセッサは、論理プロセッサを意識して処理を組むことで、あるプロセッサで異常が発生しても、処理を継続して行うことができる。
【００９２】
この場合の、プロセッサ９Ａに障害が発生した場合の具体的な処理の一例を、図１８〜図２２を参照して説明する。
プロセッサ９Ａに障害が発生する前の状態では、図１８に示すように、端末１ＡはコネクションＰＡを介してプロセッサ９Ａに接続され、端末１ＤはコネクションＰＤを介して同様にプロセッサ９Ａに接続されている。
【００９３】
このときの論理プロセッサ名リストは、図２０に示すように、それぞれ論理プロセッサ名、物理的なプロセッサの識別情報、プロセッサの状態、現用待機属性およびその他の管理情報が格納された複数の配列からなる。すなわち、ここでは、管理情報として、プロセッサの状態および現用待機属性が図１７の例に追加されている。図２０においては、配列０が未使用状態であり、配列１には、論理プロセッサ名としてＰＭ０１、物理的なプロセッサの識別情報としてプロセッサ９Ａ、プロセッサの状態として活性状態、現用待機属性として現用を示す情報がそれぞれ格納されている。同様に配列２には、論理プロセッサ名としてＰＭ０２、物理的なプロセッサの識別情報としてプロセッサ９Ｂ、プロセッサの状態として活性状態、現用待機属性として現用を示すを示す情報が格納され、配列３には、論理プロセッサ名としてＰＭ０３、物理的なプロセッサの識別情報としてプロセッサ９Ｃ、プロセッサの状態として活性状態、現用待機属性として待機を示すを示す情報が格納されている。すなわち、この場合は、プロセッサ９Ｃがバックアップに用いられる待機プロセッサとなっている。
【００９４】
この状態でプロセッサ９Ａに障害が発生すると、図２１に示すように、配列１に格納される情報が、論理プロセッサ名としてＰＭ０１、物理的なプロセッサの識別情報としてプロセッサ９Ｃ、プロセッサの状態として活性状態、現用待機属性として現用を示す情報に変更される。配列２は、論理プロセッサ名としてＰＭ０２、物理的なプロセッサの識別情報としてプロセッサ９Ｂ、プロセッサの状態として活性状態、現用待機属性として現用を示すを示す情報が格納されたままであり、配列３は、論理プロセッサ名としてＰＭ０３、物理的なプロセッサの識別情報はなし、プロセッサの状態として閉塞状態、現用待機属性もなしの状態に変わる。
【００９５】
このことにより、障害の発生したプロセッサ９Ａの論理プロセッサ番号はプロセッサ９Ｃに引き継がれて、図１９に示すように、障害の発生したプロセッサ９Ａの機能はプロセッサ９Ｃが肩代わりすることになり、端末１ＡはコネクションＰＡを介してプロセッサ９Ｃに接続され、端末１ＤはコネクションＰＤを介してプロセッサ９Ｃに接続される。このときプロセッサ９Ａは、障害発生状態にあるが、ソフトウェア障害の場合には再ＩＰＬを実施して、プロセッサの再立ち上げを行い、プロセッサを復旧する。ハードウェア障害のときは、オペレータにプロセッサモジュールの交換等を促し、障害復旧を行う。
【００９６】
このようにしてプロセッサ９Ａの障害が復旧されると、図２２に示されるように、配列３は、論理プロセッサ名としてＰＭ０３、物理的なプロセッサの識別情報としてプロセッサ９Ａ、プロセッサの状態として活性状態、現用待機属性として待機を示すを示す情報が格納された状態となり、プロセッサ９Ａが次のバックアップ用待機プロセッサとして待機状態となる。
【００９７】
なお、アプリケーションプロセスが、システムに結合した端末に対するデータ送信用のシステムコールを実行する場合、当該結合端末に対応する通信識別子を指定する必要がある。ところで、当該通信識別子は、結合処理を実行したアプリケーションプロセスにのみ通知される。したがって、他のアプリケーションプロセス、特に端末が結合していないＰＭ内のアプリケーションプロセスは、何らかの方法で通信識別子を取得する必要がある。この場合の通信識別子を取得するには種々の方法があるが、例えば結合処理を実行したアプリケーションプロセスが、全プロセスに対して通信識別子をブロードキャストすればよい。この場合、端末切断時にも、通信識別子を無効化するためにブロードキャストが必要である。
【００９８】
従来の疎結合マルチプロセッサシステムにおいては、システムジェネレーション時に、システムに結合する端末とプロセッサとの関係を定義したテーブルを作成していた。そして、システム始動時に当該テーブルを各プロセッサの主記憶装置にロードし、アプリケーションプロセスが発行した送信システムコール処理時に、前記ロード情報を参照することによりプロセッサを決定していた。そのため、例えばプロセッサの負荷分散の目的などから、端末が結合するプロセッサを動的に変更することはできなかった。
【００９９】
また、端末が結合するプロセッサを動的に変更するように構成された疎結合マルチプロセッサシステムも従来より存在した。但し、この場合、プロセッサに結合した端末との送受信処理が可能なアプリケーションプロセスは、当該プロセッサ上で動作するものに限られていた。
【０１００】
疎結合マルチプロセッサシステムにおける端末利用を実現する上で、端末結合処理の性能とデータ送受信処理の性能とを同時に高めることはできない。
したがって、業務の運用に応じたトレードオフが必要となる。問題は、この二者択一をシステムが行うのかユーザが行うのかという点である。
【０１０１】
まず、システムが二者択一を行う方法としては、端末の運用定義による方法や、結合時にアプリケーションプロセスがパラメータで指定する方法などがある。しかし、システムプログラムの処理論理が複雑になるという点およびシステムプログラムが２本立てとなり煩雑であるという点で現実的ではない。
【０１０２】
他方、ユーザが二者択一する場合、自身の業務の運用に合わせていずれかを選択するだけであるから問題は少ない。
以上述べたように、システムがユーザの業務の運用上の要件を満たしつつ端末共用を実現することは困難である。
【０１０３】
さらに、端末が結合したプロセッサで障害発生時に、当該端末をバックアッププロセッサに引き継ぎ、なおかつ、各プロセッサから引き継いだ端末を共用できる機能は従来存在しなかった。
【０１０４】
しかしながら、疎結合マルチプロセッサシステムにおいて、端末がシステムと結合する場合、結合するプロセッサの決定論理は、ジェネレーション時に定義する手法や、運用時の各プロセッサの負荷状況に応じて選択する手法など、複数の手法を組み合わせて利用できることが、業務設計の柔軟性を向上させる上で望ましい。
【０１０５】
同じく、業務設計の柔軟性の向上の観点からいって、システムに結合した端末を、システムを構成する各プロセッサ内のアプリケーションプロセスから共用できるようにすることが望ましい。
【０１０６】
さらに、フォルトトレラントコンピュータとして疎結合マルチプロセッサシステムを利用する場合、結合端末を障害プロセッサからバックアッププロセッサに引き継ぐ前と後で、アプリケーションプロセスが実行する送受信システムコールのインタフェースが不変であることが望ましい。
【０１０７】
従来のマルチプロセッサシステムで、上述の要件を全て満足するものは存在しなかったが、上述の本発明の第２の実施例のマルチプロセッサ装置によれば、これらの要望を全て満たすことができるようになる。
【０１０８】
したがって、この実施例のマルチプロセッサ装置では、前述のように通信識別子を構造化し、システムコール時にアプリケーションプロセスが、結合端末対応に指定する通信識別子からプロセッサ識別番号を取り出すことで、端末が結合しているプロセッサの特定が可能となる。さらに、プロセッサ番号として、論理プロセッサ名リスト内の配列番号を割り当てていることにより、プロセッサで異常が発生し、端末をバックアッププロセッサに引き継いだ際にも、送信システムコールのインタフェースの普遍性が保証される。
【０１０９】
さらに、このように構成した、マルチプロセッサシステムを、先に述べた本発明の第１の実施例のネットワーク装置におけるＦＥＰシステムとして用いることができる。
【０１１０】
この場合、具体的には例えば図３に示すＦＥＰシステム３を図１０に示される疎結合マルチプロセッサシステム６で構成することになり、第１の実施例のネットワーク装置を一層有効に構成することができる。
【０１１１】
【発明の効果】
以上説明したように、本発明によれば、通信処理アプリケーションを組み込んだＦＥＰシステムを１組または複数個のホストに結合するとともに、業務実行時に、複数個の端末からネットワーク内のノードへの接続をする場合、常にＦＥＰシステムにダイアリングするだけで、ＦＥＰシステムからその時点で有効なネットワークノードに対して接続要求を振り分け、端末を有効なノードに接続するようにして、端末からダイアリングした際に、前記端末が接続される交換網とホストプロセッサが結合されるネットワークとの間で、システムの運用状況に応じて、柔軟に且つ適切に宛先管理、故障対処および業務処理を行うことを可能とするネットワーク装置を提供することができる。
【０１１２】
さらに、本発明によれば、通信処理サーバプロセスにより、端末結合時に、プロセッサ識別番号と端末管理テーブル内の配列番号の２つの情報を組み合わせたものとして構造化した通信識別子を動的に割り当て、当該マルチプロセッサシステム内で一意的に定義されるこの通信識別子をアプリケーションプロセスに通知し、該アプリケーションプロセスによる結合端末に対する送信システムコール時に、結合端末毎に対応して指定した通信識別子に基づいてプロセッサを決定し、当該プロセッサに送信データを回送するようにして、各プロセッサ内のアプリケーションプロセスからデータ送受信処理を行うことができるとともに、端末を結合するプロセッサを動的に変更可能として、前記各プロセッサ内のアプリケーションプロセスから端末を共用することができ、常時運用を可能として、前記ネットワーク装置における宛先管理、故障対処および業務処理に好適に使用することができるマルチプロセッサ装置を提供することができる。
【図面の簡単な説明】
【図１】本発明に係るネットワーク装置の構成を示す原理図である。
【図２】本発明に係るマルチプロセッサ装置の構成を示す原理図である。
【図３】本発明の実施例１に係るネットワーク装置の構成を示すブロック図である。
【図４】図３のネットワーク装置の要部の構成を詳細に示すブロック図である。
【図５】図４のネットワーク装置の接続ノード管理部の動作を説明するためのフローチャートである。
【図６】図４のネットワーク装置の宛先ノード名参照部の動作を説明するためのフローチャートである。
【図７】図４のネットワーク装置の宛先ノード名変更部の動作を説明するためのフローチャートである。
【図８】図４のネットワーク装置の接続処理実行部の動作を説明するためのフローチャートである。
【図９】図４のネットワーク装置の運用情報取得部の動作を説明するためのフローチャートである。
【図１０】本発明の実施例２に係るマルチプロセッサ装置の構成を示すブロック図である。
【図１１】図１０のマルチプロセッサ装置の動作を模式的に説明するための発呼による端末結合時のデータフロー図である。
【図１２】図１０のマルチプロセッサ装置の動作を模式的に説明するための着呼による端末結合時のデータフロー図である。
【図１３】図１０のマルチプロセッサ装置の通信識別子の採番処理の動作を説明するためのフローチャートである。
【図１４】図１０のマルチプロセッサ装置の通信識別子の通知処理の動作を説明するためのフローチャートである。
【図１５】図１０のマルチプロセッサ装置の動作を模式的に説明するためのデータ送信時のデータフロー図である。
【図１６】図１０のマルチプロセッサ装置の論理プロセッサ識別番号取得処理の動作を説明するためのフローチャートである。
【図１７】図１０のマルチプロセッサ装置に用いられるテーブルを模式的に説明するための図である。
【図１８】図１０のマルチプロセッサ装置のプロセッサ障害発生時の動作を説明するための模式図である。
【図１９】図１０のマルチプロセッサ装置のプロセッサ障害バックアップ時の動作を説明するための模式図である。
【図２０】図１０のマルチプロセッサ装置のプロセッサ障害発生時の動作を説明するための障害発生前の論理プロセッサ名リストの模式図である。
【図２１】図１０のマルチプロセッサ装置のプロセッサ障害発生時の動作を説明するための障害発生時の論理プロセッサ名リストの模式図である。
【図２２】図１０のマルチプロセッサ装置のプロセッサ障害発生時の動作を説明するための障害復旧時の論理プロセッサ名リストの模式図である。
【符号の説明】
１Ａ，１Ｂ，１Ｃ，１Ｄ…端末
２…交換網
３…フロントエンドプロセッサ（ＦＥＰ）システム
４…ネットワーク
５，５Ａ，５Ｂ…ホスト（プロセッサ）
６…疎結合マルチプロセッサシステム
７Ａ，７Ｂ…回線アダプタ
８…入出力（ＩＯ）バス
９Ａ，９Ｂ，９Ｃ…プロセッサ
３１，５１…通信処理アプリケーション実行部
３２，５２…通信処理サーバ部
３３，５３…通信アクセス法処理部
３４…ノード管理テーブル
３５…運用情報取得部
３６…宛先ノード名参照部
３７…宛先ノード名変更部
３８…接続ノード管理部
３９…接続処理実行部
９１Ａ，９１Ｂ，９１Ｃ…アプリケーションプロセス実行部
９２Ａ，９２Ｂ，９２Ｃ…通信処理サーバプロセス実行部
９３Ａ，９３Ｂ，９３Ｃ…通信アクセス法プロセス実行部
Claims (7)
- 各々、通信処理アプリケーションおよび通信アクセス法の処理を実行するための手段を有する１個以上のホストプロセッサと、
複数個の端末と、
フロントエンドプロセッサとを有し、
前記フロントエンドプロセッサは、
ネットワークを介して前記ホストプロセッサに結合され且つ交換網経由で前記端末に接続され、通信処理アプリケーション実行手段、通信処理サーバ手段および通信アクセス法処理手段を有し、前記端末からのダイアリングに対し当該端末を接続するホストプロセッサおよびそのホストプロセッサ内のネットワークノードの管理および接続の実行、前記通信処理アプリケーション実行手段により実行される通信処理アプリケーションにより指定された端末に対応して接続宛先名として登録されているネットワークノードの参照、および該通信処理アプリケーションによる指定端末の接続宛先名の変更更新を行うことを特徴とするネットワーク装置であって、
前記フロントエンドプロセッサシステムは、端末単位に、当該端末をどのプロセッサの、どのネットワークノードに接続するかを示すノード管理テーブルを保持し、前記端末からフロントエンドプロセッサシステムにダイアリングした際に、当該端末をどのプロセッサの、どのネットワークノードに接続するかを管理するための接続ノード管理手段と、フロントエンドプロセッサシステム内で動作する通信処理アプリケーションが、端末名を指定して宛先名参照のシステムコールを発生した際に、前記ノード管理テーブルにおいて指定端末の接続宛先名として登録されているネットワークノード名を前記通信処理アプリケーションに通知するための宛先名参照手段と、前記通信処理アプリケーションが、端末名とネットワークノード名を指定して宛先名変更のシステムコールを発生した際に、前記ノード管理テーブルにおける指定端末の接続宛先名を、指定ネットワークノード名に更新するための宛先名変更手段と、端末からフロントエンドプロセッサシステムにダイアリングした際に、前記接続ノード管理テーブルを参照して接続ネットワークノードを決定し当該ノードに接続要求を伝達するための接続処理実行手段と、前記通信処理アプリケーションが、端末の接続宛先名を変更するために利用する運用情報を取得するための運用情報取得手段とを具備することを特徴とするネットワーク装置。 - 運用情報取得手段は、ホストプロセッサの運用スケジュールを参照するための手段を含み、且つ接続ノード管理手段は、該当ホストプロセッサの前記運用スケジュールに基づき、ホストプロセッサ稼働時には端末の接続ノードを該当ホストプロセッサ内
のネットワークノードとし、ホストプロセッサ停止時には前記該当ホストプロセッサを代行し得る他のホストプロセッサ内のネットワークノードとして宛先を変更するための手段を含むことを特徴とする請求項１のネットワーク装置。 - 運用情報取得手段は、ホストプロセッサの運用スケジュールを参照するための手段を含み、且つ接続ノード管理手段は、該当ホストプロセッサの前記運用スケジュールに基づき、ホストプロセッサ稼働時には端末の接続ノードを該当ホストプロセッサ内のネットワークノードとし、ホストプロセッサ停止時にはそのフロントエンドプロセッサシステム内で実行される通信処理アプリケーションを前記端末に接続されるネットワークノードとして宛先を変更するための手段を含むことを特徴とする請求項１のネットワーク装置。
- 運用情報取得手段は、そのフロントエンドプロセッサシステム内で動作する通信処理アプリケーションが、ホストプロセッサ内で動作する通信処理アプリケーションとの相互に通信を行うことにより運用スケジュールを決定するための手段であることを特徴とする請求項１のネットワーク装置。
- フロントエンドプロセッサシステムは、
通信処理アプリケーションプロセスを含むアプリケーションプロセスを実行するためのアプリケーションプロセス手段、通信処理サーバプロセスを実行するための通信処理サーバプロセス手段、および通信アクセス法プロセスを実行するための通信アクセス法プロセス手段を有するマルチプロセッサが入出力バスに複数個並列的に結合される疎結合マルチプロセッサシステムであって、
前記通信処理サーバプロセス手段は、前記アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定される、プロセッサ識別信号とプロセッサ内に記憶される端末管理テーブルにおける配列番号とを含むマルチプロセッサシステム内で一意的な、通信識別子からプロセッサ識別番号を取り出すとともに、該プロセッサ識別番号により決定されるプロセッサに対して、当該プロセッサ内の通信処理サーバプロセスで端末への送信処理を実行させるべく送信データを回送する手段を具備することを特徴とする請求項１のネットワーク装置。 - 通信処理サーバプロセス手段は、
端末のプロセッサとの結合時に、プロセッサ識別信号とプロセッサ内の端末管理テーブルにおける配列番号とを組み合わせて得られるマルチプロセッサシステム内での一意的な番号を通信識別子として採番する通信識別子採番手段と、
アプリケーションプロセスに対して、端末結合の処理結果の通知時に、通信識別子を通知する通信識別子通知手段と、
アプリケーションプロセスによるデータ送信のシステムコールの実行時に、送信先端末に対応して指定された通信識別子からプロセッサ識別番号を取り出すプロセッサ識別番号取得手段とを具備することを特徴とする請求項５のネットワーク装置。 - フロントエンドプロセッサシステムを構成する疎結合マルチプロセッサシステムは、
１個のプロセッサに待機属性を、残りのプロセッサに現用属性を付与し、待機プロセッサは現用プロセッサの障害時にバックアップ用として動作するマルチプロセッサシステムであって、
各プロセッサには所定の論理プロセッサ名を付与し、待機プロセッサが障害現用プロセッサをバックアップする際に現用プロセッサの論理プロセッサ名を引き継ぐとともに、プロセッサ識別番号として論理プロセッサ名リストの配列番号を割り当てることにより、待機プロセッサが現用プロセッサに結合していた端末を引き継いだ後でも、端末と通信識別子との関係を不変とすることを特徴とする請求項５のネットワーク装置。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP31553093A JP3599364B2 (ja) | 1993-12-15 | 1993-12-15 | ネットワーク装置 |
| US08/301,781 US5764914A (en) | 1993-12-15 | 1994-09-07 | Network system for connecting to a network node from terminal |
| GB9418152A GB2284962B (en) | 1993-12-15 | 1994-09-08 | Network system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP31553093A JP3599364B2 (ja) | 1993-12-15 | 1993-12-15 | ネットワーク装置 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004146993A Division JP3860587B2 (ja) | 2004-05-17 | 2004-05-17 | マルチプロセッサ装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH07168778A JPH07168778A (ja) | 1995-07-04 |
| JP3599364B2 true JP3599364B2 (ja) | 2004-12-08 |
Family
ID=18066454
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP31553093A Expired - Fee Related JP3599364B2 (ja) | 1993-12-15 | 1993-12-15 | ネットワーク装置 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US5764914A (ja) |
| JP (1) | JP3599364B2 (ja) |
| GB (1) | GB2284962B (ja) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1997049039A1 (en) * | 1996-06-21 | 1997-12-24 | Bell Communications Research, Inc. | Apparatus and methods for highly available directory services in the distributed computing environment |
| JPH1097571A (ja) * | 1996-09-20 | 1998-04-14 | Hitachi Ltd | 相談先端末接続方法 |
| JPH11168523A (ja) * | 1997-10-02 | 1999-06-22 | Canon Inc | データ通信装置及び通信制御方法 |
| JP3489983B2 (ja) * | 1997-12-26 | 2004-01-26 | 富士通株式会社 | データ転送システム、端末装置、及びその方法 |
| US6671739B1 (en) | 2000-07-10 | 2003-12-30 | International Business Machines Corporation | Controlling network access by modifying packet headers at a local hub |
| US7512686B2 (en) | 2000-12-21 | 2009-03-31 | Berg Mitchell T | Method and system for establishing a data structure of a connection with a client |
| US7418522B2 (en) * | 2000-12-21 | 2008-08-26 | Noatak Software Llc | Method and system for communicating an information packet through multiple networks |
| US20020116397A1 (en) | 2000-12-21 | 2002-08-22 | Berg Mitchell T. | Method and system for communicating an information packet through multiple router devices |
| US7546369B2 (en) | 2000-12-21 | 2009-06-09 | Berg Mitchell T | Method and system for communicating a request packet in response to a state |
| US7287090B1 (en) * | 2000-12-21 | 2007-10-23 | Noatak Software, Llc | Method and system for identifying a computing device in response to a request packet |
| US7421505B2 (en) * | 2000-12-21 | 2008-09-02 | Noatak Software Llc | Method and system for executing protocol stack instructions to form a packet for causing a computing device to perform an operation |
| US6961773B2 (en) * | 2001-01-19 | 2005-11-01 | Esoft, Inc. | System and method for managing application service providers |
| US7215640B2 (en) * | 2002-07-11 | 2007-05-08 | Hitachi, Ltd. | Method and apparatus for path configuration in networks |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4823122A (en) * | 1984-06-01 | 1989-04-18 | Digital Equipment Corporation | Local area network for digital data processing system |
| JPS61228533A (ja) * | 1985-04-03 | 1986-10-11 | Hitachi Ltd | 電子計算機におけるセツシヨンの制御方法 |
| US4893307A (en) * | 1988-02-29 | 1990-01-09 | International Business Machines Corporation | Method and apparatus for linking SNA terminals to an SNA host over a packet switched communications network |
| JPH01276952A (ja) * | 1988-04-28 | 1989-11-07 | Nec Corp | 局データ変更方式 |
| JPH0228866A (ja) * | 1988-07-19 | 1990-01-30 | Nec Corp | ログイン切替え方式 |
| US5341477A (en) * | 1989-02-24 | 1994-08-23 | Digital Equipment Corporation | Broker for computer network server selection |
| JPH03254540A (ja) * | 1990-03-05 | 1991-11-13 | Nec Corp | 端末起動型ネットワークにおけるアドレス変換方式 |
| JPH03266156A (ja) * | 1990-03-16 | 1991-11-27 | Nec Corp | 動的端末接続方式 |
| EP0461408B1 (en) * | 1990-06-14 | 1996-04-17 | Mitsubishi Denki Kabushiki Kaisha | Network address managing method and system |
| JP2825630B2 (ja) * | 1990-09-07 | 1998-11-18 | 株式会社日立製作所 | 回線切替方式 |
| CA2048306A1 (en) * | 1990-10-02 | 1992-04-03 | Steven P. Miller | Distributed configuration profile for computing system |
| US5289578A (en) * | 1990-11-09 | 1994-02-22 | Foreign Exchange Transaction Services, Inc. | Activation of a dormant sibling computer in a communication network by overriding a unique dormant node address with a common active node address |
| GB9027186D0 (en) * | 1990-12-14 | 1991-02-06 | Int Computers Ltd | Data processing network |
| US5241682A (en) * | 1991-04-18 | 1993-08-31 | International Business Machines Corporation | Border node having routing and functional capability in a first network and only local address capability in a second network |
| JPH0553946A (ja) * | 1991-08-29 | 1993-03-05 | Nec Corp | 端末共有マルチホストシステム |
| US5371852A (en) * | 1992-10-14 | 1994-12-06 | International Business Machines Corporation | Method and apparatus for making a cluster of computers appear as a single host on a network |
| US5539884A (en) * | 1993-05-20 | 1996-07-23 | Bell Communications Research, Inc. | Intelligent broadband communication system and method employing fast-packet switches |
| US5448723A (en) * | 1993-10-15 | 1995-09-05 | Tandem Computers Incorporated | Method and apparatus for fault tolerant connection of a computing system to local area networks |
-
1993
- 1993-12-15 JP JP31553093A patent/JP3599364B2/ja not_active Expired - Fee Related
-
1994
- 1994-09-07 US US08/301,781 patent/US5764914A/en not_active Expired - Fee Related
- 1994-09-08 GB GB9418152A patent/GB2284962B/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| GB2284962B (en) | 1998-05-20 |
| GB2284962A (en) | 1995-06-21 |
| US5764914A (en) | 1998-06-09 |
| GB9418152D0 (en) | 1994-10-26 |
| JPH07168778A (ja) | 1995-07-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3599364B2 (ja) | ネットワーク装置 | |
| US5551035A (en) | Method and apparatus for inter-object communication in an object-oriented program controlled system | |
| AU667559B2 (en) | System for changing software during computer operation | |
| US6892316B2 (en) | Switchable resource management in clustered computer system | |
| EP1179770A2 (en) | File system | |
| CN100359508C (zh) | 用于处理集群计算机系统的合并协议的方法和装置 | |
| EP0501610A2 (en) | Object oriented distributed computing system | |
| US20020152423A1 (en) | Persistent session and data in transparently distributed objects | |
| CN101243445A (zh) | 数据变更通告 | |
| US20090055444A1 (en) | Method and System for High-Availability Database | |
| US6119173A (en) | System and method for communications and process management in a distributed telecommunications switch | |
| EP0405829B1 (en) | Object oriented software system architecture | |
| US20060230109A1 (en) | Mediator-based recovery mechanism for multi-agent system | |
| JP3197279B2 (ja) | 業務引継システム | |
| JP3860587B2 (ja) | マルチプロセッサ装置 | |
| US5966713A (en) | Method for determining the contents of a restoration log | |
| JP2003271404A (ja) | マルチプロセッサシステム | |
| CA2244006A1 (en) | A process and apparatus for reducing software failures using sparing in distributed systems | |
| KR100579130B1 (ko) | 라우터 이중화 실현을 위한 라우팅 엔트리 정보 이중화 방법 | |
| CN117033033B (zh) | 服务总线中公共服务高效配置和交互的方法 | |
| JP3697467B2 (ja) | 交換機のオブジェクト更新システム | |
| JP3020205B2 (ja) | プロセッサ間通信情報復元方法 | |
| Wagealla et al. | Error detection algorithm for agent-based distributed applications | |
| CN113986610A (zh) | 一种容灾系统、实现业务设备容灾的方法和管理设备 | |
| JP2003114878A (ja) | 情報処理方法および情報処理装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040316 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040517 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040831 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040914 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080924 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |