JP4199322B2 - 情報処理装置及び情報処理装置のエラー採取方法 - Google Patents
情報処理装置及び情報処理装置のエラー採取方法 Download PDFInfo
- Publication number
- JP4199322B2 JP4199322B2 JP28087297A JP28087297A JP4199322B2 JP 4199322 B2 JP4199322 B2 JP 4199322B2 JP 28087297 A JP28087297 A JP 28087297A JP 28087297 A JP28087297 A JP 28087297A JP 4199322 B2 JP4199322 B2 JP 4199322B2
- Authority
- JP
- Japan
- Prior art keywords
- error
- information
- information processing
- occurred
- unit
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0778—Dumping, i.e. gathering error/state information after a fault for later diagnosis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
- G06F11/324—Display of status information
- G06F11/327—Alarm or error message display
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Debugging And Monitoring (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、本体側ＣＰＵと各種処理カードとからなるコンピュータシステム上でエラーが発生した場合における、エラー情報（ダンプ情報）の採取技術に関する。
【０００２】
【従来の技術及び発明が解決しようとする課題】
本体側ＣＰＵ（メインボード等）と各種処理カードとからなるコンピュータシステムにおいて、システムに対して要求される性能に応じて、本体側ＣＰＵ及び処理カード内でファームウエア又はプログラム等として実行される装置制御機能の構成が異なる場合がある。
【０００３】
即ち、特定の装置制御機能は、システムに対して要求される性能に応じて、本体側ＣＰＵ側で実行される場合と、処理カード側で実行される場合とがある。
このような場合に、何れかの装置制御機能においてエラー（又は異常）が発生した場合、又は当該装置制御機能が異常終了した場合に、当該装置制御機能又は当該装置制御機能を制御する機能によって上記エラーが検出され、モニタ（又はオペレーティングシステム）を介して表示装置等に、エラーメッセージが通知される。このようなエラーメッセージが通知された場合、一般ユーザは通常、システムエンジニアや管理者等のオペレータを呼んで復旧を依頼する。
【０００４】
オペレータは、通常、通知されたエラーメッセージに従って、エラーが発生したときの装置制御機能の動作状況を収集することにより、エラーの発生原因を特定してゆく。具体的には、オペレータは、モニタルチーンにダンプ採取コマンドを発行することによって、当該装置制御機能のメモリ空間上での実行イメージであるダンプ情報を採取し、その内容を逐次解析してゆく。ダンプ採取コマンドの発行においては、通常、ダンプ採取を指示するターゲット、上述の例では、本体側ＣＰＵ又は何れかの処理カードを指定する必要がある。
【０００５】
ここで、通知されるエラーメッセージには通常、エラーが発生した装置制御機能の種別（名称等）、エラー内容、及びエラー発生アドレス等が含まれるが、エラーが発生した装置制御機能が本体側ＣＰＵで実行されているのか何れかの処理カードで実行されているのかを示す情報は含まれていない。
【０００６】
従って、従来、オペレータは、エラーメッセージによって通知される制限された情報と、マニュアル又は仕様書等の記載、及び自分自身の経験のみに基づき、エラーが発生した装置制御機能が本体側ＣＰＵにおいて実行されているか何れかの処理カードにおいて実行されているかを判断し、その判断によって決定した本体側ＣＰＵ又は処理カードに対してダンプ採取コマンドを発行し、かつそのようにして採取したダンプ情報の中から装置制御機能に該当する部分を抽出する必要があった。
【０００７】
しかし、エラー発生時における当該装置制御機能の実行場所の特定と採取したダンプ情報からの該当部分の抽出は、豊富な経験を必要とするため、誰にでも行えるというものではなかった。このために、上述した従来技術は、エラー解析／復旧を行うことのできるオペレータが限定されてしまうという問題点を有していた。
【０００８】
通知されるエラーメッセージに当該装置制御機能の実行場所に関する情報を含ませることは、以下の理由で合理的でない。
その第１の理由は、エラー検出ルーチンに当該装置制御機能の実行場所に関する情報を通知機能まで持たせると、エラー検出ルーチンが複雑になるため、システム資源の圧迫やシステム性能の低下を招いてしまうからである。
【０００９】
第２の理由は、エラーメッセージに当該装置制御機能の実行場所に関する情報が含ませたとしても、ダンプ採取の対象が本体側ＣＰＵである場合と各種処理カードである場合とで、複数のダンプ採取コマンドを使い分ける必要があるため、結局は、適切なダンプ採取のためには熟練したオペレータを必要としてしまうからである。経験の浅いオペレータがかかるダンプ採取を行った場合には、誤ったダンプ情報を採取してしまったり、ダンプ情報が不足してしまったりするため、従来は、結局全てのダンプ情報を採取する傾向にあった。
【００１０】
一般ユーザ等でも、簡単なコマンドによってエラーが発生した装置制御機能に正確に対応するダンプ情報を採取することができれば、例えばその採取したダンプ情報をサポートセンターに送付又は転送することにより、熟練したオペレータを現場まで派遣する手間を省くことができる。しかし、従来は、上述した理由により、エラーが発生した装置制御機能が実行されている本体側ＣＰＵ又は処理カードを適切に特定し、かつ当該装置制御機能に適切に対応するダンプ情報のみを採取することは困難であった。
【００１１】
本発明の課題は、エラーメッセージに応答して簡単なダンプ採取コマンドを発行するだけで、エラーが発生した装置制御機能が実行されている本体側ＣＰＵ又は処理カードを自動的に特定し、当該装置制御機能に適切に対応するダンプ情報のみを採取可能とすることにある。
【００１２】
【課題を解決するための手段】
本発明は、本体側プロセッサ装置（本体側ＣＰＵ１０１）と処理カード（通信カード１０２、４０２）とからなるコンピュータシステム上でエラーが発生した場合におけるエラー情報の採取方法を前提とする。
【００１３】
本発明の第１の態様は、以下の構成を有する。
まず本体側プロセッサ装置又は処理カード内に、エラーが本体側プロセッサ装置内の装置制御部で発生したのか処理カード内の装置制御部で発生したのかを記憶する制御情報管理テーブル（制御情報管理テーブル１１１）が配置される。
【００１４】
次に、本体側プロセッサ装置又は処理カード内の装置制御部においてエラーが発生した場合に、その発生が制御情報管理テーブルに記録される。
続いて、エラーに対応するエラーメッセージが表示される。
【００１５】
そして、そのエラーメッセージに応答したエラー情報採取コマンドが発行された場合に、制御情報管理テーブルが参照されることにより、エラーが発生した装置制御部が実行されている本体側プロセッサ装置又は処理カードが特定され、その装置制御部に対応するエラー情報のみが採取される。
【００１６】
上述した本発明の第１の態様の構成では、オペレータは、エラーメッセージに応答する単純なエラー情報採取コマンドを発行するだけで、制御情報管理テーブルが参照されることにより、エラーが発生した装置制御部が実行されている本体側プロセッサ装置又は処理カードが自動的に特定され、当該装置制御部に適切に対応するエラー情報のみを取得することが可能となる。
【００１７】
本発明の第２の態様は、以下の構成を有する。
まず本体側プロセッサ装置又は処理カード内に、本体側プロセッサ装置内又は処理カード内の装置制御部毎に個別のエントリを有し、そのエントリ毎に、そのエントリに対応する装置制御部が本体側プロセッサ装置内に存在するのか処理カード内に存在するのかを示す識別情報を記憶するハードウエア構成情報記述テーブル（ハードウエア構成情報記述テーブル４１１）が配置される。
【００１８】
次に、本体側プロセッサ装置又は処理カード内の装置制御部においてエラーが発生した場合に、そのエラーに対応するエラーメッセージが表示される。
そして、そのエラーメッセージに応答したエラー情報採取コマンドが発行された場合に、ハードウエア構成情報記述テーブルが参照されることにより、エラーが発生した装置制御部が実行されている本体側プロセッサ装置又は処理カードが特定され、その装置制御部に対応するエラー情報のみが採取される。
【００１９】
上述した本発明の第２の態様の構成では、オペレータは、エラーメッセージを参照して単純なエラー情報採取コマンドを発行するだけで、ハードウエア構成情報記述テーブルが参照されることにより、エラーが発生した装置制御部が実行されている本体側プロセッサ装置又は処理カードが自動的に特定され、当該装置制御部に適切に対応するエラー情報のみを取得することが可能となる。
【００２０】
本発明の第３の態様は、以下の構成を有する。
まず本体側プロセッサ装置又は処理カード内に、本発明の第１の態様と同様の制御情報管理テーブル（制御情報管理テーブル１１１）と、本発明の第２の態様と同様のハードウエア構成情報記述テーブル（ハードウエア構成情報記述テーブル７０１）とが配置される。
【００２１】
次に、本体側プロセッサ装置又は処理カード内の装置制御部においてエラーが発生した場合に、その発生が制御情報管理テーブルに記録される。
続いて、エラーに対応するエラーメッセージが表示される。
【００２２】
そして、そのエラーメッセージに応答したエラー情報採取コマンドが発行された場合に、制御情報管理テーブル及びハードウエア構成情報記述テーブルの両方が参照されることにより、エラーが発生した装置制御部が実行されている本体側プロセッサ装置又は処理カードが特定され、その装置制御部に対応するエラー情報のみが採取される。
【００２３】
上述した本発明の第３の態様の構成では、より確実性の高いエラー情報採取が可能となる。
なお、本発明は、コンピュータにより使用されたときに、上述の本発明の各態様の構成によって実現される機能と同様の機能をコンピュータに行わせるためのコンピュータ読出し可能記録媒体として構成することもできる。
【００２４】
【発明の実施の形態】
以下、図面を参照しながら、本発明の実施の形態について詳細に説明する。
本発明の第１の実施の形態
図１は、本発明の第１の実施の形態の構成図である。
【００２５】
第１の実施の形態におけるコンピュータシステムは、本体側ＣＰＵ１０１にインテリジェントなＬＡＮ（ローカルエリアネットワーク）カードである通信カード１０２が接続された構成を有し、オペレータ１０５は、本体側ＣＰＵ１０１内で実行されているモニタ１０４を介して、エラーメッセージを通知され、またそのエラーメッセージに応答してダンプ採取コマンドを発行する。
【００２６】
本体側ＣＰＵ１０１内で動作するドライバ１０６を構成するネットワーク共通部１０７及びＬＡＮマルチプロトコル制御部１０８の各機能部と、通信カード１０２内で動作するＴＣＰ／ＩＰ制御部１０９及びＬＡＮカード制御部１１０の各機能部とによって、通信制御機能１０３が実現される。
【００２７】
ネットワーク共通部１０７は、モニタ１０４とのインタフェース機能、共通関数の実行機能、バッファ管理機能等を有する。
ＬＡＮマルチプロトコル制御部１０８は、ＴＣＰ／ＩＰ（転送制御プロトコル／インターネットプロトコル）を始めとする各種通信プロトコルを終端する機能を有する。
【００２８】
ＴＣＰ／ＩＰ制御部１０９は、ＬＡＮカード制御部１１０を介して特には図示しないＬＡＮと本体側ＣＰＵ１０１との間のＴＣＰ／ＩＰ通信の全般を制御する機能を有する。
【００２９】
ＬＡＮカード制御部１１０は、特には図示しないＬＡＮに対する物理インタフェース機能を有する。
制御情報管理テーブル１１１は、本発明に特に関連し、本体側ＣＰＵ１０１内の特には図示しないメモリ又は記憶装置上に保持される。なお、この制御情報管理テーブル１１１は、通信カード１０２内のメモリ又は記憶装置上に保持されてもよい。図２は、制御情報管理テーブル１１１のデータ構成図である。
【００３０】
制御情報管理テーブル１１１は、図２に示されるように、エラー（異常）が本体側ＣＰＵ１０１内のドライバ１０６で発生したのか通信カード１０２内で発生したのかを特定するためのフラグビットｂｉｔ７及びｂｉｔ６と、より具体的な発生箇所を特定するためのフラグビットｂｉｔ３、ｂｉｔ２、ｂｉｔ１、及びｂｉｔ０を有する。
【００３１】
即ち、エラー（異常）が本体側ＣＰＵ１０１内のドライバ１０６内で発生した場合はフラグビットｂｉｔ７が立てられ、エラーが通信カード１０２内で発生した場合はフラグビットｂｉｔ６が立てられる。
【００３２】
また、エラーが本体側ＣＰＵ１０１内のドライバ１０６を構成するネットワーク共通制御部１０７で発生した場合はフラグビットｂｉｔ３が立てられ、エラーが本体側ＣＰＵ１０１内のドライバ１０６を構成するＬＡＮマルチプロトコル制御部１０８で発生した場合はフラグビットｂｉｔ２が立てられる。
【００３３】
更に、エラーが通信カード１０２内のＴＣＰ／ＩＰ制御部１０９で発生した場合はフラグビットｂｉｔ１が立てられ、エラーが通信カード１０２内のＬＡＮカード制御部１１０で発生した場合はフラグビットｂｉｔ０が立てられる。
【００３４】
図３は、例として、通信カード１０２内のＴＣＰ／ＩＰ制御部１０９でエラーが発生したときに実行される、本発明の第１の実施の形態の動作フローチャートである。
【００３５】
まず、ＴＣＰ／ＩＰ制御部１０９自身でエラーが検出されると、例えばその例外処理ルーチンが起動される（ステップ３０１）。
この結果、ＴＣＰ／ＩＰ制御部１０９は、本体側ＣＰＵ１０１内の制御情報管理テーブル１１１内のフラグビットｂｉｔ６とｂｉｔ１を立てる（ステップ３０２）。
【００３６】
続いて、通信カード１０２が本体側ＣＰＵ１０１内のモニタ１０４に対して、インタラプトをかけることによりエラー検出通知を行う（ステップ３０３）。
モニタ１０４は、オペレータ１０５に対して、通信制御機能１０３内でエラー検出したことをエラーメッセージとして通知する（ステップ３０４）。
【００３７】
オペレータ１０５は、そのエラーメッセージに応答して、ダンプ採取コマンドを発行する（ステップ３０５）。このコマンドは、従来技術におけるような本体側ＣＰＵ１０１又は通信カード１０２を指示する複雑なものである必要はなく、通知されたエラーメッセージに対して単にダンプ採取を指示するだけの簡単なシンタックスを有する。即ち、オペレータ１０５は、このダンプ採取コマンドの発行に際して、エラーが発生したファームウエア又はプログラムが実行されている本体側ＣＰＵ１０１又は通信カード１０２を明示的に特定する必要はない。
【００３８】
モニタ１０４は、上記ダンプ採取コマンドを受け付けると、制御情報管理テーブル１１１を参照し（ステップ３０６）、そのテーブル内のフラグビットｂｉｔ６とｂｉｔ１が立っているか否かを判定する（ステップ３０７）。
【００３９】
モニタ１０４は、制御情報管理テーブル１１１内のフラグビットｂｉｔ６とｂｉｔ１が立っていると判定した場合には、通信カード１０２に対してＴＣＰ／ＩＰ制御部１０９を特定したダンプ採取コマンドを発行する。この結果、通信カード１０２に割り当てられたメモリ空間上でのＴＣＰ／ＩＰ制御部１０９の実行イメージであるダンプ情報が採取され、本体側ＣＰＵ１０１内の特には図示しないファイルシステムにダンプファイル等として保存される（ステップ３０７→３０８）。
【００４０】
モニタ１０４は、制御情報管理テーブル１１１内のフラグビットｂｉｔ６とｂｉｔ１の両方が立ってはいないと判定した場合には、制御情報管理テーブル１１１内の他のフラグビットが立っているか否かの検索と、その検索結果に応じた必要なダンプ採取を実行する（ステップ３０７→３０９）。
【００４１】
以上のように、本発明の第１の実施の形態では、オペレータ１０５は、エラーメッセージに応答する単純なダンプ採取コマンドを発行するだけで、モニタ１０４が制御情報管理テーブル１１１を参照することにより、エラーが発生した制御部が実行されている本体側ＣＰＵ１０１又は通信カード１０２を自動的に特定し、当該制御部に適切に対応するダンプ情報のみを採取することが可能となる。
本発明の第２の実施の形態
図４は、本発明の第２の実施の形態の構成図である。
【００４２】
第２の実施の形態におけるコンピュータシステムは、本体側ＣＰＵ４０１にそれぞれがノンインテリジェントなＬＡＮカードである複数（＃１及び＃２）の通信カード４０２が接続された構成を有し、オペレータ４０５は、本体側ＣＰＵ４０１内で実行されているモニタ４０４を介して、エラーメッセージを通知され、またそのエラーメッセージに応答してダンプ採取コマンドを発行する。
【００４３】
本体側ＣＰＵ４０１内では、通信カード４０２（＃１）を制御するためのドライバ４０６（＃１）と、通信カード４０２（＃２）を制御するためのドライバ４０６（＃２）とが動作している。
【００４４】
本発明の第２の実施の形態では、図１に示される本発明の第１の実施の形態におけるネットワーク共通制御部１０７と同様の機能を有するネットワーク共通制御部４０７と、同じく図１におけるＬＡＮマルチプロトコル制御部１０８と同様の機能を有するＬＡＮマルチプロトコル制御部４０９が、本体側ＣＰＵ４０１内のドライバ４０６（＃１）とドライバ４０６（＃２）にまたがって含まれる。
【００４５】
また、本発明の第２の実施の形態では、図１に示される本発明の第１の実施の形態では通信カード１０２内に実装されていたＴＣＰ／ＩＰ制御部１０９と同様の機能を有するＴＣＰ／ＩＰ制御部４０８（＃１）と、同じく図１において通信カード１０２内に実装されていたＬＡＮカード制御部１１０と同様の機能を有するＬＡＮカード制御部４１０（＃１）が、通信カード４０２（＃１）に対応する本体側ＣＰＵ４０１内のドライバ４０６（＃１）に含まれる。
【００４６】
更に、本発明の第２の実施の形態では、ＯＳＩ制御部４０８（＃２）とＬＡＮカード制御部４１０（＃２）が、通信カード４０２（＃２）に対応する本体側ＣＰＵ４０１内のドライバ４０６（＃２）に含まれる。
【００４７】
ＯＳＩ制御部４０８（＃２）は、ＬＡＮカード制御部４１０（＃２）を介して特には図示しないＬＡＮと本体側ＣＰＵ４０１との間のＯＳＩ通信の全般を制御する機能を有する。
【００４８】
上述した構成を有する本体側ＣＰＵ４０１内の２つのドライバ４０６（＃１、＃２）と、２枚の通信カード４０２（＃１、＃２）とによって、通信制御機能４０３が実現される。
【００４９】
本発明の第２の実施の形態では、本発明に特に関連する機能として、ハードウエア構成情報記述テーブル４１１（＃１）及び４１１（＃２）が、それぞれ通信カード４０２（＃１）及び４０２（＃２）内のメモリ又は記憶装置上に保持される。なお、これらハードウエア構成情報記述テーブル４１１（＃１、＃２）は、本体側ＣＰＵ４０１内のメモリ又は記憶装置上に保持されてもよい。
【００５０】
図５は、ハードウエア構成情報記述テーブル４１１のデータ構成図である。
このハードウエア構成情報記述テーブル４１１は、ＴＣＰ／ＩＰ制御部４０８（＃１）、ＯＳＩ制御部４０８（＃２）、ＬＡＮカード制御部４１０（＃１）、ＬＡＮカード制御部４１０（＃２）といった、通信カード４０２側に実装される可能性のある制御部毎に、個別のエントリＸＸＸ、ＹＹＹ、・・・を有する。そして、各エントリ毎に、そのエントリに対応する制御部（装置制御プログラム）が本体側ＣＰＵ４０１内に存在するか通信カード４０２内に存在するかを示すためのフラグビットｂｉｔ７及びｂｉｔ６と、各制御部がシステム内（本体側ＣＰＵ４０１又は通信カード４０２）に存在するか否かを示すためのフラグビットｂｉｔ３、ｂｉｔ２、ｂｉｔ１、及びｂｉｔ０を有する。
【００５１】
即ち各エントリ毎に、そのエントリに対応する制御部（装置制御プログラム）が、本体側ＣＰＵ４０１内に存在する場合はフラグビットｂｉｔ７が立てられ、通信カード４０２内に存在する場合はフラグビットｂｉｔ６が立てられる。
【００５２】
また各エントリ毎に、ネットワーク共通制御部４０７がシステム内に存在する場合はフラグビットｂｉｔ３が立てられ、そのエントリに対応するＴＣＰ／ＩＰ制御部４０８（＃１）又はＯＳＩ制御部４０８（＃２）の何れかがシステム内に存在する場合はフラグビットｂｉｔ２が立てられ、ＬＡＮマルチプロトコル制御部４０９がシステム内に存在する場合はフラグビットｂｉｔ１が立てられ、そのエントリに対応するＬＡＮカード制御部４１０（＃１）又は４１０（＃２）の何れかがシステム内に存在する場合はフラグビットｂｉｔ０が立てられる。
【００５３】
図６は、例として、ＴＣＰ／ＩＰ制御部４０８（＃１）又はＯＳＩ制御部４０８（＃２）でエラーが発生したときに実行される、本発明の第２の実施の形態の動作フローチャートである。
【００５４】
まず、ＴＣＰ／ＩＰ制御部４０８（＃１）又はＯＳＩ制御部４０８（＃２）でエラーが検出されると、例えばその例外処理ルーチンが起動される（ステップ６０１）。
【００５５】
この結果、ＴＣＰ／ＩＰ制御部４０８（＃１）又はＯＳＩ制御部４０８（＃２）が、本体側ＣＰＵ４０１内のモニタ４０４に対して、インタラプトをかけることによりエラー検出通知を行う（ステップ６０２）。
【００５６】
モニタ４０４は、オペレータ４０５に対して、ＴＣＰ／ＩＰ制御部４０８（＃１）又はＯＳＩ制御部４０８（＃２）でエラー検出したことをエラーメッセージとして通知する（ステップ６０３）。
【００５７】
オペレータ４０５は、そのエラーメッセージを参照して、モニタ４０４に、ＴＣＰ／ＩＰ制御部４０８（＃１）又はＯＳＩ制御部４０８（＃２）のダンプ採取コマンドを発行する（ステップ６０４）。この時点まではモニタ４０４はＴＣＰ／ＩＰ制御部４０８（＃１）又はＯＳＩ制御部４０８（＃２）が本体側ＣＰＵ４０１内のドライバ４０６側に存在することは知らない。このコマンドは、従来技術におけるような複雑なものである必要はなく、通知されたエラーメッセージに表示されている制御部を指定したダンプ採取を指示するだけの簡単なシンタックスを有する。即ち、オペレータ４０５は、このダンプ採取コマンドの発行に際して、エラーが発生したファームウエア又はプログラムが実行されている本体側ＣＰＵ４０１又は通信カード４０２を明示的に特定する必要はない。
【００５８】
モニタ４０４は、上記ダンプ採取コマンドを受け付けると、まず、通信カード４０２（＃１）内のハードウエア構成情報記述テーブル４１１（＃１）を参照する（ステップ６０５）。
【００５９】
そして、ＴＣＰ／ＩＰ制御部４０８（＃１）に対応するエントリＸＸＸのフラグビットｂｉｔ７とｂｉｔ２が立っているか否かを判定する（ステップ６０６）。
【００６０】
モニタ４０４は、ハードウエア構成情報記述テーブル４１１（＃１）内のフラグビットｂｉｔ７とｂｉｔ２が立っていると判定した場合には、エラーが検出されたのが本体側ＣＰＵ４０１内のドライバ４０６（＃１）を構成するＴＣＰ／ＩＰ制御部４０８（＃１）であると認識できるため、本体側ＣＰＵ４０１内のドライバ４０６（＃１）を構成するＴＣＰ／ＩＰ制御部４０８（＃１）を特定したダンプ採取コマンドを発行する。この結果、本体側ＣＰＵ４０１内のドライバ４０６に割り当てられたメモリ空間上でのＴＣＰ／ＩＰ制御部４０８（＃１）の実行イメージであるダンプ情報が採取され、本体側ＣＰＵ４０１内の特には図示しないファイルシステムにダンプファイル等として保存される（ステップ６０６→６０７）。
【００６１】
モニタ４０４は、ハードウエア構成情報記述テーブル４１１（＃１）内のフラグビットｂｉｔ７とｂｉｔ２の両方が立ってはいないと判定した場合には、ハードウエア構成情報記述テーブル４１１（＃１）において、ＴＣＰ／ＩＰ制御部４０８（＃１）に対応するエントリＸＸＸのフラグビットｂｉｔ６とｂｉｔ２が立っているか否かを判定する（ステップ６０８）。
【００６２】
モニタ４０４は、ハードウエア構成情報記述テーブル４１１（＃１）内のフラグビットｂｉｔ６とｂｉｔ２が立っていると判定した場合には、エラーが検出されたのが図４の場合とは異なる通信カード４０２（＃１）内で実行されているＴＣＰ／ＩＰ制御部４０８（＃１）であると認識できるため、通信カード４０２（＃１）内のＴＣＰ／ＩＰ制御部４０８（＃１）を特定したダンプ採取コマンドを発行する。この結果、通信カード４０２（＃１）に割り当てられたメモリ空間上でのＴＣＰ／ＩＰ制御部４０８（＃１）の実行イメージであるダンプ情報が採取され、本体側ＣＰＵ４０１内の特には図示しないファイルシステムにダンプファイル等として保存される（ステップ６０８→６０９）。
【００６３】
モニタ４０４は、ハードウエア構成情報記述テーブル４１１（＃１）内のフラグビットｂｉｔ６とｂｉｔ２についてもその両方が立ってはいないと判定した場合は、エラーが検出されたのがＴＣＰ／ＩＰ制御部４０８（＃１）ではなくＯＳＩ制御部４０８（＃２）であると認識できるため、今度は通信カード４０２（＃２）内のハードウエア構成情報記述テーブル４１１（＃２）を参照して、上述のステップ６０６〜６０９と同様の制御処理を実行して、該当するダンプ情報を採取する（ステップ６１０）。
【００６４】
以上のように、本発明の第２の実施の形態では、オペレータ１０５は、エラーメッセージを参照して単純なダンプ採取コマンドを発行するだけで、モニタ４０４がハードウエア構成情報記述テーブル４１１（＃１、＃２）を参照することにより、エラーが発生した制御部が実行されている本体側ＣＰＵ４０１又は通信カード４０２（＃１、＃２）を自動的に特定し、当該制御部に適切に対応するダンプ情報のみを採取することが可能となる。
本発明の第３の実施の形態
図７は、本発明の第３の実施の形態の構成図である。
【００６５】
図７に示される本発明の第３の実施の形態の構成は、基本的には図１に示される本発明の第１の実施の形態の構成と同じであるが、本体側ＣＰＵ１０１内に、制御情報管理テーブル１１１に加えてハードウエア構成情報記述テーブル７０１が配置されている点が図１の構成と異なる。
【００６６】
図７の制御情報管理テーブル１１１は、本発明の第１の実施の形態の場合と同様の図２に示される構成を有し、ハードウエア構成情報記述テーブル７０１は、本発明の第２の実施の形態の場合と同様の図５に示される構成を有する。
【００６７】
この場合に、各エントリ毎に、そのエントリに対応する制御部（装置制御プログラム）が、本体側ＣＰＵ１０１内に存在する場合はフラグビットｂｉｔ７が立てられ、通信カード１０２内に存在する場合はフラグビットｂｉｔ６が立てられる。
【００６８】
また各エントリ毎に、ネットワーク共通制御部１０７がシステム内に存在する場合はフラグビットｂｉｔ３が立てられ、ＬＡＮマルチプロトコル制御部１０８がシステム内に存在する場合はフラグビットｂｉｔ２が立てられ、ＴＣＰ／ＩＰ制御部１０９がシステム内に存在する場合はフラグビットｂｉｔ１が立てられ、ＬＡＮカード制御部１１０がシステム内に存在する場合はフラグビットｂｉｔ０が立てられる。
【００６９】
なお、制御情報管理テーブル１１１とハードウエア構成情報記述テーブル７０１は、通信カード１０２内のメモリ又は記憶装置上に保持されてもよい。
本発明の第３の実施の形態では、制御情報管理テーブル１１１とハードウエア構成情報記述テーブル７０１の両方の内容を使ってエラーが発生した制御部が特定されダンプ情報が採取されることが、本発明に関連する特徴である。
【００７０】
図８は、例として、通信カード１０２内のＴＣＰ／ＩＰ制御部１０９でエラーが発生したときに実行される、本発明の第３の実施の形態の動作フローチャートである。
【００７１】
まず、ＴＣＰ／ＩＰ制御部１０９自身でエラーが検出されると、例えばその例外処理ルーチンが起動される（ステップ８０１）。
この結果、ＴＣＰ／ＩＰ制御部１０９は、本体側ＣＰＵ１０１内の制御情報管理テーブル１１１内のフラグビットｂｉｔ６とｂｉｔ１を立てる（ステップ８０２）。
【００７２】
続いて、通信カード１０２が本体側ＣＰＵ１０１内のモニタ１０４に対して、インタラプトをかけることによりエラー検出通知を行う（ステップ８０３）。
モニタ１０４は、オペレータ１０５に対して、通信制御機能１０３内でエラー検出したことをエラーメッセージとして通知する（ステップ８０４）。
【００７３】
オペレータ１０５は、そのエラーメッセージに応答して、ダンプ採取コマンドを発行する（ステップ８０５）。このコマンドは、本発明の第１の実施の形態の場合と同様に、通知されたエラーメッセージに対して単にダンプ採取を指示するだけの簡単なシンタックスを有する。
【００７４】
モニタ１０４は、上記ダンプ採取コマンドを受け付けると、制御情報管理テーブル１１１を参照し（ステップ８０６）、そのテーブル内のフラグビットｂｉｔ６とｂｉｔ１が立っているか否かを判定する（ステップ８０７）。
【００７５】
モニタ１０４は、制御情報管理テーブル１１１内のフラグビットｂｉｔ６とｂｉｔ１が立っていると判定した場合には、通信カード１０２に対してＴＣＰ／ＩＰ制御部１０９を特定したダンプ採取を行えばよいことを認識する（ステップ８０７→８０８）。
【００７６】
モニタ１０４は、制御情報管理テーブル１１１内のフラグビットｂｉｔ６とｂｉｔ１の両方が立ってはいないと判定した場合には、制御情報管理テーブル１１１内の他のフラグビットが立っているか否かの検索と、その検索結果に応じた必要なダンプ採取を実行する（ステップ８０７→８０９）。
【００７７】
上述のステップ８０４〜８０９の制御処理に続いて、モニタ１０４は、以下のステップ８１０〜８１５の制御処理を実行する。
即ちまず、モニタ１０４は、オペレータ１０５に対して、ＴＣＰ／ＩＰ制御部１０９でエラー検出したことをエラーメッセージとして通知する（ステップ８１０）。
【００７８】
オペレータ１０５は、そのエラーメッセージを参照して、モニタ１０４に、ＴＣＰ／ＩＰ制御部１０９のダンプ採取コマンドを発行する（ステップ８１１）。この時点まではモニタ１０４はＴＣＰ／ＩＰ制御部１０９が通信カード側１０２に存在することは知らない。このコマンドは、本発明の第２の実施の形態の場合と同様に、通知されたエラーメッセージに表示されている制御部を指定したダンプ採取を指示するだけの簡単なシンタックスを有する。
【００７９】
モニタ１０４は、上記ダンプ採取コマンドを受け付けると、ハードウエア構成情報記述テーブル７０１を参照する（ステップ８１２）。
そして、ＴＣＰ／ＩＰ制御部１０９に対応するエントリＸＸＸのフラグビットｂｉｔ６とｂｉｔ１が立っているか否かを判定する（ステップ８１３）。
【００８０】
モニタ１０４は、ハードウエア構成情報記述テーブル７０１内のフラグビットｂｉｔ６とｂｉｔ１が立っていると判定した場合には、エラーが検出されたのが通信カード１０２内のＴＣＰ／ＩＰ制御部１０９であると認識できるため、通信カード１０２内のＴＣＰ／ＩＰ制御部１０９を特定したダンプ採取を行えばよいことを認識する（ステップ８１３→８１４）。
【００８１】
モニタ１０４は、ハードウエア構成情報記述テーブル７０１内のフラグビットｂｉｔ６とｂｉｔ１の両方が立ってはいないと判定した場合には、ＴＣＰ／ＩＰ制御部１０９に対応するエントリＸＸＸのフラグビットｂｉｔ７とｂｉｔ１が立っているか否か、即ちＴＣＰ／ＩＰ制御部１０９が本体側ＣＰＵ１０１内に存在するか否かを判定する処理等を実行する（ステップ８１５）。
【００８２】
モニタ１０４は、ステップ８０８及び８１４の認識結果を得た後、両方の認識結果が一致しているか否かを判定する（ステップ８１６）。
モニタ１０４は、ステップ８０８及び８１４の両方の認識結果が一致していると判定した場合には、通信カード１０２に割り当てられたメモリ空間上でのＴＣＰ／ＩＰ制御部１０９の実行イメージであるダンプ情報を採取し、本体側ＣＰＵ１０１内の特には図示しないファイルシステムにダンプファイル等として保存する（ステップ８１６→８１７）。
【００８３】
モニタ１０４は、ステップ８０８及び８１４の両方の認識結果が一致していないと判定した場合には、何等かの異常が発生しているとしてエラー終了する（ステップ８１６→８１８）。
【００８４】
以上のように、本発明の第３の実施の形態では、より確実性の高いダンプ採取が可能となる。
エラーメッセージの例
図９〜図１２に、オペレータ１０５（図１、図７）又はオペレータ４０５（図４）に対して表示されるエラーメッセージの例（各図(a) ）と、それぞれに対応するマニュアル等の記述（各図(b) ）を示す。
各実施の形態を実現するプログラムが記録された記録媒体についての補足
本発明は、コンピュータにより使用されたときに、上述の本発明の各実施の形態の各構成によって実現される機能と同様の機能をコンピュータに行わせるためのコンピュータ読出し可能記録媒体として構成することもできる。
【００８５】
この場合に、図１３に示されるように、例えばフロッピィディスク、ＣＤ−ＲＯＭディスク、光磁気ディスク、リムーバブルハードディスク等の可搬型記録媒体１３０２や、ネットワーク回線１３０３経由で、本発明の各実施の形態の各種機能を実現するプログラムが、本体側ＣＰＵ１０１又は４０１に対応するコンピュータ１３０１の本体１３０４内のメモリ（ＲＡＭ又はハードディスク等）１３０５にロードされて、実行される。
【００８６】
【発明の効果】
本発明の第１の態様の構成によれば、オペレータは、エラーメッセージに応答する単純なエラー情報採取コマンドを発行するだけで、制御情報管理テーブルが参照されることにより、エラーが発生した装置制御部が実行されている本体側プロセッサ装置又は処理カードが自動的に特定され、当該装置制御部に適切に対応するエラー情報のみを取得することが可能となる。
【００８７】
本発明の第２の態様の構成によれば、オペレータは、エラーメッセージを参照して単純なエラー情報採取コマンドを発行するだけで、ハードウエア構成情報記述テーブルが参照されることにより、エラーが発生した装置制御部が実行されている本体側プロセッサ装置又は処理カードが自動的に特定され、当該装置制御部に適切に対応するエラー情報のみを取得することが可能となる。
【００８８】
本発明の第３の態様の構成によれば、より確実性の高いエラー情報採取が可能となる。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態の構成図である。
【図２】制御情報管理テーブルの構成図である。
【図３】本発明の第１の実施の形態の動作フローチャートである。
【図４】本発明の第２の実施の形態の構成図である。
【図５】ハードウエア構成情報記述テーブルの構成図である。
【図６】本発明の第２の実施の形態の動作フローチャートである。
【図７】本発明の第３の実施の形態の構成図である。
【図８】本発明の第３の実施の形態の動作フローチャートである。
【図９】エラーメッセージ例（その１）を示す図である。
【図１０】エラーメッセージ例（その２）を示す図である。
【図１１】エラーメッセージ例（その３）を示す図である。
【図１２】エラーメッセージ例（その４）を示す図である。
【図１３】各実施の形態を実現するプログラムが記録された記録媒体の説明図である。
【符号の説明】
１０１、４０１ 本体側ＣＰＵ
１０２、４０２（＃１、＃２） 通信カード
１０３、４０３ 通信制御機能
１０４、４０４ モニタ
１０５、４０５ オペレータ
１０６、４０６（＃１、＃２） ドライバ
１０７、４０７ ネットワーク共通制御部
１０８、４０９ ＬＡＮマルチプロトコル制御部
１０９、４０８（＃１） ＴＣＰ／ＩＰ制御部
１１０、４１０（＃１、＃２） ＬＡＮカード制御部
１１１ 制御情報管理テーブル
４１１（＃１、＃２）、７０１ ハードウエア構成情報記述テーブル
【発明の属する技術分野】
本発明は、本体側ＣＰＵと各種処理カードとからなるコンピュータシステム上でエラーが発生した場合における、エラー情報（ダンプ情報）の採取技術に関する。
【０００２】
【従来の技術及び発明が解決しようとする課題】
本体側ＣＰＵ（メインボード等）と各種処理カードとからなるコンピュータシステムにおいて、システムに対して要求される性能に応じて、本体側ＣＰＵ及び処理カード内でファームウエア又はプログラム等として実行される装置制御機能の構成が異なる場合がある。
【０００３】
即ち、特定の装置制御機能は、システムに対して要求される性能に応じて、本体側ＣＰＵ側で実行される場合と、処理カード側で実行される場合とがある。
このような場合に、何れかの装置制御機能においてエラー（又は異常）が発生した場合、又は当該装置制御機能が異常終了した場合に、当該装置制御機能又は当該装置制御機能を制御する機能によって上記エラーが検出され、モニタ（又はオペレーティングシステム）を介して表示装置等に、エラーメッセージが通知される。このようなエラーメッセージが通知された場合、一般ユーザは通常、システムエンジニアや管理者等のオペレータを呼んで復旧を依頼する。
【０００４】
オペレータは、通常、通知されたエラーメッセージに従って、エラーが発生したときの装置制御機能の動作状況を収集することにより、エラーの発生原因を特定してゆく。具体的には、オペレータは、モニタルチーンにダンプ採取コマンドを発行することによって、当該装置制御機能のメモリ空間上での実行イメージであるダンプ情報を採取し、その内容を逐次解析してゆく。ダンプ採取コマンドの発行においては、通常、ダンプ採取を指示するターゲット、上述の例では、本体側ＣＰＵ又は何れかの処理カードを指定する必要がある。
【０００５】
ここで、通知されるエラーメッセージには通常、エラーが発生した装置制御機能の種別（名称等）、エラー内容、及びエラー発生アドレス等が含まれるが、エラーが発生した装置制御機能が本体側ＣＰＵで実行されているのか何れかの処理カードで実行されているのかを示す情報は含まれていない。
【０００６】
従って、従来、オペレータは、エラーメッセージによって通知される制限された情報と、マニュアル又は仕様書等の記載、及び自分自身の経験のみに基づき、エラーが発生した装置制御機能が本体側ＣＰＵにおいて実行されているか何れかの処理カードにおいて実行されているかを判断し、その判断によって決定した本体側ＣＰＵ又は処理カードに対してダンプ採取コマンドを発行し、かつそのようにして採取したダンプ情報の中から装置制御機能に該当する部分を抽出する必要があった。
【０００７】
しかし、エラー発生時における当該装置制御機能の実行場所の特定と採取したダンプ情報からの該当部分の抽出は、豊富な経験を必要とするため、誰にでも行えるというものではなかった。このために、上述した従来技術は、エラー解析／復旧を行うことのできるオペレータが限定されてしまうという問題点を有していた。
【０００８】
通知されるエラーメッセージに当該装置制御機能の実行場所に関する情報を含ませることは、以下の理由で合理的でない。
その第１の理由は、エラー検出ルーチンに当該装置制御機能の実行場所に関する情報を通知機能まで持たせると、エラー検出ルーチンが複雑になるため、システム資源の圧迫やシステム性能の低下を招いてしまうからである。
【０００９】
第２の理由は、エラーメッセージに当該装置制御機能の実行場所に関する情報が含ませたとしても、ダンプ採取の対象が本体側ＣＰＵである場合と各種処理カードである場合とで、複数のダンプ採取コマンドを使い分ける必要があるため、結局は、適切なダンプ採取のためには熟練したオペレータを必要としてしまうからである。経験の浅いオペレータがかかるダンプ採取を行った場合には、誤ったダンプ情報を採取してしまったり、ダンプ情報が不足してしまったりするため、従来は、結局全てのダンプ情報を採取する傾向にあった。
【００１０】
一般ユーザ等でも、簡単なコマンドによってエラーが発生した装置制御機能に正確に対応するダンプ情報を採取することができれば、例えばその採取したダンプ情報をサポートセンターに送付又は転送することにより、熟練したオペレータを現場まで派遣する手間を省くことができる。しかし、従来は、上述した理由により、エラーが発生した装置制御機能が実行されている本体側ＣＰＵ又は処理カードを適切に特定し、かつ当該装置制御機能に適切に対応するダンプ情報のみを採取することは困難であった。
【００１１】
本発明の課題は、エラーメッセージに応答して簡単なダンプ採取コマンドを発行するだけで、エラーが発生した装置制御機能が実行されている本体側ＣＰＵ又は処理カードを自動的に特定し、当該装置制御機能に適切に対応するダンプ情報のみを採取可能とすることにある。
【００１２】
【課題を解決するための手段】
本発明は、本体側プロセッサ装置（本体側ＣＰＵ１０１）と処理カード（通信カード１０２、４０２）とからなるコンピュータシステム上でエラーが発生した場合におけるエラー情報の採取方法を前提とする。
【００１３】
本発明の第１の態様は、以下の構成を有する。
まず本体側プロセッサ装置又は処理カード内に、エラーが本体側プロセッサ装置内の装置制御部で発生したのか処理カード内の装置制御部で発生したのかを記憶する制御情報管理テーブル（制御情報管理テーブル１１１）が配置される。
【００１４】
次に、本体側プロセッサ装置又は処理カード内の装置制御部においてエラーが発生した場合に、その発生が制御情報管理テーブルに記録される。
続いて、エラーに対応するエラーメッセージが表示される。
【００１５】
そして、そのエラーメッセージに応答したエラー情報採取コマンドが発行された場合に、制御情報管理テーブルが参照されることにより、エラーが発生した装置制御部が実行されている本体側プロセッサ装置又は処理カードが特定され、その装置制御部に対応するエラー情報のみが採取される。
【００１６】
上述した本発明の第１の態様の構成では、オペレータは、エラーメッセージに応答する単純なエラー情報採取コマンドを発行するだけで、制御情報管理テーブルが参照されることにより、エラーが発生した装置制御部が実行されている本体側プロセッサ装置又は処理カードが自動的に特定され、当該装置制御部に適切に対応するエラー情報のみを取得することが可能となる。
【００１７】
本発明の第２の態様は、以下の構成を有する。
まず本体側プロセッサ装置又は処理カード内に、本体側プロセッサ装置内又は処理カード内の装置制御部毎に個別のエントリを有し、そのエントリ毎に、そのエントリに対応する装置制御部が本体側プロセッサ装置内に存在するのか処理カード内に存在するのかを示す識別情報を記憶するハードウエア構成情報記述テーブル（ハードウエア構成情報記述テーブル４１１）が配置される。
【００１８】
次に、本体側プロセッサ装置又は処理カード内の装置制御部においてエラーが発生した場合に、そのエラーに対応するエラーメッセージが表示される。
そして、そのエラーメッセージに応答したエラー情報採取コマンドが発行された場合に、ハードウエア構成情報記述テーブルが参照されることにより、エラーが発生した装置制御部が実行されている本体側プロセッサ装置又は処理カードが特定され、その装置制御部に対応するエラー情報のみが採取される。
【００１９】
上述した本発明の第２の態様の構成では、オペレータは、エラーメッセージを参照して単純なエラー情報採取コマンドを発行するだけで、ハードウエア構成情報記述テーブルが参照されることにより、エラーが発生した装置制御部が実行されている本体側プロセッサ装置又は処理カードが自動的に特定され、当該装置制御部に適切に対応するエラー情報のみを取得することが可能となる。
【００２０】
本発明の第３の態様は、以下の構成を有する。
まず本体側プロセッサ装置又は処理カード内に、本発明の第１の態様と同様の制御情報管理テーブル（制御情報管理テーブル１１１）と、本発明の第２の態様と同様のハードウエア構成情報記述テーブル（ハードウエア構成情報記述テーブル７０１）とが配置される。
【００２１】
次に、本体側プロセッサ装置又は処理カード内の装置制御部においてエラーが発生した場合に、その発生が制御情報管理テーブルに記録される。
続いて、エラーに対応するエラーメッセージが表示される。
【００２２】
そして、そのエラーメッセージに応答したエラー情報採取コマンドが発行された場合に、制御情報管理テーブル及びハードウエア構成情報記述テーブルの両方が参照されることにより、エラーが発生した装置制御部が実行されている本体側プロセッサ装置又は処理カードが特定され、その装置制御部に対応するエラー情報のみが採取される。
【００２３】
上述した本発明の第３の態様の構成では、より確実性の高いエラー情報採取が可能となる。
なお、本発明は、コンピュータにより使用されたときに、上述の本発明の各態様の構成によって実現される機能と同様の機能をコンピュータに行わせるためのコンピュータ読出し可能記録媒体として構成することもできる。
【００２４】
【発明の実施の形態】
以下、図面を参照しながら、本発明の実施の形態について詳細に説明する。
本発明の第１の実施の形態
図１は、本発明の第１の実施の形態の構成図である。
【００２５】
第１の実施の形態におけるコンピュータシステムは、本体側ＣＰＵ１０１にインテリジェントなＬＡＮ（ローカルエリアネットワーク）カードである通信カード１０２が接続された構成を有し、オペレータ１０５は、本体側ＣＰＵ１０１内で実行されているモニタ１０４を介して、エラーメッセージを通知され、またそのエラーメッセージに応答してダンプ採取コマンドを発行する。
【００２６】
本体側ＣＰＵ１０１内で動作するドライバ１０６を構成するネットワーク共通部１０７及びＬＡＮマルチプロトコル制御部１０８の各機能部と、通信カード１０２内で動作するＴＣＰ／ＩＰ制御部１０９及びＬＡＮカード制御部１１０の各機能部とによって、通信制御機能１０３が実現される。
【００２７】
ネットワーク共通部１０７は、モニタ１０４とのインタフェース機能、共通関数の実行機能、バッファ管理機能等を有する。
ＬＡＮマルチプロトコル制御部１０８は、ＴＣＰ／ＩＰ（転送制御プロトコル／インターネットプロトコル）を始めとする各種通信プロトコルを終端する機能を有する。
【００２８】
ＴＣＰ／ＩＰ制御部１０９は、ＬＡＮカード制御部１１０を介して特には図示しないＬＡＮと本体側ＣＰＵ１０１との間のＴＣＰ／ＩＰ通信の全般を制御する機能を有する。
【００２９】
ＬＡＮカード制御部１１０は、特には図示しないＬＡＮに対する物理インタフェース機能を有する。
制御情報管理テーブル１１１は、本発明に特に関連し、本体側ＣＰＵ１０１内の特には図示しないメモリ又は記憶装置上に保持される。なお、この制御情報管理テーブル１１１は、通信カード１０２内のメモリ又は記憶装置上に保持されてもよい。図２は、制御情報管理テーブル１１１のデータ構成図である。
【００３０】
制御情報管理テーブル１１１は、図２に示されるように、エラー（異常）が本体側ＣＰＵ１０１内のドライバ１０６で発生したのか通信カード１０２内で発生したのかを特定するためのフラグビットｂｉｔ７及びｂｉｔ６と、より具体的な発生箇所を特定するためのフラグビットｂｉｔ３、ｂｉｔ２、ｂｉｔ１、及びｂｉｔ０を有する。
【００３１】
即ち、エラー（異常）が本体側ＣＰＵ１０１内のドライバ１０６内で発生した場合はフラグビットｂｉｔ７が立てられ、エラーが通信カード１０２内で発生した場合はフラグビットｂｉｔ６が立てられる。
【００３２】
また、エラーが本体側ＣＰＵ１０１内のドライバ１０６を構成するネットワーク共通制御部１０７で発生した場合はフラグビットｂｉｔ３が立てられ、エラーが本体側ＣＰＵ１０１内のドライバ１０６を構成するＬＡＮマルチプロトコル制御部１０８で発生した場合はフラグビットｂｉｔ２が立てられる。
【００３３】
更に、エラーが通信カード１０２内のＴＣＰ／ＩＰ制御部１０９で発生した場合はフラグビットｂｉｔ１が立てられ、エラーが通信カード１０２内のＬＡＮカード制御部１１０で発生した場合はフラグビットｂｉｔ０が立てられる。
【００３４】
図３は、例として、通信カード１０２内のＴＣＰ／ＩＰ制御部１０９でエラーが発生したときに実行される、本発明の第１の実施の形態の動作フローチャートである。
【００３５】
まず、ＴＣＰ／ＩＰ制御部１０９自身でエラーが検出されると、例えばその例外処理ルーチンが起動される（ステップ３０１）。
この結果、ＴＣＰ／ＩＰ制御部１０９は、本体側ＣＰＵ１０１内の制御情報管理テーブル１１１内のフラグビットｂｉｔ６とｂｉｔ１を立てる（ステップ３０２）。
【００３６】
続いて、通信カード１０２が本体側ＣＰＵ１０１内のモニタ１０４に対して、インタラプトをかけることによりエラー検出通知を行う（ステップ３０３）。
モニタ１０４は、オペレータ１０５に対して、通信制御機能１０３内でエラー検出したことをエラーメッセージとして通知する（ステップ３０４）。
【００３７】
オペレータ１０５は、そのエラーメッセージに応答して、ダンプ採取コマンドを発行する（ステップ３０５）。このコマンドは、従来技術におけるような本体側ＣＰＵ１０１又は通信カード１０２を指示する複雑なものである必要はなく、通知されたエラーメッセージに対して単にダンプ採取を指示するだけの簡単なシンタックスを有する。即ち、オペレータ１０５は、このダンプ採取コマンドの発行に際して、エラーが発生したファームウエア又はプログラムが実行されている本体側ＣＰＵ１０１又は通信カード１０２を明示的に特定する必要はない。
【００３８】
モニタ１０４は、上記ダンプ採取コマンドを受け付けると、制御情報管理テーブル１１１を参照し（ステップ３０６）、そのテーブル内のフラグビットｂｉｔ６とｂｉｔ１が立っているか否かを判定する（ステップ３０７）。
【００３９】
モニタ１０４は、制御情報管理テーブル１１１内のフラグビットｂｉｔ６とｂｉｔ１が立っていると判定した場合には、通信カード１０２に対してＴＣＰ／ＩＰ制御部１０９を特定したダンプ採取コマンドを発行する。この結果、通信カード１０２に割り当てられたメモリ空間上でのＴＣＰ／ＩＰ制御部１０９の実行イメージであるダンプ情報が採取され、本体側ＣＰＵ１０１内の特には図示しないファイルシステムにダンプファイル等として保存される（ステップ３０７→３０８）。
【００４０】
モニタ１０４は、制御情報管理テーブル１１１内のフラグビットｂｉｔ６とｂｉｔ１の両方が立ってはいないと判定した場合には、制御情報管理テーブル１１１内の他のフラグビットが立っているか否かの検索と、その検索結果に応じた必要なダンプ採取を実行する（ステップ３０７→３０９）。
【００４１】
以上のように、本発明の第１の実施の形態では、オペレータ１０５は、エラーメッセージに応答する単純なダンプ採取コマンドを発行するだけで、モニタ１０４が制御情報管理テーブル１１１を参照することにより、エラーが発生した制御部が実行されている本体側ＣＰＵ１０１又は通信カード１０２を自動的に特定し、当該制御部に適切に対応するダンプ情報のみを採取することが可能となる。
本発明の第２の実施の形態
図４は、本発明の第２の実施の形態の構成図である。
【００４２】
第２の実施の形態におけるコンピュータシステムは、本体側ＣＰＵ４０１にそれぞれがノンインテリジェントなＬＡＮカードである複数（＃１及び＃２）の通信カード４０２が接続された構成を有し、オペレータ４０５は、本体側ＣＰＵ４０１内で実行されているモニタ４０４を介して、エラーメッセージを通知され、またそのエラーメッセージに応答してダンプ採取コマンドを発行する。
【００４３】
本体側ＣＰＵ４０１内では、通信カード４０２（＃１）を制御するためのドライバ４０６（＃１）と、通信カード４０２（＃２）を制御するためのドライバ４０６（＃２）とが動作している。
【００４４】
本発明の第２の実施の形態では、図１に示される本発明の第１の実施の形態におけるネットワーク共通制御部１０７と同様の機能を有するネットワーク共通制御部４０７と、同じく図１におけるＬＡＮマルチプロトコル制御部１０８と同様の機能を有するＬＡＮマルチプロトコル制御部４０９が、本体側ＣＰＵ４０１内のドライバ４０６（＃１）とドライバ４０６（＃２）にまたがって含まれる。
【００４５】
また、本発明の第２の実施の形態では、図１に示される本発明の第１の実施の形態では通信カード１０２内に実装されていたＴＣＰ／ＩＰ制御部１０９と同様の機能を有するＴＣＰ／ＩＰ制御部４０８（＃１）と、同じく図１において通信カード１０２内に実装されていたＬＡＮカード制御部１１０と同様の機能を有するＬＡＮカード制御部４１０（＃１）が、通信カード４０２（＃１）に対応する本体側ＣＰＵ４０１内のドライバ４０６（＃１）に含まれる。
【００４６】
更に、本発明の第２の実施の形態では、ＯＳＩ制御部４０８（＃２）とＬＡＮカード制御部４１０（＃２）が、通信カード４０２（＃２）に対応する本体側ＣＰＵ４０１内のドライバ４０６（＃２）に含まれる。
【００４７】
ＯＳＩ制御部４０８（＃２）は、ＬＡＮカード制御部４１０（＃２）を介して特には図示しないＬＡＮと本体側ＣＰＵ４０１との間のＯＳＩ通信の全般を制御する機能を有する。
【００４８】
上述した構成を有する本体側ＣＰＵ４０１内の２つのドライバ４０６（＃１、＃２）と、２枚の通信カード４０２（＃１、＃２）とによって、通信制御機能４０３が実現される。
【００４９】
本発明の第２の実施の形態では、本発明に特に関連する機能として、ハードウエア構成情報記述テーブル４１１（＃１）及び４１１（＃２）が、それぞれ通信カード４０２（＃１）及び４０２（＃２）内のメモリ又は記憶装置上に保持される。なお、これらハードウエア構成情報記述テーブル４１１（＃１、＃２）は、本体側ＣＰＵ４０１内のメモリ又は記憶装置上に保持されてもよい。
【００５０】
図５は、ハードウエア構成情報記述テーブル４１１のデータ構成図である。
このハードウエア構成情報記述テーブル４１１は、ＴＣＰ／ＩＰ制御部４０８（＃１）、ＯＳＩ制御部４０８（＃２）、ＬＡＮカード制御部４１０（＃１）、ＬＡＮカード制御部４１０（＃２）といった、通信カード４０２側に実装される可能性のある制御部毎に、個別のエントリＸＸＸ、ＹＹＹ、・・・を有する。そして、各エントリ毎に、そのエントリに対応する制御部（装置制御プログラム）が本体側ＣＰＵ４０１内に存在するか通信カード４０２内に存在するかを示すためのフラグビットｂｉｔ７及びｂｉｔ６と、各制御部がシステム内（本体側ＣＰＵ４０１又は通信カード４０２）に存在するか否かを示すためのフラグビットｂｉｔ３、ｂｉｔ２、ｂｉｔ１、及びｂｉｔ０を有する。
【００５１】
即ち各エントリ毎に、そのエントリに対応する制御部（装置制御プログラム）が、本体側ＣＰＵ４０１内に存在する場合はフラグビットｂｉｔ７が立てられ、通信カード４０２内に存在する場合はフラグビットｂｉｔ６が立てられる。
【００５２】
また各エントリ毎に、ネットワーク共通制御部４０７がシステム内に存在する場合はフラグビットｂｉｔ３が立てられ、そのエントリに対応するＴＣＰ／ＩＰ制御部４０８（＃１）又はＯＳＩ制御部４０８（＃２）の何れかがシステム内に存在する場合はフラグビットｂｉｔ２が立てられ、ＬＡＮマルチプロトコル制御部４０９がシステム内に存在する場合はフラグビットｂｉｔ１が立てられ、そのエントリに対応するＬＡＮカード制御部４１０（＃１）又は４１０（＃２）の何れかがシステム内に存在する場合はフラグビットｂｉｔ０が立てられる。
【００５３】
図６は、例として、ＴＣＰ／ＩＰ制御部４０８（＃１）又はＯＳＩ制御部４０８（＃２）でエラーが発生したときに実行される、本発明の第２の実施の形態の動作フローチャートである。
【００５４】
まず、ＴＣＰ／ＩＰ制御部４０８（＃１）又はＯＳＩ制御部４０８（＃２）でエラーが検出されると、例えばその例外処理ルーチンが起動される（ステップ６０１）。
【００５５】
この結果、ＴＣＰ／ＩＰ制御部４０８（＃１）又はＯＳＩ制御部４０８（＃２）が、本体側ＣＰＵ４０１内のモニタ４０４に対して、インタラプトをかけることによりエラー検出通知を行う（ステップ６０２）。
【００５６】
モニタ４０４は、オペレータ４０５に対して、ＴＣＰ／ＩＰ制御部４０８（＃１）又はＯＳＩ制御部４０８（＃２）でエラー検出したことをエラーメッセージとして通知する（ステップ６０３）。
【００５７】
オペレータ４０５は、そのエラーメッセージを参照して、モニタ４０４に、ＴＣＰ／ＩＰ制御部４０８（＃１）又はＯＳＩ制御部４０８（＃２）のダンプ採取コマンドを発行する（ステップ６０４）。この時点まではモニタ４０４はＴＣＰ／ＩＰ制御部４０８（＃１）又はＯＳＩ制御部４０８（＃２）が本体側ＣＰＵ４０１内のドライバ４０６側に存在することは知らない。このコマンドは、従来技術におけるような複雑なものである必要はなく、通知されたエラーメッセージに表示されている制御部を指定したダンプ採取を指示するだけの簡単なシンタックスを有する。即ち、オペレータ４０５は、このダンプ採取コマンドの発行に際して、エラーが発生したファームウエア又はプログラムが実行されている本体側ＣＰＵ４０１又は通信カード４０２を明示的に特定する必要はない。
【００５８】
モニタ４０４は、上記ダンプ採取コマンドを受け付けると、まず、通信カード４０２（＃１）内のハードウエア構成情報記述テーブル４１１（＃１）を参照する（ステップ６０５）。
【００５９】
そして、ＴＣＰ／ＩＰ制御部４０８（＃１）に対応するエントリＸＸＸのフラグビットｂｉｔ７とｂｉｔ２が立っているか否かを判定する（ステップ６０６）。
【００６０】
モニタ４０４は、ハードウエア構成情報記述テーブル４１１（＃１）内のフラグビットｂｉｔ７とｂｉｔ２が立っていると判定した場合には、エラーが検出されたのが本体側ＣＰＵ４０１内のドライバ４０６（＃１）を構成するＴＣＰ／ＩＰ制御部４０８（＃１）であると認識できるため、本体側ＣＰＵ４０１内のドライバ４０６（＃１）を構成するＴＣＰ／ＩＰ制御部４０８（＃１）を特定したダンプ採取コマンドを発行する。この結果、本体側ＣＰＵ４０１内のドライバ４０６に割り当てられたメモリ空間上でのＴＣＰ／ＩＰ制御部４０８（＃１）の実行イメージであるダンプ情報が採取され、本体側ＣＰＵ４０１内の特には図示しないファイルシステムにダンプファイル等として保存される（ステップ６０６→６０７）。
【００６１】
モニタ４０４は、ハードウエア構成情報記述テーブル４１１（＃１）内のフラグビットｂｉｔ７とｂｉｔ２の両方が立ってはいないと判定した場合には、ハードウエア構成情報記述テーブル４１１（＃１）において、ＴＣＰ／ＩＰ制御部４０８（＃１）に対応するエントリＸＸＸのフラグビットｂｉｔ６とｂｉｔ２が立っているか否かを判定する（ステップ６０８）。
【００６２】
モニタ４０４は、ハードウエア構成情報記述テーブル４１１（＃１）内のフラグビットｂｉｔ６とｂｉｔ２が立っていると判定した場合には、エラーが検出されたのが図４の場合とは異なる通信カード４０２（＃１）内で実行されているＴＣＰ／ＩＰ制御部４０８（＃１）であると認識できるため、通信カード４０２（＃１）内のＴＣＰ／ＩＰ制御部４０８（＃１）を特定したダンプ採取コマンドを発行する。この結果、通信カード４０２（＃１）に割り当てられたメモリ空間上でのＴＣＰ／ＩＰ制御部４０８（＃１）の実行イメージであるダンプ情報が採取され、本体側ＣＰＵ４０１内の特には図示しないファイルシステムにダンプファイル等として保存される（ステップ６０８→６０９）。
【００６３】
モニタ４０４は、ハードウエア構成情報記述テーブル４１１（＃１）内のフラグビットｂｉｔ６とｂｉｔ２についてもその両方が立ってはいないと判定した場合は、エラーが検出されたのがＴＣＰ／ＩＰ制御部４０８（＃１）ではなくＯＳＩ制御部４０８（＃２）であると認識できるため、今度は通信カード４０２（＃２）内のハードウエア構成情報記述テーブル４１１（＃２）を参照して、上述のステップ６０６〜６０９と同様の制御処理を実行して、該当するダンプ情報を採取する（ステップ６１０）。
【００６４】
以上のように、本発明の第２の実施の形態では、オペレータ１０５は、エラーメッセージを参照して単純なダンプ採取コマンドを発行するだけで、モニタ４０４がハードウエア構成情報記述テーブル４１１（＃１、＃２）を参照することにより、エラーが発生した制御部が実行されている本体側ＣＰＵ４０１又は通信カード４０２（＃１、＃２）を自動的に特定し、当該制御部に適切に対応するダンプ情報のみを採取することが可能となる。
本発明の第３の実施の形態
図７は、本発明の第３の実施の形態の構成図である。
【００６５】
図７に示される本発明の第３の実施の形態の構成は、基本的には図１に示される本発明の第１の実施の形態の構成と同じであるが、本体側ＣＰＵ１０１内に、制御情報管理テーブル１１１に加えてハードウエア構成情報記述テーブル７０１が配置されている点が図１の構成と異なる。
【００６６】
図７の制御情報管理テーブル１１１は、本発明の第１の実施の形態の場合と同様の図２に示される構成を有し、ハードウエア構成情報記述テーブル７０１は、本発明の第２の実施の形態の場合と同様の図５に示される構成を有する。
【００６７】
この場合に、各エントリ毎に、そのエントリに対応する制御部（装置制御プログラム）が、本体側ＣＰＵ１０１内に存在する場合はフラグビットｂｉｔ７が立てられ、通信カード１０２内に存在する場合はフラグビットｂｉｔ６が立てられる。
【００６８】
また各エントリ毎に、ネットワーク共通制御部１０７がシステム内に存在する場合はフラグビットｂｉｔ３が立てられ、ＬＡＮマルチプロトコル制御部１０８がシステム内に存在する場合はフラグビットｂｉｔ２が立てられ、ＴＣＰ／ＩＰ制御部１０９がシステム内に存在する場合はフラグビットｂｉｔ１が立てられ、ＬＡＮカード制御部１１０がシステム内に存在する場合はフラグビットｂｉｔ０が立てられる。
【００６９】
なお、制御情報管理テーブル１１１とハードウエア構成情報記述テーブル７０１は、通信カード１０２内のメモリ又は記憶装置上に保持されてもよい。
本発明の第３の実施の形態では、制御情報管理テーブル１１１とハードウエア構成情報記述テーブル７０１の両方の内容を使ってエラーが発生した制御部が特定されダンプ情報が採取されることが、本発明に関連する特徴である。
【００７０】
図８は、例として、通信カード１０２内のＴＣＰ／ＩＰ制御部１０９でエラーが発生したときに実行される、本発明の第３の実施の形態の動作フローチャートである。
【００７１】
まず、ＴＣＰ／ＩＰ制御部１０９自身でエラーが検出されると、例えばその例外処理ルーチンが起動される（ステップ８０１）。
この結果、ＴＣＰ／ＩＰ制御部１０９は、本体側ＣＰＵ１０１内の制御情報管理テーブル１１１内のフラグビットｂｉｔ６とｂｉｔ１を立てる（ステップ８０２）。
【００７２】
続いて、通信カード１０２が本体側ＣＰＵ１０１内のモニタ１０４に対して、インタラプトをかけることによりエラー検出通知を行う（ステップ８０３）。
モニタ１０４は、オペレータ１０５に対して、通信制御機能１０３内でエラー検出したことをエラーメッセージとして通知する（ステップ８０４）。
【００７３】
オペレータ１０５は、そのエラーメッセージに応答して、ダンプ採取コマンドを発行する（ステップ８０５）。このコマンドは、本発明の第１の実施の形態の場合と同様に、通知されたエラーメッセージに対して単にダンプ採取を指示するだけの簡単なシンタックスを有する。
【００７４】
モニタ１０４は、上記ダンプ採取コマンドを受け付けると、制御情報管理テーブル１１１を参照し（ステップ８０６）、そのテーブル内のフラグビットｂｉｔ６とｂｉｔ１が立っているか否かを判定する（ステップ８０７）。
【００７５】
モニタ１０４は、制御情報管理テーブル１１１内のフラグビットｂｉｔ６とｂｉｔ１が立っていると判定した場合には、通信カード１０２に対してＴＣＰ／ＩＰ制御部１０９を特定したダンプ採取を行えばよいことを認識する（ステップ８０７→８０８）。
【００７６】
モニタ１０４は、制御情報管理テーブル１１１内のフラグビットｂｉｔ６とｂｉｔ１の両方が立ってはいないと判定した場合には、制御情報管理テーブル１１１内の他のフラグビットが立っているか否かの検索と、その検索結果に応じた必要なダンプ採取を実行する（ステップ８０７→８０９）。
【００７７】
上述のステップ８０４〜８０９の制御処理に続いて、モニタ１０４は、以下のステップ８１０〜８１５の制御処理を実行する。
即ちまず、モニタ１０４は、オペレータ１０５に対して、ＴＣＰ／ＩＰ制御部１０９でエラー検出したことをエラーメッセージとして通知する（ステップ８１０）。
【００７８】
オペレータ１０５は、そのエラーメッセージを参照して、モニタ１０４に、ＴＣＰ／ＩＰ制御部１０９のダンプ採取コマンドを発行する（ステップ８１１）。この時点まではモニタ１０４はＴＣＰ／ＩＰ制御部１０９が通信カード側１０２に存在することは知らない。このコマンドは、本発明の第２の実施の形態の場合と同様に、通知されたエラーメッセージに表示されている制御部を指定したダンプ採取を指示するだけの簡単なシンタックスを有する。
【００７９】
モニタ１０４は、上記ダンプ採取コマンドを受け付けると、ハードウエア構成情報記述テーブル７０１を参照する（ステップ８１２）。
そして、ＴＣＰ／ＩＰ制御部１０９に対応するエントリＸＸＸのフラグビットｂｉｔ６とｂｉｔ１が立っているか否かを判定する（ステップ８１３）。
【００８０】
モニタ１０４は、ハードウエア構成情報記述テーブル７０１内のフラグビットｂｉｔ６とｂｉｔ１が立っていると判定した場合には、エラーが検出されたのが通信カード１０２内のＴＣＰ／ＩＰ制御部１０９であると認識できるため、通信カード１０２内のＴＣＰ／ＩＰ制御部１０９を特定したダンプ採取を行えばよいことを認識する（ステップ８１３→８１４）。
【００８１】
モニタ１０４は、ハードウエア構成情報記述テーブル７０１内のフラグビットｂｉｔ６とｂｉｔ１の両方が立ってはいないと判定した場合には、ＴＣＰ／ＩＰ制御部１０９に対応するエントリＸＸＸのフラグビットｂｉｔ７とｂｉｔ１が立っているか否か、即ちＴＣＰ／ＩＰ制御部１０９が本体側ＣＰＵ１０１内に存在するか否かを判定する処理等を実行する（ステップ８１５）。
【００８２】
モニタ１０４は、ステップ８０８及び８１４の認識結果を得た後、両方の認識結果が一致しているか否かを判定する（ステップ８１６）。
モニタ１０４は、ステップ８０８及び８１４の両方の認識結果が一致していると判定した場合には、通信カード１０２に割り当てられたメモリ空間上でのＴＣＰ／ＩＰ制御部１０９の実行イメージであるダンプ情報を採取し、本体側ＣＰＵ１０１内の特には図示しないファイルシステムにダンプファイル等として保存する（ステップ８１６→８１７）。
【００８３】
モニタ１０４は、ステップ８０８及び８１４の両方の認識結果が一致していないと判定した場合には、何等かの異常が発生しているとしてエラー終了する（ステップ８１６→８１８）。
【００８４】
以上のように、本発明の第３の実施の形態では、より確実性の高いダンプ採取が可能となる。
エラーメッセージの例
図９〜図１２に、オペレータ１０５（図１、図７）又はオペレータ４０５（図４）に対して表示されるエラーメッセージの例（各図(a) ）と、それぞれに対応するマニュアル等の記述（各図(b) ）を示す。
各実施の形態を実現するプログラムが記録された記録媒体についての補足
本発明は、コンピュータにより使用されたときに、上述の本発明の各実施の形態の各構成によって実現される機能と同様の機能をコンピュータに行わせるためのコンピュータ読出し可能記録媒体として構成することもできる。
【００８５】
この場合に、図１３に示されるように、例えばフロッピィディスク、ＣＤ−ＲＯＭディスク、光磁気ディスク、リムーバブルハードディスク等の可搬型記録媒体１３０２や、ネットワーク回線１３０３経由で、本発明の各実施の形態の各種機能を実現するプログラムが、本体側ＣＰＵ１０１又は４０１に対応するコンピュータ１３０１の本体１３０４内のメモリ（ＲＡＭ又はハードディスク等）１３０５にロードされて、実行される。
【００８６】
【発明の効果】
本発明の第１の態様の構成によれば、オペレータは、エラーメッセージに応答する単純なエラー情報採取コマンドを発行するだけで、制御情報管理テーブルが参照されることにより、エラーが発生した装置制御部が実行されている本体側プロセッサ装置又は処理カードが自動的に特定され、当該装置制御部に適切に対応するエラー情報のみを取得することが可能となる。
【００８７】
本発明の第２の態様の構成によれば、オペレータは、エラーメッセージを参照して単純なエラー情報採取コマンドを発行するだけで、ハードウエア構成情報記述テーブルが参照されることにより、エラーが発生した装置制御部が実行されている本体側プロセッサ装置又は処理カードが自動的に特定され、当該装置制御部に適切に対応するエラー情報のみを取得することが可能となる。
【００８８】
本発明の第３の態様の構成によれば、より確実性の高いエラー情報採取が可能となる。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態の構成図である。
【図２】制御情報管理テーブルの構成図である。
【図３】本発明の第１の実施の形態の動作フローチャートである。
【図４】本発明の第２の実施の形態の構成図である。
【図５】ハードウエア構成情報記述テーブルの構成図である。
【図６】本発明の第２の実施の形態の動作フローチャートである。
【図７】本発明の第３の実施の形態の構成図である。
【図８】本発明の第３の実施の形態の動作フローチャートである。
【図９】エラーメッセージ例（その１）を示す図である。
【図１０】エラーメッセージ例（その２）を示す図である。
【図１１】エラーメッセージ例（その３）を示す図である。
【図１２】エラーメッセージ例（その４）を示す図である。
【図１３】各実施の形態を実現するプログラムが記録された記録媒体の説明図である。
【符号の説明】
１０１、４０１ 本体側ＣＰＵ
１０２、４０２（＃１、＃２） 通信カード
１０３、４０３ 通信制御機能
１０４、４０４ モニタ
１０５、４０５ オペレータ
１０６、４０６（＃１、＃２） ドライバ
１０７、４０７ ネットワーク共通制御部
１０８、４０９ ＬＡＮマルチプロトコル制御部
１０９、４０８（＃１） ＴＣＰ／ＩＰ制御部
１１０、４１０（＃１、＃２） ＬＡＮカード制御部
１１１ 制御情報管理テーブル
４１１（＃１、＃２）、７０１ ハードウエア構成情報記述テーブル
Claims (6)
- 演算処理装置を有する情報処理装置と、前記情報処理装置に接続され前記情報処理装置の機能を拡張する機能拡張装置を有する情報処理システムにおいて、
前記情報処理システムは、
前記情報処理装置又は前記機能拡張装置の何れにおいてエラーが発生したことを示すエラー発生装置識別情報を格納する記憶部を前記情報処理装置内又は前記機能拡張装置内のいずれかに有し、
前記情報処理装置は、
前記情報処理システム内で発生したエラーを監視するエラー監視部と、
前記演算処理装置に、前記情報処理装置内で発生した第１のエラーを検出させ、前記第１のエラーを前記エラー監視部に通知して、前記第１のエラーが前記情報処理装置内で発生したことを示す情報が記録されている前記エラー発生装置識別情報を前記エラー監視部に参照させる第１の処理部を有し、
前記機能拡張装置は、
前記機能拡張装置内で発生した第２のエラーを検出し、前記第２のエラーが前記機能拡張装置内で発生したことを示す情報を前記エラー発生装置識別情報に記録する第２の処理部と、
前記第２のエラーを前記エラー監視部に通知するエラー通知部を有することを特徴とする情報処理システム。 - 前記エラー監視部は、
前記エラー発生装置識別情報に基づいて、前記情報処理装置又は前記機能拡張装置のうちエラーが発生した装置に対応するエラー情報のみを採取することを特徴とする請求項１記載の情報処理システム。 - 演算処理装置を有する情報処理装置と、前記情報処理装置に接続され前記情報処理装置の機能を拡張する機能拡張装置を有する情報処理システムのエラー採取方法において、
前記情報処理装置が有する第１の処理部又は前記機能拡張装置が有する第２の処理部が、前記情報処理装置内で発生した第１のエラーを前記演算処理装置に検出させ、又は前記機能拡張装置内で発生した第２のエラーを検出するステップと、
前記第２の処理部が、前記第２のエラーが前記機能拡張装置内で発生したことを示す情報を、エラー発生装置識別情報として記憶部に記録するステップと、
前記第１の処理部が、前記第１のエラーを、前記情報処理システム内で発生したエラーを監視するエラー監視部に通知して、前記第１のエラーが前記情報処理装置内で発生したことを示す情報が記録されている前記エラー発生装置識別情報を前記エラー監視部に参照させるステップと、
前記第２の処理部が、前記第２のエラーを、前記エラー監視部に通知するステップと、
前記エラー監視部が、前記記憶部に記録された前記エラー発生装置識別情報に基づいて、前記情報処理装置又は前記機能拡張装置のうちエラーが発生した装置に対応するエラー情報のみを採取するステップを有することを特徴とするエラー採取方法。 - 演算処理装置を有する情報処理装置と、前記情報処理装置に接続され前記情報処理装置の機能を拡張する機能拡張装置を有する情報処理システムのエラー採取方法において、
前記情報処理装置が有する第１の処理部又は前記機能拡張装置が有する第２の処理部が、前記第１の処理部内で発生した第１のエラーを前記演算処理装置に検出させ、又は前記第２の処理部内で発生した第２のエラーを検出するステップと、
前記第２の処理部が、前記第２のエラーが前記機能拡張装置内で発生したことを示す情報を、エラー発生処理部識別情報として記憶部に記録するステップと、
前記第１の処理部が、前記第１のエラーを、前記情報処理システム内で発生したエラーを監視するエラー監視部に通知して、前記第１のエラーが前記情報処理装置内で発生したことを示す情報が記録されている前記エラー発生処理部識別情報を前記エラー監視部に参 照させるステップと、
前記第２の処理部が、前記第２のエラーを、前記エラー監視部に通知するステップと、
前記エラー監視部が、前記記憶部に記録された前記エラー発生処理部識別情報に基づいて、前記第１又は第２の処理部のうちエラーが発生した処理部に対応するエラー情報のみを採取するステップを有することを特徴とするエラー採取方法。 - 演算処理装置を有する情報処理装置と、前記情報処理装置に接続され前記情報処理装置の機能を拡張する機能拡張装置を有する情報処理システムのエラー採取プログラムを格納したコンピュータで読み取り可能な記録媒体において、
前記情報処理装置が有する前記演算処理装置に、
前記情報処理装置が有する第１の処理部又は前記機能拡張装置が有する第２の処理部が、前記情報処理装置内で発生した第１のエラー又は前記機能拡張装置内で発生した第２のエラーを検出するステップと、
前記第２の処理部が、前記第２のエラーが前記機能拡張装置内で発生したことを示す情報を、エラー発生装置識別情報として記憶部に記録するステップと、
前記第１の処理部が、前記第１のエラーを、前記情報処理システム内で発生したエラーを監視するエラー監視部に通知して、前記第１のエラーが前記情報処理装置内で発生したことを示す情報が記録されている前記エラー発生装置識別情報を前記エラー監視部に参照させるステップと、
前記第２の処理部が、前記第２のエラーを、前記エラー監視部に通知するステップと、
前記エラー監視部が、前記記憶部に記録された前記エラー発生装置識別情報に基づいて、前記情報処理装置又は前記機能拡張装置のうちエラーが発生した装置に対応するエラー情報のみを採取するステップを実行させることを特徴とするエラー採取プログラムを格納したコンピュータで読み取り可能な記録媒体。 - 演算処理装置を有する情報処理装置と、前記情報処理装置に接続され前記情報処理装置の機能を拡張する機能拡張装置を有する情報処理システムのエラー採取プログラムを格納したコンピュータで読み取り可能な記録媒体において、
前記演算処理装置に、
前記情報処理装置が有する第１の処理部又は前記機能拡張装置が有する第２の処理部が、前記情報処理装置内で発生した第１のエラー又は前記機能拡張装置内で発生した第２のエラーを検出するステップと、
前記第２の処理部が、前記第２のエラーが前記機能拡張装置内で発生したことを示す情報を、エラー発生処理部識別情報として記憶部に記録するステップと、
前記第１の処理部が、前記第１のエラーを、前記情報処理システム内で発生したエラーを監視するエラー監視部に通知して、前記第１のエラーが前記情報処理装置内で発生したことを示す情報が記録されている前記エラー発生処理部識別情報を前記エラー監視部に参照させるステップと、
前記第２の処理部が、前記第２のエラーを、前記エラー監視部に通知するステップと、
前記エラー監視部が、前記記憶部に記録された前記エラー発生処理部識別情報に基づいて、前記第１又は第２の処理部のうちエラーが発生した処理部に対応するエラー情報のみを採取するステップを実行させることを特徴とするエラー採取プログラムを格納したコンピュータで読み取り可能な記録媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP28087297A JP4199322B2 (ja) | 1997-10-14 | 1997-10-14 | 情報処理装置及び情報処理装置のエラー採取方法 |
| US09/048,023 US6105150A (en) | 1997-10-14 | 1998-03-26 | Error information collecting method and apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP28087297A JP4199322B2 (ja) | 1997-10-14 | 1997-10-14 | 情報処理装置及び情報処理装置のエラー採取方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11120039A JPH11120039A (ja) | 1999-04-30 |
| JP4199322B2 true JP4199322B2 (ja) | 2008-12-17 |
Family
ID=17631138
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP28087297A Expired - Fee Related JP4199322B2 (ja) | 1997-10-14 | 1997-10-14 | 情報処理装置及び情報処理装置のエラー採取方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6105150A (ja) |
| JP (1) | JP4199322B2 (ja) |
Families Citing this family (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE19827431C2 (de) * | 1997-07-22 | 2000-12-07 | Siemens Ag | Verfahren zur Fehlererkennung in einem Prozessorsystem |
| US7581077B2 (en) | 1997-10-30 | 2009-08-25 | Commvault Systems, Inc. | Method and system for transferring data in a storage operation |
| US6418478B1 (en) * | 1997-10-30 | 2002-07-09 | Commvault Systems, Inc. | Pipelined high speed data transfer mechanism |
| US6269459B1 (en) | 1998-08-25 | 2001-07-31 | Advanced Micro Devices, Inc. | Error reporting mechanism for an AGP chipset driver using a registry |
| US6643802B1 (en) * | 2000-04-27 | 2003-11-04 | Ncr Corporation | Coordinated multinode dump collection in response to a fault |
| US6983362B1 (en) | 2000-05-20 | 2006-01-03 | Ciena Corporation | Configurable fault recovery policy for a computer system |
| US6708291B1 (en) * | 2000-05-20 | 2004-03-16 | Equipe Communications Corporation | Hierarchical fault descriptors in computer systems |
| US6832342B2 (en) * | 2001-03-01 | 2004-12-14 | International Business Machines Corporation | Method and apparatus for reducing hardware scan dump data |
| US7165202B2 (en) * | 2001-03-22 | 2007-01-16 | Landesk Software Limited | Method and apparatus to perform customized error handling |
| US6845469B2 (en) * | 2001-03-29 | 2005-01-18 | International Business Machines Corporation | Method for managing an uncorrectable, unrecoverable data error (UE) as the UE passes through a plurality of devices in a central electronics complex |
| US6829729B2 (en) * | 2001-03-29 | 2004-12-07 | International Business Machines Corporation | Method and system for fault isolation methodology for I/O unrecoverable, uncorrectable error |
| US6880113B2 (en) * | 2001-05-03 | 2005-04-12 | International Business Machines Corporation | Conditional hardware scan dump data capture |
| GB2409553B (en) | 2002-09-16 | 2007-04-04 | Commvault Systems Inc | System and method for optimizing storage operations |
| WO2005065084A2 (en) | 2003-11-13 | 2005-07-21 | Commvault Systems, Inc. | System and method for providing encryption in pipelined storage operations in a storage network |
| US7308609B2 (en) * | 2004-04-08 | 2007-12-11 | International Business Machines Corporation | Method, data processing system, and computer program product for collecting first failure data capture information |
| US8312323B2 (en) | 2006-12-22 | 2012-11-13 | Commvault Systems, Inc. | Systems and methods for remote monitoring in a computer network and reporting a failed migration operation without accessing the data being moved |
| US8839044B2 (en) * | 2012-01-05 | 2014-09-16 | International Business Machines Corporation | Debugging of adapters with stateful offload connections |
| JP6327026B2 (ja) * | 2014-07-10 | 2018-05-23 | 富士通株式会社 | 情報処理装置、情報処理方法およびプログラム |
| US9904481B2 (en) | 2015-01-23 | 2018-02-27 | Commvault Systems, Inc. | Scalable auxiliary copy processing in a storage management system using media agent resources |
| US9898213B2 (en) | 2015-01-23 | 2018-02-20 | Commvault Systems, Inc. | Scalable auxiliary copy processing using media agent resources |
| JP2016186719A (ja) * | 2015-03-27 | 2016-10-27 | 富士通株式会社 | 入出力制御装置、情報処理装置及び入出力制御装置の制御方法 |
| US10366458B2 (en) | 2017-03-01 | 2019-07-30 | Bank Of America Corporation | Live reporting of check image keying issues |
| US11010261B2 (en) | 2017-03-31 | 2021-05-18 | Commvault Systems, Inc. | Dynamically allocating streams during restoration of data |
| US11204821B1 (en) * | 2020-05-07 | 2021-12-21 | Xilinx, Inc. | Error re-logging in electronic systems |
| US11500715B1 (en) | 2021-05-27 | 2022-11-15 | Fort Robotics, Inc. | Determining functional safety state using software-based ternary state translation of analog input |
| WO2023278865A1 (en) * | 2021-07-01 | 2023-01-05 | Fort Robotics, Inc. | Method for encoded diagnostics in a functional safety system |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5617531A (en) * | 1993-11-02 | 1997-04-01 | Motorola, Inc. | Data Processor having a built-in internal self test controller for testing a plurality of memories internal to the data processor |
| US5515384A (en) * | 1994-03-01 | 1996-05-07 | International Business Machines Corporation | Method and system of fault diagnosis of application specific electronic circuits |
| US5495573A (en) * | 1994-08-05 | 1996-02-27 | Unisys Corporation | Error logging system with clock rate translation |
| KR970010242B1 (ko) * | 1994-11-08 | 1997-06-23 | 엘지정보통신 주식회사 | 디지틀 통신시스팀의 판정에러 정정 방법 및 이를 실현하기 위한 디지틀 통신시스팀 |
| US5720031A (en) * | 1995-12-04 | 1998-02-17 | Micron Technology, Inc. | Method and apparatus for testing memory devices and displaying results of such tests |
-
1997
- 1997-10-14 JP JP28087297A patent/JP4199322B2/ja not_active Expired - Fee Related
-
1998
- 1998-03-26 US US09/048,023 patent/US6105150A/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11120039A (ja) | 1999-04-30 |
| US6105150A (en) | 2000-08-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4199322B2 (ja) | 情報処理装置及び情報処理装置のエラー採取方法 | |
| US7016957B2 (en) | Distributed data processing system and error analysis information saving method appropriate therefor | |
| US10545807B2 (en) | Method and system for acquiring parameter sets at a preset time interval and matching parameters to obtain a fault scenario type | |
| JP2008065668A (ja) | 障害発生の原因箇所の発見を支援する技術 | |
| EP1661367B1 (en) | Packet sniffer | |
| JP2000132413A (ja) | エラーリトライ方法、エラーリトライシステム及びその記録媒体 | |
| JPH10105440A (ja) | システム障害監視装置及び記録媒体 | |
| JP3691272B2 (ja) | 分散処理システムおよび障害解析情報の保存方法 | |
| JP2007257266A (ja) | 情報処理装置、デバイス表示処理方法、記憶媒体、プログラム | |
| JP3309942B2 (ja) | プリントサーバ及びその動作方法 | |
| JPH0558567A (ja) | 昇降機故障解析装置 | |
| JPH10260870A (ja) | システム起動／終了制御装置 | |
| US20030093489A1 (en) | Network terminal device | |
| CN116185978A (zh) | 日志处理方法、装置、电子设备及存储介质 | |
| JP2553046B2 (ja) | 交換機の正常稼動への移行方式 | |
| JPH0944380A (ja) | モジュール管理装置 | |
| JPH0662089A (ja) | 通信システムにおける障害情報採取方法 | |
| JPH02310755A (ja) | ヘルスチェック方式 | |
| JP2005322272A (ja) | プリンタ装置およびプリンタ装置を含むシステム | |
| JPH11134223A (ja) | 自動性能チューニング方法 | |
| JP2000259451A (ja) | 障害通知システム | |
| JP2005182110A (ja) | 制御装置及び処理ユニットの状態監視方法 | |
| JPH0333918A (ja) | 情報処理装置 | |
| JPH02114340A (ja) | トレース制御方式 | |
| JPH07182119A (ja) | リモートプリント方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040927 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070723 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070821 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071019 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080226 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080424 |
|
| RD12 | Notification of acceptance of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7432 Effective date: 20080519 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20080519 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080701 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080804 |
|
| 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: 20080930 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20081003 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111010 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |