Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	http://www.oracle.com/technology/documentation/index.html   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary
Tuxedo Doc Home   |   Administration   |   Topic List   |   Previous   |   Next   |   Contents

   Administering a BEA Tuxedo Application at Run Time

The first step in troubleshooting is determining problem areas. In most applications you must consider six possible sources of trouble:

• Application

• BEA Tuxedo system

• Database management software

• Network

• Operating system

• Hardware

Once you have determined the problem area, you must then work with the appropriate administrator to resolve the problem. If, for example, you determine that the trouble is caused by a networking problem, you must work with the network administrator.

The following steps will help you detect the source of an application failure.

1. Check any BEA Tuxedo system warnings and error messages in the user log (ULOG).

2. Select the messages you think most likely reflect the current problem. Note the catalog name and the number of each of message, so you can look up the message in BEA Tuxedo System Messages. The manual entry provides:

   • Details about the error condition indicated by the message

   • Recommendations for recovery actions

3. Check any application warnings and error messages in the ULOG.

4. Check any warnings and errors generated by application servers and clients. Such messages are usually sent to the standard output and standard error files (named, by default stdout and stderr, respectively).

   • The stdout and stderr files are located in the directory defined by the APPDIR variable.

   • The stdout and stderr files for your clients and servers may have been renamed. (You can rename the stdout and stderr files by specifying -e and -o in the appropriate client and server definitions in your configuration file. For details, see servopts(5) in BEA Tuxedo File Formats and Data Descriptions Reference.)

5. Look for any core dumps in the directory defined by the APPDIR.variable. Use a debugger such as dbx to get a stack trace. If you find core dumps, notify your application developer.

6. Check your system activity reports (for example, by running the sar(1) command) to determine why your system is not functioning properly. Consider the following reasons:

   • The system may be running out of memory.

   • The kernel might not be tuned correctly.

The following steps will help you detect the source of a system failure.

1. Check any BEA Tuxedo system warnings and error messages in the user log (ULOG):

   • TPEOS messages indicate errors in the operating system.

   • TPESYSTEM messages indicate errors in the BEA Tuxedo system.

2. Select the messages you think most likely reflect the current problem. Note the catalog name and number of each of message, so you can look up the message in BEA Tuxedo System Messages. The manual entry provides:

   • Details about the error condition flagged by the message

   • Recommendations for recovery actions

3. Prepare for debugging in the following ways:

   • Shut down the suspend service.

   • Use tmboot -n -s(server) -d1. (This will not boot the server, but prints the command line used to boot the server by the BEA Tuxedo system.) Use that command line with a debugger such as dbx.