Conference azur::mcc

Access to the namespace is always through the root or clearinghouse.

Once you answer NEW to the installation question, just make sure that 
the name you choose for your namespace is not the same name as the
production namespace. 

I believe that the default name is <nodename>_NS.  If you are running on 
a different node than the corporate namespace then use the default name.

In addition, if you use any products that access the namespace, you must 
make sure that the corporate namespace prefix is added to those product 
commands.  For example, in the DEC: namespace, the DFS mount command
	MOUNT .ENG.NAC.TOOK.USER43
must be changed to 
	MOUNT DEC:.ENG.NAC.TOOK.USER43

This has to be done because, inorder to have MCC access your private 
namespace, you must set your default namespace the private one, using 
DNS$CHANGE_DEFAULT_FILE.COM.


...kjn

    .0>    Although I have read the appropriate documentation regarding the use of
    .0>    a DNS namespace with DECmcc, I am still confused regarding the issue of
    .0>    setting up a private DNS namespace for the sole purposes of field
    .0>    testing the DECmcc software.
    
    As of the external fieldtest of DECmcc v1.0, we are no longer
    recommending use of a private DNS namespace. In fact I would actively
    *discourage* such use.  
    For the field test customer, (and this point was emphasized during FT
    training) they should use their 'normal' namespace (ie. the one they
    use for DFS, NOTES, RSM, etc.)
    For internal sites, again use the normal namespace - this happens to
    be administered by EasyNet folks. If you have problems using our
    corporate namespace, contact the folks who administer it for
    assistance.
    
    Colin

    Re .2
    
    Since we are recommending that the customer's existing "corporate" DNS
    namespace, rather than a private namespace, be used for the external
    field test of DECmcc V1.0, can someone provide further clarification
    regarding the problems or issues involved using a private DNS
    namespace?  Is the objection performance related or something else in
    nature?
    
    At GE Aircraft Engines (GEAE), it will be politically difficult to convince
    GEAE to use their existing "corporate" PRODUCTION DNS namespace for the
    purpose of supporting Field Test software.
    
    Please advise.
    
    		\Thanks in Advance

HI,

Just my two cents with respect to 88.2 ::
From my experience with MCC and DNS I HOPE that the MCC release notes
(not the ones I got (MCC$EXEC_UT1_0_0.RELEASE_NOTES 5-mar-1990)
have DETAILED information for setting up the DNS directories for node 
registration.

During the MCC FT training everyone spoke of how "DNS was the major problem
people were having with MCC". I believe one reason for this (besides that DNS
is a beast itself) is that  NO ONE spent the time to document the DNS
directory structure setup well enough.

So, Have I made any enemies yet?? ===Steve

    Re: 4
    
    The DECmcc V1.0 Installation Guide appears to have omitted the
    DNS$CONTROL command required for the ETHERNET Stations.  I am assuming
    that the required command is:
    
    DNS> CREATE DIRECTORY .MCC$STATION_BackTranslation
    
    Please confirm - the documentation seems unclear on this point.  I am
    assuming that the word "STATION" is correct because of the REGISTER
    command discussion in the ETHERNET ACCESS MODULE USE manual.
    
    	\Thanks in Advance
    
    P.S.: I still would like someone to reply to my earlier question in .3
    as well.

> I am assuming that the required command is:
>
>    DNS> CREATE DIRECTORY .MCC$STATION_BackTranslation

This is correct.  This follows exactly the format that the Bridge AM uses:

			   .MCC$BRIDGE_BackTranslation

    
    Okay, I guess DNS is a hot topic today.
    
    RE 88.3: The main reason you haven't gotten an answer yet is because
    Colin is out of town, and he was the person telling you not to use
    the private name space.  He won't be back for a while still. I will
    see what I can do about finding some one else who might know, and
    be able verbalize, his reasons.
    
    RE 88.*: Janice Sahagian is the writer for the DECmcc Installation
    and Use manuals. She is aware of the problems that people are having.
    She has been taking the information (and questions) that you have
    been putting here to update the documenation. If there are specifics
    items that you would like to see covered (and even if you have an
    idea of which manual you think it belongs in) your input would and
    is appreciated.
    
    jill
    

