Conference azur::mcc

    Hi Dave,
    
    it's not that bad.
    DECmcc is able to register a Phase IV node the same way as the
    migration tools do. But DECmcc adds some attributes to the object.
    For DECmcc V1.1 these attributes are required.
    They are for example mcc_uid, mcc_class, etc
    So do the Phase Iv systems registration through DECmcc, there is 
    an mcc command procedure provided that helps you doing this job.
    
    In case that you have some Phase V system using extended addresses then 
    things are slightly different. 
    For DECmcc the Phase V system still must have a Phase IV compatibility 
    address (DECmcc runs on Phase IV). This address value could as well be
    written to the node object's tower attribute by DECmcc. But for the 
    extended addresses you depend on the KeepMeHere function of the Phase V 
    system.
    The Phase V system requires a node-object to be available to perform
    tower maintenance and backtranslation maintenance. So you will have to
    register the system by means of decnet_dns_register and the system
    will then update the attribute values and softlinks. 
    DECmcc will then have to do another registration to append the mcc_* 
    attributes.
    
    As you know DECmcc entity registrations can be done by means of FCL and 
    by the Iconicmap. If your customer wants to use the map interface, it 
    will not be obvious that you actually perform a second registration. 
    There is only minor difference between the ways to add a node to a domain 
    map or to register a node and add it to the map. You actually get one
    more window asking for the synonym name of the node if it is a
    registration. 
   
    If all this is not satisfying, wait for DECmcc V1.2. DECmcc will not
    create DECdns objects with mcc_* atttributes anymore.
    
    Cheers,
    Klaus
            

    
    Hi Klaus,
    
    Thanks for the heartening reply.  The customer will accept the response
    of resolution in version 1.2.  Just to explain my previous concerns a
    little more, the real facts are that MCC on my machine (which is a
    development machine) currently takes 5 meg of memory and the backgroud
    tasks take at least 4.  The MCC process is running line mode and there
    are no MCC processess running the windows interface.  The problem comes
    in when the person or persons registering new nodes has to do this on a
    live MCC station which is also running the alarms, reports, windows
    interface, etc.  This would be a lot for a "production" system to do
    (even on the Model 76s).  But this is addressed, so we just use an
    alternate method until V1.2.
    
    Again, thanks for the good news.
    
    Regards,
    
    Dave Comfort
    

    Let me clarify a bit.
    
    The MCC_ attributes on the objects are not removed for V1.2 of DECmcc.
    
    DECmcc provides a copy of the same tool that the transition kit has
    that when run will register nodes in DNS just the same BUT will
    add the MCC attributes (it uses mcc instead of NCL). In your case it
    is too bad you did it already with NCL if you intended to use DECmcc.
    
    What DOES change in V1.2 is that partial registration is possible even
    if the actual system is not currently reachable. This lets you get
    stuff into DNS so you can proceed with things like map building etc
    untill the node comes available.
    
    s/rob

    And adding to what Rob said in .3
    
    If you've "registered" stuff with NCL (or a DECnet-supplied command
    procedure or script) and not (yet) registered with MCC, then trying
    to manage via MCC will yield a more helpful message than shown in .0
    - effectively indicating that the entity is only partially registered.
    
    Colin

	Ah.....

	As for one who has to tackle this "mess" in the real life, perhaps
	you could consider this suggestion :

	Could you make the MCC registration routines available to DECnet
	developers for DECnet/OSI wave 2.. on VAX/VMS and DECnet/OSI V5.1
	on Ultrix/OSF/Alpha....

	This so that customers who do their registration could set up DNS
	objects with the correct MCC info to start with. Helpful error
	messages don't make people very happy, but a initial MCC registration
	would - I'm sure!
	
	For those who are afraid that of "overhead" from the MCC attribs,
	the (DECnet) supplied routines could give you the chance of leaving
	out the MCC attribs (if explicitely requested).

	We are sure to look stupid if DECnet and its (hopefully) main managemnt
	system do NOT integrate!

	No copyrigth on this one!

	H�kan

    
    Hi,
    
    Let me get back on the horse here for a minute.  In .3 there is
    reference to a registration procedure similar to the one being shipped
    with WAVE 1.  Will this procedure be able to run standalone,like the
    one with WAVE 1?  Can it be run on a node that does not have MCC on it?

    This would be most helpful because as I have suggested before, I feel
    (translate to my customer) that the MCC station should not have to be
    used for simple node registration procedures.  The stations is (in my
    view) a vehicle for alarms and fault detection and correction and node
    management, not for administration.  Except for the management aspect,
    which should not be on a continual basis, the majority of the work done
    by the system will be autonomous and should not have any large number
    of interactive users beating on it.  I have a "decked out" model 76 and
    when I run MCC line in the background, windows, historian and exporter,
    the system does start chugging at times.  I would hate to have some
    administration person registering nodes while that station is doing
    "valuable" work (this doesn;t even address the issues of training
    someone either in the window, line or FCL interfaces. 
    
    Now that I have rattled on enough...
    
    Regards,
    
    Dave Comfort 

    Sorry, but the DECmcc registration procedure uses DECmcc to perform
    the registrations. Some of the attributes describe the child entities
    of the system (lines, circuits etc).
    
    You may feel that you only want to use DECmcc for alarms and fault
    detection but the product definition was to be THE management interface
    which includes management of NCP databases, Phase V info in DNS and
    others.
    
    Admitedly it doesn't do everything it needs to do yet nor, in some
    cases as easy as we want.
    
    If you accept the premis that DECmcc becomes the single management
    interface, then the training issue becomes a non-issue because it
    IS the default interface and registration is only one of the functions.
    
    Also, keep in mind that the command line interface (the FCL) is the
    same syntax as that used by the NCP replacement for OSI, NCL so
    any training invested in either DECmcc or NCL transfers to the other.
    
    s/rob

    Hi Rob,
    
    have been out of the office for a few days, so I could not follow
    the discussion.
    Could you please clarify, why the func spec for MCC V1.2 states that
    the use of DECdns will be optional ? Following what you say, we will
    have to use DECdns.
    I included some paragraph out of the publically available Component
    Spec for V1.2.
    
    -------------------------------------------------------------------------
         *  Optional use of DECdns.  Support for a local  instance  repository
            that  does  not  rely  on  DECdns.   Implementation  to optionally
            utilize the platform specific MIR as the instance repository.
    
    					...
    
        The DECmcc V1.2 product for VMS is designed to  run  on  VMS  V5.4  or
   later.   The  DECmcc  V1.2  product for ULTRIX is designed to run on ULTRIX
   V4.2 or later.  DECmcc V1.2 no longer requires  the  use  of  DECdns  as  a
   prerequisite product, however DECdns can be utilized as the global instance
   repository for the storage of entity information.  Refer to the SPD.

    -----------------------------------------------------------------------
    
    Thanks,
    Klaus

	Klaus,

	In V1.2  *DECmcc*  no  longer  requires DECdns, it is optional.
	During the installation,  you  will  be asked as to whether you
	would like DECdns or use the local MIR.  Once you have made you
	choice and are using DECmcc, it  is quite easy to switch to the
	other choice if you decide to go  from  local MIR --> DECdns or
	DECdns --> local MIR, it is controlled by a logical.

	Now, if  some  other  layered  product  requires  DECdns,  like
	DECnet/OSI?, then you  have  have to buy and install DECdns for
	that layered product and  you will need to use it from a DECmcc
	perspective.

	The reason for making DECdns optional was that there an out cry
	for a simple method to manage  a  smaller  network.   A network
	with a few DECnet IV nodes, a  few  bridges,  some  TCP/IP SNMP
	hosts,  etc.  With a single DECmcc installation,  using  DECdns
	made  little sense.  As many DECmcc systems are  installed  and
	data desired to be shared, DECdns makes alot of sense.

	JCE

    Hi John,
    
    thanks for the fast answer. 
    The reason why I was coming back to the optional use of DECdns was
    that Dave had problems with the registration of Phase IV and Wave I
    systems in the namespace. He did not want to use decnet_dns_register
    and additionally the mcc register directive.
    My answer to his question was, that mcc V1.2 would not create
    node objects anymore. (At least if you choose not to use DECdns).
    Rob corrected me and said, mcc would still create the mcc_* attributes
    on node objects. I don't understand yet, why I can have a need for
    attributes on objects in a namespace that I decided not to use for mcc.
    
    John, I understand your point very well, that especially in small networks
    the use of DECdns was kind of overkill. I still understand that using 
    some distributed naming service is reasonable in environments with
    multiple (perhaps distributed) directors.
    
    But that all together implies that mcc V1.2 in a Phase V world (marketeers
    please forgive me for not calling it ADVANTAGE-NETWORKS) may still modify
    the definition of existing node objects. 
    To make that clear: I don't bother about entries for bridges, stations,
    IP hosts etc. I am only interested in Phase V entity objects.
    A true Phase V node may autoconfigure its NSAPs and therefore has to
    perform tower maintenance on its node object. The object typically
    was created by decnet_dns_register. If you want the object to be 
    created by 'mcc> register' then this is possible for Phase IV
    entities, but for a Phase V node you need to have a valid entry
    (ie. one with tower attributes) in the namespace, because mcc cannot
    write autoconfigured towers on behalf of another node. 
    Do I understand correctly, that if the mcc V1.2 system is configured to use
    DECdns, that mcc can create a node object for a Phase V entity with 
    the required mcc_* attributes, although mcc may not know the nodes
    address at this point of time ? So I would take advantage of the fact
    that mcc can now register nodes which are not reachable at the time
    of the registration ? No matter if the lack of reachability comes from
    a lack of addressing information or the node actually being down ?
    
    My last question is perhaps a little hypthetical:
    
    Does anyone work on a recommendation on how to register nodes
    in the namespace if DECmcc is going to be used ?
    The reason why I'm asking is very simple. I can create Node-Objects
    by means of decnet_dns_register, 'mcc> register node4', perhaps by
    'mcc> register node' in V1.2 and by  vrou_host_config. I can have towers
    being written to the object by decnet_dns_register for a Phase IV node,
    by 'mcc> register node4', by vrou_router_config and by the node itself
    performing tower maintenance.
    So if I want to use MCC as the standard management platform, I at least 
    need to have a comprehensive insight, which tool gives me what function. 
    And especially if an object gets deleted accidentally, I need to know which
    steps to perform to recreate it with all required attributes and their
    values.
    
    Thanks for any further input about what DECmcc V1.2 will be able to do in
    a Namespace.
    
    Klaus
    
    
      
    

    My previous replies all assumed that DECdns was chosen for the DECmcc
    namespace.
    
    In the case where you choose (in V1.2) NOT to use DECdns as the
    namespace for DECmcc, then NO Attributes in DECdns will be changed
    and DECdns will not be used at all for DECmcc.
    
    As John said earlier, for small networks where there is likely to only
    be one network management station/system, then using a local MIR based
    namespace makes more sense than using DECdns for the namespace.
    However, if multiple management systems are to be used (maybe at more
    than one location), then perhaps DECdns might be the best choice.
    
    I hope this clears up the issue of what is in V1.2 and the namspace.
    
    As for how to register phase V nodes into DECdns, I can only say that
    I would reccomend that if DECmcc is intended to be used as the
    management system on that network, then, DECmcc should be the means
    (hopefully sole means) that nodes are registered and removed.
    
    I personally would plan to assign node addresses and activly register
    them rather than use the autoregistration feature of Phase V. The
    discussion of all my reasons is beyond the scope of this note but let
    me finish by saying that my reasons have to so with access to DECdns,
    and authority to add nodes to a network. I agree that there will be
    some networks that will simply let people add nodes, but I think that
    networks like that that also intend to do comprehensive network
    management will be few.
    
    s/rob

    Hi Rob,
    
    it looks like there is a minor missunderstanding:
    I was talking about address autoconfiguration. This is building the
    NETs based on the router, combine those with the Transport-Selectors
    as are enabled on the system at that point of time, so that the system
    finally ends up in creating its DNA$Tower values.
    
    I agree totally with you that node autoregistration (what is nothing
    but creating the node object and the .DNA_NodeSynonym entry) is very
    unlikely to happen. At least in most of the networks.
    
    All the discussion so far just deals with the problem that DECmcc can
    easily create a node object, write a DNA$Towers value for a DECnet Phase
    IV node (ie. one having only one NSAP, derived from the Phase IV
    address with selector for NSP), but that DECmcc cannot create Towers if
    the system to be registered is a Phase V system having extended
    addresses. In this case the only assumption that DECmcc could make is
    that there is a Phase IV compatibility address with NSP selector for this
    system.
    So is your answer implying that DECmcc V1.2 relies on all Phase V
    systems, may they be DECnet/ULTRIX V5.0 or T5.1 or DECnet/VAX Wave 2,
    having a Phase IV compatibility address ?
    If not, then the initial problem will not be solved:
    - 1 tool has to create the node object
    - the node has to maintain the DNA$Towers attribute
    - DECmcc can register the node as Phase V entity because now the
      address information is available
    So we still have to have another tool for the namespace
    management.
    
    Thanks for answering so promptly, even on a sunday. If you prefer, we 
    may continue this discussion off-line.
    
    Klaus
                                         

Let me check if I understand the previous correctly:

1. In V1.2 you can choose to use DNS or not

2. If you choose during installation one or the other, it is a question of 
   just changing a logical , if you want to go later on from NO DNS to DNS 
   or vice versa. There is no need to reinstall DECmcc or any access modules.

3. If you use the phase V AM to manage phase V nodes, you need DNS since 
   phase V needs DNS (??)

Can somebody confirm these?

Thanks

Timo

>1. In V1.2 you can choose to use DNS or not

Right.

>2. If you choose during installation one or the other, it is a question of 
>   just changing a logical , if you want to go later on from NO DNS to DNS 
>   or vice versa. There is no need to reinstall DECmcc or any access modules.

There are at least a couple of other things you need to do.

If switching from MIR -> DECdns, you may need to run a set-up script,
to create the MCC specific directories in DECdns.  You will also
need to define the network IDP.

Either way, at the moment you will have to re-register all entities,
as there is no automatic way of transferring information from
one instance repository to the other.  We are working on a script
to automate this procedure, however.

On ULTRIX, when switching either way, you will definitely need to stop
all access modules and re-start them (but not re-install or re-enroll)
after changing the environmental variables.  We would advise using
"setld -c" to re-configure DECmcc rather than tweaking manually.

>3. If you use the phase V AM to manage phase V nodes, you need DNS since 
>   phase V needs DNS (??)

No.  You can use the DECmcc phase V AM from any system running DECmcc,
independent of whether or not it is running DECnet phase V or DECdns.
However, if your system is _running_ DECnet phase V, you get DECdns,
regardless of whether you have DECmcc installed or not.

You can still use the DECmcc local MIR option for your instance repository,
even if you are running on a Phase V system.  However, we haven't heard
a good reason yet why someone who is already running DECdns would
choose not to use it for the DECmcc instance repository.