Conference azur::mcc

>> In the MSL example page 149 (figure 7.6) there is no identifier
>> of type FullName, only Phase4Address and Phase4Name. 
>>
>> Does this mean:
>>
>>  1). There is an inconsistency in the SRM ?

  Yes - I would say so

>>  2). If these two identifiers are being used, it is required to have a
>>      third identifier of type FullName?

  You need another identifier (say, Registered Name) which is of type
  fullname - if you want to register your entity to MCC.

>>  3). The Name attribute should be of type FullNname, but in addition the
>>      AM should register something as a SYNONYM as a required input argument
>>      during the register phase, and it is the responsability of the AM to
>>      make a MCC_DNS call to convert from FullName to Phase4Name, using the
>>      SYNONYM from the DNS name space, any time that identifier is used?

  Yes, this is correct.  For the Sample AM & v1.2 we have added Registration.
  The Identifiers are set up as:

    Registered Name:  FullName
    Name:             Phase4Name
    Address           Phase4Address

>>  If that example on page 149 would have the 3 identiferes, how will
>>  DECmcc make a distinction between the Identifer of type FullName,
>>  against the identifier Phase4Name ?

  The FullName Identifier begins with a "." and the Phase4Name doesn't

--------

The rest of your note regarding the SHOW DOMAIN and the ILV output
I am not familiar with - sorry

/keith

    I am not sure a DNS FullName always starts with a ".", because a
    generic DNS name is of the following form:
    
    	NAME_SPACE:.dir.subdir.object
    
    	Dominique.

>>  I am not sure a DNS FullName always starts with a ".", because a
>>  generic DNS name is of the following form:
>>  
>>  NAME_SPACE:.dir.subdir.object

You are correct.  The "." prefix means to use the default name space.  If
you prefix the fullname with a specific name space, the parser still knows
its a fullname and uses the name space you specify.

/keith

    I am managing a VMS application, accessed by a DECnet logical link.
    
    The DNS PRIMARY identifier is a FullName
    The only DNS ALTERNATE identifier ia a Phase4Address
    
    Also I use the algorithm, that the last part of a DNS FullName is used
    as the DECnet node name: e.g.
    MY_NAMESPACE:.root.mydirectory.MYNODE corresponds to the DECnet phase 4
    node name "MYNODE"
    
    The real data was
    	Nodename	BRSADV
    	Address		48.15 (49179)
    	FullName	DECTOWN:.mcc_servers.BRSADV
    
    First, MCC seems not be able to distinguish between an Address or a
    Fullname.  This means that a command as
    
    SHOW application 48.15 all identifiers
    
    	does encode the "48.15" with a MCC data type "FullName", where I
    expected a Phase4Address.  This puts me really into troubles, as I have
    no means any more to distinguish between a node name and a node Address,
    except perhaps with dirty tricks.  
    
    How is this solved in the modified version of the MCC SAMPLE access
    module?  Are the sources reachable over the network?
    
    Secondly,  I was astonished that my access module still worked.  This
    is a bug or a feature of DECnet:
    
    Because 48.15 was passed as a FullName, the AM decided that the
    DECnet nodename had to be "15", and encoded this in the Network
    Control Block.  So the DECnet connect executed something as
    	15::"Task=MY_TASK"
    which means node number 15 in my DECnet area. That's why the
    application works, although DECnet did not got the full DECnet address.
    
    	The main problem however remains:
    
    WILL DECmcc will ever distinguish between a Phase4Address and a DNS
    FullName ?
    
    Dominique.

>> How is this solved in the modified version of the MCC SAMPLE access
>> module?  Are the sources reachable over the network?

I will double check that the Sample AM works properly under the conditions
that you have described.

Yes - the source code is available - I can mail it to you.  It is a routine
which determines if the Global Instance is a FULLNAME, and if so pulls out
the last simple name (.mcc_servers.brsadv --> brsadv).

But, if you are passed the phase4address with a datatype of fullname,
my code won't help much.  Perhaps it is the order in which the identifer
attributes are defined in your MSL - sounds silly, but I've heard stranger
things before.

The sample identifiers are defined as:


