JPH0325629A

JPH0325629A - プログラムのエラー検出方法及びシステム

Info

Publication number: JPH0325629A
Application number: JP2155575A
Authority: JP
Inventors: Paul R Cobb; ポール・レイモンド・コブ; Christopher J Lennon; クリストフア・ジヨン・レノン; Kenneth J Long; ケネス・ジヨン・ロング
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1989-06-16
Filing date: 1990-06-15
Publication date: 1991-02-04
Also published as: EP0403415A2; JPH0432417B2; EP0403415A3; US5119377A

Abstract

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

Description

【発明の詳細な説明】Ａ．産業上の利用分野この発明は、ソフトエアのエラー検出のための方法及び
システムに関するものである。

Ｂ．従来の技術歴史的には、大抵のソフトウェアは、それが決して障害
を起こさないという仮定の下で設計されてきた。そして
、ソフトウェアには、エラー検出能力が殆どまたは全く
デザインされなかった。そして、ソフトウェア・エラー
または障害が生じた時、エラーを検出するのが通常コン
ピュータ・オペレーティング・システムであるかまたは
、プログラムが正しい結果をもたらさないが故にコンピ
ュータ・オペレータがソフトウェア・プログラムの実行
を取り消すかである。

ソフトウェア・エラーまたは障害の場合、そのソフトウ
ェア・プログラムによって使用される記憶領域全体を捕
捉することが一般的である。しかし、プログラム障害が
明るみに出る前にエラーが起こるので、エラーまたは障
害の原因を決定するために必要なキー・データは多くの
場合失われるかまたは上書きされており、エラーが最終
的にあらわれた点まで実行がどのようにして辿り着いた
かが明らかでない。大抵のプログラム開発者は、ソフト
ウェア・エラーを分離するため、トレーシングと呼ばれ
るプロセスを使用する。

トレーシングを使用するためには、実行の径路を通過す
るデータをサンプルするべく、問題のプログラム内にト
レース点を配置しなくてはならない。もし可能なら、問
題が再現され、トレース点からのデータが集められる。

しかし、不都合にも、トレーシングは次のような悪い副
次的効果を及ぼす。その第１として、トレーシングは、
トレース点に遭遇する毎にトレース・ルーチンへ分岐す
ることを要するが、そのことはしばしば、問題のプログ
ラムのみならず、そのシステム上で動作している別のプ
ログラムにも重大な影響を及ぼす。第２に、トレーシン
グは、トレース点によって生成されるデータのボリュー
ムを収めるための膨大なデータ・セットを必要とする。

第３に、診断データを捕捉するためにトレーシングを使
用するプログラマは、自分が、大部分がエラーの原因を
反映しないような大量のデータをふるいにかけているこ
とを気づくことになる。第４に、もしソフトウェアの問
題が、２つのプログラム（例えば、互いに通信するネッ
トワーク・プログラム）の閏のタイミングの問題によっ
て引き起こされたものであるなら、トレースは、ほとん
どのタイミングの問題が再現され得ない点までプログラ
ムの実行を低下させることになりかねない。第５に、プ
ログラムの問題が解決された後、プログラムは、市販に
リリースされる前にすべてのトレース点は除去され、再
コンパイルされなくてはならない。

全てのデータが集められ、プログラム・エラーの原因が
決定され、解決手段が施されてテストされた後、ソフト
ウェア支援要員が依然として別の問題に１１面すること
がある，もしこの問題が別のプロセッサ上で動作する同
一のソフトウェアの別のコピーで発生するなら、それを
いかに迅速に決定することができようと、既に解決され
た問題を解決しようと資源が無駄使いされてしまうので
はなかろうか。これが現在の技法の別の欠点である。ソ
フトウェアの問題が既に解決され、報告され、または解
決されたかどうか、を決定しようとするとき、ソフトウ
ェア支援要員は、エラーまたは障害に遭遇した人員から
の問題の記述に依存することになる。しかし、しかし人
が異なると問題の兆候も興なって記述され、そのことは
、既知の問題を識別し、既存の解決策を当てはめること
を、不可能ではないにしても、困難にする。ソフトウェ
ア・プログラマは、ソフトウェアの問題が報告されてお
りそれが早期に解決されていることを後で見いだすため
にのみ、ソフトウェア問題の診断データを検討するのに
数時間あるいは数日を費やすことがある。

従来技術の典型的なものとしては、米国特許第４８０２
１６５号、同第３５５１６５９号、同第３９３７９３８
号がある。米国特許第４８０２１６５号は、プログラム
のさまざまな位置に挿入されたマクロ・コールを使用す
ることによって、コンピュータ・プログラムをデバッグ
するための方法及び装置を開示する。このシステムは、
テストされるプログラムからのトレース出力を記録し、
トレース出力は、無条件的、すなわち、エラーが生じた
か否かにかかわらず発生される。米国特許第３５５１６
５９号は、さまざまなテスト点でプログラムをテストし
、出力装置上にエラー状況情報を自動的に記録すること
によってコンピュータ・プログラムをデバッグする方法
を開示する。

これにおいては、選択されたテスト点が、エラー・チェ
ック・ルーチンへの無条件転送の呼び出しを引き起こす
。米国特許第３９３７９３８号は、メモリ構造中に、プ
ログラムの誤動作が生じた時点の最近に実行された１６
個のプログラム命令を永久的に記憶することによる、エ
ラーの検出とプログラムのデバッグの支援のための方法
を開示する。

要約すると、ソフトウェア・エラー検出のための既存の
プロセスは、ソフトウェア・エラーによって引き起こさ
れるＩＩＩ害があらわれるのを待つという方法論を採用
するものである。そして、データ・トレース点が挿入さ
れ、問題が再現され、大量のデータを集めながら問題の
プログラムの実行径路が追跡され、望ましくは、何が悪
化したかを決定するデータが捕獲される。

Ｃ．発明が解決しようとする課題この発明の目的は、ソフトウェア・エラーが発生すると
直ちにそれを検出し、問題の分離と収集を容易ならしめ
る限定された量の診断データを自動的に集めるための方
法を提供することにある。

この発明の別の目的は、問題のプログラム中のソフトウ
ェア・エラーの結果として条件付きでイネーブルされ、
さもなければ休眠状態にとどまるようなエラー検出のた
めのシステムを提供することにある。

