アプリケーション構築の手引き

ビルド・ファイル、makefile、およびエラー検査ユーティリティー

DB2 には、プログラム開発における必要に応えるための一群の構築ツールが用意されています。 これらのツールを利用することにより、 DB2 の幅広い機能性を示している、提供されたサンプル・プログラムを簡単に構築することができます。 また、これらのツールを使って独自のデータベース・プログラムを構築することも可能です。 DB2 には、サポートしているコンパイラーごとにビルド・ファイル、makefile、 エラー検査ユーティリティーなどが用意されています。 これらのものはサンプル・プログラムとともにサンプル・ディレクトリーにあります。 この節では、これらのツールの使い方を説明します。

ビルド・ファイル

以下の各章で使われているファイルには、 サポートしているプラットフォームのコンパイラーでプログラムを構築するための compile および link コマンドが含まれています。 これらのファイルは、OS/2 ではコマンド・ファイル、 UNIX ではスクリプト・ファイル、 Windows 32 ビット・オペレーティング・システムではバッチ・ファイルと呼ばれています。 本書では、これらのファイルを総称してビルド・ファイルと呼ぶことにします。

DB2 では、ビルド・ファイルが、 各言語のサンプル・プログラムと同じディレクトリーの中で、 構築されるプログラムを使用できるプラットフォームの各言語ごとに用意されています。 表 16 では、 Windows 32 ビット・オペレーティング・システムを除く、 サポートされているすべてのプラットフォーム上のすべての言語のビルド・ファイルをリストします。 ファイル名の拡張子は、省略されています。 OS/2 の場合、拡張子は .cmd で、 Windows 32 ビット・オペレーティング・システムの場合、拡張子は .bat です。 UNIX プラットフォームの場合には、拡張子はありません。

Windows 32 ビット・オペレーティング・システムの場合、 サポートされている 2 つの C++ コンパイラー (Microsoft Visual C++ および IBM VisualAge C++) があります。 これらのコンパイラーの場合、bldclisp を除き、それぞれ、 "m" または "v" が各ビルド・ファイル名の "bld" の後に挿入されており、 bldmclis または bldvclis のいずれかになります。 これらのビルド・ファイルは、表 17にリストされています。 .bat という拡張子は省略されています。


表 16. DB2 ビルド・ファイル
ビルド・ファイル 構築されるプログラムのタイプ
bldsqlj Java Embedded SQLJ アプリケーション。
bldsqljs Java Embedded SQLJ ストアード・プロシージャー。
bldcli DB2 CLI アプリケーション (組み込み SQL を含むものと含まないもの)。
bldapi DB2 CLI アプリケーション (組み込み SQL を含むものと含まないもの)。 データベースを作成および除去するための DB2 API を含む、 utilapi ユーティリティー・ファイル内のリンクが必要です。
bldclisp DB2 CLI ストアード・プロシージャー (組み込み SQL なし)。
bldapp アプリケーション・プログラム (組み込み SQL を含むものと含まないもの)。
bldsrv 組み込み SQL ストアード・プロシージャー。
bldudf ユーザー定義関数 (UDF)。
bldmt マルチスレッド組み込み SQL アプリケーション (サポートされている UNIX プラットフォーム上の C/C++ にのみ使用可能)。
bldevm イベント・モニター・サンプル・プログラム evm (AIX および OS/2 上でのみ使用可能)。


表 17. C/C++ ビルド・ファイル (Windows 32 ビット・オペレーティング・システム用)
ビルド・ファイル 構築されるプログラムのタイプ
bldmcli Microsoft Visual C++ DB2 CLI アプリケーション (組み込み SQL を含むものと含まないもの)。
bldvcli VisualAge C++ DB2 CLI アプリケーション (組み込み SQL を含むものと含まないもの)。
bldmapi Microsoft Visual C++ DB2 CLI アプリケーション (組み込み SQL を含むものと含まないもの)。 データベースを作成および除去するための DB2 API を含む、 utilapi ユーティリティー・ファイル内のリンクが必要です。
bldvapi VisualAge C++ DB2 CLI アプリケーション (組み込み SQL を含むものと含まないもの)。 データベースを作成および除去するための DB2 API を含む、 utilapi ユーティリティー・ファイル内のリンクが必要です。
bldmclis Microsoft Visual C++ DB2 CLI ストアード・プロシージャー (組み込み SQL なし)。
bldvclis VisualAge C++ DB2 CLI ストアード・プロシージャー (組み込み SQL なし)。
bldmapp Microsoft Visual C++ アプリケーション・プログラム (組み込み SQL を含むものと含まないもの)。
bldvapp VisualAge C++ アプリケーション・プログラム (組み込み SQL を含むものと含まないもの)。
bldmsrv Microsoft Visual C++ 組み込み SQL ストアード・プロシージャー。
bldvsrv VisualAge C++ 組み込み SQL ストアード・プロシージャー。
bldmudf Microsoft Visual C++ ユーザー定義関数 (UDF)。
bldvudf VisualAge C++ ユーザー定義関数 (UDF)。

