Skip navigation.

File Formats, Data Descriptions, MIBs, and System Processes Reference

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader


AUTHSVR Additional Information


Warning: ${TUXDIR}/lib/AUTHSVR.c is not the source file used to generate ${TUXDIR}/bin/AUTHSVR (don't clobber this executable); if you provide your own AUTHSVR, it is recommended that you install it in ${APPDIR}.


AUTHSVR is supported as a BEA Tuxedo-supplied server on non-Workstation platforms.



AUTHSVR SRVGRP="AUTH" CLOPT="-A -- -f /usr/tuxedo/users" \
# Using ACLs

# Using a custom authentication service


See Also

tpaddusr(1), tpusradd(1), UBBCONFIG(5)

Setting Up a BEA Tuxedo Application

Administering a BEA Tuxedo Application at Run Time

Programming a BEA Tuxedo ATMI Application Using C




compilation—Instructions for compilation of BEA Tuxedo ATMI system application components.


In order to compile application clients and servers, and subroutines that are link edited with the BEA Tuxedo system, programmers need to know:

A programmer who has finished writing code modules and is ready to build an executable program must:

The BEA Tuxedo system provides two commands that perform both of these operations for client and server modules: buildclient() and buildserver(), respectively. If you run one of these commands to perform both operations, be sure to specify, on the command line, the libraries with which your files need to be link edited. (For details, see buildclient(1) or buildserver(1) in BEA Tuxedo Command Reference.)

Link editing must be done by running buildclient or buildserver, but the system allows more flexibility about how compiling is done. If you prefer, you can use the compile command of your choice to compile your files, and then run buildclient or buildserver to perform the link editing.

This rest of this reference page specifies the header files and environment variables required for various types of programs.

Basic BEA Tuxedo System

In terms of header file sequence, UNIX header files should always be included before any BEA Tuxedo system header files. Commonly used UNIX header files are stdio.h and ctype.h.

Environment Variables

The following environment variables should be set and exported:


Specifies the topmost directory in which the BEA Tuxedo system software resides.


Should include $TUXDIR/bin.


Prefix of the filename of the central event log; by default, the value of ULOGPFX is ULOG.

If . . .

Then you must first set and export the following environment variables . . .

You want to run

  • buildclient(1)

  • buildserver(1)

  • TUXDIR—always required for servers; also required for native clients

  • CC—if you want to use a non-default compiler

  • CFLAGS—if you want to specify flags to be passed to the compiler

A default or validation routine references FML fields

  • FIELDTBLS—a comma-separated list of field table files

  • FLDTBLDIR—a colon-separated list of directories to search for the FIELDTBLS

You want to execute a server

TUXCONFIG—full pathname of the binary configuration file (default is the current directory)

  • Security is turned on in your application

  • You are going to supply input indirectly (that is, from a source other than standard input) for any of the following system-supplied clients: tmadmin(1), tmconfig or wtmconfig (see tmconfig, wtmconfig(1)), or ud or wud (see ud, wud(1))

  • APP_PW—application password

  • USR_PW—user password

You want to execute a Workstation client

  • WSENVFILE—file containing environment variable settings

  • WSDEVICE—network device to use for connection

  • WSTYPE—workstation machine type


Note: More information about these variables can be found in Programming a BEA Tuxedo ATMI Application Using C, Programming a BEA Tuxedo ATMI Application Using COBOL, and Setting Up a BEA Tuxedo Application.

After the system has been built with shared libraries and before you execute a client, you must set a variable that defines the location of the shared libraries.

On this platform . . .

Set the following environment variable . . .

All platforms except HP-UX and AIX







Note: More information about options for servers can be found on the servopts(5) reference page.

FML Programs

In terms of header file sequence, C programs that call FML functions should include the following header files, in the following order:

#include <UNIX_header_files> (if needed by the application)
#include "fml.h"

Compilation of FML Programs

To compile a program that contains FML functions, execute:

cc pgm.c -I $TUXDIR/include -L $TUXDIR/lib -lfml -lengine -o pgm

where pgm is the name of the executable file.

If the -L option is not locally supported, use the following command, instead:

cc pgm.c -I $TUXDIR/include $TUXDIR/lib/libfml.a $TUXDIR/lib/libengine.a -o pgm

Note: The order in which the libraries are specified is significant. Use the order given above.

Compiling FML VIEWS

To use the FML view compiler, execute the following:

viewc view_file

Here view_file is a set of one or more files containing source view descriptions.

Note: viewc invokes the C compiler. The environment variable CC can be used to designate the compiler to use. The environment variable CFLAGS can be used to pass a set of parameters to the compiler.

Environment Variables for FML

The following environment variables should be set and exported when running an application that uses FML.


A comma-separated list of field table files.


A colon-separated list of directories to search for the FIELDTBLS.

The following environment variables should be set and exported when executing viewc.


A comma-separated list of field table files.


A colon-separated list of directories to search for the FIELDTBLS.


A directory containing viewfiles; the default is the current directory.

See Also

buildclient(1), buildserver(1), viewc, viewc32(1)
(1), mc(1) in a UNIX system reference manual




DMADM—Domains administrative server


DMADM SRVGRP = "identifier"


The Domains administrative server (DMADM) is a BEA Tuxedo system-supplied server that provides run-time access to the BDMCONFIG file.

DMADM is described in the SERVERS section of the UBBCONFIG file as a server running within a group, for example, DMADMGRP. There should be only one instance of the DMADM running in this group, and it must not have a reply queue (REPLYQ must be set to "N").

The following server parameters can also be specified for the DMADM server in the SERVERS section: SEQUENCE, ENVFILE, MAXGEN, GRACE, RESTART, RQPERM, and SYSTEM_ACCESS.

The BDMCONFIG environment variable should be set to the pathname of the file containing the binary version of the DMCONFIG file.


DMADM is supported as a BEA Tuxedo system-supplied server on all supported server platforms.


DMADM must be installed on BEA Tuxedo release 5.0 or later; other machines in the same domain with a release 5.0 gateway may be release 4.1 or later.


The following example illustrates the definition of the administrative server and a gateway group in the UBBCONFIG file. This example uses the GWTDOMAIN gateway process to provide connectivity with another BEA Tuxedo domain.

gwgrp LMID=mach1 GRPNO=2

See Also

dmadmin(1), tmboot(1), DMCONFIG(5), GWADM(5), servopts(5), UBBCONFIG(5)

Setting Up a BEA Tuxedo Application

Administering a BEA Tuxedo Application at Run Time

Using the BEA Tuxedo TOP END Domain Gateway with ATMI Applications




DMCONFIG—Text version of a Domains configuration file


A Domains configuration is a set of two or more domains (business applications) that can communicate and share services with the help of the BEA Tuxedo Domains component. How multiple domains are connected and which services they make accessible to each other are defined in a Domains configuration file for each BEA Tuxedo domain participating in the Domains configuration. The text version of a Domains configuration file is known as the DMCONFIG file, although the configuration file may have any name as long as the content of the file conforms to the format described on this reference page.

The DMCONFIG file is parsed and loaded into a binary version, called BDMCONFIG, by the dmloadcf(1) utility. As with DMCONFIG, the BDMCONFIG file may be given any name; the actual name is the device or system filename specified in the BDMCONFIG environment variable. One BDMCONFIG file is required for each Tuxedo domain participating in a Domains configuration.

The DMCONFIG and BDMCONFIG files are analogous to the UBBCONFIG and TUXCONFIG files used to define a BEA Tuxedo domain. For a description of the UBBCONFIG and TUXCONFIG files, see UBBCONFIG(5).

For additional information pertaining to the DMCONFIG file, including examples, see DMCONFIG(5) Additional Information. For a detailed description of the BEA Tuxedo Domains component for both ATMI and CORBA environments, see Using the BEA Tuxedo Domains Component.


A BEA Tuxedo domain is defined as the environment described in a single TUXCONFIG file. In BEA Tuxedo terminology, a domain is the same as an application—a business application.

There is one Domains administrative server (DMADM) process running in each BEA Tuxedo domain involved in a Domains configuration. The DMADM is the administrative server for all domain gateway groups running in a particular BEA Tuxedo domain.

A domain gateway group consists of a BEA Tuxedo system gateway administrative server (GWADM) process and a BEA Tuxedo system domain gateway process.

A BEA Tuxedo system domain gateway process provides communication services with a specific type of transaction processing (TP) domain; for example, the GWTDOMAIN process enables BEA Tuxedo applications to communicate with other BEA Tuxedo applications. A domain gateway relays requests to another domain and receives replies.

A local domain access point is a user-specified logical name representing a set of services of the BEA Tuxedo domain that is made available to other domains (remote domains). A local domain access point maps to a domain gateway group; both terms are used as synonyms.

A remote domain access point is a user-specified logical name representing a set services of a remote domain that is made available to the local domain. The remote domain may be another BEA Tuxedo application or an application running on another TP system.

A remote service is a service provided by a remote domain that is made available to the local domain through a remote domain access point and a local domain access point.

A local service is a service of the local domain that is made available to remote domains through a local domain access point.

Configuration File Purpose

You use a DMCONFIG file to:

Configuration File Format

The DMCONFIG file is made up of the following specification sections:

Lines in a DMCONFIG file beginning with an asterisk (*) indicate the beginning of a specification section. Each such line contains the name of the section immediately following the *. The asterisk is required when specifying a section name. The DM_LOCAL section must precede the DM_REMOTE section.

This reference page describes how to configure a domain gateway of type TDOMAIN (the TDomain gateway), which is implemented by the GWTDOMAIN gateway process. For information about how to configure a SNAX, OSITP, or OSITPX domain gateway, see BEA eLink Documentation .

Parameters are generally specified by: KEYWORD = value; white space (space or tab character) is allowed on either side of the equal sign (=). This format sets KEYWORD to value. Valid keywords are described below within each section.

Lines beginning with the reserved word DEFAULT contain parameter specifications that apply to all lines that follow them in the section in which they appear. Default specifications can be used in all sections. They can appear more than once in the same section. The format for these lines is:

DEFAULT: [KEYWORD1 = value1 [KEYWORD2 = value2 [...]]]

The values set on this line remain in effect until reset by another DEFAULT line, or until the end of the section is reached. These values can also be overridden on non-DEFAULT lines by placing the optional parameter setting on the line. If on a non-DEFAULT line, the parameter setting is valid for that line only; lines that follow revert to the default setting. If DEFAULT appears on a line by itself, all previously set defaults are cleared and their values revert to the system defaults.

If a value is numeric, standard C notation is used to denote the base, that is, 0x prefix for base 16 (hexadecimal), 0 prefix for base 8 (octal), and no prefix for base 10 (decimal). The range of values acceptable for a numeric parameter are given under the description of that parameter.

If a value is an identifier (a string value already known to the BEA Tuxedo Domains component such as TDOMAIN for the TYPE parameter), standard C rules are typically used. A standard C identifier starts with an alphabetic character or underscore and contains only alphanumeric characters or underscores. The maximum allowable length of an identifier is 30 bytes (not including the terminating NULL).

There is no need to enclose an identifier in double quotes. A value that is neither an integer number nor an identifier must be enclosed in double quotes.

Input fields are separated by at least one space (or tab) character.

"#" introduces a comment. A newline ends a comment.

Blank lines and comments are ignored.

Comments can be freely attached to the end of any line.

Lines are continued by placing at least one tab after the newline. Comments cannot be continued.

Domains Terminology Improvements

For BEA Tuxedo release 7.1 or later, the Domains MIB uses improved class and attribute terminology to describe the interaction between local and remote domains. The improved terminology has been applied to the DMCONFIG(5) reference page, section names, parameter names, and error messages, and to the DM_MIB(5) reference page, classes, and error messages.

For backwards compatibility, aliases are provided between the DMCONFIG terminology used prior to BEA Tuxedo 7.1 and the improved Domains MIB terminology. For BEA Tuxedo release 7.1 or later, both versions of DMCONFIG terminology are accepted. The following table shows the mapping of the previous and improved terminology for the DMCONFIG file.

Previous Terminology

Improved Terminology

Section Name

Parameter Name

Section Name

Parameter Name




















For BEA Tuxedo release 7.1 or later, the dmunloadcf command generates by default a DMCONFIG file that uses the improved domains terminology. Use the -c option to print a DMCONFIG file that uses the previous domains terminology. For example:

prompt> dmunloadcf -c > dmconfig_prev


Skip navigation bar  Back to Top Previous Next