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: James Shanks <James_Shanks@TIVOLI.COM>
Date: Tue, 6 Apr 1999 12:16:49 -0400
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>
I have had this work fine for artificial objects.  Are you certain you
issued the command correctly?


James Shanks
Tivoli (NetView for UNIX) L3 Support



BANDIERAMONTE Miguel TECSIS <TCSBTE@TECSIS.COM> on 04/05/99 05:28:56 PM

Please respond to Discussion of IBM NetView and POLYCENTER Manager on
      NetView <NV-L@UCSBVM.UCSB.EDU>

To:   NV-L@UCSBVM.UCSB.EDU
cc:    (bcc: James Shanks)
Subject:  Re: Changing status... The Word from Support





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