[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
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 |
1236.0. "Register NODE4 failing to connect to DNS" by MAYDAY::ANDRADE (The sentinel (.)(.)) Thu Jul 11 1991 13:12
Some more problems with registering phase IV nodes. I keep getting
the folowing error:
"MCC Routine Error = %DNS-E-NOCOMMUNICATION, Unable to
communicate with DNS server"
I have checked EVERYTHING I could think of, I have re-installed both
DNS and MCC a couple of times each, and still the problem persists.
It doesn't seem to be related to resources, licenses, etc... so I am
beginning to suspect something to do with VMS 5.4
It worked a couple of times even if it gave the error, and another
couple of times it even did it right ... !!! It works when you simply
register domains, and I was able to access DNS from NOTES, so DNS is
there and working but somehow MCC fails to connect to it.
Anyway here follows a log of one of the many many failures with the
some tracing enabled.
Gil
$MCC
DECmcc (V1.1.0)
USE VERIFY ON
REGISTER NODE4 tq_ns:.dna_node.BISTRO SYNONYM=BISTRO
*****************************************************
* FCL PM Arguments before call_function: *
*****************************************************
VERB code: 29
PARTITION code: 10
AES dump of ENTITY IN:
depth=1 class code= 12 instance = �
ILV dump of IN_P:
[ 0 ] (
[ 0 ] 42 49 53 54 52 4f -- BISTRO
)
ILV dump of IN_Q: in_q is NULL
TIME SPEC is: 0, NOW
HANDLE STATE, before call: FIRST
%MCC-I-LOG, MCC_IM_LOG = 28
MCC_CALL FUNCTION (2) dispatch start
241 calls to LIB$GET_VM, 16 calls to LIB$FREE_VM, 1039568 bytes still allocated
MCC_CALL ACCESS (2) dispatch start
363 calls to LIB$GET_VM, 61 calls to LIB$FREE_VM, 1056168 bytes still allocated
MCC_CALL ACCESS (3) dispatch return
374 calls to LIB$GET_VM, 63 calls to LIB$FREE_VM, 1057136 bytes still allocated
MCC_CALL ACCESS (2) dispatch start
374 calls to LIB$GET_VM, 64 calls to LIB$FREE_VM, 1056088 bytes still allocated
MCC_CALL ACCESS (3) dispatch return
401 calls to LIB$GET_VM, 88 calls to LIB$FREE_VM, 1057152 bytes still allocated
MCC_CALL ACCESS (2) dispatch start
408 calls to LIB$GET_VM, 94 calls to LIB$FREE_VM, 1058880 bytes still allocated
MCC_CALL ACCESS (3) dispatch return
412 calls to LIB$GET_VM, 98 calls to LIB$FREE_VM, 1059680 bytes still allocated
MCC_CALL FUNCTION (3) dispatch return
420 calls to LIB$GET_VM, 110 calls to LIB$FREE_VM, 1056520 bytes still allocated
**********************************************
FCL PM Arguments on return from call_function:
CVR returned:
%MCC-S-COMMON_EXCEPTIO, success with common exception reply
ILV dump of OUT_P:
[ 2 ] (
[ 1 ] 01
[ 2 ] 01 de 80 22
)
AES dump of ENTITY OUT:
depth=1 class code= 12 instance = �
HANDLE STATE, on return: FIRST
HANDLE STATE, at check_handle: = 0
Node4 TQ_NS:.dna_node.BISTRO
AT 11-JUL-1991 16:42:26
The requested operation cannot be completed
MCC Routine Error = %DNS-E-NOCOMMUNICATION, Unable to
communicate with DNS server
USE VERIFY OFF
EXIT
$
T.R | Title | User | Personal Name | Date | Lines |
---|
1236.1 | I'm no dns guru, but this worked for us... | TOOK::DMCLURE | Work to build the net | Thu Jul 11 1991 15:53 | 38 |
| First of all, there is a dns$analyze.exe program you might want
to try (see note 490.3 in the NOTED::DNS notesfile for more info).
Also, are you sure you correctly reinstalled dns? I made this
mistake several times before I finally got it right. Follow this
procedure exactly (substituing <diskname> and <nodename>'s, etc. where
appropriately marked) to reinstall dns. Warning: this procedure will
blow away your existing local namespace, so only do this if you don't
care what's currently in there:
A. Prior to [re]installing dns:
1. $ @sys$manager:dns$stop
2. $ @sys$manager:dns$client_stop
3. $ delete sys$system:dns$global.gbl;
4. $ delete sys$system:global_cache.gbl;
5. $ rename sys$system:dns$default_file.dat *_old.dat
6. $ delete <diskname>:[sys0.dns$server]ch_<nodename>.dns;
7. $ delete <diskname>:[sys0.dns$server]ch_<nodename>.gbl;
B. Install dns making sure you have the latest dns V1.1 kit (apparently
there was a patched kit released sometime after the original V1.1):
1. $ @sys$update:vmsinstal dns <kit_location>
C. DNS post-installation instructions:
1. $ @sys$manager:dns$startup
2. Add above to systartup_v5.com (if not already there).
...and that should fix your problem (fingers crossed). It worked
for us anyway. Previously we had problems similar to yours which
turnd out to be caused be multiple name servers running on the same
system (one in sys$specific and one in sys$common).
-davo
note: check also notes #463.*, and #490.* in the NOTED::DNS notesfile.
|
1236.2 | Check the default DNS Namespace | TRM::KWAK | | Thu Jul 11 1991 16:31 | 19 |
| RE: .0
When you specify the Namespace (tq_ns:) in the fullname in a node4
registration command, for example,
REGISTER NODE4 tq_ns:.dna_node.BISTRO SYNONYM=BISTRO
the MCC V1.1 tries to create two backtranslation links (synonym and
address backtranslation) in your system's DEFAULT DNS Namespace!!
It looks like that the DNS Clerk on your system cannot communicate with
the nameserver of the default namespace. Check your system's DNS default
namespace, and see if you can access the namespace using DNS$Control
program.
William
PS: The topic #652 includes many discussions on DNS default namespace.
|
1236.3 | | NSSG::R_SPENCE | Nets don't fail me now... | Thu Jul 11 1991 17:20 | 4 |
| The namespace you use for DECmcc MUST be the Default namespace on the
system (for now).
s/rob
|
1236.4 | OK for now | MAYDAY::ANDRADE | The sentinel (.)(.) | Fri Jul 12 1991 06:27 | 16 |
| re .1, .2, .3
Thank you for your help. I had already checked and done the things
you sugested. Namelly accessing DNS using the dns$control program,
checking that the default name space was the correct one, making sure
there were no multiple DNS's, deleting the files and re-installing DNS,
etc...
But because you sugested it, I went and deleted and re-installed DNS
once again, as per Davo's sugestion in re .1, and it worked !!!!!!!!
Third time lucky I guess.
Now lets hope it doesn't go bad once again, as it has done before.
If it does I will post it here.
Gil
|
1236.5 | Thanks William! | TOOK::DMCLURE | Work to build the net | Fri Jul 12 1991 11:17 | 15 |
| re: .4,
> But because you sugested it, I went and deleted and re-installed DNS
> once again, as per Davo's sugestion in re .1, and it worked !!!!!!!!
> Third time lucky I guess.
That's what happened for me too. I could have sworn I already
did those things the first few times, but apparently dns is very
particular about how it reinstalled and it must be done just right
or else...
-davo
p.s. The real credit goes to William Kwak who originally supplied
me with hardcopy of the steps I outlined in #.1.
|