Oracle Tuxedo Management Tools

4.1 Oracle Tuxedo Tool Architecture

As shown in the following figure, the Oracle Tuxedo administration processes used to manage an Oracle Tuxedo application encompass a variety of tools constructed around the Oracle Tuxedo management information base (MIB).

Figure 4-1 Tools to Administer Your Oracle Tuxedo Application

The Oracle Tuxedo MIB contains all the information necessary for the operation of an Oracle Tuxedo application. It contains the TM_MIB, which is common to all applications, and the following component MIBs, each of which describes a subsystem of the Oracle Tuxedo system:

WS_MIB—used to manage Workstation groups and processes associated with them
ACL_MIB—used to administer access control lists (ACLs)
APPQ_MIB—used to administer application stable-storage queues
EVENT_MIB—used to control event notification and the subscription request database
DM_MIB—used to administer an Oracle Tuxedo Domains (multiple-domain) configuration

The MIB reference pages (TM_MIB(5), generic reference page MIB(5)) are defined in BEA Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference.

Parent topic: Oracle Tuxedo Management Tools

4.1.1 Tool Interfaces with the MIB

The Oracle Tuxedo administration tools, briefly described in the following list, provide different types of interfaces to the MIB:

Command-line utilities—a set of commands used to activate, deactivate, configure, and manage an Oracle Tuxedo application.
Oracle Tuxedo MIB application programming interface—a set of functions for accessing and modifying information in the MIB.
EventBroker—an Oracle Tuxedo component that provides asynchronous routing of application events among the client and server processes running in an Oracle Tuxedo application, and distributes system events—typically faults or exceptional happenings—to whichever application processes want to receive them.

Parent topic: Oracle Tuxedo Tool Architecture

4.1.2 MIB Interfaces with Other System Components

The MIB accesses the following Oracle Tuxedo system components:

TUXCONFIG file—binary version of an Oracle Tuxedo application’s configuration (UBBCONFIG) file. Every server machine in an Oracle Tuxedo application stores a copy of the TUXCONFIG file. The MIB updates the TUXCONFIG file and reads information from the TUXCONFIG file.
Bulletin board—a memory segment in which all the configuration and dynamic processing information for an Oracle Tuxedo application is held at run time. Every server machine in an Oracle Tuxedo application has a bulletin board. The MIB updates the bulletin board and reads information from the bulletin board.
ULOG (no cross-reference in original document)—a user log file in which Oracle Tuxedo system and application messages—error messages, warning messages, information messages, and debugging messages—are stored. Every server machine in an Oracle Tuxedo application should have a ULOG. The MIB gathers information from the ULOG.
TLOG—a transaction log file in which records of committed global transactions are stored. Every server machine in an Oracle Tuxedo application should have a TLOG. The MIB gathers information from the TLOG.

Parent topic: Oracle Tuxedo Tool Architecture

4.2 Managing Operations Using the MIB

The Oracle Tuxedo MIB is used to administer an Oracle Tuxedo application. It defines the parts of an application that are required in every Oracle Tuxedo domain. MIB defines an Oracle Tuxedo application as a set of classes (for example, servers, groups, machines, domains), each of which is made up of objects that are characterized by various attributes (for example, identity and state).

When an Oracle Tuxedo server machine becomes active, it advertises the names of its services in the bulletin board (BB), which is the run-time (dynamic) representation of the MIB. (The bulletin board is where global and local state changes to the MIB are posted.) The Oracle Tuxedo system uses the binary TUXCONFIG file on the master machine to construct the bulletin board, and propagates a copy of the TUXCONFIG to the non-master machines in the application to set up the bulletin board on those machines. A bulletin board runs on each server machine in an Oracle Tuxedo application.

The following figure presents a high-level view of Oracle Tuxedo MIB operation.

Figure 4-2 High-Level View of Oracle Tuxedo MIB Operation

