|Subject:||Re: [nv-l] what is tivoli class definition?|
|From:||James Shanks <email@example.com>|
|Date:||Tue, 9 Sep 2003 18:27:00 -0400|
|Delivered-to:||mailing list firstname.lastname@example.org|
|Delivery-date:||Tue, 09 Sep 2003 23:26:48 +0100|
|Mailing-list:||contact email@example.com; run by ezmlm|
I don't wish to offend anyone, but I cannot comment on this without an observation.
Your customer sounds like someone who has had a bad experience in some way in the past and now wants to vent his anger and frustration. Unless you get an answer as to what his real problem was, or is, you probably won't be able to satisfy him. I'd say he already has another product in mind and is looking for an excuse not use NetView and TEC. In my opinion, there is a lot of smoke in his objections, without much substance, but some would say that I am biased.
What he is talking about is forwarding events to TEC. Apparently he doesn't like the fact that TEC arranges events in classes. But the proper response to that is that determining a class hierarchy allows TEC to treat events as objects, and provides the same advantages that C++ has over C for the person writing TEC rules. The underlying engine doesn't care about the details. You only have to give it the proper class and it will work the same on all instances of the class.
But furthermore, I think he is mistaken in much of what he says. For the most part, almost all vendors do define their traps in MIBs and you can compile them. I challenge him to provide you (me) a MIB that we cannot compile well-enough to define the trap. Further more MIBs are not necessary at all. If a trap is not formatted, then the "not found" message will tell you exactly what came in, how many variables and what values were delivered. Everything you need to configure the trap is there. If the vendor doesn't use a MIB, then he will have to provide textual documentation somewhere to explain what his trap means, and you can easily embody that in the trapd.conf definition.
Also, I think he is confused about the difference between the NetView TEC adapters and the Tivoli stand-alone SNMP adapter. In the UNIX product for example, all traps sent to NetView which are not given their own unique class, will be give the TEC base class automatically, either "Nvserverd_Event" or "TEC_ITS_BASE". In either case, they will format and display just fine over in TEC. No further definition is required unless the user want to use a new class of his own design.
In the Windows product, it is more difficult, because you have to configure the tecad_nv6k.oid file and tecad_nv6k.cds file, as well as the tecad_nv6k.conf file to get your event sent to TEC, but that is not all that difficult, and you have plenty of examples to guide you. In Windows there is no automatic assignment of events to a default class, so you have to do it yourself. What you have to do is examine the baroc files (which define classes) already in use over in TEC and decide whether to use what is there or define a new class. You customer make it sound as if this is quite difficult. But it is trivial. For any arbitrary class ABC, you simply code up a file which says
TEC_CLASS : ABC ISA EVENT
If you have new fields you want to include you put them between the braces in the DEFINES clause. Otherwise you just send over any of the 23 base fields that define an EVENT in TEC and all will be well. Once you import your class definition (your baroc file) into the TEC rulebase, you can start doing all sorts of magical things with it -- like determine who should see the event, how long it should remain on the console, when it should be removed, and soon. That's why there are classes.
PS: It's a lot easier to demonstrate this than to explain it.
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
I got a Tivoli Netview 7.1.3. One of our customers has the following
requirement about tivoli class definitions. The documentation on netview
does not seem to have anything about tivoli class definitions. Could you
help me understand what he is talking about?
Thanks a bunch
Vendors that boast the use of SNMP to send alerts into Tivoli must describe
how events are to be mapped into Tivoli. The standard Tivoli SNMP interface
does not have a MIB compiler and needs a "class definition" for each type of
message that will be sent and translated into Tivoli. Many vendors do not
document their SNMP traps. MIBs are not always useful and may not compile
under Openview or Netview either. Logfiles have another set of problems. If
messages cannot be easily translated into a handful of Tivoli class
definitions we are unlikely to find the product friendly or acceptable.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [nv-l] what is tivoli class definition?, Stephen Hochstetler|
|Next by Date:||Re: [nv-l] SNMPv3 & netview/AIX, Helder Garcia|
|Previous by Thread:||Re: [nv-l] what is tivoli class definition?, Stephen Hochstetler|
|Next by Thread:||[nv-l] Launching CiscoView from Netview Web Console, Meyos Yemveng|
|Indexes:||[Date] [Thread] [Top] [All Lists]|
Archive operated by Skills 1st Ltd
See also: The NetView Web