[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

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

3863.0. "MCC-DNS | Problem with Replica" by COLSER::WELZEL (Uwe Welzel, NaC, Cologne) Tue Oct 06 1992 10:30

Hi,

	We are haveing a problem with our read-only replica of  our mcc-dns
namespace. This problem has been discussed in note 1661 ( and somewhat in
1708 and 2135).

Here is our scenario:

We started with V1.0, then we field tested 1.2 and are now at V1.2. 
About the time that we went to V1.2 ( we are not sure if the upgrade from
field test to SSB was made before or after creating the second nameserver,
we did both around the same time) we also installed a second nameserver and
replicated our mcc-dns database.

We then noticed that when the master server went down, we couldn't work
with the read only client server. 

Here  is the setup

VAX 4000-500
Master Replica
DNS V1.1 Protocol Version 1.0
DECmcc 1.2

VAXstation 3100
Read-only replica
DNS V1.1 Protocol Version 1.0
DECmcc 1.1

To simulate the DNS-server being unavailable I stopped the DNS-server using
DNS$STOP.COM. Then the VAX 4000 is a client to the read only VS 3100.
But I can't work with DECmcc on either machine. I get the symptoms described
in note 1661, either unknown entity or cannot communicate with DNS Server.
From DNS$Control everything works fine.

Then we started the master, deregistered a node, registered this node and
updated the replica and stopped the master. And now we could work with this
one entity.

So here is the question:

In note 1661 it mentions a DECmcc Kernel Patch 03. But I assume this was
for V1.1, or? (oops, I meant above that we are running DECmcc 1.1 on the
second system) It also mentions that if one installs this patch, that should
be built into V1.2, that one then must reregister all entities, but replicas
aren't used!!?? Can this point be clarified.

Second Question, if i did indeed install my second nameserver and then do
my upgrad to V1.2 would reinstalling my second nameserver and re-replicating
my directories work? Or is it really a general problem with DECmcc that
one has to create the replicas before populating the namespace? ( again see note
1661.13)

Now, if this is a general MCC problem, then it is really a problem!! I would
think that one of the purposes of using DNS is this ability to have
many nameservers for backup purposes. One server is not available, then DECmcc 
can look to another name server. So, if one cannot replicate directories after
populating the DECmcc domains ( at the moment just an assumption based on
note 1661) then that means that after installing DECmcc one cannot say, now I
would like to create a read-only replica in these other name servers or
decide to buy another nameserver and then replicate the mcc database without
having to deregister and register all entities. I really don't think this
would be a great selling point for our product. I hope therefore that my
assumption is wrong.

Julie Ann

T.RTitleUserPersonal
Name
DateLines
3863.1DNS$LIB bugTOOK::R_SPENCENets don't fail me now...Tue Oct 06 1992 14:0618
    This particular problem is not actually a DECmcc fault. It wouldn't
    have mattered which version of DECmcc you have.
    
    The problem is that MCC Attributes in DNS are binary coded values
    that happen to have values that are less than the binary value of
    the space character (the lowest printable ascii character). DNS$CONTROL
    only deals with codes from SPACE on up. Soooo, when you created the
    replica set and (I assume) COPYed the directories with DNS$CONTROL,
    it didn't copy the DECmcc Attributes.
    
    There is a fix for this. The problem is in DNS$LIB.EXE 
    
    The next note will contain a patch for it.
    
    You will need to recreate the replica set after applying the patch
    but you don't need to re-register the DECmcc entities.
    
    s/rob
3863.2DNS$LIB_SIMPLEMATCH.PATCHTOOK::R_SPENCENets don't fail me now...Tue Oct 06 1992 14:0783
$! see below for details of patch
$! To install, simply run this .com file.
$! 
$    verify_save 	= "noverify"
$    if f$verify() .eq. 1 then -
	verify_save = "verify"
$    default_save 	= f$environment("default")
$!
$    if f$trnlnm("exe$dir") .eqs. "" then -
        define exe$dir sys$system, sys$library
$!----------------------------------------------------------------------------
$    file		= "dns$lib.exe"
$!----------------------------------------------------------------------------
$    x 			= f$search("exe$dir:''file'")
$    if x .nes. "" then -
	goto filefound
$    write sys$output "File ''file' not found"
$    exit
$!
$filefound:
$    defdir		= f$parse("''x'",,,"device") -
			+ f$parse("''x'",,,"directory")
$    on control_y then - 
	goto cleanup
$!
$    set verify 
$    set default 'defdir'	! force updated file to same directory
$!
$    patch 'file'
!
!  Patch to DNS$LIB.EXE in V1.1 to fix dns$names_simplematch such that NULL
!  simplenames collate lower than all other types.
!  (ref module NAMES_LIB in DNS 1.1 listings)
!  This is to fix a problem which manifested itself under MCC wherein
!  attributes with binary (as opposed to normal) names on objects, were not 
!  copied when the directory in which the objects resided was replicated
!  (ie. using DNS$CONTROL COPY DIRECTORY command). Any binary named attributes
!  would not be returned for requests serviced by the clearinghouse containing
!  the directory replica.
!
	set eco 1
	define simplematch=420D
	define x=simplematch-0C
	repl/i x+0E
!					make room for JMP to patch area
		'MOVAB   W^0FDF8(SP),SP'
		'MOVAL   W^0FDFA(FP),R3'
		exit
!					restore instructions replaced by JMP
		'MOVAB   W^0FDF8(SP),SP'
		'MOVAL   W^0FDFA(FP),R3'
!					now for the inserted code
		'MOVL	B^04(AP),R1'	! name1 addr
		'MOVL	B^08(AP),R2'	! name2 addr
		'CMPB	(R1),#0'
		'BNEQ	L2'		! name1 type not NULL
		'CMPB	(R2),#0'
		'BNEQ	L1'		! name2 type not NULL
		'MOVL	#0,R0'		! both NULL - return EQL
		'RET'
	'L1:	 MNEGL	#1,R0'		! name1 NULL, name2 ^NULL - return LSS
		'RET'
	'L2:	 CMPB	(R2),#0'
		'BNEQ	L4'		! name2 type not NULL
		'CMPB	(R1),#0'
		'BNEQ	L3'		! name1 type not NULL
		'MOVL	#0,R0'		! both NULL - return EQL
		'RET'
	'L3:	 MOVL	#1,R0'		! name1 ^NULL, name2 NULL - return GTR
		'RET'
	'L4:	 NOP'			! continue in original code
		exit
	UPDATE
	EXIT
$    if .not. $status then -
	goto cleanup
$    x=f$environment("DEFAULT")+file
$    if f$file_attributes(x,"KNOWN") then -
         install replace 'x
$cleanup:
$    set default 'default_save'
$    set 'verify_save'
$    exit
3863.3Thanks for the PatchCOL01::WELZELUwe Welzel, NaC, CologneMon Oct 12 1992 17:098
    
    Thanks Rob,
    
    the patch has solved the problem. We're now able to shutdown the
    DNS-Master and having all MCC information on the Read Only Replica
    available.
    
    Best regards Uwe