#
# Original Created by xnmtrap at Mon May 11 15:52:58 1998 by clv
# IPMM distributed FILE
#
#  Property of Electronic Data Systems, Inc.
#  EDS Limited Distribution.
##########################################################################
#
# Modification Log:
#
# Date     Name            Description
# -------  --------------  -----------------------------------------------
# 19July99 M. McLeod       Converted to netview and added event classes
#                          for TEC 
##########################################################################

###################
#
# enterprises:
#
###################
#
# display categories:
#
CATEGORY 0 "Threshold Events"
CATEGORY 1 "Network Topology Events"
CATEGORY 2 "Error Events"
CATEGORY 3 "Status Events"
CATEGORY 4 "Node Configuration Events"
CATEGORY 5 "Application Alert Events"
CATEGORY 6 "All Category Events"
CATEGORY 7 "Log Only Events"
CATEGORY 8 "Map Events"
CATEGORY 9 "Ignore Events"
CATEGORY 10 "SMARTS Root Causes"
###################
#
# Operator Actions:
#
ACTION 20 "Print Events" /usr/OV/bin/printEvents
SDESC
Print events to printer with title and some filtering.
EDESC
ACTION 20 "Print Events with Topology Information" /usr/OV/bin/printEvents -s
SDESC
Print events to printer with topology information for every
event hostname.
EDESC
ACTION 0 "Browse MIB" /usr/OV/bin/xnmbrowser -node "`awk '{if (NR==1)print $10}'`
SDESC
Bring up the SNMP MIB browser, on the hostname selected from the
list of indicated events.
EDESC
ACTION 20 "Sort Events by Severity" /usr/OV/bin/sortEvents -s
SDESC
Sort the events based on severity, and passes them to a dialog in
which you may do further sorting or printing.
EDESC
ACTION 20 "Sort Events by Hostname" /usr/OV/bin/sortEvents -n
SDESC
Sort the events based on Hostname of the event, and passes them to a dialog in
which you may do further sorting or printing.
EDESC
ACTION 20 "Sort Events by Message" /usr/OV/bin/sortEvents -m
SDESC
Sort the events based on the message string, and passes them to a dialog in
which you may do further sorting or printing.
EDESC
ACTION 20 "Sort Events by Hostname Frequency" /usr/OV/bin/freqSortEvnt -s
SDESC
Sort the events based on frequency of event hostname.
This is useful to find out which hostname sends the most events.
EDESC
ACTION 20 "Sort Events by Event Frequency" /usr/OV/bin/freqSortEvnt -e
SDESC
Sort the events based on frequency of event type.
This is useful to find out type of event is most frequently sent.
EDESC
ACTION 20 "Sort Events by Hostname and Event Frequency" /usr/OV/bin/freqSortEvnt -c
SDESC
Sort the events based on frequency of the combination of event type
and hostname.  This is useful to find out which event and hostname
combination is the most common.
EDESC
###################
#
# enterprises:
#
SMARTS {1.3.6.1.4.1.733}
#
# User added trap formats:
#

SM_IPIf-Unavailable {1.3.6.1.4.1.733} 6 100100 a 4 0 "SMARTS Root Causes"
InCharge: $2
EVENT_CLASS SM_IPIf-Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
This is a root cause which may explain other related events.

The event contains the following varbinds:
   1) Selection name of the IP interface
   2) Description text
   3) Selection name of the node containing the interface
EDESC
SM_PhIf-Unavailable {1.3.6.1.4.1.733} 6 100200 a 4 0 "SMARTS Root Causes"
InCharge: $2
EVENT_CLASS SM_PhIf-Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
This is a root cause which may explain other related events.

Physical interfaces are not directly manageable by OpenView so
this notification will contain the selection name of the enclosing
node and a reference to the physical interface specified either as
a description (ifDesc) or as an interface number if the description
is not available.

The event contains the following varbinds:
   1) Selection name of the node containing the interface
   2) Description text
   3) Physical interface description or number
EDESC
SM_PhIf-Flapping {1.3.6.1.4.1.733} 6 100201 a 4 0 "SMARTS Root Causes"
InCharge: $2
EVENT_CLASS SM_PhIf-Flapping
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
The status of the interface goes from up to down within a flapping
interval which may represent some intermitent line conditions.

