[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

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

3487.0. "AM questions." by TAVIS::ORNA () Fri Jul 31 1992 20:20

    My customer has started to use DECmcc on ULTRIX for
    management and for development of an AM.
    
    We have some questions:
    
    1. When we exit DECmcc normally, several process of mcc
       continue running:
       mcc_notification_fm 10 N
       mcc_domain_fm 6 N
       mcc_alarms_fm 2 N
    
    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?
    
    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?
    
    4. According to what is written in the book, AM should
       handle real ports.
       If we have a network interface which handles the real
       ports and the AM gets the information from it (the
       AM handles a logic port), what address should we
       give instead the real port?
    
    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?
    
    
    Thanks for any response,
    Orna.
    
T.RTitleUserPersonal
Name
DateLines
3487.1Some answersTOOK::MINTZErik Mintz, dtn 226-5033Fri Jul 31 1992 21:3528
>    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.

3487.2No answer for question 4?TAVIS::ORNAMon Aug 10 1992 14:201
    
3487.3What does it mean?TOOK::MINTZErik Mintz, dtn 226-5033Tue Aug 11 1992 04:596
I'm afraid I don't understand question 4, and it may be that nobody
else did either.  Which AM (and which book) are you refering to, and
what is a "real port"? 

-- Erik

3487.4Question 4 - more clearlyTAVIS::ORNATue Aug 11 1992 10:0119
    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.
          
3487.5TOOK::STRUTTManagement - the one word oxymoronTue Aug 11 1992 17:1348
    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