Troubleshooting a Problem on Tivoli Enterprise Console to a IBM Tivoli Business Systems Manager Connection

If something goes wrong and the object is not shown at the IBM Tivoli Business Systems Manager console, we have to analyze the source of the failure:

1. First, check whether the conditions have been met to cause an alert at the endpoints where the monitors have been distributed. For DM classic, we use wlseng -l <enpoint_name>, and for IBM Tivoli Monitoring or DM Advanced Edition, we use wdmlseng -e <endpoint_name> -verbose.
2. If these monitors fire correctly and the network communications within the Tivoli Management Region are working, the next step for this event is to check the TEC. When TEC receives a recognized event, it is parsed by the rules engine. The rule that will parse and act upon classic DM events and send them to IBM Tivoli Business Systems Manager is ihstdmon.rls.
3. The wtdumprl command is used to display all received events and their disposition, whether they are processed or get a parsing failed status. When parsing fails, it means that either the class is not defined or there is an unknown slot (field) or an unparsable slot.
4. The wtdumptr command is used to display the completion of the action invoked from the TEC rules for an event. For example, the completion code of invoking the event enablement exits.
5. If the received event matches the profile of an event that has been slated to be sent to IBM Tivoli Business Systems Manager, a TEC exit ihstztec is invoked. This exit also is invoked when there is a change of status of this event to ACK or CLOSE. Again, we confirm this from the rule trace, if you have enabled the rule tracing from the EventServer setting.
6. If you examine the trace of the rules, you will see the event that matches the condition that you want and then the ihstztec exit is invoked. This formats the data and passes it onto the ITBSM Event Enablement service. This in turn sends this event to the Agent Listener. We have seen the usage of wtdumprl, wtdumptr, and the tracing of the rule base that has been used to show the data flow from within TEC. The most common problem you will see from the wtdumprl is that of an unprocessed event. If this is the case, check the classes (BAROC files) whose addition may have been missed. The most useful trace is that of the rule base, as you may have made a syntax error with the customization of a rule.
7. The Event Enablement engine itself also keeps log files. Four log files, two for the task server and two for event enablement, are available in the $BINDIR/TDS/EventService/log directory. You need to start tracing for event enablement to get meaningful information in the log file. Run the trace using the tserver ee_utility -t command. To format these log files, we use the ihszfmt command, which is located in the $BINDIR/TDS/EventService/bin subdirectory.
8. The next part of the data flow we examine is that of the Agent Listener. Verify that the Agent Listener is connected to the event enablement with the gemeeconfig command.
9. The next point to check is the Agent Listener log file. The amount of information logged in the log file depends on the loglevel, which can be set in the Windows registry. When the loglevel is set to 0, everything will be traced. The default loglevel setting is 2. The file is named AL + Timestamp of creation, so the file AL200211141427.log is the Agent Listener log that is created on 14 November 2002, at 14:27.