Conference azur::mcc

The error you seem to be getting would suggest that the problem is not 
with DNS.  Invalid in_entity is not returned by the dns routines, as far 
as I know.  But I will make sure.

The fact that DEREGISTER with a wildcarded instance works is news to me. 
It should not, in fact my code explicitly checks for wildcarded 
instances and kicks them out.  Hmmmmm...

...kjn

Well,  the wildcarded DEREGISTER works `cause the TRM intercepts the GE 
wildcard and enumerates all the entiites of the class, issueing the 
directive for each one.

I can't see how your problem is with DNS.  If your namespace is really 
empty, then there should be no problem with adding stuff to it. You 
probably want to make sure that you are pointed to the namespace you 
think you are.  Type out SYS$SYSTEM:DNS$DEFAULT_FILE.DAT.

One thing ->  what is your namespace name?  I will get in with 
DNS$Control and take a look around.

I really don't know what to say.  You probably need to narrow down the 
problem a lot more.  In the mean time, however, I suggest you try other 
avenues.

...kjn

    The testbed I am using is on a private network (not directry accessible 
    from the easynet). I have only one namespace that I created myself. I just
    learned that there is an internal DECdns kit which implements secondary
    replicas. I am not using that version of the server software, I am using
    the SDC kit, I don't know if that makes any difference.
    
    I can execute a series of DNS$Control commands and send the output to
    you or I can provide you access to the testbed. You would have to login
    to my workstation then use LATmaster in a reverse lat situation to
    login to testbed nodes.
    
    Thanks for your help
    Linda

    I am making some progress registering entities. I sort of got back
    to where I was, able to register entities by entering a bunch or erase 
    commands which shouln't have much effect.
    
    I tried deregestering entities without privs and it didn't reproduce
    my first problem. Privileges and proxies might be part of my problem.
    I have privileges but not proxies. It just dawned on me that since
    a register touches the entity, that I need proxies to register node4
    entities. And I even read the documentation :-)
    
    The error message changed from "NML object not found" to "Requested
    entity does not exist". The entity does exist, I can follow the
    register command whith a show node4 <nodeid> all ident and it works
    fine. Any idea what causes that error?
    
    Linda
    

I have spent many hours registering many entities and looking at the
results. I have had very inconsistent results. Every time I think I
am on to something, the error message changes. 

From what I can tell, you need privileges (proxy access) to register
phase iv nodes. When no proxies are used, I get any one of the following
error messages. It is not reproducible, the error message changes often.

1) Node terminated link before confirmation

2) NML Object not found

3) Access control information not valid at remote node

4) Requested entry does not exist

When I get the first error, the entity is not in the configuration. When
all other errors occur, the node name is available (dir node4) but the node 
address is not.

When I get the last error, and then deregister the node4 entity, sometimes 
I get the following error message: "No such DNS attribute" and the DNS object 
remains in the namespace.

When I set up proxies, it seems to work OK.
I am having a difficult time obtaining consistent results. Is anybody
else having these kinds of problems?
    

RE: .5

  >> I have spent many hours registering many entities and looking at the
  >> results. I have had very inconsistent results. Every time I think I
  >> am on to something, the error message changes. 

  >> From what I can tell, you need privileges (proxy access) to register
  >> phase iv nodes. When no proxies are used, I get any one of the following
  >> error messages. It is not reproducible, the error message changes often.

  >> 1) Node terminated link before confirmation

  >> 2) NML Object not found

  >> 3) Access control information not valid at remote node

  >> 4) Requested entry does not exist

  >> When I get the first error, the entity is not in the configuration. When
  >> all other errors occur, the node name is available (dir node4) but the node 
  >> address is not.

As far as DNS goes, this is what I think is happening (you will have to 
hear from Jim Carey to tell what is going on with the Phase IV node):

	1)  You begin the REGISTER process and encounter an error 
	    condition

	2)  You do not DEREGISTER or ERASE following the failed REGISTER

As documented in the Release Notes, in the EFT release, a failed 
REGISTER does not rollback and the entry remains in DNS.  That is why 
you see the name, but no address.

I do know that you must have access to the NML agent at the node you are
trying to manage.  The agents may be protected in such a way that the 
nodes you are trying to manage are not accepting your connect.

Do you get all of these various errors as a result of a REGISTER?  If 
not, what directives are you issueing.  That information will allow us 
to let you know exactly what the problem is.  

The code paths are very different depending on whether you are trying
REGISTER, SET, SHOW, etc.   REGISTER, DEREGISTER, SHOW REFERENCE, and
SET REFERENCE access DNS, but SHOW and SET of any other attribute
partition go straight to the AM and from there to the network - DNS is
not involved at all.  REGISTER calls the AM to retrieve the IDENTIFIER
partition, and so requires the AM to have access to the entity. 

  >> When I get the last error, and then deregister the node4 entity, sometimes 
  >> I get the following error message: "No such DNS attribute" and the DNS object 
  >> remains in the namespace.

Hmmm... I have not been able to repoduce this problem.

  >> When I set up proxies, it seems to work OK.
  >> I am having a difficult time obtaining consistent results. Is anybody
  >> else having these kinds of problems?
    
I would suspect that having set up proxies, your REGISTER succeeds and 
then all other directives operate as expected.  I would strongly suspect 
that the failed REGISTER (for whatever reason) is your problem.

...kjn

    
    Linda,
    
    I have no idea what's going on.  When you REGISTER a NODE4 entity
    nothing at all special happens.  The CONFIG FM calls down to the Phase
    IV AM with a series of requests for Global and Child Entity
    identifiers.  Nothing more flashy than:
    
    	SHOW NODE4 <node> ALL IDENT
    	SHOW NODE4 <node> LINE * ALL IDENT
    	SHOW NODE4 <node> CIRCUIT * ALL IDENT
    
    and pretty soon it'll ask for OBJECT * all ident.  None of those are
    protected in any way.  All you need is the NML object and a default 
    NML (or DECnet) account.  The account doesn't need any special
    privileges or anything, so I'm kind of at a loss.  If you can form a 
    connection, you can get that information.  And I know that you've
    formed at least a couple of DECnet links in the last six months!
    
    Of your list of errors, the first two: 
    
    	Node terminated link before confirmation, and
    	NML object not found  
    
    mean that the node4 you are trying to register isn't set up to allow
    itself to be managed.  The NML Object has to be there, and a default
    account that can be logged into must be out there as well.
    
    	Access Control information not valid at Remote Node
    
    Should only occur if SOME access control information was specified, but
    either incorrectly, or not enough.  For example, if you have proxy to
    an account HUGHES on the node you're trying to REGISTER, then
    specifying BY USER = "HUGHES" is more than enough to get you in.  If 
    HUGHES is your default account, then you don't even need that.  But if
    you don't have proxy, then you will need to specify both BY USER, and
    PASSWORD to gain access.
    
    I haven't seen a case where this error is returned, and no access
    control information was provided.  Should that happen, it could mean
    that the Phase IV AM is setting up the NML message as though access
    information is there, when it isn't.  That might happen if we were
    passed an invalid IN_Q although we took pains to protect against that.
    
    I have no idea where your last error could be from.
    
    Are the nodes you are trying to REGISTER VMS nodes, or do you get a
    variety of errors depending on the system you're registering?
    
    Anything else you could give us would be most helpful.  
    
    Hmmm.  For instance, on these nodes that you can't REGISTER, are you
    able to SHOW the node4 and its child entities before and after you
    can't register it?  If so, we have to look elsewhere for the problem.
    
    -Jim
    
    		

    Some of the nodes I am registering are VMS 5.3 systems that do not
    have a default decnet account. When you run netconfig for 5.3 systems
    you have the option of creating specific accounts for objects and
    not using a default decnet account. The systems are set up different
    ways from specifying accounts for every object to using the default
    decnet account for everything. We tried to set them up consistently
    but with so many hands in this testbed it's close to impossible.
    
    The bottom line is that some of these systems require access control
    to a privileged account to execute an ncp show node x status command.
    Therefore, I expect MCC to get an error but I kind of guessed that
    I should consistently get the same error but I don't. The 4 errors
    that I documented in an earlier note are generated from a register
    node4 command when I did not have access by default.
    
    I have set-up proxies to privileged accounts and I am making a bit more
    progress testing.
    
    Thanks for all your good (and timely) responses.
    Linda

    It looks like a generic problem with distributed applications.
    Unless one has a possibility to trace the network access at the
    application level, it is very difficult to know what is broken.

    DNS can make accesses to several different systems, and you will not
    know which one has proxies or something else broken.

    Applications like MCC should have a mean to trace interfaces between the
    PM,FM,AMs, this would have been a first step in debugging.
    This should not be difficult to do, since all modules use a consistent
    set of MCC calls.

    Trouble shooting is very inefficient of we have to look to the lines 
    with a datascope just to know what was the real access and what was
    the returned error.

     So, I see here two sets of generic troubleshooting problems, lack of
    MCC interface tracing ( sure you have something in Engineering...)
    and lack of DNS access tracing.
    						wlodek

    re: .9
    
    I think you made a very good point about how difficult it could be
    to troubleshoot this problem. MCC returned 3 or 4 different error
    messages for the same problem. When I used NCP to see what message
    was returned it was always the same error message, network partner
    exited. Since NCP has been around for so long and there is pretty
    good information available as to what is happening when this error
    is returned it was a lot easier to determine the problem using NCP.
    
    Linda