Conference azur::mcc

One simple question (please, someone answer it):  To exercise the full 
function of MCC (including specifically creating domains) does my system
need to be a DNS server?

    You don't need to be a server, but you need access to one. I will
    find some one who has more knowledge in this area to help you along.
    

In case someone else runs across this issue, here's what we did. Thanks
to those of you I contacted by phone and mail for help along the way.

o Although servers and clients can support more than one namespace, they
can have only one DEFAULT namespace. MCC expects to find it's objects and
the .MCC directory in the default namespace.

o We could have added another namespace to the nameserver on our development
cluster, but the cluster managers were reluctant to do so. That's cool,
their rice bowl comes from up-time, not support for every wrinkle I come up
with.

o We wanted to keep using RSM and DFS-mounted disks on our test cluster,
even after DEC: was no longer the default namespace.

1. Got a name server kit and installed it on our test cluster. (If you don't 
have one, send mail to GLUTNY::SYSTEM and pledge that you won't let MCC 
out into the DEC:namespace.)

2. During the DNS install, when it asks whether we want to use the
default namespace, we told it no and entered the namespace we wanted. Brevity
is goodness.

3. Executed SYS$MANAGER:DNS$CHANGE_DEF_FILE.COM to change the namespace
from what it was to the new one. This system had been running dns client,
if it handn't we wouldn't have needed this step.

4. Now, to get our RSM and DFS stuff back we took the definition of the DEC:
namespace out of SYS$MANAGER:DNS$CHANGE_DEF_FILE.OLD and appended it at the
end of SYS$MANAGER:DNS$CHANGE_DEF_FILE.COM. The first entry in this file
determines the default namespace. So the default is our private namespace,
but we can get to DEC: as long as we explicitly specify it.

5. We edited our DFS and RSM startup files to prepend DEC: to the DNS names,
so they get looked up in our private namespace.

6. We run MCC, it looks in the default, private namespace, and we be smilin'

Ok.  This is about where I'm at...  And I'm confused.

Rich, in .-1, is using a private namespace.  In fact, I think I got the 
impression that those in control of the corporate namespace are trying to keep 
MCC out of the corporate namespace.  (Did I misunderstand??)  I in fact looked, 
and can't see MCC in the DEC: namespace. (Though, MCC_UID is there.)

Do I need a private namespace to run MCC on the EASYNET???

If not, is it supposed to be in our (DEC) corporate namespace???

There's a procedure provided with the latest EFT kit, to create the MCC 
directories in the default (DEC:) namespace.  Do >>I<< need to run this??? Or 
can't I assume that someone else has done this for me??

Likewise, there's a procedure provided to populate the namespace with phase
IV names...  Do >>I<< need to run this??

My impression is that the two procedures mentioned (MCC_DNS_SETUP.COM and
MCC_NODE4_LOAD.COM) are only for use by private namespaces, or, of course for
external field test sites.  But regardless they need be executed only once
per "enterprise".  I.E. once per namespace.

Thanks.

-	stp

Hi Steve, long time no see.

We were told in no uncertain terms that were we not to run the dns setup
against the corporate namespace. No danger of that, we didn't have the
privs anyway.

You have to set up a private namespace. This is a surprisingly hard thing
to do out in the wilds, for as much political reasons as technical.

How about a MCC$DNS_ROOT logical name, that I could set to .CXN.S.DBS-AIM.MCC
and do my development in my own sub-directory of the DEC: namespace? For
FT stuff anyway?

.4> Rich, in .-1, is using a private namespace.  In fact, I think I got the 
.4> impression that those in control of the corporate namespace are trying to keep 
.4> MCC out of the corporate namespace.  (Did I misunderstand??)  I in fact looked, 
.4> and can't see MCC in the DEC: namespace. (Though, MCC_UID is there.)
    This scares me. I've heard it before.
    
    If those wishing to use MCC are denied access to the corporate name
    space, *and* we are about to ship this product to paying customer, what
    message are we giving out? 
    Do we really not "trust" our own product, and use thereof?
    Why can't folks get their "own" directories in the DNS namespace?
    
    I can certainly understand that some development work, such as within
    our own group, ought to use private name spaces, and private name
    servers, but for the general Digital populace the corporate name space
    should be used!
    
    <flame on>
    is this going to be another of those anonymous "them" who make up silly
    rules such as "you can't have a node name that's less than 4
    characters, cos it gives us a headache".
    <flame off>
    
    Suggestion - push your own local "name server" people (ie. them that
    "own" the corporate name space), and force them to let you use it.
    After all, DFS and NOTES managed, so why shouldn't MCC?
    
    Colin

