Conference azur::mcc

>> Does the DNS Primary_name identifier attribute have to be always of
   type FullName ?

   Yes - this is a requirement of the Registration FM (and DNS)

>> How do you register an entity having more than 1 identifier e.g. an
>> entity having NAME (primary_name) and ADDRESS (alternate_name)
>> identifiers. Do you have to use ADDRESS as an argument for a REGISTER
>> entry point and use the MCC_DNS... routines within the AM, e.g.
>> REGISTER TSC Bristol-01 ADDRESS=12345) ?

   As far as I know, when you provide your REGISTER directive, you specify
   you need arguments - as you described.  Your REGISTER directive would
   put the information (In-Entity and Arguments) into an in-memory cache
   or MIR.

   When you are called with other directives and In-Entity is of datatype
   FULLNAME, you search the cache (or MIR) to see what the address is, 
   then use the address (or whatever the alternate identifier is) to 
   complete the operation.

>> What is the most usual reason for the Register error:
>>
>>   %MCC-E-INV_IDENT, specified identifier attribute is not
>>      valid for instance lookup

   We'll have to save this one for the Registration FM team, sorry.

/keith

Some urgent questions about REGISTER:

a) Does the DNS Primary_name identifier attribute have to be always of
   type FullName ?

kjn>>  As stated in -.1 YES, it is a requirement.

b) How do you register an entity having more than 1 identifier e.g. an
   entity having NAME (primary_name) and ADDRESS (alternate_name)
   identifiers. Do you have to use ADDRESS as an argument for a REGISTER
   entry point and use the MCC_DNS... routines within the AM, e.g.
   REGISTER TSC Bristol-01 ADDRESS=12345) ?

kjn>>  The Registration FM calls the AM with a SHOW IDENT, For V1.1 the 
kjn>>  Registration FM expects to get the entire identifier partition, 
kjn>>  and will insert all of the alternate identifiers into the 
kjn>>  namespace.

kjn>>  The logic for the Registration process is specified in the MRM 
kjn>>  for the Registration FM.

kjn>>  You may have to do a bit of extra work in your AM if your entity
kjn>>  cannot return all of its identifiers, i.e.,  user input is
kjn>>  required to associate the name with the address, etc.

kjn>>  if you need help with this, send mail to me and we will discuss
kjn>>  how the AM needs to cache the name, address, etc in a Register 
kjn>>  entry point in the AM.  Your AM does not need to call any of
kjn>>  DNS routines to get alternate names in the namespace.


c) What is the most usual reason for the Register error:

	MCC Routine Error = %MCC-E-INV_IDENT, specified identifier
	attribute is not valid for instance lookup

kjn>> the most usual reason for this is that you have used an identifier 
kjn>> that was marked DNS_IDENT=NOT_USED in your MSL.  

	(We have used the guidelines for "minimal support for the
	 Registration FM" as described in MM dev manual). ??

knn>> Minimal support only works if the AM can always return the entire
kjn>> Identifier partition in response to a SHOW IDENT.  For example,
kjn>> DECnet nodes can always return their name and address, so the AM
kjn>> always has access to that information and can return it during the
kjn>> REGISTER.  Soooo... The DECnet AM theoritically did not have to 
kjn>> provide a REGISTER entry point.  Just an entry in the MSL.
kjn>> Bridges, on the other hand, do not know their name.  
kjn>> The Bridge AM must provide the initial mapping between name and 
kjn>> address by caching the name and address during the REGISTER 
kjn>> process.

>> c) What is the most usual reason for the Register error:

>>	MCC Routine Error = %MCC-E-INV_IDENT, specified identifier
>>	attribute is not valid for instance lookup


Just an additional note, I have also seen this error when there is no 
backtranslation directory defined in the DNS namespace for the global 
entity class.

One of the identifiers for the global entity class must be marked 
DNS_IDENT=PRIMARY_NAME in the MSL.  Hopefully, the identifier of type
Fullname.  For the other identifiers, you have the choice of marking 
them DNS_IDENT=ALTERNATE_NAME or DNS_IDENT=NOT_USED.  

If you have identifiers marked ALTERNATE_NAME, you must have a 
backtranslation directory defined in the DNS namespace.  You can look 
in your namespace with the browser or DNS$CONTROL utilities.  You will 
see backtranslation directories for BRIDGE and STATION.  Your directory 
must be named in a similar fashion:

	.MCC_<classname>_BACKTRANSLATION

where <classname> is the name for the global entity class as specified 
in your MS.  It is under this directory that the softlinks for each 
alternate name are stored.  They provide the same function that an 
alternate key would provide in an ISAM file or database - lookup by an 
alternate name and also name-to-alternate_name translation.

...kjn

    I think you have to support an identifier of datatype fullname
    to get it to work, but I am uncertain with all of the changes
    that have happened in that module. I have sent your request for
    assistance off to the developers. If you have resolved the problem
    please post the solution.
    
    thanks
    jill