Fwd: Re: [HECnet] More clustering fun

My apolgies for the confusion Peter. But you're right to assume I meant the cl.gr.nr. And yes, there is obviously something wrong here. IF an autogen was done I'd say have a look at modparams.dat - alloclass must be unique for each node - same for tapealloclass And check the cluster license. AFAIK the cluster license must bu unique for each node. Or one license with 0 units and in that case make sure all nodenames are mentioned in the /INCLUDE list, again on all nodes where the license was loaded. PS I'm travelling now so can't check my mail too often Hans -----Original Message----- From: Peter Coghlan <HECNET at beyondthepale.ie> Sender: owner-hecnet at Update.UU.SE Date: Fri, 16 Sep 2011 12:52:13 To: <hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SESubject: Re: Fwd: Re: [HECnet] More clustering fun 2) The cluster id and cluster password are different on both nodes. Whats the cluster id? The cluster id is 4. Sorry - I should have said "What do you mean by the cluster id?" I guess you mean the cluster group number but I wanted to be sure we weren't referring to two different things. I've confirmed that the authorize file is the same on both the alpha and vax nodes: $$ diff dsa0:[sys0.syscommon.sysexe]cluster_authorize.dat - _$$ $4$dkb400:[sys0.syscommon.sysexe]cluster_authorize.dat Number of difference sections found: 0 Number of difference records found: 0 DIFFERENCES /IGNORE=()/MERGED=1- DSA0:[SYS0.SYSCOMMON.SYSEXE]CLUSTER_AUTHORIZE.DAT;1- $4$DKB400:[SYS0.SYSCOMMON.SYSEXE]CLUSTER_AUTHORIZE.DAT;1 [snip] It's weird that by changing the VOTES to 0 on the satellite and running an AUTOGEN that this behaviour is experienced. Before that the satellite boots off the served disk no problem. I doubt that changing VOTES to 0 was responsible. To check this, you could set VOTES back to 1 (probably manually using SYSGEN) and test again. (A problem with running AUTOGEN for the first time is that it finds anything that you didn't know was lurking in MODPARAMS.DAT and acts on it.) Indeed, the 'master' disk which is a local drive in the VAXstation boots into the cluster no problem, but again, with VOTES = 1. Check that there are no files called SYS$SPECIFIC:[SYSEXE]CLUSTER_AUTHORIZE.DAT on either node. If you find any, delete them. You may have to reboot both nodes in order to get them to read the correct CLUSTER_AUTHORIZE.DAT files after copying them or deleting errant ones. Regards, Peter Coghlan.