| 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 |
After researching the EMA Entity model T1.0.0 and the DECmcc V1.1 SRM V1.1 I confess that I don't understand what event partitions are for, so I'm worried that I'm going to define MSL that won't be what we need. I think I understand event groups. Event groups are a way to refer to more than one event. Events can be in more than one group. But what is the utility of event partitions? I notice that while all event definitions must appear within an event partition (just like attributes), there don't seem to be any pre-defined event partitions like there are attribute partitions. Also, what are the strategic implications of placing a given event in one partition or another (or all events in one partition)? What gets easier/harder or works/breaks one way or the other? What I'm doing for the moment is putting all the events that are generated by a related "tree" of entities into the same event partition. That is on the presumption of being able to say "watch for anything from event partition mumble". Trouble is, that looks like what an event group will do. Thanks
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 678.1 | TOOK::STRUTT | Colin Strutt | Wed Jan 30 1991 20:02 | 36 | |
Like attributes, events have both partitions and groups.
The v1.0 entity model, which is only concerned with entities
themselves, refers just to groups.
From the director's point of view, there is a need to distinguish the
two concepts of partitions (which literally partition the set of
attributes or events) and groups (which are arbitrarily, perhaps
overlapping, perhaps dynamically defined by users, groups of
attributes or events. The reason that the director needs to distinguish
the two concepts is:
partitions are a unit of dispatch (in terms of mcc_call)
groups are what users see, eg. at the user interface.
Notice that, therefore, all partitions are automatically also groups.
Thus, with attributes, one might have the following partitions:
(entity supported, via an AM):
identifiers, characteristics, counters, status
(director supported by an FM):
statistics, reference, etc. etc.
And, one might have the following groups available to the user through
the director:
identifiers, characteristics, counters, status, statistics,
reference, useful attributes, error attributes, performance
attributes, security attributes, etc. etc. etc.
Now, back to event partitions - your original question. You note
that there are not any pre-defined event partitions as there are
attribute partitions (defined as groups in the entity model). You are
correct. Problem is, noone really knows what they should be. The
only restriction is that ALL events of a given partition (for a
particular class) MUST be supported by a single management module.
Other than that, right now I think you are fairly free to register
your own event partitions. Maybe in a while, as events become more
pervasive within MCC, we will get some ideas about how we should define
some commonly defined event partitions.
Colin
| |||||
| 678.2 | lucked out | COOKIE::KITTELL | Richard - Architected Info Mgmt | Thu Jan 31 1991 19:14 | 8 |
Colin, First, thanks for the lucid description of attributes and groups. Second, I lucked out because I've been putting all the events supported by one access module into the same partition. | |||||
| 678.3 | 1:n | NMVT::WINKLER | Mon Feb 04 1991 09:15 | 10 | |
>Second, I lucked out because I've been putting all the events supported >by one access module into the same partition. It's the other way around, isn't it? Isn't the restriction that all events in a single partition be supported by the same MM, but not that all events supported by an MM be in the same partition? Kathrin | |||||
| 678.4 | Two partitions currently in use | GOSTE::CALLANDER | Tue Feb 05 1991 17:09 | 20 | |
I will have to reread Colins a bit more closely (I just breezed
over it), but Kathrin what you said is what we expect.
And for any one interested the partitions currently in use by the
base system components are:
Configuration Events (code 15 MCC_K_PRT_CONFIGURATION_EVENTS)
Notification Events (code 16 MCC_K_PRT_NOTIFICATION_EVENTS)
The codes are defined in sys$share:mcc_vea_def.h if you have installed
the latest toolkit.
We use configuration events for pretty much everything that has
to do with the configuration (like the real events coming in off
of the wire); while the notification events are more application
oriented these we use for passing things like rule firing information
(alarming).
| |||||