Tuxedo
0
e-docs > Tuxedo > Command Reference > Section 1 - Commands

Command Reference

 Previous Next Contents View as PDF  

buildserver(1)

Name

buildserver—Constructs a BEA Tuxedo ATMI server load module.

Synopsis

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

Description

buildserver is used to construct a BEA Tuxedo ATMI 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 ATMI 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

Specifies that buildserver should work in verbose mode. In particular, it writes the compilation command to its standard output.

-o outfile

Specifies the name of the file the output load module is to have. If not supplied, the load module is named SERVER.

-f firstfiles

Specifies one or more user files to be included in the compilation and link edit phases of buildserver first, before the BEA Tuxedo ATMI libraries. If more than one file is specified, filenames 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.

-l lastfiles

Specifies one or more user files to be included in the compilation and link edit phases of buildserver last, after the BEA Tuxedo ATMI libraries. If more than one file is specified, filenames 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

Specifies the resource manager associated with this server. The value 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. 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 } ]

Specifies the names of services that can be advertised when the server is booted. Service names (and implicit function names) must be less than or equal to 15 characters in length. An explicit function name (that is, a name specified after a colon) can be up to 128 characters in length. Names longer than these limits are truncated with a warning message. When retrieved by 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 following specification builds the associated server with services x, y, and z, each to be processed by a function of the same name:

-s x,y,z

In other cases, a service (or several services) may be performed by a function of a different name. The following specification builds the associated server with services x, y, and z, each to be processed by the function abc:

-s x,y,z: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 run time. 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 following specification 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.

-s :pqr

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 `.' 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

Specifies COBOL compilation.

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 buildservercs 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

Keeps the server main stub. 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 filename 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.

-t

Specifies multithreading. If you want your servers to be multithreaded, this option is mandatory. If this option is not specified and you try to boot a server with a configuration file in which the value of MAXDISPATCHTRHREADS is greater than 1, a warning message is printed in the user log and the server reverts to single-threaded operation.

The purpose of this option is to prevent an administrator from trying to boot, as a multithreaded server, a server that is not programmed in a thread-safe manner.

Environment Variables

TUXDIR

buildserver uses the environment variable TUXDIR to find the BEA Tuxedo ATMI libraries and include files to use during compilation of the server process.

CC

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 the buildserver 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

The environment variable 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

When the -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.

Note: On a Windows system, the ALTCC and ALTCFLAGS environment variables are not applicable and setting them will produce unexpected results. You must compile your application first using a COBOL compiler and then pass the resulting object file to the buildserver(1) command.

ALTCFLAGS

The environment variable 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, the value is set to the same value used for CFLAGS, as specified above.

Note: See previous note, under ALTCC environment variable.

COBOPT

The environment variable COBOPT is taken to contain a set of additional arguments to be used by the COBOL compiler, when the -C option is specified.

COBCPY

The environment variable 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 (UNIX systems)

The environment variable LD_LIBRARY_PATH indicates which directories contain shared objects to be used by the COBOL compiler, in addition to the BEA Tuxedo shared objects. Some UNIX systems require different environment variables: for HP-UX systems, use the SHLIB_PATH environment variable; for AIX, use LIBPATH.

LIB (Windows NT systems)

Indicates a list of directories within which to find libraries. A semicolon (;) is used to separate the list of directories.

Compatibility

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.

Portability

The buildserver compilation tool is supported on any platform on which the BEA Tuxedo ATMI server environment is supported. RM XA libraries are not supported on the Windows platform.

Notices

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.

Examples

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

See Also

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

C compiler and linker documentation in the reference manual for your operating system

 

Back to Top Previous Next
dev2devesupporthttp://www.oracle.com/technology/documentation/index.htmlpartner net
Contact e-docsContact BEAwebmasterprivacy