この発明のさらに別の目的は、デバッグが完了した後で
除去されるような選択されたトレース点に一時的にマク
ロ・コールを配置するのではなく、ソフトウェア・プロ
グラム内のエラー検出点に永久的にマクロ・コールを配
置することに依存するエラー検出のためのシステムを提
供することにある。

この発明のさらに別の目的は、捕獲されたデータから、
問題一意的に識別する兆候ストリングを自動的に構築し
、ネットワーク監視者に対して総括的警告を生成するこ
とにある。

この発明のさらに別の目的は、プログラムをデバッグす
ることに関連するオーバーヘッドを最小限にととめ、以
てコンピュータ資源に対する影響を最小限に抑える、エ
ラー検出及び分離のためのシステムを提供することにあ
る。

Ｄ．課題を解決するための手段上記目的は、プログラム内の戦略的位置でソフトウェア
処理の条件付きチェックを要求する技法を利用するプロ
セスによって達或される。この論理がエラーを検出する
時、そのプロセスが呼ばれ、そのプロセスはエラーを診
断するために必要なデータのみを集める。このプロセス
は、早期検出データ捕獲（ＥＤＤＣ）プロセスとして知
られる。それは、エラー検出点で識別されたきわめて特
定のプログラム情報を捕獲する、テーブル駆動データ収
集及び報告ルーチンである。それは、ソフトウェア兆候
ストリングとして知られる一意な間ａｍ別子を構築し、
例えば、ＩＢＭシステム・ネットワーク・アーキテクチ
ャ（ＳＮＡ）を利用するコンピュータ・ネットワークに
おけるＩＢＭＳＮＡ総称的警告機能を使用して、オペレ
ータに対して問題の自動的な通知を送る。

ＥＤＤＣプロセスは、ソフトウェア問題プログラム内の
エラー検出コードからの必要な最小限の情報で、ソフト
ウェア・エラーのための洗練されたデータ捕捉機能と通
知機構を提供する。また、ＥＤ・ＤＣプロセスは、問題
のプログラムによって使用されるデータ構造及び記憶領
域のレイアウト及びフォーマットを記述する予定のテー
ブルの使用を通じて、この能力を提供する。エラーが検
出された時、ＥＤＤＣプロセスに対する呼び出しは、収
集されるべきデータと、通知のため構築されるべき総称
的警告のタイプについての基本的情報を含む。

早期検出データ捕獲プロセスは、最初に開発された時点
でソフトウェア・プログラム内に戦略的に位置づけられ
る、永久的に配置されたエラー検出点を使用する。この
検出点は、その実行全体に亙るソフトウェア・プログラ
ムの状況をチェックする。そして、もしエラーが検出さ
れると、ＥＤＤＣプロセスが呼び出される。もしエラー
が検出されないなら、ＥＤＤＣプロセスは、完全に非活
動性のままとどまる。

早期検出データ捕獲プロセスには、５つの主要な利点が
ある。その第ｌは、エラー検出点が、その開発の間にソ
フトウェア・プログラム内に永久的に配置されるという
ことである。そして、ソフトウェア・プログラムがエラ
ーに遭遇するとき、追加的なコード（例えばトレース点
）は必要でない。第２に、ソフトウェア・エラーを診断
するため・に必要なデータは、新しいプロセスについて
エラーが発生した最初の時点で捕獲され、問題の再現を
必要としないということである。第３に、早期に検出さ
れたエラーは、エラー検出が大抵の場合あまりにも遅れ
て検出される従来のプロセスとは興なり、永久的なプロ
グラムの損害（データペース破壊、プログラム・コード
の上書きなど）が発生する前に停止することができる、
ということである。第４に、エラーを診断するためにわ
ずかのデータしか収集されず、もってデータ・ダンブ・
リストが小さくなり、記憶すべきデータが減り（ディス
ク・スペースがすこしでよい）、データを収集し出力す
るためのコンピュータによる処理時間が減少する、とい
うことがある。それとは対照的に、トレース点は膨大な
量のデータを捕獲する。第５に、早期エラー検出は、エ
ラーの分離を戒功させる確立を向上させ、以て完全なソ
フトウェア・プログラムの障害の機会を減少させる。

その結果、より高い可用事をもつソフトウェア・プログ
ラムがもたらされる。

Ｅ．実施例ＥＤＤＣプロセスは、アプリケーション・データ・テー
ブル（ＡＤＴ）と称するテーブルの構築を必要とする。

そのエントリは、問題のプログラムについての詳細な情
報を含み、ＥＤＤＣプロセスに対する呼び出しの時点で
、パラメータとじてのエラー検出コードによって選択さ
れる。ＥＤＤＣプロセスは、このテーブル情報を、特定
のプログラム領域のダンブを生威し、ソフトウェア・エ
ラー・ログ中でエントリを作威し、ソフトウェア総称的
警告を構築するために使用する。それは、プロセスに、
有用且つ意味のある診断データ出力を提供するために必
要な全ての情報を与える予定のテーブルである。

第１図を参照すると、テーブル１０は、後述する付章で
詳細に説明されているソフトウェア・マクロ２０の組を
使用して構築されたものである。

そのテーブル・エントリ情報は、エラー検出コードによ
って選択され、やはり付章で記述されているマクロ・コ
ールを介してプロセスに渡される。

この選択は、プロセスに、何が捕獲されるべきかという
ことと、構築されるべき総称的警告のタイプを知らせる
。ＡＤＴ　１　０は、次のようなエントリ・タイプ、す
なわち、アプリケーション・データ・ヘッダ、アプリケ
ごション・データ構造エントリ、総称的警告記述子、総
称的警告原因、及び総称的推奨動作のうちの１つまたは
それ以上を含む。

アプリケーション・データ・ヘッダ・エントリ１１は、
問題のプログラムについての大域的情報を含む。そこに
含まれるのは、問題のプログラムの名前と、そのバージ
ョンまたはリリース番号である。テーブル毎にこれらの
エントリのうちの１つだけが存在する。それは、ＢＬＤ
ＴＡＢＬＥマクロ２１を介してＡＤＴ中に含まれる。こ
のエントリのフォーマット及び構造は、第２図に示され
ている。

