| > 1. When we exit DECmcc normally, several process of mcc
> continue running:
This is normal, and documented. MM processes continue until explicitely
terminated by mcc_kill.
> 2. If the MIR got an event, and a rule for that event had
> been defined, would this event be handled, or should
> we write some more code?
I don't understand this question. The MIR is not executable code.
Are you asking if the alarms FM will process certain kinds of events?
> 3. If a counter got a value or changed his value in the
> AM I had written, how is the display beeing done:
> automatically or some code should be written?
Again I'm not sure of your question, but the alarms FM is generic, so
you can write rules that work for attributes returned by any AM.
I don't know about 4.
> 5. In order to integrate the AM into the DECmcc, we should
> give it an address in order to register it as an entity:
> what is this address?
Send mail to DSSR::MCC for information about registering your MSL.
|
| Ok. I'll try to be more clear.
We have to write a network interface who "talks" with the
the real ports of our DECsystem, so this interface deals
with the actual/"real" addresses.
The network interface gets events from the ports and has
to pass them to DECmcc in order to deal/make some actions.
My question are:
1. How is the communication between this external application
to the DECmcc and from the DECmcc done?
(MCC_CALL_INTERFACE is used just among the different MM
inside the DECmcc)
2. What address should the entity inside DECmcc, who deals with this
network interface, be given (for registeration porpuse)?
Orna.
|
| re: question 4 (and .4)
I'm not sure I understand the situation you're describing in sufficient
detail, but let's try and answer what I *think* you might be asking...
If you're writing an Access Module (actually any module) that is
presenting a view of some managed object, you have a certain amount of
control around the way that managed object is manifested across the
mcc_call interface.
Typically, one would want to 'model' the managed object in some way
that is natural (or at least, not unnatural) to the (human) manager.
However, if you wish to make the managed object appear to be completely
different, in one or more respects, that is your decision.
For example, if I have a multi-user application, which I wish to make
manageable, I might wish to represent the 'users' of the application
as managed objects. In order to distinguish these different users, one
has to choose an appropriate identifer. I can think of the following
possibilities, among the universe of possibilities to identify the
managed object to be represented:
1) choose the username, providing it is unambiguous
2) choose a process ID, again assuming it's unambiguous
3) choose a random, unique, number assigned to each user on
starting to use the application
4) choose an integer, representing the number of nano-seconds since
Jan 1st 1970 when the user started running the application
5) etc. etc.
As you go from 1) down, you get more and more abstract. But that
doesn't matter to DECmcc. So you have to choose whether you want to
identify a managed object by something that is meaningful (such as a
username in this example), by something that is less meaningful (such
as a PID) or something that is completely obscure.
Thus, in your example, you *can* choose to name the ports according to
the port names assigned to the system (whatever that is). Or you could
choose to name them in a completely different way - however, for
usability, you would probably want to have a status attribute which
indicates the real (ie. system) port name, so the manager can relate it
to something that is meaningful to them.
I *think* this addresses point 2 from reply .4
For point 1 to reply .4, it is worth pointing out that any application
(with suitable preparation) is able to make mcc_call's - I believe this
is documented in the Toolkit doc set (if not, someone will correct me).
Colin
|