There is more than one topic going on here:

1) RE: 3, Certainly, we are encouraging our Field Test sites to use
their 'corporate' namespace when possible.  However, we understand a
valid reluctance to use field test software with `production' systems. 

The information in the namespace associated with nodes in still in flux 
due to uncertainty surrounding Phase 5 and will continue to change 
throughout MCC field test.

Do what is appropriate for the site in question. If the customer does 
not have a policy for field test software in general and its interaction 
with the namespace in particular, I would strongly suggest that you 
assist them with developing one.  More and more products will be 
shipping that make use of the namespace this year.


2) Setting up directories for MCC's use.  Since MCC is a `plug and play' 
product, each site has a potentially unique configuration of AMs and 
FMs.  The MCC developers and documenters cannot know in advance just 
what DECdns directories will be necessary.

That is why the documentation specifies a backtranslation directory for 
each entity class to be managed and gives an example for BRIDGE

	MCC$<classname>_BackTranslation
	MCC$BRIDGE_BackTranslation

certainly for station the correct directory is

	MCC$STATION_BackTranslation

and for terminal servers is

	MCC$TERMINAL_SERVER_BackTranslation


As far as directories for nodes goes, we did specify that you need 
DNA$Node, DNA$BackTranslation and one child directory for each area in 
your network.  Since we don't know what areas are in your network we 
cannot do more than give examples.

...kjn

	re:.4


There is pretty detailed information on setting up the namespace in the 
installation guide (Chapter 3 - post installation info).  We took it out 
of the release notes and included it in the regular documentation.

If you have comments on the deficiency of the information in the 
documentation on MCC's use of DECdns, please start a new note with that 
subject and let the documenters (and us developers) know what would be 
helpful.

Thanks
...kjn

Regarding GE's problem using their corporate namespace for DECmcc FT.

First of all, Digital recommends using a single corporate namespace 
because a single namespace minimizes the managerial overhead which
would be incurred with multiple independent namespaces and because
accessing of multiple namespaces by applications on a single node may 
present problems in application configuration (RSM for example can not
deal with the use of the namespace nickname in namespace related 
command lines) and easy of use (does the user really want to remember
that there are multiple namespaces and which one to use for what).

In a single corporate namespace, naming objects associated with 
DECmcc is independent of those applications naming other objects 
(DFS disk or RSM clients) currently stored in the GE namespace.   
DNS has both the capacity and management capability to deal with this.   
Here are my thought and recommendations:

1) Build a directory hierarchy for use by DECmcc and use separate
   clearinghouse(s) which are part of the single namespace.  In this
   way all objects created by and for DECmcc are segregated into a known
   directory tree (which can be deleted should that be necessary).
   Using the MCC$<class>_BackTranslation and DNA$xxx directory names.

2) There are no performance issues related to maintaining one namespace.
   DNS is specifically design to accommodate LARGE numbers of entries.
   Additional servers can be added to the existing namespace and
   a structure set-up to achieve partitioning of DECmcc directories
   from others currently in use.   The additionally server(s) 
   quickens deployment of DECmcc and learning time around the use 
   of DNS because staff already involved with DNS can be used to
   either set-up the new directories or train additional managers
   whose responsibility and involvement with DNS is focused solely
   one DECmcc.

3) DO NOT build a separate namespace UNLESS it will be destroyed
   after the completion of field test.   Remember that there is
   currently no way of renaming across independent namespaces at
   this time.   When DECmcc completes field test and is available
   to the customer through normal channels, the customer will 
   likely be most interested in  preserving the investment made
   in setting up DECmcc during field test.   In a production environment
   GE will incur a management headache having to reinstall and 
   reinitialize the final DECmcc version from a 'toy' namespace 
   into their corporate namespace.

