1 INFO-VAX	Sun, 24 Sep 2006	Volume 2006 : Issue 525       Contents:6 Can a satellite survive the reboot of its boot server?: Re: Can a satellite survive the reboot of its boot server?: Re: Can a satellite survive the reboot of its boot server?: Re: Can a satellite survive the reboot of its boot server?# Can a VAX MSCP-serve an ODS5 disk ? ' Re: Can a VAX MSCP-serve an ODS5 disk ? ' Re: Can a VAX MSCP-serve an ODS5 disk ? 2 Re: Should I upgrade from 7.3-2 and if so to what?. SYSUAF quota differences between VAX and Alpha2 Re: SYSUAF quota differences between VAX and Alpha  F ----------------------------------------------------------------------  + Date: Sun, 24 Sep 2006 09:28:47 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)? Subject: Can a satellite survive the reboot of its boot server? $ Message-ID: <ef5j4f$700$2@online.de>  C Imagine a 3-node cluster with each node having 1 vote.  Then boot a G 0-vote satellite into the cluster from one of the nodes.  What happens  - to this satellite if its boot server reboots?   F Motivation: My hobbyist cluster now has 2 VAXes at 7.3 and an ALPHA atC 7.3-2.  Normally, the only reboots take place after installation of G patches which require a reboot.  I also like to avoid a cluster reboot. H I have many shadow sets whose members have direct connections to variousH nodes, but any member has a direct connection to only 1 node.  Since the> advent of MINICOPY, it is no problem to reboot a VAX since, byB dismounting from the ALPHA the members of the shadow sets directlyG connected to the VAX to be rebooted, and mounting them back in from the H ALPHA, no full shadow copy is required.  My idea is to use the satelliteG (an ALPHA) for the DISMOUNT and MOUNT commands while rebooting its boot D server (also an ALPHA).  With the present setup, when rebooting the G ALPHA, I get a full shadow copy to members of shadow sets on it if the  . other member was on a VAX which didn't reboot.  A I don't mind if the satellite hangs during the reboot of its boot G server.  The essential thing is that the MINICOPY bitmaps survive this  E transition so that I can get a MINICOPY when the boot server and its  ! disks come back into the cluster.    ------------------------------  + Date: Sun, 24 Sep 2006 12:41:39 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) C Subject: Re: Can a satellite survive the reboot of its boot server? ( Message-ID: <ef5ue3$pvt$1@pcls6.std.com>  R helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:  D >Imagine a 3-node cluster with each node having 1 vote.  Then boot aH >0-vote satellite into the cluster from one of the nodes.  What happens . >to this satellite if its boot server reboots?  F To a satellite, the boot node is just another cluster member once it's@ booted.  (actually true from an early stage in the boot process)  E You'll see a 'hang' if the existing number of votes becomes less than G quorum, or its MSCP served system disk goes away while the serving node D is down (be sure the server gets rebooted and serving the disk with  MVTIMEOUT seconds).    ------------------------------  + Date: Sun, 24 Sep 2006 16:43:46 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)C Subject: Re: Can a satellite survive the reboot of its boot server? $ Message-ID: <ef6ck2$pab$1@online.de>  H In article <ef5ue3$pvt$1@pcls6.std.com>, moroney@world.std.spaamtrap.com (Michael Moroney) writes:   F > >Imagine a 3-node cluster with each node having 1 vote.  Then boot aJ > >0-vote satellite into the cluster from one of the nodes.  What happens 0 > >to this satellite if its boot server reboots? > H > To a satellite, the boot node is just another cluster member once it'sB > booted.  (actually true from an early stage in the boot process)  G Not really, since its system disk is on that particular boot node.  It  G does have local page and swap files, but otherwise uses other disks in  E the cluster (the system disk---on the boot node---and other disks as   well).  G > You'll see a 'hang' if the existing number of votes becomes less than 
 > quorum,   C Quorum will stay up (just 1 of 3 equally voting nodes will reboot).   A > or its MSCP served system disk goes away while the serving node 
 > is down   I Yes, that will happen, since the satellite has access to its system disk  " on the boot node only via the LAN.  > > (be sure the server gets rebooted and serving the disk with  > MVTIMEOUT seconds).   F MVTIMEOUT is set to 3600 seconds (the default) so that shouldn't be a  problem.  F Essentially all my disks are shadow sets.  If the entire shadow set isH unavailable (as would be the case for the system disk when the boot nodeH boots since both members have direct connections only to the boot node),< then presumably MVTIMEOUT plays the same role it would for aD non-shadowed disk.  What happens, though, when just one member of a E shadow set is unavailable?  Do I/O operations wait MVTIMEOUT seconds  H before giving up, or does the surviving member continue on (necessating . a (mini)copy when the other member comes back?   ------------------------------  + Date: Sun, 24 Sep 2006 17:30:29 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) C Subject: Re: Can a satellite survive the reboot of its boot server? ( Message-ID: <ef6fbl$359$1@pcls4.std.com>  R helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:  I >In article <ef5ue3$pvt$1@pcls6.std.com>, moroney@world.std.spaamtrap.com  >(Michael Moroney) writes:    G >> >Imagine a 3-node cluster with each node having 1 vote.  Then boot a K >> >0-vote satellite into the cluster from one of the nodes.  What happens  1 >> >to this satellite if its boot server reboots?  >>  I >> To a satellite, the boot node is just another cluster member once it's C >> booted.  (actually true from an early stage in the boot process)   C >Not really, since its system disk is on that particular boot node.   E OK, so the part about the disk server applies.  My point was there is I nothing special about the boot server shortly after boot, other than it's : likely to be the disk server as well, and in your case is.  J It's possible for a VAX to be the disk server of an Alpha system disk, andE it's probably possible (after certain copying files over and manually A entering some configuration data) to boot a cluster member from a D standalone node on the same net or even a non-VMS system, as long asG the cluster (esp. system disk) is also visible from the booting system, ( but I've never heard of the latter done.  ? >> (be sure the server gets rebooted and serving the disk with   >> MVTIMEOUT seconds).  G >MVTIMEOUT is set to 3600 seconds (the default) so that shouldn't be a  	 >problem.   G >Essentially all my disks are shadow sets.  If the entire shadow set is I >unavailable (as would be the case for the system disk when the boot node I >boots since both members have direct connections only to the boot node), = >then presumably MVTIMEOUT plays the same role it would for a E >non-shadowed disk.  What happens, though, when just one member of a  F >shadow set is unavailable?  Do I/O operations wait MVTIMEOUT seconds I >before giving up, or does the surviving member continue on (necessating  / >a (mini)copy when the other member comes back?   F The system will wait up to SHADOW_MEMBER_TMO seconds for the member toF come back, then it will kick out the missing member and continue using the remaining member(s).  A System disk is a special case, it'll wait SHADOW_SYS_TMO instead.   2 If all members are unreachable, MVTIMEOUT applies.   ------------------------------  % Date: Sun, 24 Sep 2006 02:25:09 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> , Subject: Can a VAX MSCP-serve an ODS5 disk ?, Message-ID: <451624C2.3B3C45E5@teksavvy.com>  H If I have a disk attached to a VAX, could an Alpha system intialise that, disk as an ODS-5 drive without any problem ?  F (this is VAX VMS 7.2, and the ALPHA might be 8.2 if I am lucky, or 8.3 if very lucky).   F Or is MSCP serving so low level that it absolutely does not care about volume format at all ?  F I take it that VAX-VMS backup would be unable to work on this disk andF that any backups would have to be MSCP served from the VAX hosted disk to the VAX hosted tape ?   ------------------------------  % Date: Sun, 24 Sep 2006 11:01:23 +0200 # From: "H Vlems" <hvlems@freenet.de> 0 Subject: Re: Can a VAX MSCP-serve an ODS5 disk ?5 Message-ID: <ef5hco$2304$1@registered.motzarella.org>   < "JF Mezei" <jfmezei.spamnot@teksavvy.com> schreef in bericht& news:451624C2.3B3C45E5@teksavvy.com...J > If I have a disk attached to a VAX, could an Alpha system intialise that. > disk as an ODS-5 drive without any problem ? >   I Never tried that JF, but the answer is very likely "no". The VAX serves a ' filesystem, not a collection of blocks.   H > (this is VAX VMS 7.2, and the ALPHA might be 8.2 if I am lucky, or 8.3 > if very lucky).  > H > Or is MSCP serving so low level that it absolutely does not care about > volume format at all ?  L MSCP requires knowledge of the filesystem that sits on the volume it serves.L That's why I think that a VAX cannot serve an ODS-5 disk. Its own version of RMS has no clue about ODS-5. > H > I take it that VAX-VMS backup would be unable to work on this disk andH > that any backups would have to be MSCP served from the VAX hosted disk > to the VAX hosted tape ?6 That question is moot, given the first answer is true.   Hans   ------------------------------  + Date: Sun, 24 Sep 2006 12:35:33 +0000 (UTC) 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) 0 Subject: Re: Can a VAX MSCP-serve an ODS5 disk ?( Message-ID: <ef5u2k$t0t$1@pcls4.std.com>  / JF Mezei <jfmezei.spamnot@teksavvy.com> writes:   I >If I have a disk attached to a VAX, could an Alpha system intialise that - >disk as an ODS-5 drive without any problem ?   J Yes.  The VAX won't know what to do with it if you try to mount it there, 
 of course.  G >Or is MSCP serving so low level that it absolutely does not care about  >volume format at all ?   H Exactly.  Blocks is blocks to it.  The MSCP Server is driver level code.   ------------------------------  + Date: Sun, 24 Sep 2006 10:39:31 +0000 (UTC)  From: david20@alpha2.mdx.ac.uk; Subject: Re: Should I upgrade from 7.3-2 and if so to what? , Message-ID: <ef5n93$43d$1@south.jnrs.ja.net>  w In article <ef5ikg$700$1@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes: H >My hobbyist cluster now has 2 VAXes at 7.3 and an ALPHA at 7.3-2.  I'm I >considering upgrading from 7.3-2 to 8.x.  What is the recommended value  J >of x?  I believe 8.2 and 8.3 are out now.  My intuition would be to wait B >for 8.3-1.  What do people here think?  Can I upgrade from 7.3-2 I >directly to 8.x for any value of x?  What is the highest value of x for  ; >which 7.3 (VAX) is supported as being in the same cluster?  >   D Details of supported upgrade paths are documented in the upgrade and. installation manual for each version of the OS   ie  P http://h71000.www7.hp.com/doc/83final/ba322_90045/ch04s03.html#vms-upgrade-paths   and   B http://h71000.www7.hp.com/doc/82FINAL/ba322-90002/ba322-90002.HTMlB (chapter 5 Before Upgrading the openVMS Alpha Operating system ->   Notes,cautions and restrictions)  N In this instance you can  upgrade directly from VMS 7.3-2 to either VMS 8.2 or VMS 8.3     H Upgrading directly from VMS 7.3-2 to later versions of VMS when they areL released is not guaranteed to be supported - for instance if you instead hadK VMS 7.3-1 you would be able to upgrade directly to VMS 8.2 but would not be % able to upgrade directly to VMS 8.3).       O Vax 7.3 and Alpha 8.3 systems in the same cluster are a warranted configuration  see   > http://h71000.www7.hp.com/doc/83final/ba322_90045/ch02s03.html    N and I'd expect that Vax 7.3 systems would continue to be supported in clusters, with future Alpha VMS versions for sometime.  
 David Webb Security team leader CCSS Middlesex University    I >Since I don't have any Itanium systems yet, anything related to Itanium  / >is not an issue affecting my upgrade decision.  >    ------------------------------  % Date: Sun, 24 Sep 2006 03:30:08 -0400 . From: JF Mezei <jfmezei.spamnot@vaxination.ca>7 Subject: SYSUAF quota differences between VAX and Alpha - Message-ID: <451633FC.9698131E@vaxination.ca>   2 OK, I know I am probably 10 years late on this....  B In the archives of c.o.v, I have found many references to having aH shared SYSUAF in a mixex archittecture cluster. There is a suggestion toG have the SYSUAF quotas set for VAX and then using PQL i SYSGEN to boost ; minimum quotas on the Alpha. Is that still the suggestion ?   H However, in terms of actual quotas, is there a rule of thumb that can be( used when converting from VAX to ALPHA ?  F Apart from working set (wsdef, wsquota, wsextent, pgflquo), what other quotas need to be changed ?     H If I have a shared SYSUAF with VAX-created TCPIP Services accounts, whenC I use PCSI to install TCPIP Services on the Alpha, can I expect the F installation process to increases the account quotas , or does it justE check for account existance and if it exists, it just skips over that G account ?  (Used TCPIP Services as an example here, but the question is 1 meant more generally with PCSI and/or VMSinstall)     E Also, is it possible to have a "backup" SYSUAF by having a searchlist ' for the SYSUAF (and related) logicals ?   G EG: first definition points to the file on the common directory (served D by another node), and second definition points to a  ciopy of SYSUAF= residing locally on that system. Is that possible/supported ?    ------------------------------  % Date: Sun, 24 Sep 2006 15:58:55 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> ; Subject: Re: SYSUAF quota differences between VAX and Alpha J Message-ID: <paul.sture.nospam-556477.15585524092006@mac.sture.homeip.net>  - In article <451633FC.9698131E@vaxination.ca>, 0  JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:  4 > OK, I know I am probably 10 years late on this.... >    Not to worry...   A First things first. My congratulations to yourself and the other  F winners, and of course to David for doing the right thing when he had - mail server problems with his original offer.   D > In the archives of c.o.v, I have found many references to having aJ > shared SYSUAF in a mixex archittecture cluster. There is a suggestion toI > have the SYSUAF quotas set for VAX and then using PQL i SYSGEN to boost = > minimum quotas on the Alpha. Is that still the suggestion ?   @ Going back 10 years, we decided to have 2 SYSUAFs, one for each F architecture. This was a production line control system, so we simply  took the conservative approach.   F Yes, that meant discipline was required to keep bot UAFs in step, but > out turnover of users was pretty low, so not really much work.  E Since you yourself have the opportunity to experiment, I'd recommend  ? trying out the PQL stuff and see if it meets your requirements.   J > However, in terms of actual quotas, is there a rule of thumb that can be* > used when converting from VAX to ALPHA ? > H > Apart from working set (wsdef, wsquota, wsextent, pgflquo), what other > quotas need to be changed ?  >   B Your best bet is to see what the defaults are. Look at the SYSUAF @ produced by the VMS installation. If perchance you have already I overwritten it with the one from your VAX, then do the following to find  
 the defaults:   $ $ define sysuaf somewhere:sysuaf.tmp $ mcr authorize D %UAF-E-NAOFIL, unable to open system authorization file (SYSUAF.DAT) -RMS-E-FNF, file not found$ Do you want to create a new file?  Y UAF> show default  UAF> show system UAF> ^Z  $ deassign sysuaf   I Make a note of the defaults and then review and modify existing accounts   in your real UAF accordingly.   F I don't know which version of VMS you have for your Alpha, but please E note that the V8.2 Release Notes contain revised recommendations for  * cetain quotas for both SYSTEM and DEFAULT:   --  
 Paul Sture   ------------------------------   End of INFO-VAX 2006.525 ************************                    