| 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 |
The following problem was caused in T1.3.1, but remains in V1.3.0. I have
been unable to reproduce the cause. The corruption of the LOCAL MIR detailed
below was caused when DECmcc stack dumped (due to resource problems) during
the registration and addition of an SNMP entity to a domain via the IMPM.
Symptoms:
-Only the IP address is registered in the Local MIR.
-The entity shows up as "deregistered"
-This "deregistered" entity is a member of a domain.
-The entity cannot be deleted, nor can it be removed as a member of
the domain.
Commands:
MCC> dir snmp .ip.badsys
MCC> dir snmp 1.2.3.4 ! Both commands yeild the following:
SNMP 1.2.3.4
AT 13-May-1993 00:00:00
Directory successful.
Address = 1.2.3.4
MCC> show domain .domain1 member *
.
.
.
Detected a deregistered Domain Member. LOCAL_NS:.ip.badsys
.
.
.
MCC> deregister snmp 1.2.3.4
MCC> deregister snmp .ip.badsys
MCC> deregister snmp badsys ! All 3 commands result in:
...
Not registered entity = SNMP 1.2.3.4 (or .ip.badsys or badsys)
MCC> register snmp .ip.badsys synonym badsys ! Results in:
...
Duplicate registration identifier, id already is used by another entity.
Address = 1.2.3.4
No such entity: ...
This is on a VMS V5.5-2 system.
It is my feeling that this will happen to a customer at a very crucial time
and that, with no means of fixing the problem short of rebuilding the Local
MIR, several customer satisfaction issues will result.
-Dan
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 5063.1 | See also 5021 | CUJO::HILL | Dan Hill-Net.Mgt.-Customer Resident | Fri May 14 1993 02:23 | 7 |
5021.0 describes a similar problem, but uses DNS as the MIR. This was
easily fixed by deleting the entities via DNS$CONTROL.
It should also be noted that the problem in 5021 was on a VMS V5.5-2
system running V1.3.0 DECmcc.
-Dan
| |||||
| 5063.2 | What Command to DNS$CONTROL will remove ENTITY? | MSDOA::REED | John Reed @CBO, DTN:367-6463, KB4FFE, SouthEast | Wed Mar 16 1994 14:52 | 45 |
I also am having a hard time DEREGISTERing a member from a Domain. I
assume from .1, that DNS$CONTROL is able to work with the MIR,
(Local_NS:) as well as a real DNS Namespace. I have never used
DNS$CONTROL for the LOCAL_NS:. Would someone please assist me in
deleting and Deregistering a BRIDGE from a domain ?
VAX/VMS V060 with CSCPAT for Motif.
PolyCenter400 (EMS023)
with kit and all AM's loaded from the FEB 1994 CDROM
Using the local MIR as the name space.
I tried the LAN Autotopology option, I started the SPT listener, and
waited two hours, and then ran the AUTOMAP, and Autoregister with a
Domain RESET. It built a nice spanning tree map, but could not talk
with the DECbridge90s in the DEChubs. I figured they weren't
supported, based on previous entries in this conference. But their
icons show up on the map (but no connecting lines were drawn,
indicating to me, that the autotop couldn't extract Designated-Bridge-
ID, or cost-to-root information), and I wanted to DEREGISTER THEM, so the
customer wouldn't try to click on them, and get some sort of failure.
When I hit the "deregister button" (circle with two lines) the icons
for these bridges were erased from the map. I built a rule for this
domain, (CHANGE_OF(bridge * designated bridge id,*,*) and enabled it,
but it fails with an MCC 0 ALARM error, saying that it can't contact
one of my bridges. I went to the FCL, and viola, one of the DECbridge
90's still show up when I do a MCC> SHOW BRIDGE * , IN DOMAIN .SPT_AUTO
I try to DEREGISTER it, and it say's it doesn't exist. I try to
REGISTER IT, as a different address, and it can't communicate with
target. I upgraded the DECbridge 90's, to ensure that they could
handle RBMS code (now they have firmware v3.1), and I can successfully
REGISTER THEM, (with different names), and DEREGISTER (the new names).
But I still have one OLD Bridge (named quizzically .domain.br_0800xxxx)
which the autotop wanted to call a domain, that I cannot get rid of.
Please help me with the appropriate commands to remove this entry from
my namespace, so that the BRIDGE * rule, will not somehow find this
phantom member of my domain, and keep making INDETERMINATE alarms on my
screen.
Thanks,
JR
| |||||
| 5063.3 | Send it to the doctor | BIKINI::KRAUSE | European NewProductEngineer for MCC | Thu Mar 17 1994 04:36 | 15 |
DNS$CONTROL works ONLY on DNS. There is * N O * tool to access the Local MIR. The official option is to start over with an new Local MIR (extract MCC_DNS_ATT.DAT and MCC_DNS_ENT.DAT from the distribution kit) and re-register everything. You could use MCC_DUMP_NS.COM to retrieve the data from the old MIR before replacing it. I managed to rescue a few Loacl MIRs by hand-patching them. If you send me the two MIR files I'll give it a try (copy to NACWS2::). The problem usually comes from a duplication of names, e.g. one object called ".xyz" and another called ".xyz.abc". MCC then gets confused (is "xyz" an object or a directory?). DNS does not allow you to create an object and a directory with the same name, but Local MIR doesn't check. *Robert | |||||