Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	e-docs.bea.com   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary
WebLogic Enterprise Doc Home   |   Tuxedo ATMI Topics   |   Previous Topic   |   Next Topic   |   Contents   |   Index

The BEA Tuxedo Command Reference describes, in alphabetic order, shell-level commands delivered with the BEA Tuxedo software.

Unless otherwise noted, commands described in the Synopsis section of a reference page accept options and other arguments according to the following syntax and should be interpreted as explained below.

name [ -option. . . ] [cmdarg . . .

Where name is the name of an executable file, option is a string of one of the following two types: noargletter . . . or argletter optarg [, . . .] (An option is always preceded by a "-".)

noargletter

Is a single letter representing an option that requires no option-argument. More than one noargletter can be grouped after a "-"

optarg

Is a character string that satisfies a preceding argletter. Multiple optargs following a single argletter must be separated by commas, or separated by white space and enclosed in quotes.

cmdarg

Is a pathname (or other command argument) that represents an operand of the command.

-

(dash) By itself means that additional arguments are provided in the standard input.

--

(two dashes) Means that what follows are arguments for a subordinate program.

[ ]

Surrounding an option or cmdarg, mean that the option or argument is not required.

{ }

Surrounding cmdargs that are separated by an or sign, mean that one of the choices must be selected if the associated option is used.

. . .

Means that multiple occurrences of the option or cmdarg are permitted.

bldc_dce-builds a BEA Tuxedo system client that can be called via OSF/DCE

bldc_dce [-o output_file] [-i idl_options] [-f firstfiles] 
[-l lastfiles] [idl_file . . .] 

bldc_dce parses any input IDL and related ACF source files and combines them with C source and object files and the OSF/DCE libraries to generate a BEA Tuxedo system client that can be called via DCE RPC (it is a DCE RPC client).

The command-line arguments include the input IDL source file and options to control the actions of the IDL compiler. The options are as follows:

-o output_file

The default filename is a.out.

-i idl_options

Specifies options to be passed to the IDL compiler. Options associated with the C compilation system are automatically provided by this program. This option can be used to provide the "-no_mepv" option such that the application can provide a Manager Entry Point Vector.

-f firstfiles

Specifies compiler options, C source and object files to be included on the compilation before the BEA Tuxedo system and OSF/DCE libraries.

-l lastfiles

Specifies C libraries to be included on the compilation after the BEA Tuxedo system and OSF/DCE libraries.

tidl(1)

blds_dce-build a BEA Tuxedo system server that calls OSF/DCE

blds_dce [-o output_file] [-i idl_options] [-f firstfiles] 
[-l lastfiles] [-s service] [idl_file . . .] 

blds_dce parses any input IDL and related ACF source files and combines them with C source and object files and the OSF/DCE libraries to generate a BEA Tuxedo system server that can make DCE RPC calls. The primary use of this command is to make a BEA Tuxedo system-to-OSF/DCE gateway process.

The command-line arguments include the input IDL source file and options to control the actions of the IDL compiler. The options are as follows:

-o output_file

The default filename is a.out.

-i idl_options

Specifies options to be passed to the IDL compiler. Options associated with the C compilation system are automatically provided by this program. This option can be used to provide the "-no_mepv" option such that the application can provide a Manager Entry Point Vector.

-f firstfiles

Specifies compiler options, C source and object files to be included on the compilation before the BEA Tuxedo system and OSF/DCE libraries.

-l lastfiles

Specifies C libraries to be included on the compilation after the BEA Tuxedo system and OSF/DCE libraries.

-s service[,service . . .]

Specifies the services to be advertised by the server.

tidl(1)

build_dgw-build customized domain gateway process

build_dgw [ -c dmtype] [ -o name] [ -v ]

build_dgw is used to construct a customized BEA Tuxedo domain gateway module. The files included by the caller should include only the application buffer type switch and any required supporting routines. The command combines the files supplied by the -c option with the standard BEA Tuxedo libraries necessary to form a gateway load module. The load module is built by the cc(1) command described in UNIX system reference manuals which build_dgw invokes. The options to build_dgw have the following meaning:

-c dmtype

Specifies a domain type that characterizes communications access module domain gateway. The value of dmtype must appear in the domain type table located in $TUXDIR/udataobj/DMTYPE. Each line in this file has the form:

dmtype:access_module_lib:comm_libs:tm_typesw_lib:gw_typesw_lib 

Using the dmtype value, build_dgw retrieves the corresponding entry from $TUXDIR/udataobj/DMTYPE. The access_module_lib specifies the libraries used by a this particular type of domain instantiation. The comm_libs parameter contains a list of the networking communications libraries used by the access module. The tm_typesw_lib parameter defines a list of libraries or object modules with the definition of the typed buffers used by the local application. If this parameter is not defined, the gateway will be linked with the default typed buffer definitions. The gw_typesw_lib parameter applies only to a gateway of type OSITP (see below) and defines a list of libraries or object modules used by the gateway to transform buffers into the protocol required by the remote domain. There should be a one-to-one mapping between the buffer types defined in the tm_typesw array (see typesw(5) and tuxtypes(5)) and the gw_typesw array. If this parameter is not defined, the gateway will be linked with the default typed buffer definitions provided with the OSITP instantiation.

Currently, dmtype may be set to one of the following values:

TDOMAIN

Builds a gateway for communications with another BEA Tuxedo domain. The build_dgw command will use the standard BEA Tuxedo libnws.a networking library. This is the default option.

OSITP

Builds a gateway for communications with an OSI TP domain. The OSITP access module uses the XAP-TP interface. The pathname for the library containing the XAP-TP primitives is provider dependent and should be set according to the provider's specifications.

-o name

Specifies the name of the file the output gateway load module is to have. If not supplied, the load module is named GWTDOMAIN for the TDOMAIN type and GWOSITP for the OSITP type. Note that the name selected for the load module must also be the name used for the definition of the gateway in the *SERVERS section of the TUXCONFIG file.

-v

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

build_dgw normally uses the cc command to produce the a.out. In order to allow for the specification of an alternate compiler, build_dgw checks for the existence of a shell variable named CC. If CC does not exist in the build_dgw command's environment, or if it is the string "", build_dgw 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.

build_dgw is supported as a BEA Tuxedo-supplied compilation tool on UNIX operating systems only.

The following example shows how to build a domain gateway of type TDOMAIN.

CC=ncc CFLAGS="-I $TUXDIR/include"; export CC CFLAGS build_dgw -o DGW

The following example shows use of build_dgw for an OSI TP instantiation:

build_dgw -c OSITP -o OTPGW

For the /TDOMAIN and /OSITP instantiations, the DMTYPE file will contain the following entries:

TDOMAIN:$TUXDIR/lib/libgwt.a:$TUXDIR/lib/libnwi.a $TUXDIR/lib/libnws.a:: 
OSITP:$TUXDIR/lib/libgwo.a:-l xaptp -l ositp::

The paths for the libxaptp.a and libositp.a libraries are installation and provider dependent. The application administrator must specify the correct pathnames before building an OSITP gateway instantiation.

cc(1), ld(1) in UNIX system reference manuals, tuxtypes(5), typesw(5)

buildclient-construct a BEA Tuxedo client module

buildclient [ -C ] [ -v ] [ {-r rmname | -w } ] [ -o name] 
[ -f firstfiles] [ -l lastfiles] 

buildclient is used to construct a BEA Tuxedo client module. The command combines the files supplied by the -f and -l options with the standard BEA Tuxedo libraries to form a load module. The load module is built by buildclient using the default C language compilation command defined for the operating system in use. The default C language compilation command for the UNIX system is the cc(1) command described in UNIX system reference manuals.

-v

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

-w

Specifies that the client is to be built using the workstation libraries. The default is to build a native client if both native mode and workstation mode libraries are available. This option cannot be used with the -r option.

-r rmname

Specifies the resource manager associated with this client. 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 that the client is not associated with a resource manager. Refer to the ubbconfig(5) reference page.

-o

Specifies the filename of the output load module. If not supplied, the load module is named a.out.

-f

Specifies one or more user files to be included in the compilation and link edit phases of buildclient first, before the BEA Tuxedo 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

Specifies one or more user files to be included in the compilation and link edit phases of buildclient last, after the BEA Tuxedo 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.

-C

Specifies COBOL compilation.

TUXDIR

buildclient uses the environment variable TUXDIR to find the System/T libraries and include files to use during compilation of the client process.

CC

buildclient normally uses the default C language compilation command to produce the client executable. The default C language compilation command is defined for each supported operating system platform and is defined as cc(1) for UNIX system. In order to allow for the specification of an alternate compiler, buildclient checks for the existence of an environment variable named CC. If CC does not exist in buildclient's environment, or if it is the string "", buildclient 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 buildclient. If CFLAGS does not exist in buildclient's environment, or if it is the string "", no compiler command-line arguments are added by buildclient.

ALTCC

When the -C option is specified for COBOL compilation, buildclient normally uses the BEA Tuxedo shell cobcc which in turn calls cob to produce the client executable. In order to allow for the specification of an alternate compiler, buildclient checks for the existence of an environment variable named ALTCC. If ALTCC does not exist in buildclient command's environment, or if it is the string "", buildclient 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 buildclient. When the -C option is used, putting compiler options and their arguments in the buildclient -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 (for Solaris and Compaq UNIX systems) indicates which directories contain shared objects to be used by the COBOL compiler, in addition to the BEA Tuxedo system shared objects. On HP UX systems the corresponding environment variable is SHLIB_PATH. For AIX systems the environment variable is LIBPATH. And on Windows NT the corresponding environment variable is LIB.

buildclient is supported as a BEA Tuxedo-supplied compilation tool on UNIX and MS-DOS operating systems. However, due to file naming restrictions, only the buildclt alias is supported on MS-DOS. Note that filenames supplied as part of the buildclient command line must conform to the syntax and semantics of the resident operating system.

The MS-DOS version of buildclt has significant differences from the UNIX system version. These differences warrant a separate man page for the MS-DOS version of the command. Therefore, a separate buildclt(1) reference page is also included to describe the command for the MS-DOS environment.

CC=ncc CFLAGS="-I /APPDIR/include"; export CC CFLAGS 
buildclient -o empclient -f emp.c -f "userlib1.a userlib2.a" 
 
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:$TUXDIR/lib 
export COBOPT COBCPY COBDIR LD_LIBRARY_PATH 
buildclient -C -o empclient -f name.cbl -f "userlib1.a userlib2.a" 

buildclt(1), buildserver(1), buildtms(1), compilation(5),
cc(1), ld(1) in a UNIX system reference manual

buildclt-construct a BEA Tuxedo Workstation client program for MS-DOS, Windows, Windows NT, and OS/2

buildclt [ -C ] [ -v ] [ -m {m | l} ] [ -c {m | b | i} ] 
[ -o name ] [ -f firstfiles ] [ -F Firstlibs ] [ -l libfiles ] 
[ -W ] [ -O ] [ -P ] [ -d deffile ]

buildclt is used to construct a BEA Tuxedo Workstation client program for MS-DOS, Windows, Windows NT, and OS/2. The command combines the files supplied by the -f and -l options with the standard BEA Tuxedo libraries to form an executable program. The load module is built by buildclt using the C and COBOL language compilation commands defined for the operating system in use. The options to buildclt have the following meaning:

-v

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

-o name

Specifies the filename of the output program. If not supplied, the program is named client.exe.

-f firstfiles

Specifies one or more user files (or options to the compiler or linker) to be included on the command line first, before the BEA Tuxedo libraries. If more than one file is specified, filenames must be separated by white space and the entire list must be enclosed in double quotation marks. This option may be specified multiple times.

-F Firstlibs

Specifies one or more standard or import (not dynamic-link) libraries to be included before the BEA Tuxedo libraries. If more than one file is specified, filenames must be separated by white space and the entire list must be enclosed in double quotation marks. This option may be specified multiple times.

-l libfiles

Specifies one or more standard or import (not dynamic-link) libraries to be included after the BEA Tuxedo libraries. If more than one file is specified, filenames must be separated by white space and the entire list must be enclosed in double quotation marks. This option may be specified multiple times.

-d deffile

Specifies a module definition file used for linking an MS Windows, Windows NT or OS/2 program.

-m {m | l}

Specifies the memory model to be used for compilation and linking of a client. The values for this option are m and l for the medium and large memory models, respectively. The large memory model is the default value for this option. The medium memory model is no longer supported for DOS. The memory model needs only to be specified for Windows and OS/2 16-bit compilation.

-c {m | i}

Specifies the compilation system to be used. The supported values for this option are m or i for the Microsoft C/C++ compiler, or the IBM CSET2 compiler, respectively. The Microsoft C compiler is the default value for this option. The IBM CSET2 compiler can only be used for OS/2 32-bit compilation.

-W

Compile and link an Microsoft Windows or Windows NT client.

-O

Compile and link an OS/2 character-mode client.

-P

Compile and link an OS/2 Presentation Manager client.

-C

Specifies COBOL compilation.

The following environment variables must be set for the COBOL environment.

COBCPY

The environment variable COBCPY indicates which directories contain a set of COBOL copy files to be used by the COBOL compiler.

The buildclt command assumes that directories for needed libraries are specified in the environment variables INCLUDE and LIB. They might look like the following:

INCLUDE=C:\TUXEDO\INCLUDE;C:\NET\TOOLKIT\INCLUDE;C:MSVC\INCLUDE
LIB=C:\NET\TOOLKIT\LIB;C:\WINDEV\LIB;C:\MSVC\LIB;C:\TUXEDO\LIB;

Note that in the above example, C:MSVC is the directory where Microsoft Visual C++ resides; earlier versions such as C600 or C700 can be used. Note that in the above example, C:NET is the directory where Novell LAN Workplace resides; earlier versions resided in C:XLN and can be used.

Note that COBOL source files that reference ATMI calls must be compiled with the LITLINK option.

The names of all libraries used for linking the client followed by the files specified in the -l option are put into a temporary response file and linking is done using the command line:

LINK firstfiles, outname @tmpfile 

are the filenames specified with the -f option, outname is the output filename (default client.exe), and tmpfile is the temporary response filename. The -f option should be used to include any necessary options to be passed to LINK (for example, /ST:10000 to set the default stack size to 10000 bytes). The -l option should be used to include any necessary network provider libraries (for example, mlibsock.lib). To create an executable that can be debugged using Codeview (assuming that the object files have been compiled with the -Zi option), use -f /CO.

MS-DOS C Compilation:

buildclt -cm -ml -o emp.exe -f "/CO/ST:10000/SE:200" -f emp.obj -l llibsock.lib

WINDOWS C Compilation:

buildclt -W -cm -mm -o emp.exe -f "/CO emp.obj" -d emp.def rc -k emp.res emp.exe

OS2 16-Bit:

buildclt -O -cm -ml -o emp.exe -f "/NOI/ST:15000/CO emp.obj" -d emp.def

OS2 32-Bit IBM:

buildclt -O -ci -f "/NOI/ST:25000 /CO emp.obj" -o emp.exe

Windows NT:

!include <ntwin32.mak> 
rc -r emp.rc 
buildclt -W -f "emp.obj emp.res" -l "$(winlibs)" -oemp.exe

DOS/WINDOWS/OS2 COBOL Compilation:

COBCPY=C:\TUXEDO\COBINC  
COBDIR=C:\COBOL\LBR;C:\COBOL\EXEDLL 
PATH=C:\C700BIN\;C:COBOLEXEDLL;... 
TUXDIR=C:\TUXEDO 
INCLUDE=C:\TUXEDO\INCLUDE;C:\XLN\TOOLKIT\INCLUDE;C:\C700\INCLUDE
LIB=C:\XLN\TOOLKIT\LIB;C:\C700\LIB;C:\TUXEDO\LIB;C:\COBOL\LIB 
 
COBOL EMP.CBL OMF"OBJ" LITLINK

DOS:

BUILDCLT -C -o EMP.EXE -f EMP+MFC7INTF+C7DOSIF+C7DOSLB \
-f "/NOD/NOE/SE:300/CO/ST:10000" -l LLIBSOCK

WINDOWS:

BUILDCLT -C -W -o EMP.EXE -f EMP -d EMP.DEF -f "/NOD/NOE/CO/SE:300"

OS2:

BUILDCLT -C -P -o EMP.EXE -f EMP+MFC6INTF+C6OS2IF+C6OS2LB -d 
EMP.DEF \  -f "/NOD/NOE/SE:300/CO"

Microsoft C/C++ Programming Techniques, Microsoft Corporation. Micro Focus COBOL/2 Operating Guide, Micro Focus Ltd. Micro Focus COBOL/2 Workbench for DOS and OS2, Micro Focus Ltd.

buildserver-construct a BEA Tuxedo server load module

buildserver [-C] [-s { @filename | service[,service...][:func] | :func } ] [-n maxdynam] [-v] [-o outfile] [-f firstfiles] 
[-l lastfiles] [{-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

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 can 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 BEA Tuxedo 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.

-llastfiles

Specifies one or more user files to be included in the compilation and link edit phases of buildserver last, after the BEA Tuxedo 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. 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 } ]

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

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

TUXDIR

buildserver uses the environment variable TUXDIR to find the BEA Tuxedo 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 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.

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

The buildserver compilation tool is supported on any platform on which the BEA Tuxedo server environment is supported.

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

buildtms(1)-construct a transaction manager server load module

buildtms [ -v ] -o name -r rm_name

buildtms is used to construct a transaction manager server load module.

While several TM servers are provided with BEA Tuxedo, new resource managers may be provided to work with BEA Tuxedo for distributed transaction processing. The resource manager must conform to the X/OPEN XA interface. The following four items must be published by the resource manager vendor: the name of the structure of type xa_switch_t that contains the name of the resource manager, flags indicating capabilities of the resource manager, and function pointers for the actual XA functions; the name of the resource manager that is contained in the name element of the xa_switch_t structure; the name of the object files that provide the services of the XA interface and supporting software; and the format of the information string supplied to the OPENINFO and CLOSEINFO parameters in the UBBCONFIG configuration file. See ubbconfig(5).

When integrating a new resource manager into the BEA Tuxedo system, the file $TUXDIR/udataobj/RM must be updated to include the information about the resource manager. The format of this file is

rm_name:rm_structure_name:library_names 

where rm_name is the resource manager name, rm_structure_name is the name of the xa_switch_t structure, and library_names is the list of object files for the resource manager. White space (tabs and/or spaces) is allowed before and after each of the values and may be embedded within the library_names. The colon (:) character may not be embedded within any of the values. Lines beginning with a pound sign (#) are treated as comments and are ignored.

A transaction manager server for the new resource manager must be built using buildtms and installed in $TUXDIR/bin. buildtms uses the buildserver(1) command to build the resulting a.out. The options to buildtms have the following meaning:

-v

Specifies that buildtms should work in verbose mode. In particular, it writes the buildserver command to its standard output and specifies the -v option to buildserver.

-o name

Specifies the name of the file the output load module is to have.

-r rm_name

Specifies the resource manager associated with this server. The value rm_name must appear in the resource manager table located in $TUXDIR/udataobj/RM. The entry associated with the rm_name value is used to include the correct libraries for the resource manager automatically and properly to set up the interface between the transaction manager and resource manager (using the xa_switch_t structure).

buildtms uses the buildserver command to produce the a.out. buildserver uses the CC and CFLAGS environment variables, if set, for the compiler and compiler flags, respectively. See buildserver(1) for further details.

buildtms is supported as a BEA Tuxedo system-supplied compilation tool for UNIX and Windows NT systems.

buildtms -o $TUXDIR/bin/TMS_D -r TUXEDO/D # standard System/D TMS 
buildtms -o $TUXDIR/bin/TMS_XYZ -r XYZ/SQL # TMS for XYZ resource manager 

buildserver(1), ubbconfig(5)

buildwsh-build customized Workstation Handler process

buildwsh [ -v ] [ -o name]  [ -f files]

buildwsh is used to construct a customized BEA Tuxedo Workstation Handler module. The files included by the caller should include only the application buffer type switch and any required supporting routines. The command combines the files supplied by the -f option with the standard BEA Tuxedo libraries necessary to form a Workstation Handler load module. The load module is built by the cc(1) command described in UNIX system reference manuals, which buildwsh invokes. The options to buildwsh have the following meaning:

-v

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

-o name

Specifies the filename of the output Workstation Handler load module. The name specified here must also be specified with the -w WSHname option of the WSL(5) server in the SERVER section of the configuration file. If not supplied, the load module is named WSH.

-f firstfiles

Specifies one or more user files to be included in the compilation and/or link edit phases of buildwsh. Source files are compiled using the either the cc command or the compilation command specified through the CC environment variable. Object files resulting from compilation of source files and object files specified directly as arguments to the -f option are included after all object files necessary to build a base Workstation Handler process and before the BEA Tuxedo 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 can be specified multiple times.

buildwsh normally uses the cc command to produce the a.out. In order to allow for the specification of an alternate compiler, buildwsh checks for the existence of a shell variable named CC. If CC does not exist in the buildwsh command's environment, or if it is the string "", buildwsh 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.

If your application uses shared libraries, it is not necessary to go through this compile and link process. See the description in the "Buffer Types" chapter of the BEA WebLogic Enterprise Administration Guide.

buildwsh is supported as a BEA Tuxedo-supplied compilation tool on UNIX operating systems only.

ncc CFLAGS="-I $TUXDIR/include"; export CC CFLAGS buildwsh 
-o APPWSH -f apptypsw.o

buildclient(1), wsl(5) cc(1), ld(1) in UNIX system reference manuals

cobcc-COBOL compilation interface

cobcc [option...] filename...

cobcc is used as an interface shell to the COBOL compiler. It is invoked, by default, when buildclient(1) or buildserver(1) is executed with the -C (COBOL) option. This can be overridden by specifying the ALTCC environment variable.

The following list indicates the options recognized by cobcc. To use these options, set the environment variable ALTCFLAGS to the string of options to be recognized by cobcc when running buildclient or buildserver. Consult your documentation for the COBOL and C compilers to see what effect the various options have.

Note that for cobcc, unlike cc and cob, all options must come before any filenames.

-c

This option specifies that the link phase should be suppressed. That is, compilation will be done but an executable program will not be generated.

-p -g -r -O

These option are passed directly to the COBOL compiler.

-l argument

This option and its argument are passed directly to the COBOL compiler (with no white space separating them).

-L argument

This option and its argument are passed directly to the COBOL compiler (with one space separating them).

-o output_file

This option is used to specify the name of the executable file that is output from the link stage.

-E -P -S

These options are passed through the COBOL compiler to the C compiler, and also cause suppression of the link phase.

-A -C -H -f -G

These options are passed through the COBOL compiler to the C compiler.

-w

This option causes warnings to be suppressed from both the COBOL and C compilers.

-D argument

This option and its argument are passed through the COBOL compiler to the C compiler. It is used to define macros in C.

{-T -Y -U -I -B -X -F -q} argument

Each of these options takes an argument.The option and its argument are passed through the COBOL compiler to the C compiler.

-V -v

Each of these options is passed both to the COBOL compiler and the C compiler.

-a -s

Each of these options is passed to the loader.

-u argument

This option and its argument are passed to the loader.

-W argument

The argument may consist of up to three comma-separated fields. If the first part of the argument is -p or -0, it is passed to the C compiler. If it starts with -a, it is passed to the assembler. If it starts with -l, it is passed to the loader. If it starts with -C, it is passed to the COBOL compiler. Otherwise, it is passed through to the C compiler.

The options and their arguments and the filenames are passed to the COBOL compiler with the correct options so that the right information is processed by the COBOL compiler, the C compiler, or the loader. The COBOL compiler name is assumed to be cob and already in the PATH.

buildclient(1), buildserver(1), cc reference page, Micro Focus COBOL/2 Operating Guide, Micro Focus Ltd.

dmadmin-BEA Tuxedo Domain Administration Command Interpreter

dmadmin [ -c ]

dmadmin is an interactive command interpreter used for the administration of domain gateway groups defined for a particular BEA Tuxedo application. dmadmin can operate in two modes: administration mode and configuration mode.

dmadmin enters administration mode when called with no parameters. This is the default. In this mode, dmadmin can be run on any active node (excluding workstations) within an active application. Application administrators can use this mode to obtain or change parameters on any active domain gateway group. Application administrators may also use this mode to create, destroy, or reinitialize the DMTLOG for a particular local domain. In this case, the domain gateway group associated with that local domain must not be active, and dmadmin must be run on the machine assigned to the corresponding gateway group.

dmadmin enters configuration mode when it is invoked with the -c option or when the config subcommand is invoked. Application administrators can use this mode to update or add new configuration information to the binary version of the domain configuration file (BDMCONFIG).

dmadmin requires the use of the DOMAIN administrative server (DMADM) for the administration of the BDMCONFIG file and the gateway administrative server (GWADM) for the reconfiguration of active DOMAIN gateway groups (there is one GWADM per gateway group).

Once dmadmin has been invoked, commands may be entered at the prompt (">") according to the following syntax:

command [arguments] 

Several commonly occurring arguments can be given defaults via the default command. Commands that accept parameters set via the default command check default to see if a value has been set. If one hasn't, an error message is returned.

Once set, a default remains in effect until the session is ended, unless changed by another default command. Defaults may be overridden by entering an explicit value on the command line, or unset by entering the value "*". The effect of an override lasts for a single instance of the command.

Output from dmadmin commands is paginated according to the pagination command in use (see the paginate subcommand below).

Commands may be entered either by their full name or their abbreviation (shown in parentheses) followed by any appropriate arguments. Arguments appearing in square brackets, [], are optional; those in curly braces, {}, indicate a selection from mutually exclusive options. Note that for many commands local_domain_name is a required argument, but note also that it can be set with the default command.

The following commands are available in administration mode:

advertise (adv) -d local_domain_name [{ | service}]

Advertise all remote services provided by the named local domain or the specified remote service.

audit (audit) -d local_domain_name [{off | on}]

Activate (on) or deactivate (off) the audit trace for the named local domain. If no option is given, then the current setting will be toggled between the values on and off, and the new setting will be printed. The initial setting is off.

chbktime (chbt) -d local_domain_name -t bktime

Change the blocking timeout for a particular local domain.

config (config)

Enter configuration mode. Commands issued in this mode follow the conventions defined in the section "Configuration Mode Commands" later in this reference page.

connect (co) -d local_domain_name [-R remote_domain_name]

Connect the local domain gateway to the remote gateway. If the connection attempt fails and you have configured the local domain gateway to retry a connection, repeated attempts to connect (via automatic connection retry processing) is made. (If -R is not specified, then the command applies to all remote domains configured for this local gateway.)

crdmlog (crdlog)[-d local_domain_name]

Create the domain transaction log for the named local domain on the current machine (that is, the machine where dmadmin is running). The command uses the parameters specified in the DMCONFIG file. This command fails if the named local domain is active on the current machine or if the log already exists.

default (d) [-d local_domain_name]

Set the corresponding argument to be the default local domain. Defaults may be unset by specifying "*" as an argument. If the default command is entered with no arguments, the current defaults are printed.

disconnect (dco) -d local_domain_name [-R remote_domain_name]

Break the connection between the local domain gateway and the remote gateway and do not initiate connection retry processing. If no connection is active, but automatic connection retry processing is in effect, then stop the automatic retry processing. (If -R is not specified, then the command applies to all remote domains configured for this local gateway.)

dsdmlog (dsdlg) -d local_domain_name [ -y ]

Destroy the domain transaction log for the named local domain on the current machine (that is, the machine where dmadmin is running). An error is returned if a DMTLOG is not defined for this local domain, if the local domain is active, or if outstanding transaction records exist in the log. The term outstanding transactions means that a global transaction has been committed but an end-of-transaction has not yet been written. This command prompts for confirmation before proceeding unless the -y option is specified.

echo (e) [{off | on}]

Echo input command lines when set to on. If no option is given, then the current setting is toggled, and the new setting is printed. The initial setting is off.

forgettrans (ft) -d local_domain_name [ -t tran_id]

Forget one or all heuristic log records for the named local domain. If the transaction identifier tran_id is specified, then only the heuristic log record for that transaction will be forgotten. The transaction identifier tran_id can be obtained from the printtrans command or from the ULOG file.

help (h) [command]

Print help messages. If command is specified, the abbreviation, arguments, and description for that command are printed. Omitting all arguments causes the syntax of all commands to be displayed.

indmlog (indlg) -d local_domain_name [ -y ]

Reinitialize the domain transaction log for the named local domain on the current machine (that is, the machine where dmadmin is running). An error is returned if a DMTLOG is not defined for this local domain, if the local domain is active, or if outstanding transaction records exist in the log. The term outstanding transactions means that a global transaction has been committed but an end-of-transaction has not yet been written. The command prompts for confirmation before proceeding unless the -y option is specified.

paginate (page) [{off | on}]

Paginate output. If no option is given, then the current setting will be toggled, and the new setting is printed. The initial setting is on, unless either standard input or standard output is a non-tty device. Pagination may only be turned on when both standard input and standard output are tty devices.The shell environment variable PAGER may be used to override the default command used for paging output. The default paging command is the indigenous one to the native operating system environment, for example, the command pg is the default on UNIX system operating environments.

passwd (passwd) [ -r ] local_domain_name remote_domain_name

Prompt the administrator for new passwords for the specified local and remote domains. The -r option specifies that existing passwords and new passwords should be encrypted using a new key generated by the system. The password is limited to at most 30 characters.

printdomain (pd) -d local_domain_name

Print information about the named local domain. Information printed includes a list of connected remote domains, a list of remote domains being retried (if any), global information shared by the gateway processes, and additional information that is dependent on the domain type instantiation.

printstats (pstats) -d local_domain_name

Print statistical and performance information gathered by the named local domain. The information printed is dependent on the domain gateway type.

printtrans (pt) -d local_domain_name

Print transaction information for the named local domain.

quit (q)

Terminate the session.

resume (res) -d local_domain_name [{ -all | service}]

Resume processing of either the specified service or all remote services handled by the named local domain.

stats (stats) -d local_domain_name [{ off | on | reset }]

Activate (on), deactivate (off), or reset (reset) statistics gathering for the named local domain. If no option is given, then the current setting will be toggled between the values on and off, and the new setting will be printed. The initial setting is off.

suspend (susp) -d local_domain_name [{ -all | service}]

Suspend one or all remote services for the named local domain.

unadvertise (unadv) -d local_domain_name [{ -all | service}]

Unadvertise one or all remote services for the named local domain.

verbose (v) [{off | on}]

Produce output in verbose mode. If no option is given, then the current setting will be toggled, and the new setting is printed. The initial setting is off.

! shellcommand

Escape to shell and execute shellcommand.

!!

Repeat previous shell command.

# [text]

Lines beginning with "#" are comment lines and are ignored.

<CR>

Repeat the last command.

The dmadmin command enters configuration mode when executed with the -c option or when the config subcommand is used. In this mode, dmadmin allows run-time updates to the BDMCONFIG file. dmadmin manages a buffer that contains input field values to be added or retrieved, and displays output field values and status after each operation completes. The user can update the input buffer using any available text editor.

dmadmin first prompts for the desired section followed by a prompt for the desired operation.

The prompt for the section is as follows:

Section:
         1) RESOURCES         2) LOCAL_DOMAINS
         3) REMOTE_DOMAINS    4) LOCAL_SERVICES
         5) REMOTE_SERVICES   6) ROUTING
         7) ACCESS_CONTROL    8) PASSWORDS
         9) TDOMAINS         10) OSITPS
        11) SNADOMS          12) LOCAL_REMOTE_USER
        13) REMOTE_USERS     14) SNACRMS
        15) SNASTACKS        16) SNALINKS
        17) QUIT