Parent topic: Oracle Tuxedo Management Tools

4.2.1 AdminAPI

The AdminAPI is an application programming interface for directly accessing and manipulating system settings in the Oracle Tuxedo MIB. You can use the AdminAPI to automate administrative tasks, such as monitoring log files and dynamically reconfiguring an application, thus eliminating the need for human intervention. This advantage can be crucially important in mission-critical, real-time applications. Using the MIB programming interface, you can manage operations in the Oracle Tuxedo system easily. Specifically, you can monitor, configure, and tune your application through your own programs. The MIB can be defined as:

An implementation-independent management database defined as a set of Field Manipulation Language (FML) attributes
A programming interface that enables you to query the Oracle Tuxedo system (that is, to obtain information from the system through a get operation) or to update the Oracle Tuxedo system (that is, to change information in the system through a set operation) at any time using a set of ATMI functions. Examples of these functions include tpalloc, tprealloc, tpgetrply, tpcall, tpacall, tpenqueue, and tpdequeue.

Parent topic: Managing Operations Using the MIB

4.2.2 Types of MIB Users

The MIB defines three types of users: system (or application) administrators, system operators, and others. The following table describes each type

Type of User	Characteristics
System (or application) administrator	Person responsible for keeping an application running successfully. The administrator is authorized to use all administrative tools and all MIB administrative capabilities. The administrator configures, manages, and modifies a running production application.
System operator	Person responsible for monitoring and reacting to the daily operation of a production application. An operator monitors statistics about a running application, sometimes reacting to events and alerts by taking actions such as booting servers or shutting down machines. An operator does not reconfigure an application, add servers or machines, or delete machines.
Other	People or processes (such as custom programs) that may need to read the MIB but are not authorized to change the application.

Parent topic: Managing Operations Using the MIB

4.2.3 Classes, Attributes, and States in the MIB

Classes are the types of entities such as servers and machines that make up an Oracle Tuxedo application. Attributes are characteristics of the objects in a class: identity, state, configuration parameters, run-time statistics, and so on. There are a number of attributes that are common to MIB operations and replies and common to individual classes. Every class has a state attribute that indicates the state of the object.

Independent of classes is a set of common attributes that are defined in the MIB(5)reference page. These attributes control the input operations, communicate to the MIB what the user is trying to do, and/or identify to the programmer some of the characteristics of the output buffer that are independent of a particular class.

4.3 Managing Operations Using Command-Line Utilities

Oracle Tuxedo provides a set of commands for managing different parts of an application built on the Oracle Tuxedo system. The commands enable you to access common administrative utilities. These utilities can be used for the following tasks:

Parent topic: Oracle Tuxedo Management Tools

4.3.1 Configuring Your Application Using Command-Line Utilities

You can configure your application by using command-line utilities. Specifically, you can use a text editor to create and edit the configuration file (UBBCONFIG) for your application, and then use the command-line utility named tmloadcf to translate the text file (UBBCONFIG) to a binary file (TUXCONFIG). You are then ready to boot your application.

The following list identifies common command-line utilities that you can use to configure your application:

tmloadcf(1)—a command, run on the master machine, that allows you to compile your application’s UBBCONFIG file into the binary TUXCONFIG file. The tmloadcf command loads the binary file to the location defined by the TUXCONFIG environment variable.
tmunloadcf(1)—a command, run on the master machine, that allows you to translate the binary TUXCONFIG file back to a text version, so that the UBBCONFIG and TUXCONFIG files can be synchronized. The tmunloadcf command prints the text version to standard output.

Note:
:Dynamically updating the binary TUXCONFIG file does not update the text UBBCONFIG file.
tpusradd(1), tpusrdel(1), tpusrmod(1)—a set of commands that allow you to create and manage a user database for authorization purposes.
tpgrpadd(1), tpgrpdel(1), tpgrpmod(1)—a set of commands that allow you to create and manage user groups by using access control lists to authorize access to services, queues, and events.
tpacladd(1), tpaclcvt(1), tpacldel(1), and tpaclmod(1)—a set of commands that allow you to create or manage access control lists for applications. These commands enable the use of security-related authorization features.