4) GE MUST solve their independent namespace management issue 
   prior to starting field test of DECnet/OSI where the network
   software requires a single namespace per domain (read domain as
   network).  The DNA$XXX directories used by DECmcc are the same
   ones required for DECnet/OSI Phase V (and GE is a Field test 
   site for these too).   

5) GE seems to have a people/political management problem that they must 
   resolve.  Either they build a new namespace for DECmcc and Phase V
   which will become their new corporate namespace or they use the 
   current namespace -- the goal is to achieve one corporate namespace.
   

		Sample hierarchy ---


		GE:. (GE's root directory) in corporate namespace
                  / \
                 /   \
             GE1_CH  GE1_CH          - corporate top level clearinghouse
              DFS     DECMCC         - create this directory at an existing
             or RSM  branches          DNS node and turn on this directory's
            branches	\	       ability to hold clearinghouse names.
                         \
                    DECmcc.MCCxxx_CH - create a new nameserver called
                          |            DECmcc.nodnam_CH
                          |
                     DNA$Nodes       - create the DECnet/OSI Phase V dir's
                     DNA$NodeSynonyms 
                     DNA$BackTranslation  in the clearinghouse DECmcc.MCCxxx_CH
				     - now create subdirectories ...
                     DNA$BackTranslation.%x0001 (note the %X) through
                     DNA$BackTranslation.%x003F for area 1 to 63 in HEX
                     MCC$<class>_BackTranslation
  
				     - Register all DECmcc objects here as 
				       MCC$<class>_BackTranslation ... 
                                       and so forth.
                                    
The above puts all the directories needed for DECmcc in clearinghouses
not associated with the rest of the namespaces (only child pointers get
stored in the main namespace).  Note that part of this set-up is for 
DECnet/OSI Phase V (note that tools will be available to set-up the 
DNA$.. directories with the DECnet/OSI Phase V kits).   

Also, this can be fairly easily dismantled if the needs arises.

Also note that DECnet/OSI Phase V uses the directory name syntax 
DNA$BackTranslation.%x0001 where %x indicates that the area simple
name is a HexRadix of 0001 (the hexadecimal byte pairs 00-01).   
The DECmcc documenation incorrectly specifies DNA$BackTranslation.0001 
(where the name would be a normal simple name '0001' were each character 
is represented as 1 byte).   This bug in DECmcc documentation will be 
corrected to reflect the proper syntax.

/Claudia Peters		

The suggestion proposed by CLAUDI::PETERS will not work exactly as 
specified.

1)  MCC$<class>_BackTranslation and the DNS$* directories  are assumed 
to be rooted directories - that is, they must be directly under the 
root.  I believe that the picture shown in the previous note has the 
suggested clearinghouse under a DECmcc directory.

2)  The DNA$BackTranslation children ARE implemented at the present 
time, EFT software, to be 

    DNA$BackTranslation.0001 	NOT 	DNA$BackTranslation.%X0001
				___


Since almost all products shipped by Digital over the next 2 years will 
make use of the DECdns Nameserver, we would suggest that GE and all 
other customers that participate in field test have a policy for dealing 
with field test use of namespaces.

Having a consistent policy will allow customers to deal with this in a 
smooth manner.

We knew that we were not completely compliant with the Phase V naming 
conventions (as there were no hard and fast conventions) when we 
developed the DECmcc use of the DNA$* directories.  We also published in 
the release notes that these directory names would probably change.

Be warned that with EFT update, DECmcc will conform to the, now solid, 
Phase V naming conventions for directores in the namespace.  This means 
deleteing node objects with the EFT software, installing the EFT update 
software, setting up new directories, REGISTERing node objects with the 
new software.

...kjn