Physical interfaces are not directly manageable by OpenView so this
notification will contain the selection name of the enclosing node
and a reference to the physical interface specified either as a 
description (ifDescr) or as an interface number if the description
is not available.

The event contains the following varbinds:
   1) Selection name of the node containing the interface
   2) Description text
   3) Physical interface description or number
EDESC
SM_Host-Unavailable {1.3.6.1.4.1.733} 6 100300 a 4 0 "SMARTS Root Causes"
InCharge: $2
EVENT_CLASS SM_Host-Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
This is a root cause which indentifies the given host as an independent
point of failure which can not be explained by other interface/router
failures.  Usually either the host is down or it is disconnected from 
the network.

The event contains the following varbinds:
   1) Selection name of the host
   2) Description text
EDESC
SM_MCard-Unavailable {1.3.6.1.4.1.733} 6 100400 a 4 0 "SMARTS Root Causes"
InCharge: $2
EVENT_CLASS SM_MCard-Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
This is a root cause which identifies the given management card as a 
point of failure which can not be explained by other interface/router
failures.  Normally this failure represents a failure of a dumb hub
or a switch which don't provide physical topology information. This
event doesn't occur if the switch or hub have other managed nodes
connected to it.  In this case, the segment which represents this
hub will be reported as unavailable.

The event contains the following varbinds:
   1) Selection name of the hub/switch
   2) Description text
EDESC
SM_Router-Unavailable {1.3.6.1.4.1.733} 6 100500 a 4 0 "SMARTS Root Causes"
InCharge: $2
EVENT_CLASS SM_Router-Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
This is a root cause which indentifies the given router as an independent
point of failure which can not be explained by other interface/router
failures.  Usually either the router is down or it is disconnected from
the network.  This event may suppress many NetView failures if the 
router leads to a network containing managed nodes/interfaces.

The event contains the following varbinds:
   1) Selection name of the router
   2) Description text
EDESC
SM_Hub-Unavailable {1.3.6.1.4.1.733} 6 100600 a 4 0 "SMARTS Root Causes"
InCharge: $2
EVENT_CLASS SM_Hub-Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
This is a root cause which identifies the given hub as an independent 
point of failure which can not be explained by other interface/router/hub
failures.  Usually either the hub is down or it is disconnected from the
network.  This event may suppress many NetView failures if this hub
connects other managed nodes/interfaces.  It occurs only if the hub is
smart, i.e. provides the physical topology which can be discovered by
NetView or specified from some alternative topology source.  Otherwise,
the segment which represents this hub will be notified as unavailable.

This event contains the following varbinds:
   1) Selection name of the hub
   2) Description text
EDESC
SM_Switch-Unavailable {1.3.6.1.4.1.733} 6 100700 a 4 0 "SMARTS Root Causes"
InCharge: $2
EVENT_CLASS SM_Switch-Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
This is a root cause which identifies the given switch as an independent 
point of failure which can not be explained by other interface/router/hub
failures.  Usually either the switch is down or it is disconnected from the
network.  This event may suppress many NetView failures if this switch
connects other managed nodes/interfaces.  It occurs only if the switch is
smart, i.e. provides the physical topology which can be discovered by
NetView or specified from some alternative topology source.  Otherwise,
the segment which represents this switch will be notified as unavailable.

This event contains the following varbinds:
   1) Selection name of the switch
   2) Description text
EDESC
SM_Seg-Unavailable {1.3.6.1.4.1.733} 6 100800 a 4 0 "SMARTS Root Causes"
InCharge: $2
EVENT_CLASS SM_Seg-Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
This is a root cause which identifies the given segment as an independent 
point of failure which can not be explained by other interface/router/hub/switch
failures.  Usually it represents a failure of a dumb hub/switch.  In this
case the physical topology is unavailable and the hub/switch can not be
correctly identified.  The other possible reason is a frame relay switch
failure if this segment connects multiple frame relay interfaces.
This event may suppress many NetView failures if this segment
connects other managed nodes/interfaces.  

This event contains the following varbinds:
   1) Selection name of the segment
   2) Description text
EDESC
SM_Part-Unavailable {1.3.6.1.4.1.733} 6 100900 a 4 0 "SMARTS Root Causes"
InCharge: $2
EVENT_CLASS SM_Part-Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
Partition failures are usually explained by failures of some router/interfaces
which lead to some part of the network but are not managed by NetView.
Instead of notifying all nodes/interfaces behind the failure router as
unavailable, InCharge gives only this notification.  Please read 
"IPFM User's Guide" which describes how to identify this unknown failed
element.

