Conference azur::mcc

    
    sorry about that, but they didn't get it into the manuals and
    they felt without documentation putting everything in the release notes
    was a bit much so here is the quickie "get you started input":
    
    
    HOW TO MAKE USE OF THE TARGETING FUNCTIONS IN MCC **
    
    What are the targetting directives? In V1.2 of MCC there is a set of
    new directives common referred to as the targetting directives. These
    commands give the user the ability to control the visual impact of
    event information on their map and in the FCL display.
    
    The targetting commands consist of the ASSIGN TARGET, DEASSIGN TARGET,
    and DIRECTORY TARGET commands. The ASSIGN TARGET command allows the
    user to define what severity, and what domain member is to be visually
    associated with an event. For example, a user can assign the severity
    Critical to any Circuit Down event returned by the Node4 Circuit
    entity.
    
    The targetting commands support targetting based on domains. For each
    domain the user determines what targetting is to occur. The commands
    store the targetting information in the targetting database
    (MCC_SYSTEM:MCC_TARGET*MIR.DAT). 
    
    When should you use the targetting directives?  The commands were
    developed to help the user configure their enviroment to meet their
    needs. Some uses of the targetting commands are:
    
    	1) if you have a multi user environment, with rules created and
    	enabled in a general fashion (like a batch job) for all users
    	on that system. By doing this every user receives the same events
    	with the same targetting (severity and entity) information. These
    	"defaults" can be overwritten by assigning new severities through
    	the targetting commands.
    
    	2) Some entity models are defined so as to return the event
    	on the entity having the problem, while others return it against
    	the entity that detects the problem. The targetting commands allow
    	you to modify how this is seen. For example: you can target all
    	Node4 * Remote Node * events to display the color change on your
    	map on the remote node entity (if Node4 goste Remote Node foo 
    	returns an event, have the event cause Node4 foo to turn a color).
    
    COMMAND SYNTAX:
    
    The ASSIGN TARGET is a domain based command
    	verb: ASSIGN TARGET
    	entity: Domain <name>
    	arguments:	event source = <entity spec>
    			event name = "name of event"
    			managed object = "entity spec"
    			target entity = "entity spec"
    			target severity = enumerated_value
    
    To understand what that all means, you have to understanda bit about
    where events come from. Events in MCC can come from an entity, through
    the access module; but they can also come from an application (like the
    alarms FM) which creates an event on the entities behalf. The entity
    within MCC that generates the event, is known as the event source. This
    would be the entity used in the GETEVENT directive. For example: Domain
    foo Rule * is the event source for all rule firing information from the
    alarms FM rules in domain foo; while Node4 * would be the event source
    for all Node4 events. Wildcards or specific instances are allowed.
    
    The managed object is the entity for which the event applies. When
    talking about raw events (known in MCC as Configuration Events) the
    event source is the same as the managed object. But, for application
    sources like Domain Rules the managed object is the entity specified in
    the rule. This argument is not a required argument, its purpose is to
    allow for symbol substitution in the target entity. For example, given
    the following arguments (the # sign is the symbol substitution
    character):
    
    		managed object = "node4 * remote node #1"
    		target entity = "node4 #1"
    
    ...this means that the  instance returned in the remote node child
    entity is to be used as the instance name for the Node4 entity returned
    to the PM. So, instead of the remote node child entity being flagged
    with an event, the node4 entity it refers to will be instead.
    
    The target entity argument allows specific instances to be targetted,
    or through symbol substitution, any entity to be targetted.
    
    The event name accepts event partitions, or specific event names. Only
    one event or partition can be entered per command.
    
    So how does it work? Try entering the following commands and see...
    
    	MCC> CREATE DOMAIN FOO
    	MCC> REGISTER NODE4 NS:.mynode SYNO=mynode
    	MCC> CREATE DOMAIN FOO MEMBER NS:.mynode
    	MCC> ASSIGN TARGET DOMAIN FOO -
    	_MCC>	event source= node4 * remote node *, -
    	_MCC> 	event name="any configuration event", -
    	_MCC>	manage objec="node4 * remote node #1", -
    	_MCC> 	target entit="node4 #1", -
    	_MCC>	target severity = warning
    	MCC> NOTIFY DOMAIN FOO EVENT=(ANY CONFIGURATION EVENT)
    	MCC> DISPLAY NOTIFY !make sure it is in a running state
    	MCC> SET NODE4 mynode REMOTE NODE mynode COUNTER TIMER=60
    
    At this point you should see an event generated against the notify
    command, but instead the notification entity being the node4 remote
    node you will see the warning severity and the node4 entity as the
    notification entities.
    
    To do the equivalent from the map, select NOTHING on the map, and pull
    down the Operations menu. You will see the targetting commands there.
    
    Please note: 
    retargetting on a specific instance will take presidence over an
    assignment on a wildcarded entity class.      
    
    
    DEASSIGN TARGET
    
    To deassign a target you can deassign all targets for a given domain,
    or for a specific entity or wildcard in a domain. (Final release will
    include additional clarification by entity and event). 
    
    	DEASSIGN TARGET DOMAIN <name>
    	- or -
    	DEASSIGN TARGET DOMAIN <name> EVENT SOURCE = <entity spec>
    
    
    DIRECTORY TARGET
    
    This command does not currently work from the iconic map (well it
    actually works, but it flashes by too fast for you to read it; the next
    update will correct this problem by supplying a specialized window for
    reviewing/modifying/creating targetting entries). The directory is
    quite simple:
    
    	DIRECTORY TARGET DOMAIN <name>
    
    
    
    ---------------------------
    since there was a lack of documentation, this was a bit verbose. I hope
    it helps explain some of what the capabilities are.
    
    jill
    

