Conference azur::mcc

    
    RE: .0
    
    The only constructed data type supported for Global entity's alternate 
    identifiers is MCC_K_DT_SET_OF type in mcc_dns_add_identifier().
    
    "Alternate identifier" means that there is a DECdns softlink
    (backtransltion link) that you can use instead of a registered name
    (fullname). For example, IP name is an altenate identifier and the
    corresponding softlink is in .MCC_SNMP_Backtranslation directory.
    
    If you need to store the RECORD datatype information, you may define
    it as a characteristics attribute, and store the value in DECdns by calling
    mcc_dns_write_attr_data().
    
    William

    Hi,
    
    This puts me in somewhat of a spot : What I'm trying to add *is* an
    alternate identifier for which I *need* backtranslation facilities, and
    which is made up of 6 different fields. My choice of RECORD constructed
    type was made based on Mark Sylor's reply to note 2162 (see note
    2162.5) where he said this was the appropriate thing to do in such a
    case.... 
    
    Adding the idents as characteristics isn't really going to help me as
    it won't give me the backtranslation facility.... So I assume the only
    solution is to set up some internal tables or to use a private MIR.... 
    which in turn will lead to problems as I'll have to try to implement
    some distributed kind of MIR if I have several management stations....
    
    Can anyone show me the way out of this one ?
    
    Philippe.

From looking through the mcc_dns code, the restriction is DNS's.
The mcc_dns code is written to handle constructed types.

I looked through the MSL sample in 2162.  The four attributes
which together make a unique identifier are all Latin1String.  If you
treated all the fields of your RECORD as Latin1String, you could 
work around this by making the top level constructed type SET_OF Latin1
String instead of RECORD.  You might have more work to be sure that the 
set elements are correctly matched to the record fields, and that the other 
two fields of your record get converted into their correct data types.

Ruth K.

By the way, other questions from .0:
    
>    -	Should I ILV-encode a record ?

No, the mcc_dns_add_identifier routine will do that.

>    -	If I use ILV encoding, what is the ID code  I have to specifiy for
>    	the ilv_param_begin ? 

                        N/A, However, you would use the ID code of the 
        alternate identifier attribute.

>    -	Should I chain descriptors pointing to the fields of my record (I
>    	saw a note about that some time ago ...)

Yes.  The convention is: for each mcc descriptor, 
1) the mcc_a_pointer field points to the contents of the  descriptor, and
2)  The mcc_a_link field points to the next descriptor.   

In the case of a SET_OF, it would go like this: The top level descriptor 
has the id of the alternate identifier attribute, and data type of
SET_OF.  The contents of a SET are its elements, so the mcc_a_link is NULL. 
The mcc_a_pointer points to an mcc descriptor.  This descriptor has the id 
and data type of the first element of the set, its mcc_a_pointer points to 
the value of the first element.  Its mcc_a_link points to the descriptor of 
the second field of the element, and so forth.  The last element of the set
has a NULL in the descriptor's mcc_a_link field.

It may help if you draw pictures of the descriptors.  The algorithm may
be repeated--a constructed type may be contained in a constructed type.

If such a tree of descriptors is the entity instance of  an AES, interactions
betwee the AES routines and the ILV routines for encoding and decoding it
can get expensive.

Ruth K.

    Hi again,
    
    What I'm trying to construct is actually an OSI address-like 
    identifier. I believe there will be an OSI address datatype in DECmcc
    1.2, but as the SRM isn't out yet, can anyone confirm this and point me
    to the definition so I can check if it fits ? 
    
    Regards,
    
    Philippe.
    

    I'm a bit confused by the term "an OSI address-like identifier".
    Are you talking about a DECnet PhaseV towerset or NSAP address?
    Can you give an example?
    
    John

    The system my customers is trying to talk to is a Bull ISO-DSA system.
    It's identifier is made up of 6 fields including a NSAP, TSAP, SSAP
    etc... (I don't remember them all), one of which is a 4 character
    mailbox name . That's why I say it's "OSI like".
    
    I don't think TowerSet datatype can be used because I'm not using
    DECnet.
    
    I had a look at the EndUserSpec datatype, which may do the trick, but
    would this be supported by DNS as an alternate Identifier ?
    
    Regards,
    �hR.

Philippe,

How are you going to communicate with this Bull ISO-DSA system?
Are you writing an OSI access module?  We have some engineers here working
one one but it's in the early stages of development.

If you were intending the DNA5 AM to be used as a transport then that won't
work.  The DNA5 AM doesn't use an OSI type of association.  It's strictly
DECnet.

From what I understand about the module being developed, they use a datatype
of octet string for the address and store it in the namespace via a
registration process.  The information is retrieved from the namespace
when they need to make an association.

I spoke with one of the developers and she is willing to speak with you on
the phone about what you're trying to do.  She's only here another day or two
before going on vacation so you'd better hurry.  Try Arun Sankar - 226-5336.

John

Hi,

The Bull systems are OSI except for network Management. They use a specific 
protocol which runs on top of an OSI session, so we will develop a specific 
AM on top of the MARBEN OSI stack. We can't use OSAK because session level 
API's are no longer supported. (There's a message for Marketing there.....)

To get back to the orginal problem, to identify my agent, I have an agent 
address which includes some OSI fields (TSAP, NSAP, etc...) and some 
specific fields (mailbox address etc..). That's why I thought the RECORD 
datatype seemed the most appropriate. As Mark Sylor recommended it to 
Sylviane in a previous note, I presumed MCC supported it.

As it turns out, I believe I now have the following alternatives :

1-	Request that DNS routines support constructed alternate idents  
	(Unlikely to happen, but please put this on the wishlist for V n+1)

2-	Try to use the SET OF latin1String (ugly because I have no way of 
	identifying the various fields which make up my address)

3-	Investigate more exotic datatypes like endUserSpecification (Has 
	anyone used this ? Would it be viable as an alternate identifier ?)

4-	In my Register directive code, I could concatenate all my arguments 
	into a single Latin1 String (with perphaps some sort of separator to 
	make the ident readable).

Any comments ?

�hR.