Conference azur::mcc

This is probably because of the problems with the synonym directory in the DEC:
namespace (see discussions in IAMOK:DNS_PROGRAM or the DNS conference).  This is
in the process of being fixed.  However, fixing it should allow SHOWs to succeed,
but you still won't be able to REGISTER nodes, so you may want to consider using
a private namespace for the moment.  CT is working on allowing the use of the
DEC: namespace for DECmcc, but it will be a while, I'd guess.

Did you try node4 cronic? 

_MaryEllen

MaryEllen

I just tried various combinations of SHOW NODE4 nodename, and they all worked
like a champ, as long as I examined a node that was defined in my node's
DECNET database.  When I tried one that isn't:

MCC> show node4 bulova all char

Node4 bulova
AT 25-SEP-1991 16:44:10 Characteristics

Node does not exist or is not known to local Node.

So, it looks like NODE4 doesn't use DNS to locate information.  So, I still
need to get the problem described in .0 fixed.

Thanks!
tl

the command you entered used a phase 4 name. If you had entered it with
a dns fullname then you would have required the namespace to interpret
the command. The iconic map ONLY uses fullnames and therefore requires
the namespace. The FCL on the other hand is more flexible in allowing
access to unregistered entities.

jill

    
    Actually, everyone is partly right!
    
    The phase IV AM will do everything it can to find a DECnet address
    to form a connection to.  In general:
    
    	o If we get the address as the input identifier, we're happy
    	  to use it.
    
    	o If we get the phase4name, we try to resolve it to address, first
    	  with the Remote node database, and then with DNS if we can't do
    	  it there, so you get two chances.
    
    Same fancy chain of events for fullname, too.  We try to take advantage
    of all of the places the info might be stored to resolve the
    information and provide maximum manageability.
    
    Anyway, it is also true that the entity has to be registered through 
    MCC before you can use the fullname with MCC.  We stick some stuff 
    on it to help us.
    
    -JIm
    

Re .4

>    Anyway, it is also true that the entity has to be registered through 
>    MCC before you can use the fullname with MCC.  We stick some stuff 
>    on it to help us.

Ah, hah!  So, when I enter:

MCC> show node4 .hlo.argyle
Using default ALL IDENTIFIERS

Node4 DEC:.hlo.argyle
AT 26-SEP-1991 12:23:54 Identifiers

Internal error in DECnet Phase IV AM.
                              MCC Error = %MCC-E-NOATTRIB, no such DNS attribute

I'm forcing DECmcc to use DNS to locate the node.  Since the node DOES exist in
the namespace, but WASN'T added with DECmcc, not all of the DECmcc-required
identifiers are present on the object (yes?).  And when I type:

MCC> show node4 argyle
Using default ALL IDENTIFIERS

Node4 6.45
AT 26-SEP-1991 12:24:23 Identifiers

Examination of Attributes shows:
                                Address = 6.45
                                   Name = ARGYLE

DECmcc instead use NETNODE_REMOTE.DAT, finds the address there, and all is well.

If this is true, it sounds like a BIG problem to me.  It has been my fond hope
to use DECmcc with the node information maintained by Corporate in the
corporate namespace, in the form .sitecode.nodename.  Unless Corporate (1)
uses DECmcc to manipulate this node information or (2) adds the same information
that DECmcc expects ( "We stick some stuff on it to help us", from above), my
fond hope is dust.

tl

    
      MCC can manage the entities that are  registered through MCC.
    Requiring MCC to manage all sorts of entries in name space may be too much.
    
    On the other hand requiring the corporate name space to add some MCC
    specific stuff is not right either.
    
    If you want to use MCC then use MCC registration. It is as simple as
    1, 2, 3.
    
    
    Jay

Re: .6    
>      MCC can manage the entities that are  registered through MCC.
>    Requiring MCC to manage all sorts of entries in name space may be too much.
>    
>    On the other hand requiring the corporate name space to add some MCC
>    specific stuff is not right either.
>    
>    If you want to use MCC then use MCC registration. It is as simple as
>    1, 2, 3.

Not having looked at the MCC registration procedure in detail, I can't be sure 
exactly what data the user is required to input - so forgive me if these
comments are superfluous or inappropriate.

It should be a goal that users never have to enter the same information more
than once.  Therefore, if node information has already been placed in a DNS
namespace, then the user should not have to re-enter that data in order to
manage the node with MCC.  Now, whether this is accomplished by MCC providing
tools to auto-register (with MCC under policy control by class or whatever) 
nodes which are already in the non-MCC namespace, or automatic completion of
the relevant fields in the MCC registration form (based on data extracted from
the non-MCC namespace) after manual instigation of the registration, is 
irrelevant - the user should not have to re-enter data or otherwise jump through
hoops in order to manage the nodes.

Paul