File Formats, Data Descriptions, MIBs, and System Processes Reference
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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.
# Using USER_AUTH
*RESOURCES
SECURITY USER_AUTH
AUTHSVC AUTHSVC
*SERVERS
AUTHSVR SRVGRP="AUTH" CLOPT="-A -- -f /usr/tuxedo/users" \
SRVID=100 RESTART=Y GRACE=0 MAXGEN=2
#
#
# Using ACLs
*RESOURCES
SECURITY ACL
AUTHSVC ..AUTHSVC
*SERVERS
AUTHSVR SRVGRP="AUTH" SRVID=100 RESTART=Y GRACE=0 MAXGEN=2
#
#
# Using a custom authentication service
*RESOURCES
SECURITY USER_AUTH
AUTHSVC KERBEROS
*SERVERS
KERBEROSSVR SRVGRP="AUTH1" SRVID=100 RESTART=Y GRACE=0 MAXGEN=2
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.
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
.
The following environment variables should be set and exported:
Then you must first set and export the following environment variables . . . |
|
---|---|
|
|
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.
Note: More information about options for servers can be found on the servopts(5)
reference page.
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"
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.
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.
The following environment variables should be set and exported when running an application that uses FML.
The following environment variables should be set and exported when executing viewc
.
buildclient(1), buildserver(1), viewc, viewc32(1)
(1),
ccmc
(1) in a UNIX system reference manual
DMADM
—Domains administrative server
DMADM SRVGRP = "
identifier
"
SRVID = "number
"
REPLYQ = "N
"
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.
#
*GROUPS
DMADMGRP LMID=mach1 GRPNO=1
gwgrp LMID=mach1 GRPNO=2
#
*SERVERS
DMADM SRVGRP="DMADMGRP" SRVID=1001 REPLYQ=N RESTART=Y GRACE=0
GWADM SRVGRP="gwgrp" SRVID=1002 REPLYQ=N RESTART=Y GRACE=0
GWTDOMAIN SRVGRP="gwgrp" SRVID=1003 RQADDR="gwgrp" REPLYQ=Y RESTART=Y MIN=1 MAX=1
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.
The DMCONFIG
file is made up of the following specification sections:
DM_LOCAL_DOMAINS
)DM_REMOTE_DOMAINS
)DM_LOCAL_SERVICES
)DM_REMOTE_SERVICES
)TDOMAIN
)DM_
dom
, where dom
may be any of the following sections for other domain gateway types: SNACRM
, SNASTACKS
, SNALINKS
, OSITP
, OSITPX
.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.
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.
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:
![]() ![]() |
![]() |
![]() |