![]() |
![]() |
|
|
UBBCONFIG(5)
Name
UBBCONFIG—Text version of a BEA Tuxedo configuration file
Description
When a BEA Tuxedo application is booted, the tmboot command refers to a binary configuration file called TUXCONFIG to get the information necessary for starting application servers and initializing the bulletin boards in an orderly sequence. This binary file cannot be created directly; it must be created from a text file called UBBCONFIG. To configure an application, an administrator creates a UBBCONFIG file (with a text editor) and loads the file into a binary version (TUXCONFIG) by running the tmloadcf(1) command. During the life of the application, the TUXCONFIG file is used by various BEA Tuxedo administrative tools. tmadmin(1) uses the configuration file (or a copy of it) in its monitoring activity. tmshutdown(1) references the configuration file for information needed to shut the application down. For additional information pertaining to the entire UBBCONFIG file, see UBBCONFIG(5) Additional Information.
Definitions
A server is a process that accepts requests and sends replies for clients and other servers. A client originates requests and gets replies.
A resource manager is an interface and associated software providing access to a collection of information and/or processes. An example of a resource manager is a database management system; a resource manager instance is a particular instantiation of a database controlled by a DBMS. A distributed transaction is a transaction that spans multiple resource manager instances, is started with tpbegin(), and ended with tpcommit() or tpabort().
A server group is a resource manager instance and the collection of servers and/or services providing access to that resource manager instance on a particular machine. The XA interface associated with the group is used for transaction management. If a server does not access a resource manager instance or does not access it as part of a distributed transaction, it must be in a server group with a NULL XA interface. Similarly, clients run in a special client group that does not have to be specified in the GROUPS section. The client group is not associated with a resource manager.
A remote domain is defined to be an environment for which the bulletin board for this BEA Tuxedo system configuration is not available. Remote domains are not specified in the UBBCONFIG file, but rather through host-specific environment variables that are specified in host-specific reference pages.
Configuration File Format
A UBBCONFIG file is made up of nine possible specification sections. Lines beginning with an asterisk (*) indicate the beginning of a specification section. Each such line contains the name of the section immediately following the *. Allowable section names are: RESOURCES, MACHINES, GROUPS, NETGROUPS, NETWORK, SERVERS, SERVICES, INTERFACES, and ROUTING. The RESOURCES and MACHINES sections must be the first two sections and must be included in that order. The GROUPS section must precede the SERVERS, SERVICES, and ROUTING sections. The NETGROUPS section must precede the NETWORK section.
Parameters (except in the RESOURCES section) 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 within each section.
Lines beginning with the reserved word, DEFAULT:, contain parameter specifications that apply to any lines that follow them in the section in which they appear. Default specifications can be used in all sections other than the RESOURCES section. They can appear more than once in the same section. The format for these lines is:
DEFAULT: [optional KEYWORD=value pairs]
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 acceptable values for a numeric parameter is given under the description of that parameter.
If a value is an identifier (a string value already known to the BEA Tuxedo system such as APP_PW for the SECURITY 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 (not including the terminating NULL).
Note: 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. This value is a user-defined string. The maximum allowable length of a user-defined string is 78 characters (not including the terminating NULL). Exceptions to this rule are as follows:
In the RANGES parameter of the ROUTING section, certain special characters can be escaped inside a string using a backslash.
"\\" translates to a single backslash
"\"" translates to a double quote
"\n" translates to a newline
"\t" translates to a tab
"\f" translates to a formfeed
"\O+" translates to a character whose octal value is O+
where O+ is one, two, or three octal characters. "\0" translates to an embedded NULL character. "\xH+" or "\XH+" translates to a character whose hexadecimal value is H+ where H+ is one or more hexadecimal characters. "\y" (where 'y' is any character other than one of the previously mentioned characters) translates to 'y'; this produces a warning.
"#" (pound sign) introduces a comment. A newline ends a comment.
An identifier or a numeric constant must always be followed by white space (space or tab character), a newline character, or a punctuation character (pound sign, equals sign, asterisk, colon, comma, backslash, or period).
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.
RESOURCES Section
This section provides for user specification of the system-wide resources, such as the number of servers, and services which can exist within a service area. Lines in the RESOURCES section are of the form: KEYWORD value where KEYWORD is the name of the parameter, and value its associated value. Valid KEYWORDs are as follows:
Note: The SIGNAL notification method is not available for MS-DOS clients, and is not available for multithreaded or multicontexted clients.
MACHINES Section
The MACHINES section specifies the logical names for physical machines for the configuration. It also specifies parameters specific to a given machine. The MACHINES section must contain an entry for each physical processor used by the application. Entries have the form:
ADDRESS required_parameters [optional_parameters]
where ADDRESS is the physical name of a processor, for example, the value produced by the UNIX system uname -n command. On a Windows system, the value can be set using the Computer Name value in the Network Control Panel and must be specified in upper case. The length of the entire ADDRESS must be 30 characters or less. If the name is not an identifier, it must be enclosed in double quotes.
If the LAN option is not specified, only one machine name can appear in this section. One of the required KEYWORDs is LMID, which is the logical machine string_value assigned to the physical machine. An LMID string_value must be unique within the MACHINES section of the configuration file.
These parameters are required:
Note: The pathname specified for this parameter must match exactly (inlcuding case) the pathname specified for the TUXCONFIG environment variable. Otherwise, tmloadcf(1) cannot be run successfully.
Optional parameters are:
Note: Unlike the corresponding attribute in the SERVERS section, this parameter cannot take the string DEFAULT as a valid value.
GROUPS Section
This section provides information about server groups. This section must have at least one server group defined in it (which can be added via tmconfig, wtmconfig(1) after the TUXCONFIG file has been created). A server group entry provides a logical name for a collection of servers and/or services on a machine. The logical name is used as the value of the SRVGRP parameter in the SERVERS section to identify a server as part of this group. SRVGRP is also used in the SERVICES section to identify a particular instance of a service with its occurrences in the group. Other GROUPS parameters associate this group with a specific resource manager instance (for example, the employee database). Lines within the GROUPS section have the form:
GROUPNAME required_parameters [optional_parameters]
where GROUPNAME specifies the logical name (string_value) of the group. The group name must be unique within all group names in the GROUPS section and LMID values in the MACHINES section and cannot contain an asterisk (*), comma, or colon. It must be 30 characters or less.
Required parameters are:
Optional parameters are:
OPENINFO = "TUXEDO/QM:qmconfig:qspace"
OPENINFO = "TUXEDO/QM:qmconfig;qspace"
OPENINFO = "TUXEDO/QM:qmconfig;qspace"
OPENINFO = "TUXEDO/QM,[a.b.c]qmconfig,qspace"
Password for OPENINFO (SRVGRP=BANKB3):
password
NETGROUPS Section
The NETGROUPS section describes the network groups available to the application in the LAN environment. Any pair of machines may be in any number of network groups. Two communicating nodes use the priority mechanism in order to determine how to communicate between elements of its group.
Every LMID must be a member of the default network group, DEFAULTNET. Machines running BEA Tuxedo releases earlier than release 6.4 (in which NETGROUPS became available) can belong only to the DEFAULTNET network group. The network group number (NETGRPNO) for DEFAULTNET is 0 (zero), and may not be changed. The default priority of DEFAULTNET, however, may be modified.
The general format for entries in this section is:
NETGROUP required_parameters [optional_parameters]
where NETGROUP is the network group name. If NETGROUP is equal to DEFAULTNET then the entry describes the default network group.
Required parameters are:
Optional parameters are:
Note: Parallel data circuits are prioritized by network group number (NETGRPNO) within priority group number.
NETWORK Section
The NETWORK section describes the network configuration for a LAN environment. For each processor on which a bridge server is located, an entry must be placed in the NETWORK section giving the network address of the bridge process. An error is generated if this section exists and LAN is not specified for the OPTIONS parameter of the RESOURCES section.
The general format for entries in this section is:
LMID required_parameters [optional_parameters]
where LMID is the logical machine where the bridge process is placed. LMID must have direct access to the network device to be used (as given in the BRIDGE parameter).
Required parameters are:
"//#.#.#.#:port_number"
Note: Some port numbers may be reserved for the underlying transport protocols (such as TCP/IP) used by your system. Check the documentation for your transport protocols to find out which numbers, if any, are reserved on your system.
Optional parameters are:
Note: The link-level encryption value of 40 bits is provided for backward compatibility.
Note: The link-level encryption value of 40 bits is provided for backward compatibility.
SERVERS Section
This section provides information on the initial conditions for servers started in the system. The notion of a server as a process that continually runs and waits for a server group's service requests to process, may or may not apply to a particular remote environment. For many environments, the operating system or perhaps a remote gateway will be the sole dispatcher of services; when either of these is the case, only SERVICE table entries (see next section) and no SERVER table entries need be specified for remote program entry points; BEA Tuxedo system gateway servers would advertise and queue remote domain service requests. Host-specific reference pages must indicate whether or not UBBCONFIG server table entries apply in their particular environments, and if so, the corresponding semantics. Lines within the SERVERS section have the form:
AOUT required_parameters [optional_parameters]
where AOUT specifies the file (string_value) to be executed by tmboot(1). tmboot executes AOUT on the machine specified for the server group to which the server belongs. tmboot searches for the AOUT file on its target machine. Thus, AOUT must exist in a filesystem on that machine. (Of course, the path to AOUT can include RFS connections to filesystems on other machines.) If a relative pathname for a server is given, the search for AOUT is done first in APPDIR, then in TUXDIR/bin, then in /bin, and then in path> where path> is the value of the last PATH= line appearing in the machine environment file, if one exists. The values for APPDIR and TUXDIR are taken from the appropriate machine entry in the TUXCONFIG file. See ENVFILE in the MACHINES section for a more detailed discussion.
Required parameters are:
The optional parameters are divided into two categories: boot options and run-time options. Boot options are used by tmboot(1) when it executes a server. Once running, a server reads its entry from the configuration file to determine its run-time options. The unique server ID is used to find the right entry.
Optional boot parameters are:
Optional run-time parameters are:
SERVICES Section
This section provides information on services used by the application. Lines within the SERVICES section have the form:
SVCNM [optional_parameters]
where SVCNM is the (string_value) name of the service. SVCNM must be 15 characters or fewer in length.
There are no required parameters. Services need not be listed if no optional parameters need to be set. Optional parameters are:
BUFTYPE=VIEW:* implies that the service takes all subtypes
of FML views.
The following parameters are for DTP applications only:
The INTERFACES Section
This section provides information for defining application-wide default parameters for CORBA interfaces used by the application. There are no required parameters for CORBA interfaces unless you are implementing factory-based routing, a feature that allows you to distribute processing to specific server groups. If you are implementing factory-based routing, you must specify the following parameters:
In this section... |
You must specify... |
---|---|
INTERFACES |
|
ROUTING |
Routing criteria |
GROUPS |
Names of the server groups |
For details about factory-based routing and the parameters associated with it, see "ROUTING Section" after this section.
You do not need to list any CORBA interfaces if you do not want to specify any parameters.
The following optional parameters are available.
ROUTING Section
This section provides information for data-dependent routing of service requests using FML buffers, XML buffers, and views. The routing criteria specified here are used only if the default routing functions _froute, _xroute, and _vroute, are being used (see tuxtypes(5)). Lines within the ROUTING section have the form:
CRITERION_NAME required_parameters
where CRITERION_NAME is the (string_value) name of the routing entry that was specified on the services entry. CRITERION_NAME must be 15 characters or less in length.
Required parameters are:
FIELD="root_element[/child_element][/child_element][/. . .][/@attribute_name]"
An example of a routing entry is:
BRNCH FIELD=B_FLD RANGES="0-2:DBG1,3-5:DBG2,6-9:DBG3" BUFTYPE="FML"
which sends buffers with field B_FLD values 0-2 to server group DBG1, values 3-5 to server group DBG2, and values 6-9 to DBG3; no other values are allowed.
If the field value is not set (for FML buffers), or does not match any specific range and a wildcard range has not been specified, an error is returned to the application.
An example of a routing entry based on the XML element CODE is:
PRODUCT FIELD="ORDER/CODE" RANGES="'AAA' - 'FFF':DBG1, 'GGG-ZZZ':DBG2" BUFTYPE="XML"
Here, CODE is a child element of the root element ORDER.
A routing entry based on the attribute ORDERNO might look like the following example.
ORDER FIELD="ORDER/HEADER/@ORDERNO" FIELDTYPE=long RANGES="0-9999:DBG1,10000-MAX:DBG3" BUFTYPE="XML"
Here, ORDERNO is the attribute of the XML child element HEADER of the root element ORDER.
UBBCONFIG(5) Additional Information
Files
The TUXCONFIG and TUXOFFSET environment variables are used to find the TUXCONFIG configuration file on the MASTER machine.
Example
# The following configuration file defines a 2-site
# configuration with two machine types. Data dependent
# routing is used.
*RESOURCE
IPCKEY 80952 # key for well known address
DOMAINID My_Domain_Name
UID 4196 # user id for ipc structures
GID 601 # group id for ipc structures
PERM 0660 # permissions for ipc access
MAXSERVERS 20 # at most 20 simultaneous servers
MAXSERVICES 40 # offering at most 40 services
MAXGTT 20 # at most 20 simultaneous global transactions
MASTER SITE1
SCANUNIT 10
SANITYSCAN 12
BBLQUERY 180
BLOCKTIME 30
NOTIFY DIPIN
OPTIONS LAN,MIGRATE
SECURITY USER_AUTH
AUTHSVC AUTHSVC
MP # a multiprocessor based bulletin board
LDBAL Y # perform load balancing
#
*MACHINES
mach1 LMID=SITE1 TUXDIR="/usr4/tuxbin"
MAXACCESSERS=25
APPDIR="/usr2/apps/bank"
ENVFILE="/usr2/apps/bank/ENVFILE"
TLOGDEVICE="/usr2/apps/bank/TLOG" TLOGNAME=TLOG
TUXCONFIG="/usr2/apps/bank/tuxconfig" TYPE="3B2"
ULOGPFX="/usr2/apps/bank/ULOG"
SPINCOUNT=5
mach386 LMID=SITE2 TUXDIR="/usr5/tuxbin"
MAXACCESSERS=100
MAXWSCLIENTS=50
APPDIR="/usr4/apps/bank"
ENVFILE="/usr4/apps/bank/ENVFILE"
TLOGDEVICE="/usr4/apps/bank/TLOG" TLOGNAME=TLOG
TUXCONFIG="/usr4/apps/bank/tuxconfig" TYPE="386"
ULOGPFX="/usr4/apps/bank/ULOG"
#
*GROUPS
DEFAULT: TMSNAME=TMS_SQL TMSCOUNT=2
# For Windows, :bankdb: becomes ;bankdb;
BANKB1 LMID=SITE1 GRPNO=1
OPENINFO="TUXEDO/SQL:/usr2/apps/bank/bankdl1:bankdb:readwrite"
# For Windows, :bankdb: becomes ;bankdb;
BANKB2 LMID=SITE2 GRPNO=2
OPENINFO="TUXEDO/SQL:/usr4/apps/bank/bankdl2:bankdb:readwrite"
DEFAULT:
AUTHGRP LMID=SITE1 GRPNO=3
#
*NETWORK
SITE1 NADDR="mach1.80952" BRIDGE="/dev/starlan"
NLSADDR="mach1.serve"
#
SITE2 NADDR="mach386.80952" BRIDGE="/dev/starlan"
NLSADDR="mach386.serve"
*SERVERS
#
DEFAULT: RESTART=Y MAXGEN=5 REPLYQ=Y CLOPT="-A"
TLR SRVGRP=BANKB1 SRVID=1 RQADDR=tlr1
CLOPT="-A -- -T 100"
TLR SRVGRP=BANKB1 SRVID=2 RQADDR=tlr1
CLOPT="-A -- -T 200"
TLR SRVGRP=BANKB2 SRVID=3 RQADDR=tlr2
CLOPT="-A -- -T 600"
TLR SRVGRP=BANKB2 SRVID=4 RQADDR=tlr2
CLOPT="-A -- -T 700"
XFER SRVGRP=BANKB1 SRVID=5
XFER SRVGRP=BANKB2 SRVID=6
ACCT SRVGRP=BANKB1 SRVID=7
ACCT SRVGRP=BANKB2 SRVID=8
BAL SRVGRP=BANKB1 SRVID=9
BAL SRVGRP=BANKB2 SRVID=10
BTADD SRVGRP=BANKB1 SRVID=11
BTADD SRVGRP=BANKB2 SRVID=12
AUTHSVR SRVGRP=AUTHGRP SRVID=20 #
*SERVICES
DEFAULT: LOAD=50 AUTOTRAN=N
WITHDRAWAL PRIO=50 ROUTING=ACCOUNT_ID
DEPOSIT PRIO=50 ROUTING=ACCOUNT_ID
TRANSFER PRIO=50 ROUTING=ACCOUNT_ID
INQUIRY PRIO=50 ROUTING=ACCOUNT_ID
CLOSE_ACCT PRIO=40 ROUTING=ACCOUNT_ID
OPEN_ACCT PRIO=40 ROUTING=BRANCH_ID
BR_ADD PRIO=20 ROUTING=BRANCH_ID
TLR_ADD PRIO=20 ROUTING=BRANCH_ID
ABAL PRIO=30 ROUTING=b_id
TBAL PRIO=30 ROUTING=b_id
ABAL_BID PRIO=30 ROUTING=b_id
TBAL_BID PRIO=30 ROUTING=b_id SVCTIMEOUT=300
#
#
*ROUTING
ACCOUNT_ID FIELD=ACCOUNT_ID BUFTYPE="FML"
RANGES="MIN - 9999:*,10000-59999:BANKB1,60000-109999:BANKB2,*:*"
BRANCH_ID FIELD=BRANCH_ID BUFTYPE="FML"
RANGES="MIN - 0:*,1-5:BANKB1,6-10:BANKB2,*:*"
b_id FIELD=b_id BUFTYPE="VIEW:aud"
RANGES="MIN - 0:*,1-5:BANKB1,6-10:BANKB2,*:*"
Interoperability
In an interoperating application, the master site must be the latest release available. Parameter values for PMID (machine ADDRESS), LMID, TLOGNAME, group names, RQADDR, service names, and ROUTING (routing criteria names) must be identifiers (valid C identifiers that are not UBBCONFIG keywords) when multiple releases of the BEA Tuxedo system are interoperating with each other.
Network Addresses
Suppose the local machine on which the bridge is being run is using TCP/IP addressing and is named backus.company.com, with address 155.2.193.18. Further suppose that the port number at which the bridge should accept requests is 2334. Assume that port number 2334 has been added to the network services database under the name bankapp-naddr. The address could be represented in the following ways:
//155.2.193.18:bankapp-naddr//155.2.193.18:2334
//backus.company.com:bankapp-naddr
//backus.company.com:2334
0x0002091E9B02C112
The last of these representations is hexadecimal format. The 0002 is the first part of a TCP/IP address. The 091E is the port number 2334 translated into a hexadecimal number. After that each element of the IP address 155.2.193.1 is translated into a hexadecimal number. Thus the 155 becomes 9B, 2 becomes 02 and so on.
See Also
buildserver(1), tmadmin(1), tmboot(1), tmloadcf(1), tmshutdown(1), tmunloadcf(1), buffer(3c), tpinit(3c), servopts(5)
Setting Up a BEA Tuxedo Application
Administering a BEA Tuxedo Application at Run Time
Programming BEA Tuxedo ATMI Applications Using C
![]() |
![]() |
![]() |
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|