1 INFO-VAX	Tue, 25 Apr 2006	Volume 2006 : Issue 228       Contents: For Sale* Re: HP Storageworks Arrays are Bulletproof* Re: HP Storageworks Arrays are Bulletproof hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question  Re: hypothetical question + Re: IMCB$V_PARENT_PROT What is it good for? + Re: IMCB$V_PARENT_PROT What is it good for? 
 Intel VPro Re: Intel VPro Re: Intel VPro Re: Intel VPro Re: Intel VPro Re: Intel VPro Re: Intel VPro Re: Intel VPro. RE: Opinion: I was just trying to sell OpenVMS. Re: Opinion: I was just trying to sell OpenVMS% OT: Scott McNeily steps down from SUN  Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet RE: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet Re: OT: Sparc not dead yet* Re: Quorum, locks and application question* Re: Quorum, locks and application question* Re: Quorum, locks and application question Re: Replacing drives in bricks4 Re: shadow sets, cluster, merge, MVTIMEOUT, dismount" Spawn command in Asynchronous mode& Re: Spawn command in Asynchronous mode Re: Strange disk device state  Re: Strange disk device state  Re: Strange disk device state  Re: Strange disk device state  Re: Strange disk device state ' Re: The Sun Logo on the OpenVMS Manuals P Re: The Sun Logo on the OpenVMS Manuals (was: Re: HP Storageworks Arrays are Bul To Be Auctioned: MicroVAX 3100s   F ----------------------------------------------------------------------  # Date: Mon, 24 Apr 2006 20:36:49 GMT  From: <logquality@hotmail.com> Subject: For Sale + Message-ID: <BFa3g.10120$2c3.4867@edtnps89>    DEC Alpha Server (HP) 800 5/333  (Windows 2k RC1 installed) $300  # Shuttle XPC SN45g + Sony DCR TRV 25  Computer and Canmcorder  AMD 2600+ (tbred B)  786 DDR 400 RAM  40 Gig & 80 Gig Hardrives  Geforce 6600GT Video Card  17inch Samsung CRT LiteON CDRW/DVD Player    Sony DCR TRV 25 Mini DV Handycam5 Full Package, Tripod, Carry Case, Carl Zeis wide lens  Extra huge Battery  5 $1250 for Both or 600 for Handycam + 750 for Computer    ------------------------------  % Date: Mon, 24 Apr 2006 21:47:46 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca> 3 Subject: Re: HP Storageworks Arrays are Bulletproof 7 Message-ID: <7df3g.841$1V4.64075@news20.bellglobal.com>   ; "JF Mezei" <jfmezei.spamnot@teksavvy.com> wrote in message  % news:444D0951.8E908F1@teksavvy.com...  > Neil Rieck wrote: " >> I have yet to see OpenVMS takenA >> seriously by anyone outside of this newsgroup as a desktop OS.  > G > The problem is VMS beung taken seriously is far more than just at the G > desktop. People don't take it seriously because it is taken for dead, 7 > not marketed and HP doesn't defend any FUD about VMS.  > L You sound so negative. We all would like to see a little more marketing but 4 at least things have improved since the Compaq days.  = 1) Compaq got rid of OpenVMS education and HP is reviving it. 9 2) The TUD (technical update days) stuff started under HP 4 3) I "think" the OpenVMS boot camps started under HP 4) This web page: A http://h71000.www7.hp.com/openvms/os/openvms-release-history.html L makes me think HP is cranking out more OpenVMS code (in a shorter amount of  time) than Compaq did.  M The current HP atmosphere is somewhat reminiscent of the DEC days. Only time  H will tell if things can get even better. Now with regards to an OpenVMS I desktop, I don't think this will ever happen until OpenVMS runs on x86-64   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.8 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html: http://www3.sympatico.ca/n.rieck/links/openvms_demos.html    ------------------------------  % Date: Mon, 24 Apr 2006 23:51:11 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 3 Subject: Re: HP Storageworks Arrays are Bulletproof / Message-ID: <r5mdnQNJ_vVsBtDZRVn-jg@libcom.com>    JF Mezei wrote:  > Neil Rieck wrote:  > ! >>I have yet to see OpenVMS taken @ >>seriously by anyone outside of this newsgroup as a desktop OS. >  > G > The problem is VMS beung taken seriously is far more than just at the G > desktop. People don't take it seriously because it is taken for dead, 7 > not marketed and HP doesn't defend any FUD about VMS.  > E > Lets face it: apart from the work done by Mr Peleg, the rest of VMS I > development doesn't affect users at all. Engineering is just keeping up G > with hardware changes, new disk technologies , new interconnects.  So ) > the user interface on VMS is quite old.  > G > It wouldn' that that much to bring in Motif 2.3, and possibly include J > additional widgets, update the DEC specific widgets and make the desktopI > quite modern.  It may not have "office" softwware, but there are plenty G > of applications that are desktop but not "office". (think air traffic ) > control, nuclear reactor control rooms,   H After seeing and reading about DECwindows reliability, you would use it  in critical areas?   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Mon, 24 Apr 2006 22:25:30 +0300 7 From: "Guy Peleg" <guy.peleg@remove_this_header@hp.com>  Subject: hypothetical question* Message-ID: <444d262e@usenet01.boi.hp.com>  : If I could make your BACKUP operations complete faster....; 2-5 times faster....but restrict this feature for save-sets 7 written to disks only (not to support it with save-sets / written to tapes).....would you find it useful?   ! I'm looking for yes/no answer....   ' Please do not ask for more details..... 1 Please do not speculate.....it will be clear soon   ; I'm unable to provide any further information at this point    Thank you !   	 Guy Peleg  OpenVMS Engineering   J (Please do not re-post this in any other forum, I chose c.o.v. on purpose)   ------------------------------  % Date: Mon, 24 Apr 2006 14:28:49 -0500 7 From: Staffan Tjernstrom <news@staffan.tjernstrom.name> " Subject: Re: hypothetical questionR Message-ID: <1145906928.8304.0.camel@linspiron8200.mobile.staffan.tjernstrom.name>   Yes.3 On Mon, 2006-04-24 at 22:25 +0300, Guy Peleg wrote: < > If I could make your BACKUP operations complete faster....= > 2-5 times faster....but restrict this feature for save-sets 9 > written to disks only (not to support it with save-sets 1 > written to tapes).....would you find it useful?  > # > I'm looking for yes/no answer....  > ) > Please do not ask for more details..... 3 > Please do not speculate.....it will be clear soon  > = > I'm unable to provide any further information at this point  > 
 > Thank you !  >  > Guy Peleg  > OpenVMS Engineering  > L > (Please do not re-post this in any other forum, I chose c.o.v. on purpose) >  >    ------------------------------  % Date: Mon, 24 Apr 2006 15:53:19 -0400  From: norm.raphael@metso.com" Subject: Re: hypothetical questionQ Message-ID: <OF1CE6AB29.3C7BBBA5-ON8525715A.006D2D2D-8525715A.006D406B@metso.com>    Yes.  G "Guy Peleg" <"guy.peleg@remove_this_header"@hp.com> wrote on 04/24/2006  03:25:30 PM:  < > If I could make your BACKUP operations complete faster....= > 2-5 times faster....but restrict this feature for save-sets 9 > written to disks only (not to support it with save-sets 1 > written to tapes).....would you find it useful?  > # > I'm looking for yes/no answer....  > ) > Please do not ask for more details..... 3 > Please do not speculate.....it will be clear soon  > = > I'm unable to provide any further information at this point  > 
 > Thank you !  >  > Guy Peleg  > OpenVMS Engineering  > C > (Please do not re-post this in any other forum, I chose c.o.v. on  purpose) >  >  [Why would anyone say no?]   ------------------------------  % Date: Mon, 24 Apr 2006 21:58:32 +0200 3 From: Wilm Boerhout <w4OLD.boerhout@PAINTplanet.nl> " Subject: Re: hypothetical question6 Message-ID: <444d2df7$0$29161$ba620dc5@nova.planet.nl>  & Guy Peleg mailde op 24-4-2006 21:25...< > If I could make your BACKUP operations complete faster....= > 2-5 times faster....but restrict this feature for save-sets 9 > written to disks only (not to support it with save-sets 1 > written to tapes).....would you find it useful?  > # > I'm looking for yes/no answer....  > ) > Please do not ask for more details..... 3 > Please do not speculate.....it will be clear soon  > = > I'm unable to provide any further information at this point  > 
 > Thank you !  >  > Guy Peleg  > OpenVMS Engineering  > L > (Please do not re-post this in any other forum, I chose c.o.v. on purpose) >  >  YES!   ------------------------------    Date: 24 Apr 2006 12:56:32 -0700) From: "Ken Robinson" <kenrbnsn@gmail.com> " Subject: Re: hypothetical questionB Message-ID: <1145908592.203364.72390@g10g2000cwb.googlegroups.com>   Guy Peleg wrote:< > If I could make your BACKUP operations complete faster....= > 2-5 times faster....but restrict this feature for save-sets 9 > written to disks only (not to support it with save-sets 1 > written to tapes).....would you find it useful?  > # > I'm looking for yes/no answer....  >   / Can the answer be an unqualified ... maybe? :-)    If not, yes.   Ken Robinson   ------------------------------  # Date: Mon, 24 Apr 2006 20:24:05 GMT ; From: "Jeffrey H. Coffield" <jeffrey@digitalsynergyinc.com> " Subject: Re: hypothetical question> Message-ID: <Fta3g.74706$dW3.16322@newssvr21.news.prodigy.com>   Guy Peleg wrote:< > If I could make your BACKUP operations complete faster....= > 2-5 times faster....but restrict this feature for save-sets 9 > written to disks only (not to support it with save-sets 1 > written to tapes).....would you find it useful?  > # > I'm looking for yes/no answer....  > ) > Please do not ask for more details..... 3 > Please do not speculate.....it will be clear soon  > = > I'm unable to provide any further information at this point  > 
 > Thank you !  >  > Guy Peleg  > OpenVMS Engineering  > L > (Please do not re-post this in any other forum, I chose c.o.v. on purpose) >  >  Yes, absolutely.   ------------------------------  % Date: Mon, 24 Apr 2006 16:09:12 -0400 - From: JF Mezei <jfmezei.spamnot@tekksavy.com> " Subject: Re: hypothetical question, Message-ID: <444D3061.A1F1E648@tekksavy.com>   Guy Peleg wrote: > < > If I could make your BACKUP operations complete faster....0 > 2-5 times faster.....would you find it useful?     Yes.  ? I would not use it often, but when I would, it would be useful.   G HOWEVER: if the time savings would be susbantial, it might allow one to  use    	quiesce aplications,  	BACKUP DISK1: DISK2:  	restore appliction service  	BACKUP DISK2: TAPE1:   E While overall backup operation would take longer, disruption to users  would be shorter.   E You would need to qualify whether your trick applies to all disk/disk I transfers, or just disks on the same node without SCS being involved etc.      > I chose c.o.v. on purpose   F And you should know that on c.o.v, you cannot get just a "yes" or "no"
 answer :-)   ------------------------------    Date: 24 Apr 2006 13:22:53 -0700 From: davidc@montagar.com " Subject: Re: hypothetical questionC Message-ID: <1145910173.764149.294140@e56g2000cwe.googlegroups.com>    Yes.   ------------------------------  % Date: Mon, 24 Apr 2006 20:51:32 +0000  From: bradhamilton@comcast.net" Subject: Re: hypothetical questiong Message-ID: <042420062051.10693.444D3A53000EB889000029C5220076139402019B0407030E080B0E9D0D@comcast.net>   7  -------------- Original message ----------------------  From: "Guy Peleg" < > If I could make your BACKUP operations complete faster....= > 2-5 times faster....but restrict this feature for save-sets 9 > written to disks only (not to support it with save-sets 1 > written to tapes).....would you find it useful?  > # > I'm looking for yes/no answer....    Yes.   ------------------------------  # Date: Mon, 24 Apr 2006 20:59:05 GMT + From: Ryan Moore <rmoore@rmoore.dyndns.org> " Subject: Re: hypothetical question; Message-ID: <Pine.LNX.4.64.0604241357330.9822@jaipur.local>   K My vote for yes.  I'd say most of our backups are to disk instead of tape.  J And the ones to tape happen in batch, so if it takes a little longer, not  a big deal.   % On Mon, 24 Apr 2006, Guy Peleg wrote: < > If I could make your BACKUP operations complete faster....= > 2-5 times faster....but restrict this feature for save-sets 9 > written to disks only (not to support it with save-sets 1 > written to tapes).....would you find it useful?  > # > I'm looking for yes/no answer....    ------------------------------  # Date: Mon, 24 Apr 2006 21:00:47 GMT + From: Ryan Moore <rmoore@rmoore.dyndns.org> " Subject: Re: hypothetical question; Message-ID: <Pine.LNX.4.64.0604241400010.9864@jaipur.local>   H And if a feature would only work to disk, it would be awesome if BACKUP J could figure out it was going to disk and automatically choose the faster  mode.   % On Mon, 24 Apr 2006, Guy Peleg wrote: < > If I could make your BACKUP operations complete faster....= > 2-5 times faster....but restrict this feature for save-sets 9 > written to disks only (not to support it with save-sets 1 > written to tapes).....would you find it useful?  > # > I'm looking for yes/no answer....  > ) > Please do not ask for more details..... 3 > Please do not speculate.....it will be clear soon  >    ------------------------------   Date: 24 Apr 2006 20:58:36 GMT From: healyzh@aracnet.com " Subject: Re: hypothetical question+ Message-ID: <e2je5s029v@enews3.newsguy.com>   6 Guy Peleg <guy.peleg@remove_this_header@hp.com> wrote:< > If I could make your BACKUP operations complete faster....= > 2-5 times faster....but restrict this feature for save-sets 9 > written to disks only (not to support it with save-sets 1 > written to tapes).....would you find it useful?   # > I'm looking for yes/no answer....    Yes    	Zane    ------------------------------  % Date: Mon, 24 Apr 2006 14:36:46 -0700 # From: "Tom Linden" <tom@kednos.com> " Subject: Re: hypothetical question) Message-ID: <op.s8i7nkvzzgicya@hyrrokkin>   / On Mon, 24 Apr 2006 12:25:30 -0700, Guy Peleg   , <guy.peleg@remove_this_header@hp.com> wrote:   > would you find it useful?    Yes.   ------------------------------  % Date: Mon, 24 Apr 2006 17:59:00 -0400 - From: "Jim Agnew" <brainwavesurfer@gmail.com> " Subject: Re: hypothetical questionI Message-ID: <a184d6630604241459m3f90c22en9ced37bb65a7e1a2@mail.gmail.com>   ) ------=_Part_22329_24489811.1145915940349 , Content-Type: text/plain; charset=ISO-8859-1+ Content-Transfer-Encoding: quoted-printable  Content-Disposition: inline   D Absolutely!!!!  This would help us get back up online a bit faster..   Thanks!!   Jim   ; On 4/24/06, Guy Peleg <guy.peleg@remove_this_header> wrote:  > < > If I could make your BACKUP operations complete faster....= > 2-5 times faster....but restrict this feature for save-sets 9 > written to disks only (not to support it with save-sets 1 > written to tapes).....would you find it useful?  > # > I'm looking for yes/no answer....  > ) > Please do not ask for more details..... 3 > Please do not speculate.....it will be clear soon  > = > I'm unable to provide any further information at this point  > 
 > Thank you !  >  > Guy Peleg  > OpenVMS Engineering  > L > (Please do not re-post this in any other forum, I chose c.o.v. on purpose= )  >  >  >   ) ------=_Part_22329_24489811.1145915940349 + Content-Type: text/html; charset=ISO-8859-1 + Content-Transfer-Encoding: quoted-printable  Content-Disposition: inline   L Absolutely!!!!&nbsp; This would help us get back up online a bit faster.. <=L br><br>Thanks!!<br><br>Jim<br><br><div><span class=3D"gmail_quote">On 4/24/=L 06, <b class=3D"gmail_sendername">Guy Peleg</b> &lt;guy.peleg@remove_this_h= eader&gt; wrote:L </span><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rg=L b(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If I could=L  make your BACKUP operations complete faster....<br>2-5 times faster....but=$  restrict this feature for save-setsL <br>written to disks only (not to support it with save-sets<br>written to t=L apes).....would you find it useful?<br><br>I'm looking for yes/no answer...=K <br><br>Please do not ask for more details.....<br>Please do not speculate=  ....it will be clear soon L <br><br>I'm unable to provide any further information at this point<br><br>=L Thank you !<br><br>Guy Peleg<br>OpenVMS Engineering<br><br>(Please do not r=L e-post this in any other forum, I chose c.o.v. on purpose)<br><br><br></blo= ckquote>
 </div><br>  + ------=_Part_22329_24489811.1145915940349--    ------------------------------  % Date: Mon, 24 Apr 2006 17:38:36 -0400 - From: JF Mezei <jfmezei.spamnot@tekksavy.com> " Subject: Re: hypothetical question, Message-ID: <444D454F.6644960A@tekksavy.com>   Guy Peleg wrote:# > I'm looking for yes/no answer....      yes/no       :-)    ------------------------------    Date: 24 Apr 2006 15:19:55 -0700( From: "Rich Jordan" <jordan@ccs4vms.com>" Subject: Re: hypothetical questionB Message-ID: <1145917195.371713.36520@t31g2000cwb.googlegroups.com>   Guy,	      yes!   F Both for work (occasional but time critical and important when needed)! and home/hobbyist (all the time!)    Rich   ------------------------------  % Date: Mon, 24 Apr 2006 16:56:20 -0700 , From: Ken Fairfield <my.full.name@intel.com>" Subject: Re: hypothetical question+ Message-ID: <e2joj4$5dh$1@news01.intel.com>    Guy Peleg wrote:< > If I could make your BACKUP operations complete faster....= > 2-5 times faster....but restrict this feature for save-sets 9 > written to disks only (not to support it with save-sets 1 > written to tapes).....would you find it useful?        Absolutely YES!!!   # > I'm looking for yes/no answer....   <     In fact, we have a couple of environments in which we do: a database backup-to-disk during a scheduled downtime (the7 one I'm thinking of at the moment is really a COPY job; 4 there's another that is a database backup).  That is< subsequently backed up to tape.  As we accumulate more data,: making the downtime window gets more difficult and various< ingenious hacks are created to make the window...   Having a5 faster disk-to-disk backup would be a real boon.  :-)    	-Ken  --  6 I don't speak for Intel, Intel doesn't speak for me...  
 Ken Fairfield ! D1C Automation VMS System Support " who:   kenneth dot h dot fairfield where: intel dot com   ------------------------------  % Date: Mon, 24 Apr 2006 20:25:44 -0400 3 From: "Peter Weaver" <newsonly@weaverconsulting.ca> " Subject: Re: hypothetical question7 Message-ID: <e0e3g.800$1V4.62243@news20.bellglobal.com>   C "Guy Peleg" <guy.peleg@remove_this_header@hp.com> wrote in message  $ news:444d262e@usenet01.boi.hp.com...< > If I could make your BACKUP operations complete faster.... >...   Yes.     ------------------------------  + Date: Tue, 25 Apr 2006 00:58:44 +0000 (UTC) - From: Michael Savage <mike@_remove_savage.ca> " Subject: Re: hypothetical questionA Message-ID: <7e22e3b91200f8c835f901f18efc@news.mountaincable.net>    Yes.  F > If I could make your BACKUP operations complete faster.... 2-5 timesD > faster....but restrict this feature for save-sets written to disksH > only (not to support it with save-sets written to tapes).....would you > find it useful?  > # > I'm looking for yes/no answer....  > ) > Please do not ask for more details..... 3 > Please do not speculate.....it will be clear soon = > I'm unable to provide any further information at this point  > 
 > Thank you !  >  > Guy Peleg  > OpenVMS Engineering C > (Please do not re-post this in any other forum, I chose c.o.v. on 
 > purpose) >    ------------------------------  % Date: Mon, 24 Apr 2006 20:43:04 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>" Subject: Re: hypothetical question6 Message-ID: <444D7EA8.B57EACBB@NeOaSrPtAhMlNiOnWk.net>   Guy Peleg wrote: > < > If I could make your BACKUP operations complete faster....= > 2-5 times faster....but restrict this feature for save-sets 9 > written to disks only (not to support it with save-sets 1 > written to tapes).....would you find it useful?  > # > I'm looking for yes/no answer....    I'd have to say yes and no.   E No, because in our production backups, savesets are rarely written to A disk. For database backups, we've been using what's known as "hot H backup" which uses BACKUP instead of COPY (why? your guess is as good asE any) to transfer files, not create savesets. That goes away when BCVs  are implemented in two weeks.   H Yes, for those occasions - typically NOT production - where savesets are" written to disks MOUNTed FILES-11.  E What we would REALLY need is a TREMENDOUS speed up where savesets are @ written to tape-emulating disk libraries, especially if it blows4 Legato's performance clear into the next hemisphere.   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------  # Date: Tue, 25 Apr 2006 01:48:32 GMT ) From: "John Vottero" <JVottero@mvpsi.com> " Subject: Re: hypothetical question< Message-ID: <Qdf3g.5589$Lm5.3938@newssvr12.news.prodigy.com>  C "Guy Peleg" <guy.peleg@remove_this_header@hp.com> wrote in message  $ news:444d262e@usenet01.boi.hp.com...< > If I could make your BACKUP operations complete faster....= > 2-5 times faster....but restrict this feature for save-sets 9 > written to disks only (not to support it with save-sets 1 > written to tapes).....would you find it useful?  > # > I'm looking for yes/no answer....  >   9 Yes.  All of our backups already go to save-sets on disk.    ------------------------------  % Date: Tue, 25 Apr 2006 06:43:38 +0300 7 From: "Guy Peleg" <guy.peleg@remove_this_header@hp.com> " Subject: Re: hypothetical question* Message-ID: <444d9aee@usenet01.boi.hp.com>  B "Guy Peleg" <guy.peleg@remove_this_header@hp.com> wrote in message$ news:444d262e@usenet01.boi.hp.com...< > If I could make your BACKUP operations complete faster....= > 2-5 times faster....but restrict this feature for save-sets 9 > written to disks only (not to support it with save-sets 1 > written to tapes).....would you find it useful?  > # > I'm looking for yes/no answer....  > ) > Please do not ask for more details..... 3 > Please do not speculate.....it will be clear soon  > = > I'm unable to provide any further information at this point  > 
 > Thank you !  >  > Guy Peleg  > OpenVMS Engineering  > L > (Please do not re-post this in any other forum, I chose c.o.v. on purpose) >  >    Thank you for the feedback !!!  , Sorry for being cryptic....more details soon   Guy    ------------------------------  % Date: Mon, 24 Apr 2006 23:47:05 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> " Subject: Re: hypothetical question, Message-ID: <444D9BB8.7423A4A2@teksavvy.com>   Guy Peleg wrote:    > Thank you for the feedback !!! > . > Sorry for being cryptic....more details soon  E Would you have achieved the same goal if you had asked if users would 3 like a program to generate winning lottery numbers?   B i.e. was the goal of sending this only to c.o.v. to gauge how many responses you would have ?   ------------------------------  % Date: Mon, 24 Apr 2006 21:05:30 -0700 ( From: Jeff Cameron <roktsci@comcast.net>" Subject: Re: hypothetical question0 Message-ID: <C072EE1A.1E867%roktsci@comcast.net>   Yes.  H We stage our backups from other nodes to disk during off hours as to notD impact the network during business hours. We then migrate the backupG savesets to tape during the course of the day and sometimes through the 7 following evening. This would improve my backup window.   I On 4/24/06 12:25 PM, in article 444d262e@usenet01.boi.hp.com, "Guy Peleg" , <guy.peleg@remove_this_header@hp.com> wrote:  < > If I could make your BACKUP operations complete faster....= > 2-5 times faster....but restrict this feature for save-sets 9 > written to disks only (not to support it with save-sets 1 > written to tapes).....would you find it useful?  > # > I'm looking for yes/no answer....  > ) > Please do not ask for more details..... 3 > Please do not speculate.....it will be clear soon  > = > I'm unable to provide any further information at this point  > 
 > Thank you !  >  > Guy Peleg  > OpenVMS Engineering  > L > (Please do not re-post this in any other forum, I chose c.o.v. on purpose) >  >    ------------------------------  % Date: Tue, 25 Apr 2006 00:37:03 -0400 ' From: Dave Froble <davef@tsoft-inc.com> " Subject: Re: hypothetical question/ Message-ID: <H4idnUWqcNQzO9DZRVn-tw@libcom.com>    Guy Peleg wrote:< > If I could make your BACKUP operations complete faster....= > 2-5 times faster....but restrict this feature for save-sets 9 > written to disks only (not to support it with save-sets 1 > written to tapes).....would you find it useful?  > # > I'm looking for yes/no answer....  > ) > Please do not ask for more details..... 3 > Please do not speculate.....it will be clear soon  > = > I'm unable to provide any further information at this point  > 
 > Thank you !  >  > Guy Peleg  > OpenVMS Engineering  > L > (Please do not re-post this in any other forum, I chose c.o.v. on purpose) >  >    The answer is always 'Yes'.   I However, you didn't say anything about the location of the disks.  Maybe  H with some of the newer FC stuff it isn't an issue.  I'm backing up over H an Ethernet network to disks on another system.  Would such be affected?   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Tue, 25 Apr 2006 11:23:21 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> 4 Subject: Re: IMCB$V_PARENT_PROT What is it good for?1 Message-ID: <e2k4lg$ord$1@news-02.connect.com.au>    Hi Ian  F > what I posted was a direct quote.  What it means I know not. Back to > reading the source code.  K I was being facetious and probably should've put a smiley at then end. What L I sought to proffer were not questions but rather accusations held, like hot. pokers, to the bleeding eyes of my detractors.  K The indictment is this, if it is simply illegal, unsupported and sufficient G to open Pandora's box of VMS security vulnerabilities, to call out from J inner-mode to "shareable images activated subsequently" then what the hellH is the IMCB$V_PARENT_PROT good for? Why is it legal to drop the /PROTECTE qualifier on a UWSS Link in the first place? Why does LIB$GET_VM_PAGE I enforce PSL$C_USER in a call to $EXPREG when it can *only* be called from I user mode? Why does SYS$PERSONA_CREATE in (in a run o' the mill shareable G image such as SECURESHR.EXE) *beseech (nay enforce!) you* to call it in G KERNEL mode if you specify the USRPROfile argument on the one hand, yet K blatantly call LIB$GET_VM when it wants a few bytes of memory on the other? L Why do I have to go through life preparing the case for the prosecution? AreD we not all adults? Can we not all simply discuss the science and theL immutable *facts* behind the VMS Security Model and how it pertains to image activation?   J If the VMS Security Model is, in fact, "flat" then why do I always see the- top of the ships' masts on the horizon first?   I Maybe the world did go down hill when they taught us stinking peasants to L read, but we're fucking here now so let's put an end to this bullshit WizardI of Oz routine! I could probably benefit greatly from a heart, courage and L definitely a brain, but in the meantime let's just have the *facts*! Show meH *AANN EEXXAAMMPPLLEE* of a security flaw produced by calling a shareableC from inner-mode and I will show you why the USRPRO argument must be H desupported for SYS$PERSONA_CREATE. (Or are we now really competing with	 Windows?)    Cheers Richard Maher  J PS. "Ooooh there be Dragons - The great Oz is displeased with you (thunderI lightening) Leave immediately or you will perish (lots of noise) Wardrobe 
 monsters".   ----- Original Message -----    From: "Ian Miller" <ijm@uk2.net> Newsgroups: comp.os.vms & Sent: Tuesday, April 18, 2006 11:58 PM4 Subject: Re: IMCB$V_PARENT_PROT What is it good for?    F > what I posted was a direct quote.  What it means I know not. Back to > reading the source code. >   > "Richard Maher" <maher_rj@hotspamnotmail.com> wrote in message+ news:e22ulj$fp7$1@news-02.connect.com.au... 	 > Hi Ian,  >  > (But before I go :-) > 5 > > which is propagated to shareable images activated  > > subsequently > I > That simply cannot be! Wash your mouth out. What you are alluding to is * > clearly a pointless piece of redundancy. >  > Cheers Richard Maher > - > "Ian Miller" <ijm@uk2.net> wrote in message ? > news:1145368839.130610.223730@i40g2000cwc.googlegroups.com...  > > It says E > > "If either IAC$V_PARANOID or IAC$V_PROTECTED was specified in the K > > FLAGS argument, the image activator checks that the image was installed K > > and, if not, returns the error status SS$_PRIVINSTALL to its requestor.  > > IfJ > > IAC$V_PROTECTED was specified, the image must also have been installedJ > > /PROTECTED. If the image passes these checks, the image activator setsI > > IMCB$V_PARENT_PROT, which is propagated to shareable images activated B > > subsequently to ensure that similar checks are made for them." > >  >  >  >    ------------------------------  # Date: Tue, 25 Apr 2006 04:07:47 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>4 Subject: Re: IMCB$V_PARENT_PROT What is it good for?2 Message-ID: <ngh3g.6783$tG7.5011@news.cpqcorp.net>  D    Against my better judgment, I've provided someone claiming to be H Richard (or Richard) with an example of how security is broken within a ) UWSS image constructed the way he posits.   E    I will not provide that example here, as I have enough work to do  6 without giving the script kiddies more to think about.  G    I've also suggested (to Richard or someone claiming to be him) that  G OpenVMS itself need not follow its own rules for support; that OpenVMS  D itself contains constructs and mechanisms and calls that are not or I would not be supported for use within application programs.  I certainly  H make heavy use of a number of APIs that I wrote and that I also hold as F undocumented, for instance -- BACKUP is also using one of these newer D APIs, too.  (I've discussed a few of these undocumented APIs at the @ bootcamp, and have several pages in the presentations on these.)  G    I have occasionally offered what amounts to an application security  G class at various (restricted) events, though it has tended to cause me  I various problems because it is basically also a how-to class for hacking   into OpenVMS.  Obviously.    ------------------------------  % Date: Mon, 24 Apr 2006 18:14:33 -0700 # From: "Tom Linden" <tom@kednos.com>  Subject: Intel VPro ) Message-ID: <op.s8jhqjiyzgicya@hyrrokkin>   J What is it?  Didn't they previously talk about virtualization wrt Itanium?C This is somehow supposed to make PC's more secure.  Googling didn't  reveal much.   ------------------------------  % Date: Mon, 24 Apr 2006 22:22:38 -0400 ( From: Bill Todd <billtodd@metrocast.net> Subject: Re: Intel VPro G Message-ID: <29WdnV3LQOFIGtDZnZ2dnUVZ_sCdnZ2d@metrocastcablevision.com>    Tom Linden wrote: L > What is it?  Didn't they previously talk about virtualization wrt Itanium?E > This is somehow supposed to make PC's more secure.  Googling didn't  > reveal much.  % http://theinquirer.net/?article=31221    ------------------------------  % Date: Mon, 24 Apr 2006 20:04:15 -0700 # From: "Tom Linden" <tom@kednos.com>  Subject: Re: Intel VPro ) Message-ID: <op.s8jmtdsxzgicya@hyrrokkin>   H On Mon, 24 Apr 2006 19:22:38 -0700, Bill Todd <billtodd@metrocast.net>   wrote:   > Tom Linden wrote: F >> What is it?  Didn't they previously talk about virtualization wrt   >> Itanium? F >> This is somehow supposed to make PC's more secure.  Googling didn't >> reveal much.  > ' > http://theinquirer.net/?article=31221      I am still clueless.   ------------------------------  % Date: Mon, 24 Apr 2006 20:53:23 -0700 # From: "Tom Linden" <tom@kednos.com>  Subject: Re: Intel VPro ) Message-ID: <op.s8jo29u4zgicya@hyrrokkin>   ? On Mon, 24 Apr 2006 20:49:29 -0700, <heestand@gmail.com> wrote:   G > Seems from the website www.intel.com/vpro that its dual core with AMT G > and virtualization for desktop PCs. Like Centrino and Viiv it's a set E > of technologies bundled together under a single brand name.  So its I > more than a processor.   As far as I know this cannot be supported with E > current Intel products like the Pentium D processor.  The claim for E > Energy efficient performance rules out a version of Itanium for the E > desktop.   When you add it all up there is definately something new  > here.  >  > -Doug Heestand > http://vitalnetworks.com > ?   still don't see the connection to inceased security for PC's.    ------------------------------  % Date: Mon, 24 Apr 2006 23:37:10 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>  Subject: Re: Intel VPro , Message-ID: <444D9966.2C5C7572@teksavvy.com>   Tom Linden wrote: ) > > http://theinquirer.net/?article=31221  >  >   I am still clueless.  e http://news.com.com/Intel+picks+VPro+for+business+desktop+brand/2100-1006_3-6064267.html?tag=nefd.top   G It is mostly marketing fluff. Like "Centrino" which is a package of low C power CPU with wi-fi/mobile computing chips. This one is a CPU with Y chips that allow remote management and multiple instances of OS rto run (virtualisation).    ------------------------------    Date: 24 Apr 2006 20:49:29 -0700 From: heestand@gmail.com Subject: Re: Intel VPro C Message-ID: <1145936969.044071.250670@i40g2000cwc.googlegroups.com>   E Seems from the website www.intel.com/vpro that its dual core with AMT E and virtualization for desktop PCs. Like Centrino and Viiv it's a set C of technologies bundled together under a single brand name.  So its G more than a processor.   As far as I know this cannot be supported with C current Intel products like the Pentium D processor.  The claim for C Energy efficient performance rules out a version of Itanium for the C desktop.   When you add it all up there is definately something new  here.    -Doug Heestand http://vitalnetworks.com   ------------------------------  % Date: Tue, 25 Apr 2006 00:03:19 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com>  Subject: Re: Intel VPro , Message-ID: <444D9F85.B6C85843@teksavvy.com>   Tom Linden wrote: A >   still don't see the connection to inceased security for PC's.   E You can run the firewall to protect Windows as a separate OS instance H instead of the ridiculous application that runs on Windows that pretends  to act as a firewall for itself.   ------------------------------  # Date: Tue, 25 Apr 2006 04:16:55 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com> Subject: Re: Intel VPro 2 Message-ID: <Xoh3g.6785$_t7.4694@news.cpqcorp.net>   Tom Linden wrote: A > On Mon, 24 Apr 2006 20:49:29 -0700, <heestand@gmail.com> wrote:  > / >> Seems from the website www.intel.com/vpro... @ >  still don't see the connection to inceased security for PC's.  H    I know nothing about the Intel vPro package other than what little I I have seen published, but I would also poke around for discussions of the  ? nVIDIA ActiveArmour implementation, and would look also at the  F management processors cards that are for the Integrity servers.  From A what little I have read of vPro, it reminds me of these packages.    ------------------------------  % Date: Mon, 24 Apr 2006 14:23:29 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> 7 Subject: RE: Opinion: I was just trying to sell OpenVMS T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401300D09@tayexc19.americas.cpqcorp.net>   > -----Original Message-----7 > From: Andrew [mailto:andrew_harrison@symantec.com]=20  > Sent: April 24, 2006 11:59 AM  > To: Info-VAX@Mvb.Saic.Com 9 > Subject: Re: Opinion: I was just trying to sell OpenVMS  >=20 >=20  	 [snip ..]    > > > . > > > > Check out IDX / OpenVMS references at:G > > > > http://h71000.www7.hp.com/success-stories.html (also has Cerner  > > > > references as well)  > > > >  > > > E > > > Not wanting to rain on your parade but only one of the customer D > > > references on this web page are from 2006 (Dartmouth College). > > >  > > B > > Of course you want to rain on parades .. That's what you do=20 > so well...- > > Unless of course, it is a Solaris parade.  > >  > > :-)  > > : > > > One from 2005 and the rest from 2004-2003-2002-2001. > > > ; > > > All appear to be upgrades or renewed investment in=20  > OpenVMS none appear  > > > to new buiness.  > > >  > > = > > The thread I replied to was looking for a few examples=20  > where OpenVMS was  > > used in healthcare.  > > ) > > That's what these references provide.  > > ; > > Heck, you could also look at the following USD $784M=20  > announcement from / > > VA Hospitals as well (2004 - 10 year deal). = > > http://www.hp.com/hpinfo/newsroom/press/2004/040324a.html  >=20H > Not wanting to rain further on your parade, oh well it soaking and all7 > the revelers have gone home long ago so what the hec.  >=20< > Your posting makes it seem as if this is a $784 million=20 > OpenVMS sucess, ? > of course it isn't ist a services and maintence deal which=20  > does includeD > OpenVMS but also includes all the other platforms that the VA use. >=20  > Boy, looks like that reference really caused you to twitch eh?  H Of course there are other technologies involved in the overall solution,D but fwiw, OpenVMS is the only referenced OS in the HP press release.  G Again, the original poster was looking for examples of where OpenVMS is  used in healthcare.  =20 G Is this release not yet another example or am I missing something here?     9 > In addition the press release inbcludes this little gem  >=20F > "The VA's teamwork, combined with HP's Adaptive Enterprise strategy,G > has resulted in VistA being recognized as one of the premier hospital $ > information systems in the world." >=20H > Laugh, I nearly fell off my chair, this is an OpenVMS reference isn't,> > so what on earth is Adaptive Enterprise doing lurking in it. >=20  G IBM has "On Demand". Gartner calles it "Real Time Infrastructure". Meta 1 Group wrote a few books on "Adaptive Enterprise". " HP calls it "Adaptive Enterprise".  H Bottom line is that it is an overall strategy based on people, processesD and technology to better integrate the IT environment and OpenVMS is certainly a part of this.    And what does Sun call this?=20   H Not sure, but from looking at their web site, it looks like a technologyA only focus of grid computing(?), but Andrew - please feel free to % elaborate on and expand on this area.    Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------  # Date: Tue, 25 Apr 2006 05:25:46 GMT L From: winston@SSRL.SLAC.STANFORD.EDU (Alan Winston - SSRL Central Computing)7 Subject: Re: Opinion: I was just trying to sell OpenVMS 6 Message-ID: <00A54B76.7F229183@SSRL.SLAC.STANFORD.EDU>  V In article <4b48chFvcdicU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:U >In article <FA60F2C4B72A584DBFC6091F6A2B868401300B3B@tayexc19.americas.cpqcorp.net>, + >	"Main, Kerry" <Kerry.Main@hp.com> writes:  >>  I >> Heck, you could also look at the following USD $784M announcement from . >> VA Hospitals as well (2004 - 10 year deal).< >> http://www.hp.com/hpinfo/newsroom/press/2004/040324a.html > I >Even a blind hog finds an acorn once in a while!!  I would certainly not 6 >present the VA as a paragon of management excellence.  L Interesting.  In the nationalized healthcare discussion, the VA _is_ gettingJ presented as a paragon of management excellence, at least in terms of highM ratio of high-quality care delivered to relatively low cost, and to early and 8 enthusiastic adoption of medical recordkeeping software.  : (I don't claim any direct knowledge of any of this stuff.)   -- Alan    ------------------------------  % Date: Mon, 24 Apr 2006 23:52:19 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> . Subject: OT: Scott McNeily steps down from SUN, Message-ID: <444D9CF2.811AB634@teksavvy.com>  E In case you had not heard Scott McNealey has announced he is stepping E down as CEO, remaining as chairman of the board. Jonathan Swartz taks  his spot as CEO.    M http://news.com.com/McNealy+steps+down+at+Sun/2100-1014_3-6064499.html?tag=nl     G Does this increase the chances that SUN might rescue VMS from HP ?  :-)      You might also wish to read:  a http://news.com.com/Say+what+A+look+back+at+McNealy+zingers/2100-1014_3-6064563.html?tag=nefd.top   D This guys has more respect than Carly ever had.  I may disagree withD some of hos opinions, but I respect a guy who is willing to stand up( agianst Microsoft to defend his company.   ------------------------------    Date: 24 Apr 2006 13:16:25 -0500+ From: young_r@encompasserve.org (Rob Young) # Subject: Re: OT: Sparc not dead yet 3 Message-ID: <yZoxij5kAZ1s@eisner.encompasserve.org>   \ In article <444B334B.4B169DD7@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > Rob Young wrote:+ >>         Just what are you talking about?  >>  E >>         3Q 2005 compared to 3Q 2004.  When do you suppose the .com  >>         blip was?   >  >  > My question stands.    	Stands where?  6 >   Since 2001, the numbers may have gone down at Sun,J > but one needs to compare it to the levels prior to the .com anomaly.  ToH > me, what I wantto know is whether Sun's market share is higher than it > was in 1995 or lower.   C 	Why not go back to 1986 and compare?  I'm sure that still wouldn't , 	make sense, but at least someone could say:  ; 	"Look, Sun has greater marketshare than they did when they  	first started!"   	And the point would be...????  I > Or put it in another way: has Sun fully eroded the gains it made during 9 > the .com boom, or is there still more room to go down ?   B 	Of course, they aren't out of business yet.  My overarching pointA 	is compared to others, Sun is going in the wrong direction.  The & 	paradigm is shifting, they missed it.   				Rob    ------------------------------    Date: 24 Apr 2006 11:36:53 -0700C From: "AlexNOSPAMDaniels@themail.co.uk" <alexdaniels@themail.co.uk> # Subject: Re: OT: Sparc not dead yet C Message-ID: <1145903812.945716.230940@j33g2000cwa.googlegroups.com>   . "Andrew" <andrew_harrison@symantec.com> wrote: > bob@instantwhip.com wrote:G >> OpenVMS meets those requirements so why run garbage aix and slowaris  >>H > Actually it doesn't if a CPU fails on an OpenVMS box then the box will3 > always reboot, that is not the case with Solaris.  <SNIP>  D VMS will not "always reboot" if a CPU fails, if CPU 0 fails sure VMS will crash, any other CPU no.   > I struggle to think of a SMP Alpha where this is not the case.  G Also on a number of Alpha's it's possible to hot-swap failed CPUs, I've > had that done a number of times, in the production day, with a production workload going on.   D http://h18002.www1.hp.com/alphaserver/download/ek-gshpg-rm-b01.pdf -G Details the hot swap proceedure on GS160/320's, see section 2.3 for the  VMS specifics.   Alex   ------------------------------  % Date: Mon, 24 Apr 2006 15:13:42 -0400 - From: JF Mezei <jfmezei.spamnot@tekksavy.com> # Subject: Re: OT: Sparc not dead yet , Message-ID: <444D2363.AB026615@tekksavy.com>   Rob Young wrote:K >         Of course, they aren't out of business yet.  My overarching point J >         is compared to others, Sun is going in the wrong direction.  The/ >         paradigm is shifting, they missed it.   D There are two main issues here. The .COM blip , and paradigm change.  F In terms of the .com blip, I'll use a similar example that happened at about the same time.  A During the last 1990s, Bombardier/Canadair became the world's 3rd E largest aircraft manufacturer by spitting out flying skidoos (50 seat H regional jets) by the dozen. Orders were so large that the ship hired toD transport fuselage sectiosn from Ireland to Montreal didn't have theE capacity, so Bombardier hired the large Antonov 124 jets to carry the D extra fuselage sections to Montreal on a regular basis. Airlines hadB gone nuts ordering that jet which analysts had said would save theB airline industry. (This is very silimar to Sun being the "defacto"$ server for internet .com companies).  E Comes 9-11. Boeing and Airbus announce on 9-12 that they expect a big D downturn. Boeing fires 30,000 poeple, Airbus cancels plans it had toH hire extra 30,000 people. Bombardier ignores the situation and forges atH full steam ahead saying it hadn't received any cancellations. (Note: SunF has also been accused of not taking drastic actions right at the onsetC of the .com bust). This came back to bit hard, a couple years later G Bombardier was nearly bankrupt and not only did it fire top management, D but also had to sell off its recreational vehicles to raise money to" keep the aerospace division alive.    F Today, not only has production of the CRJ gone from over 130 a year toG ZERO per year, but there is a glut of CRJs ready to be purchased and it B will take years for this surplus of aircraft to be absorbed by the; airline industry that is still getting rid of extra planes.   G So Bombardier is still suffering from the overproduction it did in late A 1990s and 2000/2001. But wait ! it gets worse: now, analysts have E decided it was that jet that killed Independance air, since 50 seater E jets are inherently less efficient than larger jets. (something those H people didn't say during the .CRJ boom even though the economics are theG same, except that now, mainline pilts having agreed to concessions, the 0 costs of operating larger planes has gone down).G So there is a paradigm shift going on, at the same time that Bombardier J is stuck with a glut because airlines ordered way too many flying skidoos.    D At this point in time, it is hard to say whether the CRJ200 is dead,D whether sales will eventually pickup again once the surplus has beenA absorbed and once US airlines start to buy planes again. And what G happens in 15 years when the current flying skidoos become old and need  to be replaced ?  H I think the same can be said of Sun. Lots of companies installed tons ofF computing capacity, and this may continue to meet their needs and theyD may not require product replacement for some time to come. So Sun is? still suffering from overproduction during .COM boom, just like E Bombardier is now suffering from overproduction during the .CRJ boom.   E Eventually though, customers who bought lots of stuff a few years ago C will need product replacements. And it is at that time that we will ; really see if they stay with Sun or move to something else.   A Sun may have been late in acknowledging the .COM bust, but unlike F Bombardier, it has taken actiosn to make its product more interesting,G especially in light of Linux competition. And it si still forging ahead & with new Sparcs to remain compatitive.  C Bombardier cancelled its project for a 100 seat aircraft because it B didn't have the money nor customers to help launch it. Embraer wasH already on the market with a 100 seat aircraft and had that small marketG all sewed up. The consequences tuough is that when the marker starts to B grow again, Bombardier won't have a product to sell, Embraer will.  F In the case of Sun, because they are still developping Sparc, when itsM glut is gone and customers start to buy again, Sun will still be in the game.    ------------------------------  % Date: Mon, 24 Apr 2006 15:39:10 -0400 - From: JF Mezei <jfmezei.spamnot@tekksavy.com> # Subject: Re: OT: Sparc not dead yet , Message-ID: <444D2959.AE828B09@tekksavy.com>  + Another point: you need to look at history.   G In the 1960s, only large corporations could afford computers. With ever B major step in the computing industry, a new breed of company couldE afford to use computers. Each step opened a brand new market and grew  the computer marketplace.   ? After a market was filled, total growth would be slow, but each C manufacturer could steal customers from others. Sun's growth during 2 1980s came at the expense of Digital for instance.  > During the .COM boom, Sun got a large share of the of internetD appliances.  It was a new market and Sun didn't steal customers fromE others, it got new ones (like blue chip companies as well as volatile ! .com companies without a future).   B But now, that market has matured and is without significant growthF overall. Being the biggest player in that market, Sun  has the most to= lose from competition, just as DEC lost to others in the late  1980s/early 1990s.  H However, what is different from DEC's actiosn at the top of its heydays,C SUN is taking fairly drastic actions to remain competitive, such as G offering Solaris for free. Is it enough ? I don't know. But it seems to 6 me that Sun is taking its competition very seriously.   @ Under Palmer, DEC simply capitulated to the competition and madeG sacrificial peace offerings to the competition. Sun isn't giving itself H to a competitor, it is trying to give itself to the open sorce community* so that no single comopetitor can benefit.  D Right now, all markets are fairly well served/saturated. And for theC foreseable future, the computer industry will be rather boring with D companies trying to steal customers from each other, but with no newB major "boom", except perhaps when Microsoft introduces 64-bit onlyC software that will require a major Wintel product replacement cycle 5 (similar to 1995 for windows 95 and in 1999 for Y2K).   > If there is a paradigm shift towards Linux, then SUN is betterF positioned than HP or IBM to counter it. This is especially true of HPG because the software portfolios of HP-UX and VMS are being slimmed down = considerablty due to the forced migration to that IA64 thing.   D Of course, because HP operates in many different markets, it is muchF easier for it to hide bad financials from one division. That isn't theF case for Sun.  Remember that HP's BCS hasn't exactly done that well in recent years either.  H The biggest mistake anyone can make is to write Sun off. Underestimating your competition is very wrong.    ------------------------------  % Date: Mon, 24 Apr 2006 16:02:19 -0400 - From: JF Mezei <jfmezei.spamnot@tekksavy.com> # Subject: Re: OT: Sparc not dead yet , Message-ID: <444D2EC5.2284E40F@tekksavy.com>   Bill Todd wrote:I > I'm rooting for it, because I believe that diversity and competition in G > the industry are good things.  But I rate its chances for survival at D > about the same level as Itanic's:  not great (with probably *very*D > little likelihood of anything resembling industry domination), butG > certainly not zero either (as long as they don't seriously screw up).   G Sparc's large installed base is likely to carry it further in time than  IA64's tiny installed base.   H 8086 isn't yet ready to take on the largest machines. And until it does,0 Sun is right in pursuing its legacy chip (Sparc) to its fullest extent.  H HP has killed its legacy chips (Pa-Risc and Alpha) and is now stuck withH a dud IA64 thing without market traction nor a large installed base. AndC remember that IA64 covers only a subset of markets that Pa-Risc and 1 Alpha had, so not all customers can move to IA64.   F Sun on the other hand has one hand in its Sparc whose long term futureF is uncertain, and one hand in the 8086 whose future is not questioned.G HP has one hand in Alpha/Pa-Risc which have been murdered, and one hand H in that IA64 thing whose future is very uncertain in the medium term. SoC Sun customers are much more comfortable with the setup knowing that 9 either way, Solaris can survive and is not a dead end OS.   C Until HP makes public commitments on paper that it fully intends to D migrate all its OS from IA64 to something else ocne IA64 is declaredG dead, then uncertainty about the future of the 3 OSs that depend solely  on IA64 remains.   ------------------------------    Date: 24 Apr 2006 13:42:24 -0700C From: "AlexNOSPAMDaniels@themail.co.uk" <alexdaniels@themail.co.uk> # Subject: Re: OT: Sparc not dead yet C Message-ID: <1145911344.167679.152900@j33g2000cwa.googlegroups.com>    FredK wrote:H > "AlexNOSPAMDaniels@themail.co.uk" <alexdaniels@themail.co.uk> wrote inG > message news:1145903812.945716.230940@j33g2000cwa.googlegroups.com... 2 > > "Andrew" <andrew_harrison@symantec.com> wrote:  > > > bob@instantwhip.com wrote:K > > >> OpenVMS meets those requirements so why run garbage aix and slowaris  > > >>L > > > Actually it doesn't if a CPU fails on an OpenVMS box then the box will7 > > > always reboot, that is not the case with Solaris. 
 > > <SNIP> > > H > > VMS will not "always reboot" if a CPU fails, if CPU 0 fails sure VMS! > > will crash, any other CPU no.  > > B > > I struggle to think of a SMP Alpha where this is not the case. > > K > > Also on a number of Alpha's it's possible to hot-swap failed CPUs, I've B > > had that done a number of times, in the production day, with a! > > production workload going on.  > >  > ; > I'm struggling to understand the context of the comments.   # Mine, Andrew's or both? (or Bob's?)    >  On pretty much M > any SMP architecture - except perhaps a non-stop system running in lockstep K > (and NSK is *not* SMP) - the only CPU failure modes that can safely allow K > the system (or hard partition) to continue running safely are things like N > excessive correctable b-cache errors.  That is, a *hard* failure of a CPU orL > even a thread (in a threaded CPU) can leave the system in an unpredictableA > state.  This is true for any CPU in the system, not just CPU 0.    Sure.   J > If a CPU is having a high number of correctable errors, we have software; > that can detect it and remove the CPU from the active set    WEBES and maybe DECevent too.    >- except for the N > primary CPU (normally CPU 0 -- we have not done the work to switch primaries > on the fly).  D I understand future Integrity machines will support raiding of CPUs,+ this should alievate this specific problem.   ; I also wouldn't expect VAXft's to suffer from that problem.   A >  Of course - hard *and* soft CPU (excessive correctable errors)  > failures are very rare.   G Depends on the specific AlphaServer platform, if any comets are passing D by, if the latest firmware release is screwed, all manner of things.  G I would suggest with a couple of specific AlphaServer platforms is that 1 CPU failures (hard or soft), are not "very rare".   F Or maybe in terms of soft-errors we just get a lot of comets and freakF bad luck that hits in the two exact spots to turn single-bit errors in3 doubles around here, or repeating on the same spot.   6 >  I believe there is firmware that will prevent a CPUF > that has been flagged as failed from starting up on the next reboot.  A Didn't know that, on which AlphaServers? Even if the breakers are @ switched? Even if I rewrite the FRU table and sys_serial_number?  L > Automatic reboot is a firmware setting, you can also choose to simply stay > halted in the firmware. L > Hot swapping a CPU is possible on some Alpha platforms - but every time weI > ask customers if they would use it - they tell us that they would never M > allow a system component like a CPU or an IO controller to be yanked during L > production.  They would schedule controller/CPU swaps during a maintenance >   C I've let HP hot-swap CPUs prior and that was at two different banks ? running mission critical systems (albeit in clusters which were C active-active and I could take a failure), although I've also heard A your same comment from other people in HP, so maybe it's just me.   B I can certainly put you in touch with the on-site mission criticalB engineer who's done hot-swaps for me if you like, mail me offline.  9 >In my experience - CPU/Memory/IO controller failures are M > typically catestrophic failures (non-recoverable) and usually happen when a K > system is first started, and rarely occur after a system has been running  > for some period of time.  > I certainly wouldn't say "rarely" on some specific AlphaServer
 platforms.  1 >Software failures are a much higher probability.    Agreed.   D > To be honest - hot-swap IO/CPU/Memory is mostly marketing gimmick.  B Probably, but my experience of HP hot-swapping CPUs is that it has. never failed or brought the whole system down.  G It's a shame that while some AlphaServer platforms support hot-swapping  PCI cards, VMS doesn't.    >  TheirM > failures are rare - and usually not soft-detectable (non-catestrophic).  It J > is external devices - like cables and disks that are more likely to fail? > during operation - as someone trips over a cable for example.   C I would recommend people who have suffered from such to undertake a 7 machine room / cabling  review and apply best practice.   F However, in my experience CPU failures have been more of an issue than people triping over cables.    Alex   ------------------------------  % Date: Mon, 24 Apr 2006 17:08:09 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> # Subject: RE: OT: Sparc not dead yet T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B868401300DA2@tayexc19.americas.cpqcorp.net>   > -----Original Message-----* > From: AlexNOSPAMDaniels@themail.co.uk=20' > [mailto:alexdaniels@themail.co.uk]=20  > Sent: April 24, 2006 4:42 PM > To: Info-VAX@Mvb.Saic.Com % > Subject: Re: OT: Sparc not dead yet  >=20    	 [snip ..]     F > > To be honest - hot-swap IO/CPU/Memory is mostly marketing gimmick. >=20D > Probably, but my experience of HP hot-swapping CPUs is that it has0 > never failed or brought the whole system down. >=20? > It's a shame that while some AlphaServer platforms support=20  > hot-swapping > PCI cards, VMS doesn't.  >=20  G If you have an active-active OpenVMS cluster with a DLM managing access C to cluster files and print/batch jobs, then you can schedule entire D systems to be brought down for proactive maint and/or upgrades - all0 with zero impact on application availability.=20  H Simply set a flag at the OS level which causes all new connections to goG to other servers and when all current connections have finished on that B one server, simply shut the server down for the planned fix and/orG upgrade. When the server reboots, it again starts taking its connection @ and processing loads. [Batch jobs need to be considered as well]  G If you have this capability, local HW hot-swapping becomes much less of D an issue. Especially if FC/NIC adapters are implemented with teamingF design. If one adapter fails, simply schedule a time for the system toE be taken down and have it replaced. Since you do not need to tell end 2 users about this server going, they will not care.     Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  4 OpenVMS - the secure, multi-site OS that just works.   ------------------------------    Date: 24 Apr 2006 14:34:57 -0700C From: "AlexNOSPAMDaniels@themail.co.uk" <alexdaniels@themail.co.uk> # Subject: Re: OT: Sparc not dead yet C Message-ID: <1145914497.184753.279070@e56g2000cwe.googlegroups.com>    Main, Kerry wrote:  I > If you have an active-active OpenVMS cluster with a DLM managing access E > to cluster files and print/batch jobs, then you can schedule entire F > systems to be brought down for proactive maint and/or upgrades - all/ > with zero impact on application availability.  > J > Simply set a flag at the OS level which causes all new connections to goI > to other servers and when all current connections have finished on that D > one server, simply shut the server down for the planned fix and/orI > upgrade. When the server reboots, it again starts taking its connection B > and processing loads. [Batch jobs need to be considered as well]  E I've implimented Load Broker and supplimented it with LAN/IP failover # for more clusters than I can count.   D However you still need to wait for all the existing users to log offC and batch jobs to finish. Performance and/or availablity is reduced G during this time.Being able to hot-swap a PCI-X card, would be, I would  image, perferable.  I > If you have this capability, local HW hot-swapping becomes much less of F > an issue. Especially if FC/NIC adapters are implemented with teamingH > design. If one adapter fails, simply schedule a time for the system toG > be taken down and have it replaced. Since you do not need to tell end 4 > users about this server going, they will not care.  E Been working with peecee's lately? I didn't know the "teaming" phrase G had made it to VMS. I thought in terms of NICs we said LAN failover and  Failsafe IP?  C As I'm sure your aware FailSafe IP also gives you added performance F benfits for your outgoing traffic, if there in the same subnet. LosingC a card drops your performance. And yes the obvious workaround is to < deploy FailSafe on top of LAN Failover, with the added cost.  G FC cards same issue, you lose performance, possible path changes across  the cluster et al.  C So yes one can wait for the users/batch jobs to finish, then drop a F node, but it's not ideal and customers are left having to puchase more% hardware to mitigate for these times.    Alex   ------------------------------    Date: 24 Apr 2006 15:17:49 -0700C From: "AlexNOSPAMDaniels@themail.co.uk" <alexdaniels@themail.co.uk> # Subject: Re: OT: Sparc not dead yet C Message-ID: <1145917069.315714.125600@v46g2000cwv.googlegroups.com>    FredK wrote:N > "AlexNOSPAMDaniels@themail.co.uk" <alexNOSPAMdaniels@themail.co.uk> wrote inG > message news:1145911344.167679.152900@j33g2000cwa.googlegroups.com... H > > I understand future Integrity machines will support raiding of CPUs,/ > > this should alievate this specific problem.  > > J > I guess I need to research just how you "raid" CPUs - since they are allL > active components - unlike memory or disk.  Unless this is just to do with > CPU cache. >   F I can't say I know, but it was in a HP presentation, if you can't findD any more details internally, let me know and I'll have a dig around.  G It wasn't however just specific to the CPU cache, but actual raiding of  CPUs themselves.   > > E > > >  Of course - hard *and* soft CPU (excessive correctable errors)  > > > failures are very rare.  > > K > > Depends on the specific AlphaServer platform, if any comets are passing H > > by, if the latest firmware release is screwed, all manner of things. > >  > J > Put up some tinfoil ;-)  In any case, a multi-bit error on the bcache is > pretty much fatal.   I've thought about it ;)   > K > > I would suggest with a couple of specific AlphaServer platforms is that 5 > > CPU failures (hard or soft), are not "very rare".  > > J > > Or maybe in terms of soft-errors we just get a lot of comets and freakJ > > bad luck that hits in the two exact spots to turn single-bit errors in7 > > doubles around here, or repeating on the same spot.  > >  > I > Hmmm.  Which platforms?  I see hard errors mostly from CPU's within the N > first few hours of power on - after that - it is rare.  Can sunspot activityL > cause a multi-bit cache error?  Sure I suppose.  Of course the probability > isn't all *that* high.  E Wildfires mostly, at one customer site, across four Wildfires (at two A different locations) I had on average one CPU failure a month, at & least. Not my definition of very rare.  B I saw no corrolation to how recently the CPUs had been powered on.  : > > >  I believe there is firmware that will prevent a CPUJ > > > that has been flagged as failed from starting up on the next reboot. > > E > > Didn't know that, on which AlphaServers? Even if the breakers are D > > switched? Even if I rewrite the FRU table and sys_serial_number? > >  > M > I'm not doing platform support any more, and can't tell you what platforms. C > My guess is that it isn't persistent across flash memory changes.  >  > > G > > I've let HP hot-swap CPUs prior and that was at two different banks C > > running mission critical systems (albeit in clusters which were G > > active-active and I could take a failure), although I've also heard E > > your same comment from other people in HP, so maybe it's just me.  > > F > > I can certainly put you in touch with the on-site mission criticalF > > engineer who's done hot-swaps for me if you like, mail me offline. > >  > M > I didn't say it would not *work* - it will.  Just that pretty much everyone G > tends to never do it.  The most interest I have seen is hot inswap of  > additional CPUs.  ; I've less interest in that, as it's rarer and planned work.   D Although assuming there were slots free in the box, and the box onlyE supported hot inswap, you could a new one, and then remove the failed  one at a planned downtime.  = > > >In my experience - CPU/Memory/IO controller failures are J > > > typically catestrophic failures (non-recoverable) and usually happen > when aG > > > system is first started, and rarely occur after a system has been 	 > running  > > > for some period of time. > > B > > I certainly wouldn't say "rarely" on some specific AlphaServer > > platforms. > >  > N > The question is are they *recoverable* errors or catestrophic.  I don't knowN > what a recoverable disk controller error is - for example - disk error yes -N > but controller error no.  Usually controller failures manifest themselves as > machine checks.  >   D A single-bit error on memory on the controller. If you then start to! get repeats, time to swap it out.   K > Memory typically is protected by ECC.  But with large memory systems, and L > long up times - you can get failed memory.  Raid memory is one solution to > that.   B I could point out at least one place a on Wildfire, where there isD memory (not main memory obviously), that is not ECC protected, but a) failure there can take out the whole box.   H > > > To be honest - hot-swap IO/CPU/Memory is mostly marketing gimmick. > > F > > Probably, but my experience of HP hot-swapping CPUs is that it has2 > > never failed or brought the whole system down. > >  > 0 > Sure - because it wasn't a *hard* CPU failure. > K > > It's a shame that while some AlphaServer platforms support hot-swapping  > > PCI cards, VMS doesn't.  > >  > F > Again, while I think hot-add is a reasonable idea.  Even hot-upgradeI > perhaps.  We really don't get many requests for it.  It's a lot of work F > unless there is a demand for it - as opposed to a marketing feature.  F I suspect hot-upgrade/addition would be far easier to impliment in VMSF than hot-swap. Like with my point above on CPUs, the replacement couldC be added as an extra option, and the failed unit removed in planned 	 downtime.   E Hot-Swap would be nicer, but hot-inswap would pretty much address it,  assuming no lack of slots.   > > J > > However, in my experience CPU failures have been more of an issue than > > people triping over cables.  > >  > ( > Catestrophic?  Or soft (cache errors)?   Both.    Alex   ------------------------------  % Date: Mon, 24 Apr 2006 16:20:22 -0700 # From: "Tom Linden" <tom@kednos.com> # Subject: Re: OT: Sparc not dead yet ) Message-ID: <op.s8jcf8a5zgicya@hyrrokkin>   H On Mon, 24 Apr 2006 16:10:40 -0700, Bill Todd <billtodd@metrocast.net>   wrote:  I > Don't be silly.  Itanic's installed base isn't what will carry Itanic   F > anywhere:  Intel's (and HP's) level of commitment is, and with the  H > captive HP-UX (and to a far lesser extent Alpha) customer base (plus  I > SGI's as well, assuming that SGI survives and doesn't move largely to   L > Opteron and Xeon platforms) in tow they can doubtless carry Itanic along  L > as long as they're willing to spend time, money, and effort there rather   > than in more lucrative/  > productive areas.   I SGI's survival you may indeed question, but if they do survive, Itanium    will= not be part of the product spectrum.  This is not an opinion.    ------------------------------  % Date: Mon, 24 Apr 2006 19:10:40 -0400 ( From: Bill Todd <billtodd@metrocast.net># Subject: Re: OT: Sparc not dead yet = Message-ID: <lIednYc146pKx9DZRVn-pQ@metrocastcablevision.com>    JF Mezei wrote:  > Bill Todd wrote:J >> I'm rooting for it, because I believe that diversity and competition inH >> the industry are good things.  But I rate its chances for survival atE >> about the same level as Itanic's:  not great (with probably *very* E >> little likelihood of anything resembling industry domination), but H >> certainly not zero either (as long as they don't seriously screw up). > I > Sparc's large installed base is likely to carry it further in time than  > IA64's tiny installed base.   F Don't be silly.  Itanic's installed base isn't what will carry Itanic C anywhere:  Intel's (and HP's) level of commitment is, and with the  E captive HP-UX (and to a far lesser extent Alpha) customer base (plus  F SGI's as well, assuming that SGI survives and doesn't move largely to I Opteron and Xeon platforms) in tow they can doubtless carry Itanic along  I as long as they're willing to spend time, money, and effort there rather  ( than in more lucrative/productive areas.  F Without such supplier-push, Itanic would of course sink like a stone, E unlike SPARC (which has enough customer commitment behind it that it  < would likely survive for quite a while even if Sun did not).   - bill   ------------------------------    Date: 24 Apr 2006 16:43:56 -0700C From: "AlexNOSPAMDaniels@themail.co.uk" <alexdaniels@themail.co.uk> # Subject: Re: OT: Sparc not dead yet C Message-ID: <1145922236.176568.226750@i39g2000cwa.googlegroups.com>   5 "FredK" <fred.nospam@nospam.dec.com> wrote in message & news:444d5612$1@usenet01.boi.hp.com...M > Correctable errors on memory and CPU bcache yes.  Maybe it's been a while - L > but I don't recall any IO adapters that report correctable errors on theirM > internal memory to the host - or any other controller-internal soft failure  > for that matter.  @ Is controller internal soft error reporting that not part of the PCI-Express spec?   < http://www.intel.com/technology/magazine/systems/it04031.pdf	 (Page 6.)   D And PCI-Express is slated to be in Integrity boxes that support VMS,8 with Montecito (out later this quarter or next, I hope).  g http://h71000.www7.hp.com/presentations/openvms_customer_conference_emea/Server_roadmap_performance.pdf    Page 16    Alex   ------------------------------    Date: 24 Apr 2006 17:10:52 -0700 From: bob@instantwhip.com # Subject: Re: OT: Sparc not dead yet C Message-ID: <1145923852.957935.198690@g10g2000cwb.googlegroups.com>    Bill Todd wrote: > J > You might enjoy learning how z-series mainframes handle this, then.  zOSJ > has extensive recovery facilities even for such hard CPU errors, withoutI > operating in lock-step (but with a *lot* of state that can help recover H > from whatever the failed CPU was doing, plus extensive internal checksJ > in the processor to help catch failures before any external state can beG > affected by them).  For example, it can ascertain whether the CPU was E > executing system or process code at the time of failure, and if the H > latter just evict the process and let the rest of the system continue.H > And IIRC additional mechanisms handle hard memory failures by figuringE > out exactly what the failed memory could have affected and limiting  > losses to that.  > F > Normally, I wouldn't tend to advocate attempting such fix-ups ratherF > than restarting with a clean slate, but in the mainframe world 'highJ > availability' is not just a statistic - and IBM seems to have managed toD > pull this off (not that I'd trust many other people to be able to:' > they've spent decades perfecting it).  >   G they have had too ... I spent a month on an AS400 and had three crashes B none of which were ever explained ... never had a crash on vms ...   ------------------------------  % Date: Mon, 24 Apr 2006 19:38:07 -0400 ( From: Bill Todd <billtodd@metrocast.net># Subject: Re: OT: Sparc not dead yet G Message-ID: <geidnQ6tw6nb_NDZnZ2dnUVZ_t6dnZ2d@metrocastcablevision.com>    Tom Linden wrote: I > On Mon, 24 Apr 2006 16:10:40 -0700, Bill Todd <billtodd@metrocast.net>   > wrote: > I >> Don't be silly.  Itanic's installed base isn't what will carry Itanic  F >> anywhere:  Intel's (and HP's) level of commitment is, and with the H >> captive HP-UX (and to a far lesser extent Alpha) customer base (plus I >> SGI's as well, assuming that SGI survives and doesn't move largely to  F >> Opteron and Xeon platforms) in tow they can doubtless carry Itanic E >> along as long as they're willing to spend time, money, and effort  ' >> there rather than in more lucrative/  >> productive areas. > J > SGI's survival you may indeed question, but if they do survive, Itanium  > will? > not be part of the product spectrum.  This is not an opinion.   A Now, you really can't in good conscience drop that bomb into the  1 conversation and then just saunter away, can you?   G I've been hearing credible reports since last fall about SGI's Opteron  A plans and intense dissatisfaction with Intel over the continuing  C Montecito delays and feature cut-backs, but it sounds as if you've  , encountered something much more substantial.   Inquiring minds want to know...    - bill   ------------------------------  % Date: Mon, 24 Apr 2006 20:38:24 -0400 - From: JF Mezei <jfmezei.spamnot@tekksavy.com> # Subject: Re: OT: Sparc not dead yet , Message-ID: <444D6F68.4CD6D702@tekksavy.com>   bob@instantwhip.com wrote:I > they have had too ... I spent a month on an AS400 and had three crashes D > none of which were ever explained ... never had a crash on vms ...  F I've had hardware crashes on a vaxstation 3100. My all mighty MVII was rock solid though.   ------------------------------    Date: 24 Apr 2006 19:45:06 -0500+ From: young_r@encompasserve.org (Rob Young) # Subject: Re: OT: Sparc not dead yet 3 Message-ID: <PL8kQJmJ7Bh8@eisner.encompasserve.org>   r In article <n5WdnbmDMYHIgNDZnZ2dneKdnZydnZ2d@metrocastcablevision.com>, Bill Todd <billtodd@metrocast.net> writes: > Rob Young wrote:_ >> In article <444B334B.4B169DD7@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes:  >  > ...  > K >>> Or put it in another way: has Sun fully eroded the gains it made during ; >>> the .com boom, or is there still more room to go down ?  >>  E >> 	Of course, they aren't out of business yet.  My overarching point D >> 	is compared to others, Sun is going in the wrong direction.  The) >> 	paradigm is shifting, they missed it.  > J > Oh, my - 'the paradigm is shifting'.  When struggling to make a dubious , > point, by all means break out the cliches. >   ? 	Quite simple in Sun's case.  Their love affair with all things ? 	SPARC.  In-house CPU development and all that entails... only   	IBM can get away with that.  H > It's really hard to tell whether your idiocy is feigned or real, Rob. I > Indeed, the paradigm *did* shift back in the mid-to-late '90s, and Sun  J > caught that shift rather more successfully than others did.  JF's point C > (for once a reasonable one) is that unless *after you remove the  F > original shift and the later 'correction'* Sun is now *worse off in E > terms of market share than it was before the dot-com ups and downs  F > occurred*, then there's a distinct possibility that it's still just G > experiencing the trailing symptoms of the correction and may just be  B > returning to the status quo ante - rather than anything of more F > fundamental significance (as you appear characteristically eager to  > suggest).     A 	Nope.  Today's news confirms Sun will be making radical changes.   J > In other words, if you want to look at trends in anything resembling an J > objective manner, you shouldn't pick your evidence (and time-frames) so I > selectively.  Of course, if you just want to spin, then selectivity is  " > definitely the order of the day.  < 	Sun is in trouble.  Obviously, the BOD McNealy himself must 	have admitted it.  J > I'm rooting for it, because I believe that diversity and competition in H > the industry are good things.  But I rate its chances for survival at E > about the same level as Itanic's:  not great (with probably *very*  E > little likelihood of anything resembling industry domination), but  G > certainly not zero either (as long as they don't seriously screw up).   @ 	Sure.  I'd put them somewhere between SGI and 1/2 Dell in size.   	Here's what Paul dug up:   U http://money.cnn.com/2006/04/24/technology/business2_sun/index.htm?source=yahoo_quote   O "But Schwartz may well be more suited to make the hard decisions Sun needs now. I In a recent research report, Sanford C. Bernstein analyst Toni Sacconaghi I estimated that Sun needs to cut 10,000 to 12,000 jobs . 27 percent of its N workforce of 39,000 . to get its costs in line with the rest of the industry."  M "In the conference call, Schwartz announced his first task would be to review 0 all of Sun's $2 billion in annual R&D spending."   ---   < 	We'll see if all those pet CPU projects survive.  Doubt it.   				Rob  	    ------------------------------  % Date: Mon, 24 Apr 2006 22:43:50 -0400 ( From: Bill Todd <billtodd@metrocast.net># Subject: Re: OT: Sparc not dead yet G Message-ID: <6uKdncp3a-lTEdDZnZ2dnUVZ_uWdnZ2d@metrocastcablevision.com>    Rob Young wrote:   ...   K >> In other words, if you want to look at trends in anything resembling an  K >> objective manner, you shouldn't pick your evidence (and time-frames) so  J >> selectively.  Of course, if you just want to spin, then selectivity is # >> definitely the order of the day.  > > > 	Sun is in trouble.  Obviously, the BOD McNealy himself must > 	have admitted it.  F As usual you still don't get it, Rob.  Of *course* Sun is in trouble: A any company which fails to hold onto past gains has to take that  D seriously.  But the question of whether it is in any worse relative I shape than it was prior to the dot-com bubble is still a relevant one in  G determining whether its current problems are inherent (e.g., in SPARC,  F as you would like us to believe) or largely just a natural correction  after the dot-com anomaly.  G As for SPARC itself, there's every reason to believe that Sun can 'get  E away with' continuing SPARC development at the very least as much as  H Intel can 'get away with' continuing Itanic development (though neither F may be in as strong a position as POWER is in that respect).  Sun may I not have Intel's financial depth to bring to bear but, unlike Itanic, it  G has a large and loyal customer base which clearly doesn't want to move  I elsewhere if Sun can continue to provide any reasonable continuation for  I the platform.  And while that may have been in doubt for a while, it now  I looks quite credible - while over the past couple of years the wheels on  G the Itanic bandwagon (that threatened to steal SPARC customers, though  E in fact seems not to have done so:  most of the SPARC loss in market  C share seems to have gone to POWER) have become increasingly wobbly.   G The main effect of the CEO transition may be to buy Sun enough time on  H Wall Street to start to make it clear whether their current product set A is sufficient in itself to initiate a turn-around or whether the  D heavy-handed R&D cuts that Wall Street seems to favor (often at the G expense of long-term viability) are really necessary.  A fine piece of  H sleight-of-hand if that's what's going on, and just what the kibitzing, % non-productive bean-counters deserve.    - bill   ------------------------------  % Date: Tue, 25 Apr 2006 09:41:54 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> 3 Subject: Re: Quorum, locks and application question 1 Message-ID: <e2junc$gus$1@news-02.connect.com.au>   	 Hi Keith,   G > If I understand your question, the basic issue is that when a lock is G > being used to protect updates to some shared resource, you may really H > need to know if the reason you are now being granted your lock request
 > is because: H > 1) the prior user is now done with it, having left the shared resource3 > (like a database block) in a consistent state, or H > 2) the prior user got interrupted in mid-update by a node failure, andI > the resource has been left in an indeterminate state and probably needs  > to be fixed up  2 Yep that's the question. (Or at least half of it).  I > In the early '90s Rdb asked for and received new capabilities in VMS to J > handle this possibility. The $SETCLUEVT system service allows one to askJ > for notification of events like loss of a node from the cluster, and VMSG > guarantees that the AST notifying you of the node loss will always be H > delivered before any AST (or mainline process execution) notifying youH > that a has lock granted because the old lock on a failed node has been, > freed as a result of the state transition.  C I didn't know it was Rdb that asked for that, or about the ordering  gurantee. Thanks for the info.  I But my question about Rdb's freeze lock strategy would apply equally to a E single node SMP environment. I'll put more in a reply to John Santos.    Cheers Richard Maher  > "Keith Parris" <keithparris_NOSPAM@yahoo.com> wrote in message, news:BCN1g.6585$fy3.4056@news.cpqcorp.net... > Richard Maher wrote: > > Consider this conundrum: - > > K > > Q. How does a Rdb Monitor process faithfully implement it's FREEZE lock @ > > mechanism so as to protect the ACID properties of a database transaction? > > L > > A. Stuffed if I know. (There was a discussion in ITRC about this a while	 > > back)  > > J > > 1) Process A on Node X has entered a Cayman Island transaction for $1B and J > > will have to rollback 'cos a commit-time constraint will stop it going > > through.H > > 2) Process B on Node Y has a lock pending on this Account record and wants / > > to transfer the balance to the Isle of Man. F > > 3) Node Z is thrashing away sending tree re-mastering requests all around, > > the cluster and being a general nuisance > > 4) Node X dies > > : L > > : From this point on I imagine the possibility of a race-condition. That is, F > > what *right-now* is stopping Process B from seeing the dodgy data? > G > If I understand your question, the basic issue is that when a lock is G > being used to protect updates to some shared resource, you may really H > need to know if the reason you are now being granted your lock request
 > is because: H > 1) the prior user is now done with it, having left the shared resource3 > (like a database block) in a consistent state, or H > 2) the prior user got interrupted in mid-update by a node failure, andI > the resource has been left in an indeterminate state and probably needs  > to be fixed up > I > In the early '90s Rdb asked for and received new capabilities in VMS to J > handle this possibility. The $SETCLUEVT system service allows one to askJ > for notification of events like loss of a node from the cluster, and VMSG > guarantees that the AST notifying you of the node loss will always be H > delivered before any AST (or mainline process execution) notifying youH > that a has lock granted because the old lock on a failed node has been, > freed as a result of the state transition.   ------------------------------  % Date: Tue, 25 Apr 2006 10:06:27 +0800 3 From: "Richard Maher" <maher_rj@hotspamnotmail.com> 3 Subject: Re: Quorum, locks and application question 1 Message-ID: <e2k05d$iqs$1@news-02.connect.com.au>    Hi John,  G > I think you can do this using lock value blocks.  Put a flag in there I > that says "the transaction was successfully completed".  Clear the flag C > on acquiring the lock.  Set the flag when you exit.  If, when you < > acquire the lock, the flag is already clear, or if you getE > SS$_VALNOTVALID, then you need to back out whatever transaction was  > in progress first.  I Yes I think you're right. The ss$_valnotvalid status should be enough for L anybody! Which led me to revisit my question and ask "Well, what the hell isI the FREEZE lock doing then?". My next best guess is that although the DLM G will faithfully report a failure scenario to, at least, the next person J waiting for the lock to be promoted, what if nobody else has a lock on theK same resource? Surely the next user wanting access to the dodgy row(s) will H create a totally new lock with a totally new lock value block? So is the7 Freeze lock designed to stop "new" locks being created?   L Is this a race condition where a new user could, quite conceivably, obtain aF (new) lock on the row and read the dodgy data *before* the freeze lockE orders him to cease and desist? (I know that no Commiting can be done J (before Freeze+RDM rollback) but the dodgy data could be displayed, and ifH they are silly enough to update the row without first checking to see if( it's changed, could that be a disaster?)  H Before we all come up with all sorts of ways to overcome this situation,E does anyone know exactly what Rdb does do? What does this freeze lock  achieve and why?   Cheers Richard Maher  L PS. Are System Owned locks really all that unwieldy? Anyone have an example?    - "John Santos" <john@egh.com> wrote in message " news:zqe2g.438$bU6.109@trnddc06... > Dave Froble wrote: > > Keith Parris wrote:  > >  > >> Richard Maher wrote:  > >>  > >>> Consider this conundrum: - > >>> H > >>> Q. How does a Rdb Monitor process faithfully implement it's FREEZE lockB > >>> mechanism so as to protect the ACID properties of a database > >>> transaction? > >>> H > >>> A. Stuffed if I know. (There was a discussion in ITRC about this a while  > >>> back)  > >>> H > >>> 1) Process A on Node X has entered a Cayman Island transaction for
 > >>> $1B and L > >>> will have to rollback 'cos a commit-time constraint will stop it going > >>> through.J > >>> 2) Process B on Node Y has a lock pending on this Account record and > >>> wants 1 > >>> to transfer the balance to the Isle of Man. H > >>> 3) Node Z is thrashing away sending tree re-mastering requests all > >>> around. > >>> the cluster and being a general nuisance > >>> 4) Node X dies > >>> : I > >>> : From this point on I imagine the possibility of a race-condition.  > >>> That is,H > >>> what *right-now* is stopping Process B from seeing the dodgy data? > >> > >> > >>J > >> If I understand your question, the basic issue is that when a lock isJ > >> being used to protect updates to some shared resource, you may reallyK > >> need to know if the reason you are now being granted your lock request  > >> is because:K > >> 1) the prior user is now done with it, having left the shared resource 6 > >> (like a database block) in a consistent state, orK > >> 2) the prior user got interrupted in mid-update by a node failure, and F > >> the resource has been left in an indeterminate state and probably > >> needs to be fixed up  > >>I > >> In the early '90s Rdb asked for and received new capabilities in VMS I > >> to handle this possibility. The $SETCLUEVT system service allows one C > >> to ask for notification of events like loss of a node from the G > >> cluster, and VMS guarantees that the AST notifying you of the node F > >> loss will always be delivered before any AST (or mainline processJ > >> execution) notifying you that a has lock granted because the old lockI > >> on a failed node has been freed as a result of the state transition.  > >  > > H > > So if a lock is granted because the node holding the lock exited theD > > cluster, the process acquiring the lock must be testing for thisJ > > condition by having such an AST queued every time a lock is requested? > G > I think you can do this using lock value blocks.  Put a flag in there I > that says "the transaction was successfully completed".  Clear the flag C > on acquiring the lock.  Set the flag when you exit.  If, when you < > acquire the lock, the flag is already clear, or if you getE > SS$_VALNOTVALID, then you need to back out whatever transaction was  > in progress first. > G > But probably of more practical use, since the information to back out H > a partial transaction has to be stored somewhere (e.g. RMS journaling,I > a database, or roll-your-own), the "transaction in progress" flag could J > be stored in the same place.  This may involve some disk I/O, but on theC > plus side, it will also survive a complete cluster crash.  If you G > acquire the lock cleanly, (valid lock value block that says there was J > no transaction in progress) just do your thing.  If the lock value blockC > is invalid, either it was held by a process on another node which A > crashed, or you are the first process up after a system boot or H > application restart, so you need to check for in-progress transactionsF > and back them out before continuing.  If there is a valid lock valueF > block, but it indicates an in-progress transaction, then the processE > which held the lock (but not the node it was running on), must have  > crashed, so same thing.  > E > You may need to have two resources, one which is used for exclusive D > access to the database (or whatever), and a 2nd one which can onlyI > be held by the current holder of an exclusive lock on the 1st resource. D > The 2nd lock records the current state of the transaction, and hasI > its value set to "in progress" *after* a process acquires the 1st lock, G > and then is set to "done" after finishing the transaction, but before D > releasing the 1st lock.  Then use invalidity of the value block orD > an "in progress" value (for the 2nd resource), to decide whether aA > back-out is needed.  The reason for this, ISTR, is that you can E > only modify the contents of a lock value block when you release the H > lock, so you need a lock you can release without losing your exclusiveA > access to the database.  (For this to work well, all interested B > processes need to take out "null" locks on both the resources atC > startup, and then use lock conversions on them, rather than using C > $enq/$deq each time they need the lock.  Otherwise, when the last D > holder does its $deq, the lock value block will evaporate, and theJ > app will do a lot of unnecessary checking for in-progress transactions.) >  >  > > L > > Does RDB queue an AST and test for the condition.  (I'm guessing that itJ > > does since your post is in reply to such an event.)  In the case whereJ > > the condition exists, what does RDB do?  It's like "hey buddy, you now@ > > have the resource, but the last guy never finished with it". >  >  >  >  > --  
 > John Santos  > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539   ------------------------------  # Date: Tue, 25 Apr 2006 03:57:49 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>3 Subject: Re: Quorum, locks and application question 2 Message-ID: <17h3g.6782$FF7.2906@news.cpqcorp.net>   Richard Maher wrote:  H >> I think you can do this using lock value blocks.  Put a flag in thereJ >> that says "the transaction was successfully completed".  Clear the flagD >> on acquiring the lock.  Set the flag when you exit.  If, when you= >> acquire the lock, the flag is already clear, or if you get F >> SS$_VALNOTVALID, then you need to back out whatever transaction was >> in progress first.  > K > Yes I think you're right. The ss$_valnotvalid status should be enough for N > anybody! Which led me to revisit my question and ask "Well, what the hell is > the FREEZE lock doing then?".     G    I have not dug back through the thread to see if this was suggested  @ before, but I'd (again) look at DECdtm here; at the distributed F transaction manager.  I'm sure there's some reason why DECdtm and RTR H can't be used here, but -- so long as we're back (again) looking at the F distributed lock manager and at the event services -- I'll suggest it  (again).   ------------------------------  # Date: Mon, 24 Apr 2006 18:07:07 GMT ) From: Alfred Falk <falk@arc.REMOVE.ab.ca> ' Subject: Re: Replacing drives in bricks 6 Message-ID: <Xns97AF7B470CBAfalkarcabca@198.80.55.250>  ) Rob Brown <mylastname@gmcl.com> wrote in  < news:Pine.LNX.4.61.0604211057130.6747@localhost.localdomain:  % > On Thu, 20 Apr 2006, syslost wrote:  > G >> But wait there's more.. I also have 48 ba350-sb shelves.  Some have  F >> 150 watt power supplys, and all have two fans.  Same deal, you pay  >> only the shipping.  > F > This sounds attractive.  Now here is a hypothetical.  I get a BA350 I > and some rz28s in storageworks bricks.  n years down the road an rz28s  F > dies.  What is the wisdom of opening up the bricks in replacing the ? > dead drive with a modern drive (with appropriate cabling and  H > terminators etc.) so that I can continue to use the slot in the BA350? > : > Would you do it as a hobbyist?  Would you do it at work?  F Problem with this, Rob, is that the internal cabling of each brick is H designed to fit a particular drive.  This affects SCSI id selection and F drive status returned to shelf and displayed on the two front LEDs of I the brick.  For instance, RZ-28, RZ-28D, and RZ-28 are all different and  G can't be interchanged.  If you can live without shelf-assigned SCSI id  G or status lights, it works just fine for any old-style 50 pin drive in  7 the grey/green -VA bricks, or 68-pin in the -VW bricks.   H On the other hand, the blue bricks use 80-pin SCA connectors internally H and you can interchange to your heart's content.  (I've replaced all my ? old 4 and 9 GB drives with newer, faster, 18 and 36 GB drives.)    --  @ ----------------------------------------------------------------A   A L B E R T A         Alfred Falk               falk@arc.ab.ca  @ R E S E A R C H         Information Systems Dept   (780)450-5185+   C O U N C I L         250 Karl Clark Road 1                         Edmonton, Alberta, Canada  http://www.arc.ab.ca/   T6N 1E4   http://www.arc.ab.ca/staff/falk/   ------------------------------  + Date: Mon, 24 Apr 2006 21:00:21 +0000 (UTC) P From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)= Subject: Re: shadow sets, cluster, merge, MVTIMEOUT, dismount $ Message-ID: <e2je95$73j$1@online.de>  5 In article <444C2775.92936B08@teksavvy.com>, JF Mezei ' <jfmezei.spamnot@teksavvy.com> writes:    E > Then you basically have to perform all the tasks in shutdown.com in ) > syshutdwn.com ... re-invernt the wheel.    It depends.   I > For instance, the INSTALL PURGE is done very late in the shutdown code. G > You would have to do it yourself in syshutdwn.com to make sure you've G > cleared all your disks of installed images.  And you need to stop the  > queues as well etc etc etc.   C The queues are stopped on the node to be shut down.  No additional  G problem there.  I'm not worried about INSTALLed stuff.  It's either on  H the system disk or DISK$SOFT, my disk for third-party software.  Since, A obviously, this is needed by more than one node, its members are  G distributed across more than one node.  Basically, for disks with both  G members on the same node, we are talking about system disks.  However,  F the node which goes down won't have any files open on the system-disk * shadow set of another node in the cluster.  H > It also needs good design in terms of page/swap file locations so thatJ > you can cleanly dismount disks without having to cull processes all over > the cluster.  C I agree, planning is the main thing.  As I said, in practice (in my B case) I'm thinking of shutting down node A and nodes B and C have G mounted its system-disk shadow set.  They don't have any files open on  H it; I just mount it for convenience so that I can access all disks from 
 all nodes.  I As it stands now, my cluster is now working fine, and with a minimum of   5 effort I can reboot nodes with no unnecessary merges.    ------------------------------    Date: 24 Apr 2006 21:37:19 -0700& From: "Rajni" <rajni_chugh1@yahoo.com>+ Subject: Spawn command in Asynchronous mode C Message-ID: <1145939839.311844.227320@e56g2000cwe.googlegroups.com>    Hi All,   < We want to run a C code from Uniface program  on OPen VMS in asynchronous mode.   Platform - OpenVMS8 We are running a spawn command from the uniface program.  # ;spawn_str = "%%spawn_str %%$LIST$"   B When I do spawn ----C pgm-----, it runs the program in synchronous mode.   F But I want to run this C pgm in Asynch mode, as per the documentation,) if I use PIPE (-------)&, it doesnt work. . ;spawn_str = "PIPE ( %%spawn_str %%$LIST$ ) &"  ? Could some one please let me know how to run it in asynch mode? C Please let  me know what should be the spwan command syntax in this  case.    Regards, Rajni.   ------------------------------  % Date: Tue, 25 Apr 2006 01:15:31 -0400 ) From: "Ken Robinson" <kenrbnsn@gmail.com> / Subject: Re: Spawn command in Asynchronous mode G Message-ID: <7dd80f60604242215v22338e62v3b639c128402b6b@mail.gmail.com>   D On 24 Apr 2006 21:37:19 -0700, Rajni <rajni_chugh1@yahoo.com> wrote:	 > Hi All,  > > > We want to run a C code from Uniface program  on OPen VMS in > asynchronous mode. >  > Platform - OpenVMS: > We are running a spawn command from the uniface program. > ' > ;spawn_str =3D "%%spawn_str %%$LIST$"  >   F I don't know the syntax of the Uniface program, but to spawn a program= and not wait for the completion use the :"/nowait" qualifier:    $ spawn/nowait ....    $ help spawn& will give you most the help you need..   Ken    ------------------------------  % Date: Mon, 24 Apr 2006 13:45:28 -0400 ' From: Dave Froble <davef@tsoft-inc.com> & Subject: Re: Strange disk device state9 Message-ID: <nPWdnTYzZ9RlkNDZnZ2dnUVZ_tydnZ2d@libcom.com>    Albrecht Schlosser wrote:  > Dave Froble wrote: > H >> Steve and Rob will definitely be closer to understanding this than I E >> am, but a thought.  If the disk is truly dead, perhaps the system  H >> never received something it needed to dismount the disk.  I'd expect J >> some type of timeout to resolve this.  The reference count seems to be % >> at least some part of the problem.  >>I >> I believe you mentioned that the disk was hot-swapable?  Why not just  J >> pull the bugger and insert a hopefully good disk.  Could be wrong, and G >> Steve and Rob seem to indicate that this may not work, but VMS just  : >> might surprise you once it can get the disk to respond. >  > I > We did try that, and VMS _surprised_ me with a negative ref. count and  I > the inability to recover the system with a new disk (without a reboot)   > :-( .  > K > But I don't want to speak bad of VMS - in my opinion and long experience  K > with VMS almost nothing can kill a VMS system except hardware problems -   > and here we have one.  > 
 > Albrecht  D I'm not one who opposes a periodic re-boot of the system, even when @ there are no problems.  I don't particularly advocate it either.  H However, I am a firm believer that things, anything, can get so screwed D up that only option is to throw out the anchor and stop everything. H I've seen people attempt to recover from errors by using the very thing K that is causing the errors.  Not much chance of anything but getting worse.   H Nothing wrong with a fresh copy of the OS.  Reboots are not a bad thing.   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  % Date: Mon, 24 Apr 2006 14:21:09 -0400 - From: JF Mezei <jfmezei.spamnot@tekksavy.com> & Subject: Re: Strange disk device state, Message-ID: <444D170F.2932AAFD@tekksavy.com>   Albrecht Schlosser wrote: H > dismount and replacement of the disk. Without stopping the applicationG > software. Simply doing a reboot seemed not to be VMS-like for me. ;-)   B Over the years, there have been many discussions about the need toF reboot VMS in the case of a device stuck in a weird state. The reasonsH given are sound (what happens when an IO completes and the device driverF in kernel mode moves data to memory locations that no longer exist, orI tries to call an AST in a memory location which no longer contains code).     H The problem is that drivers are written by different people in differentH companies and there may not be a single solution to being able to safelyE reset a device to a known "idle" state. Personally, I think that is a F big weakness of VMS in a context where customers don't want to have to reboot a node.  F On the other hand, with clustering, it does allow one to reboot a node3 without losing service or with minimal disruptions.    ------------------------------  % Date: Mon, 24 Apr 2006 14:52:03 -0400  From: norm.raphael@metso.com& Subject: Re: Strange disk device stateQ Message-ID: <OFA1E71E58.E6D07BAF-ON8525715A.00675A8A-8525715A.0067A487@metso.com>   H JF Mezei <jfmezei.spamnot@tekksavy.com> wrote on 04/24/2006 02:21:09 PM:   > Albrecht Schlosser wrote: J > > dismount and replacement of the disk. Without stopping the applicationI > > software. Simply doing a reboot seemed not to be VMS-like for me. ;-)  > D > Over the years, there have been many discussions about the need toH > reboot VMS in the case of a device stuck in a weird state. The reasonsJ > given are sound (what happens when an IO completes and the device driverH > in kernel mode moves data to memory locations that no longer exist, orK > tries to call an AST in a memory location which no longer contains code).  >  > J > The problem is that drivers are written by different people in differentJ > companies and there may not be a single solution to being able to safelyG > reset a device to a known "idle" state. Personally, I think that is a H > big weakness of VMS in a context where customers don't want to have to > reboot a node. > H > On the other hand, with clustering, it does allow one to reboot a node5 > without losing service or with minimal disruptions.   F Well I wasn't going to butt in, but I just tried to replace an NSR and? we couldn't get VMS to recognize the devices behind it, and the H recommendation from support was to shut down the entire cluster to clearD the device database and then reboot each node to form a new cluster.: That is not very VMS-like, and quite disruptive is it not.  E [P.S.  We put the original NSR back and everything picked up as was.]    ------------------------------  % Date: Mon, 24 Apr 2006 14:45:34 -0400 - From: JF Mezei <jfmezei.spamnot@tekksavy.com> & Subject: Re: Strange disk device state, Message-ID: <444D1CCD.35598FD1@tekksavy.com>   Dave Froble wrote:I > However, I am a firm believer that things, anything, can get so screwed E > up that only option is to throw out the anchor and stop everything. I > I've seen people attempt to recover from errors by using the very thing M > that is causing the errors.  Not much chance of anything but getting worse.   E Think of it as testing some new drug on terminally ill patients. They G have nothing to lose. If you knwo you're going to reboot anyways, might , has well use that opportunity to experiment.    H Say you have scheduled 2 hours for a shutdown due to that state. But youG first try that patch and play around for one hour to see what effect it F has had and if it renders the device usable without crashing. Lets say. the patch *appears* to work. You still reboot.  F Then, if that situation arises again during a busy time where you needF access to that device again, you might consider applying that patch toP regain immediate use of the device, AND STILL SCHEDULE A REBOOT WHEN CONVENIENT.   ------------------------------  # Date: Mon, 24 Apr 2006 18:55:31 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>& Subject: Re: Strange disk device state2 Message-ID: <Da93g.6753$Ky7.5886@news.cpqcorp.net>   Albrecht Schlosser wrote:   I > Okay, thanks, now we know what led to the problem. But what would have  G > been the right way to dismount and replace the disk? I've never seen  C > this BADBLOCKSCAN process before. Is this documented anywhere? I  E > couldn't find anything about it in the docs (looking in the system  H > manager manual - where else should I look?). What (and how) does this G > process do, and when would it have finished by itself? Would it have   > finished at all?  C    The bad block scan gets triggered when a disk gets into serious   trouble.  F    There's a discussion of bad block handling in one of the topics of @ the OpenVMS Ask The Wizard area.  Off-hand, I do not recall the H particular topic number over there, but the topic goes into substantial G detail on how bad block handling is performed on SCSI disks on OpenVMS.   E    Either let the bad block scan run to completion, or shut down and  H swap this disk.  By the time a SCSI disk is generating piles of errors, I it's usually also been kicked out of the shadow set, and it's usually at   the stage of active failure.  8    Shadowing (Host-based volume shadowing) or Mirroring F (Controller-based RAID) is the way to avoid disk errors and data loss.    K > Thanks for this long and helpful explanation. So, my conclusion is: this  J > hot-swap feature of the disks is at most a "warm-swap" feature, because 3 > all other disks on the same bus must be quiet :-(   H    I am aware of no hot-swap capability here, until and unless you have G a controller and a bus that (also) support the capability; some way to  F quiesce the whole (parallel) SCSI bus.  I am also aware of folks that G have "gotten lucky" with their disk hot-swaps.  I would not personally  G depend on this particular brand of "luck" within a production cluster,   however.   ------------------------------  % Date: Mon, 24 Apr 2006 23:53:25 -0400 ' From: Dave Froble <davef@tsoft-inc.com> 0 Subject: Re: The Sun Logo on the OpenVMS Manuals/ Message-ID: <r5mdnQJJ_vXpAdDZRVn-jg@libcom.com>    Hoff Hoffman wrote:  > Dave Froble wrote: > G >> Then again, is it HP, or some company they hired?  Remember the VMS  J >> media kit, or whatever, with the Sun workstation/terminal on the cover? >  > J >   Remember what?  My own mistakes?  Yes, I do tend to remember the ones = > I've made that serve as fodder for postings in comp.os.vms.  > G >   As has been discussed previously, I picked that particular picture  E > from a set of available photographs, along with two folks from the  # > OpenVMS business management team.  > F >   As for the background, the three of us had a choice from a set of J > moderate-resolution photos from the Compaq corporate image library, and H > the printing process then allowed the Sun logo to be visible when the D > picture was printed at the higher resolution on the covers of the  > OpenVMS manuals. > G >   Similar printing-related risks have been discussed in Risks Digest  J > from time to time, and particularly when you don't request or don't see K > a proof from the actual printing run.  (And why would you expect to even  7 > need a proof copy?  Well, now I know why, of course.)  >  >   I And here I was believing that it was some outside firm.  Guess I owe all   of them an apology.    --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com 170 Grimplin Road  Vanderbilt, PA  15486    ------------------------------  # Date: Mon, 24 Apr 2006 18:45:41 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>Y Subject: Re: The Sun Logo on the OpenVMS Manuals (was: Re: HP Storageworks Arrays are Bul 1 Message-ID: <p193g.6752$uy7.980@news.cpqcorp.net>    Dave Froble wrote:  F > Then again, is it HP, or some company they hired?  Remember the VMS I > media kit, or whatever, with the Sun workstation/terminal on the cover?   I    Remember what?  My own mistakes?  Yes, I do tend to remember the ones  ; I've made that serve as fodder for postings in comp.os.vms.   F    As has been discussed previously, I picked that particular picture C from a set of available photographs, along with two folks from the  ! OpenVMS business management team.   E    As for the background, the three of us had a choice from a set of  H moderate-resolution photos from the Compaq corporate image library, and F the printing process then allowed the Sun logo to be visible when the B picture was printed at the higher resolution on the covers of the  OpenVMS manuals.  F    Similar printing-related risks have been discussed in Risks Digest H from time to time, and particularly when you don't request or don't see I a proof from the actual printing run.  (And why would you expect to even  5 need a proof copy?  Well, now I know why, of course.)    ------------------------------  % Date: Mon, 24 Apr 2006 20:55:04 -0500 @ From: "David J. Dachtera" <djesys.nospam@NeOaSrPtAhMlNiOnWk.net>( Subject: To Be Auctioned: MicroVAX 3100s5 Message-ID: <444D8178.99BEF8D@NeOaSrPtAhMlNiOnWk.net>   C O.k., folks. These are working systems with no disk, no tape and no  CD-ROM:    2 - DV-31ETA-A with 8MB RAM  1 - DV-31ETA-A with 4MB RAM  1 - DV-31DTA-A with 4MB RAM   H These will be posted to eBay for auction, opening bid $0.99 with a $9.99E "Buy-It-Now" price. Essentially, these are being sold for the cost of 	 shipping.    E-mail me privately at:    djesys at comcast dot net   B ...if you want one of these before I post them to eBay this comingF Sunday evening, 30-Apr-2006. After that, I have to go through the eBayE motions and complete the sale on-line. I'm going to request PayPal in A any event, but that's not cast in stone unless you buy from eBay.   3 The shipping weight on these is roughly 25 pounds.    F I would prefer not to ship overseas at this time. If you have a friendD state-side who would be willing to help you out in that regard, dropH them a note and ask them to complete the purchase for you. Once it's out9 of my hands, I am not responsible for what happens to it.   ? Again, these will be posted to eBay this coming Sunday evening,  30-Apr-2006.   --   David J Dachtera dba DJE Systems  http://www.djesys.com/  & Unofficial OpenVMS Marketing Home Page! http://www.djesys.com/vms/market/   ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/   " Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/   ) Unofficial OpenVMS Hobbyist Support Page: " http://www.djesys.com/vms/support/   ------------------------------   End of INFO-VAX 2006.228 ************************                                                                                                          t|:KG[p>u\{lU܆OY'^R4̖!wKYF|8z.#EMPs@ 4`6w}I۶l3yٟŪU8-c򥝃a2.U*
ա E
ƤyޫZq? 
dۺgP6۷L=Je2#?QJɶy4W}cYk[m{L/}VRv-2d _IPʽ<:,~
~NwŔ&EX+ʓ;Y+b3MXG&i.y36[yZ>]zƷPxvWXsR&wV|H)6[34@?![YX=''H*&SIȇ .nojBjBt1R%q*^7poz}|K*Ś}-(5-׿ܺͽC~.=?c	vtSrMCzW>\,mfx _Nէ]iMD%V]nEJ=+jzdi&Zr;(SׂV9z] v~+T2&T
BG gfǜȴC+L8ߓ7ݽiTxGUI	z
0m)ߥy&92%r$Wl*k3AVnɎHY]<Չu*>^>W{kV풺"Wra>I9EqZ}2K""=z}#>f}u[9Hս^Bipx<Kz}14VU`2[}p>\gܳuHKGYߥ
Z]rGTk@n</RVO[LlqAWbS° 1N㭑/Beu\1Y`{m8*zDw'ȭB<U?vg.?KN7^V%`&o i2M%p{ꪰo޼:߿0NYs3p7a+	CO[D'BH|N'tŌ%
°"jquWoGIԷ8Xj8E#X\McgZGY[K"n.FUNcAk):((&)MRvoM9=.uTEj[C,^T8"Bi; 3~2|KPJm,AHN+/8R\(n[ukRsjT`oYR*GiPkFD<s$e?z}RtNN;3֢)0^
</!wlwy9FL]pC2T]J㆜k7eVaQx.K>PkC*Z,遱W#ּf7o ~1	[76#vnRgN('XLqe]A'2w
II}v8Pl;4ْtK,?]D1YM ,^4.%AXnw]ų
' t$3*.ъrunH}JV#(u*6߽9( $Sk^.V[98;aX0]mɭq]Fwq.;^0dR
Fώ~Y!2_9?d+mcx `6E*vGԟɔoW69>mi=jmڠ0UUVvl:^p_$j|urU^E}i~3VA-=$Q@<Y|2ybLnwK0vJ%ey.?ߣ^7>jll[kkdDF_@qp.Ek1St̝ψ19Vy%h=W[ru$C'n2v2m?9+g7)X