The directories DNA$nodes, MCC$xxx, etc.  are in fact located under the ROOT
directory they just do not live in the same clearinghouse as the root 
directory nor is the root directory located in the clearinghouse that 
contains the directories used by DECmcc.   What does 'live' in the
clearinghouse with the root directory are the child pointers to
the DECmcc/DECnet directories and the object which points to the 
clearinghouse containing them.   Hence the lower clearinghouse solely
contains all information needed by DECmcc or any other field test software
using the DECnet/OSI directories.   /Claudia

    re ;11 Could you please tell us what is the current schedule for the
    EFT update.
    
    Thank you,
    	Georges.

       
       I am not sure if a formal date has been announced. We
       have started integration of the update; I will see if
       management has a schedule to post. If so I would expect
       it to be posted in note 3 - Baselevels.
       
       jill
       

    There are several situations when the single root directory for all
    MCC objects will cause problems .

    1. Field test ( next one). As Caudia pointed out, one can now
       reasonably separate  MCC directory for field test from production 
       name space . But next field test will have problems.

    2. Size. This directory will be huge for networks like Easynet.
       Do you imagine all DEC's manageable entities in few flat directories ?

    3. Spanning management domains.    
       We will have few global networks with possibly ( not sure at this
       time...) one global name spaces. Networks span several management
       domains. In the case of HEP/SPANnets there are now 46 different
       network management domains. There is no reason to have info about
       Spanish network available to New Zeland's network managers.
       People might want to call their devices the same ( "bridge1"),
       there is no need to have unique names in different management
       domains.

    4.  Security. 
        People in different management domains may not want to share
        detailed information about their network, like the one kept in
        MCC name space. But still have partially common name space for
        Session Control use. 

    All these problems would be easier to manage if one could define in the
    name space a subdirectories for network management domains and put MCC
    directories there, thus separating global MCC root directories into
    management domain specific directories.

    In the current product, only way to create a network management
    domain specific chunk of name space is through a private name space.
    It would be good to understand what exactly are implication of it, 
    will it work ? What would break ? In other words, how much of the
    real name space must be mapped in to this private space.


					wlodek
    

RE: .15

One very important point that I want to make right up front is that, 
aside from some well-known MCC$*Backtranslation directories that MCC
uses for address-to-name translation,  there are no MCC directories in
the namespace.  These MCC$*Backtranslation directories contain only 
softlinks which point to global entries in the namespace.  All of the
directories that begin with DNA$ are for the use of Phase V (and
sometimes IV).  

MCC enhances (augments?) entries in the namespace with information it
needs to do its job, but there are no entries which are specifically for
MCC's use.  MCC shares the namespace, and the entiries that represent
globally addressable entities, with other applications. 

I believe that MCC will allow the customer to set up this namespace as 
desired or dictated by corporate policy.  However, to specifically 
address points made in .15, let me use the examples mentioned there.

1. Field Test 

Yah, field test is always tough, especially with a V1.0 product.
Don't forget we are a field test product.  Many of the restrictions that 
are necessary for the current EFT product will go away with the EFT 
Update and V1.0 product.

2. Size.

With MCC V1.0 EFT update, most restrictions about placing entities in the 
namespace will go away.  The requirement to name bridges and stations so 
that they were placed under the root was a short term solution to a 
namespace searching problem.

Even Phase IV nodes will be able to take on fullnames, so that they can 
be placed wherever desired, instead of restricted to placement under the 
DNA$Node directory.  This will aid the customer in setting up the 
corporate namespace in preparation for Phase V.

The customer should have a plan and set of policies in place for the 
configuration of the namespace.


3. Spanning Management Domains

We have chosen to deal with the management domain in a different 
fashion.  Beginning with MCC V1.1, you will be able to group entities 
managed by MCC into domains.

A Domain is a user-defined (arbitrary) group of global entities.  
Domains have no membership size limit.  Any specific entity may belong 
to multiple domains.  A domain is an entity, like any other entity in 
MCC, and can be managed by MCC using the same directives.

Example domains might be:
	1) all of the bridges in building1
	2) all of the managed (of any class) entities on floor1 of building1
	3) all of the entities (of any class) which belong to manager1
	4) all of the nodes and bridges  managed by operator3
	5) all of domains in SPAIN