Parent topic: Managing Operations Using Command-Line Utilities

4.3.2 Operating Your Application Using Command-Line Utilities

After you have configured your application successfully, you can use the following command-line utilities to operate your application:

tmboot(1)—a command, run on the master machine, that allows you to centrally start up your application servers. The tmboot command reads the TUXCONFIG environment variable to locate your application’s TUXCONFIG file. The tmboot command loads TUXCONFIG into shared memory to establish the bulletin board, propagating the changes to the remote server machines in a multiple-machine domain.
tmadmin(1)—an interactive meta-command, typically run on the master machine, that enables you to run subcommands to configure, monitor, and tune your application. You can use the tmadmin command before your application is booted (in configuration mode) or when your application is running.
tmconfig(1)—another interactive meta-command, typically run on the master machine, that enables you to run subcommands to configure, monitor, and tune your application. You can use the tmconfig command only when your application is running. The tmconfig command is more powerful but less user friendly than the tmadmin command.
tmshutdown(1)—a command, run on the master machine, that allows you to centrally shut down your application servers. The tmshutdown command reads the TUXCONFIG environment variable to locate your application’s TUXCONFIG file.

Parent topic: Managing Operations Using Command-Line Utilities

4.3.3 Administering Your Application Queues Using Command-Line Utilities

You use the command-line utility qmadmin(1) to perform all administration functions for the application queues in your application. Like the tmadmin and tmconfig commands, qmadmin is an interactive meta-command that enables you to run many subcommands.

In an Oracle Tuxedo application, you can have multiple application queue devices, and you can run application queues on multiple server machines. Each machine has its own queue device, so you can run qmadmin to monitor and manage a particular application queue device on each server machine.

Parent topic: Managing Operations Using Command-Line Utilities

4.3.4 Administering Your Domains Application Using Command-Line Utilities

To build an Oracle Tuxedo Domains (multiple-domain) application, you integrate your existing Oracle Tuxedo application with other domains. To do so, you must add a domain gateway group of system servers (DMADM, GWADM, and GWTDOMAIN) to your UBBCONFIG file. These servers are described in Oracle Tuxedo Domains (Multiple-Domain) Servers.

All domains configuration information for an Oracle Tuxedo application involved in a Domains configuration is stored in a file known as DMCONFIG. Similar to the UBBCONFIG file, the DMCONFIG file may have any name as long as the content of the file conforms to the format described on reference page DMCONFIG(5) in Oracle Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference. You use a text editor to create and edit the DMCONFIG file, and then use the command-line utility named dmloadcf to translate the text file (DMCONFIG) to a binary file (BDMCONFIG). The BDMCONFIG file must reside on the machine that will run the DMADM server.

Note:

The DMADM server may run on any machine (master machine, non-master machine) in an Oracle Tuxedo domain. The following list identifies the command-line utilities that you can use to configure and operate the domain gateway group of system servers for an Oracle Tuxedo application involved in a Domains configuration:

dmloadcf(1)—a command, run on the same machine as the DMADM server, that allows you to compile an application’s DMCONFIG file into the binary BDMCONFIG file. The dmloadcf command loads the binary file to the location defined by the BDMCONFIG environment variable.
dmunloadcf(1)—a command, run on the same machine as the DMADM server, that allows you to translate the binary BDMCONFIG file back to a text version, so that the DMCONFIG and BDMCONFIG files can be synchronized. The dmunloadcf command prints the text version to standard output.

Note:
Dynamically updating the binary BDMCONFIG file does not update the text DMCONFIG file.
dmadmin(1)—an interactive meta-command, typically run on the same machine as the DMADM server, that enables you to run subcommands to configure, monitor, and tune domain gateway groups. You can use the dmadmin command before your application is booted (in configuration mode) or when your application is running.

