| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1661.1 | | KAOT01::S_HYNDMAN | | Tue Oct 15 1991 17:46 | 7 |
|
Does your dns$default_file.dat indicate your pointed to the proper
name space? Might want to rerun dns$change_def_file.com.
Just a thought,
Scott
|
| 1661.2 | DNS$DEFAULT_FILE.DAT is ok | ANTIK::WESTERBERG | Stefan Westerberg CS Stockholm | Tue Oct 15 1991 20:10 | 9 |
| > Does your dns$default_file.dat indicate your pointed to the proper
> name space? Might want to rerun dns$change_def_file.com.
Yes, both servers are in the DNS$DEFAULT_FILE.DAT.
When DECmcc recives information from a read-only replica it dosen't seem
to like what it gets !!
/Stefan
|
| 1661.3 | Is DNS time right? | TOOK::R_SPENCE | Nets don't fail me now... | Wed Oct 16 1991 15:18 | 7 |
| Just a wild shot; Is the DNS TDF set correcly on both servers?
I have seen skulking work ok, but propogation of changes not work due
to time difference between the two servers. The time on the two servers
MUST be close to the same for things to work right.
s/rob
|
| 1661.4 | Time is right | STKMCC::LUND | | Wed Oct 16 1991 16:21 | 5 |
| Both systems have DNS timezone set to 02:00 and MCC_TDF logical set to +2:00
Time is synchronized on both systems with DECdts, the skew between the system
clocks is less than 00:00:00.10 s
/Niklas
|
| 1661.5 | what's the word on .0 ?? | ANOSWS::COMFORT | Spent a little time on the hill | Tue Oct 22 1991 15:54 | 12 |
| Hi,
I'll throw my two cents in. I am experiencing the EXACT same problem
as Niklas in .0. I am out at SmithKline and we are looking to roll
out the MCC platform in December using four DNS servers. I am looking
for an update on the situation as I will have to advise my customer
regarding the use of the two servers they already have operating
and the two they intend to purchase for this project.
Thanks,
Dave Comfort
|
| 1661.6 | Same problem, more info.
| GOYA::MARTIN | Jos� Luis Mart�n - E.I.S. Spain | Wed Oct 23 1991 07:19 | 32 |
| Hello,
I think I'm experiencing the same problem in a customer.
The scenario is:
VAXstation 3100 VAX 9000-410
- DNS server - DNS server
- Clearinghouse A_CH - Clearinghouse B_CH
- Master directories - Read-only replicas (all dirs.)
- DECmcc BMS
- Only one namespace.
- Not "time differences".
What happens is:
1.- When only clearinghouse A_CH is "started", then DECmcc runs ok.
2.- Started (only) clearinghouse B_CH, DECmcc always fails. I means, not trying
to register anything, but only trying to get into domain (error: No such DNS
attribute) or selecting a NODE4 entity (error: Entity not registered),etc.
3.- Starting clearinghouse A_CH and later B_CH, running DECmcc Iconic Map, it
initially runs OK, but in a while it begans to fail (like previous point).
Then, stopping and starting clearinghouse B_CH, it runs Ok again.
Any ideas?
Could we look to any attributes of chars. in the DNS environment?
Regards,
Jos� Luis.
|
| 1661.7 | More problems w/ replicas | ANOSWS::COMFORT | Spent a little time on the hill | Wed Oct 23 1991 10:05 | 123 |
|
Another situation encountered:
Two clearinghouses PHMCC_CH and PHVMCC_CH, which weren't working
properly as indicated in previous entries in this note. Before
discovering the failures on read-only replicas, I had created a
DNS directory tree:
.domains
|
---------
| |
.us .uk
.us is mastered by PHMCC_CH, which is the master of the root dir and
all others. .uk is mastered by PHVMCC_CH, the only directory allowed
to be mastered. So things looked like this from DNS$CONTROL:
DNS> show char dir .domains.uk
Convergence _____________ HIGH
Last successful update __ 23-OCT-1991 08:49:59.40
Directory copies:
Address _________________ PHVMCC (1.59)
Replica Type ____________ Master
Clearinghouse ___________ MCC_NS:.PHVMCC_CH
Address _________________ PHMCC (1.34)
Replica Type ____________ Replica
Clearinghouse ___________ MCC_NS:.PHMCC_CH
Sooo, I wanted to shut down the PHVMCC name server and associated
clearinghouse so things would work correctly. Therefore, to maintain
write access to the .domains.uk directory, i performed a:
DNS> rebuild dir .domains.uk master phmcc_ch read phvmcc_ch
Things then looked the way they should and even worked, most of the
time, ie. when the DNS request was posted to the PHMCC_CH
clearinghouse. Then I made my fatal mistake and attempted a
DNS> remove dir .domains.uk clear phvmcc_ch
After this, MCC could not find the obj (a domain in the .uk dir).
ie.
MCC> SHOW DOMAIN .DOMAINS.UK.FRGEN
Using default ALL IDENTIFIERS
Domain MCC_NS:.DOMAINS.UK.FRGEN
AT 23-OCT-1991 08:28:08 Identifiers
No such entity: Domain MCC_NS:.DOMAINS.UK.FRGEN
Unknown Entity = Domain MCC_NS:.DOMAINS.UK.FRGEN
However,
MCC> create domain .domains.uk.frgen
Domain MCC_NS:.domains.uk.frgen
AT 23-OCT-1991 08:47:59
The requested operation cannot be completed
Entity Existence Info = Entity Exists
and,
MCC> delete domain .domains.uk.frgen
Domain MCC_NS:.domains.uk.frgen
AT 23-OCT-1991 08:48:48
The requested operation cannot be completed
MCC Unhandled Service Reply = The requested operation cannot be
completed
MCC Routine Error = %MCC-E-INV_HANDLE, software error:
invalid handle parameter
Sooo...
I tried to place things back they were by:
DNS> rebuild dir .domains.uk master phvmcc_ch read phmcc_ch
no luck,
tried:
DNS> rebuild dir .domains.uk master phvmcc_ch
not luck:
I have, though, since create a domain test
MCC> CREATE DOMAIN .DOMAINS.UK.TEST
Domain MCC_NS:.DOMAINS.UK.TEST
AT 23-OCT-1991 08:26:55
Create Successful
MCC> SHOW DOMAIN .DOMAINS.UK.TEST
Using default ALL IDENTIFIERS
Domain MCC_NS:.DOMAINS.UK.TEST
AT 23-OCT-1991 08:27:09 Identifiers
Examination of attributes shows
DomainName = MCC_NS:.DOMAINS.UK.TEST
No problems. Of course, I now have no idea how to get rid of the
domain object .domains.uk.frgen short of removing the object entries
manually via DNS$CONTROL
So, just more info/problems.
Regards,
Dave Comfort
|
| 1661.8 | Remove MCC Domain Extensions as well | TRM::KWAK | | Thu Oct 24 1991 17:00 | 21 |
|
RE: .7
When you creat a domain .DOMAINS.UK.FRGEN, MCC creates two DNS
objects:
.DOMAINS.UK.FRGEN and
.DOMAINS.UK.FRGEN_MCC_EXT000
If you delete the object .DOMAINS.UK.FRGEN using the DNS$CONTROL
program, please make sure that .DOMAINS.UK.FRGEN_MCC_EXT000 is ALSO
removed. Otherwise the domain .DOMAINS.UK.FRGEN cannot be
re-registered.
William
PS: If the domain contained many members, you may have DNS objects
.DOMAINS.UK.FRGEN_MCC_EXT001, .DOMAINS.UK.FRGEN_MCC_EXT002, ...
The reason for having the domain extensions is that the DECdns object
size (in DECdns V1.1) is limited, and thus we cannot store an infinite
number of members to a DNS object.
|
| 1661.9 | re .8 and more | ANOSWS::COMFORT | Spent a little time on the hill | Fri Oct 25 1991 11:09 | 26 |
|
Indeed, what you describe is exactly what I did to remove the FRGEN
object from the directories. However, it seems that some of my
problems stemmed from the fact that I created my directories manually
from DNS$CONTROL and then created the object from MCC. I found that
the access to the directories and the objects were incorrect. I then
manually attempted to add the appropriate access (ie. .dna_registrar
and .*...) using a directory I created via the MCC_DNS_SETUP.COM and an
object placed in there by MCC. This did not work (though they looked
identical and I think it should have), so I manually delete the objects
and directories and re-created everything using the utilties and MCC.
This seems to have straightened out the problem, even when using
read-only replicas. However, this does NOT account for the problems
encountered when accessing an object that is in the root, when a second
clearinghouse providing a read-only replica is enabled. I do not have
problems with my .MCC or .DNA_NODE directories, but they do not have
read-only replicas. I also have not used the "new" .domains.uk
structure much (ie. maybe not enough times to cause a failure) because
I have to shutdown the second clearinghouse to get any meaningful work
done (my station is half development and half live monitoring the
SmithKline wide area net).
AT any rate, for what its worth...
Dave Comfort
|
| 1661.10 | Any news on .0 | ANTIK::WESTERBERG | Stefan Westerberg CS Stockholm | Wed Nov 06 1991 16:57 | 6 |
| Any new bright ideas on note .0 ?
We should like some respons on this matter due to that we have some important
customer where we need this function to work !
/stefan
|
| 1661.11 | Problem fixed by patch. | STKMCC::LUND | Niklas Lund | Mon Nov 18 1991 15:24 | 4 |
| This problem seems to be solved by MCC kernel patch 03.
But you have to deregister and register all entitys.......puh
Regards Niklas
|
| 1661.12 | More info. please! | CSC32::D_COHN | SummaNulla(The High Point of Nothing) | Wed Nov 27 1991 18:08 | 10 |
| re: .11
Please clarify on the patch you mentioned in your reply. We have
several sites calling in with what appears to be the same problem running in
this note but we here at the CSC/CS have no idea what patch you are referring
to and what it fixes.
Thanks,
CSC/CS
|
| 1661.13 | More on Replicas | TOOK::R_SPENCE | Nets don't fail me now... | Fri Nov 29 1991 21:27 | 24 |
| Let me clarify a bit.
The patch previously mentioned doesn't"fix" the problem, it makes it
go away (ie; replicas arn't used). We don't think this is a good
solution.
However, before you jump up and yell...
Recently, a discovery was made of a problem in the COPY function of
DNS and I understand that a patch is being readied.
The problem with read only replicas and DECmcc only comes up if you
have a master replica with DECmcc stuff in it and THEN you create the
read only copies and COPY the directories. Is seems that the COPY
function doesn't get the DECmcc attributes (same bug that doesn't let
you view them with DNS$CONTROL).
If you create all the replica sets BEFORE you start putting DECmcc
stuff in to DNS, then it all works ok. The Propogate code does the
right thing (only COPY doesn't).
Stay tuned for more info (Noel? William?)
s/rob
|
| 1661.14 | KERNEL_PATCH_3; Notification structures may be disabled; Autoplaced icons | CUJO::HILL | Dan Hill-Net.Mgt.-Customer Resident | Fri Dec 06 1991 01:28 | 46 |
| RE: .12
I have placed the KERNEL_3 PATCH and associated files in notes 1267.16
through 1267.18. I got this patch from Bill Beach in the CSC. It does
in fact seem to prevent the problem, although I did have to deregister
and reregister certain entities.
A trick for finding which entities must be de-/re-registered:
MCC> DIR STATION *
MY_NS:.station.NODE1
08-00-2B-A7-88-A7 ! If phys addr is present
! this node is OK. If just
! name appears, this will
! be a candidate.
I found the same with SNMP entities, but instead of missing physical
address, they were missing IP address (eg, 128.1.1.1).
Another symptom of this problem can be the presence of the Iconic Map
PM error message "Notification structures may be corrupted. Please
disable notification."
You may also see entities being "autoplaced" in duplicate and even
showing up deleted from map files and domains upon bringing up the
IMPM, even though you MCC_ICONS and MCC_MAPS logicals are defined
properly. I thought I was going nuts because I had carefully verified
all of these (map files, logicals, and domain members) just before
bringing up the map.
The problem of "autoplacement" is similar to that exhibited when an
SNMP entity in the MAP file has a "." in front of the name (eg, .SNMP1
instead of just SNMP1), but my problem had nothting to do with a bad
map file.
You may also experience missing attributes (I believe this is what is
being described by Rob in .13) when issuing the DNS$CONTROL commands:
DNS> SHOW CHAR GROUP .domain.MYDOMAIN ATTRIBUTE DNS$MEMBERS
You should see a list of all members of the domain, but I only saw 11
out of more than 30 for my domain of interest.
I wish to express my appreciation to Jim Lemmon who helped me work the
resolution to this tricky problem. I also look forward to installing
the patch mentioned by Rob in .13.
|