Conference azur::mcc

>	I'm quite new using Notification and Targeting, but from
>	the first tests I made, seems that I need to have 2 
>	"Notify Request" for each of the nodes that I want to 
>	monitor (something like 50, so 100+/- Notify Requests), 
>	plus 5 "Targeting" for the domains . If someone want more 
>	details I could explain better my situation.

Depending on your domain hierarchy, you might get away with just 1 
notify request (with expand=true).

To get correlation in the IMPM to work properly, you'll want to
listen for all the events that you want to correlate to one another
in a single notify request anyway, e.g. "circuit up" and "circuit down".

To do reachability for phase IV based on events, you can 
generally get away with setting up targets in each domain and
using a notify request at the top domain with expand=true and the 
global entity instance being wildcarded.

    Hi Pete,
    	
    	Thanks for your reply, the info you pass me about the Expand=True
    	could be a very nice and useful function.
    
    	But it isn't applicable to my customer, I try to explain why:
    
    	Imagine that I've a LAN with about 150 decnet node (50 Vaxes
    	and 100 PCs), if I use a general Notify request asking to a
    	router all the "Adjacency up/down" I'll receive a notification
    	every time a decnet node, no matter if it's a PC or a VAX.
    
    	The customer doesn't want notifications for the up/down of these
    	PCs (and not for all the VAXes BTW).
    
    	The only way that I see it's to build 2 Notify Request (1 for
    	the adiacency up and 1 for the adiacency down) specifing 
    	every node I interested in. (I could use also 1 Notify Request
    	for every node waiting for both the events and use 2 Targeting)
    
    	My principal problem it's the difference in CPU, memory, and
    	so on, used by each Notify Request, specially in comparision
    	with alarm rule.  I hope that some of the engineering people
    	could answer me.
    
    
    					Thanks again,
    
    					Ciao 		Luciano Barilaro

Hi,

I am not sure how much effort you're willing to go to get this functionallity
but I have done similar things as you require in the past. Basically I change
HOW I notify the map and use Data Collectors. Here is an example:

- Write an alarm rule to fire when the event comes in

- Next check a config file to see if it is a node of interest. This config file
  can be something like all nodes in MCC domains. This file can be 
  automatically created each night with the self-starting alarms-enable 
  procedure.

- If node is present (of interest) send data collector event to appropriate 
  node which highlights icon etc...

FWIW, maintenance of setting up NOTIFY requests for each node of interest will
most likely be too cumbersome.

best regards,
brad...

Brad's suggestion is a good one, and a good general purpose
mechanism for overcoming alarms/notification shortcomings.

You could also put a list of entities into each notify request,
but you'll run up against some limit or other soon enough
(I think 256 chars in a notif request line read from a file will 
shut you down soonest).

>    	The only way that I see it's to build 2 Notify Request (1 for
>    	the adiacency up and 1 for the adiacency down) specifing 
>    	every node I interested in. (I could use also 1 Notify Request
>    	for every node waiting for both the events and use 2 Targeting)
 
In situations like this, definitely go with one notify request 
listening for both events and use the targets to assign severity.  This
will allow correlation to work properly, as previously noted.

   
>    	My principal problem it's the difference in CPU, memory, and
>    	so on, used by each Notify Request, specially in comparision
>    	with alarm rule.  I hope that some of the engineering people
>    	could answer me.

I'm sorry to say that I can't give you a precise estimate on how
expensive notify requests are vs. alarms.  And I am some of the 
engineering people.  :^)  I would suggest trying both and measuring
the differences in the areas of interest to verify which approach
is most efficient for you.

Alarms and notifications only overlap in situations where one is
interested in events.  Generally, the perception is that if you can 
get away with a few notify requests to do the job, that's the better 
way to go.  If you have a job that requires trickery, go with an 
alarms command procedure and the data collector.

Another thought which may or may not be feasable or 
appropriate is to use the phase IV event sink's filters
to filter out (block) or in (pass) events such that
only the interesting events will make it into the 
phase IV AM.

In that case, one notify request could do the whole
shebang.