Conference azur::mcc

Currently, re-targeting to the correct entity using the standard
"assign target" can only be done if the correct entity shows up as
a piece of the ENTITY specification that the event is reported
against.  There is no way to access the ARGUMENTS of
an event report using the standard targeting mechanism.

That is, if the event report is generated for an ENTITY
that in some way contains the desired target entity,
you can use the "managed object" field to do what you 
want.  For example, you can receive events against 
"node4 * circuit * adjacent node X" where X is typically
thought to be the correct node to turn a color.  You
would then assign a target as follows:

assign target domain foo -
event source = node4 * circuit * adjacent node *, -
event name = "circuit down", -
managed object = "node4 * circuit * adjacent node #1", -
target entity = "node4 #1"

Unfortunately, it appears that in the particular event you're 
interested in, only the circuit entity information shows up
in the entity specification, and the node id argument contained
in the event report is what you're really interested in.

Here's a suggested work-around: define an alarm rule that
listens for the events you're interesed in (OCCURS format).
Have the action procedure that is executed when the rule fires
parse the contents of the rule and, in turn, use the data collector
to send an event to the appropriate entity in the appropriate domain.
This is admittedly cludgey, and it will require some creativity
to avoid sending the events to domains that the node does not
exist in (which would potentially cause many duplicate notifications),
and a lot of grunt work to set it up (registering a bunch of data
collectors in appropriate domains, writing the command procedure, 
etc.) but it's the best I can offer at this time.  If anyone else has
a better idea, by all means, suggest it.

It sounds like you have a requirement for targeting based on the
arguments of an event report.  Something along the lines of:
 
******************** NOTE: THIS IS BLUE-SKY *******************
assign target domain foo -
event source = node * ROUTING CIRCUIT CSMACD-0 *, -
event name = "id reachability change", -
event argument = "node id = #1",
target entity = "node #1"
******************** NOTE: THIS IS BLUE-SKY *******************

I've heard similar requirements for basing the target severity on
the contents of an event report, e.g.

******************** NOTE: THIS IS BLUE-SKY *******************
assign target domain foo -
event source = node * ROUTING CIRCUIT CSMACD-0 *, -
event name = "id reachability change", -
event argument = "node id = #1, New ID Reachability = #2", -
target entity = "node #1", -
target severity advanced = "if #2 = 'up' then clear else critical"
******************** NOTE: THIS IS BLUE-SKY *******************

Nothing like this is planned for any future releases that I'm 
aware of.

Sorry.

    I'm curious to know if anyone else that has been using our OSI routers
    with DECmcc has this same issue.
    
    Unless I'm acting on the wrong type of event, it seems that for OSI
    based networks, retargeting of events such as the one described in .0
    will not be possible.
    
    I'd also be interested  to know if any other category of entity would
    report information that cannot be picked up in a standard MCC event.
    
    Rather difficult to say to a customer, particularly during a demo, that
    "oh by the way, the nice feature you see we have that allows you turn
    the icon color that is actually having the problem or is down, is not
    available for OSI, but only for our proprietary protocols such as
    DECnet"!!!
    
    Hope this gets fixed sometime in the future!!!
    
    Al
    

>    Unless I'm acting on the wrong type of event, it seems that for OSI
>    based networks, retargeting of events such as the one described in .0
>    will not be possible.

It is possible, as it was suggested in .1, it just isn't do-able using
the standard targeting mechanism.  

>    Rather difficult to say to a customer, particularly during a demo, that
>    "oh by the way, the nice feature you see we have that allows you turn
>    the icon color that is actually having the problem or is down, is not
>    available for OSI, but only for our proprietary protocols such as
>    DECnet"!!!

Rather incorrect to say that to a customer as well, so I would hope you
would refrain from doing so.

The standard targeting mechanism covers certain scenarios quite nicely.
Some scenarios are out of its territory though, so you have to resort
to something a bit more complex.

The desired solution can be obtained, you just have to be a little more
creative than just using "assign target".

