Conference azur::mcc

Converting from DECdns to a local namespace requires extracting
all of the registration information from DECdns, and then re-registering
after switching the system to local namespace.  I think there may be
a procedure for the extraction, but haven't used it personally, so
I don't know how difficult it is.

>    	BTW, the "custom" AM was designed using a local MIR.  Does anyone
>    have a feel for whether it's easier to integrate the "custom" AM into
>    our DNS namespace or whether we'd save some time going the other way... 

The AM code should not need to change to handle local namespace vs DECdns.
The choice is handled by low level kernel routines.

>    I've heard that local MIRs are the way to go with 1 "centralized" MCC
>    Server, which will act as the *server* for other MCC Stations in 3-4
>    other geographical locations...  Any tips?  Thanks.

I'm not sure what you mean by *server*.  Information stored in a local
namespace on one DECmcc system is not normally available to other
stations running DECmcc.

    Erik,
    	Hi there.  could you expand on this reply abit more, or could
    someone else in the conference that's converted their DNS namespace to
    a local MIR please add a pointer to a procedure I could look at? 
    Thanks in advance.  I'm just not quite grasping it...  /Mic
    

Well, I haven't done it.  But I would guess the procedure on ULTRIX would
be as follows:

1) Use the shell script pointed to in note 3126 to extract all the
   information in the DNS portion of your repository (I think there
   is a equivalent DCL .com file)

2) Edit the files /usr/mcc/mcc_system/mcc_login.{sh,csh)

   change MCC_DNS_SELECTION from DNS to MIR

3) You may need to re-enroll the registration FM to create the
   local namespace files.

4) Use the file produced in step 1) to re-register all of your
   entities in the new namespace.

If you try this, let us know how it worked.  We don't have much
experiencing switching between namespaces; we originally envisioned
people picking one at installation time and sticking with it.

