Conference azur::mcc

    
    I've seen similar problems before, the crux of the matter being DNS,
    but that problem was supposed to be resolved with VMS 5.5-2 and the new
    DNS Clerk V2.0.  Anyway, check to see if the the synonym link is there. 
    
    Dave

    No, there's no DNA$NodeSynonym attribute there.
    As a matter of fact, thera are no DNA$-attributes at
    all.
    
      /Nils

    just want to mention i:
    
    Whan I installed the ECO, it told me to reboot the system, which I did,
    and since then I've had two errormessages printed out during boot
    saying that "protected image has to be installed" and refering to
    DNS$SHARE.EXE.  These messages are printed before SYSTARTUP_V5.COM
    being executed.  I do install the image in the SYSTARTUP_V5 before 
    DECnet is started.
    
      /N

    Boy do I hate that error message (Internal error in DECnet Phase IV AM)
    It doesn't give me much to go on.  If there's no dna$* attributes
    when you do a show object in dns$control then something is really
    wrong with dns on your system.  Be aware that versions of DNS and
    DECnet V are *very* tied together.  For instance, the new CML.EXE
    won't work correctly if you try using it with the last FT baselevel
    of DECnet V and DNS from what I'm told. I'd try deleting the object
    using DNS$CONTROL, and try registering again.  And double check that
    you don't have a mish-mash of executables (SSB and FT).
    If you still have problems we may be able to turn on some trace bit
    settings in the AM to get more info.  Are all these nodes on the Enet
    so I can try to reproduce the problem?  I'm out tomorrow btw, so this
    may have to wait until Monday.
    
    John
    

    
    Hi,
    
    In .1 I was referring to the DNS soft link pointer in the
    .DNA_NODESYNONYM directory as opposed to attributes on the object. 
    What I have seen in the past is that if during a registration, the
    DNS server system that is requested to do the registration is a replica
    and not the master, then not all portions of the registration get
    written.  For the most part, it seems to not put in the circuit and
    line attributes on the object and seems to not place the synonym link
    in the aforementioned directory.  Then when referencing the phase IV
    node by its "regular" DECnet name (ie. its synonym), DNS cannot find
    and resolve the back link to the object.  To determine if the back link
    is there, get into DNS$CONTROL and...
    
    	show dir .dna_nodesynonym k links (and look for the node name in
    					   question)
    
    		or
    
    	show link .dna_nodesynonym.phred (where phred is the phase IV
    				          node name in question)
    
    
    if the link is not there, you can get a DECnet Phase IV AM internal
    error when trying to manipulate the object, depending on the particular
    operation being performed.  To fix this problem, use the
    DECNET_DNS_REGISTER.COM procedure to overwrite the existing record with
    a synonym, and at least you will be able to manipulate the object
    correctly.  As an afterthought, you have the choice of dereg and
    rereging the node OR register the line and circuits (if they are
    missing) as the children that they are.
    
    I hope this helps.
    
    Dave

I've recreated the whole DNS-structure and now it works
like expected.

Don't know what was wrong before (and I shouldn't 
care to much...)


Thanks for your help!

   /Nils