Conference azur::mcc

    The AM is going to have to keep its own count.  Doing this in a
    general way in the registration database is difficult - for one thing
    you normally have pseudo-entities like domains or references entities;
    how would such things be counted?
    

>
>    The AM is going to have to keep its own count.  Doing this in a
>    general way in the registration database is difficult - for one thing
>    you normally have pseudo-entities like domains or references entities;
>    how would such things be counted?
>    
Lets seperate the issue into 2 problems:

1. This is really addressed to project management:
	A. Was the possibility of licencing DECmcc AMs by the amount of
	   entities ever considered? 
	B. Is some sort of "Proper" solution
	   (I.E Registration FM checking LMF licence before registering
            an entity) planned for future version? 

2. For the time being if I want to do the licensing stuff in the code of my AM
   then I need a quick way to count the number of XYZ entities registered.
   For example, I could check this number at the beginning of the SHOW
   and SET procedures and refuse to operate if the number of XYZ entities
   is too high. 

I guess my real question is: Is there a QUICK way for an AM to get the number
of registered entities of a CERTAIN CLASS? It must be fast because it is
done at every AM command and should not spoil performance for legitimate
use of the AM.

Or maybe you have a different approach that can solve this problem? I will
be glad to hear about it.

Peretz Gur-El

    Question 1. Yes, we considered it. There were many options discussed.
    When we decided that internally it did not match our business model
    we abandoned the discussion with no conclusions. At that time, no
    SVP or ISV was requesting support for this kind of a business model.
    
    Question 2. The best solution that I can provide is the following.
    Each AM must provide a registration entry point for each object
    that the AM supports. The registration FM calls that entry point
    for each registration. If the AM keeps a count of entities somewhere
    in non-volatile storage, then the AM can know when the count reaches
    the customers license limits. It can prevent the registration of the
    new entity/object.
    
    Now we will deal with the more difficult part. What happens when I
    deregister an object. In this case, we do not call the AM, thus the
    AM's count may get out of synch with what is in the registry. My
    suggestion is that each time the AM is registered, it can go to
    the MIR and count the number of items of type xyz that are registered
    and change its stored count as appropriate.
    
    wally

    Yes we do call the AM at its DEREGISTER entyr point, if it has one.
    

Re .0:

And don't forget, registration is a global operation, not local to an AM.
If a network had two MCC's  installed, and both had this software house's
AM installed, one could Register the entity, and the other could Deregister it.
Boy would that mess up the counts :-).

I suspect the software house needs to rethink of how AM's are bound to 
particular global entities, and work out who keeps track of what where,
and how an AM instance "knows" this global entity name is his.

						Mark

PS, if that software house ever figures out how to answer those questions,
let us know. We have 3 or 4 AM development groups in house they can teach
the answer to. :-)

>And don't forget, registration is a global operation, not local to an AM.
>If a network had two MCC's  installed, and both had this software house's
>AM installed, one could Register the entity, and the other could Deregister it.
>Boy would that mess up the counts :-).

This is still in the far (V2.x) future, isnt it? 

>I suspect the software house needs to rethink of how AM's are bound to 
>particular global entities, and work out who keeps track of what where,
>and how an AM instance "knows" this global entity name is his.

This should really be done by REGISTRATION FM. I hope that in V2.0 the
registration FM will include this feature. Doing it in the AM is only
a TEMPORARY solution...

Peretz

    why would you consider it a future. The registered inforamtion can
    be stored in DNS, and you can have multiple mcc's/users all
    accessing the same registered information. This would mean
    that the only method for an AM to track the current totel
    would be to have some form of communications between
    the different MCC systems so that each MCC can know the
    count (without haveing to dir a directory of the entire
    database to check it out). This level of distribution is working
    in even v1.1.
    
    

    Peretz
    
>This is still in the far (V2.x) future, isnt it? 
    
    Nope, as Jill said, that's how it works today.
    
>This should really be done by REGISTRATION FM. I hope that in V2.0 the
>registration FM will include this feature. Doing it in the AM is only
>a TEMPORARY solution...
    
    Nope, I doubt it will. "Registration", at least the critical operation
    of creating a name in a name server (whether DECdns or some other) for
    a global entity, is a low leve,l very basic, very primitive operation.
    It has to be done "first", before much else works. Among the data that
    has to be stored in the name server is the necessary addressing
    information needed to talk to the global entity. Since that varies from
    protocol to protocol, that can only be done down at the "AM" level
    
    				Mark

>    Nope, I doubt it will. "Registration", at least the critical operation
>    of creating a name in a name server (whether DECdns or some other) for
>    a global entity, is a low leve,l very basic, very primitive operation.
>    It has to be done "first", before much else works. Among the data that
>    has to be stored in the name server is the necessary addressing
>    information needed to talk to the global entity. Since that varies from
>    protocol to protocol, that can only be done down at the "AM" level

Now I am really confused:
1. Didn't you indicate in previous notes that counting entities in the
   AM level is not the right way to go and is problematic in case of
   distributed operations?
2. I do not understand your argument:
	A. Registration is very basic and primitive operation.
	B. Addressing info varies from entity to entity.
   I do not see why A & B leads to the conclusion that REGISTRATION FM is not
   the right place to count the number of already registered XYZ entities (and  
   refusing to register another XYZ entity if this number is too big).

Peretz

    The AM is the right place to put it as this is not a general
    requirement.
    
    The AM's private data space (in memory or on disk is NOT the place to
    keep the count because of the distribution phenomenon.
    
    The right way is to have the AM maintain the count data as a private
    (orphaned) attribute in the global namespace.  You could create
    a dummy instance which would carry the count attribute.   Or you could
    simply do a mcc_dns_get_identifiers and count the number everytime
    your AM is called at the REGISTER entry point and refuse registration
    if too big.
    
    In any case there are various ways to solve this at AM level without
    having to wait for some MCC base system future.