|
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.
|