Enter Section [1]:

The number of the default section appears in square brackets at the end of the prompt. You can accept the default by pressing RETURN or ENTER. To select another section enter its number, then press RETURN or ENTER.

dmadmin then prompts for the desired operation.

Operations:
        1) FIRST        2) NEXT
        3) RETRIEVE     4) ADD
        5) UPDATE       6) DELETE
        7) NEW_SECTION  8) QUIT
Enter Operation [1]:

The number of the default operation is printed in square brackets at the end of the prompt. Pressing RETURN or ENTER selects this option. To select another operation enter its number, then press RETURN or ENTER.

The currently supported operations are:

1. FIRST-Retrieve the first record from the specified section. No key fields are needed (they are ignored if in the input buffer).

2. NEXT-Retrieve the next record from the specified section, based on the key fields in the input buffer.

3. RETRIEVE-Retrieve the indicated record from the specified section by key field(s) (see fields description below).

4. ADD-Add the indicated record in the specified section. Any fields not specified (unless required) take their defaults as specified in dmconfig(5). The current value for all fields is returned in the output buffer. This operation can only be done by the BEA Tuxedo administrator.

5. UPDATE-Update the record specified in the input buffer in the selected section. Any fields not specified in the input buffer remain unchanged. The current value for all fields is returned in the input buffer. This operation can only be done by the BEA Tuxedo administrator.

