bea ホーム | 製品 | dev2dev | support | askBEA
BEA Logo Tuxedo
 ドキュメントのダウンロード   サイトマップ   用語集 
検索
0

Tuxedo コマンド・リファレンス

 Previous Next Contents View as PDF  

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

buildserver のコンパイルおよびリンク段階で最後に取り込む 1 つ以上のファイルを指定します。指定されたファイルは、BEA Tuxedo ATMI ライブラリが取り込まれた後で取り込まれます。複数のファイルを指定する場合は、各ファイル名を空白で区切り、リスト全体を引用符で囲まれなければなりません。このオプションは何回指定してもかまいません。

-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 によって実行されます。たとえば、次のように指定すると、サービス xy、および z を提供するサーバが構築されます。これらのサービスはそれぞれ同じ名前の関数によって処理されます。

-s x,y,z

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

-s x,y,z:abc

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

-s :pqr

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

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

-C

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

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

-k

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

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

-t

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

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

環境変数

TUXDIR

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

CC

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

CFLAGS

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

ALTCC

-C オプションを使って COBOL のコンパイルを指定すると、buildserver は通常、BEA Tuxedo のシェル cobcc(1) を使用します。すると、cobcc は cob を呼び出し、クライアント実行可能コードを生成します。buildserver は、別のコンパイラを指定する ALTCC という環境変数の有無をチェックします。ALTCCbuildserver の環境に存在しない場合、または文字列 "" である場合、buildservercobcc を使用します。環境に 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 すなわち databasegenoption を指定するのに -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

関連項目

buildtms(1)servopts(5)UBBCONFIG(5)

お使いのオペレーティング・システムのリファレンス・マニュアルで説明する C コンパイラとリンカに関する記述

 

Back to Top Previous Next
Contact e-docsContact BEAwebmasterprivacy