Conference azur::mcc

    The following Alarms errors were reported in the error logs:
    
    MCC_ALARMS_20-JUN-1991_ERROR.LOG;1
    
     >>> 20-JUN-1991 10:14:30.04   MCC 0 ALARMS RULE
    lab_bridge1_port_2_carrier_loss
    
         Expression = (CHANGE_OF (BRIDGE MY_NS:.lab_bridge_1 LINE
    2  carrier l
    ost, *,*), at  every=00:00:10)
         Status     = %SYSTEM-F-IVLOCKID, invalid lock id
    
    MCC 0 ALARMS RULE lab_bridge1_port_2_carrier_loss
    AT 20-JUN-1991 10:14:30
    
    
    
     >>> 20-JUN-1991 11:24:04.03   MCC 0 ALARMS RULE
    lab_bridge1_port_2_forwarding
         Expression = (CHANGE_OF (BRIDGE MY_NS:.lab_bridge_1 LINE
    2  port modu
    le state , *,*), at  every=00:00:10)
         Status     = %LIB-F-SECINTFAI, secondary interlock failure in
    queue
    
    MCC 0 ALARMS RULE lab_bridge1_port_2_forwarding
    AT 20-JUN-1991 11:24:04
    

    This is reproducable:
    
    -Disabled and deleted all 10 rules
    -recreated rules
    -re-enabled rules
    -rules work fine when manually enabled from IMPM
    -exit IMPM
    -start command procedure, all alarms enable successfully...
    	.
    	.
    	.
    Normal operation has begun.
    ENABLE MCC 0 ALARMS RULE lab_bridge_2_port_2_carrier_loss, in domain
    ICOM_LAB
    
    MCC 0 ALARMS RULE lab_bridge_2_port_2_carrier_loss
    AT 20-JUN-1991 17:25:20
    
    Normal operation has begun.
    ENABLE MCC 0 ALARMS RULE MCC1_CIRCUIT, in domain ICOM_LAB
    	.
    	.
    	.
    -re-enter IMPM
    -domains containing fired rules show correct status..
    -clicking on domain icon for domain with fired rule, triggers first 
     error described in .0
    -resetting all alarms clears status
    -alarms never fire again during the course of the IMPM session
    
    If I Control-Y the command procedure, I get:
    
    %MCC-F-FATAL_FW, fatal framework condition:  Failed to dequeue next
    ready thread
    %MCC-F-FATAL_FW, fatal framework condition:  Failed to dequeue next
    ready thread
    %MCC-E-ABORTCTRLY, image aborted by Cntrl\y
    

Are you enabling rules in batch AND bringing up the map w/notify
enabled at the same time? If you are stagger the two by enabling
the rules in batch first, check log to ensure they have all enabled,
then bring up map. After figuring out about how long it takes to
enable the rules you can use a wait statement if they both start via
the same procedure.

brad...    

    In the last few runs of this, I simply invoked the command procedure
    to enable the rules from a DECterm session.  When the procedure
    blocks on the SHOW MCC 0 ... I then bring up the IMPM.  The map
    comes up with my top level domain icons indicating that the alarms
    have been fired.  When I click on the domain icon, I get the first
    error.  The behaviour was the same when I submitted the batch job
    but when I was doing it that way, I may not have waited long
    enough..?
    
    Nick
    

    
    What a mess of problems!
    
    Are you still seeing the LOCK errors in the Alarms Error Log?
    Do you see this every time you run these rules?  If so, then
    this problem should be considered separate from the Notification
    problem.
    
    I do not think that staggering the execution of the command
    procedure and IMPM invocation will make a difference.  They are
    two separate processes and each will let you enable the rules.
    You will get two sets of Notification-highlights on your icons --
    one from the rules enabled in the command procedure and one from
    the rules enabled by the IMPM.  I don't think this should cause
    a problem, but I will need to look into this.
    
    So, if you can hang on a while, I'll get you some answers.
    
    aud...