6. DELETE-Delete the record specified in the input buffer from the selected section. This operation can only be done by the System/T administrator.

7. NEW SECTION-Clear the input buffer (all fields are deleted). After this operation, dmadmin immediately prompts for the section again.

8. QUIT-Exit the program gracefully (dmadmin is terminated). A value of q for any prompt also exits the program.

For configuration operations, the effective user identifier must match the BEA Tuxedo administrator user identifier (UID) for the machine on which this program is executed. When a record is updated or added, all defaults and validations used by dmloadcf(1) are enforced.

dmadmin then prompts whether or not to edit the input buffer: Enter editor to add/modify fields [n]? Entering a value of y will put the input buffer into a temporary file and execute the text editor. The environment variable EDITOR is used to determine which editor is to be used; the default is "ed". The input format is in field name/field value pairs and is described in the "CONFIGURATION INPUT FORMAT" section below. The field names associated with each DMCONFIG section are listed in tables in the subsections below. The semantics of the fields and associated ranges, defaults, restrictions, etc., are described in dmconfig(5). In most cases, the field name is the same as the KEYWORD in the DMCONFIG file, prefixed with "TA_". When the user completes editing the input buffer, dmadmin reads it. If more than one line occurs for a particular field name, the first occurrence is used and other occurrences are ignored. If any errors occur, a syntax error will be printed and dmadmin prompts whether or not to correct the problem. Enter editor to correct?