So, a bridge that is on floor1 in building1, managed by operator3, and 
belonging to manager1 will be in domains 1,2,3, and 4.

You can use the namespace to partition the entities into  management 
domains, however, use of the namespace alone, does not allow any one 
entity to participate in or be associated with multiple domains.

Use of a naming policy in the namespace in conjunction with the 
definition of MCC domains offers a more flexible solution which allows the 
customer to partition the namespace into management domains, is desired, 
but does not tie any entity to one and only one domain.

To use your example, of HEP/SPANnets, you could certainly name two 
bridges in different parts of the namespace with the same local name.  
For example:

    root:.SPAIN.city.building.bridge1 OR root:.NEWZ.city.building.bridge1

MCC does not preclude this.


4.  Security

You are correct people in different management domains may not want to 
share detailed information with other management doamins.

MCC and the namespace work in conjunction to provide this security.  The 
namespace administrator may protect the directories and objects in the 
namespace so that only certain persons have access.  In addition, since 
domains are entities defined in the namespace, they can be protected as 
well.

For example, there are two ways to provide security on a management 
domain basis.

	1)  put all entities in a particular management domain in a 
protected partition of the namespace along with any MCC domains which 
associate entities within the large management domain.

	2) make all entities available in a global pool, but protect the 
MCC domain entities.

For V1.1, the iconic map interface presents domain views.  If a user 
does not have access to the domain, there is no access to the domain 
membership.

    Great ! If we get rid of root directories I don't see problems.
    Backtranslation is OK since I can't see ( other then maliciously
    entered) duplicated object names.

    Actually, multiple name spaces is the nightmare we will unfortunately
    have to live through, but MCC will not automatically add to the mess.

    					regards,

    							wlodek

What's the current status of this issue?  Our site (a Digital internal site,
part of the Digital corporate Easynet) is bringing up DECmcc now
for the first time.  MUST we create a private namespace, or can we use the
public one?  What are the issues of either choice?  If we can't use the public
namespace now, what stands in the way?

We did a trial run of MCC_DNS_SETUP.COM, and found that only the .DNA_Node
directory was lacking from the namespace:

.
.
.
$       IF NS_INIT_BCK .NE. 1 THEN TTOUT "    .DNA_BackTranslation"
$       IF NS_INIT_SYN .NE. 1 THEN TTOUT "    .DNA_NodeSynonym"
$       IF NS_INIT_NOD .NE. 1 THEN TTOUT "    .DNA_Node"
    .DNA_Node
$       IF NS_INIT_TIM .NE. 1 THEN TTOUT "    .DTSS_GlobalTimeServers"
$       IF NS_INIT_MCC .NE. 1 THEN TTOUT "    .MCC"
$       IF NS_INIT_B_BCK .NE. 1 THEN TTOUT "    .MCC_Bridge_BackTranslation"
$       IF NS_INIT_S_BCK .NE. 1 THEN TTOUT "    .MCC_Station_BackTranslation"

Thanks, in advance, for your help!
tl

Who shold I talk to about this?  We won't use DECmcc until this issue is
resolved.

Thanks!
tl

Talk to your local/regional DNS support group and escalate the question
up the food chain if this is a real problem for you. Most initial problems
were due to replication and security issues. Resolving some of this also
rests (opinion) as an EASYnet implementation issue. These issues have been
addressed but exactly where it stands today I'm not sure. FYI, implementating
a private NS turned out to be reletively easy using the MCC setup procedures
and was not a painful workaround for us. 

best regards,
brad...

Okay, I'll do that, thanks.  What issues do you see around using a private
namespace now, and moving to a public namespace for DECmcc in the future?  How
painful/labor-intensive will this be?

Thanks!
tl

> Okay, I'll do that, thanks.  What issues do you see around using a private
> namespace now, and moving to a public namespace for DECmcc in the future?  How
> painful/labor-intensive will this be?

