Conference azur::mcc

    
    Does your dns$default_file.dat indicate your pointed to the proper
    name space?  Might want to rerun dns$change_def_file.com.
    
    Just a thought,
    
    Scott

>    Does your dns$default_file.dat indicate your pointed to the proper
>    name space?  Might want to rerun dns$change_def_file.com.

Yes, both servers are in the DNS$DEFAULT_FILE.DAT.

When DECmcc recives information from a read-only replica it dosen't seem
to like what it gets !!

/Stefan

    Just a wild shot;  Is the DNS TDF set correcly on both servers?
    I have seen skulking work ok, but propogation of changes not work due
    to time difference between the two servers. The time on the two servers
    MUST be close to the same for things to work right.
    
    s/rob
    

Both systems have DNS timezone set to 02:00 and MCC_TDF logical set to +2:00
Time is synchronized on both systems with DECdts, the skew between the system
clocks is less than 00:00:00.10 s

/Niklas

    Hi,
    
    I'll throw my two cents in.  I am experiencing the EXACT same problem
    as Niklas in .0.  I am out at SmithKline and we are looking to roll
    out the MCC platform in December using four DNS servers.  I am looking
    for an update on the situation as I will have to advise my customer
    regarding the use of the two servers they already have operating
    and the two they intend to purchase for this project.
    
    Thanks,
    
    Dave Comfort

    
    Another situation encountered:
    
    Two clearinghouses PHMCC_CH and PHVMCC_CH, which weren't working
    properly as indicated in previous entries in this note.  Before
    discovering the failures on read-only replicas, I had created a
    DNS directory tree:
    
    				.domains
    				    |
    				---------
    				|	|
			       .us     .uk
    
    .us is mastered by PHMCC_CH, which is the master of the root dir and
    all others.  .uk is mastered by PHVMCC_CH, the only directory allowed
    to be mastered.  So things looked like this from DNS$CONTROL:
    
DNS> show char dir .domains.uk
      Convergence _____________ HIGH
      Last successful update __ 23-OCT-1991 08:49:59.40
    
      Directory copies:
    
         Address _________________ PHVMCC  (1.59)
         Replica Type ____________ Master
         Clearinghouse ___________ MCC_NS:.PHVMCC_CH

         Address _________________ PHMCC  (1.34)
         Replica Type ____________ Replica
         Clearinghouse ___________ MCC_NS:.PHMCC_CH
    
    Sooo, I wanted to shut down the PHVMCC name server and associated
    clearinghouse so things would work correctly.  Therefore, to maintain
    write access to the .domains.uk directory, i performed a:
    
    DNS> rebuild dir .domains.uk master phmcc_ch read phvmcc_ch
    
    Things then looked the way they should and even worked, most of the
    time, ie. when the DNS request was posted to the PHMCC_CH
    clearinghouse.  Then I made my fatal mistake and attempted a 
    
    DNS> remove dir .domains.uk clear phvmcc_ch
    
    After this, MCC could not find the obj (a domain in the .uk dir).
    
    ie.
    
    MCC> SHOW DOMAIN .DOMAINS.UK.FRGEN
    Using default ALL IDENTIFIERS
    
    Domain MCC_NS:.DOMAINS.UK.FRGEN
    AT 23-OCT-1991 08:28:08 Identifiers
    
    No such entity: Domain MCC_NS:.DOMAINS.UK.FRGEN
                             Unknown Entity = Domain MCC_NS:.DOMAINS.UK.FRGEN

    However,
    
    MCC> create domain .domains.uk.frgen
    
    Domain MCC_NS:.domains.uk.frgen
    AT 23-OCT-1991 08:47:59
    
    The requested operation cannot be completed
                      Entity Existence Info = Entity Exists

    and,
    
    MCC> delete domain .domains.uk.frgen
    
    Domain MCC_NS:.domains.uk.frgen
    AT 23-OCT-1991 08:48:48
    
    The requested operation cannot be completed
               MCC Unhandled Service Reply = The requested operation cannot be
                                             completed
                         MCC Routine Error = %MCC-E-INV_HANDLE, software error:
                                             invalid handle parameter

    
    Sooo...
    
    I tried to place things back they were by:
    
    DNS> rebuild dir .domains.uk master phvmcc_ch read phmcc_ch
    
    no luck,
    
    tried:
    
    DNS> rebuild dir .domains.uk master phvmcc_ch
    
    not luck:
    
    I have, though, since create a domain test
    
    MCC> CREATE DOMAIN  .DOMAINS.UK.TEST
    
    Domain MCC_NS:.DOMAINS.UK.TEST
    AT 23-OCT-1991 08:26:55
    
    Create Successful
    MCC> SHOW DOMAIN .DOMAINS.UK.TEST
    Using default ALL IDENTIFIERS
    
    Domain MCC_NS:.DOMAINS.UK.TEST
    AT 23-OCT-1991 08:27:09 Identifiers
    
    Examination of attributes shows
                                 DomainName = MCC_NS:.DOMAINS.UK.TEST
    
    No problems.  Of course, I now have no idea how to get rid of the
    domain object .domains.uk.frgen short of removing the object entries
    manually via DNS$CONTROL
    
    So, just more info/problems.
    
    
    Regards,
    
    Dave Comfort
    

    
    RE: .7
    
    When you creat a domain .DOMAINS.UK.FRGEN, MCC creates two DNS
    objects:
            .DOMAINS.UK.FRGEN and
            .DOMAINS.UK.FRGEN_MCC_EXT000
    
    If you delete the object .DOMAINS.UK.FRGEN using the DNS$CONTROL
    program, please make sure that .DOMAINS.UK.FRGEN_MCC_EXT000 is ALSO
    removed. Otherwise the domain .DOMAINS.UK.FRGEN cannot be
    re-registered.
    
    William
    
    PS: If the domain contained many members, you may have DNS objects 
        .DOMAINS.UK.FRGEN_MCC_EXT001, .DOMAINS.UK.FRGEN_MCC_EXT002, ... 
    
        The reason for having the domain extensions is that the DECdns object
        size (in DECdns V1.1) is limited, and thus we cannot store an infinite
        number of members to a DNS object.

    
    Indeed, what you describe is exactly what I did to remove the FRGEN
    object from the directories.  However, it seems that some of my
    problems stemmed from the fact that I created my directories manually
    from DNS$CONTROL and then created the object from MCC.  I found that
    the access to the directories and the objects were incorrect. I then
    manually attempted to add the appropriate access (ie. .dna_registrar
    and .*...) using a directory I created via the MCC_DNS_SETUP.COM and an
    object placed in there by MCC.  This did not work (though they looked
    identical and I think it should have), so I manually delete the objects
    and directories and re-created everything using the utilties and MCC.
    This seems to have straightened out the problem, even when using
    read-only replicas. However, this does NOT account for the problems
    encountered when accessing an object that is in the root, when a second
    clearinghouse providing a read-only replica is enabled.  I do not have
    problems with my .MCC or .DNA_NODE directories, but they do not have
    read-only replicas. I also have not used the "new" .domains.uk
    structure much (ie. maybe not enough times to cause a failure) because
    I have to shutdown the second clearinghouse to get any meaningful work
    done (my station is half development and half live monitoring the
    SmithKline wide area net).
    
    AT any rate, for what its worth...
    
    Dave Comfort
    

