| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3115.1 | Your GETEVENT directive should support Global Wildcards | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Tue Jun 02 1992 14:25 | 13 |
| Dominique,
I don't know what the Notification FM is doing .. or why .. but your
Management Module GETEVENT directive should support a Global Wildcard.
The good news ... your directive need only validate (ie, accept) a global
wildcard for GETEVENT and pass it on to the event manager; as the event
manager can handle a global wildcard.
If you are using the Toolkit Design Framework, check out the the Example
FM GETEVENT directive source code for more information.
/keith
|
| 3115.2 | I regret this became a requirement ! | KETJE::PACCO | | Fri Jun 05 1992 18:25 | 32 |
| Keith,
Thanks for this info. I assume this requirement is one of the new
1.2.7 field test, because I have never encountered this before.
I haven't seen this requirement in the books too. I hope all these "special"
requirements will be CLEARLY documented in the developement manuals,
otherwise we will suffer from phone calls from all customers developing
management modules.
This change in requirement has broken two of my access modules, and
makes the implementation of one of these now a LOT more complex now.
In fact because my access module has now to support a wildcarded global
entity for the GETEVENT directive, and because I get my events from
a GETEVENT to the generic SNMP access module, I now will receive ALL SNMP
events, even the ones in which I am not interested in, and the amount of
these can be 100 times more than the ones I have to consider.
This means first a lot of CPU cycles lost.
But the MAJOR PROBLEM is now that the AM should try to find out if a
SNMP event has to be processed or has to be discarded, just based on the
IP address. The SNMP event carries NO information about the type of
entity from which it was generated.
The conclusion of all this:
This requirement implies a VERY serious increase in COMPLEXITY of
the AM coding to work around this, therefore also several more weeks
for developement, and a serious impact on the (already lousy) performance
of the system.
Dominique.
|
| 3115.3 | Services Offered and Services Required | TOOK::STRUTT | Management - the one word oxymoron | Sun Jun 07 1992 05:02 | 16 |
| I would expect that the 'requirement' that notification requires the
service of Getevent on a global wildcard to be located in the MRM for
the Notification FM.
It is important that MM writers understand the importance of matching
'services offered' by one module with the 'services required' by
another in order that the two modules interoperate. We have chosen MRMs
as the means to document the services:
PMs generally only require services
AMs generally only offer services
FMs usually both offer services (to PMs or to other FMs)
and require services (of AMs or of other AMs)
(Of course, all MMs would normally offer services corresponding to
their self management).
Colin
|
| 3115.4 | Some Notificaiton Help | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Mon Jun 08 1992 12:36 | 5 |
|
Could someone from the Notification Team help here. What are the
requirements (services required) of the Notification FM?
/keith
|
| 3115.5 | Also in the RELEASE NOTES please. | KETJE::PACCO | | Tue Jun 09 1992 19:04 | 11 |
| As a MM writer it would be nice to be "informed" about these changes,
and not find out in the hard way that suddenly from a certain version
on something does not work any more or breaks. Just updating the
NOTIFICATION MRM is not enough, because you cannot expect people to go
through ALL manuals to find out of something changes compared to the
previous version.
This is clearly something to write down in the release notes !
Dominique.
|