アプリケーション・データ構造エソティティ・テーブル
・エントリ１２は、問題のプログラムによって使用され
る単一のデータ構造または制御ブロックのレイアウト及
びフォーマットである。それは、データ構造の長さ及び
名前などの情報を含む。それは、ＡＤＳＥＥＮＴマクロ
２２のコーディングによって、ＡＤＴ中に含まれる。こ
れらのエントリの１つまたはそれ以上が、ＡＤＳＥＥＮ
Ｔキーワードを介して検出点で選択される。ＥＤＤＣプ
ロセスは、どの記憶領域が捕獲に必要であるかを決定す
るためにこう情報を使用する。このテーブル・エントリ
の構造は、第３図に示されている。

総称的警告記述子テーブル・エントリ１３は、総称的警
告によって必要とされる、検出されたエラーのカテゴリ
についての情報を含む。それは、ＧＡＤＳＣＥＮＴマク
ロ２３のコーディングによってＡＤＴ中に含められる．
ＡＬＥＲＴＤＳＣキーワードによって検出点で選択され
ると、ＥＤＤＣプロセスはそれを、総称的警告通知のた
めの総称的警告データ及び可能的原因サブベクトルを構
築するために使用する。このテーブル・エントリの構造
は、第４図に示されている。

総称的警告原因テーブル・エントリ１４は、総称的警告
によって必要とされる、検出されたエラーの原因につい
ての情報を含む。それは、ＧＡＣＳＥＥＮＴマクロ２４
に辻ってＡＤＴ中に含められる。これらのうちの１つま
たはそれ以上を、ＡＬＥＲＴＣＳＥキーワードによって
検出点で選択することができる。ＥＤＤＣプロセスは、
総称的警告通知のための原因サブベクトルを構築するた
めにこれらを使用する。そのテーブル・エントリは、第
５図に示されている。

総称的警告推奨動作テーブル・エントリ１５は、エラー
を解決するために必要な動作についての情報を含む。そ
れは、ＧＡＥＡＣＥＮＴマクロ２５のコーディングによ
ってＡＤＴ中に含められる。これらの１つまたはそれ以
上を、ＡＫＥＲＴＲＡＣキーワードを介して検出点によ
って選択することができる。ＥＤＤＣプロセスは、総称
的警告通知のための推奨動作サブベクトルを構築するた
めにそれを使用する。このテーブル・エントリの構造は
、第６図に示されている。

第７図に示されているような、ソフトウェア・プログラ
ムによるＥＤＤＣプロセスの使用には、２つの異なる動
作が必要である。第１に、ソフトウェア・プログラマは
，ＥＤＤＣソフトウェア・マクロのセットを使用して、
ソフトウェア・プログラムの記憶の使用の内部構造を記
述する。これらのマクロは、通常、ソフトウェア・プロ
グラムの開発と並行する個別のジョブとしてコーディン
グされる。これらのマクロからの出力は、そのエントリ
が、ＥＤＤＣプロセス５０によって必要とされる総称的
警告情報及びソフトウェア・プログラム３０によって使
用されるデータ構造（例えば、制御ブロック、データ領
域）を記述するような、アブリケーシもン・データ・テ
ーブル（ＡＤＴ）１０を含む。第２に、アプリケーショ
ン・プログラマがエラー検出コード３５またはＥＤＤＣ
コールを、プログラム開発の間に、ソフトウェア・プロ
グラム３０内のエラー検出点に配置する。これらの検出
点３５は、「起こるべきでない」条件の存在を検出する
ことになる。

検出点を配置することができる点の例としては次のよう
なものがある。（１）ループａｆＩＡを実現するソフト
ウェア・コードにおいては、ループが実行される回数を
カウントし、それをある最大値と比較する。もしそれが
最大値を超えたなら、ＥＤＤＣプロセスが呼び出される
。（２）プログラムがデータを求めて別のプログラムを
呼び出す場合はいつでも、その別のプログラムが期一待
されたタイプ及びデータの範囲の値を返したことを検証
する。もしそうでないなら、ＥＤＤＣプロセスがコール
される。（３）プログラムが別のプログラムに対してデ
ータの要求を発行する時はいつでも、その応答に許容さ
れる最大の待ち時間をタイマにセットする。もし制御が
戻る前にタイマが切れるなら、ＥＤＤＣプロセスが呼ば
れる。（４）もし別のソフトウェア・ルーチン（例えば
、記憶取得、データベース読取〉からのサービスを実行
するためにソフトウェア・ルーチンが呼ばれ、または要
求され、その呼び出しがエラーである（例えば、その機
能がサポートされていない、呼び出しに無効なデータが
あった〉なら、ＥＤＤＣプロセスが呼び出される。

エラー検出点でつまずいた時はいつでも、検出点がＥＤ
ＤＣプロセスを呼び出し、それに必要な情報を渡す。Ｅ
ＤＤＣプロセス５ｏが呼び出された時、それは次のよう
に動作を行う。（１）ＴＡＢＮＡＭＥキーワードによっ
てＥＤＤＣコール３５中で名付けられたＡＤＴ　１　０
がディスクからメモリにもってこられる（ＡＤＴは、そ
れが構築された後はディスク・ファイルとして格納され
る）。（２）ＥＤＤＣコール３５上でＡＤＳＥＥＮＴキ
ーワードによって選択されたアブリケーシヲン・データ
・エントリ・エンティティ１２が、ＥＤＤＣプロセス５
０によって突き止められる。これらの名付けられたエン
トリのうちのめいめいの１つによって識別されるプログ
ラム記憶が収集されて単一のプログラム・ダンプ・ファ
イル４０中に配置される。そのダンプ・ファイルの名前
は、プロセスが実現きれる時ユーザーによって選択可能
なシーケンス名付け規約を使用して動的に構築される。

ＥＤＤＣプロセス５０は、シーケンス中の次の名前を自
動的に選択する。ユーザーはルート名またはブリフィッ
クスと、１からＥＤＤＣプロセス５０が作成することに
なるダンプ・ファイルの最大数までの数を選択し、それ
はルートまたはプリフィックスに追加される。例えば、
ルート名はＡＰＰＬＤＭＰであり、任意の瞬間に存在す
ることができるダンプ・ファイルの最大数は９である。

ＥＤＤＣプロセス５０は、ＡＰＰＬＤＭＰ１に最初のダ
ンプを排置し、コールされた時ＡＰＰＬＤＭＰ９が構築
されるまでダンブ・データ・セットを構築し続ける。そ
の後、ＥＤＤＣプロセス５０は、前のどれかのダンプ・
データがクリアされたかどうかをチェックする。もしそ
うでないなら、ＥＤＤＣプロセス５０が、ダンプ・デー
タ・セットが可用でなくダンブは行われないことを述べ
るメッセージを発行する。（３）ダンプ・ファイルの最
初に、１次兆候ストリングとして知られる一意的な問題
識別子が排置される。その兆候ストリングは、キーワー
ドと値の対の組からなる。そのキーワードは、それに関
連する意味を識別する。ＥＤＤＣプロセス５０によって
構築された兆候ストリングは、次のようなものである。

