Conference azur::mcc

> When an entity is registered, how do you specifiy which identifier
> attributes must be entered manually (ex : for a bridge, you have to
> enter a name AND and Ethernet address) ?
>
> ...which identifier...in the  in_entity parameter ?
>

For the Bridge (and Station) entity, both the name and ethernet address
must be specified (In_Entity must contain FullName, and the Address Argument
must contain an ethernet address) for the REGISTER to succeed.

Registration FM requires this (at least for Bridge and Station).

I believe the Guide to Writing an Access Module (or something like that)
contains details of the Registration FM <-> AM handshaking during Register.

> ... mentionned that to register an entity also registers it's child
> entities. I thought only global entity identifiers were stored in DNS ?

Whether child entities are automatically stored in DNS is deternimed by
the MS file for the entity. If an entity is marked as DYNAMIC = TRUE, then
it isn't autoregistered on REGISTER of the Global Entity.

						Chris

>    4) Alarms FM :  
>    
>    Can alarms expressions include wildcarded global entities ? If so, will
>    the alarm testing be restricted to the domain in which the alarm was
>    defined ?
>    

     V1.1 Alarms does not support global entity wildcarding. We will support
     it in V1.2. And yes the global entity wild card will be expanded to 
     all the entities within the domain context.

     - Anil

    The new SRM does document an internet protocol address and an internet
    name. These should meet your needs. When you get the new document
    you will find them on pages 244 and 245 of volume 1.
    
    The MSL names for these data types are ipaddress and internetname.
    
    

    Thanks for all the replies.
    
    Re : .1
    
    The MM development guide is not too explicit about this handshake,
    particularly concerning entites whic have more than one identifier. My
    question was not really about which attributes are mandatory when
    registering "standard" attributes, but rather how do you specify (in
    the MSL ? ) that an attribute is required when an entity is registered.
    
    Is it possible to make reference attributes mandatory ?
    
    Re: .2 
    
    Yes, I can wait, and so will my customer if he knows he will be able to
    do it in V1.2. %^)
    
    Re: .3
    
    Santa Claus forgot to bring the new SRM. Oh, how I long to hold it (the
    1.1. SRM) in my arms.... Seriously, I called someone from Engineering
    in Valbonne who said he would send me one today ! Hopefully, 99,99% of
    my questions will be answered by monday ! 
    
    Amicalement,
    
    Philippe.

> RE 586.4
>
> The MM development guide is not too explicit about this handshake,
> particularly concerning entites whic have more than one identifier. My
> question was not really about which attributes are mandatory when
> registering "standard" attributes, but rather how do you specify (in
> the MSL ? ) that an attribute is required when an entity is registered.

  Here's some quick answers, with STATION used as the example:

  1. On REGISTER STATION, In_Entity contains FullName. Other
     ARGUMENTS to the Register directive can be used to specify
     additional IDENTIFIER attributes. By specifying REQUIRED = TRUE in
     the MS for these arguments, you are making them "mandatory". If they
     are specified as REQUIRED = FALSE, they're not. Example:

	REGISTER STATION <name> ADDRESS = <addr>
			[, ALT ADDR = <addr>]
			[, FUNC SUPP = <funcsupp> ]

      for Station, ADDRESS is required (and happens to also be an IDENTIFIER
      Attribute), the other Arguments aren't required.

  2. On REGISTER, arguments that do NOT represent IDENTIFIER attributes
     may be specified. In the example above, FUNC SUPP is a CHARACTERISTIC
     that the Ethernet AM (via MCC_DNS routines) writes to DNS. This
     REGISTER Argument is optional in V1.1, but was required in V1.0.

  3. On REGISTER, the Registration FM calls the AM's REGISTER Entry Point
     and passes it all of the arguments supplied by the user. The AM does
     verification of arguments, writes the FUNCTIONS SUPPORTED value
     to DNS (entry in DNS already created by Registration FM), and caches
     the NAME at this point.
     The Registration FM then calls the AM with a SHOW ALL IDENTS, and the
     AM responds by returning all identifiers (including the previously
     cached NAME).

   I'll have to check the Guide again, but I was almost positive that this
   information got in.

   Does this seem confusing?

>
> Is it possible to make reference attributes mandatory ?
>

   I'll have to defer to Pat here, since I don't know what problems would
   exist in doing this from the REGISTER entry point.


						Chris Brienen

    Re : .5 :
    
    Ok, I understand what happens during the registration process. Now,
    after I've registered entities, how is this information (GET ALL
    IDENTIFIERS) used by the various modules ?
    
    Ex : supposing I have a station , it has two identifiers : 
    
    o A DNS Fullname which you could compare to a "logical", as it does not
    allow me to communicate directly with the entity
    
    o An address (08-00-2B-whatever).
    
    If I then do a  :
    MCC> Register station toto, address = 08-00-2B-XX-XX-XX
    MCC> Show station toto all char
    
    To retrieve the Characteristics partition, the AM needs the address of
    bridge toto.
    
    Which module has to perform the DNSFullName -> Ethernet address
    translation ? Is it the PM using registration FM services ? Or will the
    DNSFullName be passed as in_entity to the access module ?
    
    More questions in both cases :
    
    Case 1:
    
    If the PM or FM does the translation, we assume the address is passed
    to the AM. This is ok, we can now talk to the object. However, if we
    have a complex object which responds to 2 or more identifiers (ex :
    Station has Hardware and Physical address), which secondary identifier
    will be retrieved and passed to the AM ? Is it the order in which
    identifiers are defined in the MSL which prevails ?
    
    Case 2:
    
    The AM gets the DNSFullName as in_entity. Which set of MCC routines
    does an AM call to access information stored in DNS ?
    
    Many thanks for your help,
    
    Philippe.

    Philippe,
    
    The PM only encodes what the user enters (in 90% of all cases) and
    passes it along. In this case that is exactly what is done, so the
    AM will get the full name. It is then up to the AM to translate
    it into the needed identifier. There is a routine,
    mcc_dns_get_identifiers, which should do what you are looking for.
    
    I am NOT an AM developer (PMs and FMs only) so some one out there
    might actually know something easier to do, but I don't.
    
    good luck
    jill
    

    Jill,
    
    Thanks.... I expect this is part of the 1.1 SRM, as it does not appear
    in my version of the SRM... As I said earlier, all will be clear next
    week !
    
    Have a nice week-end (It's friday night here !)
    
    Philippe.