I see that your 'Maps Managed' is greater than your 'Maps Exists'. That
means it is
time to do 'ovmapcount -a'. This discrepancy can cause problems with
status. I think
it also may mean that you should put on 5.1.1.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
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
|