>    I do not think that staggering the execution of the command
>    procedure and IMPM invocation will make a difference.  They are
>    two separate processes and each will let you enable the rules.

The problem I saw wasn't with enabling rules from each process, it was
seen by enabling rules from one process and enabling IMPM notification
at the same time. This definitely causes problems, whether this is base
notes problem or not I can't be sure.

Nick, are you using OCCURS alarms in this situation? If so try starting
fresh. Delete alarms batch job, MCC_DNA4_EVL process, and EVL process.
Restart processes in proper order EVL, MCC_DNA4_EVL, then alarm enable
job (stagger all of them). After 5-10 minutes (you should be safe) restart
IMPM and notification. If I remember right once I got the problem I had
to do the above steps to rid myself of the errors. If this doesn't clear
it you've got a different disease :-(.

Also, the problem I had was documented in a note (I think EVL was in the title)
and a QAR if anyone needs to reference any similiarities.

best regards,
brad...

Hi,

I've pointed out your map problems to the IMPM person responsible for V1.1
notification.

I have a feeling that the first problem in .0 could be a timing problem (rules
firing just as the IMPM is initializing) or a domain/map definition problem.

The second problem in .0 sounds like it's related to the problem in .1, i.e.
when the evaluation of the alarm rules on bridges failed the error bubbled back
up to the IMPM which didn't know what to do, so it stoped notification.

FWIW, when you enable notification in the IMPM, it walks the tree of dynamic
nested domains from the top-level domain in each map window and starts one
notify request for each domain it finds.  If a notify command encounters an
unexpected error, only that notify command is stopped and you see the messages 
as described in the second problem in .0.  If you pull down the File menu,
you'll see that the "Disable Notification" button is still sensitive and
the "Enable Notification" button is still insensitive.  That's because there
may be several notify commands running and only one was disabled due to the
unexpected error.  Choose "Disable Notification" and then "Enable Notification" 
to get the IMPM to restart notification in all domains, including the domain 
whose notify request was stopped.  Until you do this, no further notification
will take place in the domain(s) whose notify commands were stopped due to 
errors.  This entire area is being re-worked for V1.2.


I'm not sure about the problems in .1.  It appears as if either the Alarms FM
or the Bridge AM is encountering a problem when Alarms is attempting to evaluate
the rule.  If this is happening consistently, please let us know so we can
track this further.  

    Regarding the IMPM problem, Brad's answer in .6 would be my guess too.
    The IMPM notification code shares data structures with the map code.
    However, Fred and I do not have locks on those structures.  It is 
    something we have been aware of for a while.  
    
    I suspect it is indeed a timing problem since notification may be trying 
    to access structures that the map has not finished setting up.  For the
    time being, the easiest work-around is to restart notification if you
    see the errors.
    
    I will qar this against the IMPM.
    
    Christine
    

    This has been qared in MCC_INTERNAL as #727.
    
    Christine
    

    Any possibility of a patch being made available before V1.2?
    
    Nick
    

>    Any possibility of a patch being made available before V1.2?

I would say that a patch is possible only if this is an extremely high priority
for an exteremely important external customer.  If this is the case, I would
suggest making your case via more formal support channels than this conference.

Patches aren't quick or easy to create even for simple problems, and this
isn't a simple problem to fix. 

    No, it's not critical yet.  I'll try staggering the procedure and
    IMPM a bit longer and observe the results. 
    
    Also, one of the bridges that I'm polling has been "turned into" an LTM
    Listener.  There is still an Alarm rule monitoring Line X for
    "Carrier Loss" change.  This could be one of the rules that's
    failing, because if I simpy perform a show -> characteristics of
    that bridge, no response comes back.  (It's a LAN Bridge 150 loaded
    with LAN Traffic Monitor).  I'll get rid of this rule (or disable
    it) and see if this clears up some of this.
    
    Nick