nv-l
[Top] [All Lists]

Re: Changing status... The Word from Support

To: nv-l@lists.tivoli.com
Subject: Re: Changing status... The Word from Support
From: BANDIERAMONTE Miguel TECSIS <TCSBTE@TECSIS.COM>
Date: Mon, 5 Apr 1999 18:28:56 -0300
Reply-to: Discussion of IBM NetView and POLYCENTER Manager on NetView <NV-L@UCSBVM.UCSB.EDU>
Sender: Discussion of IBM NetView and POLYCENTER Manager on NetView <NV-L@UCSBVM.UCSB.EDU>
Leslie,
        I opted to use the command line snmptrap and it works fine over real
nodes, but I made manualy a new object and doesn´t work on it, here is the
description:
OBJECT: 63654

        FIELD ID        FIELD NAME                      FIELD VALUE
        10              Selection Name                  "sapserv4"
        14              OVW Maps Exists                 1
        15              OVW Maps Managed                2
        71              isNode                          TRUE
        73              isComputer                      TRUE
        81              isMini                          TRUE
 which is the parameter I have to change (and how) in orther to snmptrap
script works fine?
Thanks . . .

> -----Original Message-----
> From: PUB:Leslie Clark [SMTP:lclark@US.IBM.COM]
> Sent: Monday, April 05, 1999 1:07 PM
> To:   NV-L@UCSBVM.ucsb.edu
> Subject:      Re: Changing status... The Word from Support
> 
> Here's something I keep handy on this subject.. Warning. long append.
> File for future reference.
> 
>  ------------------------------------------------------------------
> 
>  One of the most common, and yet most complicated, things that NetView
> 
>  users ask about is how to alter the status (color) of an icon on the
> 
>  map using a trap, effectively overriding what netmon has done.  This
> 
>  can be accomplished in one of three ways, (1) using a ruleset with the
> 
>  override node in it, (2) issuing the 58916871 NetView trap, or (3) by
> 
>  configuring a non-NetView trap.
> 
>  This document is an attempt to explain how these processes work.
> 
>  Types of status
> 
>  There are three (3) sources of status for objects on a NetView map:
> 
>  1.  Object source -- status of a single object is kept in the
> 
>   database entry for that object
> 
>  2.  Compound Propagated source -- object has no status of its own, but
> 
>        it is derived from status of its constituent objects.
> 
>         Network symbols and collection objects have status source of
> 
>         'Compound Propagated'
> 
>  3.  Symbol source -- an ipmap status not part of the object host nodes
> 
>          in the map have this status source
> 
>  You can determine the status source for any map object by selecting
> 
>  it with the rightmost mouse button and clicking on Edit ==> Modify /
> 
>  Describe ==> Symbol.
> 
>  General requirements
> 
>  1. In order for an event, no matter how it is processed, to override
> 
>  status and change the color of an object on the map(s), the Event
> 
>  process (called nvevents) must be running in dynamic workspace in a
> 
>  control desk on the read-write map, and the control desk must have
> 
>  been started by ovw (the map process) initially.  This is the default
> 
>  NetView End User Interface configuration.
> 
>  The reason for this is that the APIs for the status override function
> 
>  are in nvevents and ovw, and they can only be used effectively when
> 
>  both are connected to the same read-write map.
> 
>  2. The API can easily override the status of objects which have a
> 
>   status source of 'Object' or 'Symbol', but a status source of
> 
>  'Compound Propagated' is more difficult.  Since this is a derived
> 
>  status it cannot be changed directly.  What nvevents can do in this
> 
>  case, is to change the status source of the object to 'Symbol' first,
> 
>  and then override it.  But as this means that from that time on, the
> 
>  map object will no longer reflect the combined status of the objects
> 
>  "below" it (unless you later change the status source back to
> 
>  'Compound Propagated again via Edit with the right mouse button) you
> 
>  must set the application defaults for nvevents to permit this to
> 
>  happen.  You must edit app-defaults/Nvevents to say
> 
>    nvevents.overrideCompoundStatus : True
> 
>  When your event requests a status override, the object's status source
>
>  will be changed from compound to symbol, and then overridden.  But now
> 
>  you must take responsibility to change the status again when the
> 
>  condition which caused you to change it in the first place has passed,
> 
>  as it will never again reflect the status derived from its components.
> 
>  Failure to have  nvevents.overrideCompoundStatus : True set in your
> 
>  Nvevents file is the most common reason why users report that overrides
> 
>  do not work.  Be aware that each user could have his or her own
> 
>  copy of Nvevents in his or her $HOME directory or could have
> 
>  incorporated the Nvevents entries into a .Xdefaults file.  And be aware
> 
>  that X is not forgiving about user defaults.  The value here must be
> 
>  "True" and not "True " with any extra spaces trailing the 'e'.
> 
>  Note that if a host node is in a Collection, it has status source of
> 
>  'Compound Propagated', while on the IP Segment map it will have a
> 
>  status source of 'Symbol'.   If you do not have
> 
>    nvevents.overrideCompoundStatus : True
> 
>  set in the Nvevents app-defaults, then the status you set will not be
> 
>  reflected in the Collection.  This is another common problem which
> 
>  users report.
> 
>  Note that the host node on a Segment map typically has status source
> 
>  of 'Symbol'.  It is set when netmon issues a Node Up/Node Down trap.
> 
>  Note that interfaces have a status source of 'Object'.  Their status
> 
>  is set when netmon issues an Interface Up/Interface Down trap. At
> 
>  higher levels, networks and segments have a status source of 'Compound
> 
>  Propagated', so both the host node AND its "down" interfaces must
> 
>  have their status set to User1 or User2 to avoid having them alter the
> 
>  status of the network.  Failure to set both of them is another common
> 
>  user problem.
> 
>  3. Condsider how you will change the status back again.  If you are
> 
>  changing status of nodes and interfaces that netmon pings, remember
> 
>  that it will change them back again, so you might delay the netmon
> 
>  polling cycle for them.  If you are overriding the status source of an
> 
>  object that was 'Compound Propagated' and are changing it to 'Symbol',
> 
>  you must find a way to change the status again with so other "cleared
> 
>  condition" event, since it will not change on its own now.
> 
>  Override status with ruleset
> 
>  In order for a ruleset to override status and change the color of an
> 
>  object on the map(s), the ruleset must be running in dynamic workspace
> 
>  in a control desk on the read-write map.  This is general requirement
> 
>  #1.
> 
> 
>  And for the ruleset to override the status of an object which has a
> 
>  status source of 'Compound Propagated', you must edit
> 
>  app-defaults/Nvevents to say
> 
>    nvevents.overrideCompoundStatus : True
> 
>  This is general requirement #2.
> 
>  But ruleset override will only override the status of the host node,
> 
>  the "origin" of the trap, and not the interface (unless the interface
> 
>  does not have a hostname associated with it in the NetView database).
> 
>  This can be inconvenient, especially if what you want to do is
> 
>  override the status of both the host node and the interface (to
> 
>  something like User1 or User2) so that they do not figure in status
> 
>  propagation to higher-level nodes.
> 
>  Note that the host node on a Segment map typically has status source
> 
>  of 'Symbol'.  It is set when netmon issues a Node Up/Node Down trap.
> 
>  Note that interfaces have a status source of 'Object'.  Their status
> 
>  is set when netmon issues an Interface Up/Interface Down trap. At
> 
>  higher levels, networks and segments have a status source of 'Compound
> 
>  Propa- gated', so both the host node AND its "down" interfaces must
> 
>  have their status set to User1 or User2 to avoid having them alter the
> 
>  status of the network.
>
>  So NetView also provides another way that status can be overridden.
> 
>  Override status using the 58916871 trap.
> 
>  If you look at the description of this trap in Event Configuration,
> 
>  you will see that this trap is not issued by netmon but is in fact
> 
>  designed for customer use to change status (and therefore color) on a
> 
>  map.  It doesn't affect true status in the object database.  Below is
> 
>  a shell script which will issue this trap via the snmptrap command.
> 
>  You pass it two variables -- (1) the name of the object from object
> 
>  database, and (2) the status you want this changed to on the map(s).
> 
>  Here's the script:
> 
>  #!/bin/ksh
> 
>  set -x
> 
>  NAME=$1
> 
>  STATE=$2
> 
>  /usr/OV/bin/snmptrap `hostname` .1.3.6.1.4.1.2.6.3.1 \
> 
>  `hostname` 6 58916871 1 \
> 
>  .1.3.6.1.4.1.2.6.3.1.1.2.0 Integer 14 \
> 
>  .1.3.6.1.4.1.2.6.3.1.1.3.0 OctetString $NAME \
> 
>  .1.3.6.1.4.1.2.6.3.1.1.4.0 OctetString "Object status is" \
> 
>  .1.3.6.1.4.1.2.6.3.1.1.5.0 OctetString $STATE
> 
>  Obviously you can make this script more elaborate if you like.
> 
>  The permissable status values are Unknown, Normal, Marginal, Critical,
> 
>  Up, Down, User1, and User2.
> 
>  You can obtain the name of the object by highlighting the icon on the
> 
>  map and clicking with the RIGHT mouse button to get to Edit ==>
> 
>  Modify/Describe ==> Object and the name is in the Set Selection Name
> 
>  Typically, a host is known by its hostname and an interface by
> 
>  hostname:interfacename, where the interface name is the IFdescription
> 
>  from the MIB (such as "nv6ktst5.raleigh.ibm.com:tr0" for example).
> 
>  You can always verify you have a correct object name by doing
> 
>  ovobjprint -s <name>.  If the object is not found, then you have a bad
> 
>  name.
> 
>  Since this is being done using the nvevents API to ovw, the same
> 
>  restrictions apply. The snmptrap must be received by some NetView with
> 
>  nvevents running in a control desk attached to an ovw running the
> 
>  read-write map.  This is general requirement #1.
> 
>  And the Nvevents app-defaults file must have the same value set:
> 
>  nvevents.overrideCompoundStatus : True if what you are setting has a
> 
>  status source of Compound Propagated.  This is general requirement #2.
> 
>  Override with a trap setting
> 
>  As in all other cases, general requirements #1 and #2 apply here as
> 
>  well.
> 
>  In addition, you cannot alter the status set by netmon traps, so you
> 
>  have to use a trap from another agent.  Here you can also use snmptrap
> 
>  to create your own traps and issue those by script or automatic action
> 
>  from Event Configuration.
> 
> --------------------------------------------------------------------------
> -
> ------------------------------------------------
> 
> Cordially,
> 
> Leslie A. Clark
> IBM Global Services - Systems Mgmt & Networking
> 
> 
> 
> Hi everybody!
>         Does anybody know which is the command line to change the color
> (status) of an objetct.
> Many thanks.
> 
> Ing. Miguel Bandieramonte
> TECSIS ACE Siderca Siderar
> ARGENTINA
> tcsbte@tecsis.com
> 54-3489-4-3-3979

<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web