This event contains the following varbinds:
   1) Selection name of the partition
   2) Description text
EDESC
SM_Control-Topofix {1.3.6.1.4.1.733} 6 101000 a 4 0 "SMARTS Root Causes"
InCharge: $2
EVENT_CLASS SM_Control-Topofix
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
ovtopofix has been executed
 
This utility updates the topology database which may cause massive
topology changes. InCharge server restart is strongly recommended
otherwise inconsistent correlation results may occur.
 
The event contains the following varbinds:
        1) Selection name of the NNM server which runs InCharge
        2) Description text
EDESC
SM_Control-TopChange {1.3.6.1.4.1.733} 6 101001 a 4 0 "SMARTS Root Causes"
InCharge: $2
EVENT_CLASS SM_Control-TopChange
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
Major topology change has occured (a whole network has been renumbered
or a switch has been replaced).
 
InCharge server restart is strongly recommended
otherwise inconsistent correlation results may occur.
 
The event contains the following varbinds:
        1) Selection name of the NNM server which runs InCharge
        2) Description text
EDESC
SM_Control-NoResponse {1.3.6.1.4.1.733} 6 101002 a 4 0 "SMARTS Root Causes"
InCharge: $2
EVENT_CLASS SM_Control-NoResponse
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
InCharge adapter is not responding. Either the adapter which has been
started as a separate process has exited or the load on the server is
too high. Check the adapter status by running
 
ovstatus sm_ipfm
 
and if this event doesn't clear in 5-10 minutes restart it.
 
The event contains the following varbinds:
        1) Selection name of the NNM server which runs InCharge
        2) Description text
EDESC
SM_IPIf+Unavailable {1.3.6.1.4.1.733} 6 200100 a 0 0 "SMARTS Root Causes"
InCharge: Cleared: $2
EVENT_CLASS SM_IPIf+Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
The condition specified below has been cleared.  It does not necessarily
mean that the underlying problem has been fixed.  It may mean that 
InCharge provides a better root cause (for example, a failing router may
explain earlier host failures which will be cleared).

This event contains the following varbinds:
   1) Selection name of the IP interface
   2) Description text
   3) Selction name of the node containing the interface
EDESC
SM_PhIf+Unavailable {1.3.6.1.4.1.733} 6 200200 a 0 0 "SMARTS Root Causes"
InCharge: Cleared: $2
EVENT_CLASS SM_PhIf+Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
The condition specified below has been cleared.  It does not necessarily
mean that the underlying problem has been fixed.  It may mean that 
InCharge provides a better root cause (for example, a failing router may
explain earlier host failures which will be cleared).

Physical interfaces are not directly manageable by NetView so this 
notification will contain the selection name of the enclosing
node and a reference to the physical interface specified either
as a description (ifDescr) or as an interface number if the description
is not available.
This event contains the following varbinds:
   1) Selection name of the node containing the interface
   2) Description text
   3) Physical interface description or number
EDESC
SM_PhIf+Disconnected {1.3.6.1.4.1.733} 6 200201 a 0 0 "SMARTS Root Causes"
InCharge: Cleared: $2
EVENT_CLASS SM_PhIf+Disconnected
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
The condition specified below has been cleared. It does not necessarily mean
that the underlying problem has been fixed. It may mean that InCharge provides
a better root cause (for example, a failing router may explain earlier host
failures which will be cleared).
 
Physical Interface is disconnected from its port or a connection point.
 
This event represents the topology inconsistency which may be explained
by the partially discovered topology or partially managed nodes or
interfaces (a node is managed while some of its interfaces are not).
InCharge server restart is strongly recommended. If the problem persists,
try to manage the enclosing node again and poll the switch/hub connecting
this interface (Fault->Network Connectivity->Poll).
 
Physical interfaces are not directly manageable by NetView so
this notification will contain the selection name of the enclosing
node and a reference to the physical interface specified either as
a description (ifDescr) or as an interface number if the description
is not available.

The event contains the following varbinds:
        1) Selection name of the node containing the interface
        2) Description text
        3) Physical interface description or number