本書にはビルド・ファイルが記載されていますが、それはこれらのファイルに、 サポートしているコンパイラーで各種のプログラムを構築するときに推奨される DB2 のコンパイルおよびリンクのオプションの使い方が非常に分かりやすく示されているからです。 通常はこれらの他にも使用できるコンパイルとリンクのオプションは多数あり、 ユーザーはそれらを自由に試すことができます。 用意されているコンパイルとリンクのすべてのオプションについて知りたい場合は、 ご使用のコンパイラーのマニュアルを参照してください。 開発者はそれらのビルド・ファイルを使ってサンプル・プログラムを構築するだけでなく、 自分のプログラムを構築することも可能です。 サンプル・プログラムをユーザーが変更できるテンプレートとして利用することにより、 プログラム開発に役立てることができます。

これらのビルド・ファイルの便利な点として、 コンパイラーで使用可能なファイル名が付いていれば、 どのソース・ファイルでも構築するように設計されています。 これは、プログラム名がファイル中にハードコーディングされる makefile とは異なります。 ビルド・ファイルでは、UNIX の場合には $1 変数、 また OS/2 や Windows 32 ビット・オペレーティング・システムの場合には %1 変数を使って、 プログラム名を内部的に置き換えます。 同様にして名前が付けられた他の変数は、 必要とされる他の引き数を置き換えます。 各ビルド・ファイルは特定のプログラム構築、たとえば DB2 API、 DB2 CLI、組み込み SQL、ストアード・プロシージャー、 ユーザー定義関数など、それぞれに適したものになっているため、 ビルド・ファイルは短時間で、かつ簡単に試してみることが可能です。 それぞれのタイプのビルド・ファイルは、 そのビルド・ファイルが想定している特定の種類のプログラムをコンパイラーがサポートしている場合に用意されています。

ビルド・ファイルが作成するオブジェクト・ファイルや実行可能ファイルは、 ソース・ファイルが修正されない場合でさえ、プログラムが構築されるたびに自動的に上書きされます。 これは makefile の場合とは異なっています。 つまり、開発者は以前のオブジェクト・ファイルや実行可能ファイルを削除したり、 またはソースを修正したりすることなく、 既存のプログラムを再構築することができます。

ビルド・ファイルには、サンプル・データベース用のデフォルト設定が組み込まれています。 ユーザーが別のデータベースにアクセスする場合は、 別のパラメーターを指定してデフォルトの指定を変更するだけで済みます。 その別のデータベースを一貫して使用する予定であれば、 ビルド・ファイルの中にある sample を置き換えて、 このデータベースの名前をハードコーディングすることができます。

組み込み SQL プログラムに使用されるビルド・ファイルは別のファイル embprep を呼び出し、 これらの組み込み SQL プログラムが使用するプリコンパイルとバインドのステップがその中に入っています。 これらのステップでは、 組み込み SQL プログラムをどこに組み込むかによって、 任意指定のパラメーターであるユーザー ID とパスワードが必要になる場合があります。

データベースがあるサーバー・インスタンス上で開発者がプログラムを構築する場合はユーザー ID とパスワードが共通であるため、 ビルド・ファイルに入力パラメーターとして指定する必要がないからです。 その一方で、開発者が別のインスタンスで作業する場合、 たとえばサーバー・データベースへリモート・アクセスするクライアント・マシン上で作業する場合などは、 ビルド・ファイルを実行するときにこれらのパラメーターを指定しておくことが必要です。 embprep ファイルは、makefile によっても使用されます。 このファイルの詳細については、makefileを参照してください。

最後の点として、ビルド・ファイルは開発者が自分の都合に合わせて修正することが可能です。 開発者は (前述のように) ビルド・ファイル中のデータベース名を変更できるだけでなく、 他のパラメーターをファイル内にハードコーディングしたり、 コンパイルとリンクのオプションを変更したり、 デフォルトの DB2 インスタンス・パスを変更したりすることが簡単に行えます。 ビルド・ファイルはその性質上、簡単で分かりやすく、具体的であるため、 自分の必要に応じてそれらのファイルに手を加えるのが容易です。

makefile

