Conference azur::mcc

    If you are doing primitive services in your AM, why do you need to call
    an FM?   Sounds like you have some structuring/laying problems that
    need to be looked at.
    
    The whole idea of AMs is to normalize the view of managed objects such
    that they all respond to a similar set of primitives.  That way the
    generic FMs we supply (alarms, control, historian, etc) will
    automatically support your entity class simply by enrolling your AM.
    
    If you implement your primitives at FM level, you will not be able to
    access them from our generic FMs.
    
    
    

RE: .1

Jim,

The entity class I have in mind, as I said in my previous note, is not a 
physical object. It is more like a virtual support object, a little bit like 
the domain object. Some of the services might be fullfilled by accessing a MIR 
repository, but I may need to call other FMs to fullfill some of the primitive 
services.

According to the SRM 1.1 (2.5.1 page 19), AM to FM call is not allowed. 
Therefore, my MM will be an FM. But, still according to the SRM (2.3.3 page 14), 
primitive services should used the access dispatch tables and I fully understand 
the rationale behind that. 

Do you systematicaly put primitive services in the access dispatch tables and 
value-added services in the function dispatch tables ? It seems so from reading 
the SRM, but in that case, how do you decide what service is a primitive one 
and what service is a value-added one ?
   

Marc.

>    If you implement your primitives at FM level, you will not be able to
>    access them from our generic FMs.

   Jim, this is NOT true at least in one case.  The Alarms FM utilizes the MCC 
   CALL_FUNCTION to get the data necessary to evaluate a rule expression:

     CALL_FUNCTION (SHOW...) or CALL_FUNCTION (GETEVENT...)

   Since the Control FM enrolls all primitive AM services in the FM dispatch
   table, this strategy works fine.  That is, if no other FM can service the
   request, then the Control FM will redirect the call to a CALL_ACCESS function
   which will access the AM dispatch table to complete the service request.

   Thus, Alarms can be used to alarm on data available from either an FM or AM.
   Alarms on statistics (available from the PA FM) is proof that this works!

   I don't personally know how the other generic FMs that we provide work.  
   Maybe the appropriate PLs could provide this info?

> That way ... support your entity class simply by enrolling your AM.

   I don't mean to seem overly picky, but I just wanted to say something about 
   the phrase "simply by enrolling your AM".

   It seems that we (engineering in general) tend to over-simplify just how 
   simple this is.  Please remember that not all "generic" FM services are 
   available just by "simply enrolling your AM".  Regrettably, you may also
   have to AUGMENT the MCC data dictionary with the MSL definitions of the 
   generic function which you wish to utilize (e.g., Historian, Export).  Not
   all generic FMs require this, but some do.  I do not mean to pick on these
   FMs, but AM developers should be aware of exactly what needs to be done
   to take advantage of our generic FMs and we shouldn't trivialize (or hide)
   the steps involved.

                                                                      - Jerry

   P.S. - Jim: Forgive me for using your note to jump on a mini-soapbox! ;)

    The notification FM also does the same thing as alarms. By making
    use of the control FM the notification functions always make a call
    function for requesting event information. By doing this we don't
    have to make any descisions about who (am or fm) supplies the service,
    if the getevent command we are looking for is not in the FM table
    then control passes it along for us.
    
    

The iconic map also only does a CALL_FUNCTION.  

/Jim

    
    RE:.2
    
    There isn't much difference between what an AM does and what an FM
    does.  Sometimes it is obvious that you are providing value-added
    functions only, and sometimes it is obvious that you are providing
    primitive management for a new entity only.
    
    More often the line is somewhat blurred.  The Alarms FM for instance,
    clearly provides value added services to any entity.  Yet it can be
    argued that an alarm Rule is an entity, and is managed with primitive
    operations such as CREATE, DELETE, ENABLE, and DISABLE which act on
    this rule "entity".  I don't have any problem with the current state of
    the Alarms FM, because it does its job quite well.  It just may be that
    it does some functions we expect an AM to do, and some functions that
    we expect an FM to do.
    
    I don't think that users are ever going to care what we call the
    modules.  What's important is that DECmcc and its module extensions
    provide the services that network managers need to control their
    networks, and that the tools we construct from it are easy to use and
    effective.
    
    As you get further into the management modelling of your "virtual
    support object" you may find that what you are dealing with is clearly
    an AM.  You may find that it actually has components of both that can
    be clearly divided so that you end up with an AM and an FM.  Or you
    might find that it works best when thought of as an FM.
    
    In any case, if our users have to care about the type of module it is,
    then we've made some serious mistakes.  I think that we want them to
    care about what it does to make their life simpler.
    
    So see how it fits in, and if there's a problem, you can change the
    name later!
    
    -Jim Carey
    
    
    

    Re: .0:  2 years ago, I wrote a Repeater AM which sounds similar 
    in concept to what you described.  It was a "protocol-less" or
    "fictitious" AM because it didn't really talk to real repeaters,
    it just remembered what you told it about repeaters.  This function
    was derived from the old etherNIM product.  I don't know what
    happened to it, but there didn't seem to be any real reason why 
    you couldn't write your s/w as an AM.  I'm not taking sides on this,
    just providing a data point :->
    
    ben