(*
 *  Identifier Attributes
 *)

        IDENTIFIER ATTRIBUTES

        ATTRIBUTE Address = 1 : Phase4Address
           DNS_IDENT = ALTERNATE_NAME,
           ACCESS = NONSETABLE,
           DISPLAY = TRUE,
           CATEGORIES = (CONFIGURATION),
           SYMBOL = SAMPLE_ADDR
        END ATTRIBUTE Address;

        ATTRIBUTE Name = 2 : Phase4Name
           DNS_IDENT = ALTERNATE_NAME,
           ACCESS = NONSETABLE,
           DISPLAY = TRUE,
           CATEGORIES = (CONFIGURATION),
           SYMBOL = SAMPLE_NAME
        END ATTRIBUTE Name;

        ATTRIBUTE Registered Name = 10 : FullName
           DNS_IDENT = PRIMARY_NAME,
           ACCESS = NONSETABLE,
           DISPLAY = TRUE,
           CATEGORIES = (CONFIGURATION),
           SYMBOL = SAMPLE_REGISTERED_NAME
        END ATTRIBUTE Name;

        END ATTRIBUTES; (* IDENTIFIER *)


/keith

RE: .4

You are having a parsing experience.  If your .MS looks like the one 
below, there may be help.  Essentially, when you type in your instance,
the parser is trying to figure out what datatype this ASCII string maps
to. 

Notice the line

      IDENTIFIER = ( Name, Address ),

the parser is going to try to fit whatever you typed into the datatypes 
specified for your identifier attributes IN THE ORDER YOU SPECIFIED.

I am willing to bet that you listed the identifier of datatype Fullname 
first.  Fullname is a broad datatype.  Most ASCII strings will be valid 
fullnames.  If you reverse the order and put Address first, your 
problems will probably be solved.  Non-numeric characters are not valid 
for Phase IV addresses so the Name will never be mistaken for an 
address.  And the form dd.dddd will be correctly identified as an 
address.

Hope this works for you 

...kjn

    MANAGEMENT SPECIFICATION MCC_yourentity_am_srvc_if;
       VERSION = V1.1.0;
       SYMBOL-PREFIX = MCC_;

    GLOBAL ENTITY YOURMM = xx :
       IDENTIFIER = ( Name, Address ),
       SYMBOL = CLASS_YOURENTITY,

       IDENTIFIER ATTRIBUTES

             ATTRIBUTE Name = 1 : FullName
                DNS_IDENT = PRIMARY_NAME,
                ACCESS = NONSETABLE,
                DISPLAY = TRUE,
                SYMBOL = ATTR_Name,
                CATEGORIES = ( CONFIGURATION )
             END ATTRIBUTE Name;

             ATTRIBUTE Address = 1 : Phase4Address
                DNS_IDENT = ALTERNATE_NAME,
                ACCESS = NONSETABLE,
                DISPLAY = TRUE,
                SYMBOL = ATTR_Address,
                CATEGORIES = ( CONFIGURATION )
             END ATTRIBUTE Address;

       END ATTRIBUTES; (* IDENTIFIER *)

    Before you change your MS know that help is on the way!!!!
    
    As it is now the use of the identifier definition in MS is over-
    burdened. It is used to denote both the parse order and the
    primary,secondary identifier ordering for the entity. Well
    these things need to be mutually exclusive or you have a big
    problem on your hands, like what you are seeing. 4.111 IS a
    valid fullname that is why you aren't seeing it as an address,
    and without changing your MS you won't ever see it as an address.
    
    In V1.2 we are working to make it so that your parse order can
    be anything you want, and that whenever you enter a register
    command (the only one that we know REQUIRES you use a fullname)
    that is is always interpretted as a fullname. More on that when
    the fixes are complete with v1.2 EFT.
    
    

    IDENTIFIERS = (.....) was the key to the success.
    
    With first the Address identifier, followed by the FullName identifier,
    it works as expected.
    
    Thanks to you all who responded.
    Regards,
    Dominique.

    
    Is it a requirement to have global names fullnames for DECmcc 1.2?
    If it is not, what are the implications of not having fullnames?
    (Looks like it won't appear in iconic map, and I wonder about global
    instance wildcarding.)
    
    		thanks,
    
    			Bonnie

    At least one of the identifiers of your entity must be a fullname
    datatype in order to register the entity.  If you can't register the
    entity you can't do global instance wildcards obviously.  And you can't
    put it into a domain - so no iconic map support.
    
    However, there is no enforcement of this requirement.  People have
    written AMs for simple non-registerable entities without fullnames
    and have successfully used them from the command line interface.
    
    Also note that once you've registered yout entity, you don't need
    to use its fullname to refer to it - you can use one of its native
    identifiers.