゛ＰＩＤＳ／ｘｘｘｘｘｘｘｘ　　ＬＶＬＳ／１１１１
１１１１　　ＲＩＤＳ／ｒｒｒｒｒｒｒｒ　　ＰＣＳＳ
／ｓｓｓｓｓｓｓｓ　　（追加データ）’ＰＩＤ’キー
ワードは、関連の値’ｘｘｘｘｘＸＸＸ゜が、エラー条
件を検出した問題プログラムの名前を含むことを指定す
る。この値は、数または名前である。それは、アブリケ
ーシ３ン・データ・テーブル１０中のアプリケーション
・テーブル・ヘッダ・エントリ１１から取得される。

’ＬＶＬＳ“キーワードは、関連値’１　１　１　１　
１１１１゛が、エラーを検出した問題のプログラムのバ
ージョンまたはリリース・レベルを含むことを指定する
。この値は、アプリケーション・データ・テーブル１０
中のアプリケーション・テーブル・ヘッダ・エントリ１
１から取得される。

’ＲＩＤＳ’キーワードは、関連値’ｒｒｒｒｒｒｒｒ
゛が、エラーを検出した問題のプログラムのモジュール
または要素の名前を含むことを指定する。この値は、Ｅ
ＤＤＣコール３５上のＭＯＤＮＡＭＥキーワードから取
得される。

’ｐｃ　ｓ　ｓ’キーワードは、関連値’８Ｓ３Ｓ８９
９８゛が固有の検出点識別子を含むことを識別する。こ
の値は、ＥＤＤＣコール３５上で渡されたＤＥＴＰＴＩ
ＤキーワードからＥＤＤＣプロセス６０によって受け取
られたものである。ＰＣＳＳ値は通常、そのモジュール
内で一意的なシーケンス番号である。ＥＤＤＣコール３
５上のＭＯＤＮＡＭＥキーワードからのモジュールまた
は要素名とともに、この識別子は、そのソフトウェア・
エラーを検出した検出点を一意的に識別することになる
。

（追加データ）は、ＥＤＤＣプロセス５０によって兆候
ストリング４５に追加されたデータである。それはＥＤ
ＤＣプロセス・コール３５上のＳＹＭＳＴＲＤＴキーワ
ードを介してＥＤＤＣプロセス５０によって受け取られ
たものである。これは、プログラム開発者が、兆候スト
リングに含めるべきプロセスに渡すことができる追加情
報である。各兆候ストリング・エンティティは、フォー
マット゛ｘ　ｘ　ｘ　ｘ　／　ｖ　ｖ　ｖ　ｖ　ｖ　ｖ
　ｖ　ｖ　’をもち、ここで’ｘｘｘｘ′は、関連値”
ｖｖｖｖｖｖｖｖｌのカテゴリを識別するキーワードで
ある。ＥＤＤＣプロセスによって使用されサポートされ
るキーワード全体のセットは以下の第１表に示す通りで
ある。

第１表兆候ストリング・キーワード ’ＡＢ’−’ｖｖｖｖｖｖｖｖ’が異常終了（ＡＢＥＮ
Ｄ）またはプログラム・チェック・コードを含むことを
指定する。

”ＡＤＲＳ’−’ｖｖｖｖｖｖｖｖ’が、検出されたエ
ラーに関連するアドレスまたはオフセットを含むことを
指定する。

’ＤＥＶＳ’−’ｖｖｖｖｖｖｖｖ’が、障害に関連す
る装置を識別する値（例えば、装置番号、装置アドレス
）を含むことを指定する。

’ＦＬＤＳ’　一’ｖｖｖｖｖｖｖｖ’が、検出された
エラーに関連するフィールド、データ構造、またはラベ
ル名を含むことを指定する。

ＭＳ’　一’ｖｖｖｖｖｖｖｖ’が、検出されたエラー
に関連する、または装置によって発行されたメッセージ
番号を含むことを指定する。

’ＯＰＣＳ’−’ｖｖｖｖｖｖｖｖ’が，検出されたエ
ラーに関連するプロセス・コード（例えば、プログラム
・オペレーション・コード、コマンド・コード、要求コ
ード）を含むことを指定する。

’ＯＶＳ’−’ｖｖｖｖｖｖｖｖ’が、記憶が上書きさ
れた記憶領域（例えば制御ブロック、データ領域）の名
前を含むことを指定する。

’ＰＣＳＳ’−’ｖｖｖｖｖｖｖｖ’が、検出されたエ
ラーに関連するステートメント名、コマンドまたはパラ
メータを含むことを指定する。

’ＰＲＣＳ’−’ｖｖｖｖｖｖｖｖ’が、検出されたエ
ラーに関連するリターン・コード、状況コード、条件コ
ード、または装置コードを含むことを指定する。

”ＲＥＧＳ゜−　　ｖｖｖｖｖｖｖｖ’が、検出された
エラーに関連するレジスタ・タイプを含むことを指定す
る。次の゛ＶＡＬＵ’キーワードは、このレジスタに含
まれる値をあらわすことになる。

’ＲＩ　ＤＳ’−’ｖｖｖｖｖｖｖｖ’が、検出された
障害に関連するモジュール、マクロ、サブルーチン、関
数または手続名を含むことを指定する。

’ＳＩＧ−’ｖｖｖｖｖｖｖｖ’が、検出された障害に
関連するオペレータ警報信号識別子を含むことを指定す
る。

’ＶＡＬＵ’−’ｖｖｖｖｖｖｖｖ’が、検出された障
害に関連するレジスタの値を含むことを指定する。この
キーワードは、’ＲＥＧ’キーワードと組み合わせて使
用される。

ＷＳ’−’ｖｖｖｖｖｖｖｖ’が、検出されたエラーに
関連する待機状態コー　ドを含むことを指定する。

