Determining Types of Failures


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| PDF Files \| Contact \| Glossary

Tuxedo Documentation \| Administering a BEA Tuxedo Application at Run Time \| Local Topics \| Previous Topic \| Next Topic \| Contents

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.

How to Determine the Cause of an Application Failure

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

Check any BEA Tuxedo system warnings and error messages in the user log (ULOG).
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 System Messages. The manual entry provides:
- Details about the error condition indicated by the message
- Recommendations for recovery actions
Check any application warnings and error messages in the ULOG.
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 the File Formats, Data Descriptions, MIBs, and System Processes Reference.)
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.
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.

How to Determine the Cause of a BEA Tuxedo System Failure

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

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.
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 System Messages. The manual entry provides:
- Details about the error condition flagged by the message.
- Recommendations for recovery actions.
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.