Usage

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

Portability

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

Examples

# 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

See Also

Setting Up a BEA Tuxedo Application

Administering a BEA Tuxedo Application at Run Time

Programming a BEA Tuxedo ATMI Application Using C

compilation(5)

Name

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

Description

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:

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:

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.

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.

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

See Also

DMADM(5)

Name

DMADM—Domains administrative server

Synopsis

DMADM SRVGRP = "identifier"
SRVID = "number" 
REPLYQ = "N"

Description

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.

Portability

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

Interoperability

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.

Examples

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

See Also

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(5)

Name

DMCONFIG—Text version of a Domains configuration file

Description

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.

Definitions

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.

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.

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