buildserver(1)


	BEA ホーム \| イベント \| ソリューション \| パートナ \| 製品 \| サービス \| ダウンロード \| ディベロッパ・センタ \| WebSUPPORT
	e-docs \| サイトマップ \| 検索 \| PDF版 \| お問い合わせ \| 用語集

Tuxedo ホーム \| BEA Tuxedo コマンド・リファレンス \| 先頭へ \| 前へ \| 次へ \| 目次

buildserver(1)

名前

buildserver-BEA Tuxedo ATMI システムのサーバのロード・モジュールを構築

形式

buildserver [-C] [-s { @filename | service[,service . . . ]
[:func]| :func } ] [-v] [-o outfile] [-f firstfiles] 
[-l lastfiles] [{-r|-g} rmname] [-k] [-t]

機能説明

buildserver は、BEA Tuxedo ATMI システムのサーバのロード・モジュールを構築するときに使用します。このコマンドは、オプション -f および -l で指定されたファイルを標準サーバのメイン・ルーチンおよび標準 BEA Tuxedo ATMI ライブラリと結合し、ロード・モジュールを作成します。このロード・モジュールは、buildserver が呼び出す cc(1) コマンドによって作成されます (UNIX システムのリファレンス・マニュアルの cc(1) を参照してください)。buildserver のオプションにはそれぞれ、次のような意味があります。

-v

buildserver を冗長モードで実行します。特に、cc コマンドをその標準出力に書き出します。

-o outfile

出力されるロード・モジュールを収めるファイル名を指定します。このファイル名を指定しない場合、ロード・モジュールの名前は SERVER になります。

-f firstfiles

buildserver のリンク段階で 1 つまたは複数のユーザ・ファイルを組み込み、その後で BEA Tuxedo ATMI ライブラリを組み込みます。複数のファイルを指定する場合は、各ファイル名を空白で区切り、ファイル名を列記した文字列全体を二重引用符で囲む必要があります。このオプションは何回指定してもかまいません。コンパイラ・オプションおよび引数を含むように指定する場合は、以下に説明する CFLAGS および ALTCFLAGS 環境変数を使用します。

-l lastfiles

BEA Tuxedo ATMI ライブラリを組み込んでから、buildserver のリンク段階で 1 つまたは複数のユーザ・ファイルを組み込みます。複数のファイルを指定する場合は、各ファイル名を空白で区切り、ファイル名を列記した文字列全体を引用符で囲む必要があります。このオプションは何回指定してもかまいません。

-r rmname

このサーバに対応するリソース・マネージャを指定します。rmname は、$TUXDIR/udataobj/RM にあるリソース・マネージャのテーブルにあるものでなければなりません。このファイルの各行は次のような形式になります。

rmname:rmstructure_name:library_names

(詳しくは buildtms(1) を参照してください)。rmname の値を使用することにより、$TUXDIR/udataobj/RM にあるエントリは、リソース・マネージャに関連したライブラリを自動的に含み、トランザクション・マネージャとリソース・マネージャ間のインターフェイスを正しく設定するのに使用されます。ほかの値は、リソース・マネージャのテーブルに追加されているものを指定できます。-r オプションの指定がない場合、デフォルトの設定としてヌル・リソース・マネージャが使用されます。UBBCONFIG(5) マニュアルを参照してください。

-s { @filename | service[,service...][:func] | :func } ]

サーバの起動時に宣言できるサービス名を指定します。サービス名および暗黙のファンクション名は 15 文字以下でなければなりません。明示的関数名 (コロンの後に指定する名前) は、128 文字まで使用できます。この文字数より長い名前が指定された場合は、警告メッセージが表示されて短縮されます。tmadmin(1) または TM_MIB(5) によりファイルを取得した場合は、名前の最初の 15 文字だけが表示されます (servopts(5) を参照してください)。サービスに関連付けることのできるすべての関数を、このオプションで指定する必要があります。一般的には、サービスは同じ名前をもつ関数によって実行されます。つまり、x サービスは関数 x によって実行されます。たとえば、次のように指定すると、サービス x、y、および z を提供するサーバが構築されます。これらのサービスはそれぞれ同じ名前の関数によって処理されます。

-s x,y,z

その他のケースでは、異なる名前の関数でサービスが実行されることもあります。次のように指定すると、サービス x、y、および z を提供するサーバが構築され、それらのサービスは関数 abc によって処理されます。

-s x,y,z:abc

カンマとカンマの間に空白を入れてはいけません。関数名の前にはコロンを付けます。別のケースでは、実行時までサービス名が分からないことがあります。関連するサービスを持つ可能性のあるすべての関数を、buildserver で指定しなければなりません。サービス名がマップされている可能性のある関数を指定するには、関数名の前にコロンを付けます。たとえば、次のように指定すると、サービスが関連付けられている可能性のある関数 pqr でサーバを構築します。tpadvertise(3c) は、関数 pqr にサービスをマップするために使用されます。

