Tracking Down Ambiguous Tuxedo/Oracle Errors

White Paper Sections

• Tracking down ambiguous Tuxedo/Oracle errors
• Oracle RM/TMS integration errors

Run - Fizzle, boom, bang, crash!

So, you have just completed coding and compiling an Embedded SQL service. You've built an Oracle transaction manager according to the instructions, and you've specified what you hope to be a correct OPENINFO string in the *GROUPS section of the ubbconfig file.

You eagerly boot your application and run ud32 to test your service. You expect to see wonderful and magical things but all you get back is an Oracle error; "Not connected" or "Not logged on".

These two errors confuse even experienced Tuxedo developers, especially when SQL code has been copied from one service to another and other SQL services seem to be working just fine. These two errors, and several other Oracle errors, are simply trying to indicate that you have committed some sort of protocol faux pas.

The Oracle -1012 "Not logged on" error does not really mean that you are "not logged on". In fact, you will find that the tpopen() function call has succeeded and the OPENINFO string is correct. What this error means is that the service is trying to access the Oracle session without a global transaction ID. That is, you did not begin a transaction. You must explicitly begin a transaction using tpbegin() or implicitly begin a transaction by specifying the AUTOTRAN=Y flag for the service in the ubbconfig file. Remember, any time you access a resource manager that is under the control of a transaction manager, you must first begin a transaction.

Sometimes, the design of the application requires that a service be called as a participant (not initiator) of a transaction. In this case, the service should explicitly check the transaction state by calling the tpgetlev() function. If the service is called outside the bounds of a transaction, then the SQL statements must not be executed and a more human friendly error message should be returned to the requestor.

Return to Top of Page

Oracle RM/TMS integration errors

The Oracle "Not connected" error usually means that the OPENINFO string is incorrect and that the server process was unable to establish a connection, or that an established connection has been destroyed. Oracle has published the requirements for the OPENINFO string, however this information is sometimes hard to find.

See the Oracle technical reference manual for detailed information on the components of the OPENINFO string. This information is also documented in white papers that can be found at http://www.aurorainfo.com/wp.htm.

Any time you encounter an Oracle error that you suspect might be related to the RM/TMS integration, you should follow these steps to track down the cause.

1. Check the Oracle sqlnet logs for an indication of the problem. One of the options in the OPENINFO string is LogDir. If you leave the default of LogDir=. then you will have to search for the log in your $APPDIR directory.
2. Check for the existence of the Tdevice/TLOG (see crdl and crlog in tmadmin).
3. Be sure the Oracle Distributed Option and transaction views are installed. Check for the existance of the V$XATRANS$ view and check that all permissions have been granted to the appropriate users.
   (see $ORACLE_HOME/rdbms/admin/xaviews.sql)
4. Be sure that a transaction is started, either with tpbegin() or AUTOTRAN=Y in the *SERVICES section of the ubbconfig file.
5. Ensure that tpopen() is called in the tpsvrinit() function. Be sure you check the return code for all tp* function calls including tpopen().
6. Be sure the OPENINFO string is set appropriately in the *GROUPS section. Does tpopen() return an error code?
7. Check the Oracle libraries in the RM file and be sure that the Oracle TMS has been built correctly.
8. Bring in a consultant to review your code and configuration.

So, you have just completed coding and compiling an Embedded SQL service. You've built an Oracle transaction manager according to the instructions, and you've specified a correct OPENINFO string in the *GROUPS section of the ubbconfig file.

You eagerly boot your application and run ud32 to test your service. You expect to see wonderful and magical things and you are not disappointed.

~end of Aurora Information Systems' White Paper Series #6
  "Tracking Down Ambiguous Tuxedo/Oracle Errors"~

Return to Top of Page

Do you find this information interesting? Consider employment with Aurora!

Do you need help implementing your Middleware app? Aurora can make your life easier.