[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:	DECmcc user notes file. Does not replace IPMT.
Notice:	Use IPMT for problems. Newsletter location in note 6187
Moderator:	TAEC::BEROUD

Created:	Mon Aug 21 1989
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	6497
Total number of notes:	27359

1292.0. "Phase IV address change" by TROOA::GILBERT () Mon Jul 29 1991 11:56

    I have an MCC system which had all our Phase IV DECnet nodes added
    using the REGISTER*.COM command files.  Since then, the DECnet address
    of one of the nodes has changed.  DECmcc was not used to make the
    change.
    
    I now want to adjust the address so MCC can be used to access the node. 
    However, it can't find the node since it's not at its old address.  I
    tried to DEREGISTER the node and REGISTER it but the DEREGISTER command
    won't work unless the node is accessible.
    
    What command can I use to fix this situation? It sounds like a classic
    "Catch 22" to me.  In the future, should all address changes be made
    through MCC?
    
    Thanks,
    
    Peter

T.R Title User Personal
Name Date Lines

1292.1 Ugly yes, but there is a workaround TOOK::CAREY Mon Jul 29 1991 12:46 64

T.R	Title	User	Personal Name	Date	Lines
1292.1	Ugly yes, but there is a workaround	TOOK::CAREY		`Mon Jul 29 1991 12:46`	64
	Sorry. Yep, true story, you've encountered a classic catch 22. Due to an oversight in the phase 4 am, we only allow you to deregister node4s that exist. If it doesn't exist, we don't want to hear about it. If you think that that doesn't make sense, then we're in complete agreement. It has already been fixed for V1.2. The following will work if the name has not been changed, but the address has. I can also show you how to do it if the name has been changed and the address hasn't. If both have been changed, then the problem gets uglier. First, remember to change the address of the remote node on your MCC management system so that you can successfully access it... that is: MCC> DELETE NODE4 0 REMOTE NODE node MCC> DELETE NODE4 0 REMOTE NODE node DATABASE = PERMANENT MCC> CREATE NODE4 0 REMOTE NODE node ADDRESS = address MCC> CREATE NODE4 0 REMOTE NODE node ADDRESS = address, DATA = PERM Once you've done that you can register the node4. There are a couple of approaches to resolving the problem using FCL. If you use the IMPM, it is going to keep bumping into the DNS inconsistency that has been created. Most likely, the easiest way to take care of the problem is the following: - Make sure the DECnet database has been updated with the new address (as above) - Using FCL, DEREGISTER the node using its DECnet name (that is, Took, or Rampal, not .LKG.ENG.TOOK). A command like: MCC> DEREGISTER NODE4 nodename - That should clean things up so you can just register it normally now. Another way, is by modifying the node4 itself for a few moments: - change your node4 back to its old name and address for a moment. (on the node4 itself) - Deregister it. - change the node4 address back to its current address - Register it. If that's not feasible, we can show you how to pull the node4 DNS entries so that MCC no longer has it registered, but as long as you've only changed one of the identifiers, this problem is pretty easy to work around. -Jim Carey P.S. Sorry for the inconvenience.

    
    Sorry.
    
    Yep, true story, you've encountered a classic catch 22.
    
    Due to an oversight in the phase 4 am, we only allow you to deregister
    node4s that exist.  If it doesn't exist, we don't want to hear about
    it.
    
    If you think that that doesn't make sense, then we're in complete
    agreement.  It has already been fixed for V1.2.
    
    The following will work if the name has not been changed, but the
    address has.  I can also show you how to do it if the name has been
    changed and the address hasn't.  If both have been changed, then the
    problem gets uglier.
    
    First, remember to change the address of the remote node on your
    MCC management system so that you can successfully access it... that
    is:
    
    	MCC> DELETE NODE4 0 REMOTE NODE node
    	MCC> DELETE NODE4 0 REMOTE NODE node DATABASE = PERMANENT
    
    	MCC> CREATE NODE4 0 REMOTE NODE node ADDRESS = address
    	MCC> CREATE NODE4 0 REMOTE NODE node ADDRESS = address, DATA = PERM
    
    Once you've done that you can register the node4.
    
    There are a couple of approaches to resolving the problem using FCL.
    If you use the IMPM, it is going to keep bumping into the DNS
    inconsistency  that has been created.
    
    Most likely, the easiest way to take care of the problem is 
    the following:
    
    - Make sure the DECnet database has been updated with the new
      address (as above)
    - Using FCL, DEREGISTER the node using its DECnet name (that is, Took,
      or Rampal, not .LKG.ENG.TOOK).  A command like:
    
    	MCC> DEREGISTER NODE4 nodename
    
    - That should clean things up so you can just register it normally
    now.
    
    Another way, is by modifying the node4 itself for a few moments:
    
    - change your node4 back to its old name and address for a moment.
      (on the node4 itself)
    - Deregister it.
    - change the node4 address back to its current address
    - Register it.
    
    If that's not feasible, we can show you how to pull the node4 DNS
    entries so that MCC no longer has it registered, but as long as you've
    only changed one of the identifiers, this problem is pretty easy to
    work around.
    
    -Jim Carey
    
    P.S.  Sorry for the inconvenience.