-s :pqr

サービスが関連付けられている可能性のある関数 pqr でサーバを構築します。tpadvertise(3c) は、関数 pqr にサービスをマップするために使用されます。

-s オプションでファイル名を指定するには、ファイル名の前に「@」文字を付けます。このファイルの各行は、-s オプションの引数と見なされます。このファイルには、コメントを入れることができます。コメント行の先頭には「#」文字を置きます。このファイルは、サービス名がマップされている可能性のある、サーバ中のすべての関数を指定するのに使用できます。

-s オプションは何回使用してもかまいません。「.」文字で始まるサービスはシステムで使用するように予約されているため、-s を指定してそのようなサービスをサーバに組み込もうとすると、buildserver は異常終了します。

-C

COBOL のコンパイルを指定します。

buildserver は通常、cc コマンドを使用して a.out を生成します。代わりのコンパイラを指定できるように、buildserver はシェル変数 CC が存在しているかどうかを調べます。CC が buildserver の環境にない場合、または変数の値がヌル文字列 "" である場合は、buildserver はコンパイラとして cc を使用します。環境内に CC が存在する場合、CC の値が実行されるコンパイラの名前となります。同様に、シェル変数 CFLAGS も、コンパイラへ渡す一連のパラメータを取り込むためにチェックされます。

-k

サーバの main スタブを保持します。buildserver は、サービス・テーブルなどのデータ構造と main() 関数を持つ main スタブを生成します。通常これは、サーバの構築時に、コンパイルの後で削除されます。このオプションは、ソース・ファイルを保持する必要があることを示します (ソース・ファイル名を表示するには、-v オプションを使用します)。

注記このファイルの生成内容は、リリースによって変更される場合があります。このファイルで公開されているデータ構造およびインターフェイスを重視しないでください。このオプションは、構築の問題のデバッグを支援するためのものです。

-t

マルチスレッド処理を指定します。サーバをマルチスレッド操作で使用する場合は、必ずこのオプションを指定してください。コンフィギュレーション・ファイルの MAXDISPATCHTRHREADS に 1 より大きな値が設定されている場合に、このオプションを指定せずにサーバを起動しようとすると、ユーザ・ログに警告メッセージが出力され、サーバはシングルスレッド操作に戻ります。

このオプションは、管理者がスレッド・セーフな方法でプログラミングされていないサーバをマルチスレッド・サーバとして起動するのを防止するために使用されます。

環境変数

TUXDIR

buildserver は、環境変数 TUXDIR を使用して、サーバ・プロセスのコンパイル時に使用する BEA Tuxedo ATMI ライブラリとインクルード・ファイルを見つけます。

buildserver は通常、デフォルトの C 言語コンパイル・コマンドを使用してサーバ実行可能コードを生成します。デフォルトの C 言語コンパイル・コマンドは、サポートされている各オペレーティング・システムごとに定義されており、UNIX システムの場合は cc(1) です。代替コンパイラを指定できるようにするため、buildserver は環境変数 CC が存在するかどうかを調べます。CC が buildserver の環境に存在しない場合、あるいは環境変数が文字列 "" である場合は、buildserver はデフォルトの C 言語コンパイラを使用します。CC が環境に存在すれば、実行するコンパイラの名前としてその値が使用されます。

CFLAGS

環境変数 CFLAGS は、コンパイラ・コマンド行の一部として引き渡される一群の引数を指定するときに使用します。これは、buildserver に自動的に渡されるコマンド行オプション "-I${TUXDIR}/include" に追加されます。CFLAGS が buildserver の環境に存在しない場合、あるいはこれが文字列 "" である場合には、buildserver はコンパイラ・コマンド行の引数を何も追加しません。

ALTCC

-C オプションを使って COBOL のコンパイルを指定すると、buildserver は通常、BEA Tuxedo のシェル cobcc() を使用します。すると、cobcc は cob を呼び出し、クライアント実行可能コードを生成します。 buildserver は、別のコンパイラを指定する ALTCC という環境変数の有無をチェックします。ALTCC が buildserver 環境に存在しないか、文字列 " " である場合は、buildserver は cobcc を使用します。環境に ALTCC が存在する場合は、その値をとって実行するコンパイラ・コマンドとします。

注記 Windows システムでは、環境変数 ALTCC と ALTCFLAGS は使用できません。これらの変数を設定すると、予想外の結果が生じます。まず COBOL コンパイラを使用してアプリケーションをコンパイルして、次に生成されたオブジェクト・ファイルを buildserver(1) コマンドに渡す必要があります。