EDESC
SM_Host+Unavailable {1.3.6.1.4.1.733} 6 200300 a 0 0 "SMARTS Root Causes"
InCharge: Cleared: $2
EVENT_CLASS SM_Host+Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
The condition specified below has been cleared. It does not necessarily mean
that the underlying problem has been fixed. It may mean that InCharge provides
a better root cause (for example, a failing router may explain earlier host
failures which will be cleared).
 
Host is unavailable
 
This is a root cause which identifies the given host as an independent
point of failure which can not be explained by other interface/router
failures. Usually either the host is down or it is disconnected from the
network.
 
The event contains the following varbinds:
        1) Selection name of the host
        2) Description text
EDESC
SM_MCard+Unavailable {1.3.6.1.4.1.733} 6 200400 a 0 0 "SMARTS Root Causes"
InCharge: Cleared: $2
EVENT_CLASS SM_MCard+Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
The condition specified below has been cleared. It does not necessarily mean
that the underlying problem has been fixed. It may mean that InCharge provides
a better root cause (for example, a failing router may explain earlier host
failures which will be cleared).
 
Management card is unavailble
 
This is a root cause which identifies the given management card as a
point of failure which can not be explained by other interface/router
failures.  Normally this failure represents a failure of a dumb hub or
a switch which don't provide physical topology information. This event
doesn't occur if the switch or hub have other managed nodes connected to
it. In this case the segment which represents this hub will be reported
as unavailble.

The event contains the following varbinds:
        1) Selection name of the hub/switch
        2) Description text
EDESC
SM_Router+Unavailable {1.3.6.1.4.1.733} 6 200500 a 0 0 "SMARTS Root Causes"
InCharge: Cleared: $2
EVENT_CLASS SM_Router+Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
he condition specified below has been cleared. It does not necessarily mean
that the underlying problem has been fixed. It may mean that InCharge provides
a better root cause (for example, a failing router may explain earlier host
failures which will be cleared).
 
Router is unavailable
 
This is a root cause which identifies the given router as an independent
point of failure which can not be explained by other interface/router
failures. Usually either the router is down or it is disconnected from the
network. This event my suppress many NetView failures if this router leads
to a network containing managed nodes/interfaces.
 
The event contains the following varbinds:
        1) Selection name of the router
        2) Description text
EDESC
SM_Hub+Unavailable {1.3.6.1.4.1.733} 6 200600 a 0 0 "SMARTS Root Causes"
InCharge: Cleared: $2
EVENT_CLASS SM_Hub+Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
The condition specified below has been cleared. It does not necessarily mean
that the underlying problem has been fixed. It may mean that InCharge provides
a better root cause (for example, a failing router may explain earlier host
failures which will be cleared).
 
Hub is unavailable
 
This is a root cause which identifies the given hub as an independent
point of failure which can not be explained by other interface/router/hub
failures. Usually either the hub is down or it is disconnected from the
network. This event my suppress many NetView failures if this hub connects
other managed nodes/interfaces. It occurs only if the hub is smart, i.e.
provides the physical topology which can be dicovered by NetView or
specified from some alternative topology source. Otherwise, the segment
which represents this hub will be notified as unavailable.
 
The event contains the following varbinds:
        1) Selection name of the hub
        2) Description text
EDESC
SM_Switch+Unavailable {1.3.6.1.4.1.733} 6 200700 a 0 0 "SMARTS Root Causes"
InCharge: Cleared: $2
EVENT_CLASS SM_Switch+Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
The condition specified below has been cleared. It does not necessarily mean
that the underlying problem has been fixed. It may mean that InCharge provides
a better root cause (for example, a failing router may explain earlier host
failures which will be cleared).
 
Switch is unavailable
 
This is a root cause which identifies the given switch as an independent
point of failure which can not be explained by other interface/router/hub/switch
failures. Usually either the switch is down or it is disconnected from the
network. This event my suppress many NetView failures if this switch connects
other managed nodes/interfaces. It occurs only if the switch is smart, i.e.
provides the physical topology which can be dicovered by NetView or
specified from some alternative topology source. Otherwise, the segment
which represents this switch will be notified as unavailable.
 
The event contains the following varbinds:
        1) Selection name of the switch
        2) Description text
