[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
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.R | Title | User | Personal Name | Date | Lines |
---|
1286.1 | notification services | TOOK::CALLANDER | Jill Callander DTN 226-5316 | Fri Jul 26 1991 10:17 | 17 |
|
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.2 | the power of DCL | ENUF::GASSMAN | | Wed Jul 31 1991 09:43 | 7 |
| 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
|