Conference azur::mcc

    One thing that you can do is you can still use your two MCC machines
    but only one will monitor the terminal servers. In the same time, the
    other MCC system will check if the primary one still working (ex: check
    for the event "node reachibility change"). If that happen, you can then
    using the alarm procedure, enable the alarm rule for the terminal
    server until the other MCC system is back to normal.
    
    Never tried it but may be it will work.
    
    regards 

I like the suggestion in .1, by the way if your fallback is to TSM,
you are going to encounter the same problem, if you run it from both
platforms.

The only other way I can think of preventing this problem is to
synchronize your accesses on a larger scale.  This would require that
the clocks on both hosts be kept well synchronized.  (Isn't that what
DECdts is for?)

For the sake of argument, divide all of your terminal servers into two
partitions, during the first 30 seconds of any minute, check on the
first partition from the node 1, and the 2nd partition from node 2.
During the second 30 seconds, node 1 checks on partition 2, node two
checks on partition 1...

-Dave

    To get around being notified of exceptions caused by someone using the
    console port, we modified our Alarm Exception Procedure to contain the
    following -
    
    $ if f$extract(0,41,P6) .eqs. -
    "Terminal server management port in use by" 
    $ then goto exit
    !
    $ else -
    $ whole_line =-
    "** Exception at ''p5' *** Cannot check remote links on ''server' *,''p6'"
    $ !
    $ !
    $ !      ****  Light up domain icon on MAP ****
    $ !
    $ mcc_evc_send nodename muxserver_alarms -
      "Domain ''domain' member ''server'" -
      "Please check ''server'" -
      "Unable to check links on ''server', Reason: ''p6' " major
    $ endif
    $ reply/user=(netmanager,engineer)/bell "''whole_line'"
    
    We keep these alarms in a "hidden domain", so no icons change colour,
    and use the Data Collector to notify us when the exceptions are for
    real, like when the server does not respond to a poll (which is not
    always a problem unfortunately). So we get an icon change, a broadcast
    message, and also a DECtalk message.
    
    Cheers,
    Louis

    re .3
    
    This stops the icons from changing color but the exceptions still 
    appear in the notification window.
    
    We (Steve and I are in the same boat) can use filters to stop the entry
    from appearing in the notification window  but it looks like the filters 
    are not saved and they must be defined each time the Iconic Map is 
    started.  Any way to save filters?
    
                                                     

    
    >>>This stops the icons from changing color but the exceptions still
    >>>appear in the notification window.
    
    No, this is wrong. We have the server alarms setup in a domain that is
    not a member of any domains that are up on the current Iconic Map. All
    alarms and alarm exceptions that fire in this hidden domain, have no
    way of lighting anything up on the Iconic Map, and cannot appear in the
    notification window unless we specifically say so ( which we do not ).
    All that is enabled in the notification window is any collector events. 
    Hence we have to use the Data Collector to bring up a message in the 
    notification window, and we can pick and choose what icons we want to light 
    up. 
    
    An example of its application is how we setup refernce icons for MUXserver
    links, which we can then light up when a link goes down or comes back
    up.
    
    Cheers,
    Louis

    re .5
    
    What I meant was that without using targeting and diverting the alarms, 
    there doesn't appear to be a way to stop the exceptions from appearing
    in the notification window.
    
    Filtering will work BUT,
    
    	AS I ASKED IN .4, IS THERE NO WAY TO SAVE FILTER SETTINGS?  Please
    	don't tell me that you have to redefine your filters each time you 
    	start the Iconic Map!

    

>  	AS I ASKED IN .4, IS THERE NO WAY TO SAVE FILTER SETTINGS?  Please
>    	don't tell me that you have to redefine your filters each time you 
>    	start the Iconic Map!

Sorry, in V1.2 there is no way to save your filters, and indeed you must
redefine them each time the IMPM is started.

Save/restore filters did make it into V1.3.

Also, in V1.3 you can customize the filters to delete notifications 
instead of just hiding the notifications (and taking up room).

    re .5
    
    I've taken your suggestion and I've used it to solve the problem of 
    intercepting the "Terminal server management port in use by local system."
    exceptions.  But now I have the problem of the clear events that
    are generated when the terminal server comes available.   Any suggestions
    on how to block these clears but not block any other "legitimate"
    clears.
    
    A short description of what I've done -
    
    I have my term servers in a "hidden domain" with rules created for that
    domain.  The rules consist of one for "SOFTWARE/SELFTEST STATUS" on
    each term server and two rules for each port (PORT STATUS <> Connected
    and INPUT SIGNALS changing from  *,* ).
                                              
    The command procedures for the rules trigger mcc_evc_send to target the 
    terminal servers in the displayed domain using the collector.  In the 
    exception procedure I check for "Terminal server management port in use by 
    local system." and exit if true.  The rule command procedure is a pass
    through.
    
    I'm using V1.2.  V1.3 fixes this as it allows saving of filters for 
    subsequent IMPM sessions but we're stuck with 1.2 for now.
    
            
                                      
                                            

    re .8
    
    Just to complete the story -
    
    I found that the rules containing  the change of expression did not
    generate clears when the term server came available.  Makes sense.
    So I changed all the rules to use the change of expression format
    and it looks good.  
    

    Just out of interest ( for my sanity ), have your TSAM alarms ever just
    stopped working. By this I mean you check their status after working
    successfully for a while, and they say they are still trying to
    complete a poll, but never complete it. Hence the need to turn them
    off/on.
    
    Cheers,
    Louis