Conference azur::mcc

    The MIR routines are case sensitive for all datatypes except
    SimpleName.
    
    There are only two string datatypes that I can think of for
    representing a identifier in the MIR.  Latin1String and SimpleName. 
    Latin1String is defined to be completely case sensitive.
    SimpleName is insensitive for matching, but case preserving for
    displaying.  Prior to EFT update, the MIR routines did not support
    ANY case insensitivity.  As of EFT update, SimpleName may be used
    to store identifiers case insensitive for matching, but case preserving
    for returning back to the caller.  But, before you go rushing off to
    buy a boat load of SimpleNames, be warned.  SimpleNames are not simple.
    The have two leading bytes which mean something.  They are more like
    primitive string descriptors, than simple character strings.  You need
    to read the SimpleName datatype description in the Datatypes chapter of
    the SRM before using them.  Note that the MIR routines only do case-checking
    when it is a "normal" SimpleName. (I guess that's the same as an "easy"
    SimpleName.)   Also note that a Version 1.0 restriction is that the
    SimpleName length can only be up to 222, and not the architected size
    of 255 for storage in the MIR.
    
    -Matt.

Note that Latin1String is quoted so case should be preserved by VMS. 
Latin1string is not a good choice as
an identifier (I don't know of any entity that uses it as it's identifier)
SimpleName (while not simple) is the prefered data type for an identifier 
for a local entity when the manager choses the name.

By the way, Fullname and FileName are also data types that must preserve case.

re: .2

>Note that Latin1String is quoted so case should be preserved by VMS.

DCL upcases any parameter that isn't quoted. Thus,

    $ mcc create pbd mumble

and

    $ mcc
    MCC> show pbd mumble all ident

didn't work as the (user) expected.

As long as everyone works from the MCC prompt, they will get what they type.
It is only when they enter a command on the DCL line invoking MCC that
they get a surprise.

The user visible form for a Latin1String *requires* the quotes (according to
NETMAN).  So, if the identifier is a Latin1String then neither

    $ mcc create pbd mumble

or

    $ mcc
    MCC> show pbd mumble all ident

should have been parsed.  The correct syntax (in both cases) is:

... pbd "mumble" ...

I believe  that  was the point of Mark's reply in .2: if the rules are being
followed  (i.e.   quotes  are  required)  the  user can't enter a name which
doesn't behave as he expects.

Looks like a bug in the parser (FCL?).

Graham

re: .4

The type of the attribute in question is FullName, so it doesn't have to
be quoted, but the MIR handles it as case-sensitive. My reply in .3
muddied the water, sorry.

It sounds like a reasonable way to go here is to make the attribute a
SimpleName. According to previous replies, it would then be handled
by the MIR as case-insensitive.

I must confess I haven't completely got a handle on the strategic implications
of Full vs Simple names. Can I still specify a namespace and directory path
for an object with a SimpleName?

Thanks.

Nope, a simple name is one of those DNS fragments in a fullname, like
	Fred3
	"Mark Sylor"
	%XDEC0
Those are easy, quoted and binary simple names respectively.

    re: .5 and .6
    Surely, for a Global Entity, therefore, a simple name is inappropriate,
    and a full name is 'de rigeur'. This allows "global" things to be
    named globally uniquely.
    However, for identifying a child entity, a simple name is most
    appropriate.

I had  forgotten that it is a global entity.  The entity model requires that
global  entities have a FullName as their primary identifier (it technically
allows  an  identifier  from  any  naming  service  at  least as powerful as
DECdns).

>The type of the attribute in question is FullName, so it doesn't have to
>be quoted, but the MIR handles it as case-sensitive. 

Ah, so it is just a bug in the MIR.

The case-sensitivity  for  full  and  simplenames is extremely complex.  The
full  rules for comparing full and simple names appears in the DNS spec.  It
is not just as simple as doing a case-insensitive match on the external form
of the fullname (or, worse, on the internal form).

The MIR has to learn about these strange DNS datatypes!

Graham