| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 855.1 | clarify who to react | TOOK::CALLANDER | | Mon Apr 01 1991 12:38 | 2 |
| Does he want the DECmcc SMS displays to react or the DECmcc Director/BMS
iconic map interface to react?
|
| 855.2 | iconic map react with vaxsim | MAIL::HELTON | | Mon Apr 01 1991 12:44 | 5 |
| His question was rather generic, although I believe his intentions were
to have the iconic map to react.
Thanks,
Gary Helton
|
| 855.3 | | TOOK::CALLANDER | | Mon Apr 01 1991 14:18 | 11 |
| Gary,
If you are right then the potential to do as he is requesting will be there
some time in the not to distant future. We are working on an AM (actual release
date unknown) called the data collector which will give applications an
interface into MCC for getting event information into the system. This
means that things like the application you are talking about could simply
send data to MCC without having to write an AM (though they would have
to put in the calls to the data collector; passing the info across the
network).
jill
|
| 855.4 | More info on Data Collector AM | TRADE::ASHRAF | | Wed Apr 03 1991 11:21 | 16 |
|
<RE: .3>
Jill,
I have been looking into the feasibility of developing a home-brewed
AM for the DECtrade platform to log events with MCC. Since these
events can also be generated by third-party applications, one of the
requirements is that these events must not necessarily have to be
pre-defined.
Can you provide more information on the capabilities of the Data
Collector AM, or provide contact information?
Muhammad
|
| 855.5 | | VETTE::SULZBACH | | Wed Apr 03 1991 12:00 | 12 |
|
Gary,
I am a member of the SDD tools development team and would like to say
that we are looking into using DECmcc on a new VAXsimplus fault management tool.
We are not at the point where we would commit any deliverable to a customer, but
your question falls in line with our thinking.
Please call me at DTN: 523-2982 or Keith Norman at DTN: 523-2185 if you would
like to discuss this or put in a requirement to the product.
- Roger
|
| 855.6 | notification | TOOK::CALLANDER | | Wed Apr 03 1991 19:03 | 4 |
| As to more information on 1.1 notification services and 1.2 enhancements
i am the appropriate person to call (PL for those modules).
226-5316
|
| 855.7 | Where do they fit according to the architecture? | LINSEY::OBRIEN | | Mon Apr 22 1991 18:12 | 28 |
| You can't tell whether an event collector is going to be adequate for an
application until you understand the characteristics of the events it will
collect. What satisfies the DECsim gentleman in this note may not fit the
system management alarms described in note 875.
One way to find out is to ask the note author to state into which of the
Event Architecture's design centers this application fits, based on matching the
characteristics of the events at the source, at the sink and the event transport
protocol. This will be admittedly a little hard for him to do, as I only just
started the Event Services document down the review path a month ago, but at
least one of the solutions (the DNA Phase V Event Logging) exists (and has for
over three years), so it is not impossible. Have you both agreed that the DNA
Event Dispatcher meets the application requirements? If not, I need to talk to
Muhammed and Roger about what they are trying to do and make sure that they are
covered by the architecture.
Likewise, will the MCC Data Collector meet the same DNA EVD spec? If not, I
need to talk to you, Jill, about its characteristics and determine which event
services spec it will meet, so you can proceed without worrying about both
market positioning and architecture non-conformance issues in the future. There
are a number of signalling, notification and monitoring solutions being
architected in NAS and EMA (and implementations being built with the expectation
that applications will use their APIs) and it will help to know where you fit
in.
Linsey O'Brien
Event Services architect
EMA group
|