As far  as  I can see, targeting is almost exclusively used for reachability
changes.  Sure, it is a general purpose facility but I bet 95% of its use is
for  routers  reporting  reachability  changes.  The hack described in .1 is
impossible to use, so effectively targeting is useless for Phase V networks.

When it  was  designed someone only looked at Phase IV router events.  There
is  no  point  going  over  history  but  that was a serious oversight.  The
oversight  needs  to  be fixed urgently if MCC is going to be any use -- our
customers  are  rapidly  replacing DEC Phase IV routers with Phase V routers
(or  competitors'  routers).  This will mean changing the plans for the next
version so that targeting based on arguments can be incorporated.

By the  way, the Phase V network managemnt rules effectively prevent us from
including  the  affected node in the "entity" portion of the event -- it has
to  go  in an argument.  If you dispute that please contact me by mail and I
will explain why.

Graham

Hi there,

How about in the next version omit the requirement of CLASS in targets
all together. A simple fullname should be all that is required.

just a thought,
brad...

See note 3700 for an implementation of the impossible to use hack
described in .1.  8^)

re: .4

>When it  was  designed someone only looked at Phase IV router events.  There
>is  no  point  going  over  history  but  that was a serious oversight.  The
>oversight  needs  to  be fixed urgently if MCC is going to be any use -- our
>customers  are  rapidly  replacing DEC Phase IV routers with Phase V routers
>(or  competitors'  routers).  This will mean changing the plans for the next
>version so that targeting based on arguments can be incorporated.

Let's assume you're right: nobody looked at the relevant phase V events
for this same scenario, and the current symbol substitution approach
was invented primarily with phase IV in mind.  

If someone had looked at the relevant phase V events, they would have 
found an interesting problem in that the adjacent node argument in the 
specific phase V event being discussed here is some sort of octet 
string that doesn't map very neatly to the current identifiers
supported by the phase IV AM.

I'm interested in your ideas of what a correct solution would be. 
Here are some alternatives.  Please feel free to propose whatever 
else you think is appropriate.

	1) add another argument to the phase V event which contains
	   a useable phase IV address or phase IV name

	2) change phase IV AM to accept an octet string as an 
	   identifier

	3) add a few appropriate DCL lexical function-like things
	   to the "target entity" syntax to be able to, for example,
	   translate the octet string to a phase IV address

	4) write an FM that does all the "right" things for these
	   particular phase V events, e.g. retargets to phase IV
	   entities or phase V entities (or other entities?) as 
	   appropriate, etc.

I'm no phase V expert.  You sound like you are.  I'm sure I don't know
all the issues involved here.  Your help will be appreciated.

> See note 3700 for an implementation of the impossible to use hack
> described in .1.  8^)

Will that  be documented, supported and shipped in the next release? I still
maintain  that it would be impossible for a customer to design and implement
the hack by themselves!

> I'm no phase V expert.  You sound like you are.  I'm sure I don't know
> all the issues involved here.  Your help will be appreciated.

There are  actually  a number of arguments which could come up (in different
events)  and  which  are  useful.   They  are  IDs, NSAPs and NETs.  Phase V
includes  a  mechanism  (backtranslation)  specifically to allow those to be
translated  into  the name (and hence, if desired, the address) of the node.
Working  out  whether  it  is  a Phase IV or a Phase V node is a little more
difficult  but  would  be  possible (the Session Control version is probably
good enough).

There are (at least) two options:

1) Add ID, NSAP and NET as alternate identifiers to the Phase IV and Phase V
AMs.   When  used,  these  would  be back-translated (using the real Phase V
backtranslation  information  in DNS -- not any MCC-specific backtranslation
information).

2) Add  a  few  appropriate  DCL lexical function-like things to the "target
entity"  syntax to be able to, for example, translate the ID, NSAP or NET to
a global entity specifier (class and name).

I am  not  an  expert  in  MCC  but  the  first  option sounds more like the
"correct" MCC way.

Graham