Conference azur::mcc

The register directive requires both a fullname and a synonym (which
should be the internet name).  What information have you entered on
the form?

-- Erik

	Y'see, that's where it gets confusing.  I don't get any further than
the "Add Entity - Enter Entity Information" window.  The only field I can
type into looks something like:

	SNMP |___________________________________________

		OK		Apply		Cancel

with a bunch of alternate icons on the bottom.  I expect that the next window,
after it notices that there's no DECdns object called (in this case)
"LAA:.Dugal.DGD300", would be where I could enter the synonym.

	One other possibly relevant bit of info.  I've got a mysterious DECdns
link in my LAA:.MCC_SNMP_BackTranslation directory:

	DNS> show dir MCC_SNMP_BackTranslation link *
	 Link _______ ""

Could this be hosing me over?  I've tried to delete it, but what kind of 
DNS$CONTROL syntax do you use to delete a null link???

	Thanks Erik!

- Dave

    >One other possibly relevant bit of info.  I've got a mysterious DECdns
    >link in my LAA:.MCC_SNMP_BackTranslation directory:
    
    >DNS> show dir MCC_SNMP_BackTranslation link *
    > Link _______ ""
    
    >Could this be hosing me over?  I've tried to delete it, but what kind
    >of DNS$CONTROL syntax do you use to delete a null link???
    
    I am only able to answer this part of your question.
    
    If you do the following command from FCL, you will get
    
    MCC> show snmp 16.20.48.54
    Using default ALL IDENTIFIERS
    
    SNMP 16.20.48.54
    AT  4-FEB-1992 17:23:07 Identifiers
    
    Examination of attributes shows:
                                    Address = 16.20.48.54
                                       Name =
    
    This tells you that the SNMP entity 16.20.48.54 is reachable but
    has no name associated with it. You can go into UCX and do the
    following to know that it is reachable
    
    UCX> loop 16.20.48.54
    %UCX-I-LOOPACT, 16.20.48.54 is alive
    
    Now if someone register this snmp using command such as
    
    MCC> REGISTER SNMP .FOO ADDRESS 16.20.48.54
    
    it will be successful and doing a DIRECTORY will show
    
    MCC> dir snmp .FOO
    
    SNMP MCC1_NS:.FOO
    AT  4-FEB-1992 17:30:11
    
    Directory successful.
                            Registered Name = MCC1_NS:.FOO
                                    Address = 16.20.48.54
                                       Name =
    
    Also the null link "" that you saw in DNS is created. However, you
    cannot refer to MCC1_NS:.FOO using this null Internet Name. You can
    do a SHOW DIR .mcc_snmp_backtranslation known link to see it
    
    DNS> show dir .mcc_snmp_backtranslation known link
     Link _______ ""
    
       ....
    
    
    but you cannot do the following to see it
    
    DNS> show link .mcc_snmp_backtranslation.""
     %DNS-E-UNKNOWNENTRY, Requested entry does not exist
    
    
    The only way I know to get rid of it is to DEREGISTER the SNMP that is
    associated with it.
    
    DO a DIRECTORY SNMP *, and deregister using the fullname found (there
    can only be one)
    
    MCC> DIR SNMP *
    
       ....
    
    SNMP MCC1_NS:.FOO
    AT  4-FEB-1992 17:30:11
    
    Directory successful.
                            Registered Name = MCC1_NS:.FOO
                                    Address = 16.20.48.54
                                       Name =
    
    MCC> DEREGISTER SNMP MCC1_NS:.FOO
    
    
    	This problem was in the FT kit. It is fixed and will be in next FT
    release.
    
    /Ed
    

	Thanks for the response, Ed.  I tried the command you suggested and got
the following results:

MCC> dir snmp *

SNMP *
AT  4-FEB-1992 21:14:29

The requested operation cannot be completed
                      MCC Routine Error = %DNS-E-UNKNOWNENTRY, Requested entry
                                          does not exist

which seems to imply that a DECdns object inadvertently got deleted by an 
external force (ie. DNS$CONTROL).  I then tried to register an SNMP station 
using only the Internet address and got another novel response from MCC:

MCC> register snmp dugal.a address 16.20.48.150
%MCC-E-ATTRNOTALLOW, no attribute or argument allowed

Clearly the REGISTER directive does take arguments, doesn't it?  Are my problems
even worse that it would initially appear?

	Help!  My management station has fallen and can't get up!!!

- Dave

    Talked to Dave off-line. He has been able to register snmp entities
    successfully by rebuilding his parse table. Somehow his dictionary and
    the parse table is out-of-syn.