Any new bright ideas on note .0 ? 

We should like some respons on this matter due to that we have some important 
customer where we need this function to work !

/stefan

This problem seems to be solved by MCC kernel patch 03.
But you have to deregister and register all entitys.......puh

Regards Niklas

re: .11 

	Please clarify on the patch you mentioned in your reply.  We have 
several sites calling in with what appears to be the same problem running in 
this note but we here at the CSC/CS have no idea what patch you are referring 
to and what it fixes.

Thanks,

CSC/CS

    Let me clarify a bit.
    
    The patch previously mentioned doesn't"fix" the problem, it makes it
    go away (ie; replicas arn't used). We don't think this is a good
    solution.
    
    However, before you jump up and yell...
    
    Recently, a discovery was made of a problem in the COPY function of
    DNS and I understand that a patch is being readied.
    
    The problem with read only replicas and DECmcc only comes up if you
    have a master replica with DECmcc stuff in it and THEN you create the
    read only copies and COPY the directories. Is seems that the COPY
    function doesn't get the DECmcc attributes (same bug that doesn't let
    you view them with DNS$CONTROL).
    
    If you create all the replica sets BEFORE you start putting DECmcc
    stuff in to DNS, then it all works ok. The Propogate code does the
    right thing (only COPY doesn't).
    
    Stay tuned for more info (Noel? William?)
    
    s/rob

    RE: .12
    I have placed the KERNEL_3 PATCH and associated files in notes 1267.16
    through 1267.18.  I got this patch from Bill Beach in the CSC.  It does
    in fact seem to prevent the problem, although I did have to deregister
    and reregister certain entities.
    
    A trick for finding which entities must be de-/re-registered:
    
    MCC> DIR STATION *
    
    			MY_NS:.station.NODE1
    			08-00-2B-A7-88-A7	! If phys addr is present
    						! this node is OK.  If just
    						! name appears, this will
    						! be a candidate.
    
    I found the same with SNMP entities, but instead of missing physical
    address, they were missing IP address (eg, 128.1.1.1).
    
    Another symptom of this problem can be the presence of the Iconic Map
    PM error message "Notification structures may be corrupted.  Please
    disable notification."
    
    You may also see entities being "autoplaced" in duplicate and even
    showing up deleted from map files and domains upon bringing up the
    IMPM, even though you MCC_ICONS and MCC_MAPS logicals are defined
    properly.  I thought I was going nuts because I had carefully verified
    all of these (map files, logicals, and domain members) just before
    bringing up the map.     
    
    The problem of "autoplacement" is similar to that exhibited when an
    SNMP entity in the MAP file has a "." in front of the name (eg, .SNMP1
    instead of just SNMP1), but my problem had nothting to do with a bad
    map file.
    
    You may also experience missing attributes (I believe this is what is
    being described by Rob in .13) when issuing the DNS$CONTROL commands:
    
    DNS> SHOW CHAR GROUP .domain.MYDOMAIN ATTRIBUTE DNS$MEMBERS
    
    You should see a list of all members of the domain, but I only saw 11
    out of more than 30 for my domain of interest.
    
    I wish to express my appreciation to Jim Lemmon who helped me work the
    resolution to this tricky problem.  I also look forward to installing
    the patch mentioned by Rob in .13.