データ・ダンプが完了した後、問題のプログラム３０に
対する遅延を最小限にとどめるため、ＥＤＤＣプロセス
５０の呼び出し側に制御が戻される。第８図に示すフォ
ーマットに従ってエラー・ログ・データ・レコードが構
成され、それは、次のような情報を含む。（１）エラー
を検出した問題プログラム３０が実行されているプロセ
ッサの識別子。この情報は、オペレーティング・システ
ム・サービスを通じてアクセスされる。（２〉ＥＤＤＣ
プロセス５０が呼び出された日付及び時間。この情報は
、オペレーティング・システム・サービスを通じてアク
セスされる．（３）記憶ダンブ４０を含むファイルの名
前。これは、ＥＤＤＣプロセス５０内の記憶収集ルーチ
ンから取得される．（４）エラーを検出した問題プログ
ラム３０が走っているオペレーティング・システムの識
別子。この情報は、オペレーティング・システム・サー
ビスを通じてアクセスされる。（５）エラーを検出した
問題プログラム３０の識別子。この情報は、アプリケー
ション・データ・テーブル（ＡＤＴ）１０中のアプリケ
ーション・データ・ヘッダ・エントリ１１から取得され
る。（６）１次兆候ストリング。（７）エラーをさらに
識別するために必要な追加データの集まりであ６２次兆
候ストリング。エラー検出の時点での全てのレジスタと
その値が２次兆候ストリングに含められなくてはならな
い。エラー・ログ・レコードは、ソフトウェア問題エラ
ー・ログ上に配置される。

次に、第１０図に概略的に示すような総称的警告をサポ
ートするコンピュータ・ネットワーク中のプロセッサ上
で実行されるソフトウェア・プログラムのために、総称
的警告が構或される。総称的警告を構或するためには複
数のステップが実行されなくてはならない。第１のステ
ップでは、ＥＤＤＣプロセス・コール３５（第７図）上
のＡＬＥＲＴＤＳＣキーワードによって選択された総称
的警告記述子エントリ１３中の情報から、総称的警告デ
ータ及び可能的原因サブベクトルが構築される。第９図
は、総称的警告記述子エントリ・フィールドの、総称的
警告データ及び可能的原因サブベクトルの詳細なマツビ
ングをあらわす。第２のステップでは、総称的警告原因
サブベクトルが、ＥＤＤＣプロセス・コール３５上のＡ
ＬＥＲＴＣＳＥキーワードによって選択された総称的警
告原因エントリ中の情報から構築される。第９図はやは
りこのマッピングをも示す。第３のステップでは、ＥＤ
ＤＣプロセス・コール３５上のＡＬＥＲＴＲＡＣキーワ
ードによって選択された総称的警告推奨動作エントリ中
の情報から、総称的警告推奨動作サブベクトルが構築さ
れる。第９図は、総称的警告推奨動作サブベクトルに対
する、総称的警告推奨動作エントリの詳細なマツビング
を示す。総称的警告の構成における最後の３つのステッ
プは、エラー・ログ５５上に記憶されたソフトウェア問
題エラー・ログ・レコードからの情報を必要とする。エ
ラー・ログ・レコードからは、日付／時間サブベクトル
、製品識別子サブベクトル、及び相関サブベクトルが構
築される。相関サブベクトルは、記憶ダンプ４０を含む
ファイルの名前を含む。総称的警告７０が一旦構築され
ると、それは、遠隔プロセッサ２００上で走るネットワ
ーク管理プログラム６０から、オペレーティング・シス
テム６５を介して、ホスト・プロセッサ１００での処理
のために、ネットワーク管理アプリケーション７５に渡
される。ホスト・オペレーティング・システム８０は次
に、ネットワーク・オペレータ８５に通知を渡す。この
時点で、ＥＤＤＣプロセスが終了する。

尚、この発明の好適な実施例は、単一のプログラム中の
ソフトウェア・エラーの検出及び診断に関連して説明さ
れてきたが、この発明のシステムと方法は、複数のソフ
トウェア・プログラムを同時に処理するように容易に拡
張することができる。このことは、ＥＤＤＣプロセス５
０を、第７図に示すような多重ＡＤＴ　１　０との共通
のルーチンとして実現することにより達戒される。する
と、各ソフトウェア・プログラム３０は、少なくとも１
つのＡＴＤ　１　０を関連付けられることになる。

Ｆ．付章（Ｉ）アプリケーション・データ・テーブル（ＡＤＴ）
　　・マクロＡＤＴを構築するために使用されるマクロは、ＢＬＤＴ
ＡＢＬＥ，ＡＤＳＥＥＮＴ，ＧＡＤＳＣＥＮＴ，及びＧ
ＡＲＡＣＥＮＴである。これらのマクロのフォーマット
は、以下に示すとおりである。

ＢＬＤＴＡＢＬＥＢＬＤＴＡＢＬＥマクロは、ＡＤＴプロセス構築を介し
するために使用される。それは、ＡＤＴ構築プログラム
における最初のマクロであり、各ＡＤＴテーブル構築毎
に一度存在する。その出力は、テーブル中の最初のエン
トリである、アプリケーション・データ・ヘッダ・エン
トリである。

このマクロのフォーマットは、次のとおりである。

ＢＬＤＴＡＢＬＥ　　ＮＡｌ４Ｅ＝ｔａｂｌｎａｍｅ．
入ＰＰＬＩＤ＝ｐｇｍｎａｍｅ．入ＰＰＬＶＥＲ−ｐｇｍｖｅｒｓｎ，ＳＶＣＬＶＬｇｓｖｃｌｅｖｅｌここで、 ’　ｔａｂ　Ｉ　ｎａｍｅ　’は、このＡＤＴに与えら
れる名前である（このテーブルは、検出点でのＥＤＤＣ
コール上で使用されるＴＡＢＮＡＭＥキーワードを通じ
て、この名前によって選択される）。

ｐｇｍｎａｍｅ　’は、このデータが関連するプログラ
ムの名前である。

ｐｇｍｖｅｒｓｎ’は、このプログラムのバージョンま
たはリリース番号である。

ｓｖｃｌｅｖｅＦは、このプログラムに既に適用された
修正的サービスのレベルである。

ＡＤＳＥＥＮＴＡＤＳＥＥＮＴマクロは、ＡＤＴ中にアプリケーション
・データ構造エンティティ・エントリを配置するために
使用される。このマクロは、ソフトウェア・プログラム
によって使用されるデータ構造または制御ブロックの記
述を構築する。１つまたはそれ異常のＡＤＳＥＥＮＴが
存在してもよく、その各々は次のようなフォーマットを
もつ。

