JP2001318806A - プログラムの障害解析データ作成方法 - Google Patents
プログラムの障害解析データ作成方法Info
- Publication number
- JP2001318806A JP2001318806A JP2000138815A JP2000138815A JP2001318806A JP 2001318806 A JP2001318806 A JP 2001318806A JP 2000138815 A JP2000138815 A JP 2000138815A JP 2000138815 A JP2000138815 A JP 2000138815A JP 2001318806 A JP2001318806 A JP 2001318806A
- Authority
- JP
- Japan
- Prior art keywords
- data
- module
- failure
- program
- address
- 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.)
- Pending
Links
Landscapes
- Debugging And Monitoring (AREA)
Abstract
(57)【要約】
【課題】 特に大規模なソフトウェアにおいて、障害発
生時に障害原因の可能性のある箇所を素早く特定するこ
とができ、障害解析に必要なデータの取得漏れをなくし
て障害解析データの領域を有効に用いることのできるプ
ログラムの障害解析データ作成方法を提供する。 【解決手段】 ロードモジュール内のある機能のモジュ
ール２２はデータ部２３と実行命令部２４とから構成さ
れている。また、データ部２３には、実行命令部先頭ア
ドレスと実行命令部末尾アドレスとが格納されているた
め、障害発生時の実行命令アドレスを保持するエラープ
ログラムカウンタ４１を基に、各モジュールのデータ部
を参照することにより、当該命令が含まれるモジュール
を特定することができる。また、モジュール毎に優先度
順に取得すべきデータを定義しておくことにより、障害
解析に必要なデータを効率よく取得することができる。
生時に障害原因の可能性のある箇所を素早く特定するこ
とができ、障害解析に必要なデータの取得漏れをなくし
て障害解析データの領域を有効に用いることのできるプ
ログラムの障害解析データ作成方法を提供する。 【解決手段】 ロードモジュール内のある機能のモジュ
ール２２はデータ部２３と実行命令部２４とから構成さ
れている。また、データ部２３には、実行命令部先頭ア
ドレスと実行命令部末尾アドレスとが格納されているた
め、障害発生時の実行命令アドレスを保持するエラープ
ログラムカウンタ４１を基に、各モジュールのデータ部
を参照することにより、当該命令が含まれるモジュール
を特定することができる。また、モジュール毎に優先度
順に取得すべきデータを定義しておくことにより、障害
解析に必要なデータを効率よく取得することができる。
Description
【０００１】
【発明の属する技術分野】このプログラムは、コンピュ
ータプログラム実行中に発生した障害を解析するための
障害解析データ作成方法に関する。特に、開発規模の大
きなコンピュータプログラムのための障害解析データ作
成方法に関する。
ータプログラム実行中に発生した障害を解析するための
障害解析データ作成方法に関する。特に、開発規模の大
きなコンピュータプログラムのための障害解析データ作
成方法に関する。
【０００２】
【従来の技術】コンピュータプログラムの実行中に障害
が発生した場合、コンピュータのオペレーティングシス
テムの機能等によって、障害の解析のためのデータが取
得される。この障害解析データには、障害発生時の実行
命令アドレス、レジスタの値のダンプ、メモリの値のダ
ンプなどが含まれる。このような障害解析データを基に
した解析により、障害の原因の特定が試みられる。
が発生した場合、コンピュータのオペレーティングシス
テムの機能等によって、障害の解析のためのデータが取
得される。この障害解析データには、障害発生時の実行
命令アドレス、レジスタの値のダンプ、メモリの値のダ
ンプなどが含まれる。このような障害解析データを基に
した解析により、障害の原因の特定が試みられる。
【０００３】
【発明が解決しようとする課題】数十人〜数千人の開発
者という大規模な体制で開発されたプログラムの場合、
まず障害の原因となっている可能性のある箇所に責任を
持っている開発担当者を素早く特定し、その特定された
開発担当者が詳細な解析を行うことが効率的である。例
えば、電話交換機ソフトウェアやオンライントランザク
ションシステムやオペレーティングシステムなど、プロ
グラムが大規模であり障害による停止時間がそのまま経
済的損失につながる場合などは、一刻も早く上記開発担
当者の特定を行うことが必要とされる。また、そのよう
な大規模プログラムのテストの段階においても、同様に
障害箇所およびその担当者の特定を素早く行い、テスト
効率を向上させることが望まれる。
者という大規模な体制で開発されたプログラムの場合、
まず障害の原因となっている可能性のある箇所に責任を
持っている開発担当者を素早く特定し、その特定された
開発担当者が詳細な解析を行うことが効率的である。例
えば、電話交換機ソフトウェアやオンライントランザク
ションシステムやオペレーティングシステムなど、プロ
グラムが大規模であり障害による停止時間がそのまま経
済的損失につながる場合などは、一刻も早く上記開発担
当者の特定を行うことが必要とされる。また、そのよう
な大規模プログラムのテストの段階においても、同様に
障害箇所およびその担当者の特定を素早く行い、テスト
効率を向上させることが望まれる。
【０００４】また他の課題として、障害解析データに適
切な範囲のメモリダンプが含まれるようにすることが必
要とされる。近年のコンピュータシステムではメモリ空
間がますます大きくなっているため、その空間すべてに
わたるダンプ出力を行うことは、それ自体が相当の資源
および時間を要する。よって、例えば障害発生時の実行
命令アドレスの近辺など、障害に関連する可能性の高い
範囲に絞ってメモリダンプ出力することがしばしば行わ
れるが、多数のモジュールが複雑に関係し合う構造を有
するプログラムの場合、必ずしも障害の原因となる実行
命令あるいはデータはメモリ上の障害発生時の実行命令
アドレスと無関係な領域に存在していることもあり、そ
のような肝心の領域のダンプが取得できなかったため
に、障害解析が行えなかったり、わざわざ再現テストを
行わざるを得なかったりする場合もある。
切な範囲のメモリダンプが含まれるようにすることが必
要とされる。近年のコンピュータシステムではメモリ空
間がますます大きくなっているため、その空間すべてに
わたるダンプ出力を行うことは、それ自体が相当の資源
および時間を要する。よって、例えば障害発生時の実行
命令アドレスの近辺など、障害に関連する可能性の高い
範囲に絞ってメモリダンプ出力することがしばしば行わ
れるが、多数のモジュールが複雑に関係し合う構造を有
するプログラムの場合、必ずしも障害の原因となる実行
命令あるいはデータはメモリ上の障害発生時の実行命令
アドレスと無関係な領域に存在していることもあり、そ
のような肝心の領域のダンプが取得できなかったため
に、障害解析が行えなかったり、わざわざ再現テストを
行わざるを得なかったりする場合もある。
【０００５】本発明は、上記事情に鑑みてなされたもの
であり、障害発生時に障害原因の可能性のある箇所およ
びその箇所の担当者を素早く特定することができるとと
もに、障害解析に必要なデータの取得漏れをなくして障
害解析データの領域を有効に用いることのできる障害解
析データ作成方法を提供することを目的とする。
であり、障害発生時に障害原因の可能性のある箇所およ
びその箇所の担当者を素早く特定することができるとと
もに、障害解析に必要なデータの取得漏れをなくして障
害解析データの領域を有効に用いることのできる障害解
析データ作成方法を提供することを目的とする。
【０００６】
【課題を解決するための手段】上記の課題を解決するた
めに、請求項１に記載の発明は、予めプログラム内の各
モジュールの実行命令の範囲を示す実行命令範囲情報と
各モジュールのデータのアドレスを示すデータ情報をテ
ーブルに設定しておき、障害発生時のプログラム実行命
令アドレスと前記モジュール範囲情報とから、障害発生
時に実行されていたモジュールを特定し、当該モジュー
ルに関する前記データ情報を基に、データを取得するこ
とを特徴とするプログラムの障害解析データ作成方法を
要旨とする。
めに、請求項１に記載の発明は、予めプログラム内の各
モジュールの実行命令の範囲を示す実行命令範囲情報と
各モジュールのデータのアドレスを示すデータ情報をテ
ーブルに設定しておき、障害発生時のプログラム実行命
令アドレスと前記モジュール範囲情報とから、障害発生
時に実行されていたモジュールを特定し、当該モジュー
ルに関する前記データ情報を基に、データを取得するこ
とを特徴とするプログラムの障害解析データ作成方法を
要旨とする。
【０００７】また、請求項２に記載の発明は、予めプロ
グラム内の各モジュールから呼び出されるタスクに関す
るタスク情報と各モジュールのデータのアドレスを示す
データ情報をテーブルに設定しておき、障害発生時のプ
ログラム実行命令アドレスを基に障害発生時に実行され
ていたタスクを特定し、前記タスク情報を基に当該タス
クを呼び出したモジュールを特定し、当該モジュールに
関する前記データ情報を基に、データを取得することを
特徴とするプログラムの障害解析データ作成方法を要旨
とする。
グラム内の各モジュールから呼び出されるタスクに関す
るタスク情報と各モジュールのデータのアドレスを示す
データ情報をテーブルに設定しておき、障害発生時のプ
ログラム実行命令アドレスを基に障害発生時に実行され
ていたタスクを特定し、前記タスク情報を基に当該タス
クを呼び出したモジュールを特定し、当該モジュールに
関する前記データ情報を基に、データを取得することを
特徴とするプログラムの障害解析データ作成方法を要旨
とする。
【０００８】また、請求項３に記載の発明は、各モジュ
ールの実行に関連する関連モジュールを識別する関連モ
ジュール情報を予め設定しておき、この関連モジュール
情報を基に、障害発生時のプログラム実行命令アドレス
を基に特定されたモジュールに関連する関連モジュール
についても障害解析データ用にデータを取得することを
特徴とするものである。
ールの実行に関連する関連モジュールを識別する関連モ
ジュール情報を予め設定しておき、この関連モジュール
情報を基に、障害発生時のプログラム実行命令アドレス
を基に特定されたモジュールに関連する関連モジュール
についても障害解析データ用にデータを取得することを
特徴とするものである。
【０００９】
【発明の実施の形態】以下、図面を参照しこの発明の一
実施形態について説明する。図１は、本実施形態におけ
る複数のモジュールからなるプログラムの構成を示す構
成図である。図１において、符号１１Ａ、１１Ｂ、１１
Ｃ、・・・はそれぞれ機能Ａ、機能Ｂ、機能Ｃ、・・・
のオブジェクトモジュールであり、２１はこれらのオブ
ジェクトモジュール１１Ａ、１１Ｂ、１１Ｃ、・・・を
連携編集することにより生成されたロードモジュールで
ある。各モジュール毎にその開発に責任を持つ開発担当
者が定められており、その関係は別途管理されている。
実施形態について説明する。図１は、本実施形態におけ
る複数のモジュールからなるプログラムの構成を示す構
成図である。図１において、符号１１Ａ、１１Ｂ、１１
Ｃ、・・・はそれぞれ機能Ａ、機能Ｂ、機能Ｃ、・・・
のオブジェクトモジュールであり、２１はこれらのオブ
ジェクトモジュール１１Ａ、１１Ｂ、１１Ｃ、・・・を
連携編集することにより生成されたロードモジュールで
ある。各モジュール毎にその開発に責任を持つ開発担当
者が定められており、その関係は別途管理されている。
【００１０】図２は、各機能毎のモジュール内の構成を
示す構成図である。図２において、符号２２は、ロード
モジュール内の１機能のモジュールであり、モジュール
２２は、データ部２３と実行命令部２４とから成ってい
る。図２ではデータ部２３には、機能テーブルアドレ
ス、機能テーブル番号、実行命令部先頭アドレス、実行
命令部末尾アドレスなどのデータがエントリーされてい
る。これらの先頭アドレスおよび末尾アドレスにより、
メモリ空間上における当該実行命令部の範囲が示されて
いる。ここで、機能テーブルアドレスとはデータ部２３
自身の先頭アドレスであり、機能テーブル番号とはロー
ドモジュール内におけるこのモジュールの識別番号であ
り、実行命令部先頭アドレスおよび末尾アドレスは実行
命令部２４のそれぞれ先頭と末尾のアドレスである。こ
れらのデータの他にも、このデータ部２３には、このモ
ジュール自身のためのデータ領域や他のモジュールとの
インタフェースとなるデータ領域が存在している。ま
た、実行命令部２４の先頭と末尾にはそれぞれ先頭識別
データおよび末尾識別データが配置されている。これら
先頭識別データおよび末尾識別データは、それぞれ固定
的なパターンのデータであり、これらのデータに挟まれ
た領域が実行命令であることを表している。一例として
は、先頭識別データとしては「１２３４５６７８」、末
尾識別データとしては「８７６５４３２１」といった文
字データを用いる。
示す構成図である。図２において、符号２２は、ロード
モジュール内の１機能のモジュールであり、モジュール
２２は、データ部２３と実行命令部２４とから成ってい
る。図２ではデータ部２３には、機能テーブルアドレ
ス、機能テーブル番号、実行命令部先頭アドレス、実行
命令部末尾アドレスなどのデータがエントリーされてい
る。これらの先頭アドレスおよび末尾アドレスにより、
メモリ空間上における当該実行命令部の範囲が示されて
いる。ここで、機能テーブルアドレスとはデータ部２３
自身の先頭アドレスであり、機能テーブル番号とはロー
ドモジュール内におけるこのモジュールの識別番号であ
り、実行命令部先頭アドレスおよび末尾アドレスは実行
命令部２４のそれぞれ先頭と末尾のアドレスである。こ
れらのデータの他にも、このデータ部２３には、このモ
ジュール自身のためのデータ領域や他のモジュールとの
インタフェースとなるデータ領域が存在している。ま
た、実行命令部２４の先頭と末尾にはそれぞれ先頭識別
データおよび末尾識別データが配置されている。これら
先頭識別データおよび末尾識別データは、それぞれ固定
的なパターンのデータであり、これらのデータに挟まれ
た領域が実行命令であることを表している。一例として
は、先頭識別データとしては「１２３４５６７８」、末
尾識別データとしては「８７６５４３２１」といった文
字データを用いる。
【００１１】４１はＥＰＣ（エラープログラムカウン
タ）であり、何らかの障害が発生したときに、このＥＰ
Ｃ４１は障害発生時の実行プログラムアドレスを保持す
る。従って、障害発生時にこのＥＰＣ４１を参照して、
そのＥＰＣ４１が指す実行命令がどのモジュールに含ま
れているかを逆に辿ることによって、障害発生時の実行
モジュールを特定することが可能となる。
タ）であり、何らかの障害が発生したときに、このＥＰ
Ｃ４１は障害発生時の実行プログラムアドレスを保持す
る。従って、障害発生時にこのＥＰＣ４１を参照して、
そのＥＰＣ４１が指す実行命令がどのモジュールに含ま
れているかを逆に辿ることによって、障害発生時の実行
モジュールを特定することが可能となる。
【００１２】本実施形態では、モジュール内部から「タ
スク」と呼ばれるサブモジュールを呼び出す場合があ
る。このタスクが行う処理の例としては、入出力装置な
どからデータを読み込むあるいは入出力装置などにデー
タを書き出すことや、他のコンピュータシステムなどに
データを転送することなどがある。本実施形態は、この
ようなタスクにおいて障害が発生した場合にも、障害箇
所を特定して適切な障害解析データを取得するためのし
くみを持っている。図３は、モジュールとそれらのモジ
ュールから呼び出されるタスクのタスクタイプとの関係
を保持するデータの構造を示す構造図である。図３にお
いて、符号５１Ａ、５１Ｂ、・・・は、それぞれ機能
Ａ、機能Ｂ、・・・のタスクタイプテーブルであり、５
２はそれらのタスクタイプテーブルのアドレスを保持す
るタスクタイプテーブルベクタである。
スク」と呼ばれるサブモジュールを呼び出す場合があ
る。このタスクが行う処理の例としては、入出力装置な
どからデータを読み込むあるいは入出力装置などにデー
タを書き出すことや、他のコンピュータシステムなどに
データを転送することなどがある。本実施形態は、この
ようなタスクにおいて障害が発生した場合にも、障害箇
所を特定して適切な障害解析データを取得するためのし
くみを持っている。図３は、モジュールとそれらのモジ
ュールから呼び出されるタスクのタスクタイプとの関係
を保持するデータの構造を示す構造図である。図３にお
いて、符号５１Ａ、５１Ｂ、・・・は、それぞれ機能
Ａ、機能Ｂ、・・・のタスクタイプテーブルであり、５
２はそれらのタスクタイプテーブルのアドレスを保持す
るタスクタイプテーブルベクタである。
【００１３】これらのタスクタイプテーブル５１Ａ、５
１Ｂ、・・・およびタスクタイプテーブルベクタ５２の
領域は予めロードモジュール内に確保されるようにして
も良いし、ロードモジュール内の情報を基に障害解析デ
ータ作成機能内のデータ領域に確保しても良い。
１Ｂ、・・・およびタスクタイプテーブルベクタ５２の
領域は予めロードモジュール内に確保されるようにして
も良いし、ロードモジュール内の情報を基に障害解析デ
ータ作成機能内のデータ領域に確保しても良い。
【００１４】そして、例えば、タスクタイプテーブル５
１Ａは、機能Ａのモジュールから呼び出されるタスクす
べてについてのエントリーを有しており、それぞれのエ
ントリーは、「（機能Ａの名前）＿（タスク固有の名
前）」などといった形式のタスクタイプを保持してい
る。また、タスクを呼び出して実行する際にはそのタス
クタイプが一時的に記録されるとともに、タスク内にお
いて障害が起こった場合も前述の場合と同様にＥＰＣに
障害発生時の実行命令アドレスが保持される。このよう
にして、タスク内での障害の場合にも、障害の起こった
タスクと、そのタスクを呼び出していたモジュールを特
定することが可能となる。
１Ａは、機能Ａのモジュールから呼び出されるタスクす
べてについてのエントリーを有しており、それぞれのエ
ントリーは、「（機能Ａの名前）＿（タスク固有の名
前）」などといった形式のタスクタイプを保持してい
る。また、タスクを呼び出して実行する際にはそのタス
クタイプが一時的に記録されるとともに、タスク内にお
いて障害が起こった場合も前述の場合と同様にＥＰＣに
障害発生時の実行命令アドレスが保持される。このよう
にして、タスク内での障害の場合にも、障害の起こった
タスクと、そのタスクを呼び出していたモジュールを特
定することが可能となる。
【００１５】次に、障害解析のために有効なデータを取
得する方法について説明する。図４は、障害解析データ
取得のためのデータの構造を示す構造図である。図４に
おいて、符号６１Ａは機能Ａのためのデータテーブルで
あり、６２は複数のモジュールのためのデータテーブル
のアドレスを保持するデータテーブルベクタである。デ
ータテーブル６１Ａには、関連機能のテーブル番号を保
持する領域が設けられている。この領域には、機能Ａに
関連の深い他の機能（例えば、機能Ａのモジュールが呼
び出される直前に実行されるモジュール等）を識別する
番号が格納されている。なお、この関連モジュールは１
個だけでも良いし、複数であっても良い。このように関
連機能のテーブル番号を保持することにより、例えば、
障害が発生したときには機能Ａのモジュールの実行中で
あったがその障害の原因が関連モジュールの方にある場
合などにも、有効な解析データを取得することが可能と
なる。
得する方法について説明する。図４は、障害解析データ
取得のためのデータの構造を示す構造図である。図４に
おいて、符号６１Ａは機能Ａのためのデータテーブルで
あり、６２は複数のモジュールのためのデータテーブル
のアドレスを保持するデータテーブルベクタである。デ
ータテーブル６１Ａには、関連機能のテーブル番号を保
持する領域が設けられている。この領域には、機能Ａに
関連の深い他の機能（例えば、機能Ａのモジュールが呼
び出される直前に実行されるモジュール等）を識別する
番号が格納されている。なお、この関連モジュールは１
個だけでも良いし、複数であっても良い。このように関
連機能のテーブル番号を保持することにより、例えば、
障害が発生したときには機能Ａのモジュールの実行中で
あったがその障害の原因が関連モジュールの方にある場
合などにも、有効な解析データを取得することが可能と
なる。
【００１６】また、データテーブル６１Ａは、機能Ａが
使用するデータのデータアドレスとデータサイズとデー
タ名とを優先度の大きい順に保持している。これによ
り、障害発生時に、それらのデータを優先度の大きい順
に障害解析データ内に含めることが可能となる。また、
このデータテーブル６１Ａに登録されているデータのみ
を障害解析データ内に含めることも可能であり、それ以
外の無用のデータが障害解析データの領域を占めること
なく、障害解析データ領域を有効に利用することが可能
となる。
使用するデータのデータアドレスとデータサイズとデー
タ名とを優先度の大きい順に保持している。これによ
り、障害発生時に、それらのデータを優先度の大きい順
に障害解析データ内に含めることが可能となる。また、
このデータテーブル６１Ａに登録されているデータのみ
を障害解析データ内に含めることも可能であり、それ以
外の無用のデータが障害解析データの領域を占めること
なく、障害解析データ領域を有効に利用することが可能
となる。
【００１７】なお、データテーブル６１Ａの内容、つま
り関連機能や取得データの優先度等は、機能Ａの開発者
によって定義され、コンパイルおよびリンケージの過程
を通してこのデータテーブル６１Ａの領域に設定され
る。また、機能Ｂ、Ｃ、Ｄ、・・・のそれぞれについて
も、データテーブルが存在しており、それぞれのデータ
テーブルはデータテーブルベクタ６２の各エントリから
指されている。これらのデータテーブル６１Ａ、・・・
およびデータテーブルベクタ６２の領域は予めロードモ
ジュール内に確保されるようにしても良いし、ロードモ
ジュール内の情報を基に障害解析データ作成機能内のデ
ータ領域に確保しても良い。
り関連機能や取得データの優先度等は、機能Ａの開発者
によって定義され、コンパイルおよびリンケージの過程
を通してこのデータテーブル６１Ａの領域に設定され
る。また、機能Ｂ、Ｃ、Ｄ、・・・のそれぞれについて
も、データテーブルが存在しており、それぞれのデータ
テーブルはデータテーブルベクタ６２の各エントリから
指されている。これらのデータテーブル６１Ａ、・・・
およびデータテーブルベクタ６２の領域は予めロードモ
ジュール内に確保されるようにしても良いし、ロードモ
ジュール内の情報を基に障害解析データ作成機能内のデ
ータ領域に確保しても良い。
【００１８】次に、障害発生時の障害解析データ作成手
順について説明する。図５は、障害解析データ作成手順
を示すフローチャートである。障害発生時には障害解析
データ作成機能が実行され、この障害解析データ作成機
能は、まずエラープログラムを参照することによって障
害が発生した実行命令のアドレスを特定する（ステップ
Ｓ１）。次にそのアドレスがタスク内かどうかを判別し
（ステップＳ２）、タスク内でない場合は、ロードモジ
ュール内の各モジュールのデータ部に格納されている実
行命令部先頭アドレスおよび実行命令部末尾アドレスを
基に該当するモジュールを特定する（ステップＳ３）。
タスク内である場合には、タスクタイプを特定し（ステ
ップＳ４）、そのタスクタイプを基にタスクタイプテー
ブルを参照することなどによってモジュールを特定する
（ステップＳ５）。
順について説明する。図５は、障害解析データ作成手順
を示すフローチャートである。障害発生時には障害解析
データ作成機能が実行され、この障害解析データ作成機
能は、まずエラープログラムを参照することによって障
害が発生した実行命令のアドレスを特定する（ステップ
Ｓ１）。次にそのアドレスがタスク内かどうかを判別し
（ステップＳ２）、タスク内でない場合は、ロードモジ
ュール内の各モジュールのデータ部に格納されている実
行命令部先頭アドレスおよび実行命令部末尾アドレスを
基に該当するモジュールを特定する（ステップＳ３）。
タスク内である場合には、タスクタイプを特定し（ステ
ップＳ４）、そのタスクタイプを基にタスクタイプテー
ブルを参照することなどによってモジュールを特定する
（ステップＳ５）。
【００１９】モジュールが特定されると、データテーブ
ルベクタからそのモジュールのデータテーブルのアドレ
スを取得し（ステップＳ６）、そのデータテーブルか
ら、設定されている優先度に従って、各データのデータ
アドレスとデータサイズとデータ名を取得して、さらに
そのデータ領域のデータを取得する（ステップＳ７）。
次に、該当モジュールのデータテーブルを参照してその
モジュールの関連機能のテーブル番号を取得し（ステッ
プＳ８）、関連モジュールのデータテーブルから、設定
されている優先度に従って、関連機能の各データのデー
タアドレスとデータサイズとデータ名を取得して、さら
にそのデータ領域のデータを取得する（ステップＳ
９）。
ルベクタからそのモジュールのデータテーブルのアドレ
スを取得し（ステップＳ６）、そのデータテーブルか
ら、設定されている優先度に従って、各データのデータ
アドレスとデータサイズとデータ名を取得して、さらに
そのデータ領域のデータを取得する（ステップＳ７）。
次に、該当モジュールのデータテーブルを参照してその
モジュールの関連機能のテーブル番号を取得し（ステッ
プＳ８）、関連モジュールのデータテーブルから、設定
されている優先度に従って、関連機能の各データのデー
タアドレスとデータサイズとデータ名を取得して、さら
にそのデータ領域のデータを取得する（ステップＳ
９）。
【００２０】上述の障害解析データ取得の過程は、プロ
グラムの形式でコンピュータ読み取り可能な記録媒体に
記憶されており、このプログラムをコンピュータが読み
出して実行することによって、上記処理が行われる。こ
こでコンピュータ読み取り可能な記録媒体とは、フロッ
ピー（登録商標）ディスク、光磁気ディスク、ＣＤ−Ｒ
ＯＭ、磁気ハードディスク、半導体メモリ等をいう。
グラムの形式でコンピュータ読み取り可能な記録媒体に
記憶されており、このプログラムをコンピュータが読み
出して実行することによって、上記処理が行われる。こ
こでコンピュータ読み取り可能な記録媒体とは、フロッ
ピー（登録商標）ディスク、光磁気ディスク、ＣＤ−Ｒ
ＯＭ、磁気ハードディスク、半導体メモリ等をいう。
【００２１】また本明細書では、「モジュール」という
語は、論理的構造を持つプログラムの一部分、複数の文
や命令などからなる機能単位、あるいはプログラム部品
などの総称として用いている。モジュールは多重のネス
ト構造を持つ場合がある。つまり、言い換えれば、ある
モジュールは単数または複数の他のモジュールから構成
される場合がある。各々のプログラム言語に応じてある
いは各々の開発方法論に応じて用いられる次のような語
は、ここでいう「モジュール」の例である。すなわち、
例えば、ブロック（block ）、関数（ファンクション、
function）、手続き（プロシジャ、procedure ）、ルー
チン（routine ）、サブルーチン（subroutine）、サブ
プログラム（subprogram）、タスク（task）、サブタス
ク（subtask ）、オブジェクト（object）、クラス（cl
ass ）、メソッド（method）、メッセージ（message
）、パッケージ（package ）、プロジェクト（project
）などである。但し、これらに限定されない。
語は、論理的構造を持つプログラムの一部分、複数の文
や命令などからなる機能単位、あるいはプログラム部品
などの総称として用いている。モジュールは多重のネス
ト構造を持つ場合がある。つまり、言い換えれば、ある
モジュールは単数または複数の他のモジュールから構成
される場合がある。各々のプログラム言語に応じてある
いは各々の開発方法論に応じて用いられる次のような語
は、ここでいう「モジュール」の例である。すなわち、
例えば、ブロック（block ）、関数（ファンクション、
function）、手続き（プロシジャ、procedure ）、ルー
チン（routine ）、サブルーチン（subroutine）、サブ
プログラム（subprogram）、タスク（task）、サブタス
ク（subtask ）、オブジェクト（object）、クラス（cl
ass ）、メソッド（method）、メッセージ（message
）、パッケージ（package ）、プロジェクト（project
）などである。但し、これらに限定されない。
【００２２】
【発明の効果】以上説明したように、この発明によれ
ば、各モジュールおよび各タスクの実行命令部の先頭ア
ドレスおよび末尾アドレスをデータとして保持し、これ
らのアドレスを障害発生時の実行命令アドレスと比較す
る処理を行うため、障害発生時に実行されていたモジュ
ールを素早く特定することが可能となる。また、このモ
ジュールを特定することにより障害発生箇所のプログラ
ムに責任を持つ開発担当者を素早く特定できるため、障
害の解析を効率的に行うことが可能となる。
ば、各モジュールおよび各タスクの実行命令部の先頭ア
ドレスおよび末尾アドレスをデータとして保持し、これ
らのアドレスを障害発生時の実行命令アドレスと比較す
る処理を行うため、障害発生時に実行されていたモジュ
ールを素早く特定することが可能となる。また、このモ
ジュールを特定することにより障害発生箇所のプログラ
ムに責任を持つ開発担当者を素早く特定できるため、障
害の解析を効率的に行うことが可能となる。
【００２３】また、この発明によれば、モジュール毎に
重要なデータのアドレスやサイズを優先度とともに予め
設定しておき、障害発生時には、障害発生時に実行され
ていたモジュールに関する重要なデータを取得して障害
解析データとして出力することが可能になるため、障害
の解析を効率的に行うことが可能になるとともに、不用
なデータが障害解析データ領域を無駄に占めることがな
いため、障害解析データ領域を有効に利用することがで
きる。特に電話交換機等、専用の障害解析データ領域を
用いることになっているソフトウェアの場合に、この効
果によるメリットが大きい。
重要なデータのアドレスやサイズを優先度とともに予め
設定しておき、障害発生時には、障害発生時に実行され
ていたモジュールに関する重要なデータを取得して障害
解析データとして出力することが可能になるため、障害
の解析を効率的に行うことが可能になるとともに、不用
なデータが障害解析データ領域を無駄に占めることがな
いため、障害解析データ領域を有効に利用することがで
きる。特に電話交換機等、専用の障害解析データ領域を
用いることになっているソフトウェアの場合に、この効
果によるメリットが大きい。
【００２４】また、この発明によれば、ある機能のモジ
ュールと関連する機能を識別するためのテーブル番号を
予め設定しておき、障害発生時には、障害発生時に直接
実行されていたモジュールだけでなく、この関連モジュ
ールについてもデータを取得するため、解析に必要なデ
ータの取得漏れの可能性が小さくなる。
ュールと関連する機能を識別するためのテーブル番号を
予め設定しておき、障害発生時には、障害発生時に直接
実行されていたモジュールだけでなく、この関連モジュ
ールについてもデータを取得するため、解析に必要なデ
ータの取得漏れの可能性が小さくなる。
【図１】 この発明の一実施形態による複数のモジュー
ルからなるプログラム（ロードモジュール）の構成を示
す構成図である。
ルからなるプログラム（ロードモジュール）の構成を示
す構成図である。
【図２】 同実施形態による各機能毎のモジュール内の
構成を示す構成図である。
構成を示す構成図である。
【図３】 同実施形態によるモジュールとタスクのタス
クタイプとの関係を保持するデータの構造を示す構造図
である。
クタイプとの関係を保持するデータの構造を示す構造図
である。
【図４】 同実施形態による障害解析データ取得のため
のデータの構造を示す構造図である。
のデータの構造を示す構造図である。
【図５】 同実施形態による障害解析データ作成の手順
を示すフローチャートである。
を示すフローチャートである。
１１Ａ，１１Ｂ，１１Ｃ オブジェクトモジュール ２１ ロードモジュール ２２ モジュール ２３ データ部 ２４ 実行命令部 ４１ ＥＰＣ（エラープログラムカウンタ） ５１Ａ，５１Ｂ，・・・ タスクタイプテーブル ５２ タスクタイプテーブルベクタ
Claims (3)
- 【請求項１】 予めプログラム内の各モジュールの実行
命令の範囲を示す実行命令範囲情報と各モジュールのデ
ータのアドレスを示すデータ情報をテーブルに設定して
おき、 障害発生時のプログラム実行命令アドレスと前記モジュ
ール範囲情報とから、障害発生時に実行されていたモジ
ュールを特定し、 当該モジュールに関する前記データ情報を基に、データ
を取得することを特徴とするプログラムの障害解析デー
タ作成方法。 - 【請求項２】 予めプログラム内の各モジュールから呼
び出されるタスクに関するタスク情報と各モジュールの
データのアドレスを示すデータ情報をテーブルに設定し
ておき、 障害発生時のプログラム実行命令アドレスを基に障害発
生時に実行されていたタスクを特定し、前記タスク情報
を基に当該タスクを呼び出したモジュールを特定し、 当該モジュールに関する前記データ情報を基に、データ
を取得することを特徴とするプログラムの障害解析デー
タ作成方法。 - 【請求項３】 各モジュールの実行に関連する関連モジ
ュールを識別する関連モジュール情報を予め設定してお
き、 この関連モジュール情報を基に、障害発生時のプログラ
ム実行命令アドレスを基に特定されたモジュールに関連
する関連モジュールについても障害解析データ用にデー
タを取得することを特徴とする請求項１または２に記載
のプログラムの障害解析データ作成方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000138815A JP2001318806A (ja) | 2000-05-11 | 2000-05-11 | プログラムの障害解析データ作成方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000138815A JP2001318806A (ja) | 2000-05-11 | 2000-05-11 | プログラムの障害解析データ作成方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2001318806A true JP2001318806A (ja) | 2001-11-16 |
Family
ID=18646376
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000138815A Pending JP2001318806A (ja) | 2000-05-11 | 2000-05-11 | プログラムの障害解析データ作成方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2001318806A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2012137239A1 (ja) * | 2011-04-04 | 2012-10-11 | 株式会社日立製作所 | 計算機システム |
| JP2013167937A (ja) * | 2012-02-14 | 2013-08-29 | Fujitsu Ltd | 情報処理装置、プログラムおよびエラー処理方法 |
-
2000
- 2000-05-11 JP JP2000138815A patent/JP2001318806A/ja active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2012137239A1 (ja) * | 2011-04-04 | 2012-10-11 | 株式会社日立製作所 | 計算機システム |
| JP2013167937A (ja) * | 2012-02-14 | 2013-08-29 | Fujitsu Ltd | 情報処理装置、プログラムおよびエラー処理方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5717950A (en) | Input/output device information management system for multi-computer system | |
| CN110659256B (zh) | 多机房同步方法、计算设备及计算机存储介质 | |
| JP2001318806A (ja) | プログラムの障害解析データ作成方法 | |
| JP2005338987A (ja) | 例外テスト支援プログラム及び例外テスト支援装置 | |
| US6141635A (en) | Method of diagnosing faults in an emulated computer system via a heterogeneous diagnostic program | |
| US7277920B2 (en) | Implementing applications requiring access to multiple files | |
| JP3608993B2 (ja) | コンパイラ装置及びコンパイラプログラムを記録した記録媒体 | |
| JPH09146782A (ja) | ジョブ間データ引き継ぎにおける異常発生時の対応方法 | |
| US20040093537A1 (en) | System for determining computer program memory allocation and deallocation | |
| JPH08286950A (ja) | 情報処理装置及びトレース情報格納方法 | |
| JPH11265278A (ja) | オペレーティングシステムの動的機能管理方法 | |
| JP3179353B2 (ja) | プログラムテスト自動化システム | |
| JPH11154093A (ja) | プログラムコンパイラ及びコンパイラ用プログラムを記録した記録媒体 | |
| JP2001142772A (ja) | メモリの名称による管理方法及び複写方法並びにメモリの名称による管理プログラムを記録した媒体及び複写プログラムを記録した媒体 | |
| JP2000010820A (ja) | マルチプロセスシステムにおける１プロセスのテスト方法及びシステム | |
| JP3079825B2 (ja) | 電子計算機装置 | |
| JPH0659937A (ja) | ロードモジュール単体テスト支援装置 | |
| JPH04324525A (ja) | プログラム移植支援装置 | |
| JP2655612B2 (ja) | 外部参照更新方式 | |
| JPH07168711A (ja) | プログラム管理方法 | |
| JP2000339145A (ja) | プログラム保守支援方法、装置及び記録媒体 | |
| JP2000112771A (ja) | 割り込み制御装置、割り込み処理方法、オペレーティングシステム、マイクロコンピュータシステム、情報処理装置、プログラムを記録した記録媒体 | |
| JPH11149489A (ja) | シミュレーション装置 | |
| JPS63313231A (ja) | 自動磁気テ−プトレイララベル書き込み方式 | |
| JP2000172528A (ja) | デバッグ支援装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040525 |