サポートしているコンパイラーごとに用意されているサンプル・ディレクトリーの中には、 提供されているサンプル・プログラムを構築するための makefile が入っています。 makefile は、コンパイラーに付属している大部分の DB2 サンプル・プログラムを構築します。 また、サンプル・プログラムのコンパイルごとに使われる共通要素の多くに対して変数を利用します。 makefile の構文、およびそれらのコマンドからの出力は、 提供されているビルド・ファイルのものとはいくつかの重要な点で異なっています。 以下に示すように、make コマンドの使用は簡単でありながら強力です。

make <program_name>
指定したプログラムのコンパイルとリンクを実行します。

make all
makefile に記述されているすべてのプログラムのコンパイルとリンクを実行します。

make clean
makefile に記述されているすべてのプログラムの中間ファイル (オブジェクト・ファイルなど) を削除します。

make cleanall
makefile に記述されているすべてのプログラムの中間ファイルと実行可能ファイルをすべて削除します。

ビルド・ファイルとは異なり、 makefile はその中に記述されているプログラムの既存の中間ファイルと実行可能ファイルを上書きしません。 make all コマンドを使用した場合、 他のファイルに実行可能ファイルがすでにあると make all はそれらのファイルを単に無視するだけなので、 いくつかのファイルの実行可能ファイルを作成するのであれば makefile による処理の方が高速です。 ただし、既存のオブジェクト・ファイルと実行可能ファイルが不要な場合には、 make clean および make cleanall コマンドを使ってそれらのファイルを除去しなければなりません。

makefile はプログラム開発に使用することができます。 ビルド・ファイルに比べると使い勝手が良くありませんが、 make コマンドの持つ強力な機能と利便性を利用したい場合には一考の価値があります。 新しいプログラムを既存の makefile に組み込むには、 既存のサンプル・プログラムで似ているものをテンプレートとして利用し、 構文に従ってプログラム項目をコーディングします。 構文はストアード・プロシージャーと UDF の場合と同様に、 DB2 API、DB2 CLI、組み込み SQL の各プログラムで異なる点に注意してください。

ここでは、提供されている makefile の使用例を示します。 使用する makefile は AIX の samples/cli ディレクトリーにあるもので、 これは AIX で提供されているすべての DB2 CLI サンプルを IBM C コンパイラーで構築します。 この例ではストアード・プロシージャー spserver を構築し、 クライアント・アプリケーションが呼び出すことのできる共用ライブラリー spclient にする方法を示しています。

makefile を使用する前に、 このファイル中の以下の変数を編集しなければならない場合があります。

DB
使用しているデータベース。 デフォルトでは sample に設定されています。

UID
使用しているユーザー ID。 デフォルトでは値が設定されていません。

PWD
UID ユーザー ID のパスワード。 デフォルトでは値が設定されていません。

AIX の場合、DB2 CLI の makefile には 変数 DB2PATHCCCOPYERASECFLAGS、および LIBS が以下のように定義されています。

   # Set DB2PATH to where DB2 will be accessed. 
   # The default is the instance path. 
   DB2PATH=$(HOME)/sqllib
   CC = cc
   COPY = cp
   ERASE = rm -f
   # The required compiler flags
   CFLAGS= -I$(DB2PATH)/include
   # The required libraries 
   LIBS= -L$(DB2PATH)/lib -Wl,-rpath,$(DB2PATH)/lib -ldb2

makefile はこれらの変数をストアード・プロシージャー spserver をコンパイルするときに使用し、 共用ライブラリーを function サブディレクトリーにコピーします。

spserver : utilcli.o
        $(CC) -o spserver spserver.c utilcli.o $(CFLAGS) $(LIBS) \
        -H512 -T512 -bE:spserver.exp -e outlanguage
        $(ERASE) $(DB2PATH)/function/spserver
        $(COPY) spserver $(DB2PATH)/function/spserver

組み込み SQL プログラムの場合、 makefile は embprep ファイルを呼び出し、 これらの組み込み SQL プログラムが使用するプリコンパイルとバインドのステップがその中に入っています。 これを組み込み SQL プログラムごとに呼び出される別個のファイルにすることにより、 makefile そのものの本文中でこれらのステップが繰り返し出現すことを避けられます。 このファイルには、サーバー上のデータベースへ接続するためのユーザー ID、 パスワード、データベース名を指定しなければなりません。 makefile は呼び出しの際に、 これらの値を embprep に渡します。

データベース変数 DB はデフォルトで sample データベースにハードコーディングされており、 別のデータベースを使用する場合、ユーザーはこれを変更することが可能です。 ユーザー ID 変数とパスワード変数、UID および PWD には、 デフォルトでは値が設定されていません。 これらの任意指定のパラメーターは、 ユーザーがすでにサーバー・データベースと同じインスタンスで作業している場合には使用する必要がありません。 それ以外の場合、 たとえばユーザーがクライアント・マシンからサーバーにリモート接続している場合などは、 makefile を変更して UID 変数と PWD 変数に適切な値を指定すると、 それらの値が embprep プリコンパイルおよびバインドのファイルに自動的に渡されるようになります。 以下に示してあるのは embprep ファイルの例で、 Windows NT 上の Micro Focus COBOL makefile がこれを呼び出して、 組み込み SQL アプリケーション updat を構築します。