人ＤＳＥＥＮＴ　　ＮＡＭＥ−ｅｎｔｒｎａｒｎａ，Ｄ
ＳＬＥＮＡＤＲ−１ｅｎａｄｒｓ，ＤＳＮＡＤＲＬＮ＝ｎｘａｄｒｌｅｎ，ＤＳＮＸ人ＤＲ
Ｓ−ｎｅｘｔａｄｒｓ，ＳＴＰＩＤＡＤＲ＝ｓｔｉｄａ
ｄｒｓ，ＳＴＯＰＩＯ−ｓｔｐｉｄｖａｌ，ＤＳＩＤＡＤＲ＝ｄｓｉｄａｄｒ，ＤＳＩＤ＝ｄｓｉｄｖａｌ，ＤＳＴＩＴＬＥ＝ｄｓｔｉｔｌｅここで、ｅｎｔｒｎａｒｎｅは、このエントリに割り当
てられた名前、 ’Ｉｅｎａｄｒｓ’は、このデータ構造の長さが配置さ
れている箇所のデータ構造中へのオフセット、ｎｅｘｔ
ａｄｒｓ　’は、このデータ構造のチェインから外れた
、次のデータ構造のアドレスが配置されている、このデ
ータ構造中へのオフセット（このキーワードは、記述さ
れているデータ構造が、連鎖されたデータ構造の列中の
リンクである場合にのみ使用される）。

’ｓｔｉｄａｄｒｓ　’は、チェイン中の最後の識別子
が配置されている、このデータ構造へのオフセットであ
る（このキーワードは、記述されているデータ構造が、
連鎖されたデータ構造の列中のリンクである場合にのみ
使用される。この識別子は、ＥＤＤＣプロセスに、これ
が、連鎖されたデータ構造の列中の最後のデータ構造で
あることを教える〉。

’ｓｔｐｉｄｖａＦは、ＥＤＤＣプロセスがデータ構造
のチェインをダンプしている間に、チェイン・データ構
造の最後が見いだされた時を調べるためのチェックを行
う際に、比較のために使用される。

’ｄｓｉｄａｄｒ’は、データ構造識別子が配置されて
いる箇所での、このデータ構造へのオフセットである（
この識別子の値は、正しいデータ構造が見いだされたこ
とを保証するために、ＤＳＩＤキーワードに割り当てら
れた識別子の値と比較される〉。

’ｄｓｉｄｖａｌ’は、ＤＳＩＤＡＤＲキーワードとし
て指し示される、このデータ構造中で見いだされたデー
タ構造識別子に比較する際に使用される値である。

’ｄｓｔｉｔｌｅ’は、ダンブされた時このデータ構造
上に配置されることになるタイトルである。

ＧＡＤＳＣＥＮＴＧＡＤＳＣＥＮ．Ｔマクロは、総称的警告記述子エント
リをＡＤＴ中に配置するために使用される。このマクロ
は、総称的警告サブベクトルのうちの２つ、すなわち、
総称的警告データ及び可能的原因サブベクトルを構築す
るために必要な情報を含むエントリを構築する。１っま
ｉ二はそれ以上のＧＡＤＳＣＥＮＴが存在することがで
き、その各々は次のようなフォーマットをもつ。

ＧＡＤＳＣＥＮＴ　ＮＡＭＥ＝ｅｎｔｒｎａｍｅ．ＣＡ
ＴＧＹ＝ｅｒｒｃａｔｇｙ，ＤＥＳＣ（ｆ）ＰＴ＝ｄｓｓｅｃｐ，ＰＲＯＢＣＣＰＳ＝　（ｐｒｏｂｃｃｐｌ，．．　ｐｒ
ｏｂｃｃｐｘ）ここで、ｅｎｔｒｎａｔｎｅ’は、このエントリに割り
当てられた名前である。

ｅｒｒｃａｔｇ７’は、障害のカテゴリ（例えば、永久
的、一時的、未知）である。

’ｄｅｓｃｃｐ’は、全体的なエラー記述をあらゎす２
バイト１６進コード点である。

ｐｒｏｂｃｃｐＦ乃至’　ｐｒｏｂｃｃｐｘ　’は、エ
ラーの可能的原因を識別する１乃至５個の１６進コード
点である。

注意：コード点とは、システム・ネットワ−ク・アーキ
テクチャ総称的警告機能によって使用される用語である
。それは、障害のある側面を記述する２バイト１６進の
値をあらわす。この情報の詳綱は、’ＩＢＭ　Ｓｙｓｔ
ｅｎＮｅｔｗｏｒｋ　Ａｒｃｈｉｔｅｃｔｕｒｅ　Ｍａ
ｎｕａｌ　Ｊ注文番号Ｇ人２７−３１３６に記載されて
いる。

ＧＡＣＳＥＥＮＴＧＡＤＳＥＥＮＴマクロは、総称的警告原因エントリを
ＡＤＴ中に配置するために使用される。

このマクロは、総称的原因サブベクトルを構築するため
に必要な情報を含むエントリを構築する。

１つまたはそれ以上のＧＡＣＳＥＥＮＴが存在すること
ができ、その各々は次のようなフォーマットをもつ。

ＧＡＣＳＥＥＮＴ　　Ｎ人ＭＥ＝ｅｎｔｒｎａｍｅ．Ｃ
ＡＵＳＥ＝ｃａｕｓｅｃａｔ，ＣＡＵＳＥＣＰ＝ｃａｕｓｅｃｐ，ＣＰＴＥＸＴ＝（（ｔｅｘｔｔｙｐｅ．ｔｅｘｔ）．・
・・（ｔｅｘｔｔｙｐｅ，　ｔｅｘｔ））ここで、’ｅ
ｎｔｒｎａＩＩｌｅ’は、このエントリ【こ割り当てら
れた名前である。

ｃａｕｓｅｃａｔ”は、原因のカテゴリ（例えば、導入
エラー　ユーザー・エラー　欠陥、未知〉である。

’ｃａｕｓｅｃｐ’は、障害の原因を識別する２バイト
１６進コード点である。

“ｔｅｘｔｔｙｐｅ“は、’ｔｅｘｔ’が何をあらわす
か（　例えば、プログラム・チェック・コード、戻りコ
ード、エラー・コード）を識別する１バイト値である。

