| Hi,
Alarms/Notification in V1.2 of MCC implements a detection and
notification approach. It is not trouble-ticketing.
Some of the things you're asking for sound like what the TNMP product effort
in France is attempting to address.
TNMP is building on alarms/notification by creating "alarm objects" that behave
in a way similar to what you want (e.g. status reflected on map regardless of
when alarm was detected, one operator handling an alarm is reflected on other
operators' maps, etc.). I believe that's more like what you want.
For more information on the TNMP effort, contact Marc Flauw at TENERE::FLAUW.
I'll try to address your individual questions:
A. Alarms on IMPM
-----------------
>1. The Data Collector seems to "generate" only one kind of event, the
>"General Event - Collector General Event".
Yes, the Data Collector generates one MCC event. The "text" of the
event displayed in the notification summary window is taken from the
"event title" argument of that event. Thus, sending two events via the
data collector with different "event title" arguments will result in two
very different looking events showing up on the user's notification window.
>Is there any way to generate other
>events?
Not using the out-of-the-box data collector API. However, the data collector
is a fairly simple AM, and depending on what you need you could build an AM
modeled on it to generate other distinct events.... but that may not be
necessary... read on...
>Does this mean that you can have only ONE "Data Collector" alarm on a
>given entity?
No. You can tailor the IMPM/Notification PM to do several different kinds of
event correlation: correlation by notification request, event ID or event text.
Out-of-the-box, the IMPM is tailored to do correlation for data collector
events based on the event text. So, two data collector events with different
text will be correlated as as two different events.
>2. The Detail Alarm Window displays a time. Where is it coming from?
From the alarms FM.
>The "DECmcc Notification: Notification Detail" window displays a timestamp and a
time. Where are they coming from?
Timestamp is the same as displayed in the
If MCC_EVC_SEND is called once (ONE EVENT)
but two operators are working with notification enabled, they will see THIS
EVENT with different number but also different times...
>3. The alarms or notifications are numbered, BY USER (MCC process). Which
>means that two operators don't see the alarms with the same numbers... Not too
>easy to handle alarms.
Good point. We'll consider this in a future release.
>4. When an operator deletes a notification, it is not deleted for the other
>operators... Am I missing something or is there a way for more than one
>operator to USE MCC?
You're not missing anything. See opening paragraph of this note.
>5. Is there any way to "update" a given event from the MCC_SEND_EVENT API?
>By update, I mean "Delete" or "Change the severity". This is absolutely
>mandatory...
See earlier discussion on event correlation in IMPM. Basically, send another
event with the same text and a different severity, and the later event's
severity will override that of the earlier event's.
>6. When displaying a notification, is there a way to "really find" the entity,
>not only in the current domain but anywhere? Something like the "Manage entity
>in New Map Window" or "Find anywhere".
Sigh... I wish there was. It was on the list of things to do, but was never
implemented.
>7. The "Display Notifications" operation on the IMPM is disabled if there is
>already a Display Alarms window. Not to easy to use with dozen of windows!
Do you mean you want it to still be active and have it pop the existing
"Display Alarms" window to the top of the heap if the window is already
displayed? I agree.
>8. Any way to save the position and size of the "DECmcc Notification:
>Notification Detail" window? Could be included in "Settings".
Aha! Finally something I can say "yes" to. From the notification window,
bring up all the windows you want to save the geometry of. Position and size
them the way you want. Leave them all up. Then, on the notification window,
Press Customize->General Notification..., click on the "Use Current Window
Positions" and "Use Current Window Dimensions" buttons, press OK, then press
Customize->Save Current Settings, and Customize->Use Last Saved Settings.
>9. In the "General Notification Customization", you will get an ACCVIO if you
>enter a too big (too long, plenty of 9) "Maximum Notifications":
>%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=39393939,
>PC=80000010, PSL=03C00004
Thanks! Qar'd as 2839 in MCC_INTERNAL database.
B. The SINK process
-------------------
I'll forward your questions to someone who can answer them more accurately.
C. MCC_SEND_EVENT
-----------------
>1. Is there any way to specify the time WHEN the event was detected? We must
Perhaps include this information as part of the "event text" argument in
the event you send in via the data collector (if you're still going to use
that approach).
|
| the no request waiting is returned to the person trying to do the
send_event, NOT to the person doing the get. So the sender does
know that no one is looking at what they are putting, and it is
up to the putter to figure out if/what they want to do about it.
As to disabling logging, I assume you mean the data collector logging,
simply disable mcc 0 collector sink decnet.
|
| Sorry, I didn't completely answer your question A 2.... I moved on while I
brought up an example to see exactly what you meant and then never went back.
>2. The Detail Alarm Window displays a time. Where is it coming from?
That is an argument in the "OSI rule fired" event report, generated by the
alarms FM.
>The
>"DECmcc Notification: Notification Detail" window displays a timestamp and a
>time. Where are they coming from?
The timestamp indicates when the notification was received from the
notification FM. The "time" is the same argument as described above.
>If MCC_EVC_SEND is called once (ONE EVENT)
>but two operators are working with notification enabled, they will see THIS
>EVENT with different number but also different times...
The "timestamp" field will be different. The "time" argument should be the
same, as both operators will be receiving the same event.
|
| re :.0, .1
The product referenced by Pete in .1 is called TeMIP. It is developped
in TBG Eng in Valbonne. This product in its 1st version is provided fault
management capabilities on top of the alarm/notifications services and runs on
Ultrix only.
In its first version, it consists of 3 sets of modules :
- Alarm Handling FM + PM :
This module manages Operation Context objects. An Operation context is a
context of collection and management of alarms, defined by the domain tree to
which it applies, a Discriminator contruct (filter allowing you to collect
only some specific alarms) and a scheduling package to specify when you want
the collection to take place.
For each Operation Context, the collected alarms are transformed into alarm
objects, allowing to keep a status of the alarms (outstanding, acknowledged,
...), to provide operations on the alarms like acknowledgement, clearance,...
and to associate them with trouble tickets.
The alarms collection for OC is done in background mode even if no operator is
logged in. A same operation context can be shared by multiple operators and if
an operator acknowledges an alarm in 1 OC, all the other operators using this
OC will see the acknowledgement.
We provide a specific Motif X-windows PM acting in association with the
Iconic Map PM to display alarm objects.
- Event Log FM + PM
This module manages the ISO Log objects. It provides event logging
capabilities for ISO events and alarms. As for Operation Context, it is
associated with a domain tree, a Discriminator construct and a
scheduling package.
It runs also in background mode and uses its specific PM to display
log records.
- Trouble Ticket FM +PM
This module provides a Trouble Ticketing function, which is the follow-up of
problems. Trouble ticketing can work stand-alone or in conjonction with the
Alarm Handling FM. It uses a Ultrix-SQL database to store its information.
If you need more information, please feel free to ask directly myself or
Claude Hary (ulysse::hary) who is the product manager.
You can also ask questions in the TeMIP notefile (TAEC::PNMP).
Best regards,
Marc.
TeMIP Project Manager
|