If the problem is not corrected (response n), then the input buffer will contain no fields. Otherwise, the editor is executed again.

Finally, dmadmin asks if the operation should be done. Perform operation [y]?

When the operation completes, dmadmin prints the return value as in Return value TAOK followed by the output buffer fields. The process then begins again with a prompt for the section. All output buffer fields are available in the input buffer unless the buffer is cleared.

Entering break at any time restarts the interaction at the prompt for the section.

When "QUIT" is selected, dmadmin prompts for authorization to create a backup ASCII version of the configuration: Unload BDMCONFIG file into ASCII backup [y]? If a backup is selected, dmadmin prompts for the filename: Backup filename [DMCONFIG]. On success, dmadmin indicates that a backup was created; otherwise, an error is printed.

Input packets consist of lines formatted as follows:

fldname fldval

The field name is separated from the field value by one or more tabs (or spaces).

Lengthy field values can be continued on the next line by having the continuation line begin with one or more tabs (which are dropped when read back into dmadmin).

Empty lines consisting of a single newline character are ignored.

To enter an unprintable character in the field value or to start a field value with a tab, use a backslash followed by the two-character hexadecimal representation of the desired character (see ASCII(5) in a UNIX reference manual). A space, for example, can be entered in the input data as \20. A backslash can be entered using two backslash characters. dmadmin recognizes all input in this format, but its greatest usefulness is for non-printing characters.

