PURPOSE
buildserver - construct a TUXEDO System server load module
SYNOPSIS
SYNOPSISbuildserver [-C] [-s { @filename | service[,service...][:func] | :func } ]
[-n maxdynam] [-v] [-o outfile] [-f firstfiles] [-l lastfiles] [{-r|-g} rmname] [ -k ]
DESCRIPTION
buildserver
is used to construct a TUXEDO System server load module.
The command combines the files supplied by the -f
and -l
options with the standard server main routine
and the
standard TUXEDO System 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.
- -n maxdynam
- specifies the maximum number of dynamic services
the user may specify when the server is run.
A dynamic service allows the user to specify at run time the
function within the server
that is to process the service.
If -n is not specified,
the maximum number of such services is set to 25.
- -ffirstfiles
- specifies one or more user files to be included
in the compilation and link edit phases of buildserver
first, before the System/T 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
- specifies one or more user files to be included
in the compilation and link edit phases of buildserver
last, after the System/T 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
- 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.
The value TUXEDO/D includes the libraries
for the TUXEDO System/D resource manager.
The value TUXEDO/SQL includes the libraries
for the 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) manual 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 a file is retrieved by tmadmin(1) or \f4TM_MIB(5), only
the first 15 characters of its 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(3cbl) 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 character '_' or '.'
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 buildserver's
environment, or if it is the string "", buildserver
uses 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 tabke abd 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.
ENVIRONMENT VARIABLES
- TUXDIR
- buildserver uses the environment variable TUXDIR to find the
System/T 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 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 executed.
- 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 TUXEDO shell cobcc 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
- 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, then the value is set to the same value used for CFLAGS,
as specified above.
- 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
- The environment variable LD_LIBRARY_PATH indicates which
directories contain
shared objects to be used by the COBOL compiler, in addition
to the TUXEDO System shared objects.
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.
The genoption database is equivalent to TUXEDO/D, and
the genoption sql is equivalent to TUXEDO/SQL.
PORTABILITY
buildserver is supported as a TUXEDO System-supplied compilation tool
on UNIX Systems only.
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"
#endifTo 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 how to use the buildserver command
without specifying a resource manager:
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),
cc(1), ld(1) in a UNIX System reference manual