NOTE: Switching in the other direction (local NS -> DNS) is a bit
      more complicated, since you need to define an IDP.

    Erik,
    	Now I AM confused!!!  I'm not the same dude as in #3126...although
    at this point I'm willing to try installing an Ultrix stations instead
    of our VAXserver...smile.
    	We're trying to integrate the "custom" AM that we wrote, using a
    local MIR, onto the MCC platform that I installed with DNS 1.1 as our
    namespace of choice...that's where the initial question (#3131) came
    from.  Sorry for the confusion...smile.
    
    /Mic
    

    Hi there,
    	This item (#3131) has escalated somewhat on our project list, and I
    need to repost the note.  Maybe someone out there can send me mail or
    give a call to explain the process???
    	Basically, here's what we want to do.  We have 2 different VMS
    platforms running DECmcc.  1 platform was designed using a Local MIR. 
    It is currently running BMS 1.2.4.  It contains a "custom" AM.  The
    other platform, is running BMS 1.2.7, and was designed using DNS 1.1 as
    the namespace server.  The only AM that didn't come with BMS, is TSAM,
    which we've layered on the MCC station.
    	What I'd like to be able to do, as painlessly as possible, is to
    integrate the DNS stuff into a Local MIR.  Either 'THE' local MIR that
    the custom AM is installed in, or 'A' local MIR and then integrate the
    custom code into it...  Does this sound confusing?  Erik's previous
    note seems to point that it's quite simple, as a matter of fact,
    there's a procedure (I think it's something like,
    ...DNS_TO_LOCAL_MIR...) that does the converts...
    	I *really* would appreciate any/all help in this one.  Thanks in
    advance.
    
    /Mic (DTN 474-7472, VOICEmail, leave a message I'll call back)  or
    E-mail, NM%POBOX::GALVIN.
    

    Hi there,
    	Ok, I'm getting *warm*....got great mail from John Egolf...thanks. 
    Also, Erik, I *finally* get your drift...sorry 8^).  Stay tuned and
    I'll post any gotchas that perhaps our viewers may find of interest ;^}
    
    /Mic
    
    PS Oh, BTW, is there any reason why I can't get to PPINC?  The pointer
    I got for a procedure to dump DNS namespace and then setup a local MIR
    is on PPINC, and I haven't been able to get to it for 1+ days???  Has
    this data, MCC_PUBLIC (note #3.???) moved to a new location?  Thanks!
    

PPINC went down (along with the rest of our system) due to a power failure.
Apparently it took longer to boot PPINC.  It is back now.

-- Erik

    Hi there,
    	Well, I tried running a procedure, MCC_DUMP_DNS.COM, which I got
    from PPINC.  All was going well until, it appears, I get to the
    TERMINAL_SERVER stuff...  Let me explain.
    
    	I ran the .COM file with no 'p1' parameter, since I technically
    only have 1 domain.  In reviewing the logfile, I'll post what I saw.
    
    !Dumping TERMINAL_SERVER
    
    %MCC-I-NOPARCMD, 'DOMAIN_SPEC', to file = SYS$SCRATCH:
    MCC_TERMINAL_SERV <CR>
    
    � as an aside, all entities that I have added to my domain reside,
    PHYSICALLY, in the Computer Room, except for the terminal servers which
    are PHYSICALLY in another state...don't know if this is my problem?
    
    %MCC-I-SYNTAXERR, SYNTAX ERROR--UNABLE TO INTERPRET REMAINDER OF LINE
    
    %MCC-E-ATTRNOTALLOW, NO ATTRIBUTE OR ARGUMENT ALLOWED
    
    � next, it goes humming along until it gets to the Collector
    
    !Dumping COLLECTOR
    
    %MCC-I-NOENTREG, NO ENTITIES OF THE SPECIFIED CLASS ARE CURRENTLY
    REGISTERED
    
    � finally, it gets to creating the command file...
    
    !Creating command file named SYS$LOGIN MCC_LOAD_DNS.COM
    
    � it goes whacky at this point...
    
    !Parsing for TERMINAL_SERVER entity information
    
    DCL-W-INSFPRM, missing command parameters - supply all required
    parameters
    
    DCL-W-INVERB, unrecognized command verb - check validity and spelling
    
    'MCC_TERMINAL_SERVER_ID'
    
    DCL-W-UNDFIL, file has not been opened by DCL--check logical name
    
    � It does this for EVER!  I stopped it after ~10MINS, and 3k blocks of
    a logfile.
    
    	Next, I tried the above procedure again, (I'm sadistic) and this
    time, I supplied my DOMAIN NAME as a 'p1' parameter...guess what?  Same
    thing!!!
    	One thing I noticed, in my SYS$LOGIN area it successfully created
    an MCC_LOAD_DNS.COM, the first time I ran the above mentioned
    procedure, it created a .COM file that actually registered all ENTITIES
    that were in my DOMAIN.  When I specify the 'p1' parameter, using my
    DOMAIN NAME (DOWNERS_GROVE), it doesn't put any of the registration
    info into the MCC_LOAD_DNS.COM file.
    	My head is ready to explode....smile.  Please help.
    
    /Mic
    

    Like I haven't asked enough....  When 'staging' the MCC_DUMP_DNS.COM,
    does it matter if the DNS processes are currently active?  What I mean
    is, I don't need to issue a DNS$STOP *before* doing it, do I?
    
    thanks,
    
    /Mic
      

    Mic,
    
    	You can @DNS$STOP.COM if you have a complete namespace supported by
    one or more other nameserver nodes.  You must have the Clerk software
    running to communicate with the server, though.
    
    	DNS$STOP.COM stops the DNS nameserver software.  If you have only
    one nameserver, then you will not be able to read from the namespace. 
    If you have more than one nameserver, and there are directories in
    different clearinghouses on different nameserver nodes, you could have
    a real mess on your hands.  Some things would appear, while others
    would not.
    
    	If you have more than one nameserver node, it would be wise to
    rebuild all of your directories to ensure that everything in properly
    ordered.
    
    	IMPORTANT:  Issuing the DNSCP> REBUILD DIRECTORY command can 
    		    cause a great deal of damage to your namespace if
    		    you do not know what you are doing.  Read the 
    		    DNS manual.  If you use the REBUILD command and
    		    exclude a directory that is master, you can end
    		    up with a partitioned namespace.
    
    -Dan

    Hi there,
    	Well, I was able to convert *most* of the DNS stuff to a local MIR. 
    I used the MCC_DUMP_DNS.COM file, that seems to have several authors... 
    Anyway, there's 2 things I noticed:  1.) the TERMINAL_SERVER stuff does
    NOT work!  I described the problems I was having in an earlier note,
    contained in this base note;  2.) the CIRCUIT stuff is commented out in
    the procedure, and since I had CIRCUIT information that I wanted to
    use, I tried commenting it out, and it barfed...  So I re-commented it
    out and it ran ok.
    	One additional question I have, since I haven't had the courage to
    reboot my MCC station yet, when I setup the DNS startup files, I've
    been told my Dan Hill and a few others, that I need to ensure that the
    DNS Client is still running, but I can do away with the DNS server. 
    How does one do this?  I have a DNS$STARTUP.COM that gets called from
    SYSTARTUP_V5.COM, I was thinking of commenting it out and leaving the
    files for the time being, so as not to make a mistake and delete some
    Client stuff...  I haven't really analyzed it yet, but if I just
    comment out DNS$STARTUP, will the Client software still startup up???  
    	Last question, my customer has queried me about the future of MCC
    relative to DNS.  This may be Pandora's AM, but will we support a local
    MIR in the next release of DECmcc?  Or as rumour has spouted, will DNS
    ONLY be supported...?  Thanks.
    
    /Mic
    

    Mic,
    
    	Since you are now accessing the local MIR, you need not care about
    DNS for DECmcc.  If you are not using DNS for anything else (e.g., DFS,
    RSM, OSI, DECmessageQ, ...), then you can simply comment out the
    @DNS$STARTUP.COM commands in SYSTARTUP_V5.COM and proceed normally.
    
    	If you have only one nameserver, then you have only one clearing-
    house.  The files are in SYS$SYSROOT:[DNS$SERVER].  If you are TRULY
    finished with DNS, then delete these files.
    
    	If you have another nameserver elsewhere that was working in
    conjunction with the nameserver containing the clearinghouse you
    wish to delete, YOU WILL HAVE PROBLEMS if you delete the files I
    mentioned above.
    
    	Regarding DECmcc's use of DNS in the future, when we go to OSI,
    you WILL need a namespace; therefore, it is a good idea to stay
    acquainted with DNS.  Having DNS as a common repository for DECmcc
    is nice if you have OSI or if you have multiple DECmcc management
    stations.  With a common repository, all you have to do is copy the
    map files to each of the management station nodes, instead of the maps
    AND the local MIRs.
    
    -Dan

    As you discovered, CIRCUIT info isn't written for the procedure yet.
    
    I have fixed the Terminal_server bug you found for me. Thanks. I have
    also fixed up several other problems as well.
    
    There is no truth in any rumor about changes to which namespaces
    (local, DNS or any other) that DECmcc will support in a future version
    (meaning after V1.2) since there have been no decisions made in
    those areas by Engineering or anyone else that I know of. So, don't
    worry.
    
    There is a file called DNS$CLIENT_STARTUP that is used to startup
    the DNS Client if you are not hosting a server as well. If you
    need continued access to the DEC: or any other namspace, just
    substitute the client startup for the general DNS startup in
    your startup files (Have I got this right folks???).
    
    s/rob