The following are general limitations of the dynamic domain reconfiguration capability:

• Values for key fields (as indicated in the following sections) may not be modified. Key fields can be modified, when the system is down, by reloading the configuration file.

• Dynamic deletions cannot be applied when local domains are active (the corresponding gateway group is running).

Restrictions for Configuration Field Identifiers/
Updates

The following sections describe, for each DMCONFIG section, what the field identifiers are associated with each DMCONFIG field, what the field type of the identifier is, and when the field can be updated. All applicable field values are returned with the retrieval operations. Fields that are allowed and/or required for adding a record are described in dmconfig(5). Fields indicated below as key are key fields that are used to uniquely identify a record within section These key fields are required to be in the input buffer when updates are done and are not allowed to be updated dynamically. The Update column indicates when a field can be updated. The possible values are:

• Yes-Can be updated at any time.

• NoGW-Cannot be updated dynamically while the gateway group representing the local domain is running.

• No-Cannot be updated dynamically while at least one gateway group is running.

Configuring the dm_local_domains section

The following table lists the fields in the *DM_LOCAL_DOMAINS section.

Table 0-1 DM_LOCAL_DOMAINS SECTION

Field Identifier	Type	Update	Notes
TA_LDOM	string	NoGW	key
TA_AUDITLOG	string	NoGW
TA_BLOCKTIME	numeric	NoGW
TA_CONNECTION_POLICY	string	NoGW
TA_DOMAINID	string	NoGW
TA_DMTLOGDEV	string