thanks, I'll see what I can get to work, and what I can break :-).


brad...

I tried to take TARGETTING for a spin today and I've got some questions/
observations.

1. I tried to set up a NOTIFY from IMPM with entity of "node4 bbpk99 circuit
   syn-0 adjacent node *" and EVENT=adjacency down. The error I received was
   no entities in this domain support the requested events. I tried plugging
   names into the * also to no avail. Is it me or a bug??

2. I followed the last note's instructions for setting up a target. At first
   I created a basic ASSIGN for a "circuit down circuit fault" event and
   sent it to another node4 as a target. I then issued the NOTIFY command
   as described and even another for the specific event. Triggered the event
   aaaaaaaaand...nothing (no color). I then went to IMPM and created the
   NOTIFY request, triggered an event aaaaaand, it worked. Question, do notify
   commands work on a per process basis (ie. can't put them in batch) while
   the ASSIGN TARGET commands work across all MCC processes?

3. I then set up another NOTIFY for remote node "node reachability change"
   events and an ASSIGN TARGET using symbols. I didn't get this to work at
   all. One thing I noticed was that the event comes in with the node NUMBER
   and not the name. Does MCC convert this to a name to determine the
   target?? Has anyone had any luck with this event or adjacency down and
   targetting (these are the two main users of the function).


thanks,
brad...

Hi,

It seems the ALARMS FM is also no longer supporting ADJACENCY UP/DOWN
events either. What happened? Will it be coming back??

thanks for any info,
brad...

    
    BRAD,
    
    	ALARMS can do whatever you can do with the GETEVENT directive.
    	If you notice an event is gone from ALARMS, try the GETEVENT	
    	directive from FCL.
    
    		aud...

>    	ALARMS can do whatever you can do with the GETEVENT directive.
>    	If you notice an event is gone from ALARMS, try the GETEVENT	
>    	directive from FCL.
    
Hi,   		

At first I tried created an alarm and when that didn't work then
I had tried the GETEVENT directive and that is where I found Adjacency Up/Down
were now missing. Therefore should I say the "Phase IV AM" is no longer
supporting these events?

thanks,
brad...

    
    they better be, we have been using them. Under what entity did you
    look?
    
    Node4 * Circuit * adjacent node *
    
    See note 2137 for how to get these working.
    

    okay, okay, okay...
    
    you were right!!! I found a bug in the event name parsing in the
    notification FM handling of multi-keyword event names. It happens
    when an event (like circuit down) has a second event of almost
    the same name (like circuit down operator initiated), we never
    match on the substring event name. The fix has been made and tested
    and should be available some time in the near future.
    
    jill
    

thanks for fixing, now patiently waiting for the new kit...

brad/