|
Check note 3.58 in this notes file for the location of the
"management module programming" manual. The file is in the list as
something like "...MM_PROGRAMMING_V11...". You'll see it when you
look through the note.
That is the latest and greatest copy off our guide to writing an AM.
I'd also suggest grabbing a copy of the Toolkit release notes
"MCCTK011.RELEASE_NOTES" in that available directory. It has a list of
other useful documents in it that can help, depending on your level of
confidence with EMA and DECmcc. Most of those documents also have
pointers in that note.
The only document I know of that you can't get online that you will
definitely need is the "system reference manual". You can learn a lot
without it, but should order yourself a copy as soon as you can.
Event handling is part of the DECmcc Director V1.1, which is the part
of EMS that is dealt with in this notesfile, and the place for an AM
that handles Alarms like the ones you describe.
Minimally, you will have to model those aspects of your devices or
package that originate Alarms. Then the most limited possible AM would
accept GETEVENT requests, allow the showing and setting of
reference attributes, and allow the registration of your managed
objects, which is very easy for you to get. GETEVENT has a lot of
generic support in DECmcc, and the registration FM supports your
registration functions and reference attributes in a straightforward
way.
Finally, you will need a process (possibly this package being pieced
together by NABNASSET) that will translate your Alarms into MCC Events,
and deliver them to DECmcc so that they can be processed and delivered
to the DECmcc interfaces.
This does REQUIRE the DECmcc Director V1.1, which will be packaged on
EMS/SMS soon... but I don't know details on that.
Registering your managed objects allows them to be included in domains
and displayed on our Iconic Map. It may be required by our NOTIFY FM
(I'm not sure) in order for Notification Services to collect these
events and present them to the user.
Anyway, the "Management Module Programming" guide is a good place to
get an overview of what the features of DECmcc and what requirements you
must meet to take advantage of these features. Next place to spend
some time is the SRM, which as far as I know is the only place for
definitive information on Event collection and the services DECmcc
offers in that direction.
The toolkit also includes what we call MRMs (Module Reference Manuals)
about all of the Management Modules currently in DECmcc. The
Notification Services MRM, the Registration MRM, and possibly the
Alarms MRM are worth looking at as they provide the bulk of the
services you are probably going to be interested in.
Hope this helps get you started.
-Jim Carey
The outline I tossed out here for an event delivery system closely
coincides with the model we used for performing the event delivery work
for DECnet Phase 4, which works fine.
|
| As to how much to bid,,,,
I am the development manager for Decnet and OSI AMs and have been
involved with DECmcc from before it started.
We have had experience with bringing in developers from other parts
of DEC and jump starting them on access module development. Currently
we have 2 engineers from DEC Australia EIC working in LKG doing a
project for an Australian Customer.
They have the prototype AM doing registration, show, and set working
in 9 intensive days of effort. I would estimate that within one
month they will have a fairly polished product and their development
is much more complex than just a simple AM. In addition they have
to write a Mediator Server on a PC which talks to the AM.
One of the engineers had a one week course in Developing an AM. The
other one had only informal training via access to the toolkit. Both
are very intense developers willing to work 10-12 hour days and
are highly motivated to completing the task so they can go home. They
are also very polished VMS users.
For people with these kinds of skills, I would suggest that for the
AM as described by Jim Carey in .1, that you need 1 man month per
engineer to ramp up on DECmcc and another man month to actually do
the prototype AM. I would suggest writing the contract for 3 man
months for a minimal function AM and when successful you will have
enough knowledge to write a follow on contract.
You might also want to contact Jon Goodridge (TOOK::JSG) and get an
engineer into MCC College into the course for designing Access
Modules. That might actually shorten the ramp up time and possibly
reduce the effort of getting the minimum AM working.
wally
|