Conference azur::mcc

    The issue is that NML and CML share object 19 and will clash. So
    in short the limitation is with the agent and not MCC. This was not
    supposed to have happened. So the architecture specified that CML
    would use object 19 and would replace NML. If you have a node 
    registered as both (I am not sure that is allowed), then one of
    the AMs will not be able to connect to the proper agent. If you
    need to understand all the niceties involved, contact Arun Sankar
    at TOOK::SANKAR and she can fill you in with all the gory details.
    
    wally

Looks like a very strong case for a node is a node and a node
can use whatever protocol it likes and MCC should figure
it out.   Maybe DECmcc needs a protocol detector AM whose job it
is to pass of the user requests to a correct AM based on the 
protocol supported by the node.  The user/manager shouldn't
have to remember what type of thing they are talking to.  
DECmcc already supports the MCC_CLASS single valued attribute, 
which should really be the set of protocols supported by this
node, not THE single protocol attached to this DNS fullname.

This Phase IV/V issues is going to create an incredible hassle 
as DEC transitions and for our customers when they start.  
I really hope that DECmcc is working really hard to fix this 
problem.  Customers who know about this already are unhappy.  
There is a similar problem with RSM problem (a few notes back) 
where a user wanted to register an RSM server/client and use 
the same name as a node4.  Again, it doesn't work because of the 
structure of the AMs.    What is being done to fix this problem?

/Claudia

Wally is  slightly  wrong  in .1.  Wave 1 supports *both* MICE and NICE (CML
and  NML)  management  at  the  same  time (for the two halves).  The DECnet
object  19  code checks the protocol version number and starts either NML or
CML as appropriate.

I would  have  thought that you should be able to register the node with two
identiies  (with different names).  I suppose the Phase V registration might
fail  because  Register has a habit of trying to get some attributes and the
Wave 1 Node entity is not really implemented.

Graham

    re: .2
    Early on, it was suggested that we try and make a logical 'node' which
    would subsume both Phase IV and Phase V - ie. the management model
    would accomodate both nodes. (This was before the idea of a node
    containing BOTH Phase IV and Phase V simultaneously).
    
    The idea was rejected. It shouldn't take more than 5 minutes thought
    (maybe less) to realise that the end result would be even more complex.
    This is one of those places where the cure is worse than the disease.
    
    Phase V management is significantly different from Phase IV. There was
    a concious decision during the architecting of Phase V to make
    management of Phase V rational (believe it or not), and to *not* have
    backwards compatibility with Phase IV - hence NCL defines an NCP "mode"
    whereby the human manager chooses whether to manage a Phase IV beast
    or a Phase V beast by the command language (and all that implies).
    
    Just think about the (Phase V compliant) management model that the
    Phase IV AM presents to MCC - try to understand how that could be
    merged into Phase V (eg. as variants to a lot of classes). It would be
    ugly.
    
    Now......that does not mean that we shouldn't try and make Wave 1
    systems appear in a more user-friendly manner from MCC. I leave that to
    Wally or Jim C. to comment on.
    
    Colin

    And by making a single "node" like object you can accomodate all the
    other protocols that it might run as well (IP, Station, LAT...)
    without needing a separate registation per protocol.
    
    s/rob