Conference azur::mcc

    I would suspect that you need to clean something up to get rid of MIR
    entries in MCC.  I defer that part... but on DNS:  
    
    Be careful to delete the DNS database - for V1.1 it is usually in a
    file with the extension .DNS in the default disk area belonging to the
    DNS$SERVER account.  This will let you reuse the same name for your
    clearinghouse & namespace.
    
    Be careful to delete the file SYS$SYSTEM:DNS$GLOBAL.GBL 
    
    Be VERY careful NOT to delete any executables.  Particularly ones with
    CLERK in them.  This is important on versions of VMS 5.3 and later.
    
    Sally

re. .1

Colo Spgs tech support walked me through the de-installation and re-installation
of DNS.  I worked the DNS installation from their list of procedures.

My real question is, "How do I handle MCC given that I had to totally blow
away my DNS namspace and start over from scratch?"

Any MIR entries in the DNS directory are gone.  I accepted the reality that 
everything I had configured in MCC would be lost, and I need to reconfigure
MCC from ground zero.

FYI...

I found out that the DNS problem was caused by someone setting the LAVC 
system time to Jan 1992 for everyone in the cluster.  This resulted with 
the infamous "Unable to communicate with DNS server" error anytime I tried 
doing anything in MCC .  DNS does not provide an easy way to go back and 
reset it's internal timestamp.  

I would still appreciate any input on my original question in .0.  I've 
reinstalled DNS and am ready to proceed with the recovery of MCC, but I want
to make sure I do it correctly.

Thanks.

Merlin

    Your problem with the cluster time being set to 1992 was not caused by
    somebody doing something stupid, it's a weird VMS bug, I got caught
    by it too and just finished recreating my dns namespace as well.
    
    VMS has a bug that only surfaces if you reboot a cluster early in
    January. Something about the date is written on the image boot file,
    but only part of the date is written, in some circumstances the year
    will be incremented by 1, hence the year 1992.
    
    The fix for this problem is to set the time correctly (on every member), 
    then issue the set time command with no arguments (no time). I don't know 
    if you have to do that on every cluster member but with all the problems 
    this bug causes I wouln't risk it! If you don't do the second set time
    with no arguments you will notice that the year 1992 comes back on your
    next reboot. 
    
    Linda
    

I may be understating your problem, but a while ago I also ran into problems
with DNS and ended up having to reinstall.  I did work with CSC and got some
good direction, but ended up deleting all DNS*.*.* files.

Before doing this, however, I compiled two listings....one for DNS server
files and one for DNS client files.

I simply copied all client files from another workstation of similar version.
Then reinstalled the DNS server kit.

Once that was done, all I did was to rerun the MCC installation command
procedures and have had no problems since.  I also made the assumption that
you have in .0, that all DNS information for MCC was expendable.

Good luck,
Al

    Don't delete ALL the DNS$* files. Many are part of VMS and it is a pain
    to put them back.
    
    To reinstall, just execute SYS$STARTUP:DNS$STOP (or something like
    that), and then delete SYS$SYSTEM:DNS$GLOBAL.GBL.
    
    That's all. Then reinstall the server kit.
    
    s/rob