| Re .0
kjn>> Hope these answers help to clarify.
kjn>> Rumor has it that the development group will come out with a
kjn>> `How DECmcc uses the namespace' document before too long.
We have had a number of questions here at the Customer Support Center (mostly
from customers who had or were building large, complex corporate namespaces)
about the default DNS directory structure created for DECmcc.
The implication in the DECmcc Installation Manual is that the
.DNA_BackTranslation, .DNA_Node, .DNA_NodeSynonym, .DTSS_GlobalTimeServers,
and .MCC directories are REQUIRED. As a matter of fact, they are identified
as "Directories Required for DECmcc". This is a significant source of confusion
for our customers (a conclusion based upon the calls we get here at the support
center).
kjn>> The following directories are required for the proper functioning
kjn>> of DNA5 and DECmcc
.DNA_BackTranslation
.DNA_NodeSynonym
kjn>> The following directories are required for the proper functioning
kjn>> of DECmcc
.MCC_<class_name>_BackTranslation
kjn>> The following directories are created by the V1.1 DECmcc DNS setup
kjn>> command file for compliance with procedures suggested by DNA5
.DNA-Node
.DTSS_GlobalTimeServers
kjn>> The following directories are created by the V1.1 DECmcc DNS
kjn>> setup command and are going away for V1.2
.MCC
I looked through most of the notes in this conference with the keywords DNS and
DNS use and have not found a definitive answer to these questions.
1. What side-effects might occur if the node4's are registered in directories
other than .dna_node? Most customers with large complex namespaces organize
their nodes functionally (ie into subdirectories that have ACE's implementing
distributed management of these nodes). We have seen no side effects but must
admit that the namespaces we use are relatively small and simple.
kjn>> none, DNA_Node is merely a SUGGESTED policy on the part of DNA5 as
kjn>> a place to park Phase 4 nodes until they get real Phase 5 names.
kjn>> You can name your nodes whatever you like. DECmcc creates the
kjn>> directory and generates the default command that registers your
kjn>> Phase 4 nodes under .DNA_Node to be compatible with the command
kjn>> files that are shipped with Phase 5 and NCL. We have made every
kjn>> attempt to be totally compatible with DNA5.
2. If the node4's are scattered among a hundred different directories, how are
the backtranslation and node synonym links managed?
kjn>> The softlinks are like secondary keys. If you use an alternate
kjn>> name to refer to a node, in particular the name or Phase 4
kjn>> address, the links are used to find the actual object entry in
kjn>> the namespace. It all works correctly, no matter where in the
kjn>> namespace you put node object.
3. What about different MCC entities living in the same subdirectory (node4's,
node5's and ethernet stations in the same subdirectory)? What effect on back
links, etc?
kjn>> No problem
4. Has anyone seen any problems with objects from multiple clients (DFS and
MCC for instance) co-existing within the root? We have seen at least one case
where DFS and MCC appear to have had a collision (DFS objects with MCC
attributes and MCC objects with DFS attributes....). This problem was solved by
removing the objects and placing the MCC objects (domains, mostly) into their
own directory.
kjn>> I am not sure I understand the problem. The whole point is to
kjn>> have objects shared by multiple applications. If the collision
kjn>> resulted from naming two different objects with the same name
kjn>> (For example, a DFS disk and a node with exactly the same name),
kjn>> then you have problems. But if you are legitimately referring to
kjn>> the same object from two applications (DFS and DECmcc) then the
kjn>> object would have DFS and DECmcc attributes.
5. My colleague, Walt McGaw, had asked about the .MCC directory (see note 1730).
Since there have been no replies to that note I will ask the question again
here: We have a customer who already has a .MCC directory (MCC has quite
another meaning at Monsanto). Will there be any ill effects if she uses her
.MCC directory for her own purposes? It was my understanding that the original
use of the .MCC directory for DECmcc was to hold information about distributed
Directors (when and if that feature existed). Will we ever use the .MCC
directory or is it obsolete?
kjn>> I believe that the .MCC directory will no longer be created or
kjn>> used by MCC after V1.1. No bad side-effects will occur if you
kjn>> use the directory for your own purposes, even with V1.1.
Thanks in advance
Doug Dickerson
|