Conference azur::mcc

In the File menu check the settings for "Notify Domain" and
"Change Color".  They should both be enabled ("Disable" will be
selectable in this case).

..............................beth

I think that everything that should be enabled is.


The customer has tried two different types of rules. The Occurs
rule does not cause the icon to change colour, even though it 
does cause a report in the Notification window. The Comparison
rule causes the icon to change colour as well as the report in
the Notification window.

The definition for the rules follows :


create domain uic_ns:.sbb rule test1 -
expression = (occurs (PRO * PRO Local Production Down)), -
severity = critical



create domain uic_ns:.sbb rule test2 -
expression = (PRO * STATE NE WORKING, 00:10:00), -
severity = critical




Why does rule test2 cause the icon to change colour, when 
rule test1 does not?


Is this a bug in mcc (Version 1.2.0) or is there something he and I
have overlooked?



Ben

    I would guess that for the  OCCURS rule you also need a reTARGETing
    directive so the notification is appropriately targetted.
    
    Perhaps someone who understands targetting better can help?
    
    s/rob
    

Hi,

When a notification is recieved by the IMPM, it has to figure
out which icon to change color, and it uses mcc_aes_match, mcc_aes_equal and
mcc_aes_equal_levels to compare the AES that came back through alarms/notification 
with the AES's that the IMPM got from the domain FM for each entity
in the domain (when it opened the domain).  When the IMPM finds a match, 
the icon's color is changed.  

So, the AES that is coming back in the notification resulting from the
OCCURS alarm rule is not quite matching up with the AES of the entity
as it is registered.

The fact that the regular comparison alarm rule does cause the icon to change
color means that at least some of the time the AM is returning the correct AES.

My guess is that the Access Module is returning an out entity that is 
slightly different from its SHOW and GETEVENT entry point.  The OCCURS format 
rule issues a GETEVENT.  The comparison format rule issues a SHOW.  Also, 
the comparison rule is going to basically do a SHOW with an AES that came back
from the domain FM (during the course of evaluating a wildcarded rule, the 
alarms FM calls the domain FM to enumerate the wildcard).  The occurs rule 
is NOT going to enumerate the wildcard: it's going to do the equivalent of
a "GETEVENT PRO *", so it's going to be much more likely that the AM is doing
the bulk of the work in creating the AES in this case (and has that much more
opportunity to do something that won't work).

The AES comparison routines are very picky.  Little things, like the mcc_l_id
field in the descriptor that is used to do an mcc_aes_create, have to match up.  
In fact, when generating an AES, a little known fact is that the mcc_l_id and 
mcc_l_dt fields should always be set to match the attribute ID and datatype 
from the MSL/dictionary for each level of the entity.  This is probably the
problem.

For example, if I were creating an AES for "NODE4 foo CIRCUIT ISA-0", I would
have to set the mcc_l_id and mcc_l_dt fields of the descriptors that I use
in my mcc_aes_create's as follows:

NODE4 foo     mcc_l_dt = MCC_K_DT_PHASE4NAME, 
              mcc_l_id = MCC_K_DN4_NI_NODE_NAME (defined to be 1 in the MSL for Node4)

CIRCUIT ISA-0 mcc_l_dt = MCC_K_DT_SIMPLENAME,
	      mcc_l_id = MCC_K_DN4_CI_NAME (defined to be 1 in the MSL for Node4 Circ)


You can check this kind of stuff by defining logicals/environment variables as
follows in the process that the alarms FM will be run from:

$ define MCC_IM_LOG   60400000
% setenv MCC_IM_LOG 0x60400000

  OUT_ENTITY:
        entity [0] wild = NOT_WILD class = 7 id = 13 type = 24
        instance = 0                         ^^^^^^^^^^^^^^^^^^
                                             ||||||||||||||||||
                                             these are the fields I'm talking about


Good luck.

regards,

Pete

Pete,

You are a star!

Thank you very much - the problem was that he had forgotten to
set his ID field when creating his Entity for sending using
mcc_event_put in his event sink.


Ben