[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

2823.0. "Events, Notifications & Data Collector" by BALZAC::COULON (Even if it works, ask why) Wed Apr 22 1992 15:21

 We are evaluating the Data Collector as a bridge between DEC ARC (a DCM like
system monitoring product) and DECmcc. What we want to do is to be able to
display on the IMPMs (we need more than one operator) all the current alarms, 
which means display alarms when they are received but also refresh the IMPMs
(when restarting) with unhandled alarms... Here come some questions and remarks
concerning the Notifications Services and the use of the Data Collector 
(running DECmcc X1.2.15). 


A. Alarms on IMPM 
-----------------
1. The Data Collector seems to "generate" only one kind of event, the
"General Event - Collector General Event". Is there any way to generate other 
events? Does this mean that you can have only ONE "Data Collector" alarm on a 
given entity?

2. The Detail Alarm Window displays a time. Where is it coming from? The
"DECmcc Notification: Notification Detail" window displays a timestamp and a
time.  Where are they coming from? 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.

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?

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...

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".

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!

8. Any way to save the position and size of the "DECmcc Notification: 
Notification Detail" window? Could be included in "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

  Improperly handled condition, image exit forced.

        Signal arguments              Stack contents

        Number = 00000005                801F3C40
        Name   = 0000000C                00000002
                 00000001                00CDCA30
                 39393939                00CDCA18
                 80000010                00000004
                 03C00004                00CDCA8C
                                         00000000
                                         39393939
                                         00F95EE6
                                         05000001

        Register dump

        R0 = 03C00000  R1 = 39393939  R2 = 00CDCAAC  R3 = 002E1A2C
        R4 = 002E09A0  R5 = 00F95730  R6 = 00F95E00  R7 = 002ED0F0
        R8 = 00092468  R9 = 0000689C  R10= 002986BC  R11= 0029B5E8
        AP = 00CDC9CC  FP = 00CDC98C  SP = 00CDCA08  PC = 80000010


B. The SINK process
-------------------
1. What happen to received events if "no request is waiting" (no MCC running
for example). Are they lost? Is the caller (MCC_SEND_EVENT) notified?

2. Is there any way to disable the logging?


C. MCC_SEND_EVENT
-----------------
1. Is there any way to specify the time WHEN the event was detected? We must
make the difference between the detection and the notification on the MCC
Collector, because an event could be locally buffered and because we would like
to be able to "play back" unhandled events when an operator restarts the IMPM.
 
 Thanks for your time.
 Regards,

 Serge
T.RTitleUserPersonal
Name
DateLines
2823.1notification isn't trouble ticketingMCC1::DITMARSPeteWed Apr 29 1992 12:33124
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).
2823.2how sink works...(some)TOOK::CALLANDERMCC = My Constant CompanionWed Apr 29 1992 12:448
    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.
    
2823.3timestampsMCC1::DITMARSPeteWed Apr 29 1992 13:1221
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.
2823.4More info on TeMIPTAEC::FLAUWThu Apr 30 1992 06:1849
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