4.4 Managing Events Using EventBroker

An event is a state change or other occurrence in an application program or the Oracle Tuxedo system that may be of interest to an administrator, an operator, or the software. Examples of events are “a stock traded at or above a specified price” or “a network failure occurred.”

Oracle Tuxedo EventBroker provides asynchronous routing of application and system events among the processes running in an Oracle Tuxedo ATMI application. Application events are occurrences of application-defined events. System events are occurrences of system-defined events.

Parent topic: Oracle Tuxedo Management Tools

4.4.1 Differences Between Application-Defined and System-Defined Events

Application-defined events are defined by application designers and are therefore application specific. Any of the events defined for an application may be tracked by the client and server processes running in the application.

System-defined events are defined by the Oracle Tuxedo system code and are generally associated with objects defined in TM_MIB(5). A complete list of system-defined events is published on the EVENTS(5) reference page in BEA Tuxedo File Formats, Data Descriptions, MIBs, and System Processes Reference. Any of these events may be tracked by users of the Oracle Tuxedo system.

Parent topic: Managing Events Using EventBroker

4.4.2 Preparing an Application for Event Monitoring

The following table presents the basic tasks for preparing an Oracle Tuxedo application for event monitoring:

Task Description

1. Decide which events to monitor Application programs are written to (a) detect when an event of interest has occurred and (b) post the event to the EventBroker through tppost(3c). Application designers decide which events should be monitored. For system events, application designers select system-defined events from the EVENTS(5) reference page.

2. Create an events list

Task	Description
1. Decide which events to monitor	Application programs are written to (a) detect when an event of interest has occurred and (b) post the event to the EventBroker through `tppost(3c)`. Application designers decide which events should be monitored. For system events, application designers select system-defined events from the EVENTS(5) reference page.
2. Create an events list	A list of the application event subscriptions is made available to interested users, just as the Oracle Tuxedo system provides a list of system events available to users with EVENTS(5). System-defined event names begin with a dot (.); application-defined event names may not begin with a dot (.) To prepare an application-defined events list, application designers should consult the EVENTS(5), `TMUSREVT(5)`, `TMSYSEVT(5)`, and `field_tables(5)` reference pages. To prepare an application-defined events list, application designers should consult the EVENTS(5), `TMUSREVT(5)`, `TMSYSEVT(5)`, and `field_tables(5)` reference pages.

A list of the application event subscriptions is made available to interested users, just as the Oracle Tuxedo system provides a list of system events available to users with EVENTS(5). System-defined event names begin with a dot (.); application-defined event names may not begin with a dot (.)

To prepare an application-defined events list, application designers should consult the EVENTS(5), TMUSREVT(5), TMSYSEVT(5), and field_tables(5) reference pages. To prepare an application-defined events list, application designers should consult the EVENTS(5), TMUSREVT(5), TMSYSEVT(5), and field_tables(5) reference pages.

Parent topic: Managing Events Using EventBroker

4.4.3 Subscribing to Events

As the administrator for your Oracle Tuxedo application, you can enter subscription requests on behalf of a client or server process by making calls to tpsubscribe(3c) using the published list of application-defined or system-defined events. EVENTS(5)lists the notification message generated by a system event as well as the event name (used as an argument when tppost(3c) is called). Subscribers can use the wildcard capability of regular expressions to make a single call to tpsubscribe that covers a whole category of events.

Each subscription for a system-defined event specifies one of several notification methods. One such method is placing messages in the ULOG: using the T_EVENT_USERLOG class of EVENT_MIB, subscribers can write system USERLOG messages. When events are detected and matched, they are written to the ULOG.

The EventBroker recognizes over 100 meaningful state transitions in a MIB object as system events. The postings for system events include the current MIB representation of the object on which the event has occurred.