| Attempting to answer my own question... after reading the V1.2 installation
guide and the discussion about using the DNS name space it appears that
almost everything "important" is stored in DNS...
"If you sleected the DNS, the DNS stores the registered names you create
for DECmcc global entities. You also supply the entities' network addresses.
The names are then available to all DECMcc users on the network. The DNS
also stores other relevant information, including the names of child entities,
reference data, and a list of the domains that an entity is a member of."
By this I believe the only things not stored in the remote DNS would be things
like historical data, rules and the actual map files.
Of these three the rules and map files are easily moved to/from VMS & Ultrix
so I guess the only other concern is the historical information??
Thanks!
Peter
|
| Hi, Peter,
To move the DNS directories containing all objects, links, etc.
used by DECmcc is reasonably easy, assuming the install of DNS on the
VMS nameserver goes well. Here is the quick list:
1. Install DNS on a VMS node designated to be a nameserver, being
sure you select the existing namespace you wish the server to
join.
2. Once you have verified that everything is working, issue the
REBUILD command from DNS$CONTROL.
Example:
DNSCP> REBUILD DIRECTORY . MASTER vms_ch READ_ONLY ultrix_ch
You must issue the rebuild for EVERY directory beginning with
the "." root directory and ending with the lowest level
directory in the hierarchy. For example:
.DNA4_BACKTRANSLATION.%X49.%X0001
Be sure you do this in order, REBUILDing .DNA4_BACKTRANSLATION
before .DNA4_BACKTRANSLATION.%X49, and so on.
One way to do this is to use DNS_OBJECT_WALK.EXE to create
a hierarchical output of your namespace, capture it in a text
file, then edit the text file to include the DNSCP commands to
rebuild your directories. If you need this utility, I can
provide it. The command syntax for V2 of DNSCP is supposedly
good enough to provide the same thing as this utility, though
I have not used it.
3. Be sure your directories are complete. To do this,
DNSCP> STOP CLEARINGHOUSE ultrix_ch on the Ultrix node, then
try DECmcc or use DNSCP commands on the VMS nameserver node or
any DNS client, referencing your namespace. Issue the
DNSCP> START CLEARINGHOUSE ultrix_ch when you are satisfied.
4. Once you are sure your directories are complete, issue the
following REBUILD commands (preferably via command procedure),
this time NOT including the Ultrix clearinghouse:
Example:
DNSCP> REBUILD DIR . MASTER vms_ch
Do this for all directories.
REMEMBER: The above command will remove all "." directory
replicas from the namespace. These replicas MUST
be READ_ONLY, not MASTER. If you have ANY master
directories, you could very easily end up with a
partitioned namespace in which you can potentially
write to one clearinghouse master directory one
time, and another at a different time.
(There is more to this, so send mail or give me
a call if you are unsure. The last thing you
want to do is mess up your namespace and spend
your weekend re-installing DNS on all nodes,
which I have done.)
5. At this point, you can DNSCP> STOP CLEARINGHOUSE ultrix_ch
on the Ultrix node again, then completely stop DNS. Delete
the clearinghouse file on the Ultrix system and be sure that
DNS does not come up on that node. Your're done.
By the way, I have done all of the above on VMS systems.
CONCERN: My understanding from discussions with Scott Bingham of CSC
lead me to believe that you may encounter a "hang" problem
on a DNS V1.* nameserver when bringing it into a namespace
served by DNS V2 nameservers. VMS nodes usually run V1.*
while Ultix nameservers run V2.
Regards,
Dan
|