Issues probably include all these private NSs where one should actually be
used (DEC:) so there is shared resources/support and info. Something that
may crop up in the future is that NSs advertise on the LAN, therefore all
private NSs are doing this. I'm not sure if this will ever develop into a
technical prob or not but I know there are those who would like to avoid
this. As more applications use DNS DEC: (or the DNS application itself )
must be friendly enough to deal with it. I would recommend using *ALL*
command procedures to register entities, domains, and add members to domains
initially at least. This way you'll only have to edit the procedure, change
the client pointer, and run it again on DEC: to transition. Also, use the
current structure for DEC: if you want (although MCC does not yet display
only the synonym on the map). This will also make life easier to transition.

good luck,
brad...

Thanks to the leadership of John Regan, DECmcc use of the 'public' DNS
namespace is moving toward a reality.  Many DECmcc objects, with the necessary
access, now exist.  The major bugaboo still seems to be the node information.

DECmcc expects to use node information in .DNA_node and .DNA_NodeSynonym.

Digital's corporate DNS namespce implementation, however, places this 
information in each site's directory, as in:

	.HLO.CRONIC

Use of this data is highly desirable, as it is maintained by the corporate node
registrar.  I have zero interest in maintaining this information myself,
duplicating this effort.

How can these two be reconciled?

