Re: [nv-l] Traps not converting to variables

[James Shanks <jshanks@us.ibm.com>]

Well, I don't know about your PMR but
since this trap also contains some variables which are textual strings,
perhaps Level 2 does not follow what you are saying.  Have you sent
them this exact example and explanation?  I'll bet not, so I'll bet
Level 2 is confused about what you are expecting to see.  
 But I can tell you for certain
that trapd will not resolve that enumeration on his own. 

In my opinion, if you are already sending
this event to TEC in a TEC ruleset which is passing the log message as
"msg", then the easiest thing to do, as I said earlier, is to
change the log message.
From this,
         
$E $G $S $# args: $*               (which
is the default)
to something like this
        $E
$5 from  $6 indicates an  spSensorStatus value of $1, where  noStatus(1),
 normal(2), highWarning(3),
highCritical(4), lowWarning(5),  
        lowCritical(6),
 sensorError(7). because the sensor level of $3 was exceeded; with
an actual value of $2.

If you really need all the variables
laid out as before, then you can shorten that message and  just add
$* like before.  Or change it however else you like. 

 I haven't  tried it, but
you could also experiment with the oid_to_label file and see whether it
can be made to provide the substitution you wanted originally, so that
the tarp message might be shorter.   I am not certain, but think that
nvserverd will get the same result as trapd does when he calls the trap
formatting routine if the oid_to_lable file defines the correct enumeration.
 But I like the full enumeration message myself because it gives the
operator a hint as to what the range of values is that we are talking about
and what else to expect from this agent.  

The inline ruleset and postzmsg would
work, but it's a very bad idea, since you should never do a command which
might not complete immediately in an inline action, lest you hang nvcorrd.
  Everything else would halt while that inline executes.   An
action node script would be a much better idea if that's what you prefer.


As an aside, you have to wonder why
the vendor chose to send the integer value in the trap in the first place,
since he's already sending additional text in the same trap.  It would
have been child's play to have sent the text value in the trap instead
of the integer value since they are already sending text.  Look like
it would only make the trap about 10 bytes longer at most.


James Shanks
Level 3 Support  for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group

"Christopher J Petrina" <cjp8@meadwestvaco.com>
Sent by: owner-nv-l@lists.us.ibm.com

10/04/2004 11:50 AM

Please respond to
nv-l

To	nv-l@lists.us.ibm.com
cc
Subject	Re: [nv-l] Traps not converting to variables

Currently I ahve a PMR open about this issue.  I sent Level 2 the
mib the mib2trap trap file and my trapd.conf.  It seems that I get
conflicting responses from them and here.  They are saying it works
fine on their systems.  They are receiving the textual equivalent
of the enum value.  Below is a short description of one of the traps
that I am seeing doing this. 

This is what the event looks like in the event window:

Thu Sep 30 14:53:07 2004 10.40.137.254   A sensorProbe 6 10 6 args:
 [1] akcp.sensorProbe.sensorProbeTraps.spSensorStatus.0 (Integer):
5 
 [2] akcp.sensorProbe.sensorProbeTraps.spSensorValue.0 (Integer): 75
 [3] sensorProbeTraps.spSensorLevelExceeded.0 (Integer): 75
 [4] akcp.sensorProbe.sensorProbeTraps.spSensorIndex.0 (Integer): 0
 [5] akcp.sensorProbe.sensorProbeTraps.spSensorName.0 (OctetString): Temperature1
 [6] sensorProbe.sensorProbeTraps.spSensorDescription.0 (OctetString):
Test Temp in Trudi's Lab 

2 - 6 are fine since the data they show are actual numeric values.  It
is the $1 arg of 5 that I would have expected to see be a textual name
of sensorStatus a value of 1 - 5.  in the trapd.conf it looks like
this: 

spTemperatureStatus {1.3.6.1.4.1.3854.1} 6 10 A 1 0 "Status Events"
$E $G $S $# args: $* 
EVENT_CLASS hhmsTemperatureStatus 
SDESC 
Temperature sensor trap 
EDESC 
-----------------------------------------------------------------------------------------------------------------------
The mib shows this: 
 spTemperatureStatus TRAP-TYPE 
                ENTERPRISE sensorProbe
                VARIABLES
                    
   { spSensorStatus, spSensorValue, spSensorLevelExceeded,
         spSensorIndex, spSensorName, spSensorDescription
} 
                DESCRIPTION
                    
   "Temperature sensor trap" 
                ::= 10
-----------------------------------------------------------------------------------------------------------------------
When it uses variables 
 spSensorStatus OBJECT-TYPE 
            SYNTAX  INTEGER {
               noStatus(1),
               normal(2),
               highWarning(3),
               highCritical(4),
               lowWarning(5),
               lowCritical(6),
               sensorError(7)

I figured that it would display the varaible name versus the actual integer.
  
If the integer is the correct value and that is all I am going to receive
what is the easiest way in anyones opinion to replace the integer with
a name.  Would something like an inline action help?   write
a script that receives the information then do some if then statements
to post it forward onto TEC via postzmsg?   
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service._______________________________________________________________

This electronic message contains information from MeadWestvaco
Corporation or subsidiary companies, which may be confidential,
privileged or otherwise protected from disclosure. The
information is intended to be used solely by the recipient(s)
named. If you are not an intended recipient, be aware that
any review, disclosure, copying, distribution or use of this
transmission or its contents is prohibited. If you have
received this transmission in error, please notify MeadWestvaco
immediately at postmaster@MeadWestvaco.com.
_______________________________________________________________________