1 INFO-VAX	Thu, 29 May 2003	Volume 2003 : Issue 296       Contents: Alpha Upgrade sys$devices.dat ?   Re: Another VMS inquirer article  Re: Another VMS inquirer article  Re: Another VMS inquirer article  RE: Another VMS inquirer article  Re: Another VMS inquirer article  Re: Another VMS inquirer article Digital Network Product Group ! Re: Digital Network Product Group ! Re: Digital Network Product Group ! Re: Digital Network Product Group ! Re: Digital Network Product Group ! Re: Digital Network Product Group  Re: ES40 and CPU upgrade Re: Firmware Upgrade Re: Firmware Upgrade re: Firmware Upgrade Re: Firmware Upgrade/ Re: Getting LK411-AA keyboard to work correctly ' Re: Hobbyist seeks generic SIMM vendors ' Re: Hobbyist seeks generic SIMM vendors & Re: How to make a shadowed system disk Install Directory  Re: Install Directory  Re: Install Directory  Re: Install Directory  Re: Invalid Disk format  Re: Invalid Disk format  Re: Invalid Disk format  Re: Invalid Disk format P Re: Letter to HP Management from OpenVMS users around the world ... Shape up or ( Mystery Alpha CPUS, what do they fit in?, Re: Mystery Alpha CPUS, what do they fit in?, Re: Mystery Alpha CPUS, what do they fit in?, Re: Mystery Alpha CPUS, what do they fit in? Re: New MiniMerge capability Re: New MiniMerge capability Re: New MiniMerge capability3 Re: NT: son of VMS? (was Re: Portents of VMS death) 3 Re: NT: son of VMS? (was Re: Portents of VMS death) 3 Re: NT: son of VMS? (was Re: Portents of VMS death) 3 Re: NT: son of VMS? (was Re: Portents of VMS death) 3 Re: NT: son of VMS? (was Re: Portents of VMS death)  OSU http_server errorpage  Re: Portents of VMS death  Re: Portents of VMS death  Re: Portents of VMS death  Re: Portents of VMS death  Re: Portents of VMS death 7 Re: Reading CD-R burned on a Window system on an Alpha? 7 Re: Reading CD-R burned on a Window system on an Alpha? 7 Re: Reading CD-R burned on a Window system on an Alpha? 7 Re: Reading CD-R burned on a Window system on an Alpha?  StorageTek l700 on VMS 7.3-1: [OT] Writing unmaintainable code, was: Re: NT: son of VMS?  F ----------------------------------------------------------------------  % Date: Thu, 29 May 2003 12:38:57 -0400 . From: "Jerry Alan Braga" <jabraga@flanagan.ca>( Subject: Alpha Upgrade sys$devices.dat ?/ Message-ID: <uJqBa.72$oD6.3572@news.on.tac.net>   K We are upgrading from an Alpha1200 to a DS25. The system is configured in a J cluster with another AS1200 node and an HSZ70 controller with quorum disk.   Current: =====  Node REN = AS1200 (dual 5/533)# Node STIMPY = AS1200 (single 5/400)    After: ==== Node REN = DS25 ! Node STIMPY = AS1200 (dual 5/533) K Other AS1200 to moved offsite for disaster and fresh standalone VMS install    Here are the issues:  : The Alpha1200's see the HSZ70 as pkb devices via the KZPBA3 The DS25 see the HSZ70 as pka devices via the KZPBA   E I cannot change this and here is the issue.  The sys$devices.dat file  contains following entries    0 ! CLUSTER_CONFIG created  3-JUL-1998 21:49:41.68   [Port REN$PKA] allocation class = 3/ ******************************** END OF PROGRAM   ********************************0 ! CLUSTER_CONFIG updated  3-JUL-1998 22:29:23.72   [Port STIMPY$PKB]  allocation class = 3    E According to this I have to change the [PortREN$PKB] to [PortREN$PKA] I I have been told I cannot just change the file before shutdown to the new K one and then boot DS25 with new file.  I have to use cluster config on boot  conversational.  What is this ?    !! Thanks in advance !!    ------------------------------  # Date: Thu, 29 May 2003 13:45:07 GMT # From: "John Smith" <a@nonymous.com> ) Subject: Re: Another VMS inquirer article J Message-ID: <D9oBa.274580$M81.199731@news02.bloor.is.net.cable.rogers.com>  7 "JF Mezei" <jfmezei.spamnot@istop.com> wrote in message # news:3ED55E16.5EF82E38@istop.com... @ > If HP is truly so intent on keeping and growing VMS, why is it acting as if it A > is slowly winding down VMS and forced to deny this whenever the  uproar grows! > above a certain decibel level ?  > F > If HP acted in a way consisted with its promises, customers wouldn't be? > confused as to the true intentiosn of HP with regards to VMS.  >  > F > In fairness to HP, I think it only really has committed to 2 things:@ > completing te port to IA64 and then supporting Alpha-VMS for a certain numberA > of years. It has not committed to growing VMS or marketing VMS.  > E > What HP is providing is bare minimum support for a mature platform.  It isn'tC > taking any actions to make the platform truly alive and thriving. 
 That wouldE > require mentioning VMS at every opportunity it can (especially if 0  dollars F > are allocated for marketing), and it would include telling the world that HP 4 > has taken onwership of VMS and intends to grow it. > E > Right now, all I have heard is that HP will honour commitments made 
 by Compaq.     JF,   F Strictly speaking that's both true and not true...(imagine a statement like that coming from me ;-) ).   E OVMS Engineering is adding lots of bells and whistles to/around VMS - A security products from Leo Demers group, IPV6, etc....The pace of D these additions isn't necessarily what we'd like to see...perhaps inC some cases it might be accurately described as glacial, and in part C that may be due to the amount of work going on to complete the IA64 A port as opposed to adding all the bits that would keep VMS adding A competitive 'bleeding edge' additions with the same timeliness as D unix/linux.  But then again, how much truly *new* development work -B greenfield projects (to borrow a construction industry term) - areC being done by VMS customers? Mostly it's maintaining what works, so + the need for 'bleeding edge' is a bit less.   F So let's take your thesis at face value...HP is adding stuff and doingC the port only so they can continue to suck money from customers who C have such a large commitment to VMS that it makes marginal sense at ? best for those customers to migrate from VMS in the next 5 - 10 @ years....stock exchanges, military apps, certain telco, lottery,C government. All HP is doing in this case is the same a Lockheed and E Boeing do on military contracts - charging $728 for a $14 toilet seat F cover - because that's what the market for these mission-critical apps
 will bear.  F That sort of gouging couldn't take place if VMS were mass marketed. In> doing so HP has decided that it wants to get a reputation as aC financial rapist to a 'select' group of customers. Eventually those ) customers will get tired of bending over.   F Read "Competitive Strategy" by David Porter. HP has chosen to keep VMS? in the high-cost, low-volume quadrant. Eventually, according to E Porter, this is a non-tenable strategy. Countless companies that have 6 gone bankrupt have given credence to this observation.   ------------------------------  # Date: Thu, 29 May 2003 13:49:20 GMT # From: "John Smith" <a@nonymous.com> ) Subject: Re: Another VMS inquirer article J Message-ID: <AdoBa.274621$M81.217160@news02.bloor.is.net.cable.rogers.com>  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3ED5602F.DD0B7710@fsi.net...  > Sue Skonetski wrote: > > , > > http://www.theinquirer.net/?article=9705 > F > If the author - and hp - would think things through a little deeper,$ > they'd answer their own questions. > < > To me, these were the most glaring errors (all in the same
 paragraph, > interestingly):  > @ > "Since most people don't buy OSes as stand-alone products ..." > ? > Everyone knows this. Stupid, weak excuse. The OS is part of a  package,E > but then the ENTIRE package must be advertised. HP doesn't do that, 	 > either.  > C > C'mon guys, let's stop making excuses. This isn't rocket science.  > $ > "...(Linux being an exception)..." > F > Well, yes and no. Yes, folks buy Linux without it being sold with orE > pre-loaded on a machine, generally speaking - if they pay for it at  all E > (it is "freely" downloadable, after all). Then again, no one "buys" ? > Linux just to have it on the shelf. They either load it on an  existing. > system or buy/build one on which to load it. > B > "...determining your target audience and message delivery system ought 6 > to be an interesting--and time consuming--exercise." > B > Interesting? Certainly! Time-consuming? If you're doing "all the right B > things", it's time well invested. If you're paying buku-bux to a bunch B > of yahoos to tell you what you already know, then you're pissing awayE > both time and money. If you're at least doing SOMEthing pro-active,  thenA > at least you're learning *AND* getting the word out at the same  time.  > ; > Some folks think its wasteful and foolish to advertise by E > trial-and-error, and to an extent, they're correct. Even if "Ma and  PaB > Kettle" go on cable-TV to say, "We run an ISP. Call us and we'll hookF > you up", at least they're getting exposure. When folks discover thatE > KettleNET is the sharpest ISP in the area, their business takes off  and E > they become known as the "great the ISP with the lousy ads". Or, as  a C > mentor of mine once said, "I'd rather see a crooked furrow than a  field  > unplowed". > C > Folks here can attest - I cut a *LOT* of crooked furrows, but I'm  not  > always wrong, either.     E If you were an employee of 'The New hp', not only would you be wrong, @ you'd likely be fired if you didn't toe the party line. I almostF wonder if there isn't a department inside The New hp with the initials NKVD or KGB.   ------------------------------    Date: 29 May 2003 09:10:55 -0500+ From: young_r@encompasserve.org (Rob Young) ) Subject: Re: Another VMS inquirer article 3 Message-ID: <FNLXSs9SJBoS@eisner.encompasserve.org>   p In article <D9oBa.274580$M81.199731@news02.bloor.is.net.cable.rogers.com>, "John Smith" <a@nonymous.com> writes:  E > That sort of gouging couldn't take place if VMS were mass marketed.     	Wake up, coffee is on - inhale.  > 	MVS isn't mass marketed either.  VMS makes up less than 5% of: 	Enterprise seats.  Business school grads won't let you doA 	things that make no sense in Business School 101, etc. etc. etc.    > H > Read "Competitive Strategy" by David Porter. HP has chosen to keep VMSA > in the high-cost, low-volume quadrant. Eventually, according to G > Porter, this is a non-tenable strategy. Countless companies that have 8 > gone bankrupt have given credence to this observation. >   = 	Infering HP is heading towards bankruptcy because they won't ; 	mass market our favorite niche product - something that is = 	a small portion of their overall business.  Give us a break.    				Rob    ------------------------------  % Date: Thu, 29 May 2003 07:43:42 -0700 # From: "Tom Linden" <tom@kednos.com> ) Subject: RE: Another VMS inquirer article 9 Message-ID: <CIEJLCMNHNNDLLOOGNJIAELGHEAA.tom@kednos.com>   8 What is % of sales and % of profit that VMS contributes?   >-----Original Message----- 3 >From: Rob Young [mailto:young_r@encompasserve.org] % >Sent: Thursday, May 29, 2003 7:11 AM  >To: Info-VAX@Mvb.Saic.Com* >Subject: Re: Another VMS inquirer article >  >  >In article A ><D9oBa.274580$M81.199731@news02.bloor.is.net.cable.rogers.com>,  & >"John Smith" <a@nonymous.com> writes: > F >> That sort of gouging couldn't take place if VMS were mass marketed. > ! >	Wake up, coffee is on - inhale.  > ? >	MVS isn't mass marketed either.  VMS makes up less than 5% of ; >	Enterprise seats.  Business school grads won't let you do B >	things that make no sense in Business School 101, etc. etc. etc. >  >>  I >> Read "Competitive Strategy" by David Porter. HP has chosen to keep VMS B >> in the high-cost, low-volume quadrant. Eventually, according toH >> Porter, this is a non-tenable strategy. Countless companies that have9 >> gone bankrupt have given credence to this observation.  >>   > > >	Infering HP is heading towards bankruptcy because they won't< >	mass market our favorite niche product - something that is> >	a small portion of their overall business.  Give us a break. >  >				Rob >  >---' >Incoming mail is certified Virus Free. ; >Checked by AVG anti-virus system (http://www.grisoft.com). A >Version: 6.0.484 / Virus Database: 282 - Release Date: 5/27/2003  >  --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.484 / Virus Database: 282 - Release Date: 5/27/2003   ------------------------------  # Date: Thu, 29 May 2003 15:25:54 GMT # From: "John Smith" <a@nonymous.com> ) Subject: Re: Another VMS inquirer article H Message-ID: <6EpBa.85502$cK1.30759@news01.bloor.is.net.cable.rogers.com>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:FNLXSs9SJBoS@eisner.encompasserve.org...  > In articleE <D9oBa.274580$M81.199731@news02.bloor.is.net.cable.rogers.com>, "John  Smith" <a@nonymous.com> writes:  > = > > That sort of gouging couldn't take place if VMS were mass 	 marketed.  > ! > Wake up, coffee is on - inhale.  > ? > MVS isn't mass marketed either.  VMS makes up less than 5% of ; > Enterprise seats.  Business school grads won't let you do B > things that make no sense in Business School 101, etc. etc. etc. >  > > F > > Read "Competitive Strategy" by David Porter. HP has chosen to keep VMS C > > in the high-cost, low-volume quadrant. Eventually, according to D > > Porter, this is a non-tenable strategy. Countless companies that have: > > gone bankrupt have given credence to this observation. > >  > > > Infering HP is heading towards bankruptcy because they won't< > mass market our favorite niche product - something that is> > a small portion of their overall business.  Give us a break.    9 Perhaps not corporate bankruptcy, but death of a product.    ------------------------------  % Date: Thu, 29 May 2003 12:01:42 -0400 * From: "Bill Todd" <billtodd@metrocast.net>) Subject: Re: Another VMS inquirer article 2 Message-ID: <A2Wdnel-Bpz8skujXTWcpQ@metrocast.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:FNLXSs9SJBoS@eisner.encompasserve.org...    ...   > > Infering HP is heading towards bankruptcy because they won't< > mass market our favorite niche product - something that is, > a small portion of their overall business.  I $800 million in annual profit 'a small portion' of HP's overall business?  Not the last time I looked.   D Oh, wait:  VMS doesn't generate anything like those numbers any moreB (despite Terry's rose-colored reference to it in the present tenseK recently).  Perhaps that was part of the Master Plan all along:  naturally, I if VMS profits had *continued* to dominate the corporation's bottom line, A cHumPaq might have found it difficult to concentrate on its 'core ? competencies' (whatever they might be, aside from selling ink).    - bill   ------------------------------  % Date: Thu, 29 May 2003 15:11:57 +0200 7 From: Robert Trawinski <robert.trawinski@softax.com.pl> & Subject: Digital Network Product Group/ Message-ID: <bb50ut$hpg$2@bozon2.softax.com.pl>    Hello,  B Does anybody know what happend with Digital Network Product Group.  G URL http://www.dnpg.com doesn't work. Few months ago visited this side   with no problem.   Robert   ------------------------------  % Date: Thu, 29 May 2003 08:44:42 -0500 ( From: brandon@dalsemi.com (John Brandon)* Subject: Re: Digital Network Product Group1 Message-ID: <03052908444249@dscis6-0.dalsemi.com>   D > Does anybody know what happend with Digital Network Product Group. > I > URL http://www.dnpg.com doesn't work. Few months ago visited this side   > with no problem. >  > Robert  L Comes up for me.  It is now DigitaNetworks - I do not know what the previous* page displayed.  It also has TECSys on it.   Check it out again.      John Brandon VMS Systems Administrator  Dallas Semiconductor first.last@dalsemi.com 972.371.4172 wk    ------------------------------  % Date: Thu, 29 May 2003 15:48:52 +0200 B From: Michiel Erens <I.dont.want.spam@this.mailaddress.is.invalid>* Subject: Re: Digital Network Product Group7 Message-ID: <3ED60FC4.7EFA@this.mailaddress.is.invalid>    Robert Trawinski wrote:  >  > Hello, > D > Does anybody know what happend with Digital Network Product Group. > H > URL http://www.dnpg.com doesn't work. Few months ago visited this side > with no problem.   It works here.   --   ME Posted by news://news.nb.nu    ------------------------------  % Date: Thu, 29 May 2003 09:55:07 -0400 0 From: "Alan Boyles" <alan.boyles@mindspring.com>* Subject: Re: Digital Network Product Group/ Message-ID: <vdc4698dov8u03@corp.supernews.com>   L Try www.digitalnetworks.net .  They recently moved their offices from Nashua; to Londonderry and the site was down.  They're still there.    AlanD "Robert Trawinski" <robert.trawinski@softax.com.pl> wrote in message) news:bb50ut$hpg$2@bozon2.softax.com.pl...  > Hello, > D > Does anybody know what happend with Digital Network Product Group. > H > URL http://www.dnpg.com doesn't work. Few months ago visited this side > with no problem. >  > Robert >    ------------------------------  # Date: Thu, 29 May 2003 13:59:18 GMT + From: LESLIE@JRLVAX.HOUSTON.RR.COM (leslie) * Subject: Re: Digital Network Product Group; Message-ID: <WmoBa.41346$A17.3163827@twister.austin.rr.com>   8 Robert Trawinski (robert.trawinski@softax.com.pl) wrote: : Hello, : D : Does anybody know what happend with Digital Network Product Group. : I : URL http://www.dnpg.com doesn't work. Few months ago visited this side   : with no problem. :   6 It works for me in Houston as of 29-MAY-2003 08:57:20:        http://www.dnpg.com/       Digital Networks - Home   Try it by its IP address:         http://209.113.246.205/  2 --Jerry Leslie   (my opinions are strictly my own)9   Note: leslie@jrlvax.houston.rr.com is invalid for email    ------------------------------  % Date: Thu, 29 May 2003 15:48:00 +0200 7 From: Robert Trawinski <robert.trawinski@softax.com.pl> * Subject: Re: Digital Network Product Group/ Message-ID: <bb532g$i45$1@bozon2.softax.com.pl>    Robert Trawinski wrote:  > Hello, > D > Does anybody know what happend with Digital Network Product Group. > I > URL http://www.dnpg.com doesn't work. Few months ago visited this side   > with no problem. >  > Robert >    It works now   Robert   ------------------------------  % Date: Thu, 29 May 2003 09:09:39 +0100 ( From: Nic Clews <sendspamhere@127.0.0.1>! Subject: Re: ES40 and CPU upgrade ) Message-ID: <3ED5C043.F7D0EAC1@127.0.0.1>    DigiDemon wrote: > I > Real quick...we have just bought a 887 mtz CPU for our spiffy ES40.  We L > needed this to support our SmartArray 5304 card.  Anyone ever run into any > snags doing this?  Thanks!  G Have the latest copy of the firmware CD, or the relevant files from the = download site handy, and you'll need VMS 7.2-2 or above IIRC.    --  ? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences  nclews at csc dot com    ------------------------------  + Date: Thu, 29 May 2003 08:44:04 +0100 (MET) 9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>  Subject: Re: Firmware Upgrade ; Message-ID: <01KWGHCQEVGYAM3M2Q@sysdev.deutsche-boerse.com>   J > >What is the latest version of the firmware available for each of these F > >machines?  Is there a list with such information, preferably in an I > >easily digestible form, on the web somewhere?  If 5.9 or later is not  H > >available, what are the chances of running 7.3-1 on these machines?   > >Anyone done so already? > # > V7.3-1 runs fine on both systems.   8 That is excellent news.  I hope that 7.3-2 will as well!  L > Alpha firmware version numbers vary a lot from one system to another.  The; > minimum and recommended FW versions are system-dependent.  > H > You can see the FW version of a running VMS system via the SDA commandK > CLUE CONFIG.  The "Console Vers" field is the SRM console. The "PAL Code" E > field is the VMS PALcode version.  These two numbers are completely E > independent of each other.  VMS generally worries about the console  > version field.  / What does F$GETSYI("CONSOLE_VERSION") indicate?   L > On recent VMS versions, SHOW CPU/FULL gives much of the same information. H > There are a few other ways a well, which I won't try to get right from	 > memory.  > L > The most recent SRM version for the DEC 3000 family of systems is V7.0.  IJ > don't know the most recnet for the Alphastation 255/233.  Whatever is on% > the FW web site is the most recent.   D Obviously, I am confused.  For example, the "Alpha Systems Firmware G Update V6.2 Release Notes Overview" (this is in the CD packaging) says:   F    Starting with the V6.1 Alpha Systems Firmware Update CD, files for G    systems that have not had a new firmware release for at least three  I    years will be dropped from the CD.  Firmware images for the following  "    systems are no longer included:  # It then lists ALPHA255 and DEC3000.    This CD is from May 2002.   G It also has a list of "Minimum Acceptable FW CD Versions for Recent OS  G Releases".  For VMS 7.3 it lists FW CD V5.9.  Obviously, it is talking  * about the version of the firmware CD here.  I Thus, apparently the last firmware release for the 255 and 3000 was 1999  G or before.  If you say that 7.3-1 runs fine on these systems, then the  @ V5.9 firmware CD must have contained firmware for these systems.   Or am I completely confused.  D Let's ask the question another way: what is the last version of VMS G which will run on the 3000?  The 255?  7.3-2?  8.something?  (I'm just  . looking for educated guesses here, of course.)   ------------------------------  + Date: Thu, 29 May 2003 10:42:18 +0000 (UTC) + From: david20@alpha1.mdx.ac.uk (David Webb)  Subject: Re: Firmware Upgrade + Message-ID: <bb4o6a$e87$1@aquila.mdx.ac.uk>   w In article <01KWGHCQEVGYAM3M2Q@sysdev.deutsche-boerse.com>, Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> writes: K >> >What is the latest version of the firmware available for each of these  G >> >machines?  Is there a list with such information, preferably in an  J >> >easily digestible form, on the web somewhere?  If 5.9 or later is not I >> >available, what are the chances of running 7.3-1 on these machines?    >> >Anyone done so already?  >>  $ >> V7.3-1 runs fine on both systems. > 9 >That is excellent news.  I hope that 7.3-2 will as well!  > M >> Alpha firmware version numbers vary a lot from one system to another.  The < >> minimum and recommended FW versions are system-dependent. >>  I >> You can see the FW version of a running VMS system via the SDA command L >> CLUE CONFIG.  The "Console Vers" field is the SRM console. The "PAL Code"F >> field is the VMS PALcode version.  These two numbers are completelyF >> independent of each other.  VMS generally worries about the console >> version field.  > 0 >What does F$GETSYI("CONSOLE_VERSION") indicate? > M >> On recent VMS versions, SHOW CPU/FULL gives much of the same information.  I >> There are a few other ways a well, which I won't try to get right from 
 >> memory. >>  M >> The most recent SRM version for the DEC 3000 family of systems is V7.0.  I K >> don't know the most recnet for the Alphastation 255/233.  Whatever is on & >> the FW web site is the most recent. > E >Obviously, I am confused.  For example, the "Alpha Systems Firmware  H >Update V6.2 Release Notes Overview" (this is in the CD packaging) says: > G >   Starting with the V6.1 Alpha Systems Firmware Update CD, files for  H >   systems that have not had a new firmware release for at least three J >   years will be dropped from the CD.  Firmware images for the following # >   systems are no longer included:  > $ >It then lists ALPHA255 and DEC3000. >  >This CD is from May 2002. > H >It also has a list of "Minimum Acceptable FW CD Versions for Recent OS H >Releases".  For VMS 7.3 it lists FW CD V5.9.  Obviously, it is talking + >about the version of the firmware CD here.  > J >Thus, apparently the last firmware release for the 255 and 3000 was 1999 H >or before.  If you say that 7.3-1 runs fine on these systems, then the A >V5.9 firmware CD must have contained firmware for these systems.  >  >Or am I completely confused.  > E >Let's ask the question another way: what is the last version of VMS  H >which will run on the 3000?  The 255?  7.3-2?  8.something?  (I'm just / >looking for educated guesses here, of course.)   I See the SPD which contains a list of the VAX and alpha systems supported.   2 http://h18000.www1.hp.com/info/SP2501/SP2501PF.PDF  < The list of supported systems is towards the end of the SPD.  O For alpha systems practically every alpha ever produced is still supported with N VMS. This is not the case with TRU64 where the turbochannel based systems were  all dropped at around TRU64 5.1.9 VMS 7.3-1 will be the final supported version of VMS for  / DEC 2000 Models 300/500 and Tadpole AlphaBook1.   I The situation with VAX systems is not so good. HP decided to drop a large  number after VMS 7.3.        
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  % Date: Thu, 29 May 2003 12:32:21 +0100 , From: Ted Allwood <support@leva.leeds.ac.uk> Subject: re: Firmware Upgrade 3 Message-ID: <00A20966.D08200A8.38@leva.leeds.ac.uk>   A I haven't been following the Firmware thread closely so apologies # if this has already been mentioned.   ? One thing that I find useful for logging output at the console  E subsystem level on my Alpha server is to connect a lead back-to-back  J between the console serial port and a serial port tta1 on a faithful, but # little used, non-clustered microVax   # For the server, I issue the command  >>> set console serial  N On the microVax, I create a session log so that all terminal i/o is recorded.  Then 	$ set host/dte tta1 and I get alpha's >>> prompt  G I can then issue various show commands followed by the firmware upgrade , then repeat the show commands.  Then finally >>> set console graphics >>> init  9 The server boots from the normal console, leaving me with $ a session logfile on the microVax.       Regards, Ted    --  K Support@leva.leeds.ac.uk                                Tel:  0113 34 32167 + www.mech-eng.leeds.ac.uk/support/index.html G School of Mechanical Engineering,  University of Leeds,  Leeds  LS2 9JT    ------------------------------  + Date: Thu, 29 May 2003 13:46:55 +0100 (MET) 9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>  Subject: Re: Firmware Upgrade ; Message-ID: <01KWGS0LW59WAKVGCS@sysdev.deutsche-boerse.com>   K > See the SPD which contains a list of the VAX and alpha systems supported.  > 4 > http://h18000.www1.hp.com/info/SP2501/SP2501PF.PDF > > > The list of supported systems is towards the end of the SPD.  7 OK, looks like my hobbyist machines are OK for a while!    When will the 7.3-2 SPD be out?   J > VMS 7.3-1 will be the final supported version of VMS for DEC 2000 Models" > 300/500 and Tadpole AlphaBook1.   D Great!  That means that prices will plummet for the AlphaBook1!  :-)  A There is a company in England which still sells and services the  > AlphaBook1.  It IS a bit expensive, but would be nice to have.  E > The situation with VAX systems is not so good. HP decided to drop a  > large number after VMS 7.3.   D True.  On the other hand, I doubt that anyone running a Big Old VAX G actually runs a new version of VMS.  Of the machines for which 7.2 was  A the last release, how many were actually running 7.2?  7.x?  6.x?    ------------------------------    Date: 29 May 2003 10:52:57 +0200B From: holitska_a@cut-it-outludens.elte.hu (Holi - Holitska Andrs)8 Subject: Re: Getting LK411-AA keyboard to work correctly! Message-ID: <ys+fFYbtyNCF@ludens>   S In article <3ED53D5E.4070201@nowhere.com>, Don Rogstad <nobody@nowhere.com> writes: F > I have an AlphaServer 1000A 5/400 server running OpenVMS V7.3-1.  ItG > came with a RT6856T (which I assume is a LK443AA_PC) which is the PC  I > keyboard layout.   I have since acquire a LK411 keyboard (one that has  D > the "DO" key etc), but I can't get DECWindows Motif CDE v1.2-6 to G > recongnise it.  Motif still thinks it is a PC style keydoard and the   > "DO" key doesn't work. >  >    I have tried:9 > 1) Ensuring that the keyboard console variable to LK411 H > 2) Setting the keyboard type to "NORTH_AMERICAN_LK401AA" in the Style 
 > Manager.K > 3) I thought I tried setting the variable "DECW$DEFAULT_KEYBOARD_MAP" to  H >   "NORTH_AMERICAN_LK401AA" in the DECW$PRIVATE_SERVER_SETUP.COM file, / > but I see that it is commented out right now.  > J > Does anyone know how to get this keyboard recongnized as a true Digital K > keyboard?   I did notice in the AlphaServer 1000A 5/400 Golden Eggs that  H > it refers to the keyboard for VMS as LK461.  Does this mean the LK411 
 > won't work?   D   Didn't had experience with that type of keyboard myself, but maybe   this could help you...  F   Have you tried rebooting the machine, or did you just plugged in theG   new keyboard? I've had some trouble with keyboards on an AlphaStation D   when I plugged it in without a reboot. It seems that some keyboardB   initialisation occurs at power-on, which I wasn't able to repeatH   after powering on the machine (btw. if anyone knows how I could repeat?   that initialisation without a reboot, please let us know :]).   E   Oh, and I just checked, i've got an RT6856T sitting here too, which E   I configured to act more like a d|i|g|i|t|a|l keyboard, and changed C   Scroll Lock to Do and Pause to Compose (well, Alt might have been 7   a better choise for Compose, but I can live with it).   0   You can download the modified decw$keymap from  E     http://ludens.elte.hu/~holitska_a/vmsspeci/holi_pc101.decw$keymap   D   if you like, and if you can't get the keyboard to work. To use it,C   copy it to SYS$COMMON:[SYS$KEYMAP.DECW.USER] and give read access B   to the user(s) (or world) who you will allow it's usage. Then go@   to the DECwindows keyboard settings menu and select HOLI_PC101B   from the list (maybe you should rename it to rt6856t.decw$keymap$   or something more descriptive :]).     Hope this helps.  	 > Thanks, 
 > Don Rogstad ! > newvision at <lastname> dot com    Bye: <Holi>   F PS: I've changed the home, end etc. keys to more appropiate functions,     you can check details on  =       http://ludens.elte.hu/~holitska_a/vmsspeci/anyagok.html   D    The page is in hungarian, but they keyboard map is in english. ;] --  H Holitska, Andrs    holitska_a@cut-it-outludens.elte.hu   Junior ManagerG  ...................................................................... G  VMS Competence Center                            VMS Szakrti Kzpont G  Etvs Lornd University                 Etvs Lornd Tudomnyegyetem G  Budapest, Hungary                                             Budapest G  ======================================================================    ------------------------------  % Date: Thu, 29 May 2003 09:07:48 +0100 ( From: Nic Clews <sendspamhere@127.0.0.1>0 Subject: Re: Hobbyist seeks generic SIMM vendors) Message-ID: <3ED5BFD4.8762A0C2@127.0.0.1>    Alder wrote: > I > No. it has the fifth.  I was referring only to the memory that "counts" < > when talking about how much RAM a system has to work with.  E The memory is parity (36 bit) 60ns. The 'fifth bank' is the ECC bank,  also parity.  F So you populate bank 0 lets say (4 SIMMs), and also the first position@ of the ECC array with the SAME type of memory (1 SIMM), 5 total.  
 Bank1-ECC1
 Bank2-ECC2
 Bank3-ECC3   DOes this help?  --  ? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences  nclews at csc dot com    ------------------------------  % Date: Thu, 29 May 2003 10:56:20 -0700 * From: "Alder" <MUNDDGNTDYTV@spammotel.com>0 Subject: Re: Hobbyist seeks generic SIMM vendors+ Message-ID: <3ed649c4$1@obsidian.gov.bc.ca>   J Yes, thanks Nic, and to all who responded.  I'll hang on to the five SIMMsF that are currently installed in ECC0/Bank0 and simply add to that with 5-SIMM "options".    Cheers,  Alder   5 "Nic Clews" <sendspamhere@127.0.0.1> wrote in message # news:3ED5BFD4.8762A0C2@127.0.0.1...  > Alder wrote: > > K > > No. it has the fifth.  I was referring only to the memory that "counts" > > > when talking about how much RAM a system has to work with. > G > The memory is parity (36 bit) 60ns. The 'fifth bank' is the ECC bank,  > also parity. > H > So you populate bank 0 lets say (4 SIMMs), and also the first positionB > of the ECC array with the SAME type of memory (1 SIMM), 5 total. >  > Bank1-ECC1 > Bank2-ECC2 > Bank3-ECC3 >e > DOes this help?  > --A > Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciencesr > nclews at csc dot com    ------------------------------  % Date: Thu, 29 May 2003 12:39:41 -0400r& From: David M Smith <dsmit115@csc.com>/ Subject: Re: How to make a shadowed system diskw8 Message-ID: <4tdcdv48ei9fuv4be2m5hpk4v9r5gh3g1e@4ax.com>  G On 29 May 03 07:21:05 +0200, p_sture@elias.decus.ch (Paul Sture) wrote:i  D >Not so much rare, as unsupported, and has been that way for years.  >a= >SYSGEN HELP Sys_Parameters SHADOWING no longer documents it.     Well, it does on my V7.3 system:  * $ mcr sysgen help sys_parameters shadowing   SYS_PARAMETERS     SHADOWINGc  E        SHADOWING enables or disables shadowing and specifies the mode D        of shadowing operations that you want to enable. SHADOWING isC        a value that specifies the type of disk class driver that is H        loaded on the system: DUDRIVER, DSDRIVER, or SHDRIVER. See VolumeF        Shadowing for OpenVMS for more information about setting system'        parameters for volume shadowing.d  +        Specify one of the following values:           Value  Descriptionh  F        0      No shadowing is enabled; SHDRIVER is not loaded. This is                the default value.  F        2      Phase II shadowing enabled. SHDRIVER is loaded. Phase IID               shadowing provides shadowing of all disks located on a=               standalone system or an OpenVMS Cluster system.V  G        Note that a parameter value of 1 represents Phase I, which is noo9        longer supported. Instead, use Phase II shadowing. I -------------------------------------------------------------------------tI David M. Smith 302.391.8533                       dsmit115 at csc dot com I Computer Sciences Corporation     (Opinions are those of the writer only)bI -------------------------------------------------------------------------    ------------------------------    Date: 29 May 2003 07:38:55 -0700% From: wsmith@smausa.com (Wendy Smith)  Subject: Install Directory= Message-ID: <57ee6a43.0305290638.25812eb1@posting.google.com>-  B What, if any, is the convention regarding the directory into whichK third-party software should be loaded in preparation for an installation ofUG the software? We are currently installing in [000000], and a client has I indicated it is "more appropriate" to install in SYS$MANAGER. I am new toiE the Alpha VMS world, and thus have no fact-based opinion of my own...r   I appreciate your response!o   ------------------------------  % Date: Thu, 29 May 2003 10:17:53 -0500:( From: brandon@dalsemi.com (John Brandon) Subject: Re: Install Directory1 Message-ID: <03052910175390@dscis6-0.dalsemi.com>   D > What, if any, is the convention regarding the directory into whichM > third-party software should be loaded in preparation for an installation of I > the software? We are currently installing in [000000], and a client has K > indicated it is "more appropriate" to install in SYS$MANAGER. I am new to.G > the Alpha VMS world, and thus have no fact-based opinion of my own...* >  > I appreciate your response!*  M There is no standard that I know of, however I would recommend that given theY4 selection I would install TP-LP on non-system disks.  J This takes the burden off the system disk which in turns allows for better5 performance and easier management & maintenance, etc.n  K Though some TP-LP do not allow for installation other than the system disk,aO however most of the applications I have installed (both LP and TP-LP) ask for a- destination disk.2      	 Thoughts:0  L (1) A TP-LP may require a 10,000 blocks of disk for minimal install, howeverK that TP-LP may generate 20,000 blocks of log files a day.  This adds up andr impacts the system disk.  N Keep the system disk clean of clutter!  If TP-LP goes wild on your system disk$ your server gets hung or goes crash!  G Also, if your system disk is local to a specific server and you have andM installed application that serves the cluster you will have problems.  Devicee7 timeouts, hung applications, inaccesable products, etc.s        # (2) Do a show device sys$sysdevice:t  K Device                  Device      Error    Volume         Free  Trans MnttK Name                    Status      Count     Label        Blocks Count CntaJ $1$DGA100:    (XXXXXX)  Mounted         0  LLLLLLLL       3674398  1693  2  O You will notice the Trans Count.  This reflects the number of files open on themL system disk.  A good rule of thumb: the lower the number the better possible5 performance (in general theory).  So spread the love.u        . (3) Look at WIS (DSN) and do a Tech Search for  % http://relay.support.compaq.com:9004/a  . "Methods Used To Recover Space On System Disk"    M This article will describe the methods used to recover disk space on a systemlK disk.  This indirectly reflects the need to keep the system disk as clutter  free as possible.         O I personally like to keep my non-O/S products off the system disk.  Your client N indicates that it is "more appropriate" to keep them on the system disk - I amN not sure why.  Do they have a 36-GB system disk?  Are they limited to space onO other drives?  It is good management to keep the system disk clean.  It is goodlN management to keep good data management (disk for applications, disk for data,7 disk for logs, disk for this-that-and-the-other-thing.)        John Brandon VMS Systems Administratorv Dallas Semiconductor first.last@dalsemi.com 972.371.4172 wkl   ------------------------------   Date: 29 May 2003 15:54:03 GMT( From: ka2doug@cs.commoc.sc (DL Phillips) Subject: Re: Install Directory> Message-ID: <20030529115403.07518.00000583@mb-m22.news.cs.com>  ' >From: wsmith@smausa.com  (Wendy Smith) / >Date: 05/29/2003 9:38 AM Central Daylight Timed> >Message-id: <57ee6a43.0305290638.25812eb1@posting.google.com> >nC >What, if any, is the convention regarding the directory into whichaL >third-party software should be loaded in preparation for an installation ofH >the software? We are currently installing in [000000], and a client hasJ >indicated it is "more appropriate" to install in SYS$MANAGER. I am new toF >the Alpha VMS world, and thus have no fact-based opinion of my own... >  >I appreciate your response! >f  O The standard place for temporary files is SYS$SCRATCH. This is the logical nameaK of the account's login default directory. If you're logged in as SYSTEM, itt points to SYS$MANAGER. c  O That means if you use SYS$SCRATCH you must beware of causing conflict with thatt directories existing files.   E Therefore, many TP's create a temporary directory under [000000] or ae@ subdirectory under SYS$MANAGER and then remove it when finished.  L Or, you could just prompt for a dev:[directory] and let the user worry about where it goes.  O There is no "standard" for where the TP software untimately should reside other3I than normal considerations for performance, backups, space and all of theVL normal concerns dependant on the system configuration, what type of load theN software presents and,... well,... I guess you'll need to either read the restL of the book...or prompt the user for that, too, and let them worry about it.    DL Phillips   ------------------------------    Date: 29 May 2003 12:00:03 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)i Subject: Re: Install Directory3 Message-ID: <q+ld654weuXY@eisner.encompasserve.org>a  e In article <57ee6a43.0305290638.25812eb1@posting.google.com>, wsmith@smausa.com (Wendy Smith) writes: D > What, if any, is the convention regarding the directory into whichM > third-party software should be loaded in preparation for an installation ofiI > the software? We are currently installing in [000000], and a client hasnK > indicated it is "more appropriate" to install in SYS$MANAGER. I am new tofG > the Alpha VMS world, and thus have no fact-based opinion of my own...g  A Temporary directory storage during installation should be managedoA by either VMSINSTAL or PRODUCT INSTALL, the two supported methods 4 of installing software, under control of the vendor.  B If you are talking about copying the installation kits temporarilyB to magnetic disk to speed running one of those installation tools,A "wherever it fits" should do.  I tend to make a subdirectory fromn my own login directory.i  @ There is a lot of rigor for where the finished product should be> put by the installation process, but that is up to the vendor.> As I understand it, that was not your question, as you are not the vendor..   ------------------------------  % Date: Thu, 29 May 2003 09:11:46 +0100e( From: Nic Clews <sendspamhere@127.0.0.1>  Subject: Re: Invalid Disk format) Message-ID: <3ED5C0C2.75AB7CD7@127.0.0.1>    Alan Boyles wrote: > N > I was trying to install VMS 7.3-1 on an AlphaStation 500/500 ( yea, I got itL > working- see power problem ).  The system has 2 disks DKA0 and DKA100.  AtN > the >>> prompt I do a show device and they both show up as RZ1BB-BS but whenI > I tried to init dka0 as the system disk ( and when I try to init at DCL L > prompt ) I am getting an INIT-F-INVALID Invalid Media Format.  This systemK > orginally had NT on it and I am assuming that this is happening due to NTs@ > formating the disk.  How can I get this disk into ODS format ?  2 If you're sure you want to lose the data on there,, INIT/OVER=(OWN,ACC,EXP) should do the trick.  B I think the issue is that the INIT attempt to read volume data forD expiration and other fields, which should be self explanatory if you view the HELP for init).   -- -? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences. nclews at csc dot comc   ------------------------------  % Date: Thu, 29 May 2003 08:01:54 -0400m0 From: "Alan Boyles" <alan.boyles@mindspring.com>  Subject: Re: Invalid Disk format/ Message-ID: <vdbti2abppqs7f@corp.supernews.com>   " Aren't those qualifiers for tapes?  5 "Nic Clews" <sendspamhere@127.0.0.1> wrote in messagen# news:3ED5C0C2.75AB7CD7@127.0.0.1...d > Alan Boyles wrote: > > I > > I was trying to install VMS 7.3-1 on an AlphaStation 500/500 ( yea, Ii got itJ > > working- see power problem ).  The system has 2 disks DKA0 and DKA100. AtK > > the >>> prompt I do a show device and they both show up as RZ1BB-BS buto whenK > > I tried to init dka0 as the system disk ( and when I try to init at DCLeG > > prompt ) I am getting an INIT-F-INVALID Invalid Media Format.  Thiso systemJ > > orginally had NT on it and I am assuming that this is happening due to NTB > > formating the disk.  How can I get this disk into ODS format ? >l4 > If you're sure you want to lose the data on there,. > INIT/OVER=(OWN,ACC,EXP) should do the trick. >aD > I think the issue is that the INIT attempt to read volume data forF > expiration and other fields, which should be self explanatory if you > view the HELP for init). >c > --  A > Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciencesr > nclews at csc dot como   ------------------------------  % Date: Thu, 29 May 2003 14:18:09 +01002( From: Nic Clews <sendspamhere@127.0.0.1>  Subject: Re: Invalid Disk format) Message-ID: <3ED60891.1E7E0E04@127.0.0.1>5   Alan Boyles wrote: > $ > Aren't those qualifiers for tapes?  H Yes, but they appear to apply to disks as well. Been there, seen it, hadE to do it, found it successful*. Both NT and OSF formatted disks don't E agree with the VMS file system. However it makes some sense that INIT	D would try to read before performing the required function. IIRC, theH early VMS documentation (or even courses) said that non priv users couldG also mount their own disks but even at that level you'd need to protectiF using volume ownership which one non privileged user could do compared% to the owner, but equally privileged.t  B It was probably more relevant when hard disks were (more commonly)
 removable.  G I've never granted that as a system manager, never had to, but I've lettD users use tapes before now, and that's where saveset protection etc.	 comes in.   H * Command takes even for disks. HELP says only OWNER_IDENTIFER is useful1 for disks implicitly, so I accept the correction.   7 > "Nic Clews" <sendspamhere@127.0.0.1> wrote in message.  6 > > If you're sure you want to lose the data on there,0 > > INIT/OVER=(OWN,ACC,EXP) should do the trick. > >yF > > I think the issue is that the INIT attempt to read volume data forH > > expiration and other fields, which should be self explanatory if you > > view the HELP for init).     -- M? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer SciencesS nclews at csc dot coms   ------------------------------  % Date: Thu, 29 May 2003 15:26:21 +0100b+ From: John Laird <john@laird-towers.org.uk>m  Subject: Re: Invalid Disk format8 Message-ID: <mi5cdv02icmuskef3a6uo24sjgtmatilhn@4ax.com>  F On Thu, 29 May 2003 14:18:09 +0100, Nic Clews <sendspamhere@127.0.0.1> wrote:  % >> Aren't those qualifiers for tapes?a >pI >Yes, but they appear to apply to disks as well. Been there, seen it, had F >to do it, found it successful*. Both NT and OSF formatted disks don'tF >agree with the VMS file system. However it makes some sense that INIT; >would try to read before performing the required function.   G But only to see if any recognised file system (so ODS only) was present G which contained security information to be checked.  Foreign rubbish is L foreign rubbish is foreign rubbish, and can be wiped.  Tapes are a differentE matter in that ANSI standards exist - iirc there isn't a VMS-specific 3 format, all tapes written with VMS conform to ANSI.y  K "Invalid media format" sounds like one of those horrible ways VMS tells you B it doesn't really like the drive for one reason or another.  TakenH literally, it might mean it is not 512-byte sectored, but these are very- rare (I think someone had 516-bytes on scsi).0     	JohnB   ------------------------------  # Date: Thu, 29 May 2003 13:56:02 GMTi# From: "John Smith" <a@nonymous.com>WY Subject: Re: Letter to HP Management from OpenVMS users around the world ... Shape up or 9I Message-ID: <SjoBa.274687$M81.10512@news02.bloor.is.net.cable.rogers.com>r   <Jason Brady> wrote in message2 news:36sadvs209eh468s757r7buaa0cc4p8m38@4ax.com...A > On Thu, 22 May 2003 16:33:58 GMT, "John Smith" <a@nonymous.com>i wrote: >l > >> Write to the following: >  > [list omitted] >o > John,t >mE > Thanks for posting this information.  I wrote the following letter,bA > with alterations depending on the recipient, to the entire listp except< > the institutional investors.  Will advise if I receive any
 responses. >lF > -------------------------------------------------------------------- -- > [salutation] > ? > I am writing you, a Hewlett-Packard board member, to voice mys concerne= > that HP is making a serious mistake--one that is denying HP-	 customers-B > of quality solutions to their business needs and shareholders of  > potentially lucrative returns. >.@ > The mistake is HP's failure to actively promote and market its OpenVMSoA > operating system to customers, educational institutions and the B > information technology industry.  In fact, it appears that HP isE > intent on slowly killing off this excellent product--one of the few-C > products capable of driving earnings and profits to higher levels  than7 > is possible with commodity product lines such as PCs.l >tD > Please review the attached article which eloquently discusses this4 > subject in depth.  [photocopy of Inquirer article] > @ > In addition to being a customer and shareholder, I welcome theD > opportunity to develop application software for OpenVMS...but only@ > when HP demonstrates a genuine commitment to building OpenVMS' market* > share across a wide range of industries. >hD > Please join me in urging HP management to either take advantage ofF > this opportunity or to sell the OpenVMS operating system division to1 > another company that recognizes its true value.8 > , > Thank you for your time and consideration. >s
 > Regards, >.
 > [signature]c    @ Great letter. Everybody should write one like this to each boardF member, and I submit, to large institutional shareholders. Send a copyB to the tech analyst at your stockbroker/mutual fund company with aD cover letter. Ask them to ask similar questions of HP management andF institutional investors they are in daily contact with. Send a copy to@ the Editor of the Wall Street Journal, Barrons, Financial Times,? Investors Daily, Fortune, Forbes, Business Week suggesting thats there's a story to be had.  : Get enough letters pouring in to places like these and who: knows....editors tend to suspect fire when they see smoke.   ------------------------------  % Date: Thu, 29 May 2003 11:08:48 +0100T* From: "Matt Simis" <mattsimis@hotmail.com>1 Subject: Mystery Alpha CPUS, what do they fit in?a5 Message-ID: <bb4m7g$5rlec$1@ID-131939.news.dfncis.de>,  D I have seen these on eBay (even bought one :(  and around on various	 websites:R* http://www.dyna-comp.com/html/cpd/cpu.html  H What the hell are are these (21264 ones) for? I just cant get a straightI answer on why there seems to be an abundance of socket based cpus with noJ
 motherboards?R   Have look at the page for pics.l Does any one have a clue?s     Matt   ------------------------------  % Date: Thu, 29 May 2003 08:10:40 -0400t5 From: David Beatty <David.Beatty@qwertysasasdfgh.com>y5 Subject: Re: Mystery Alpha CPUS, what do they fit in?u2 Message-ID: <H=jVPqnLNvIB5G4bhmS=V0YG3d+o@4ax.com>  0 On Thu, 29 May 2003 11:08:48 +0100, "Matt Simis" <mattsimis@hotmail.com> wrote:  E >I have seen these on eBay (even bought one :(  and around on variousN
 >websites:+ >http://www.dyna-comp.com/html/cpd/cpu.html: >0I >What the hell are are these (21264 ones) for? I just cant get a straighteJ >answer on why there seems to be an abundance of socket based cpus with no >motherboards? >   >Have look at the page for pics. >Does any one have a clue? >t >i >Mattf >.  1 I used http://www.google.com/ to search for 21264 , and found a link that answers your question:  . http://www.microprocessor.sscc.ru/alpha-21264/  , The 21264B is an Alpha EV68 and the 21264 is
 an Alpha EV6..   David R. Beattyw   ------------------------------  % Date: Thu, 29 May 2003 16:45:21 +0100b* From: "Matt Simis" <mattsimis@hotmail.com>5 Subject: Re: Mystery Alpha CPUS, what do they fit in? 5 Message-ID: <bb59uk$5o3fi$1@ID-131939.news.dfncis.de>@  B "David Beatty" <David.Beatty@qwertysasasdfgh.com> wrote in message, news:H=jVPqnLNvIB5G4bhmS=V0YG3d+o@4ax.com...2 > On Thu, 29 May 2003 11:08:48 +0100, "Matt Simis"  > <mattsimis@hotmail.com> wrote: > G > >I have seen these on eBay (even bought one :(  and around on variouso > >websites:- > >http://www.dyna-comp.com/html/cpd/cpu.html, > >hK > >What the hell are are these (21264 ones) for? I just cant get a straight L > >answer on why there seems to be an abundance of socket based cpus with no > >motherboards? > > " > >Have look at the page for pics. > >Does any one have a clue? > >: > >  > >MattT > >r > 3 > I used http://www.google.com/ to search for 21264 . > and found a link that answers your question: >C0 > http://www.microprocessor.sscc.ru/alpha-21264/ >s. > The 21264B is an Alpha EV68 and the 21264 is > an Alpha EV6.  >m > David R. Beattya >s    * Thats somewhat helpful, but doesnt answer:  L What motherboard, what systems came with said CPUs and why are there so many( CPUs floating that have no motherboards?  G That page shows all the 21264 Cpus as being "PGA" packages, yet all theoI 21264 CPUs Im aware of are surface mounted to the PCB on a Daughterboard.!: Perhaps Im misunderstanding the use of "PGA" here however.     Matt   ------------------------------  # Date: Thu, 29 May 2003 16:46:11 GMT # From: "John Smith" <a@nonymous.com> 5 Subject: Re: Mystery Alpha CPUS, what do they fit in? H Message-ID: <nPqBa.85626$cK1.42100@news01.bloor.is.net.cable.rogers.com>  5 "Matt Simis" <mattsimis@hotmail.com> wrote in message / news:bb59uk$5o3fi$1@ID-131939.news.dfncis.de...r > D > "David Beatty" <David.Beatty@qwertysasasdfgh.com> wrote in message. > news:H=jVPqnLNvIB5G4bhmS=V0YG3d+o@4ax.com...4 > > On Thu, 29 May 2003 11:08:48 +0100, "Matt Simis"" > > <mattsimis@hotmail.com> wrote: > >IA > > >I have seen these on eBay (even bought one :(  and around on  variouso > > >websites:/ > > >http://www.dyna-comp.com/html/cpd/cpu.htmls > > >tD > > >What the hell are are these (21264 ones) for? I just cant get a straightF > > >answer on why there seems to be an abundance of socket based cpus with nop > > >motherboards? > > >r$ > > >Have look at the page for pics. > > >Does any one have a clue? > > >  > > > 	 > > >Mattd > > >  > > 5 > > I used http://www.google.com/ to search for 21264s0 > > and found a link that answers your question: > >h2 > > http://www.microprocessor.sscc.ru/alpha-21264/ > >e0 > > The 21264B is an Alpha EV68 and the 21264 is > > an Alpha EV6.C > >f > > David R. Beattya > >a >  >t, > Thats somewhat helpful, but doesnt answer: > F > What motherboard, what systems came with said CPUs and why are there so manyb* > CPUs floating that have no motherboards? >sE > That page shows all the 21264 Cpus as being "PGA" packages, yet all  thef< > 21264 CPUs Im aware of are surface mounted to the PCB on a Daughterboard.< > Perhaps Im misunderstanding the use of "PGA" here however.    ? Not familiar with the Samsung parts, but perhaps Samsung made ai> different packaging decision for the CPU's and boards they/API	 produced.8   ------------------------------    Date: 29 May 2003 07:35:58 -0500+ From: young_r@encompasserve.org (Rob Young) % Subject: Re: New MiniMerge capability 3 Message-ID: <++I826b61edM@eisner.encompasserve.org>:  a In article <w18U9qjhZ66H@eisner.encompasserve.org>, young_r@encompasserve.org (Rob Young) writes:Qa > In article <ivbM3zujkh8h@cuebid.zko.dec.com>, brooks@cuebid.zko.dec.nospam (Rob Brooks) writes:t0 >> young_r@encompasserve.org (Rob Young) writes: > C >>> Can anyone in engineering give an overview of how it will work?  >> 	Yes, a few of us could :-).g >> lF >> 	We don't have the design details worked out yet.  For those of you< >> who will be at either the Vienna or London meetings, JohnO >> Andruszkziewicz will have a few slides that discuss some of this.  Make sure " >> you ask him many questions! :-) >> lI >>> If used in conjunction with Write Bitmap, is it simple from a design m >>> standpoint? 4 >> 	We think so, but the design is not complete yet. >> n >  > 	How about another stab? > 9 > 	Instead of a single master with current write bitmaps:O > J > http://h71000.www7.hp.com/doc/731FINAL/5423/5423pro_010.html#index_x_409 > H > 	Instead, make it so each shadow is mastered on 2 nodes.  In a 2 node D > 	cluster, both nodes act as masters for all shadows.  To cut down B > 	message traffic, writes in progress on LBNs would flip bits to H > 	represent 1024 blocks at a time.  Write Bitmap today is working with ? > 	127 block ranges.  A much larger grained portion of the diskgA > 	must be tracked (I would guess) as you would double the numberD: > 	of messages on writes if you kept the same size chunk.  > = > 	More to walk, but storage is faster, CPUs are faster, etc.  >  iC > 	Additionally, you could piggyback write-in-progress cancellationtF > 	messages mixed in with in progress messages to the masters.  And/orA > 	streamline in progress messages, buffer cancellation messages.aA > 	Thinking about this a bit, I don't believe these messages have @ > 	to be ACKed - just sent at start of IO.  Is that right?  This9 > 	would be a huge win as you wouldn't be hindering write < > 	completion by waiting on a "write in-progress" ACK from a > 	shadow bitmap master. >   C > 	This way , short of a total power outage in datacenter, one nodeVC > 	crashes, all shadows could be walked with "in memory mini-merge" @ > 	from the nodes mastering the shadows.  Whether 1 node remains? > 	or n nodes.   Since there are 2 masters for each volume , if5E > 	2 or more nodes remain, a mechanism for who walks might be whoeverhB > 	grabs volume_walker_dsa[0-9]+ lock for the volume, gets to walk > 	it. >   G 	Maybe instead of 2 masters and 2 messages at a time,  non-master nodes : 	keep track of "writes-in-progress" in addition to sending> 	synchronously write in progress messages to the master.  When= 	IO completion occurs, cancellation messages are buffered andh> 	sent to the master.  When/if a master node crashes (all nodesF 	are masters), in a lock-rebuild fashion all pending write-in-progressD 	messages are sent to a new master node which in turn would perform A 	mini-merge.   What about the master that had writes in progress? G 	Those write messsages are sent off node to a "mini-master" which would D 	be the most likely candidate (or would be the candidate) to performA 	the rebuild of the write-in-progress tree.  In a 2 node cluster,  	the mini-master is a misnomer.s   					Rob   ------------------------------  % Date: Thu, 29 May 2003 15:33:09 +0100b( From: Nic Clews <sendspamhere@127.0.0.1>% Subject: Re: New MiniMerge capability-) Message-ID: <3ED61A25.F1726F1F@127.0.0.1>0   Rob Young wrote: >  > ...ideas snipped...uH >         The idea would be if a node crashes, all write bitmaps containJ >         [records of] outstanding writes [in progress] and act as a write% >         history log.  The node thatiI >         crashed of course may/would be mastering a subset of shadowsets B >         out there that would have to have their controller based# >         write history log walked.n  G Some ideas I like Rob, but could you achieve the same "multiple master"a> effect by simply being able to mirror the write bitmaps on the participating systems?  C (Unless I dreamt it, I thought something along these lines had beens considered...?)   B However I can't help thinking that it complicates the actual writeE process, if you're relying on SCS to deliver your write bitmap mirrornH message and your storage subsystems (MSCP or direct) to deliver the sameD physical write, there's opportunity as I see it for inconsistency ifB something goes wrong at the "wrong" time. Which master? Adding (orC needing to add) synchronization could lose you what you expected too gain.x  D Or have I misunderstood what you were saying (or badly explained the above)?    -- -? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences  nclews at csc dot come   ------------------------------    Date: 29 May 2003 10:38:32 -0500+ From: young_r@encompasserve.org (Rob Young)d% Subject: Re: New MiniMerge capabilityh3 Message-ID: <oho8LMhRDCMp@eisner.encompasserve.org>o  T In article <3ED61A25.F1726F1F@127.0.0.1>, Nic Clews <sendspamhere@127.0.0.1> writes: > Rob Young wrote: >> t >> ...ideas snipped...I >>         The idea would be if a node crashes, all write bitmaps contain-K >>         [records of] outstanding writes [in progress] and act as a writeD& >>         history log.  The node thatJ >>         crashed of course may/would be mastering a subset of shadowsetsC >>         out there that would have to have their controller baseds$ >>         write history log walked. > I > Some ideas I like Rob, but could you achieve the same "multiple master"g@ > effect by simply being able to mirror the write bitmaps on the > participating systems? >   : 	What happens to SCS message traffic if you have to mirror= 	write bitmaps?   Maybe the second idea is better as it workse; 	like lock remastering in that write bitmap master tree can- 	be recreated on node crash.  E > (Unless I dreamt it, I thought something along these lines had beenH > considered...?) > D > However I can't help thinking that it complicates the actual writeG > process, if you're relying on SCS to deliver your write bitmap mirrorRJ > message and your storage subsystems (MSCP or direct) to deliver the sameF > physical write, there's opportunity as I see it for inconsistency ifD > something goes wrong at the "wrong" time. Which master? Adding (orE > needing to add) synchronization could lose you what you expected ton > gain.C > F > Or have I misunderstood what you were saying (or badly explained the	 > above)?d >   : 	What I am thinking is that today with write bitmaps, they4 	track changes in 127 block increments.   Looking at
 	a bitmap:  5 (01:42) $               if Performing_Minicopy then -h8                         show device DSAxxxx:/bitmap/fullP Device         BitMap     Size     Percent of   Active         Creation         +   Master    Cluster   Local Delete   Bitmap P  Name            ID      (Bytes)   Full Copy                   Date/Time        )   Node        Size     Set  Pending  NameaP DSA1100:      00180049     69712        0%        No    29-MAY-2003 01:10:39.63 $   00010001     127       0%    No   + SHAD$_$1$DGAxxx:...........................i .....................h   (01:43) $ !e@ (01:43) $       if f$getdvi("$1$DGAxxx:","SHDW_CATCHUP_COPYING") (01:43) $       endifi (01:43) $ !u7 (01:43) $ !  Copying is complete.  Set back read costs.l (01:43) $ !	  = 	As we know.  What happens if master node crashes?  Resort toI> 	full copy behavior - no harm no foul.  What happens if things? 	get slightly out of synch with new MINIMERGE?  Full merge.  Nob 	harm no foul.  > 	What I am thinking is the SCS for "write-in-progress" message> 	is sent prior to or synched with StartIO.  It is synchronous.B 	If the node crashes, the SCS message that last came across is the@ 	last io that was *possibly* started.  If because of heavy write? 	activity one or more nodes had to go to buffered message mode,oB 	all bets are off and full merge for that volume will occur.  IdeaE 	would be maintain synchronous at all costs - hence maybe granularity_) 	may have to change to cut down messages.   D 	I guess I -am- relying on SCS making it.  But if SCS can't make it,E 	don't startio.  Surely there are some tricks here that I am missing,d 	I'm not a systems developer..   				Rob    ------------------------------  + Date: Thu, 29 May 2003 08:22:37 +0100 (MET)m9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>t< Subject: Re: NT: son of VMS? (was Re: Portents of VMS death); Message-ID: <01KWGF673DLEAM3M2Q@sysdev.deutsche-boerse.com><  L > > He was the original author for much of it. And the code was good qualityK > > - an unusual combination of tight efficient coding and clear design ands- > > good commenting and a very low bug rate. a > C > If you're referring to Dave Cutler here, I think you're very muchi > mistaken.   E > NT is really the son of Cutler's VAXELN - at least in NT's original. > concept. .  G > Cutler indeed had very little to do with VMS after V1 shipped, and by D > 1980 he was off doing other things.  What you know of VMS today isF > worlds away from the RSX-clone that was VMS V1, and I credit others,H > such as Dick Hustvedt, Peter Conklin and Tom Hastings, with the vision2 > that made VMS as successful as it was (and is!)   F I remember when I saw the first announcements for NT.  There was a lot@ of hype about how it "combined the best of VMS and Windows" (and4 sometimes "unix" as well).  I suspect that MicrosoftG advertising---remember, this was around the time of GQ's "alliance withhE Microsoft" stuff---hyped up Cutler's role in VMS to make NT look moretH attractive to VMS folks.  As Steve said, think about what you like aboutH VMS.  If it came after version 1, Cutler probably had nothing to do with it.   H To brush up on my history, I read through the excellent "VAX OpenVMS at  20":  '    http://www.digital.com/openvms/20th/i  F Sic transit gloria mundi!  This gives a flavour of what the world was H like back when men wore sideburns, Olsen was in charge, the VAX was the D hippest computer in town, programs were written in Fortran etc.  At 4 least until the "Affinity" chapter comes along.  :-|  = Interestingly, there is mention of "700,000 systems installediH worldwide".  Whatever the 411,000 means, apparently almost 300,000 were I lost in just a few years.  I don't think all of that is due to replacing " 100 old VAXen with 1 new Alpha.e   ------------------------------  # Date: Thu, 29 May 2003 13:27:28 GMT7# From: "John Smith" <a@nonymous.com> < Subject: Re: NT: son of VMS? (was Re: Portents of VMS death)I Message-ID: <4VnBa.274404$M81.99529@news02.bloor.is.net.cable.rogers.com>   F "Phillip Helbig" <HELBPHI@sysdev.deutsche-boerse.com> wrote in message5 news:01KWGF673DLEAM3M2Q@sysdev.deutsche-boerse.com...a <4 > (snip....) > ? > Interestingly, there is mention of "700,000 systems installedrD > worldwide".  Whatever the 411,000 means, apparently almost 300,000 were@ > lost in just a few years.  I don't think all of that is due to	 replacingr! > 100 old VAXen with 1 new Alpha.   D You are correct. The decline was due to the effects of marketing and? advertising...by Sun, IBM, HP, and SGI for unix systems, and by ; Microsoft for Windows, and by Digital for unix and Windows.m  D Did I mention marketing and advertising of VMS? Ooops...looks like ID forgot to mention that.....well not really...because there was none.    ' "It looks like deja vu all over again."E --Casey Stengle    ------------------------------    Date: 29 May 2003 09:16:26 -0500+ From: young_r@encompasserve.org (Rob Young)g< Subject: Re: NT: son of VMS? (was Re: Portents of VMS death)3 Message-ID: <81G3yunaWjBn@eisner.encompasserve.org>   o In article <4VnBa.274404$M81.99529@news02.bloor.is.net.cable.rogers.com>, "John Smith" <a@nonymous.com> writes:s > ) > "It looks like deja vu all over again."D > --Casey Stengleo >     ' http://www.yogi-berra.com/yogiisms.htmlV  L Yogi is perhaps one of the most quoted personalities of our time. From mediaM icons to Presidents, Yogi's saying have crept into our lives and surround us.tG Some of his utterances that created the phrase " Yogi-isms" are below. i  O Now, finally all of Yogi's famously quotable quotes have been gathered together  by Yogi and his family in,  9 The Yogi Book - "I really didn't say everything I said". a   	Including:    		"It's deja vu all over again"n   			Rob   ------------------------------    Date: 29 May 2003 16:26:33 -00004 From: Doc.Cypher <Use-Author-Address-Header@[127.1]>< Subject: Re: NT: son of VMS? (was Re: Portents of VMS death)6 Message-ID: <20030529162633.17226.qmail@gacracker.org>  9 On Thu, 29 May 2003, "John Smith" <a@nonymous.com> wrote:p   <snip>E >Did I mention marketing and advertising of VMS? Ooops...looks like I-E >forgot to mention that.....well not really...because there was none.-     $ FINGER VMS_Marketing@hp.com & ?Sorry, could not find "VMS_MARKETING"! $ FINGER OpenVMS_Marketing@hp.com:D OPENVMS_MARKETING                    OPENVMS_MARKETING not logged in Last Login [Never]  	 [No plan]t     Doc. -- eK OpenVMS.  Eight out of ten hackers                   https://vmsbox.cjb.neteK           prefer *other* operating systems.        http://althacker.cjb.netn   ------------------------------  % Date: Thu, 29 May 2003 12:26:28 -0400 * From: "Bill Todd" <billtodd@metrocast.net>< Subject: Re: NT: son of VMS? (was Re: Portents of VMS death)2 Message-ID: <7umcnfyan78mqUujXTWcqw@metrocast.net>  E "Steve Lionel" <Steve.Lionel@not-specified-here.zyx> wrote in message.2 news:b12adv8t25c3dqq4g31ctutv8j3paj5qdh@4ax.com...I > On Wed, 28 May 2003 17:23 +0100 (BST), duncan@macdonald.compulink.co.uke > (Duncan Macdonald) wrote:e >rC > >He was the original author for much of it. And the code was goodf quality - anE > >unusual combination of tight efficient coding and clear design anda+ > >good commenting and a very low bug rate.i >"C > If you're referring to Dave Cutler here, I think you're very mucht	 mistaken.   L No, he's absolutely correct:  Cutler's code (at least his RSX code - I neverK saw much of VMS at the source-code level) was high-quality according to thetH measures of its day:  tight, with well-designed interfaces, and correct.G I'd have included more detailed comments, but I comment code in greaterrB detail than anyone else I've ever seen, so that doesn't mean much.  L > Cutler's code may indeed have been tight and efficient, but it also tended toJ > be fragile, highly dependent on undocumented behaviors, uncommented, and) > obscure to the point of unmaintainable.o  J All code is fragile if mishandled and obscure to those not 'skilled in theG art'.  In the early '70s minicomputer OS code had to be a) small and b)p@ correct, each being equally important.  It was accepted that theH requirements of (a) implied that it would not be maintainable by trainedJ monkeys, or even average engineers - and OS people were hired accordingly.  L What constituted being 'a good software engineer' (perhaps especially in theJ OS area, since applications could be overlaid and swapped in early systemsI but to a large extent OS code was always resident), and more especially a @ good implementor, changed radically as the world moved to 32-bitJ environments and to physical memory sizes sometimes larger than disk sizesH had been earlier.  Dave may have resisted that transition in some of hisJ coding practices; I know that I certainly did, and in a few ways still do.G But his RSX code was absolutely top-notch for its time, and of course a L great deal of his superb basic RSX design benefited both VMS and NT in later years.   - bill   ------------------------------  % Date: Thu, 29 May 2003 13:18:32 +0100t0 From: Chris Sharman <chris.sharman@sorry.nospam>" Subject: OSU http_server errorpage4 Message-ID: <bb4tqs$gbo$1$8300dec7@news.demon.co.uk>  E Is there any documentation anywhere on the OSU HTTP_server errorpage S directive ?   @ All I can find is a one-liner in the docs, and the following in  http_paths.conf: # Define error pages:m% #    cep_enable         errorpage | #yG #    cep_name           protfail | openfail | rulefail | cgiprotocol | e code4..." #    cep_path           {url path} #    cep_code           [*]a #m2 .ITERATE $cep_enable $cep_name $cep_path $cep_code- .NEXT errorpage protfail /demo/error_403.htmlh& .NEXT # openfail /htbin/openfail.com *- .NEXT errorpage rulefail /demo/error_403.htmlt( .NEXT # cgiprotocol /demo/error_500.html/ .NEXT errorpage  code4 /demo/error_preproc.html:  H Presumably openfail = 404 - what's cgiprotocol and code4 ? What else is # available ? What does cep_code do ?1  ; And while I'm asking, what's this .iterate & .next anyway ?nH Wouldn't the above be simpler, clearer & functionally identical without < the .iterate line & .next tokens ? Or have I misunderstood ?   Thanks,  Chrisv   ------------------------------  # Date: Thu, 29 May 2003 15:27:59 GMTb& From: jlsue <jefflsxxxz@sbcglobal.net>" Subject: Re: Portents of VMS death8 Message-ID: <8o8cdvslhgpcq9ml4d06ike6hjvgmb0pbc@4ax.com>  H On Wed, 28 May 2003 15:03:57 -0400, JF Mezei <jfmezei.spamnot@istop.com> wrote:  
 >jlsue wrote:oJ >> Fail-over clustering can be done by the cheapest crap out there.  ThoseN >> configurations are not highly available and should not be implemented where= >> availability is a means to achieve certain business goals.s >SO >So now you are saying that smaller customers whose appliaction is not "clusterbM >saavy" and can only justify 2 or 3 nodes should simply get off VMS and go to,
 >other crap ?t  E Well, if you're going to re-state my position, at least get it right.GI If your business goal is high availability for applications that can't go:G down, then fail-over is not the best solution.  And 2 or three nodes issH fine for a cluster, provided that it is configured for correct operation and supportability.f  I But a VMScluster is a "security" domain, and it's possible to disrupt (ortF at least slow down) production application services by doing somethingE "bad" on the development/test side of the cluster.  Also, in dev/testrC environments, you usually have fewer restrictions on who has higherhK privileges - if this is clustered with a production system, that production 9 system is also open to those additional privileged users.:  J A financial system should be, imho, a very tightly controlled system, withI near extreme security measures and change control in place.  It is, againoJ imho, dangerous to mix this with an environment that tends to have a lowerK level of security requirements.  If I were an auditor, this would be resultr8 in an assessment of the production system being at risk.  J And there are middleware products (e.g., ACMS and/or RTR) that can make itC very simple (relatively speaking) to provide transparent multi-hostu	 services.a  K At one time, one of my responsibilities was a 3-node cluster (two VAX6640 +oA 1 VS3100 for quorum vote) that was dedicated to back-end databasewG processing (Rdb).  The front-end processors (48 VAX 4200s) used ACMS to.J point to the two database servers for load-balancing.  ACMS could detect aC server going down and reconnect to the other server, never losing aeH transaction.  This required almost no additional coding so was easier toG implement than trying to code it all in the app.  The two VAX6640s wereoH configured to be able to handle the full workload if necessary, but wereG typically  1/2 (or so) utilized when both were up and running.  Oh, and.J they were in seperate buildings (with the VS3100 in a 3rd building tied to the other two).   I This is a highly available environment that can also fulfill most (if notC. all) of the business continuity needs as well.   > O >If you narrow the VMS marketplace to the very same market as Tandem NSK, then:o) >	1-that market is too small to sustain 2 N >	2- HP would be stupid to keep 2 products in the same market that can sustain >only 1s  G How do you get from a discussion about a specific cluster configurationt+ into a generic, VMS marketplace discussion?n   >-K >And between Tandem and VMS, Tandem stays because tandem is the true "faultaK >tolerant" that is used by the stock exchanges etc etc. Tandem has a marketIL >presence and isn't declared "dead". VMS has no market presence and has been- >"forgotten" by its owners for over a decade.   J Absolutely incorrect.  Tandem can not provide the business continuity thatF VMScluster provides.  Tandem can provide a fault-tolerant, single-siteK server for those operations for which it makes sense to spend the extra $$$ : for absolute 100% error detection/correction in every way.  I VMS and VMSclusters, while not necessarily doing the same amount of errorsK detection/correction in processing, does provide very accurate and reliable F services, and also fulfills the business need for business continuity.   ------------------------------  # Date: Thu, 29 May 2003 15:32:38 GMTC& From: jlsue <jefflsxxxz@sbcglobal.net>" Subject: Re: Portents of VMS death8 Message-ID: <3p9cdvgljtb8a39oscadl40ak27k2f8n9v@4ax.com>  I On Wed, 28 May 2003 21:47:47 -0400, "Ron Milen" <milenronald@mailbag.net>. wrote:  K >In this I have to agree.  I've in the past inherited a cluster with a lessnI >than ideal configuration.  Over the short & medium term you have to liveCM >with it.  Over the longer term you can either convince management to let youyL >fix the problem or, of course, find a new job :), hopefully before the @#$$ >hits the fan. >n  I People will always use technology incorrectly.  I've seen people use veryyH large spreadsheets for database applications.  And I've seen VMSclustersG with multiple UAFs/Rightlists/etc.  One day, the $@$% will hit the fan,  though.   @ As a consultant - and really, everyone is a consultant - it is aF responsibility to analyze the situation, review the business goals andH drivers, and develop a business justification as to how they are not (orB will not be able to) meet the stated business goals.  Having greatJ availability merely due to the accident of fairly reliable hardware is not. a sound basis for continued business planning.  K If they still refuse to implement the correct configuration, they take fulleK responsibility for business interruptions.  In some organizations, this canc- lead to civil, and maybe even criminal suits.    ------------------------------  # Date: Thu, 29 May 2003 15:38:14 GMT & From: jlsue <jefflsxxxz@sbcglobal.net>" Subject: Re: Portents of VMS death8 Message-ID: <k5acdv4hbhst06bmns36fopdvj9f0gk48v@4ax.com>  H On Wed, 28 May 2003 14:03:31 -0400, JF Mezei <jfmezei.spamnot@istop.com> wrote:   >mist dragon wrote:wG >> That is true. However, this has not been the case and 99% of the VMS G >> systems are old, not new. I belive that rather small amount of thesecF >> 250.000 Alpha systems are running newest os. It does not matter how? >> much VMS improves if more modern version of it does not havew
 >> customers.o >tL >This is a fair point. Someone still at 5.5-2 will complain that VMS lacks aM >large enough command recall, ability to save the recall buffer and reload itcN >etc etc, and then say that VMS is old and they should migrate to Unix because >UNIX has a GUI.  I I disagree, again.  It's not fair because even if a fix were implemented,nH they would not upgrade (otherwise they would already have upgraded).  ItK makes no sense to complain about the lack of feature/performance gains whenLI you're unwilling to do the work to implement them once they are provided.t   >i >This comes back to marketing.  D In this specific instance?  Not hardly.  They made a decision not toH upgrade to a release that resolves those problems, so they suffered withK them.  Did they compare the performance of that older version of VMS with a H comparably older version of UNIX?  Or did they test it with a relativelyK new version of UNIX?  And if it was so easy to implement & migrate to UNIX, H why was it so tough to implement a more recent vesion of VMS and TCP/IP?   ------------------------------  + Date: Thu, 29 May 2003 16:04:50 +0000 (UTC)i+ From: david20@alpha1.mdx.ac.uk (David Webb)e" Subject: Re: Portents of VMS death+ Message-ID: <bb5b31$g49$1@aquila.mdx.ac.uk>   a In article <k5acdv4hbhst06bmns36fopdvj9f0gk48v@4ax.com>, jlsue <jefflsxxxz@sbcglobal.net> writes:rI >On Wed, 28 May 2003 14:03:31 -0400, JF Mezei <jfmezei.spamnot@istop.com>e >wrote:e >  >>mist dragon wrote:H >>> That is true. However, this has not been the case and 99% of the VMSH >>> systems are old, not new. I belive that rather small amount of theseG >>> 250.000 Alpha systems are running newest os. It does not matter howo@ >>> much VMS improves if more modern version of it does not have >>> customers. >>M >>This is a fair point. Someone still at 5.5-2 will complain that VMS lacks a N >>large enough command recall, ability to save the recall buffer and reload itO >>etc etc, and then say that VMS is old and they should migrate to Unix becauses >>UNIX has a GUI.d >.J >I disagree, again.  It's not fair because even if a fix were implemented,I >they would not upgrade (otherwise they would already have upgraded).  It7L >makes no sense to complain about the lack of feature/performance gains whenJ >you're unwilling to do the work to implement them once they are provided. >  >> >>This comes back to marketing.g >iE >In this specific instance?  Not hardly.  They made a decision not tonI >upgrade to a release that resolves those problems, so they suffered witheL >them.  Did they compare the performance of that older version of VMS with aI >comparably older version of UNIX?  Or did they test it with a relatively L >new version of UNIX?  And if it was so easy to implement & migrate to UNIX,I >why was it so tough to implement a more recent vesion of VMS and TCP/IP?q >i >s  G Unfortunately the answer to that last point is quite often very simple.vM The application they run was dropped on VMS and hence they are stuck running sO an older version on an older version of VMS. It's possible (not just easier but O possible) to move to the latest version of the product on a new version of UnixwG because the supplier supports it on a certain number of Unix platforms.e  H Marketing comes into this in a peripheral manner in that a well marketedA operating system tends to hold onto and attract software vendors.a  
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  # Date: Thu, 29 May 2003 16:52:52 GMT # From: "John Smith" <a@nonymous.com>n" Subject: Re: Portents of VMS deathH Message-ID: <EVqBa.85638$cK1.60503@news01.bloor.is.net.cable.rogers.com>  8 "David Webb" <david20@alpha1.mdx.ac.uk> wrote in message% news:bb5b31$g49$1@aquila.mdx.ac.uk...H@ > In article <k5acdv4hbhst06bmns36fopdvj9f0gk48v@4ax.com>, jlsue" <jefflsxxxz@sbcglobal.net> writes:/ > >On Wed, 28 May 2003 14:03:31 -0400, JF Mezei  <jfmezei.spamnot@istop.com> 	 > >wrote:m > >  > >>mist dragon wrote:F > >>> That is true. However, this has not been the case and 99% of the VMS D > >>> systems are old, not new. I belive that rather small amount of these.E > >>> 250.000 Alpha systems are running newest os. It does not mattern howhB > >>> much VMS improves if more modern version of it does not have > >>> customers. > >>C > >>This is a fair point. Someone still at 5.5-2 will complain thath VMS lacks a F > >>large enough command recall, ability to save the recall buffer and	 reload it D > >>etc etc, and then say that VMS is old and they should migrate to Unix because > >>UNIX has a GUI.o > >w? > >I disagree, again.  It's not fair because even if a fix were- implemented,< > >they would not upgrade (otherwise they would already have upgraded).  ItC > >makes no sense to complain about the lack of feature/performance 
 gains whenB > >you're unwilling to do the work to implement them once they are	 provided.o > >o > >>! > >>This comes back to marketing.  > >/D > >In this specific instance?  Not hardly.  They made a decision not toF > >upgrade to a release that resolves those problems, so they suffered withC > >them.  Did they compare the performance of that older version oft
 VMS with a@ > >comparably older version of UNIX?  Or did they test it with a
 relativelyE > >new version of UNIX?  And if it was so easy to implement & migratee to UNIX,C > >why was it so tough to implement a more recent vesion of VMS andn TCP/IP?g > >  > >P >NA > Unfortunately the answer to that last point is quite often very  simple.iF > The application they run was dropped on VMS and hence they are stuck running F > an older version on an older version of VMS. It's possible (not just
 easier butA > possible) to move to the latest version of the product on a newt version of Unixs> > because the supplier supports it on a certain number of Unix
 platforms. >bA > Marketing comes into this in a peripheral manner in that a wellc marketedC > operating system tends to hold onto and attract software vendors.     E I would, and have argued that marketing is often the principal factorsE in this process....the decision to de-support a platform by a vendor,A> and the eventual migration from that platform by the customer.   ------------------------------    Date: 29 May 2003 01:01:56 -0700# From: dooleys@snowy.net.au (dooley)y@ Subject: Re: Reading CD-R burned on a Window system on an Alpha?= Message-ID: <1ca82fc6.0305290001.43208ef2@posting.google.com>s  r zcsessions@visionair.com (Zack Sessions) wrote in message news:<db13d9fb.0305281119.d603878@posting.google.com>...H > The subject line says it all. I need to read a CD on an Alpha (OpenVMSG > 6.2) that I burned on a CD-R blank on an Windows NT 4.0 system. Is it/H > directly readable or would I need to add something to the Alpha system > to do it? I I sometimes get cds sent to me that I have to mount with these qualifiersn> $MOUNT/MED=CDROM/UNDEF=(FIX:NONE:32256) <cd device> <cd label>
 from the help  MOUNTr     /UNDEFINED_FAT  H        Establishes default file attributes to be used for records on ISO@        9660 media for which no record format has been specified.  
        Formatt  G          /UNDEFINED_FAT=record-format:[record-attributes:][record-size]E   Phil   ------------------------------    Date: 29 May 2003 05:32:03 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)t@ Subject: Re: Reading CD-R burned on a Window system on an Alpha?3 Message-ID: <yS1mtsYHUlWq@eisner.encompasserve.org>p  c In article <1ca82fc6.0305290001.43208ef2@posting.google.com>, dooleys@snowy.net.au (dooley) writes:mt > zcsessions@visionair.com (Zack Sessions) wrote in message news:<db13d9fb.0305281119.d603878@posting.google.com>...I >> The subject line says it all. I need to read a CD on an Alpha (OpenVMShH >> 6.2) that I burned on a CD-R blank on an Windows NT 4.0 system. Is itI >> directly readable or would I need to add something to the Alpha systemr >> to do it?K > I sometimes get cds sent to me that I have to mount with these qualifiers1@ > $MOUNT/MED=CDROM/UNDEF=(FIX:NONE:32256) <cd device> <cd label> > from the helpt  G While I have no quarrel with that good advice, I cannot resist pointing9F out that it results from the program that wrote the CD doing a partialG job of filling in the ISO-9660 data structures.  It is legal, but quiteo) unhelpful, and the fault is not with VMS.w   ------------------------------  # Date: Thu, 29 May 2003 11:20:18 GMTe" From:   VAXman-  @SendSpamHere.ORG@ Subject: Re: Reading CD-R burned on a Window system on an Alpha?0 Message-ID: <00A2093B.3A03C116@SendSpamHere.ORG>  c In article <1SgE5wx9pG3w@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:dP >In article <3ed562c0_3@newsfeed>, "Ron Milen" <milenronald@mailbag.net> writes:M >> I understand about ISO disks.  I've been able to mount & read them before.cI >> However, the term Joliet hierarchy is new to me.  Could someone please  >> explain this? >fK >Microsoft made their own non-compliant derivative of the ISO-9660 standardsK ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^eG >to implement Unicode file and directory names.  Their format is called  >Joliet.   Gee.  Now there's a suprise. --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM             .5   "Well my son, life is like a beanstalk, isn't it?" o   ------------------------------    Date: 29 May 2003 08:47:43 -0500- From: Kilgallen@SpamCop.net (Larry Kilgallen)U@ Subject: Re: Reading CD-R burned on a Window system on an Alpha?3 Message-ID: <g2gyVd2u0SNO@eisner.encompasserve.org>@  U In article <00A2093B.3A03C116@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:2e > In article <1SgE5wx9pG3w@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:pQ >>In article <3ed562c0_3@newsfeed>, "Ron Milen" <milenronald@mailbag.net> writes:rN >>> I understand about ISO disks.  I've been able to mount & read them before.J >>> However, the term Joliet hierarchy is new to me.  Could someone please >>> explain this?> >>L >>Microsoft made their own non-compliant derivative of the ISO-9660 standardM > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^nH >>to implement Unicode file and directory names.  Their format is called	 >>Joliet.s >  > Gee.  Now there's a suprise.  E A lot of what they did was superfluous fluff.  VMS users just have tooD live with the fact that typical PCSI kits have filenames too long toD fit into ISO-9660 directories.  Such a length limit should have been adequate for Microsoft also.  H In fairness to Microsoft, however, one thing they did want was filenamesG using 16-bit Unicode characters, and that was totally outside the scopeoF of ISO-9660.  The alternative would have been for them to design their, format to be totally orthogonal to ISO-9660.  	 =========eD Please record this event to counter future claims that I always bash
 Microsoft.   ------------------------------  # Date: Thu, 29 May 2003 12:47:13 GMTo# From: "John N." <JNixon@cfl.rr.com> % Subject: StorageTek l700 on VMS 7.3-1m; Message-ID: <ljnBa.2503$vL5.296949@twister.tampabay.rr.com>k  L I think that we have now doubled the number of sites that have a Storage TekL L700 Fibre Channel tape library hooked up to a VMS system.  Except for David7 D.  I have not heard of many others.  And we need help./  F We added the tape drive silo (w 8 SDLT 160/320 drives)  to an existingL brocade switch configuration, but we cannot see the tape drives from the VMS systems.  L The StorageTek engineer hooked his laptop up to the switches and can see theJ tape drives so he figures it is a VMS problem.  The H.P. engineer (who hasK always been outstanding) says they have never had to do anything on the VMSr& side to make them see the tape drives.  E We have three Alpha systems (Two ES40s (VMS 7.2-1) and one GS140 (VMShH 7.3-1).  Each Alpha has two FC host adapters connected to two Brocade 16E port FC switches.  Each switch is connected to our 4 HSG80s which arei' serving two TB of data disks just fine.e  L We added the L700 with 4 routers.  Each FC switch is connected to two of theI routers, and there are two tape drives on each router. None of our AlphasoH (including the VMS 7.3-1 GS140 with all ECOs applied) can see any of the tape drives.   Any suggestions?   ------------------------------    Date: 29 May 2003 06:41:10 -0500B From: clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley)C Subject: [OT] Writing unmaintainable code, was: Re: NT: son of VMS?e3 Message-ID: <JPTEWdtxdrs+@eisner.encompasserve.org>   V In article <3ED51838.25A39D24@istop.com>, JF Mezei <jfmezei.spamnot@istop.com> writes: > "Doc.Cypher" wrote:s> >> Others seem to think that job security is more important..." >> http://mindprod.com/unmain.html >  > RTFL !!!! :-) :-)m >  > 
 > 4.Look BusyrO > use define statements to make made up functions that simply comment out their  > arguments, e.g.: -0 >               #define fastcopy(x,y,z) /*xyz*/  >               ... B >               fastcopy(array1, array2, size); /* does nothing */  6 I haven't read all of it, but I enjoyed the following:  1                              ==================== L Avoid Ada: About 20% of these techniques can't be used in Ada. Refuse to useL Ada. If your manager presses you, insist that no-one else uses it, and pointM out that it doesn't work with your large suite of tools like lint and plummer  that work around C's failings. r1                              ====================   J The above is especially true when trying to misuse type conversions. (BTW,L You can do incompatible type conversions if you really must. but you have toI explicitly document that fact in a very obvious and self documenting way)t   Simon.   -- tB Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP       L VMS advocate: One who makes a Mac advocate look like a beginner at advocacy.   ------------------------------   End of INFO-VAX 2003.296 ************************