wtdumprl for Non-Tivoliers

I have noticed on a few of the message boards that there are a lot of new first time TEC users. New companies that are using Tivoli products for the first time because of ITM 6.1 seem to be struggling a little with TEC. I decided to put a short overview of the wtdumprl command.

I use the wtdumprl command to see if an event has arrived at the TEC server. The typical scenario is you have setup ITM 6.1 to monitor a system or application and the events show up on the TEP console. However, you don't see the event on the TEC console. The first command you should use to troubleshoot this is probably the wtdumprl. The wtdumprl command dumps all events in TEC reception log. There are two primary tables where events are stored in the TEC database. The first one is called the Event Repository (ER). The ER is where all of your permanent events are kept. The ER is what you see from the TEC console. The second area is a table that keeps a log of all events received by the TEC server and it is called the Reception Log (RL). This table is usually cleared out every couple of days or so. The RL is very useful for troubleshooting because it is how you can tell if your event has been received and processed by TEC. If you can't find your event in the RL then the event never made it to the TEC server. In which case you need to check to see if the event is cached at the adapter or the adapters EIF configuration (i.e. server location and server port are configured correctly). A simple way to check if your event is in the RL is to do the following command:

wtdumprl | grep

for example,

wtdumprl | grep ITM_NT_Process

Some events can be received by the TEC server but not processed (i.e., they don't parse correctly). In the TEC architecture all event classes, attributes, and attribute data types must be predefined to TEC before they can be parsed and processed. These definitions are found in the BAROC files. If an event is not defined in TEC or an attribute or attribute data type doesn't match what TEC has loaded from its rule base you will get a PARSING_FAILED status in the RL for that event.

If you find the event in the reception log then you need to check for the PARSING_FAILED status to see if the event has been parsed. On most TEC systems a lot of events are processed by the TEC reception engine and it is sometimes hard to find events by scrolling through the wtdumprl command output. What I often do is dump the output of the command into a file. Then I can do a find in the file for my specific event and check the status.

For example,

wtdumprl -f /tmp/events.out

If the file is two big (to many events in your RL) you can use optional parameters of the wtdumprl command to get the last 100 events in descending order as follows:

wtdumprl -f /tmp/events.out -o DESC -m 500

The two primary statuses you should look for in the RL for are, PROCESSED and PARSING_FAILED. If you get a PROCESSED for an event's status then your event has been sent to the TEC server and has been processed. If this is the case then your adapter (e.g., ITM 6.1) is sending events just fine and it's a problem on the TEC side and not a problem with ITM. If the event is PROCESSED and still doesn't show up on the TEC console you need to look at the TEC rules to see it if the event is getting dropped (e.g., run a rules trace) or look at your event group filters defined for your console. Note, a custom event group called All with no filters should be created so that an administrator can display all TEC events in the ER without being filtered. Below is an example or an event that has been processed by the TEC server.

2\886\"65537\"1121336503(Jul 14 06:21:43 2005)