buildserver-construct a BEA TUXEDO server load module
buildserver[-C][-s{ @filename | service[,service...][:func] | :func } ] [-nmaxdynam] [-v] [-ooutfile] [-ffirstfiles]
[-llastfiles] [{-r|-g} rmname] [-k]
buildserver is used to construct a BEA TUXEDO server load module. The command combines the files supplied by the -f and -l options with the standard server main routine and the standard BEA TUXEDO libraries to form a load module. The load module is built by the cc(1) command, which buildserver invokes. (See cc(1) in any UNIX System reference manual.) The options to buildserver have the following meaning:
-v
buildserver should work in verbose mode. In particular, it writes the compilation command to its standard output.
-o outfile
SERVER.
-n maxdynam
-n is not specified, the maximum number of such services is set to 25.
-ffirstfiles
buildserver first, before the BEA TUXEDO libraries. If more than one file is specified, file names must be separated by white space and the entire list must be enclosed in quotation marks. This option may be specified multiple times. The CFLAGS and ALTCFLAGS environment variables, described below, should be used to include any compiler options and their arguments.
-llastfiles
buildserver last, after the BEA TUXEDO libraries. If more than one file is specified, file names must be separated by white space and the entire list must be enclosed in quotation marks. This option may be specified multiple times.
-r rmname
rmname must appear in the resource manager table located in $TUXDIR/udataobj/RM. Each line in this file is of the form:
rmname:rmstructure_name:library_names
(See buildtms(1) for further details.) Using the rmname value, the entry in $TUXDIR/udataobj/RM is used to include the associated libraries for the resource manager automatically and to set up the interface between the transaction manager and resource manager properly. The value TUXEDO/D includes the libraries for the BEA TUXEDO System/D resource manager. The value TUXEDO/SQL includes the libraries for the BEA TUXEDO System/SQL resource manager. Other values can be specified as they are added to the resource manager table. If the -r option is not specified, the default is to use the null resource manager. Refer to the ubbconfig(5) reference page.
-s { @filename | service[,service...][:func] | :func } ]
tmadmin(1) or TM_MIB(5), only the first 15 characters of a name are displayed. (See servopts(5).) All functions that can be associated with a service must be specified with this option. In the most common case, a service is performed by a function that carries the same name; that is, the x service is performed by function x. For example, the specification
-s x,y,z
will build the associated server with services x, y, and z, each to be processed by a function of the same name. In other cases, a service (or several services) may be performed by a function of a different name. The specification
-s x,y,z:abc
builds the associated server with services x, y, and z, each to be processed by the function abc. Spaces are not allowed between commas. Function name is preceded by a colon. In another case, the service name may not be known until runtime. Any function that can have a service associated with it must be specified to buildserver. To specify a function that can have a service name mapped to it, put a colon in front of the function name. For example, the specification
-s :pqr
builds the server with a function pqr, which can have a service association. tpadvertise(3c) could be used to map a service name to the pqr function.
A filename can be specified with the -s option by prefacing the filename with the '@' character. Each line of this file is treated as an argument to the -s option. You may put comments in this file. All comments must start with the '#' character. This file can be used to specify all the functions in the server that may have services mapped to them.
The -s option may appear several times. Note that services beginning with the `_' or '.' character are reserved for system use, and buildserver will fail if the -s option is used to include such a service in the server.
-C
buildserver normally uses the cc command to produce the a.out. In order to allow for the specification of an alternate compiler, buildserver checks for the existence of a shell variable named CC. If CC does not exist in buildserver's environment, or if it is the string "", buildserver will use cc as the compiler. If CC does exist in the environment, its value is taken to be the name of the compiler to be executed. Likewise, the shell variable CFLAGS is taken to contain a set of parameters to be passed to the compiler.
-k
buildserver generates a main stub with data structures such as the service table and a main() function. This is normally compiled and then removed when the server is built. This option indicates that the source file should be kept (to see what the source file name is, use the -v option).
Note: The generated contents of this file may change from release to release; DO NOT count on the data structures and interfaces exposed in this file. This option is provided to aid in debugging of build problems.
TUXDIR
buildserver uses the environment variable TUXDIR to find the BEA TUXEDO libraries and include files to use during compilation of the server process.
buildserver normally uses the default C language compilation command to produce the server executable. The default C language compilation command is defined for each supported operating system platform and is defined as cc(1) for the UNIX System. In order to allow for the specification of an alternate compiler, buildserver checks for the existence of an environment variable named CC. If CC does not exist in buildserver's environment, or if it is the string "", buildserver will use the default C language compiler. If CC does exist in the environment, its value is taken to be the name of the compiler to be used.
CFLAGS
CFLAGS is taken to contain a set of arguments to be passed as part of the compiler command line. This is in addition to the command line option "-I${TUXDIR}/include" passed automatically by buildserver. If CFLAGS does not exist in buildserver's environment, or if it is the string "", no compiler command line arguments are added by buildserver.
ALTCC
-C option is specified for COBOL compilation, buildserver normally uses the BEA TUXEDO shell cobcc(1) which in turn calls cob to produce the server executable. In order to allow for the specification of an alternate compiler, buildserver checks for the existence of an environment variable named ALTCC. If ALTCC does not exist in buildserver's environment, or if it is the string "", buildserver will use cobcc. If ALTCC does exist in the environment, its value is taken to be the name of the compiler command to be executed.
ALTCFLAGS
ALTCFLAGS is taken to contain a set of additional arguments to be passed as part of the COBOL compiler command line when the -C option is specified. This is in addition to the command line option "-I${TUXDIR}/include" passed automatically by buildserver. When the -C option is used, putting compiler options and their arguments in the buildserver -f option will generate errors; they must be put in ALTCFLAGS. If not set, then the value is set to the same value used for CFLAGS, as specified above.
COBOPT
COBOPT is taken to contain a set of additional arguments to be used by the COBOL compiler, when the -C option is specified.
COBCPY
COBCPY indicates which directories contain a set of COBOL copy files to be used by the COBOL compiler, when the -C option is specified.
LD_LIBRARY_PATH
LD_LIBRARY_PATH indicates which directories contain shared objects to be used by the COBOL compiler, in addition to the BEA TUXEDO shared objects.
In earlier releases, the -g option was allowed to specify a genoption of sql or database. For upward compatibility, this option is a synonym for the -r option. The genoption database is equivalent to TUXEDO/D, and the genoption sql is equivalent to TUXEDO/SQL.
buildserver is supported as a BEA TUXEDO-supplied compilation tool on UNIX Systems only.
Some compilation systems may require some code to be executed within the main(). For example, this could be used to initialize constructors in C++ or initialize the library for COBOL. A general mechanism is available for including application code in the server main() immediately after any variable declarations and before any executable statements. This will allow for the application to declare variables and execute statements in one block of code. The application exit is defined as follows. #ifdef TMMAINEXIT #include "mainexit.h" #endif. To use this feature, the application should include "-DTMMAINEXIT" in the ALTCFLAGS (for COBOL) or CFLAGS (for C) environment variables and provide a mainexit.h in the current directory (or use the -I include option to include it from another directory).
For example, Micro Focus Cobol V3.2.x with a PRN number with the last digits greater than 11.03 requires that cobinit() be called in main before any COBOL routines, if using shared libraries. This can be accomplished by creating a mainexit.h file with a call to cobinit() (possibly preceded by a function prototype) and following the procedure above.
The following example shows how to specify the resource manager (-r TUXEDO/SQL) libraries on the buildserver command line:
buildserver -r TUXEDO/SQL -s OPEN_ACCT -s CLOSE_ACCT -o ACCT
-f ACCT.o -f appinit.o -f util.o
The following example shows how buildserver can be supplied CC and CFLAGS variables and how -f can be used to supply a -lm option to the CC line to link in the math library:
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
The following example shows use of the buildserver command with no resource manager specified:
buildserver -s PRINTER -o PRINTER -f PRINTER.o
The following example shows COBOL compilation:
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), ubbconfig(5), servopts(5) cc(1), ld(1) in a UNIX System reference manual