複数の高水準プログラム言語 (HLL) をサポートするために、Debug Tool は、そのコマンドをそれらの HLL に合うように変え、さまざまな HLL コマンドの解釈サブセット を提供し、これらの言語全体にわたってデータ型の共通属性をマップします。さらに、HLL 式の評価、および定数と変数の処理を行います。
下記のトピックは、Debug Tool がどのようにして、さまざまな言語、構造、規則、変数、および式計算の手法で構成されるプログラムをデバッグできるようになっているかについて説明します。
一般規則として、Debug Tool が各言語をどのように処理するかを、Debug Tool が言語自体に決めさせようとすることに注意してください。
ここで述べた内容に関して詳しくは、以下のトピックを参照してください。
式を入力すると、Debug Tool はその時点で有効な プログラム言語を記録します。式が実行されると、Debug Tool は、式が入力された時点で有効な言語の 実行時モジュールにそれを渡します。この実行時モジュールは、式が実行された時点で有効なものとは異なる 可能性があります。
即時には実行されない式を入力する場合、すべてのプログラム変数を 完全修飾しておくようにしてください。変数を修飾する と、式が実行されるときに言語の実行時モジュールに、確実に正しい コンテキスト情報 (ロード・モジュール、ブロックなど) が渡されます。完全修飾を行わなかった場合、ブレークポイントを設定したときに意図した コンテキストとは異なる可能性があり、言語の実行時モジュールは 式の評価をしない場合もあります。
ここで述べた内容に関して詳しくは、以下のトピックを参照してください。
Debug Tool は、HLL 変数と定数の使用をサポートしており、テスト・プログラムの 計算式の中でも、宣言の中でも、セッション変数としてでも使用できます。
Debug Tool は 3 つの一般的なタイプの変数をサポートします。
変数参照のなかには、ポインターの参照や添え字計算など、その言語に特有の 計算を必要とするものがあります。再確認しますが、Debug Tool は対象の HLL の規則によって各ケースを解釈します。Debug Tool は、現行のプログラム言語に応じて異なる形式の参照を 受け入れます。以下にその一部を示します。
ストリング定数と数値定数の両方を使用することができます。Debug Tool は、C および C++、COBOL、および PL/I の両方のタイプの定数を受け入れます。
デバッグ・セッションで使い慣れたコマンドを使用できるようにするために、Debug Tool には、各言語のコマンドの解釈サブセット が用意されています。これは、同じ構文のコマンドからなり、Debug Tool で使用されるコマンドであるか、アプリケーション・プログラムを書くときに使用されるものであるかを問いません。これらのコマンドは、Debug Tool でも、元の言語でコーディングしたときと 同じように使用することができます。
SET PROGRAMMING LANGUAGE コマンドを使用して、現行プログラム言語を希望する言語に設定します。現行プログラム言語の設定値により、コマンドの解析方法が決まります。SET PROGRAMMING LANGUAGE を AUTOMATIC に設定すると、現行の修飾が別の言語のモジュールに変更されるたびに、現行プログラム言語も自動的に更新されます。
以下のタイプの Debug Tool コマンドは、サポートするどのプログラム言語でも、対応ステートメント (ただし定義されている場合) の構文 (または そのサブセット) が同じになっています。
さらに、Debug Tool はある種の言語には特別のコマンドをサポートします。
各 HLL で名前の有効範囲の概念を定義しています。これによって、1 つの コンパイル単位内で、ある名前を複数回使用したときにどのデータが参照されるか わかるようになります (例: 2 つの異なるプロシージャーに おいて同じ変数名を使用する場合)。同様に、Debug Tool はランタイム環境のための修飾子の概念および視点についても 定義を行って、プログラムの中にサブルーチンが多数あっても、すべての変数を参照可能にしています。x = 5 という割り当ては、Debug Tool にとって処理が困難であるようには見えません。しかし、複数のサブルーチンで x を宣言すると、必ずしもそうとは限らなくなります。現在実行中のコンパイル単位に x が含まれていない場合、なんらかの手段によってユーザーが正しい x の判別方法を Debug Tool に指示することが必要です。
また、Debug Tool が現在見ることのできない変数 (すなわち、HLL の名前の有効範囲の概念によって、現在実行中のブロックまたはコンパイル単位の有効範囲に含まれない変数) を参照できるように、なんらかの手段でその視点を変更する必要もあります。
ここで述べた内容に関して詳しくは、以下のトピックを参照してください。
修飾は、特定の変数がどの手順またはロード・モジュールに属するのかを 指定する方法です。そのためには、ブロック、コンパイル単位、および ロード・モジュール (または必要なすべてのラベル) で 変数に接頭部を付け、各ラベルをコロン (またはロード・モジュール指定に 続くダブル・コロン) およびより大きい記号 (:>) によって 区切ります。次のようになります。
load_name::>cu_name:>block_name:>object
このプロシージャー (明示修飾 と呼ばれます) を使用すると、Debug Tool は、変数のある場所を正確に知ることができます。
必要であれば、load_name がロード・モジュールの名前となります。ロード・モジュールの名前は、プログラムが複数のロード・モジュールで 構成される場合で、かつ修飾を現行のロード・モジュール以外に変更したい 場合にのみ必要です。load_name は、Debug Tool 変数の %LOAD にすることができます。
必要であれば、cu_name がコンパイル単位の名前となります。cu_name は、修飾を、現在修飾されているコンパイル単位以外に変更したい場合にのみ必要です。cu_name は、Debug Tool 変数の %CU にする ことができます。
必要であれば、block_name がプログラムのブロック名となります。block_name は、修飾を、現在修飾されているブロック以外に変更したい場合にのみ必要です。block_name は、Debug Tool の変数 %BLOCK に できます。
PL/I の場合のみ:
LM::>PROC1:>variable上の例は有効です。
LM::>PROC1:>PROC1:>variable上の例は無効です。
C++ の場合のみ:
qualify block %load::>"USERID.SOURCE.LISTING(ICCD226)":>ICCD2263()
AT ENTRY "USERID.SOURCE.LISTING(ICCD0320)":>ICCD0320(long,long)
Debug Tool コマンド DESCRIBE CUS を使用して、必要な BLOCK または CU 修飾についての正しい情報を入手してください。
LIST NAMES コマンドを使用すれば、与えられた名前を持つ、同種で形式の異なる機能をすべて表示することができます。上の例では、LIST NAMES "ICCD0320*" と入力すると、ICCD0320 と呼ばれる、同種で形式の異なる機能がすべてリストされます。
現在実行中のコンパイル単位内にある変数には、まえがきを付ける必要は ありません。これらの変数は Debug Tool に既に知られています。すなわち、暗黙的に 修飾されています。
変数に対する修飾が効果を持つためには、各ブロックに名前が付いて いなければなりません。名前を付けていないブロックには、Debug Tool が %BLOCKnnn の形の名前を付けます。この 場合、nnn はプログラムの中での ブロックの相対位置に対応します。現行ブロックに付けられた Debug Tool の名前を見つけるには、DESCRIBE PROGRAMS コマンドを使用します。
ここで述べた内容に関して詳しくは、以下のトピックを参照してください。
視点は、通常は現在実行されているブロックです。アクセス不能なデータを入手するには、次のオペランドを指定して、SET QUALIFY コマンドを使用して視点を変えます。
load_name::>cu_name:>block_name
Debug Tool の 3 つの変数 %CU、%PROGRAM、%BLOCK のいずれかを更新するたびに、4 つの変数 (%CU、%PROGRAM、%LOAD、および %BLOCK) がすべて自動的に更新されて、新しい視点を反映するようになります。SET QUALIFY LOAD を使用して、%LOAD を変更した場合には、%LOAD だけが新しい視点に更新されます。その他の 3 つの Debug Tool 変数は変更されません。例えば、プログラムが現在、loadx::>cux:>blockx のところで中断されているとします。 また、コンパイル単位 cuz、およびブロック blockz を含むロード・モジュール loadz が、Debug Tool に認識されているものとします。現在有効な設定値は以下のとおりです。
次のコマンドのいずれかを入力したとします。
SET QUALIFY BLOCK blockz; SET QUALIFY BLOCK cuz:>blockz; SET QUALIFY BLOCK loadz::>cuz:>blockz;
有効な設定値は次のとおりです。
複数のエンクレーブがあるプログラムをデバッグする場合、SET QUALIFY コマンドを使用して、視点を新しいブロック、コンパイル単位、あるいはロード・モジュールにリセットし、どのエンクレーブの参照およびステートメント番号でも確認することができます。
アプリケーションの異常終了の直前でプログラム実行を中断するには、次のランタイム・オプションによってアプリケーションを始動してください。
TRAP(ON) TEST(ALL,*,NOPROMPT,*)
アプリケーションで条件が信号として出されると、Debug Tool からプロンプトが出されるので、その時に動的に 問題に対処することができます。 例えば、ポインターを初期設定したり、メモリーを割り振ったり、GOTO コマンドを使用してプログラムの論理の流れを変更したりすることができます。 また、GO BYPASS コマンドによって、発生した条件に対処済みであることを、言語環境プログラムの条件ハンドラーに知らせることも可能です。条件を発生させた命令に続くコードが、正しく保管されていない、あるいは 正しく処理されていないデータを使用している場合があるため 注意してください。
Debug Tool を使用してデバッグを行う場合、(ホスト・システムに よって) プログラムで発生した例外および条件をデバッガーに処理させる か、ユーザー・プログラムの例外ハンドラーにゆだねることができます。プログラムには、言語環境プログラム・サービスにアクセスして、例外と条件を処理させることができます。
ここで述べた内容に関して詳しくは、以下のトピックを参照してください。
デバッグ・セッション中には、2 つの方法のいずれかまたは両方により、HLL 条件が発生したときに Debug Tool に制御を渡すことができます。
デバッグ・セッションの開始時に ランタイム・オプションとして TEST(ALL) を指定すると、ほとんどの条件が発生した時に Debug Tool が制御を受け取ります。
また、AT OCCURRENCE コマンドでブレークポイントを定義し、Debug Tool に条件のオカレンスに対応させることも可能です。条件が発生すると、これらのブレークポイントによってプログラムの処理が停止され、Debug Tool が制御を受け取ります。そして、ブレークポイントを定義したときに指定したコマンドが、Debug Tool に よって処理されます。
条件の発生の仕方は幾通りかあり、それを処理する方法も 幾通りかあります。
Debug Tool セッション中には、以下の場合に条件が発生する可能性があります。
関連処置を指定してブレークポイントを定義してある場合に HLL 条件が発生すると、それらの処置が最初に実施されます。次にどのようなことが起こるかは、その処置の終わり方によって異なります。
何らかの定義済みブレークポイントの実行後に、GO によって制御が プログラムに戻されると、その条件は (発生可能であり、まだ適用可能で あれば) プログラム内で再び発生します。障害のあるステートメントをバイパスするために GOTO を使用すると、プログラムのエラー処理機能もバイパスされます。
ここで述べた内容に関して詳しくは、以下のトピックを参照してください。
Debug Tool の式の中でゼロによる除算などの例外が検出された場合、Debug Tool コマンド SET WARNING を 使用して、Debug Tool およびプログラムの応答を制御することができます。対話方式の Debug Tool セッションでは、そのような例外が入力ミスの結果 として発生する場合があり、プログラムに渡す意味がないことがあります。Debug Tool の式のエラーをプログラムに渡したくない場合は、SET WARNING ON を使用します。このようなエラーを含む式は打ち切られ、警告メッセージが表示されます。
ただし、エラー・リカバリー手順のテストなどでプログラムに例外を渡す場合 もあります。この場合、SET WARNING OFF を使用してください。
ここで述べた内容に関して詳しくは、以下のトピックを参照してください。
言語環境プログラムは、1 つのランタイム環境と言語間通信 (ILC) を提供する ことによって、複数言語アプリケーションのデバッグを簡単にします。
複数言語アプリケーションをデバッグする必要が生じたとき には、次のいずれかの状況になっています。
複数言語アプリケーションを書く場合、単一言語の場合には不必要で あった作業が必要となるため、いくつかの特別な考慮事項があります。言語環境プログラムの初期設定処理では、アプリケーション・プログラムのメイン・ロード・モジュール を構成している高水準言語のセットに合わせて調整された環境を確立します。これにより、環境を操作するために明示的な呼び出しを行う必要がなくなります。また、言語環境プログラムの環境を終了する場合も、アプリケーションに高水準言語がどのような 組み合わせで使用されているかに関係なく、整然とした方法で行われます。
ここで述べた内容に関して詳しくは、以下のトピックを参照してください。
言語環境プログラムによってサポートされる言語の組み合わせで作成され、サポートされる コンパイラーでコンパイルしたプログラムをデバッグする場合には、特別な処置は ほとんど必要ありません。Debug Tool は通常、プログラム言語の変更を認識し、ブレークポイント に達すると自動的に正しい言語に切り替わります。必要な場合には、SET PROGRAMMING LANGUAGE コマンドを使用し、指定した言語の ままにしておくことができます。ただし、この場合、現在設定されているプログラム 言語で定義された変数にしかアクセスすることはできません。
複数の異なる言語のコンパイル単位からアクセスしたいセッション変数を 定義する場合には、互換性のある属性でこれらを定義する必要があります。
ここで述べた内容に関して詳しくは、以下のトピックを参照してください。
ある言語で作業中にセッション変数を宣言し、別の言語のロード・モジュールを 呼び込んだ後でも、その使用を継続することが可能です。下記の 表は、セッション変数の属性がプログラム言語間でどのように関連付けされる かを示しています。このテーブルにない属性を持つセッション変数は、異なる プログラム言語からアクセスできません。(C、C++ または PL/I の セッション変数の場合にサポートされる一部の属性は異なる言語に 関連付けできません。これらの属性を使用して定義されたセッション変数 は、定義が行われた言語以外ではアクセスできません。ただし、COBOL セッション変数の場合にサポートされる属性 はすべて、C、C++ および PL/I でサポートされている同等の属性に 関連付けできるので、COBOL で宣言したセッション変数は すべて C、C++ および PL/I からアクセスできます。)
| マシン属性 | PL/I 属性 | C および C++ 属性 | COBOL 属性 | アセンブラーおよび逆アセンブリー属性 |
|---|---|---|---|---|
|
バイト |
CHAR(1) |
unsigned char |
PICTURE X |
DS X または DS C |
|
バイト・ストリング |
CHAR(j) |
unsigned char[j] |
PICTURE X(j) |
DS XLj または DS CLj |
|
ハーフワード |
FIXED BIN(15,0) |
signed short int |
PICTURE S9(j<=4) USAGE BINARY |
DS H |
|
フルワード |
FIXED BIN(31,0) |
signed long int |
PICTURE S9(4<j<=9) USAGE BINARY |
DS F |
|
浮動小数点 |
FLOAT BIN(21) または FLOAT DEC(6) |
float |
USAGE COMP-1 |
DS E |
|
長精度浮動小数点 |
FLOAT BIN(53) または FLOAT DEC(16) |
double |
USAGE COMP-2 |
DS D |
|
拡張浮動小数点 |
FLOAT BIN(109) または FLOAT DEC(33) |
long double |
なし |
DS L |
|
フルワード・ ポインター |
POINTER |
* |
USAGE POINTER |
DS A |
セッション変数を宣言するときは、C および C++ 変数が大文字小文字の 区別をすることに注意してください。現行のプログラム言語 が C および C++ の場合、大文字の名前で宣言したセッション変数のみ が COBOL または PL/I と共用できます。現行のプログラム言語 が COBOL または PL/I の場合、大文字と小文字が混合するかまたは 小文字のセッション変数は、大文字に変換されます。COBOL あるいは PL/I のセッション変数は、小文字と大文字を混合した宣言と参照が可能で あって、何も問題にはなりません。しかし、セッション変数を C および C++ と 共用する場合、C および C++ のプログラムの中では、大文字だけに なっていないと、参照できません (これは、同じ文字から構成される変数名 でも、1 つ以上の小文字が混合していると、C および C++ では異なる変数名とされるからです)。
互換性の無い属性をもつセッション変数をプログラム言語間で共用することは できませんし、そればかりでなく、同じ名前のセッション変数を削除 させることにもなります。例えば、COBOL では、PL/I の FLOAT DEC(33)、あるいは C の long double に相当するものはありません。現行のプログラム言語が COBOL のときに、セッション変数 X を PICTURE S9(4) と宣言すると、現行の プログラム言語の設定が PL/I になると FIXED BIN(15,0) の属性で、また現行のプログラム言語の設定が C になると signed short int の 属性で存在することになります。現行のプログラム言語の設定が PL/I に変更され、セッション変数 X が FLOAT DEC(33) と宣言される と、COBOL で宣言された X は存在しない結果になります。PL/I が宣言した変数 X は、現行プログラム言語の設定が C になると、long double の属性で存在を続けます。
ここで述べた内容に関して詳しくは、以下のトピックを参照してください。
異なるプログラム言語間で使用するコマンド・ファイルを作成したい場合は、コマンド・ファイルの作成に、コマンド・ファイルを正しく機能させるために従う必要がある、いくつかのガイドラインが説明されています。
複数のデバッガーが競合して、単一のリクエスターのみを対象とするストレージ、機能、 およびインターフェースを使用するような状況が発生する可能性があるため、 他のデバッガーとの共存は保証されません。
ここで述べた内容に関して詳しくは、以下のトピックを参照してください。
サポートされていない高水準言語または低水準言語、あるいは HLL の 古いリリースで作成したコンパイル単位またはプログラム・ユニットは許容されます。Debug Tool で使用できる、サポート対象外の 2 つの HLL については、「連携開発環境プログラム/370 リリース 2 VS COBOL II と OS PL/I による連携開発環境プログラム (CODE)/370 の使い方」を参照してください。
ここで述べた内容に関して詳しくは、以下のトピックを参照してください。