About the Configuration File

e-docs > Tuxedo > Setting Up a Tuxedo Application > About the Configuration File

Setting Up a Tuxedo Application

About the Configuration File

This topic includes the following sections:

What Is the Configuration File?

Configuring each BEA Tuxedo application is a central task of the administrator. By configuring a file, you are describing your application using a set of parameters that the software interprets to create a viable application. The configuration file is a repository that contains all the information necessary to boot and run an application, such as specifications for application resources, machines, machine groups, servers, available services, interfaces, and so on.

Text and Binary Versions of the Configuration File

The configuration file exists in two versions:

The UBBCONFIG file is a text version of the configuration file, created and edited with any text editor. Except for sample configuration files distributed with BEA Tuxedo sample applications, no UBBCONFIG file is provided. You must create a UBBCONFIG file for each new application. The syntax used for entries in the file is described in UBBCONFIG(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference.

Note: The BEA Tuxedo software provides three sample UBBCONFIG files—ubbshm, ubbmp, and ubbsimple—as part of the bankapp and simpapp applications. (See Tutorials for Developing BEA Tuxedo ATMI Applications.)
The TUXCONFIG file is a binary version of the configuration file, created from the text version by the tmloadcf(1) command. Before tmloadcf is executed, the environment variable TUXCONFIG must be set to the full pathname of the device or system file where TUXCONFIG is to be loaded. If necessary, many parameters in TUXCONFIG can be changed while the application is running by using tmconfig, wtmconfig(1) or the MIB.

Contents of the Configuration File

The following table lists the nine sections of the configuration file and describes the purpose of each section.

Section	Required or Optional	Purpose
RESOURCES	Required	Defines all system parameters.
MACHINES	Required	Specifies all the machines in your application.
GROUPS	Required	Defines all groups, group names, and group IDs for your application.
SERVERS	Optional	Specifies the initial conditions for servers started in the system.
SERVICES	Optional	Provides information on services used by the application.
INTERFACES	Optional	For CORBA environments, provides information on application-wide, default parameters for interfaces used by the application.
NETWORK	Optional	Describes the network configuration for a LAN environment.
NETGROUPS	Optional	Describes the network groups available to the application in the LAN environment.
ROUTING	Optional	Provides information for data-dependent routing of service requests using FML buffers and views.

The file must also contain a minimum of nine parameters. There are 80 different parameters, and all sections but the first, may contain multiple entries, each with its own selection of parameters. In all sections other than RESOURCES, you can use a default to specify parameters that are included in multiple entries.

You can use the command-line interface or BEA Tuxedo Administration Console to create the binary version of the configuration file (TUXCONFIG). First you need to determine the type of configuration you are defining in the file.

A single-machine application—one or more local or remote clients communicate with one or more servers residing on the same machine.
A multiple-machine (distributed) application—one or more local or remote clients communicate with one or more servers residing on several machines.
A multiple-domain application—two or more applications communicate with each other through the use of the BEA Tuxedo Domains extension. Each application included in such a configuration is called a domain.

CORBA Administrative Requirements and Performance

This section provides information to assist you in administering your CORBA environment in the BEA Tuxedo system.

Configuring NameManager

Adhering to the following requirements is fundamental to successful CORBA administration.

NameManagers should coordinate their activities with each other using the BEA Tuxedo EventBroker without administrative or operations intervention. The EventBroker must be started before any servers provide the NameManager service. If the EventBroker is not configured into the application and is not running when the NameManager service is booted, the NameManager aborts its startup and writes an error message to the user log.
At least two servers must be configured to run the NameManager service as part of any application. This requirement is to ensure that a working copy of the "name-to-IOR" mapping is always available. If the servers are on different machines, and one machine crashes, when the machine and application are restarted, the new NameManager obtains the mapping from the other NameManager. If an application is solely contained on one machine and the machine crashes, the NameManagers are rebooted as part of the application startup because the application must be rebooted. If two NameManagers are not configured in the application when a NameManager service is booted, the NameManager aborts its startup and writes an error message to the user log.
NameManagers can be designated as either master or slave, the default being slave. If a master NameManager server is not configured in the application and is not running when a slave NameManager server starts, the server terminates itself during boot and writes an error message to the user log.
If a NameManager service is not configured in the application when a FactoryFinder service is booted, the FactoryFinder aborts its startup and writes an error message to the user log. It is not necessary for the NameManager service to start before a FactoryFinder service because the FactoryFinder only communicates with a NameManager when a "find" request is received from an application. NameManagers, on the other hand, attempt to communicate with each other when they boot. FactoryFinders do not communicate with each other except when a request is received to find a factory that is in a remote domain.
BEA Tuxedo EventBroker, NameManager, and FactoryFinder services must be started before any of the application-specific servers. However, if more than one EventBroker is to be configured in the application, all secondary EventBrokers must be started after all application servers are started. There is no system protocol to enforce this in an application server; therefore, you accomplish this by positioning all secondary EventBrokers after the application servers.
The Master NameManager must be started and must be running before any application server can register a reference to a factory object. The existence of an executing Slave NameManager is not sufficient.

Reliability Requirements

This section contains information that will improve CORBA reliability.

Managing Factory Entries

When application servers "die," they often fail to unregister their factories with the NameManager. In some cases, the FactoryFinder may give out object references for factories that are no longer active. This occurs because the servers containing those factories have become unavailable, have failed to unregister their factories with the NameManager, and there is no other server capable of servicing the interface for that factory.

In general, an application factory can restart shortly thereafter, and then offer the factories. However, to ensure that factory entries are not kept indefinitely, the NameManager is notified when application servers die. Upon receipt of this notification, the NameManager may remove those factory entries that are not supported in any currently active server.

Configuring Multiple NameManagers and FactoryFinders

At a minimum, two NameManagers, a master and a slave, must be configured in an application, preferably on different machines, to provide querying capabilities for a FactoryFinder. Multiple FactoryFinders can also be configured in an application.

Designating a Master NameManager

A Master NameManager must be designated in the UBBCONFIG file. All registration activities are sent to the Master NameManager. The Master NameManager then notifies the Slave NameManagers about the updates. If the Master NameManager is down, registration/unregistration of factories is disabled until the Master restarts.

Performance Hint

You can optimize FactoryFinder and NameManager performance by running these services on separate servers within the same machine rather than running these services on different machines. This provides a quicker response because it eliminates the need for machine-to-machine communication.