| 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 |
Hi,
I have been running MCC V1.1 with DNS server V1.1 on my station for
a number of months now and have started having problems with wildcard
domain listing/operations. The error returned is:
MCC Routine Error = %MCC-E-NOATTRIB, no such DNS attribute
This error appears at random times when performing such operations
as:
show domain lavc3 member *
show node4 * max links, in domain lavc1
set node4 * broadcast routing timer 300, in domain routers_1,...
.
.
etc
The listing naturally stops at that point. The objects that produce
the error have been node4 entities, bridges, and domains (ie. demprs,
delnis, etc). There seems to be no rhyme or reason for the occurences,
however the are starting to happen frequently. If the same command is
executed a moment after a failure, it may work, stop at a different
entity or stop at the same entity. I can audibly detect the disk head
movement when the DNS lookups are being done and there seems to be an
awful lot of activity. At any rate, I'm looking for ideas or
suggestions.
Thanks,
Dave Comfort
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1528.1 | does it happen with a specific domain or any domain? | TOOK::JESURAJ | Fri Sep 27 1991 13:12 | 20 | |
Sorry it took so long to answer this...
I am not sure what exactly going on there in your system.
I assume that you have set up the DNS skulk process to
clean up the NAMESPACE once in a day. If it is not set up right
the name space may contain uncollected "garbages", and that may slow
down the activities. Check the skulk process set up.
Does this error occur only with a specfic domain or for any random
domain? If it happens only for a specific domain, most likely the domain
data in the disk have been corrupted. We can verify this using
DNS$control, and we may able to recover from this corruption.
... Jay
| |||||
| 1528.2 | Any resolution? | BABY::SYSTEM | Fri Oct 18 1991 15:52 | 5 | |
Has there been a resolution to this problem? We have a similar problem.... Thanks | |||||
| 1528.3 | Smack me upside the head | ANOSWS::COMFORT | Spent a little time on the hill | Wed Oct 30 1991 10:18 | 18 |
My sincere apologies, I had stopped monitoring this note.
Yes, I resolved the problem, but it was caused by a stupid mistake on
my part. While attempting to create a clearinghouse, I inadvertently
created it on the MCC node, which already had a clearinghouse. Both
were attempt to clear for the root directory and none of the
directories were replicated in the secondary clearinghouse, so which
ever clearinghouse served the look up request produced either a
successful retrieval or a failure.
The problems in note 1661.* appear similar, but this one was just
me.
Again, sorry I abandoned this note.
Dave Comfort
| |||||