System and Application Softwares
How to Read Tuxedo User Log (ULOG)?
The user log (ULOG) is a file to which all messages generated by the BEA Tuxedo system—error messages, warning messages, information messages, and debugging messages—are written. Application clients and servers can also write to the user log. A new log is created every day and there can be a different log on each machine. However, a ULOG can be shared by multiple machines when a remote file system is being used.
The ULOG provides an administrator with a record of system events from which the causes of most BEA Tuxedo system and application failures can be determined. You can view the ULOG, a text file, with any text editor. The ULOG also contains messages generated by the tlisten process. The tlisten process provides remote service connections for other machines in an application. Each machine, including the master machine, should have a tlisten process running on it.
The ULOG provides a central repository in which the BEA Tuxedo system and applications can store error information and simplifies the job of finding errors returned by the BEA Tuxedo ATMI.
A ULOG message consists of a tag and text. The tag consists of the following:
The text consists of the following:
The following message are some examples in the ULOG:
162214.mach1!security.23451.1.0: Unknown User 'abc'
162214.mach1!security.23451.1.0: LIBSEC_CAT: 999: Unknown User 'abc'
162214.mach1!security.23451.1.0: gtrid x2 x24e1b803 x239: Unknown User 'abc'
You can use the information in the ULOG to identify the cause of system or application failures. Multiple messages about a given problem can be placed in the user log. Generally, earlier messages provide more useful diagnostic information than later messages.
In the following example, message 358 from the LIBTUX_CAT catalog identifies the cause of the trouble reported in subsequent messages, namely, that there are not enough UNIX system semaphores to boot the application.
151550.gumby!BBL.28041.1.0: LIBTUX_CAT:262: std main starting
151550.gumby!BBL.28041.1.0: LIBTUX_CAT:358: reached UNIX limit on semaphore ids
151550.gumby!BBL.28041.1.0: LIBTUX_CAT:248: fatal: system init function ...
151550.gumby!BBL.28040.1.0: CMDTUX_CAT:825: Process BBL at SITE1 failed ...
151550.gumby!BBL.28040.1.0: WARNING: No BBL available on site SITE1.
Will not attempt to boot server processes on that site.
The ULOG is created by the BEA TUXEDO system whenever one of the following events occurs:
When a message is written to the ULOG through the tperrno global variable, application clients and servers are notified, as follows:
BEA Tuxedo system errors indicate problems at the system level, rather than at the application level. When BEA Tuxedo system errors occur, the system writes messages explaining the exact nature of the errors to the central event log (ULOG), and returns TPESYSTEM in tperrno (12). Because these errors occur in the system, rather than in the application, you may need to consult the system administrator to correct them.
By default, the user log is called ULOG.mmddyy (where mmddyy represents the date in terms of month, day, and year) and it is created in the $APPDIR directory. You can place this file in any location, however, by setting the ULOGPFX parameter in the MACHINES section of the UBBCONFIG file.
The BEA Tuxedo system uses the tperrno variable to supply information to a process when a function fails. All ATMI functions that normally return an integer or pointer return -1 or NULL, respectively, on error and set tperrno to a value that describes the nature of the error. When a function does not return to its caller, as in the case of tpreturn() or tpforward(), which are used to terminate a service routine, the only way the system can communicate success or failure is through the variable tperrno in the requester.
The tperrordetail() and tpstrerrordetail() functions can be used to obtain additional detail about an error in the most recent BEA Tuxedo system call on the current thread. tperrordetail() returns an integer (with an associated symbolic name) which is then used as an argument to tpstrerrordetail() to retrieve a pointer to a string that contains the error message. The pointer can then be used as an argument to userlog() or fprintf().
The codes returned in tperrno represent categories of errors, which are listed in the following table.
BEA Tuxedo system1
TPELIMIT and TPEBADDESC
TPESVCFAIL, TPESVCERR, TPEBLOCK, and TPGOTSIG
TPEHAZARD2 and TPEHEURISTIC2
Typed buffer mismatch
TPEITYPE and TPEOTYPE
1. Applicable to all ATMI functions for which failure is reported by the value returned in tperrno.
2. Refer to Fatal Transaction Errors for more information on this error category.
As footnote 1 shows, four categories of errors are reported by tperrno(5) and are applicable to all ATMI functions. The remaining categories are used only for specific ATMI functions.The following sections describe some error categories in detail.
In the atmi.h, you can find the definitions of the tperrno values:
* tperrno values - error codes
* The man pages explain the context in which the following error codes
* can return.
#define TPMINVAL 0 /* minimum error message */
#define TPEABORT 1
#define TPEBADDESC 2
#define TPEBLOCK 3
#define TPEINVAL 4
#define TPELIMIT 5
#define TPENOENT 6
#define TPEOS 7
#define TPEPERM 8
#define TPEPROTO 9
#define TPESVCERR 10
#define TPESVCFAIL 11
#define TPESYSTEM 12
#define TPETIME 13
#define TPETRAN 14
#define TPGOTSIG 15
#define TPERMERR 16
#define TPEITYPE 17
#define TPEOTYPE 18
#define TPERELEASE 19
#define TPEHAZARD 20
#define TPEHEURISTIC 21
#define TPEEVENT 22
#define TPEMATCH 23
#define TPEDIAGNOSTIC 24
#define TPEMIB 25
#define TPMAXVAL 26 /* maximum error message */
Invalid arguments were given (for example, svc is NULL or flags are invalid).
Cannot send to svc because it does not exist, or it is a conversational service, or the name provided begins with a dot (.).\
The type and subtype of idata is not one of the allowed types and subtypes that svc accepts.
Either the type and subtype of the reply are not known to the caller; or, TPNOCHANGE was set in flags and the type and subtype of *odata do not match the type and subtype of the reply sent by the service. Neither *odata, its contents, nor *olen is changed. If the service request was made on behalf of the caller's current transaction, then the transaction is marked abort-only since the reply is discarded.
svc belongs to a server that does not support transactions and TPNOTRAN was not set.
This error code indicates that either a timeout has occurred or tpcall() has been attempted, in spite of the fact that the current transaction is already marked rollback only. If the caller is in transaction mode, then either the transaction is already rollback only or a transaction timeout has occurred. The transaction is marked abort-only. If the caller is not in transaction mode, a blocking timeout has occurred. (A blocking timeout cannot occur if TPNOBLOCK and/or TPNOTIME is specified.) In either case, no changes are made to *odata, its contents, or *olen. If a transaction timeout has occurred, then, with one exception, any attempts to send new requests or receive outstanding replies will fail with TPETIME until the transaction has been aborted. The exception is a request that does not block, expects no reply, and is not sent on behalf of the caller's transaction (that is, tpacall() with TPNOTRAN, TPNOBLOCK, and TPNOREPLY set). When a service fails inside a transaction, the transaction is put into the TX_ROLLBACK_ONLY state. This state is treated, for most purposes, as though it were equivalent to a timeout. All further ATMI calls for this transaction (with the exception of those issued in the circumstances described in the previous paragraph) will fail with TPETIME.
The service routine sending the caller's reply called tpreturn() with TPFAIL. This is an application-level failure. The contents of the service's reply, if one was sent, is available in the buffer pointed to by *odata. If the service request was made on behalf of the caller's current transaction, then the transaction is marked abort-only. Note that regardless of whether the transaction has timed out, the only valid communications before the transaction is aborted are calls to tpacall() with TPNOREPLY, TPNOTRAN, and TPNOBLOCK set.
A service routine encountered an error either in tpreturn(3c) or tpforward(3c) (for example, bad arguments were passed). No reply data is returned when this error occurs (that is, neither *odata, its contents, nor *olen is changed). If the service request was made on behalf of the caller's transaction (that is, TPNOTRAN was not set), then the transaction is marked abort-only. Note that regardless of whether the transaction has timed out, the only valid communications before the transaction is aborted are calls to tpacall() with TPNOREPLY, TPNOTRAN, and TPNOBLOCK set. If either SVCTIMEOUT in the UBBCONFIG file or TA_SVCTIMEOUT in the TM_MIB is non-zero, TPESVCERR is returned when a service timeout occurs.
A blocking condition was found on the send call and TPNOBLOCK was specified.
A signal was received and TPSIGRSTRT was not specified.
A library routine was called in an improper context. For example, tpcall() was called improperly.
Protocol errors occur when an ATMI function is invoked, either in the wrong order or using an incorrect process. For example, a client may try to begin communicating with a server before joining the application. Or tpcommit() may be called by a transaction participant instead of the initiator.
You can correct a protocol error at the application level by enforcing the rules of order and proper usage of ATMI calls.
To determine the cause of a protocol error, answer the following questions:
A BEA Tuxedo system error has occurred. The exact nature of the error is written to a log file.
An operating system error has occurred. If a message queue on a remote location is filled, TPEOS may be returned even if tpcall() returned successfully.
The first step in troubleshooting is determining problem areas. In most applications you must consider six possible sources of trouble:
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.
The following steps will help you detect the source of a system failure.
© 2020 Digcode.com. All rights reserved.