’　ｔｅｘｔ　’は、コード点（　’　ｅａｕｓｅｅｐ
　’を参照）Ｃこ関連するテキスト・データである。

注意：選択されたＳＮＡ警告原因コード点に応じて、テ
キスト・データは、その選択されたコード点に関連する
テキスト中への挿入メッセージとして必要とされること
がある。

ＧＡＲＡＣＥＮＴＧＡＲＡＣＥＮＴマクロは、総称的警告推奨動作エント
リをＡＤＴ中に配置するために使用される。このマクロ
は、総称的推奨動作サブベクトルを構築するために必要
な情報を含むエントリを構築する．１つまたはそれ以上
のＧＡＲＡＣＥＮＴが存在することができ、その各々は
次のようなフォーマットをもつ。

ＧＡＲＡＣＥＮＴ　　ＮＡＭＥ＝ｅｎｔｒｎａｎｅ，Ｒ
ＥＣ人ＣＴＣＴ＝ｒａｃｏｄｅｐｔ，ＣＰＴＥＸＴ’（
（ｔｅｘｔｔｙｐｅ，ｔｅｘｔ），．　．　，　（ｔｅ
ｘｔｔｙｐｅ，　ｔｅｘｔ））ここで、’ｅｎｔｒｎａ
ｏｉｅ’は、このエントリに割り当てられた名前である
。

ｒａｃｏｄｅｐｔ”は、障害を解決するために必要な動
作を識別する２バイト１６進コード点である。

’　ｔｅｘｔｔｙｐｅ　’は、’ｔｅｘｔ“が何をあら
わすか（例えば、プログラム・チェック・コード、戻り
コード、エラー・コード）を識別する１バイト値である
。

’　ｔｅｘｔ　’は、コード点（　”　ｒａｃｏｄｅｐ
ｔ　’を参照〉に関連するテキスト・データで・ある。

注意：選択されたＳＮＡ警告推奨動作コード点に応じて
、テキスト・データは、その選択されたコード点に関連
するテキスト中への挿入メッセージヒして必要とされる
ことがある。

（Ｉ　Ｉ）ＥＤＤＣアプリケーション・プログラム・イ
ンターフェースＥＤＤＣプロセスは，呼び出しを通じてアクセスされ、
捕獲されたデータと、生成された総称的警告を決定する
情報を必要とする。呼び出しのフォーマットとこの情報
の記述は以下に示す通りである。

Ｃ人ＬＬ　　ＥＤＤＣ　　．（Ｔ人ＢＬＮＡＭＥ＝ｔａ
ｂｌｅ−ｎａｍｅ，＾ＤＳＴＥＮＴＳ−（（ｅｎｔｒｙ
ｌ，ａｄｄｒｅｓｓ），．．＊　（ｅｎｔｒｙｘ．ａｄ
ｄｒｅｓｓ）），ＭＯＤＮＡＭＥ＝ｍｏｄｕｌｅ　　ｎ
ａｍｅ，ＤＥＴＰＴＩＤ＝ｄｐｉｄ，ＥＲＲＯＲＣＡＴ＝ｃａｔｅｇｏｒｙ．ＳＹｔ４ＳＴＲ
ＤＴ−（（ｋｅｙｗｏｒｄ．ｖａｌｕｅ），．．＊　（
ｋｅｙｗｏｒｄ，ｖａｌｕｅ）），人ＬＥＲＴＤＳＣ＝
ａｌｅｒｔ−ｄｓｃｅｎｔｎＵＵ，人ＬＥＲＴＣＳＥ＝
（ａｌｅｒｔ　　ｃｓｅｎｔｎｍｌ，．．，ａｌｅｒＬ
ｃｓｅｎｔｎｎｘ））．ＡＬＥＲＴＲＡＣ−（ａｌｅｒ
ｔ−ｒａｅｎｔｎｎｌ，．．，ａｌｅｒｔ−ｒａｅｎｔ
ｎｍｘ））．）ここで、’ｔａｂｌｅ−ｎａｍｅ’は、ＥＤＤＣプロセ
スによって使用すべきＡＤＴの名前、ｅｎｔｒｙｌ゜は、捕獲する必要があるデータ構造を記
述するアプリケーション・データ構造エンティティ・エ
ントリの名前、 ’ａｄｄｒｅｓｓ’は、データ構造の問題プログラム内
の開始アドレス（各エントリは、「アドレス」でなくて
はならない）、ａｄｄｒｅｓｓ’はまた、データ構造が位置する問題プ
ログラム内の記憶アドレス、ｍｏｄｕｌｅ−ｎａｍｅ’は、エラーを検出したモジュ
ールまたは要素（すなわち、検出点がつまずいた箇所か
らの）名前、 ’ｄｐｉｄ’は、ＭＯＤＮＡＭＥキーワードによって識
別されるモジュール／要素内の検出点を一意的に識別す
る値、 ’ｃａｔｅｇｏｒｙ’は、検出されたエラーの類別（例
えば、ループ、待機、不正データ）、 ’　ｋｅｙｗｏｒｄ　’は、’ｖａｌｕｅ’という値を
記述する兆候ストリング・キーワード（表１は、サポー
ト兆候ストリング・キーワードとその意味のリストを与
える）、ｖａｌｕｅ’は、兆候ストリング識別子に関連する値、 ’ａｌｅｒｔＪｓｃｅｎｔｎ１は、そのエラーに関連す
るＴＡＢＮＡＭＥキーワードによって名付けられたＡＤ
Ｔ中の総称的警告記述子エントリの名前、’ａｌｅｒｔ
，，−ｃｓｅｎｔｎｍ’は、そのエラーに関連するＴＡ
ＢＮＡＭＥキーワードによって名付けられたＡＤＴ中の
総称的警告原因エントリの名前（これらの名前を１つま
たはそれ以上含めることができる）、 ’ａｌｅｒｔ，，−ｒａｅｎｔｎ１は、そのエラーに関
連するＴＡＢＮＡＭＥキーワードによって名付けられた
ＡＤＴ中の総称的警告推奨動作エントリの名前（これら
の名前を１つまたはそれ以上含めることができる）であ
る。

Ｇ．発明の効果以上説明したように、この発明によれば、ソフトウェア
・エラーが発生すると直ちにそれを検出し、問題の分離
と収集を容易ならしめる限定された量の診断データを自
動的に集めるための方法が提供される。

【図面の簡単な説明】

