| RE: .0
> 2) I believe that ALARMS FM V1.1 will also handle asynchronous events,
> and not just "request attribute/ examine response / FIRE rule"
> mechanisms. Does this mean that an event notification could fire a
> user-written procedure ?
Yes, in v1.1.
> 3) Our customer is investigating the possibility of developping some
> FM's. Because their applications will evolve, new applications will be
> added etc... they would like to make their FM's Generic, so the
> question is : do we have any estimates of how much more development
> effort it takes to write a generic FM as opposed to a specific FM ?
Since Alarms is one of the first generic FMs I'll take a quick stab
at this question:
This is not a very quantitative answer, but it isn't that much more
difficult to make an application generic. There are more calls necessary
to the dictionary, but they aren't too difficult (once you get a handle
on how dictionary `things' are named. The "reward" is worth the
additional effort!
I should add however that alot depends on what exactly you wish to make
generic! Should you find a need to post more specific questions, I'll
be happy to try to answer them.
> Will the FM Cookbook give guidelins on how to make FM's generic ? Will
> there be a "SAMPLE FM" ?
I will leave this part for the Toolkit team to answer.
- Jerry
Alarms PL
|
|
> 5) Initial Performance Analyzer works on exported data and produces
> "external" reports. Are there plans for a PM to present this type of
> data to the screen? Will there be a PM to present,say an "real-time"
> graph of "<whatever resource>" utilization ? Will we have guidelines /
> a cookbook on how to write a PM ?
The current PA does not work on exported data, it works on data
previously stored in the MIR (for past time statistic), or data
directly collected from the entity (current thru future time)
The "reports" package being developed does work off of the
exported data stored in the Rdb database. The Datatrieve
routines produce reports and DECgraph produces some graphical
reports.
Yes, we are planning to do "real-time" graphical reports,
perhaps as a part of the Iconic Map PM. The timeframe for
these is still be determined, but be assured we're
thinking/working on it. A PM cookbook is being planned for a
future release as well.
JCE
|
| Some additional answers to what's been said (typed) already. In
general, you won't get a commitment to a particular future version
of MCC - you will just be told (and you should ALWAYS explain it
to customers as) "future"
> 1) The historian FM provides recording of attribute data. Is there a
> mechanism to store asynchronous events ? Is this the "Historical
> Occurence recorder", and is there a defined timeframe for its
> availability ? Or could this handled by notification Services ?
>
This is planned to be part of Notification Services, in some future
release. Expect a capability similar to that needed to store historical
attribute data.
> 2) I believe that ALARMS FM V1.1 will also handle asynchronous events,
> and not just "request attribute/ examine response / FIRE rule"
> mechanisms. Does this mean that an event notification could fire a
> user-written procedure ?
>
yes
> 3) Our customer is investigating the possibility of developping some
> FM's. Because their applications will evolve, new applications will be
> added etc... they would like to make their FM's Generic, so the
> question is : do we have any estimates of how much more development
> effort it takes to write a generic FM as opposed to a specific FM ?
> Will the FM Cookbook give guidelins on how to make FM's generic ? Will
> there be a "SAMPLE FM" ?
>
We may not explain how to write Generic FMs when we first tell everyone
how to write FMs (ie. the second version of the Management Module
Programming guide). It is clearly more difficult to define the
management model for a generic FM than it is for a class-specific FM.
One aspect is the need to be able to augment both existing and future
classes with operations that apply to all classes - the method we may
choose to employ in early versions of MCC is likely to undergo changes
in the future. It makes sense to wait and document them only when they
are stable.
I don't know how to interpret your statement "they would like to make
their FMs generic". I'm not sure I believe that they understand what
this means. If they do, then they are perhaps able to do it already
based on the info we provide in the SRM.
> 4) A requirement we often get is how to follow up events / alarms (log
> calls to the vendor, etc...). Is this type of functionality planned at
> all ?
>
I assume you are referring to some sort of trouble-tracking, work-order
system. This is certainly in our thoughts for future work.
> 5) Initial Performance Analyzer works on exported data and produces
> "external" reports. Are there plans for a PM to present this type of
> data to the screen? Will there be a PM to present,say an "real-time"
> graph of "<whatever resource>" utilization ? Will we have guidelines /
> a cookbook on how to write a PM ?
>
>
As John says, yes we plan to make PMs present this on the screen, yes
we plan to have PMs present graphs. Information in the Management
Module Programming guide is likely to appear in a future version of that
document.
> 6) Last but definitely not least, thank you to all who answer these
> notes, your replies really help us to move ahead with DECmcc and beat
> Accumaster and Openview !
>
> An interesting comment from the project leader of the customer I'm
> dealing with :
>
> "I have been imagining something like EMA for the past three years,
That's funny - so have I
Colin
|