[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

362.0. "QUESTION: Comparing FullName" by COOKIE::KITTELL (Richard - Architected Info Mgmt) Fri Sep 28 1990 13:23

The SRM lists under relational operations for FullName, "none". It is kidding,
right?

For DNS and the MIR support to ever look up a global entity, a routine is
successfully doing a FullName compare somwhere.

I was coding up a call to aes_equal and noticed it would complain if the
datatype of any instance name wasn't comparable. That will work for
entity specs containing entities whose identifier is a FullName, right?

Thanks.
T.RTitleUserPersonal
Name
DateLines
362.1EqualityMARVIN::COBBGraham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917Tue Oct 02 1990 10:227
No ordering  is  defined for FullNames but equality certainly is.  Note that
the equality determination is not at all trivial.

Phase V has three entities I can think of with FullName identifiers.  I sure
hope MCC can handle these!

Graham
362.2I don't grok this, GrahamNAC::ENGLANDTue Oct 02 1990 22:042
    why isn't FullName ordering defined?
    
362.3it's not grokableCAPN::SYLORArchitect = Buzzword GeneratorWed Oct 03 1990 23:516
    Why? well, because...
    
    Seriously, because simple names have no order. We didn't know how to
    sort binary names against easy names. This was a DNS decision.
    
    Mark
362.4MARVIN::COBBGraham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917Thu Oct 04 1990 16:2512
362.5net. mgmt. debate # 12349860239348123493 :->NAC::ENGLANDThu Oct 04 1990 21:0310
    There is an obvious application of FullName ordering.  Any time you
    have to display a list of FullNames, the obvious thing to do is to
    display them in some kind of sorted order.  Otherwise it's a nightmare
    to search through the entire list of them.   I'll bet you that the
    DNS product already does this if it has any kind of DIRECTORY function.
    Given that SimpleNames have an ordering, what's the big deal here?
    Not that I'm going to lose sleep over it or anything...
    
    					ben
    
362.6This is not an architectural notes file, but...TOOK::GUERTINWherever you go, there you are.Fri Oct 05 1990 13:5021
    RE:.4
    
    Why not think of it as describing the path in a tree structure.  Then
    ordering (at least to me) becomes intuitive.  You sort the root
    portions first. Then the next node down.  Then the next node down, etc,
    until you are done.
    
    So in your example:
    
    which should be lower: dec:a.b.c, dec:ab.b, dec:a.c, dec:a... ?
    
    It would be:
    dec:a...
    dec:a.b.c
    dec:a.c
    dec:ab.b
    
    If you had an ibm: full name, all the dec: full names would come first,
    'cause DEC comes before IBM in the dictionary :-)
    
    -Matt.
362.7MARVIN::COBBGraham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917Mon Oct 08 1990 10:1912
Sure, you  can  define  any  number of orderings (I still don't think any of
them  is  "obvious" to a layman).  Internally in my implementation we happen
to  use an ordering that just does a simple lexical ordering of the internal
format  of  the  FullName.   This  would not be acceptable as an architected
ordering  because  "equal"  names  (e.g.  differing in case) get sorted into
different  positions.   However, it meets the particular need we have (to do
with saving state in wildcard lookups).

My point  is just that the architect didn't define an ordering.  If you want
one, go ask in the DNS_ARCH conference!

Graham
362.8I said compare, not orderCOOKIE::KITTELLRichard - Architected Info MgmtMon Oct 15 1990 16:327
Divergence struck quickly on this one! All I asked was why the SRM indicated
FullNames could not be compared. Ordering is an important, but different,
issue.

Having implemented the call that prompted me to ask the question, it is clear
that comparison of FullNames works, and that the SRM is in error.
362.9DECdns does why nor DECmccTOOK::JESURAJTue Oct 16 1990 16:126
    DECdns supports comparision of two full names. In fact there is a DNS
    function DNS$COMPARE_FULLNAMES to do that job.
    
    So why not in DECmcc?
    
    Jesuraj
362.10aes_equal worksCOOKIE::KITTELLRichard - Architected Info MgmtWed Oct 17 1990 16:344
I don't know if there is support in MCC for direct comparison of FullNames,
but mcc_aes_equal works for instances whose identifiers are Fullnames, 
and that is all I needed.