updat.cbl : updat.sqb
        embprep updat $(DB) $(UID) $(PWD)
updat.obj : updat.cbl 
        $(CC) updat.cbl;
updat : updat.obj checkerr.obj
        $(LINK) updat.obj checkerr.obj $(LIBS)

エラー検査ユーティリティー

DB2 AD クライアントは、いくつかのユーティリティー・ファイルを提供します。 これらのファイルには、 エラー検査とエラー情報の印刷出力を行う関数があります。 例外は、CLI ユーティリティー・ファイル utilapi.c で、 DB2 API を呼び出して、データベースを除去します。 ユーティリティー・ファイルは、 サンプル・ディレクトリーの中に、言語ごとに別々のバージョンが用意されています。 このユーティリティーはアプリケーション・プログラムで使用するときに有用なエラー情報を提供し、 DB2 プログラムのデバッグの労力を大幅に軽減します。 エラー検査ユーティリティーのほとんどは、 プログラム実行中に検出した問題に直接関連した SQLSTATE および SQLCA 情報を取得するのに、 DB2 API GET SQLSTATE MESSAGE および GETERROR MESSAGE を使います。 DB2 CLI ユーティリティーである utilcli は、 これらの DB2 API を使用する代わりにそれらと同じ働きをする DB2 CLI ステートメントを使用します。 どのエラー検査ユーティリティーを使用した場合でも詳細なエラー・メッセージが印刷出力されるため、 開発者は短時間で問題を把握することができます。

ストアード・プロシージャーやユーザー定義関数など、 DB2 プログラムによっては DB2 関連の問題でもこれらのユーティリティーを使用する必要はありません。 これは、例外が発生すると SQLException オブジェクトが破棄されるので不要です。

以下に示すのは、DB2 がサポートしているコンパイラーが使用する、 プログラム言語別のエラー検査ユーティリティー・ファイルです。

checkerr.cbl
COBOL プログラム用

utilcli.c
CLI プログラム用

utilapi.c
C 組み込み SQL を含まないプログラム用

utilemb.sqc
C 組み込み SQL プログラム用

utilapi.C
C++ 組み込み SQL を含まないプログラム用

utilemb.sqC
C++ 組み込み SQL プログラム用

ユーティリティー関数を使用するには、 まず最初にユーティリティー・ファイルをコンパイルした後、 ターゲット・プログラムの実行可能ファイルの作成中にそのオブジェクト・ファイルをリンクしなければなりません。 samples ディレクトリー中の makefile とビルド・ファイルは両方とも、 エラー検査ユーティリティーを必要とするプログラムで使用することによってこの処理を行います。

以下の例は、エラー検査ユーティリティーを DB2 プログラム中でどのように使用するかを示しています。 utilemb.h ヘッダー・ファイルは、 関数 SqlInfoPrint() および TransRollback() の代わりに使用される EMB_SQL_CHECK マクロを定義します。

#define EMB_SQL_CHECK( MSG_STR )           \
   if( SqlInfoPrint( MSG_STR, &sqlca, __LINE__, __FILE__)  != 0 ) TransRollback( );

SqlInfoPrint() は SQLCODE フラグを検査します。 この関数は、 このフラグが示している特定のエラーに関連した、 入手可能なすべての情報を印刷します。 また、この関数は、 ソース・コード内のどこでエラーが発生したかを示します。 TransRollback() により、 エラーが発生した場所にユーティリティー・ファイルがトランザクションを安全にロールバックできるようになります。 データベースに接続し、 ロールバックを実行するための組み込み SQL ステートメントが必要です。 以下に、 C++ プログラム cursor が、 マクロを使用し、SqlInfoPrint() 関数の MSG_STR パラメーターに値 "DECLARE CURSOR" を提供することによって、 ユーティリティー関数を呼び出す方法の例を示します。

Cursor::Fetch () {
   EXEC SQL DECLARE c1 CURSOR FOR 
            SELECT name, dept FROM staff WHERE job='Mgr'
            FOR UPDATE OF job;
   EMB_SQL_CHECK("DECLARE CURSOR") ;

EMB_SQL_CHECK マクロは、 DECLARE ステートメントが失敗すると、 トランザクションが安全にロールバックし、 該当するエラー・メッセージが確実に印刷されるようにします。

開発者の方々には DB2 プログラムの作成時に、 これらのエラー検査ユーティリティーを使って構築することをお勧めします。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]