Several points have been brought up:

.6>     Why can't folks get their "own" directories in the DNS namespace?

I haven't encountered a problem with this. Our local network people have
assigned me a sub-directory of the corporate namespace to do development
in. The problem is that I can't get MCC to use it.

.6>  Suggestion - push your own local "name server" people (ie. them that
.6> "own" the corporate name space), and force them to let you use it.
 
Steve made a good point in .4: there is no DEC:.MCC directory. Therefore,
DECmcc has never run enet-wide or the rest of us could see it. Those of us
doing AM development don't need or want to set up the whole structure, that
should be in place already. All we need to do is have someone with the
right privs add MCC_<class name>_BACKTRANSLATION to run our AM on the enet.
That should happen  as part of product certification prior to SSB submission.

In the meantime, I want to retract my suggestion in .5:

.5> How about a MCC$DNS_ROOT logical name, that I could set to 
.5> .CXN.S.DBS-AIM.MCC
.5> and do my development in my own sub-directory of the DEC: namespace? For
.5> FT stuff anyway?

I've got to stop thinking logical names, which are a trick to manage in a
distributed environment, when after all we are talking about a enterprise
management platform.

Perhaps one of the self-management characteristics of MCC should be DNS root?
MANAGE/ENTERPRISE SET MCC 0 DNS ROOT = .CXN.S.DBS-AIM.MCC

And the capability has to be in product kits, not just in FT as I suggested.
One of the big requirements we get out of production systems shops is the
need to run production and development versions of software simultaneously.
Folks doing AM development will always (reasonably) want to run out some
DNS sub-directory.

    Well you set command is right on the button, except that it is
    going to be a USE command instead. The FCL has this item currently
    on it's list for 1.1 functionality. Hopefully it will be what
    you are looking for. What our intentions were (and since you are
    the first to ask for, your the first I am asking feedback from)
    in the FCL was to give you a directive along the lines of:
    
    	MCC>  USE DEFAULT NAMESPACE DEC:.MCC
    
    And then for any subsequent command where you specify a full name,
    we will prepend the namespace information, so:
    
    	MCC>  SHOW NODE4 .GOSTE ALL IDENT
    
    		-- would mean --
    
    	MCC> SHOW NODE4 DEC:.MCC.GOSTE ALL IDENT
    
    (Note that the . is needed before goste because it is the only way
    to distinguish a simple/fullname from a phase4 name.)
    
    Is this something like what you were thinking? It would be process
    specific and not bound to any logical or current DNS defaults.
    
    jil
    

Jil,

That sure looks like a step in the right direction, but I think the setting
has the wrong scope. Since we'd be setting it in the FCL, it would apply
only to names that go though the FCL_PM. That would miss:

  o everything done through the iconic_pm

  o references to .MCC, .MCC_<class_name>_BACKTRANSLATION, etc. that are
    generated within MCC and its FMs

So it wouldn't solve the general problem of running somewhere other than the
root of the default namespace.

But as an extension of the USE DEFAULT capabilities, and thus a way to
set session context, it should save some typing.

    
    Sort of...I did look into the area you are concerned with, Iconic
    Map use of the default; and the problem there is of a different
    scope. Since the map always needs to keep the name around it sould
    only be a problem when adding something to the map, in which case
    you would have to type the entire thing in. I have spoken to the
    PL of that team to see what we can figure out, but their problems
    extend past the point of just entering the info. 
    
    They also need to figure out how to display it. The cases we were
    centering our discussions around (some of the "worst case scenarios")
    were when you wanted to deposit multiple entities onto map with each
    pointing to a different name space, what do you display as the "name"
    of the entity on the map, and if you let them specify defaults
    when/where do they apply? I will post more info here when we have
    figured things out some more.
     

Re: .8.  The DNS Architecture specifically states that using the leading dot
in  a name prevents all local defaulting and synonym processing.  I think it
would  be  a  mistake  to  stick the FCL default on the front of a name that
starts with a dot.

Graham

    
    I understand, and agree with you. The problem though still revolves
    around distinguishing a phase4name from a simple name. 
    
    If we don't allow you to put the dot on the phase4 entity then the
    defaulting will never help; would it then be a valid solution?