Thanks!
tl

    There is nothing in DECmcc that particularly "expects" to use the
    .DNA_NODE directory. It is simply the default for the DECnet Phase IV
    to Phase V transition tools. Any use of this directory just causes
    entity names to be of the format .dna_node.took (for example). DECmcc
    (and DECnet for that matter) are perfectly happy with .LKG.TOOK
    instead.  The use of the DNA_NODESYNONYM directory is a DECnet Phase V
    requirement. DECmcc is simply conforming in this case.
    Digital's corporate DNS namespace also uses .DNA_NODESYNONYM as well
    as the site directories as you pointed out.
    
    Did this help or did i confuse it more?
    
    s/rob

    We'll now that the cat is out of the bag....
    
    I'd like to set the record straight,
    
    There are NO technical problems with DECmcc users using the corporate 
    DEC: namespace.  All the directories exist (.MCC_BRIDGE_BACKTRAN
    etc..), all node objects are loaded and local DNS folks should
    have the where-with-all to create local site bridge directories for
    example (ex. .HLO.S.BRIDGES) using any naming scheme that suits
    them to allow local MCC users the ability to "register" MCC managed
    objects....  
    
    We've also made progress with regard to access control
    such that local site obj_admin groups (.HLO.OBJ_ADMIN) can be granted
    FULL Access to MCC BACKTRAN dirs as necessary to support object
    registration.  The Local DNS folks need only to add local MCC users
    to the admin group and then send along a request to add the
    site.obj_admin group to the ACS on the directory in the namespace.
    
    That will work for Concentrators, Bridges, Terminatl Serves, Stations 
    BUT NOT FOR NODE OBJECTS !
    
    That's where the problem lies!!!  DNRS owns node objects and therefore
    except for a limited few it has the access control necessary to make
    changes to node object attributes.  
    
    So now comes along DECmcc and MCC users want to be able to register
    node object attributes just like DNRS.  Well that means that 
    DECmcc users need special access control which includes DELETE
    privs to the object.  Now management doesn't like this because all of a
    sudden MCC folks can blow away their portion of node objects without
    actually using DNRS todo it.....this causes some justifiable paranoia.
    and could result in an inconsistency between DNRS and the DEC:
    namespace. (DNRS will be changing soon I hope but that's a different
    story.)
    
    A simple solution exists that I'm "testing out" with 2 sites at the
    moment,,,,HLO (Terry Lemons) and LKG (Mike Condry and Alberta
    Sullivan)....the description follows:
    
    	1. Remove .site.OBJ_ADMIN access to node objects...this can
    		be done with one command with DNSV2.
    
    	2. HAve the local .site.DNS_ADMIN person register the appropriate 
    	  node object attrributes so that DECmcc users can "manage" the
    	  object
    
    	This works OK since the .site.DNS_ADMIN folks already have the
    	access control necessary to affect the objects in question and
    	since "registering" a node object only really has to happen
    	once and perhaps again if the "line speed attribute changes".
    	So except for the initial registration node object attributes
    	remain pretty constant.  I'm also told that if there are many
    	objects for MCC to register the DNS ADMIN person can be given
        an NCL script to run in order to cut down on the time and effort
    	spent responding to MCC requests..  Of course we already find that 
        the DNS people at the site are also the MCC people in which case 
    	we haven't got a problem and we';re not risking anything more than
    	we are today. 
    
    The bottom line is this:
    	
    	1. ONly 2 sites are setup to do this today (HLO and LKG)
    		I'd like this to be the case for a few weeks before
    		we open this up to the rest of the US..
    
    	2. If you are interested in staying informed on progress to date
    	then I suggest that you stay tuned to this note or send me mail at
    	FROSTY::JREGAN (I'll put together a distribution list...)
    
    	3. As we get more comfortable with this,,,I see know reason why
    	we can't adding more sites to the DEC: namespace user list...
    	...but it all depends on management's opinion of the level of
    	exposure ....
    
    
    OTHER ISSUES :
    
    	The MCC_*_BACKTRANSLATION directories have to be owned by someone.
    	Since all * object softlinks in the world will exist in one directory
    	it's going to be REAL DIFFICULT to:
    
    		- shell out responsibility for the directory to a
    		particular geography...THe ESC who would normally
    		accept responsibility outright for this,,,is having their
    		own resource problems and are reluctant to take on more
    		than they can chew at this point...
    
    		- replicate the directory more than a few times simply due
    		to it's size (at least this will be an issue until DNS V2
    		is installed on all root servers...)
    
    
    
    stay tuned...
    
    jr

    Re .24  Ah, light dawns!  Rob, this made it a bit clearer.  Well, then,
    I have two more problems:
    
    1) .DNA_NodeSynonym doesn't exist in the Corporate DNS namespace, as of
    this writing.
    2) I'm following the DECmcc Installation Guide, and am at the point in
    the post-installation section where I'm directed to run
    MCC_DNS_SETUP.COM.  When I run this procedure, however, it bombs, as it
    can't find .DNA_Node or .DNA_NodeSynonym.  If I don't need to run this,
    or need to edit it somehow, please let me know.
    
    Re .25, Sorry if I spoke out of turn in describing your work.
    >   I'm also told that if there are many
    >	objects for MCC to register the DNS ADMIN person can be given
    >   an NCL script to run in order to cut down on the time and effort
    > 	spent responding to MCC requests.
    
    Do tell?  What do I need to do to get DECmcc to create an NCL script of
    node attribute changes?
    
    Thanks, all, for your help!  We're getting close!
    tl

    Actually DEC:.DNA_nodesynonym does exist or at least it used to exist..
    it's just broken right now.  The ESC and others are in he throws of
    getting it repopulated on a DECdns V2 server at this very moment..
    
    One thing that I gathered from taking to Terry this morning was that
    DECmcc folks should not be trying to "create" any directories in the
    corporate namespace.  All the directories needed to run DECmcc already
    exist or will soo once Synonym is recreated...
    
    This seems to be misleading in the MCC documentation which as I recall
    assumes that "the namespace" must be built...mcc does indeed provide
    the mechanism to do that,,,,for customers if it hasn't been done
    already.
    
    jr

    I have forwarded your suggestion to the writers of the appropriate
    manuals.  We should say that if you're going to use DNS and the
    namespace doesn't exist, you should create it, but if it does exist,
    you shouldn't.
    
    I should point out that conditions in the field are not always the same
    as conditions within Digital.  Last I heard, the majority of customers
    did not have DNS namespaces set up, so simply telling readers to use
    their existing namespace would, on the main, be more misleading.