第１図は、アプリケーション・データ・テーブルの構築
を示す概要図、第２図は、アプリケーション・テーブル・ヘッダ・エン
トリのフォーマットを示す図、第３図は、アプリケーシ
ョン・データ構造エンティテイ′エントリのフォーマッ
ト、第４図は、総称的警告記述子エントリのフォーマット、第５図は、総称的警告原因エントリのフォーマット、第６図は、総称的警告推奨動作エントリのフォーマット
、第７図は、早期検出データ捕獲プロセスの使用と動作を
示す慨要図、第８Ａ及び８Ｂ図は、早期検出データ捕獲プロセスによ
って生成されたエラー・ログ・レコードのフォーマット
を示す図、第９図は、アプリケーション・データ・テーブル・エン
トリ・フィールドと総称的警告フィールドの間の相互参
照を示す図、第１０図は、総称的警告をサポートするコンピュータ・
ネットワークにおける早期検出データ捕獲プロセスの実
現の概要図である，

Claims

【特許請求の範囲】

（１）コンピュータ・プロセッサ・システム上で動作す
るコンピュータ・ソフトウェア・プログラム中のエラー
を検出し診断する方法において、（ａ）上記コンピュー
タ・ソフトウェア・プログラムの内部構造を決定し、該
構造を、ディスク・ファイル中の少なくとも１つの予定
のテーブル中に記録する段階と、（ｂ）上記プログラム内に、診断データを収集すべき時
を知らせるようにソフトウェア・エラーの発生によって
個別に活動化されるエラー検出点を配置する段階と、（ｃ）上記活動化されたエラー検出点によって生成され
た、診断データを集めるための信号の受領に応答して、
上記プログラムの制御を、データ収集及び報告ルーチン
に渡す段階と、（ｄ）上記データ収集及び報告ルーチンに対するマクロ
・コールにより、上記活動化されたエラー検出点によっ
て渡された第１の組のキーワードと値の対と、上記予定
のテーブル中に含まれるプログラム構造に基づき、診断
データを収集して記憶する段階と、（ｅ）データ収集及び報告ルーチンの制御の下で、一意
的な兆候ストリング識別子を生成する段階と、（ｆ）上記兆候ストリング識別子をソフトウェア問題エ
ラー・ログ中に記録する段階を有する、プログラムのエ
ラー検出方法。
（２）ソフトウェア・エラー総称的警告を構築して該総
称的警告をネットワーク・モニタに送る段階をさらに有
する請求項１の方法。
（３）上記診断データが集められた後上記コンピュータ
・ソフトウェア・システムに制御を戻し、プログラム実
行を続ける段階をさらに有する請求項１の方法。
（４）上記兆候ストリングが、ソフトウェア・エラーを
一意的に記述し識別する第２の組のキーワードと値の対
を含む請求項１の方法。
（５）上記コンピュータ・ソフトウェア・プログラムの
内部構造を決定する段階が、収集すべきデータと、構築
すべき総称的警告のタイプを決定するために、上記ソフ
トウェア・プログラムのコーディングと並行して別個の
ジョブとして予定のマクロの組をコーディングする段階
を有する請求項２の方法。
（６）上記予定のテーブルが、対応するソフトウェア・
プログラムの識別情報と、上記ソフトウェア・プログラ
ムによって使用される各データ構造及び制御ブロックの
レイアウト及びフォーマツトと、ソフトウェア・エラー
検出の原因と、そのソフトウェア・エラーを解決するた
めに必要な動作を含む請求項１の方法。
（７）上記プログラム内にエラー検出点を配置する段階
が、ソフトウェア・エラーが生じた場合のみ到達可能な
上記ソフトウェア・プログラム内の点に、上記データ収
集及び報告ルーチンに対するマクロ・コールを位置づけ
る段階を有する請求項１の方法。
（８）上記診断データを収集し記憶する段階が、上記予
定のテーブルを上記ディスク・ファイル中のメモリにロ
ードし、上記データ収集及び報告ルーチンに対するマク
ロ・コール中に含まれるキーワードと値の対の第１の組
に基づき、プログラム記憶から、上記キーワードと値の
対によって識別されるデータを収集し、該収集したデー
タをダンプ・ファイルに書き込む段階を有する請求項１
の方法。
（９）上記兆候ストリング識別子が、プログラム名と、
プログラム・バージヨン及びリリース・レベルと、エラ
ーを検出したプログラム・モジュールと、一意的な検出
点識別子を含む請求項４の方法。
（１０）上記ソフトウェア問題エラー・ログが、プロセ
ッサ及びプログラムを実行するオペレーティング・シス
テムの識別子と、上記データ収集及び報告ルーチンが呼
び出された日付及び時間と、上記収集されたデータを含
むダンプ・ファイルの名前と、上記問題のプログラムの
識別子と、一意的なソフトウェア兆候ストリングを含む
請求項４の方法。
（１１）コンピュータ・プロセッサ・システム上で走る
コンピュータ・ソフトウェア・プログラム中のエラーを
検出して診断するためのシステムであって、（ａ）上記ソフトウェア・プログラムの内部構造をあら
わす少なくとも１つの予定のテーブルを生成するための
手段と、（ｂ）上記ソフトウェア・プログラム内の、ソフトウェ
ア・エラーが発生した場合のみアクセスすることができ
る点に位置づけられ、上記プログラムの実行を中断させ
るためのエラー検出手段と、（ｃ）上記エラー検出手段
によって通知された時に診断データを収集して記憶し、
該ソフトウェア・エラーを一意的に記述し識別するため
の一意的兆候ストリングを生成するためのデータ収集及
び報告手段とを具備する、エラー検出システム。
（１２）ソフトウェア・エラー総括的警告を構成し、該
総括的警告をネットワーク・モニタに送るための手段を
有する請求項１１のシステム。
（１３）上記ソフトウェア・エラーのためのエラー・レ
コードを発生し、上記エラー・レコードを永久的記憶媒
体上のエラー・ログに記録するための手段をさらに有す
る請求項１１のシステム。
（１４）上記診断データと上記兆候ストリングをデータ
・ファイルに永久的に記憶するための手段をさらに有す
る請求項１１のシステム。
（１５）上記エラー検出手段によって通知された時に上
記ソフトウェア・プログラムから上記データ収集及び報
告手段に制御を転送するための手段と、上記診断データ
が収集された後で上記ソフトウェア・プログラムに制御
を戻すための手段をさらに有する請求項１１のシステム
。