On re-reading your append I realized you are talking about web clients not
getting
the correct status from the collections. And they must by definition be
running against
a r/w map. So yes, that is wierd.
I have seen mysterious things happen with the web client when the web
browser is
either down-level or does not have enough resources. Also, on some browsers
there is a place where you configure how often a page is updated, and you
are
supposed to select 'Every Time'.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
==========================================================================
============================
Now you are on the right track. I was disappointed to figure out only
recently that
Collections have no special powers when it comes to read-only maps. For
some
reason I thought they might. Collections on a r/o map SHOULD (see below)
accurately reflect changes in the status of their members. They will NOT,
however, reflect
changes in MEMBERSHIP until a refresh is done. Of course. Because that
requires
Netview to create symbols, etc. So my favorite Down_Interfaces and
Problem_Nodes
collections only work properly on R/W maps.
Now as for the status of nodes in collections, regardless of r/o or r/w,
there were a
number of problems with this as late as 5.1. Most of them appear to have
been fixed
in 5.1.1.
So... Get to 5.1.1, adjust your timeouts so you don't get too many false
alarms, and
figure out something else to do instead of the Problem_Nodes collection for
r/o maps.
I'm still puzzling over that one. Maybe the right thing is to make a
collection of Important
Nodes, period, and have them watch that. Static membership, but status
should be
dynamic.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Thanks, Leslie. Maybe that is not my real problem. Yes, my subsequent
testing indeed will straighten things out but the operations staff sees the
color changes and sometimes waste time investigating false indications of
trouble. In particular - I have created a collection they monitor holding
objects which are critical or marginal using the web interface. While it
seems the IP map always reflects current status they must "refresh" the
collection submap before these false "red or yellow icons" go away. It may
be a browser issue (??). The read-write submap is always correct - only the
collection submap on the web browser must be refreshed.
Blaine Owens
Eastman Chemical Company
Email - bowens@eastman.com
Phone - (423)229-3579
Fax - (423)229-1188
> -----Original Message-----
> From: Leslie Clark [SMTP:lclark@us.ibm.com]
> Sent: Friday, April 02, 1999 11:32 AM
> To: NV-L@UCSBVM.ucsb.edu
> Subject: Re: Icon Status Color Changes
>
> If in the course of investigation of a 'down' node you ping the thing,
> Netview will hear it and
> correct the status for you. Better that than altering the guts of the
> product. Unless of course
> you are itching to write your own network management product....
>
> Cordially,
>
> Leslie A. Clark
> IBM Global Services - Systems Mgmt & Networking
>
>
>
> I automatically generate Remedy Trouble Tickets for "Node Down" events
but
> not directly from the netmon node down trap, which is not always true.
> Instead I run a script from automatic action and do more extensive
testing
> to make sure the node really is down before generating my own trap which
> triggers the Remedy Ticket. I would prefer that the icon for the node NOT
> change to red/down from the netmon 58916865 trap but rather from my trap.
> Using the gui the "STATUS" for trap 58916865 (and 58916865) is greyed
out.
> Is there a way to modify this behavior? Would it be safe to manually
> insert
> the status field in the trapd.conf file? Thanks.
>
> Blaine Owens
> Eastman Chemical Company
> Email - bowens@eastman.com
> Phone - (423)229-3579
> Fax - (423)229-1188
|