ALTCFLAGS

環境変数 ALTCFLAGS には、-C オプションを指定した場合に、COBOL コンパイラ・コマンドの一部として渡す追加の引数を指定します。これは、buildserver に自動的に渡されるコマンド行オプション "-I${TUXDIR}/include" に追加されます。-C オプションを使用する場合、コンパイラ・オプションやその引数を buildserver -fオプションで指定すると、エラーが発生するので、ALTCFLAGS を使用する必要があります。設定しなかった場合は、上記の CFLAGS と同じ値に設定されます。

注記 ALTCC 環境変数の下の注意を参照してください。

COBOPT

環境変数 COBOPT には、-C オプションを指定した場合に、COBOL コンパイラが使用する追加の引数を指定します。

COBCPY

環境変数 COBCPY には、-C オプションを指定した場合に、COBOL コンパイラが使用する COBOL コピー・ファイルが存在するディレクトリを指定します。

LD_LIBRARY_PATH (Unix システムの場合)

環境変数 LD_LIBRARY_PATH には、BEA Tuxedo システムの共有オブジェクトに加えて、COBOL コンパイラが使用する共有オブジェクトが存在するディレクトリを指定します。一部の Unix システムでは、別の環境変数が必要となる場合もあります。HP-UX システムでは SHLIB_PATH 環境変数を使用します。AIX システムでは LIBPATH 環境変数を使用します。

LIB (Windows NT システムの場合)

ライブラリを検索するディレクトリのリストを指定します。それぞれのディレクトリはセミコロン (;) で区切ります。

互換性

以前のリリースでは、sql つまり database の genoption を指定するために -g オプションを使用できました。上位互換性を保持するため、このオプションは -r オプションの同義語になっています。

移植性

buildserver コンパイル・ツールは、BEA Tuxedo ATMI サーバ環境がサポートされるプラットフォームで使用できます。RM XA ライブラリは、Windows プラットフォームではサポートされていません。

注意事項

コンパイル・システムによっては、main() へのコードの追加が必要になる場合があります。たとえば、C++ でコンストラクタを初期化したり、COBOL 用のライブラリを初期化するような場合です。サーバの main() のすべての変数宣言の直後で、すべての実行文の前に、アプリケーションのコードをインクルードするための一般的な機構が用意されています。これによって、アプリケーションは変数の宣言と文の実行を 1 ブロックのコードで行うことができます。アプリケーション exit は、次のように定義できます。#ifdef TMMAINEXIT #include "mainexit.h" #endif
この機能を使用するためには、環境変数 ALTCFLAGS (COBOL の場合) または CFLAGS (C の場合) に "-DTMMAINEXIT" を指定し、カレント・ディレクトリに mainexit.h を置く (または -I インクルード・オプションを使用してほかのディレクトリからインクルードする) 必要があります。

たとえば、Micro Focus Cobol V3.2.x で PRN 番号の最後の数字が 11.03 より大きい場合、共有ライブラリの使用時には、main() のすべての COBOL ルーチンの前で (おそらく関数プロトタイプ宣言の後で) cobinit() を呼び出す必要があります。これを行うには、cobinit() の呼び出しが入った mainexit.h を作成し、上記の手順に従ってください。

使用例

次の例は、リソース・マネージャ (-r TUXEDO/SQL) ライブラリを buildserver コマンド行で指定する方法を示しています。

buildserver -r TUXEDO/SQL -s OPEN_ACCT -s CLOSE_ACCT  -o ACCT 
-f ACCT.o -f appinit.o -f util.o

次の例は、buildserver に変数 CC および CFLAGS 変数を与える方法、および -f を使用して CC 行への -lm オプションを指定して数学ライブラリをリンクする方法を示したものです。

CFLAGS=-g CC=/bin/cc  buildserver -r TUXEDO/SQL -s DEPOSIT 
-s WITHDRAWAL -s INQUIRY  -o TLR -f TLR.o -f util.o -f -lm

次の例は、リソース・マネージャを指定せずに buildserver コマンドを使用する方法です。

buildserver -s PRINTER -o PRINTER -f PRINTER.o

次の例は、COBOL のコンパイルです。

COBCPY=$TUXDIR/cobinclude COBOPT="-C ANS85 -C ALIGN=8 -C NOIBMCOMP
-C TRUNC=ANSI -C OSEXT=cbl" COBDIR=/usr/lib/cobol
LD_LIBRARY_PATH=$COBDIR/coblib export COBOPT COBCPY COBDIR
LD_LIBRARY_PATH buildserver -C -r TUXEDO/SQL -s OPEN_ACCT 
-s CLOSE_ACCT  -o ACCT -f ACCT.o -f appinit.o -f util.o