EDESC
SM_Seg+Unavailable {1.3.6.1.4.1.733} 6 200800 a 0 0 "SMARTS Root Causes"
InCharge: Cleared: $2
EVENT_CLASS SM_Seg+Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
The condition specified below has been cleared. It does not necessarily mean
that the underlying problem has been fixed. It may mean that InCharge provides
a better root cause (for example, a failing router may explain earlier host
failures which will be cleared).
 
Segment is unavailable
 
This is a root cause which identifies the given segment as an independent
point of failure which can not be explained by other interface/router/hub/switch
failures. Usually it represents a failure of a dumb hub/switch. In this
case the physical topology is unavailable and the hub/switch can not be correctl
y
identified.  The other possible reason is a frame relay switch failure is this
segment connects multiple frame relay interfaces.
This event my suppress many NetView failures if this segment connects
other managed nodes/interfaces.
 
The event contains the following varbinds:
        1) Selection name of the segment
        2) Description text
EDESC
SM_Part+Unavailable {1.3.6.1.4.1.733} 6 200900 a 0 0 "SMARTS Root Causes"
InCharge: Cleared: $2
EVENT_CLASS SM_Part+Unavailable
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
The condition specified below has been cleared. It does not necessarily mean
that the underlying problem has been fixed. It may mean that InCharge provides
a better root cause (for example, a failing router may explain earlier host
failures which will be cleared).
 
Partition is unavailable
 
Partition failures are usually explained by failures of some router/interfaces
which lead to some part of the network but are not manageable by NetView.
Instead of notifying all nodes/interfaces behind the failed router as
unavailable, InCharge gives only this notification. Please read "IPFM User's Gui
de"
which describes how to identify this unknown failed element.
 
The event contains the following varbinds:
        1) Name of the partition
        2) Description text
EDESC
SM_Control+Topofix {1.3.6.1.4.1.733} 6 201000 a 0 0 "SMARTS Root Causes"
InCharge: Cleared: $2
EVENT_CLASS SM_Control+Topofix
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
The condition specified below has been cleared. It does not necessarily mean
that the underlying problem has been fixed. It may mean that InCharge provides
a better root cause (for example, a failing router may explain earlier host
failures which will be cleared).
 
ovtopofix has been executed
 
This utility updates the topology database which may cause massive
topology changes. InCharge server restart is strongly recommended
otherwise inconsistent correlation results may occur.
 
The event contains the following varbinds:
        1) Selection name of the NNM server which runs InCharge
        2) Description text
EDESC
SM_Control+NoResponse {1.3.6.1.4.1.733} 6 201002 a 0 0 "SMARTS Root Causes"
InCharge: Cleared: $2
EVENT_CLASS SM_Control+NoResponse
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
The condition specified below has been cleared. It does not necessarily mean
that the underlying problem has been fixed. It may mean that InCharge provides
a better root cause (for example, a failing router may explain earlier host
failures which will be cleared).
 
InCharge adapter is not responding. Either the adapter which has been
started as a separate process has exited or the load on the server is
too high. Check the adapter status by running
 
ovstatus sm_ipfm
 
and if this event doesn't clear in 5-10 minutes restart it.
 
The event contains the following varbinds:
        1) Selection name of the NNM server which runs InCharge
        2) Description text
EDESC
SM_Control+TopChange {1.3.6.1.4.1.733} 6 201001 a 0 0 "SMARTS Root Causes"
InCharge: Cleared: $2
EVENT_CLASS SM_Control+TopChange
BEGIN_SLOT_MAPPING
 msg $V3
END_SLOT_MAPPING
SDESC
The condition specified below has been cleared. It does not necessarily mean
that the underlying problem has been fixed. It may mean that InCharge provides
a better root cause (for example, a failing router may explain earlier host
failures which will be cleared).
 
Major topology change has occured (a whole network has been renumbered
or a switch has been replaced).
 
InCharge server restart is strongly recommended
otherwise inconsistent correlation results may occur.
 
The event contains the following varbinds:
        1) Selection name of the NNM server which runs InCharge
        2) Description text
EDESC
SM_IC_Error {1.3.6.1.4.1.733} 6 1111 a 4 0 "SMARTS Root Causes"
InCharge: Configuration Alert: $1. Restart InCharge
EVENT_CLASS SM_IC_Error
SDESC
This event indicates that an internal InCharge configuration error 
occurred.  InCharge restart is recommended.
EDESC
#
# end of file processing
#