[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

1286.0. "Problem/suggestion with iconic map alarms" by JETWSH::COMFORT (Spent a little time on the mountain) Fri Jul 26 1991 10:06

    
    Hi,
    
    Forgive me if this has already been suggested or addressed, but I am
    concerned about the lack of information available when viewing alarms
    in the iconic map module.  Specifically, I find that when using the
    iconic map interface and displaying alarms that have fired, if a given
    alarm has fired more than once, only the last occurance of the alarm is
    presented.  An example rule is as follows:
    
    Procedure 		= DKA0:[MCC.ALARMS.CIRC]X25_MAIL_ALARM.COM;2
    Description 	= "X.25 circuit report"
    Category 		= "X.25 circuit "
    Queue 		= "mcc$batch"
    Parameter 		= "@MCC_CIRC_ALARMS:X25_MAIL_LIST.DIS"
    Expression 		= (change_of(node4 phx25 circ X25-in-australia 
    					substate,*,*), at every 00:05:00)
    Perceived Severity 	= critical
    
    One of the intentions of this rule is to help track bouncing X25
    circuits.  However if only the last occurence of the rule firing is
    displayed in the window, one cannot easily tell (via the iconic map)
    how many times and under what circumstances the rule may have fired. 
    In my case, people on the mail distribution list get notified for each
    occurence, and hence I was able to track this discrepency.  At this
    customer site, the eventual disposition of the MCC workstation is to be
    in an operators command center with only the map interface available to
    the operators.  In my opinion, they should be able to fully determine
    what is going on when a condition occurs via the iconic map interface.
    
    
    If I have missed something (a setup feature etc) or if this issue has
    been identified and will be corrected, or if this is a design
    limitation, please let me know as my customer is interested in a
    definitive response. 
    
    
    regards,
    
    Dave Comfort
T.RTitleUserPersonal
Name
DateLines
1286.1notification servicesTOOK::CALLANDERJill Callander DTN 226-5316Fri Jul 26 1991 10:1717
In v1.2 it is planned that a complete new set of notification services will
be added on top of the functions (alarms in maps, NOTIFY command, domain
based rules...) you already have. These new features will include a number
of new notification windows available from the iconic map (you may have
heard them refered to as the notification PM). One of these windows will
keep track of all the events (alarms and configuration events) that you
have asked it to. They will be maintained in chronological order and
will NOT remove old events until the event buffer fills and then the oldest
events are removed (hopefully we will have the log function so they can be
stored to disk, but that function is not yet committed). Without getting
into to much detail, I would suggest you look at the notification services
section of the V1,.2 phase reveiw documents. I think you will find most
of what you are looking for. Feedback on the proposed functions would be
appreciated.

jill
1286.2the power of DCLENUF::GASSMANWed Jul 31 1991 09:437
    Wouldn't a workaround be to edit your alarm command procedure to keep
    track of the number of times it ran.  This could be done many ways,
    such as opening a file and adding a record to it then counting the
    records, adding one to a defined numberic symbol, running a simple
    basic program that maintains a file, etc..
    
    bill