Conference azur::mcc

If you use the local namespace option, then you get one namespace
per director, no sharing.  We still recommend using DECdns, especially for
sites with multiple directors, and for those sites running DECnet-OSI
(which requires DECdns anyway).

The local namespace option is included for ULTRIX systems running
DECnet phase IV (which does not support a DECdns clerk), and for
very simple networks which require only one director, and do not
wish to set up DECdns.

You might be able to play games with logicals ... and put your
DNS/MIR files on one system, and allow other systems to access
the files via DECnet.

Just a thought - I didn't try it.

/keith

    With Ultrix I'm sure you can use an NFS mount point to share the DNS
    Local MIR file(s).  On VMS it will NOT work because we (the MCC Kernel)
    open the file as Multi-stream with multiple RAB connects for multi-thread
    access, which does NOT work with DECnet.  We would either have to open
    the file as single stream/single connect and multiplex between threads
    (not easy when your dealing with multiple wildcard requests), or
    implement an RPC over the MIR routines (also not as simple as it
    may sound).  So please do not even try it on VMS (I've already received
    a couple of QARs from some adventurous users).
    
    -Matt.

Thanks Matt

I'm glad this came up now -- before someone went out and tried it, only
to find it didn't work

/keith

    NFS will work if you want to share those MIR files used by the non-DNS
    DNS implementation, but there are some aspects of it you might not like.
    One problem is that locking is optional with NFS - if you don't use it
    you will have no protection against writers running into readers and
    other writers in a destructive way.  Even if you use nfs locking, locks
    are acquired and released around individual record operations only -
    registration typically requires several logically-related records to be
    written together - so while the locking will insure that you don't
    physically corrupt an individual record, it still can't give you true
    serialization of the entire transaction and weird things can still
    happen.
    
    The above can be avoided though a site-imposed access discipline (i.e., 
    only one person registers and all other users wait), but this is of
    course subject to lots of unintentional screwups.
    
    Another approach might be to maintain n copies of the files, and copy
    them from site to site to keep them in sync.  This may be reasonable if
    you have only a few sites and a relatively static instance database,
    but you very quickly wind up having to do some or all of the things DNS
    was designed to do to begin with.
    
    These issues are important to understand.  We know that some people are
    put off by DNS since it carries its own management overhead and is
    unfamiliar to many people; however, it is specifically designed to
    provide a network-wide view of configuration data.  As such, MCC
    development has little motivation to try to get the non-DNS DNS to work
    in any configuration other than a single system.  (We are continously
    working on improvements to smooth out the MCC-to-DNS interfaces, so
    the user can make the choice based on what's right and not what's hard
    or easy to use).

    Thanks folks, you confirmed my suspicions!  We'll be using DNS but
    wanted to know how cumbersome it might end up being if we didn't
    and had even thought of logicals.  Thanks for saving us lots of
    aggravation!
    
    Conni