1 INFO-VAX	Wed, 27 Jun 2001	Volume 2001 : Issue 354       Contents:< 3Dlab Oxigen VX1 for OpenVMS a very expensive graphicadapter@ Re: 3Dlab Oxigen VX1 for OpenVMS a very expensive graphicadapter@ Re: 3Dlab Oxigen VX1 for OpenVMS a very expensive graphicadapter@ Re: 3Dlab Oxigen VX1 for OpenVMS a very expensive graphicadapter@ Re: 3Dlab Oxigen VX1 for OpenVMS a very expensive graphicadapter Re: Alpha -> Itanium Re: Alpha -> Itanium Alpha-IA64 Business Case Alpha-IA64 Third PartiesI Re: An Engineer's Perspective (was: Re: Compaq proves their incompetence) I Re: An Engineer's Perspective (was: Re: Compaq proves their incompetence) I Re: An Engineer's Perspective (was: Re: Compaq proves their incompetence) I Re: An Engineer's Perspective (was: Re: Compaq proves their incompetence) H Re: An Engineer's Perspective (was: Re: Compaq proves theirincompetence) Re: BACKUP listing [] 5 Re: Carbon dating DEC/VMS users, was: Re: V7.3 backup  RE: Changing platforms.  Re: Changing platforms.  Re: Changing platforms.  Re: Changing platforms. 4 Re: Clearly, someone forgot to tell the webmaster... Re: Compaq kills Alpha Re: Compaq kills Alpha$ Re: Compaq proves their incompetence$ Re: Compaq proves their incompetence$ Re: Compaq proves their incompetence$ Re: Compaq proves their incompetence$ Re: Compaq proves their incompetence$ Re: Compaq proves their incompetence$ Re: Compaq proves their incompetence Re: Compaq switches to IA-64I Re: Compaq Transfers Alpha to Intel after EV7 (was: Alpha design team...) I Re: Compaq Transfers Alpha to Intel after EV7 (was: Alpha design team...) P Re: Compaq Transfers Alpha to Intel after EV7 (was: Alpha design team...) team..P Re: Compaq Transfers Alpha to Intel after EV7 (was: Alpha designteam...) team...( Compaq, Intel x Federal Trade Commission DEC Colorwriter 1000+ Re: DecTCP static route on vms for hobbists " Disk Cluster Size for Oracle Disks Re: First lost sale  Re: FreeVMS  Re: FreeVMS  Re: FreeVMS  Re: FreeVMS " Re: FTP LIST problem. Help Please! Re: FUD  Re: FUD  Re: FUD  Re: FUD  Re: FUD  Re: FUD  Re: FUD  Re: FUD  Re: Full port of VMS to Itanium   Re: Full port of VMS to Itanium.  RE: Full port of VMS to Itanium.  RE: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  RE: Full port of VMS to Itanium.  RE: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  RE: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  Re: Full port of VMS to Itanium.  RE: Full port of VMS to Itanium.  RE: Full port of VMS to Itanium. Re: IA64 Rocks My World  Re: IA64 Rocks My World  Re: IA64 Rocks My World  Re: IA64 Rocks My World  Re: IA64 Rocks My World = Re: If you operate VMS systems, what really are your choices? = Re: If you operate VMS systems, what really are your choices? = Re: If you operate VMS systems, what really are your choices? = Re: If you operate VMS systems, what really are your choices? = Re: If you operate VMS systems, what really are your choices? = Re: If you operate VMS systems, what really are your choices? = Re: If you operate VMS systems, what really are your choices? = Re: If you operate VMS systems, what really are your choices? = Re: If you operate VMS systems, what really are your choices? = Re: If you operate VMS systems, what really are your choices? = Re: If you operate VMS systems, what really are your choices? = Re: If you operate VMS systems, what really are your choices? = Re: If you operate VMS systems, what really are your choices? = Re: If you operate VMS systems, what really are your choices?  Re: Intel/Alpha announcment  Re: Intel/Alpha announcment  Re: Intel/Alpha announcment  Re: Intel/Alpha announcment  Re: Intel/Alpha announcment  Re: Intel/Alpha announcment  Re: Intel/Alpha announcment  Re: Itanium HW REF MAN Re: Itanium HW REF MAN Re: Itanium HW REF MAN Re: Itanium HW REF MAN RE: Itanium HW REF MAN RE: Itanium HW REF MAN Itanium Logo! Itanium, non-issue, stop the mail % Re: Itanium, non-issue, stop the mail % Re: Itanium, non-issue, stop the mail % Re: Itanium, non-issue, stop the mail % Re: Itanium, non-issue, stop the mail  iVMS under Stratus Re: Marketing Rantings #3  Notice Re: NYSE Re: NYSE Re: NYSE Re: NYSE Re: NYSE Re: NYSE% Re: Offical Compaq/Intel Announcement  OpenVMS on MicroVAX? Re: OpenVMS on MicroVAX? Re: OpenVMS on MicroVAX? Re: OpenVMS on MicroVAX? Re: OpenVMS on MicroVAX? Re: OpenVMS on MicroVAX?H Re: OT answering, was RE: How to see who causes execessiveloginfailures.# Question re: Oracle and OpenVMS 7.3 6 Re: Question to Charlie Matco - reply to Terry Shannon6 Re: Question to Charlie Matco - reply to Terry Shannon6 Re: Question to Charlie Matco - reply to Terry Shannon6 Re: Question to Charlie Matco - reply to Terry Shannon6 Re: Question to Charlie Matco - reply to Terry Shannon6 Re: Question to Charlie Matco - reply to Terry Shannon6 Re: Question to Charlie Matco - reply to Terry Shannon6 Re: Question to Charlie Matco - reply to Terry Shannon6 Re: Question to Charlie Matco - reply to Terry ShannonP Re: Question to Charlie Matco - reply to Terry Shannon (and some general commentP Re: Question to Charlie Matco - reply to Terry Shannon (and some general commentP Re: Question to Charlie Matco - reply to Terry Shannon (and somegeneral comments Re: Question to Charlie Matco. Re: Question to Charlie Matco. Re: Question to Charlie Matco.
 Re: Rdb troll 
 RE: Rdb troll 
 RE: Rdb troll 
 RE: Rdb troll 
 Re: Rdb troll  ROSS GemBase on OpenVMS Alpha ! Re: ROSS GemBase on OpenVMS Alpha ! Re: ROSS GemBase on OpenVMS Alpha ! Re: ROSS GemBase on OpenVMS Alpha ! Re: ROSS GemBase on OpenVMS Alpha ( Re: Software to create PDF files on OVMS% StorageWorks MSL 5026SL Tape Library  Re: TCL in OpenVMS1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated  Translation Services% USer Record in Accounting File - HOW? ' Re: VMS 7.3/Alpha boot bugcheck problem ' Re: VMS 7.3/Alpha boot bugcheck problem ' RE: VMS 7.3/Alpha boot bugcheck problem  Re: VMS on IA64  Re: VMS on IA64 (technical)  Re: VMS on IA64 (technical)  Re: VMS on IA64 (technical)  Re: VMS on IA64 (technical) < Re: Wailing and moaning... (was: Question to Charlie Matco.)< Re: Wailing and moaning... (was: Question to Charlie Matco.)< Re: Wailing and moaning... (was: Question to Charlie Matco.)< Re: Wailing and moaning... (was: Question to Charlie Matco.)< Re: Wailing and moaning... (was: Question to Charlie Matco.)< Re: Wailing and moaning... (was: Question to Charlie Matco.)< RE: Wailing and moaning... (was: Question to Charlie Matco.)< Re: Wailing and moaning... (was: Question to Charlie Matco.)< RE: Wailing and moaning... (was: Question to Charlie Matco.)< Re: Wailing and moaning... (was: Question to Charlie Matco.)< RE: Wailing and moaning... (was: Question to Charlie Matco.) Re: Wailing and moaning....  Re: Wailing and moaning....  Re: Wailing and moaning....  Re: Wailing and moaning.... < Re: Wailing and moaning.... (was: Question to Charlie Matco)# Re: What about performance issues?? ) Re: What does Alphas dead means for VMS ?  Re: Why not port?  Re: Why not port? ! Re: [OT] but now UK vs US English  Re: [OT] Climate change M [OT] IBM Slow and sclerotic?  ( Was Re: Compaq's Alpha design team for sale?)   F ----------------------------------------------------------------------  / Date: Wed, 27 Jun 2001 10:00:23 +0200 (MET DST) & From: Rudolf Wingert <win@fom.fgan.de>E Subject: 3Dlab Oxigen VX1 for OpenVMS a very expensive graphicadapter 6 Message-ID: <200106270755.JAA27905@sinet1.fom.fgan.de>   Hello,  @ I have asked our seller for OpenVMS for the now suppoerted 3DlabG graphicadapter. He answered that this card should cost about 2.400,00DM B (~1100.00US$). I think that this is to expensive. If I am right, I+ did see prices about 370$. Is this correct?    Regards Rudolf Wingert   ------------------------------  % Date: Wed, 27 Jun 2001 03:00:34 -0700 1 From: Vance Haemmerle <vance@toyvax.Tucson.AZ.US> I Subject: Re: 3Dlab Oxigen VX1 for OpenVMS a very expensive graphicadapter 3 Message-ID: <3B394C52.464F87D9@toyvax.Tucson.AZ.US>    Rudolf Wingert wrote:   B > I have asked our seller for OpenVMS for the now suppoerted 3DlabI > graphicadapter. He answered that this card should cost about 2.400,00DM D > (~1100.00US$). I think that this is to expensive. If I am right, I- > did see prices about 370$. Is this correct?   G    This is Compaq's SOP.   Probably a specialized card with specialized J ROM for VMS that allows them to jack up the price.  The same thing happensH with the specialized "qualified" firmware on Disks and I expect the same for Itanium when it comes out.   --B Vance Haemmerle               Internet   vance@toyvax.Tucson.AZ.USK Tucson, AZ                    Web        http://toyvax.Tucson.AZ.US/~vance/    ------------------------------   Date: 27 Jun 2001 07:45 CDT ' From: carl@gerg.tamu.edu (Carl Perkins) I Subject: Re: 3Dlab Oxigen VX1 for OpenVMS a very expensive graphicadapter - Message-ID: <27JUN200107453140@gerg.tamu.edu>   * Rudolf Wingert <win@fom.fgan.de> writes... }Hello,  } A }I have asked our seller for OpenVMS for the now suppoerted 3Dlab H }graphicadapter. He answered that this card should cost about 2.400,00DMC }(~1100.00US$). I think that this is to expensive. If I am right, I , }did see prices about 370$. Is this correct? }  }Regards Rudolf Wingert   	 My guess:   H Your vendor is mistaken. There are two different kinds of "Oxygen" cardsI and the VX1 is the cheap one. Your vendor is looking at the expensive one G which is the "Oxygen something-that-isn't-VX1" (MX1? I don't remember).    --- Carl   ------------------------------  % Date: Wed, 27 Jun 2001 08:26:23 -0500 1 From: "Dave Gudewicz" <david.gudewicz@abbott.com> I Subject: Re: 3Dlab Oxigen VX1 for OpenVMS a very expensive graphicadapter 8 Message-ID: <9hcmtv$2lk$1@fizban.fizban.pprd.abbott.com>  J Terry Kennedy reported that he purchased VX1 cards for under $200 US (~400
 DM) recently.   < While not purchased from Compaq, the cards worked just fine.   Dave...   3 "Rudolf Wingert" <win@fom.fgan.de> wrote in message 0 news:200106270755.JAA27905@sinet1.fom.fgan.de... > Hello, > B > I have asked our seller for OpenVMS for the now suppoerted 3DlabI > graphicadapter. He answered that this card should cost about 2.400,00DM D > (~1100.00US$). I think that this is to expensive. If I am right, I- > did see prices about 370$. Is this correct?  >  > Regards Rudolf Wingert >    ------------------------------  % Date: Wed, 27 Jun 2001 09:42:20 -0400 8 From: "Island Computers US Corp" <dbturner@islandco.com>I Subject: Re: 3Dlab Oxigen VX1 for OpenVMS a very expensive graphicadapter / Message-ID: <tjjoca9t51ma0f@news.supernews.com>    Well  4 3DLABS VX1 Oxygen 32MB PCI Card (CPQ PN SN-PBXGF-AB)   We sell them for $215 NEW ! . And they work with VMS and Tru64 just fine !!!  I Compaq's printed labels thaty they put on the cards are very expensive to  produce, you know ;0)    DT   -- Island Computers US Corporation  2700 Gregory Street 	 Suite 150  Savannah GA 31404  Tel: 912 447 6622  Fax: 912 201 0096  sales@islandco.com www.islandco.com' http://www.islandco.com/legal-email.htm   3 "Rudolf Wingert" <win@fom.fgan.de> wrote in message 0 news:200106270755.JAA27905@sinet1.fom.fgan.de... > Hello, > B > I have asked our seller for OpenVMS for the now suppoerted 3DlabI > graphicadapter. He answered that this card should cost about 2.400,00DM D > (~1100.00US$). I think that this is to expensive. If I am right, I- > did see prices about 370$. Is this correct?  >  > Regards Rudolf Wingert >    ------------------------------  # Date: Wed, 27 Jun 2001 14:01:26 GMT 2 From: seibel_r@localhost.localdomain (Rich Seibel) Subject: Re: Alpha -> Itanium ; Message-ID: <slrn9jjpoi.esr.seibel_r@localhost.localdomain>   K On Tue, 26 Jun 2001 16:27:53 -0700, Chuck Taylor <Chuck.Taylor@Vishay.com>   wrote:- >This is a multi-part message in MIME format.  > , >------=_NextPart_000_0054_01C0FE5C.F31415C0 >Content-Type: text/plain; >	charset="iso-8859-1", >Content-Transfer-Encoding: quoted-printable > J >Does anyone have any insigt as to what this "transfer of technology" to =D >Intel actually means?  Will a follow on microprocessor from Intel =H >actually be an Alpha in Intel clothing? or will there be some sort of =9 >merging of technologies or will there be something else?  > F >As I understand the way things are right now: the Alpha has some 15 =K >years or so of actually being used and proven in the marketplace and the = I >Itanium is just beginning to ship in very small numbers (I am not sure = J >that it has actually shipped - Does anyone out there know of anyone who =
 >has one?).     B Yes.  And, it performed very well, thank you.  Only one operating D system is currently available on it.  [Grap onto your drawers] It isJ Linux.  The box was made by Intel.  It was large (approx. 1/4 cubic meter)H and heavy (took 2 men to lift it, or one giant).  It sounded like a windG tunnel when in operation, one side of the box was all fans.  The people H who brought it were pleased with its performance on a very computational intensive problem.  = >It seems to me - granted it may be a simplistic approach - = I >but the people at Intel could do a lot for their tarnished reputations = K >by just repackaging and/or relabeling the existing Alpha as their 64-bit = I >solution.  Could anyone comment on the differences between the current = K >Itanium and the current Alpha (instruction set differences, performance, = K >architecutral differences, whatever, but please try to keep it technical = K >and to the point - there are too many religious based arguements already = J >- I want some facts - data that I can use to make a reasonable decision = >about what it happening.  > K >This looks to me that Compaq is getting a lot closer to what they wanted = J >from DEC in the first place - the services organizations.  Now all they =K >need to do is get someone to buy the operating systems and the remainind = B >software groups and they will get to what they originally wanted. > K >It could be a good thing and it could be a bad thing.  I just don't have = K >enough technical data to know what the announcement actually means yet.  = I >They were probably vague on purpose but it would still be nice to know =  >what is intended. > + >17 years of VMS (started with version 3.4)  > 
 >Chuck Taylor 3 >Senior Infrastructure Developer Vishay - Siliconix  >chuck.taylor@vishay.com=20  > , >------=_NextPart_000_0054_01C0FE5C.F31415C0 >Content-Type: text/html;  >	charset="iso-8859-1", >Content-Transfer-Encoding: quoted-printable > ? ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> 
 ><HTML><HEAD> 8 ><META http-equiv=3DContent-Type content=3D"text/html; = >charset=3Diso-8859-1"> : ><META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR> ><STYLE></STYLE> ></HEAD> ><BODY bgColor=3D#ffffff> J ><DIV><FONT face=3DArial size=3D2>Does anyone have any insigt as to what = >this=20K >"transfer of technology" to Intel actually means?&nbsp; Will a follow on =  > G >microprocessor from Intel actually be an Alpha in Intel clothing? or =  >will there=20F >be some sort of merging of technologies or will there be something=20 >else?</FONT></DIV> 5 ><DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV> F ><DIV><FONT face=3DArial size=3D2>As I understand the way things are = >right now: the=20J >Alpha has some 15 years or so of actually being used and proven in the=20F >marketplace and the Itanium is just beginning to ship in very small = >numbers (I=20K >am not sure that it has actually shipped - Does anyone out there know of =g
 >anyone=20G >who has one?).&nbsp; It seems to me - granted it may be a simplistic =a >approach -=20I >but the people at Intel could do a lot for their tarnished reputations =a >by just=20aC >repackaging and/or relabeling the existing Alpha as their 64-bit =x >solution.&nbsp;=20aJ >Could anyone comment on the differences between the current Itanium and = >the=204J >current Alpha (instruction set differences, performance, architecutral=20H >differences, whatever, but please try to keep it technical and to the = >point -=20qF >there are too many religious based arguements already - I want some = >facts - data=20> >that I can use to make a reasonable decision about what it=20 >happening.</FONT></DIV>5 ><DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV> J ><DIV><FONT face=3DArial size=3D2>This looks to&nbsp;me that&nbsp;Compaq = >is getting a=20C >lot closer to what they wanted from DEC in the first place - the =g >services=20I >organizations.&nbsp; Now all they need to do is get someone to buy the =.
 >operating=20kK >systems and the remainind software groups and they will get to what they =  >p  >originally wanted.</FONT></DIV>5 ><DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>iI ><DIV><FONT face=3DArial size=3D2>It could be a good thing and it could =i >be a bad=20I >thing.&nbsp; I just don't have enough technical data to know what the=20oE >announcement actually means yet.&nbsp; They were probably vague on =e >purpose but=20s> >it would still be nice to know what is intended.</FONT></DIV>5 ><DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>nJ ><DIV><FONT face=3DArial size=3D2>17 years of VMS (started with version=20H >3.4)<BR><BR>Chuck Taylor<BR>Senior Infrastructure Developer Vishay -=20 >Siliconix<BR><A=20TG >href=3D"mailto:chuck.taylor@vishay.com">chuck.taylor@vishay.com</A>=20  ></FONT></DIV></BODY></HTML> > . >------=_NextPart_000_0054_01C0FE5C.F31415C0-- >      -- lD --------------------------------------------------------------------D Rich Seibel, Software Engineer                 (314)579-0066 ext 220D Object Computing, Inc.                           seibel_r@ociweb.comD Need ACE training?                      See http://www.theaceorb.comD --------------------------------------------------------------------   ------------------------------  + Date: Wed, 27 Jun 2001 14:34:17 +0000 (UTC)n' From: david20@alpha1.mdx.ac.uk (D.Webb)e Subject: Re: Alpha -> Itanium + Message-ID: <9hcqt8$6p6$1@aquila.mdx.ac.uk>r  f In article <005701c0fe97$9f884a80$b7081eac@vishay.com>, Chuck Taylor <Chuck.Taylor@Vishay.com> writes:F >As I understand the way things are right now: the Alpha has some 15 =K >years or so of actually being used and proven in the marketplace and the =uI >Itanium is just beginning to ship in very small numbers (I am not sure = J >that it has actually shipped - Does anyone out there know of anyone who =I >has one?).  It seems to me - granted it may be a simplistic approach - = I >but the people at Intel could do a lot for their tarnished reputations = K >by just repackaging and/or relabeling the existing Alpha as their 64-bit =eI >solution.  Could anyone comment on the differences between the current =sK >Itanium and the current Alpha (instruction set differences, performance, = K >architecutral differences, whatever, but please try to keep it technical =cK >and to the point - there are too many religious based arguements already =yJ >- I want some facts - data that I can use to make a reasonable decision = >about what it happening.  >r  N For a technical look at IA64, ALPHA and other 64bit chips look at some of the  Articles atV  E http://www.realworldtech.com/page.cfm?Section=Columns&Subject=Insiders  
 especially  ? http://www.realworldtech.com/page.cfm?ArticleID=RWT121300000000   & About the 'future' EV8 SMT technology.   andh  ? http://www.realworldtech.com/page.cfm?ArticleID=RWT062000000000e   and its update  ? http://www.realworldtech.com/page.cfm?ArticleID=RWT061101221315       
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------    Date: 27 Jun 2001 10:09:13 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)M! Subject: Alpha-IA64 Business Case 3 Message-ID: <s$pKHMcbDwH1@eisner.encompasserve.org>,  ` In article <9n6jjt0mpr1h310q2clj2nkaccfis8n8mk@4ax.com>, Alan Greig <a.greig@virgin.net> writes:3 > On Tue, 26 Jun 2001 22:21:08 -0400, "Main, Kerry"u  > <Kerry.Main@compaq.com> wrote: >  >>I >>I personally think the idea of OpenVMS strengths going up against Win64iL >>offerings is great .. each OS gets to compete on scalability, availablity,J >>performance on a similar HW platform. [No, I have no idea how similar or$ >>identical these platforms will be] > H > Capellas was asked this question and he said it was their intention toD > produce Alphaservers which could run the entire Compaq OS family -H > eventually even including NSK. Galaxy features would be ported so thatH > you could have VMS, T64, NT, NSK all running in the same box. At least( > that's the aim. according to Capellas.  7 That shows a strong forward-looking vision on his part.t  D On the other hand, it may be an unachievable goal, especially as oneH looks for NT customers willing to pay NSK prices for redundant hardware.   ------------------------------    Date: 27 Jun 2001 10:33:16 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)g! Subject: Alpha-IA64 Third Partiesr3 Message-ID: <cxOCW9mlVZXs@eisner.encompasserve.org>c  \ In article <3B39DE4F.6CB92803@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes:  P > Does anyone here beleive for a minute that part of the $500 million investmentN > to buy software/support firms might include some firms that are dedicated toP > VMS (such as buying PMDF, Process Software, perhaps buying Rdb back etc etc ?)P > ?  That would be very good news if Compaq did that because it would be putting? > its own money where its mouth is. (actually Intel's money...)g  9 No, that would be very bad news, decreasing the number of 9 independent third party vendors supporting VMS.  It wouldf: also provide the appearance of unfair competition to third parties left in the field.   ------------------------------  % Date: Wed, 27 Jun 2001 16:41:53 +0100s% From: Alan Greig <a.greig@virgin.net>tR Subject: Re: An Engineer's Perspective (was: Re: Compaq proves their incompetence)8 Message-ID: <9gvjjtcj43jm4k6elk96j5eja9cqetc6t2@4ax.com>  E On Tue, 26 Jun 2001 21:41:51 GMT, hoffman@xdelta.zko.dec.nospam (Hoff. Hoffman) wrote:h   >r >eH >  Um, I've already been excoriated once for "gloating" in this thread, G >  and am accordingly hesitant to the information you requested...  :-)I  C Hoff, I really hope that your cheery disposition indicates that youcB might be further ahead then we all think. Can you confirm that theD iVMS port will not have to wait for some mythical server released inB 2004 if all goes well. Are you targeting even a limited release at- current or near current IA64 Compaq hardware?   G >  But seriously, when we have more detailed and technical information nI >  available on the port and the platform, I would expect to see it made (G >  available.  I'd expect that major milestones will be announced, too.o >o >aO > ---------------------------- #include <rtfaq.h> -----------------------------aO >      For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    .O > --------------------------- pure personal opinion --------------------------- M >   Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.coma   -- Alan   ------------------------------  % Date: Wed, 27 Jun 2001 12:31:17 -0400e2 From: rdeininger@mindspring.com (Robert Deininger)R Subject: Re: An Engineer's Perspective (was: Re: Compaq proves their incompetence)L Message-ID: <rdeininger-2706011231170001@user-2ive7go.dialup.mindspring.com>  5 In article <3B38F28E.570CB58F@videotron.ca>, JF Mezei-% <jfmezei.spamnot@videotron.ca> wrote:e   > Christopher Smith wrote:N > > Well, I don't know any of us who are too confused by the hardware lines ;)0 > > I'll buy the manufacturing benefits, though. > M > Manufacturing benefits could have been acheived by having Alpha take on thesP > same form factor and "plug" as the IA64 chip so that An ALPHa could be plugged$ > into a motherboard built for IA64.  J Now there's a useful design constraint to hand your CPU design team.  Good grief!  What are you thinking?    N > However, while Compaq was touting the advantages of a single architecture, IK > think this is all bullshit. Surely Tandem software won't run on commodityuO > hardware , it will run on dedicated motherboards, Michael Dell will make sure-P > of this.  For Compaq to acheive the same cost structure for commodity machinesP > (aka: Wintel) and compete against Dell, it will have to design very simple andN > cheap motherboards for its mass produced units, and design custom low volume# > motherboards for Tandem machines.h  F The cost of constructing a quality IA64 system for VMS may not be much3 cheaper than an alpha system.  That's a good point.   H But Compaq will have saved the vast sum that continued alpha developmentG would have cost.  That investment might have killed them off.  ProbablyeF would have, given how poorly Compaq leverages their technology assets.  F IA64 systems will not be as good as alpha systems would have been, hadH alpha been taken over by a good company and succeeded.  But IA64 systemsI will be _good enough_ to make a quality platform for VMS.  I'll take gooduF enough over nothing at all, and continue to seek perfection elsewhere.    I > So in the end, I predict that Compaq will not be able to streamline itsnJ > manufacturing and will still have the high end machines with custom made  > motherboards: aka: STATUS QUO.  H Status Quo, except they won't be bleeding green from alpha development. J System design and integration cost money, but less money than CPU design + system design.   -- ? Robert Deininger rdeininger@mindspring.com    ------------------------------    Date: 27 Jun 2001 09:48:51 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)lR Subject: Re: An Engineer's Perspective (was: Re: Compaq proves their incompetence), Message-ID: <IKR9cvgORvb4@malvm5.mala.bc.ca>  9 In article <9gvjjtcj43jm4k6elk96j5eja9cqetc6t2@4ax.com>,  +     Alan Greig <a.greig@virgin.net> writes:c  G > On Tue, 26 Jun 2001 21:41:51 GMT, hoffman@xdelta.zko.dec.nospam (Hoffp > Hoffman) wrote:9 >  >> >>I >>  Um, I've already been excoriated once for "gloating" in this thread, VH >>  and am accordingly hesitant to the information you requested...  :-) > E > Hoff, I really hope that your cheery disposition indicates that you@D > might be further ahead then we all think. Can you confirm that theF > iVMS port will not have to wait for some mythical server released in > 2004 if all goes well.  D     Once they have any idea what that processor might look like theyD could start development, using Alphas to emulate it if necessary :-)   ------------------------------    Date: 27 Jun 2001 13:14:28 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)2R Subject: Re: An Engineer's Perspective (was: Re: Compaq proves their incompetence)3 Message-ID: <WtstCWpBCEJb@eisner.encompasserve.org>p  ` In article <IKR9cvgORvb4@malvm5.mala.bc.ca>, nothome@spammers.are.scum (Malcolm Dunnett) writes:; > In article <9gvjjtcj43jm4k6elk96j5eja9cqetc6t2@4ax.com>,  - >     Alan Greig <a.greig@virgin.net> writes:i  F >> Hoff, I really hope that your cheery disposition indicates that youE >> might be further ahead then we all think. Can you confirm that thepG >> iVMS port will not have to wait for some mythical server released in4 >> 2004 if all goes well.  > F >     Once they have any idea what that processor might look like theyF > could start development, using Alphas to emulate it if necessary :-)  D Certainly a technique that was not so efficient for Alpha (emulationE on a VAX).  In fact, before Alpha could do I/O, DEC had some internalaD machines that combined an Alpha (EV3) and a MIPS chip to emulate theH future Alpha machines.  It was much faster than total software emulation on VAX.I   ------------------------------  % Date: Wed, 27 Jun 2001 14:47:45 +0100-  From: steven.reece@quintiles.comQ Subject: Re: An Engineer's Perspective (was: Re: Compaq proves theirincompetence)pH Message-ID: <OF8C7F2348.2206F28C-ON80256A78.004B3208@qedi.quintiles.com>  H I was at a DECUS presentation back in February when I learned a bit moreJ about clustering and what the present product offerings/plans were at that time from Compaq.0  G At that time, plans included memory arrays that were described as beingeJ very similr to RAID Memory in which one memory module could be swapped outJ whilst the hardware was still running.  I.E. "hot-swap" memory in terms of the system keeping running.IJ There was also the description that I can install the software on an IntelE server at a remote location from my local PeeCee.  Load the operatingAK system CD in my local drive, connect to a console board in the Intel servero and carry out the install.  J VMS has some capabilities in these respects (there being nothing new underI the sun) but the techniques and developments that have made this possibles; in the Intel space may make our lives easier in the future..  K Good luck to the Engineering teams that will be putting together VMS, Tru64nK and NSK on the IA64 architecture.  I can see lots of Good Things coming outeI of it now that I've calmed down from the initial "ohmigod they're killingo
 Alpha" lapse.e   Steve.   Hoff wrote:  >>>dJ   Maybe the wrong thing to say (particularly if taken out of context), but?   this is gonna be a fun ride...  (I can see all sorts of niftya
 possibilitiesvH   here for new stuff, and I see an opportunity to fix some of the ratherJ   more bone-headed things we have latent in the existing implementations.) <<<b   ------------------------------  % Date: Wed, 27 Jun 2001 09:25:17 -0600 * From: Terry Aardema <taardema@nrcan.gc.ca> Subject: Re: BACKUP listing []' Message-ID: <3B39FADD.52E5@nrcan.gc.ca>o   Ingemar Olson wrote: > B > I had occasion to actually *look* at one of our backup listings.J > At the end there were a large number of files which were listed as being  > in directory "[]" (ie: blank).A > When I check the disk I find they *are* in an actual directory.t   <SNIP>    > We are on Alpha OpenVMS 7.1-2. > The backup command ist+ > $  BACKUP                               -t+ >         /IMAGE       /NOALIAS           - + >         /BLOCK=65534 /RECORD            - + >         /IGNORE=(INTERLOCK,LABEL)       - + >         /NOASSIST         /NOREWIND     -t" >         /MEDIA_FORMAT=COMPACTION	 > etc etc   H (not withstanding the comments made by John Santos, as I don't know what your exact backup command was)  E I've seen this exact same effect when performing backups of differentoG groups, each of which live on the same physical disk, but used a rootedt logical. As an example:   6 $ define/system/executive_mode/translation=concealed -      groupA $x$userdisk:[groupA.]  H If you BACKUP/SINCE=BACKUP groupA:[000000...]*.*;* ..., everything worksE as expected (i.e. you get all the files under groupA:[000000...] thatd1 have a modified date later than the backup date).   G If you BACKUP groupA:[000000...]*.*;* ..., everything works as expectedyB (i.e. you get a backup of all the files under groupA:[000000...]).  C If you BACKUP/IMAGE groupA: ..., you get an image backup of all the>H files under groupA:[000000...], followed by *ALL* the remaining files onH $x$userdisk:; but these files will appear in the backup listing to be in@ the [] (i.e. no) directory. In other words, an IMAGE backup of aB subdirectory on a volume backups the *ENTIRE* volume (just as HELPG BACKUP/IMAGE clearly states). It would be nice if BACKUP would at least=F spit out a warning ("%BACKUP-I-IMGLOG, groupA is a logical; the entire4 contents of $x$userdisk will be backed up"), but ...   HTHh  
 Terry Aardema= Systems and Network ManagerhB Natural Resources Canada/Canadian Forest Service/Northern Forestry Centre   #include <disclaimer.h>t   ------------------------------  % Date: Wed, 27 Jun 2001 16:20:05 +0100s  From: steven.reece@quintiles.com> Subject: Re: Carbon dating DEC/VMS users, was: Re: V7.3 backupH Message-ID: <OF216F519E.DAC82705-ON80256A78.0053F83E@qedi.quintiles.com>  ' The "OpenChequebook" rides again....... D Last time I asked I got a quote of over 4000 pounds GB to move threeG ESA10000 sized racks (two full of disks, one with a pair of AlphaServer G 4100s and TL892s in) about 60 feet - out of one computer room, down theAI corridor and into the other computer room.  It wasn't much more to move acD pair of Turbolasers with an SW800 each the half mile down the street between two buildings!!! Steve.   Jon Morgan wrote:a0 >Oh yeah, I'm ordering a DECmove soon as well...   ------------------------------    Date: 27 Jun 2001 09:24:51 -0500- From: koehler@encompasserve.org (Bob Koehler)/  Subject: RE: Changing platforms.3 Message-ID: <Py9Kxb4PFzen@eisner.encompasserve.org>o   In article <35666012DF4CD411BE940090279FA240010BEFD7@ppnt41.physics.ox.ac.uk>, John Macallister <J.Macallister1@physics.ox.ac.uk> writes:h  F On a couple days reflection, it appears to me that Compaq is presently5 in the process of not repeating mistakes made by DEC.t  F DEC saw itself as a computer manufacturer, yet it was the VMS softwareA which sold VAXes.  Any hardware engineer could tell you there wasuD nothing all that special about VAXes (at least most of them).  OtherF vendors had somewhat faster systems but couldn't sell them in the faceH of VMS.  In those days if you has some software to do, you bought a VAX.  G DEC looked at porting VMS to 80386, but as a computer manufacturer they H wanted to sell VAXes, not 386s.  DEC's biggest concern seemd to be IBM'sG repeated attempts to build VAX killers.  IBM was THE competition, DEC'sR focus was on IBM.u  E DEC underestimated the impact of RISC technology.  More than somewhatlD faster, it was an impact great enough that people were willing to goA through the pain of VMS to UNIX migration to get on RISC systems.   G Too late, DEC responded with a great RISC chip.  Customers who had left F VMS found no reason to come back.  For a lot of applications which had' been done on VMS, UNIX was good enough.   D Now Compaq, originally doing nothing but assembling hardware with noF software of their own sees that they are making a great profit sellingA great software.  They see that their own chip line isn't going to,E maintain it's competitive edge, and will in the forseeable future geteC behind the price/performance curve.  They put thier money where theaF profit is, software, and they do it in time to prevent a repeat of the great migration off VMS.  G Painfull?  Yes, some customers are going to disagree with the decision,pH Compaq has necessarily caused some uncertainty.  Dollars will have to be! spent to keep the software going.u  F Necessary?  Yes, the current path was obviously going to put them at a competitive disadvantage.y  F DEC like?  No, Compaq's doing exactly the kind of things DEC needed to do and failed.  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporatione= NASA GSFC Flight Software       | Federal Sector, Civil GroupmE                                 | please remove ".aspm" when replyingt   ------------------------------    Date: 27 Jun 2001 10:22:24 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)c  Subject: Re: Changing platforms.3 Message-ID: <uQgbmwPWt2gh@eisner.encompasserve.org>n  k In article <T%b_6.9729$P5.3629159@news1.rdc1.tn.home.com>, "Alphaman" <alphaman64@nixspam-home.com> writes:hN > Okay, so what products will most likely be dropped going from Alpha to IA64? > M > For example, I can only guess that "mature" products will be "retired".  Toe > wit: >  >  DECwritew
 >  Datatrieveg >  Ada >  FMS >  Notes >  VTX >  DECintact >  > Any other ideas?  A My idea is that they have learned better than that from the Alpha0@ experience.  They tried many times to kill FMS (for example) and, found they could not get customers to agree.  @ At least in the case of Ada there is a very good case that it is? "mature" because it is the older Ada83 standard.  Regardless ofiD how many customers of using it there is no reasonable set of furtherA improvements that can be made to it short of going to Ada95.  ButgD that would be a whole different compiler.  Many Ada customers cannotJ stand a whole new compiler, they need the same compiler for compatibility.   ------------------------------  + Date: Wed, 27 Jun 2001 14:57:02 +0000 (UTC)e' From: david20@alpha1.mdx.ac.uk (D.Webb)i  Subject: Re: Changing platforms.+ Message-ID: <9hcs7u$6p6$2@aquila.mdx.ac.uk>t  \ In article <3B3950FE.2AA31520@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: >Alphaman wrote: >>  DECwrite >>  Datatrieve >>  Adai >>  FMS 	 >>  Notes  >>  VTXe
 >>  DECintactd >> l >> Any other ideas?d >n >ALLIN1 (Aka Office Server). > L >I think that Mailbus400 will also disapear. Not sure about X.500 directory.  M Since the X500/LDAP server is now part of VMS in VMS 7.3 I don't see how theya could drop that.  
 David Webb VMS and Unix team leader CCSS Middlesex University     ------------------------------  % Date: Wed, 27 Jun 2001 12:59:33 -0400k- From: JF Mezei <jfmezei.spamnot@videotron.ca>r  Subject: Re: Changing platforms., Message-ID: <3B3A10F2.B7F8E359@videotron.ca>   Bob Koehler wrote:H > DEC like?  No, Compaq's doing exactly the kind of things DEC needed to > do and failed.  L The problem for us is that Compaq doesn't have a focus on VMS it has a focus) on NT. So it will build solutions for NT.d  M If Compaq can widthstand the dry "no enterprise" sales period, I am sure that0# they will survive in the long term.r  L Ironically, with its low stock price, how much is Compaq worth these days ? M Perhaps Ken Olsen could have bought back "Digital" from Compaq, complete withlM VMS and Alpha and compilers and then hired a visionary to kick start VMS intoo a very competitive OS.   ------------------------------   Date: 27 Jun 2001 15:48:09 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)= Subject: Re: Clearly, someone forgot to tell the webmaster...u, Message-ID: <9hcv7p$rhh@gap.cco.caltech.edu>  \ In article <3b38f6e7.106573945@news.supernews.com>, jhodge@biglizard.net (Joe Hodge) writes:+ >....since Compaq still has a nice page on   >i( >"Betting your business on Alpha systems$ >A rising star with a bright future" >c9 >here: http://www.compaq.com/alphaserver/qa/whyalpha.html  >4 >All I can say is, I think not.n  J Had a phone call from some fellow at Pioneer/Standard yesterday who wantedH to set up a meeting with me where a person from Compaq would explain howG they were going to transfer the technology from Alpha into IA64 and howeJ this would benefit me.  Apparently this was in response to one of my postsJ here.  I declined the offer, mostly because I've sworn off doing business K of any sort with Compaq and it would have been a waste of everybody's time. K Anyway, I believe we will soon see a line of blurbage from Compaq about howyH the Alpha is in some way morphing into IA64, or that the IA64 with Alpha9 technology is some sort of upgrade path for Alpha users.    I Anyway, some part of Alpha technology may be aboard some version of IA64  J that's very successful, but that's akin to saying a dead guy has a shiningE future because the woman who received his kidney will live another 20v years. .   Regards,   David Mathog mathog@caltech.edu? Manager, sequence analysis facility, biology division, Caltech f   ------------------------------   Date: 27 Jun 2001 15:05:59 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)  Subject: Re: Compaq kills Alphad, Message-ID: <9hcson$2974$2@info.cs.uofs.edu>  ' In article <3B3953B2.32704DF7@fsi.net>,R4  "David J. Dachtera" <djesys.nospam@fsi.net> writes: |> Bob Kaplow wrote: |> > -g |> > In article <H34_6.256744$Z2.3011370@nnrp1.uunet.ca>, "Chris Moore" <chris.moore@stelco.ca> writes:tI |> > > Bob should be picking the stuff up in a Honda Prelude instead of awQ |> > > Civic.....Honda announced today that they're killing THAT too!! (deliciousu
 |> > > irony)t |> >  P |> > That's been expected for a while. Honda did kill off the hatchback models IP |> > really wanted, leaving me stuck with a coupe and cursing if I want to stick9 |> > something the size of an Alpha 2100 box in the back.f |> sC |> Holy smoke, man! How strong are you? Alpha 2100's are not light!y  D Your joking, right??  They weigh nothing compared to the VAX and PDP boxes I transport all the time.    bill   -- lJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   p   ------------------------------  % Date: Wed, 27 Jun 2001 10:43:24 -0500r1 From: "David J. Dachtera" <djesys.nospam@fsi.net>o Subject: Re: Compaq kills Alphae' Message-ID: <3B39FF1C.2ECF90B3@fsi.net>a   Bill Gunshannon wrote: > ) > In article <3B3953B2.32704DF7@fsi.net>,m6 >  "David J. Dachtera" <djesys.nospam@fsi.net> writes: > |> Bob Kaplow wrote: > |> >i > |> > In article <H34_6.256744$Z2.3011370@nnrp1.uunet.ca>, "Chris Moore" <chris.moore@stelco.ca> writes:oK > |> > > Bob should be picking the stuff up in a Honda Prelude instead of aeS > |> > > Civic.....Honda announced today that they're killing THAT too!! (deliciousn > |> > > irony)  > |> >R > |> > That's been expected for a while. Honda did kill off the hatchback models IR > |> > really wanted, leaving me stuck with a coupe and cursing if I want to stick; > |> > something the size of an Alpha 2100 box in the back.n > |>E > |> Holy smoke, man! How strong are you? Alpha 2100's are not light!  > F > Your joking, right??  They weigh nothing compared to the VAX and PDP! > boxes I transport all the time.t  C True - but it's been a good 15+ years since I could dead-lift threeeC times my own weight. I doubt I'd get much past 1.5 times today, andnH still survive, I mean. I suppose I could heft a 2100 or even a 4100 intoG the Explorer - but I'd be in a world of hurt for a good coupla weeks orn more.s   -- c David J. Dachteraa dba DJE Systemsc http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/   F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.n   ------------------------------   Date: 27 Jun 2001 04:05 CDTh' From: carl@gerg.tamu.edu (Carl Perkins)s- Subject: Re: Compaq proves their incompetencel- Message-ID: <27JUN200104054052@gerg.tamu.edu>i  ) Dan O'Reilly <dano@process.com> writes...r+ }At 01:16 AM 6/26/2001, Carl Perkins wrote:nD }>What I want to know is what Compaq is actually getting out of this! }>deal other than an "agreement".e }>D }>The Alpha technology (intellectual property, if you will - a bunchF }>of patents if nothing else) is worth money. A *LOT* of money. So howE }>much did Intel actually pay Compaq for this IP? So far, there is nov/ }>mention of any payment - just an "agreement".@ } G }It's called a "quiet period".  The companies are not allowed BY LAW tot }discuss anything financial.  D Since this is not a merger or acquisition are you certain that thereC is a quiet period? After all, the way they arranged it to avoid FTCIG complications makes it "just another deal",a s afar as I can tell. They E licensed a bunch of stuff to Intel and are allowing Intel to activelytG poach their employees from certain groups (chip design and compiler, ataF least). What sort of "quiet period" is required by law for a licensing deal? None that I know of.  N }Besides which, even if they DID give it away (which I'm certain they didn't),L }why does that matter to anybody in the world who doesn't own CPQ stock?  IfI }you don't own CPQ stock, it's none of your (or my) business.  It's THEIRl
 }PROPERTY.J }| Dan O'Reilly                  |                                       |  F I doubt that they did either. But by the standards of Compaq, did theyG get a lot or a little? By the standards of Intel, did they pay a lot or 	 a little?:  D What they got reflects strongly on their competence. If they go vastK sums of money (by Compaq's standards or, even better, by Intel's standards) K then it may not be so bad. Intel gained a lot - a good portfolio of IP, the M chance to hire some good people, and the death of one of the main competetors I to their new product. What did Comapq get for all this? Beats me. If theya: made a bad deal then their competance is clearly lacking.   G Are you not interested in how competant the people managing Compaq are?-H You should be - as and employee of Process, which is heavily intertwinedA with the future of VMS, your job is presumably dependant on them.   E I work with VMS. I would prefer to keep working with VMS, and I wouldnE prefer it to be a living, supported, thing. I am therefore interestedaE in how Compaq is managing not only VMS, but their company as a whole.e  F Sure they can do anything they want with their property. But what theyE did can indicate whether they are competant or incompetant, shrewd oriJ morons. If your company sold me all the rights to Multinet and any relatedK intellectual property and the opportunity to recruit any of it's developersGI I was interested in for $1.75 and a Tootsie Pop, what would that tell youhJ about the people who own that property? Could you not infer from this that6 they may not manage their remaining assets any better?  G Anybody who uses Compaq products, especially those who wish to continueiE to use those products, has a legitimate interest in how well, or not,  Compaq manages it's products.b   --- Carl   ------------------------------  % Date: Wed, 27 Jun 2001 10:44:35 +0100-  From: steven.reece@quintiles.com- Subject: Re: Compaq proves their incompetence H Message-ID: <OF2BCF17E6.9218D834-ON80256A78.0034EA51@qedi.quintiles.com>  H Putting two and two together and making five (we are talking about Intel after all :-))    :   G - given that there was the other leaked story about how Compaq have set E aside $500million for the aquisitions related to becoming a solutionst> company to reinvent themselves as a Digital-type business, andG - given that Michael C. has stated that he wants to save $200million in E structural costs in Q1 (and presumably the same in Q2) then 2+2 = 5-1   C That would give a $100million shortfall which the sale of the AlphaI3 business probably supplies to Compaq in ready cash.    That would be my view anyway.A Steve.   Carl Perkins commented : >>>tF I doubt that they did either. But by the standards of Compaq, did theyG get a lot or a little? By the standards of Intel, did they pay a lot ori	 a little?o  D What they got reflects strongly on their competence. If they go vastK sums of money (by Compaq's standards or, even better, by Intel's standards)aK then it may not be so bad. Intel gained a lot - a good portfolio of IP, the=A chance to hire some good people, and the death of one of the maini competetorslI to their new product. What did Comapq get for all this? Beats me. If they 9 made a bad deal then their competance is clearly lacking.  <<<e   ------------------------------  % Date: Wed, 27 Jun 2001 04:19:11 -0700 1 From: Vance Haemmerle <vance@toyvax.Tucson.AZ.US> - Subject: Re: Compaq proves their incompetence 3 Message-ID: <3B395EBF.6B85587F@toyvax.Tucson.AZ.US>n   Carl Perkins wrote:s  F > What they got reflects strongly on their competence. If they go vastM > sums of money (by Compaq's standards or, even better, by Intel's standards)eM > then it may not be so bad. Intel gained a lot - a good portfolio of IP, theuO > chance to hire some good people, and the death of one of the main competetorspK > to their new product. What did Comapq get for all this? Beats me. If they.; > made a bad deal then their competance is clearly lacking.a  '   I figure they mainly got two things -i  L   1) Another chance to suck up to one of their masters, Intel and Microsoft.  D   2) The managers have one less thing they have to do in competition1      with other compaines and be responsible for.H    J    How much does it really cost to do processor design?  When Digital soldG  the Alpha FAB to Intel, to lean itself down to be taken over by Compaq J  (a deal us shareholders were really screwed on), we were all told that itO  would save a lot of money.  The major cost in making chips was the production, J  not the intellectual part (the design).  Give the production to companiesJ  that were good at it; Intel, IBM, AMD, etc. made many processors and thisN  allowed them to spend the money it took to create the more and more expensiveL  FABs and processes it took to create the smaller and smaller feature sizes.J  So that's why Alpha because a FAB-less operation.  Do the design work andN  let _multiple_ chip companies (you don't want to bet the business on anythingI  singled sourced!) make Alpha on competitive processes.  Heck, even share ;  motherboard design with AMD which shares the same EV6 bus.D  N    I don't think the idea behind killing Alpha is to save money at all, but isJ  mainly a weenie non-compete deal with Intel from a company that only justM  wants to stick Intel parts into machines and always has.  That's why the FTCPO  needs to look into this deal.  Back to the question,  How much does it cost tonL  pay a few hundred chip designers (is there that many?) for the 18 months itN  takes to create the next Alpha design?  What's the salary of a motivated chipN  designer working on the fastest, cleanest, cutting edge processor?  A millionL  dollars each??!!  Come on.  How much does it take to create a mask and ship  it off to a FAB?   O     What's "industry standard" about IA64 in the Enterprise space anyway excepttK  that it's made by a company that makes 85% of the consumer processors?  IfgP  marketshare determines "industry standard", what's the marketshare of somethingP  that just came out?  This deal doesn't even let the market decide.  IA64 is notM  an "industry standard" or "open processor".  As far as I know, it's strictlyoK  proprietary and single company produced.  Intel has not licensed ANY otherpE  manufacturer to make the chip.  AMD's licenses only extend to IA-32.g  E    So what happens to Compaq's "Enterprise" business when Intel can'tdH  keep up with demand or successfully manufacture the chip and Compaq hasF  to stand in line with other companies?  Of course Compaq managers canF  absolve themselves all responsibility which I think is the only thing  they strive for or do well.  G > I work with VMS. I would prefer to keep working with VMS, and I wouldaG > prefer it to be a living, supported, thing. I am therefore interested G > in how Compaq is managing not only VMS, but their company as a whole.t  K    Compaq's vision is not to create value or innovation or stand out in anywM  meaningful way but rather just to put together building blocks made by other O  companies.  I don't believe they have the motivation to design chips, softwaretN  or  anything.  That's why all they seem capable of talking about is "industryK  standard" computing which is synonymous with "Not invented here" or "don'teL  blame us for it".  Even having three lines of servers is too much for them,K  how will they deal with five OSes?  As we know, not very well.  That's why N  I think the next thing to go is the OSes and compilers.  What is an "industryH  standard" building block company doing with non-industry standard OSes?H  Compaq, please sell VMS to someone who cares and is willing to compete!    I > Anybody who uses Compaq products, especially those who wish to continuepG > to use those products, has a legitimate interest in how well, or not,r > Compaq manages it's products.e  D    I think they've pretty much proved it already - that's why I'm no  longer a stockholder again.   --B Vance Haemmerle               Internet   vance@toyvax.Tucson.AZ.USK Tucson, AZ                    Web        http://toyvax.Tucson.AZ.US/~vance/    ------------------------------  % Date: Wed, 27 Jun 2001 06:44:38 -0600 % From: Dan O'Reilly <dano@process.com> - Subject: Re: Compaq proves their incompetence B Message-ID: <5.1.0.14.2.20010627063657.02881de0@ntbsod.psccos.com>  * At 03:05 AM 6/27/2001, Carl Perkins wrote:* >Dan O'Reilly <dano@process.com> writes..., >}At 01:16 AM 6/26/2001, Carl Perkins wrote:E >}>What I want to know is what Compaq is actually getting out of thisg" >}>deal other than an "agreement". >}> E >}>The Alpha technology (intellectual property, if you will - a bunchpG >}>of patents if nothing else) is worth money. A *LOT* of money. So howeF >}>much did Intel actually pay Compaq for this IP? So far, there is no0 >}>mention of any payment - just an "agreement". >}H >}It's called a "quiet period".  The companies are not allowed BY LAW to >}discuss anything financial.f >rE >Since this is not a merger or acquisition are you certain that there.D >is a quiet period? After all, the way they arranged it to avoid FTCH >complications makes it "just another deal",a s afar as I can tell. TheyF >licensed a bunch of stuff to Intel and are allowing Intel to activelyH >poach their employees from certain groups (chip design and compiler, atG >least). What sort of "quiet period" is required by law for a licensingo >deal? None that I know of.t  0 Yes, there is a quiet period involved with this.  H >Are you not interested in how competant the people managing Compaq are?I >You should be - as and employee of Process, which is heavily intertwinedoB >with the future of VMS, your job is presumably dependant on them. >gF >I work with VMS. I would prefer to keep working with VMS, and I wouldF >prefer it to be a living, supported, thing. I am therefore interestedF >in how Compaq is managing not only VMS, but their company as a whole.  I Sure I'm interested - but on the other hand, there's not much I can do if4M they're competent or incompetent.  Like everybody else here, I'm a spectator.iE The point is, I have the same relative influence on them that you do..  L Look, all the wailing and gnashing of teeth over this thing has me, at most,I amused (for lack of a better word).  I've been through this sort of thing I several times before: PDP-8 to PDP-11, PDP-11 to VAX, VAX to Alpha, so ona@ and so on.  From my warped standpoint, CPQ can't/won't kill VMS:   a) Too much money from it.1 b) Too dependent on DOD contracts for the future.a8 c) Too many customers to want to screw them all at once.  N Business is business, and just because CPQ is giving up the Alpha doesn't meanK they have no sense of business, or even common sense, for that matter.  For N me, yes, my living comes directly from VMS.  But I'm not going to stand aroundI wringing my hands and wondering when it's all going to come crashing downo
 around me.   ------I +-------------------------------+---------------------------------------+lI | Dan O'Reilly                  |                                       |qI | Principal Engineer            |  "Why should I care about posterity?  | I | Process Software              |   What's posterity ever done for me?" | I | http://www.process.com        |                    -- Groucho Marx    |pI +-------------------------------+---------------------------------------+a   ------------------------------    Date: 27 Jun 2001 09:31:09 -0500- From: koehler@encompasserve.org (Bob Koehler)1- Subject: Re: Compaq proves their incompetenceu3 Message-ID: <N+Znyr9JN7tI@eisner.encompasserve.org>e   In article <rdeininger-2606011151260001@user-2ive7jq.dialup.mindspring.com>, rdeininger@mindspring.com (Robert Deininger) writes:m  ? > I think the existence of Macro32 on alpha proves that it is a,J > machine-independent progamming language.  I should have written "machine( > independent" earlier instead of "HLL".  D VAX macro closely resembles an intermediate language (used between aC compiler font end and it's back end) I once ran into.  The compilereA writer who used that intermediate language pointed to a publishedy- acedemic paper as reference for the language.i  B I wonder how closely the language the GEM back end reads resembles either of these?  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporation.= NASA GSFC Flight Software       | Federal Sector, Civil GroupqE                                 | please remove ".aspm" when replyingm   ------------------------------  % Date: Wed, 27 Jun 2001 09:42:17 -0400d- From: JF Mezei <jfmezei.spamnot@videotron.ca>l- Subject: Re: Compaq proves their incompetence-, Message-ID: <3B39E2B8.739F243A@videotron.ca>   Carl Perkins wrote:pK > to their new product. What did Comapq get for all this? Beats me. If they ; > made a bad deal then their competance is clearly lacking.     L What did Digital gain by donating its Alpha FAB plant ?  It got rid of a FABL plant which Digital never allowed to be used to its fullest extent (refusingI fabbing contracts just in case Digital might need the capacity for Alpha)sK which was costing Digital large sums of money. In exchange for Intel taking4I the FAB plant away from DEC, DEC had to officially give Intel some of thec- Alpha technologies Intel had stolen from DEC.u  I What does Compaq gain from this deal ? They get rid of a portion of theirsL business (Alpha) which is not part of their vision, and with the money IntelN is giving them, Compaq gets to build a software/service organisation by buying. other firms, and that is part of their vision.  K VMS and Tru64 are put on life support so they can survive some time withouttM their heart (Alpha) with a substitute heart IA64. Whether this means that VMSsH remains in a coma with basic life support or whether it gets a tru heartD transplanmt and expects to be up and running again is not known yet.  K But ask yourself: Has Compaq ever given any impression that VMS was part of L its core vision ? No. Compaq has given very strong hints that its Vision wasM Wintel based and that NT was goin to rule the IT world. Compaq has given verytI strong hints that it favours Microsoft and Intel over Digital's products.r  H Anything which is not part of Compaq's core vision should be expected toM disapear over time. Compaq is being nice by supporting these things for a few M years and I suspect that the hints will grow stronger over time. The death of N Alpha is a pretty strong hint from Compaq that anything Digital is not part ofM its core vision. The lack of marketing of VMS is a strong hint that it is nottL part of Compaq's vision. Winkler's statements that are pro-Microsoft and hisL current position high up at Compaq makes it quite clear that VMS is not partL of Compaq's vision. And since he is probably the successor to Capellas, once? he is at the top of Compaq, don't expect much support for VMS. e  I > Anybody who uses Compaq products, especially those who wish to continuecG > to use those products, has a legitimate interest in how well, or not,a > Compaq manages it's products.e  K This is where we had it all wrong. VMS is not a Compaq product, neither was N Alpha. Compaq got stuck with it and it can't seem to get rid of it for various- reasons. (a testament to VMS and its users). -  J We think Compaq is stupid for not taking full advantage of VMS. But CompaqK sees VMS as a liability, not an asset. It is something which is not part ofiL its core competencies, not part of its visions and something which Compaq isN not interested it. If they could manage to get rid of VMS in exchange for some& money, they would do it in an instant.  K There are 2 things left to deal with: Tru64 and VMS. Will they donate Tru64rK technologies to Linux and provide a way for Tru64 users to migrate to LinuxcN fairly transparently ? Nobody would really buy Tru64, except perhaps MicrosoftI if it decides to invade the Unix market. For as long as VMS and Tr64 wereIN Alpha based, I guess that they were much harder to sell because of the lack of future of Alpha.  M But once they are migrated to IA64, a platform on which Compaq has no control K and whose future i not in question, perhaps it will become possible to selleN VMS and Tru64. At that point, Compaq would be where it wants to be: the marketK leader in NT solutions and would not be hindered by these Digital remnants.    ------------------------------  % Date: Wed, 27 Jun 2001 14:55:28 +0100i% From: Alan Greig <a.greig@virgin.net>i- Subject: Re: Compaq proves their incompetencea8 Message-ID: <bvojjts6qu306oo7s2pplq97hvtnj4e9kn@4ax.com>  7 On Mon, 25 Jun 2001 15:27:29 -0700, "Barry Treahy, Jr."n <Treahy@mmaz.com> wrote:    N >Now if you perform this same comparison with VAX or Alpha to IA-64, where areP >you?  I do not see any gains and this does presuming that VMS does successfullyP >port;  Will the Q create an Alpha or VAX compatibility mode?  I doubt it so allJ >of the applications must be ported to native executables and I'm a strong  ; Capellas said in the webcast that they would aim for binary>E compatibility where possible and 100% source code compatibility where  not.  O >Maybe I'm myopic as well as pig-headed, but in never too humble opinion, the Q0 >screwed up big time...s  F I think they screwed up big time buying DEC without a well thought outE strategy. I have some sympathy for Capellas because he did not create  the mess in the first place.  E Btw Barry, as a ManMan user (although at an old version) you might beuF interested in CA's response. I happened to be at CAMUS Europe when theB announcement was made and CA's reaction was disbelief. They are to@ come back to the ManMan/DEC group (as they still call it) with aC formal response but say they would expect to support ManMan on iVMSb, given the availability of DBMS from Oracle.    >M	 >Regards,f >s >Barry >  >w >  >> >>I >> Further, the VAX to Alpha was a proven 32bit to an unproven 64bit frompJ >> a company with a good track record. And it was an in-house design and aJ >> bet the farm decision, so it had to work or they'd be gone. (Debates onK >> whether they are gone because it really didn't work vs other reasons are  >> left to another discussion).d >>F >> The difference now is that Apha to IA64 is a proven (but see above)E >> 64bit to an unproven 64bit. But the new 64bitter is not an inhousexK >> design, and from the sound of the announcements it is a bet the divisionlI >> descision. Plus, it will likely be easier to move from one 64bitter tocI >> another 64bitter than it was to do the 32bit to 64bit port, especially)> >> now that the first 64bit port has proven to be successfull. >>G >> As for bet the division, I find it hard to believe that Compaq wouldcC >> really bite off the very profitable VMS division in light of thelG >> declining profits in the PC division by putting VMS (and NonStop) oneI >> a hardware platform that is inherently inferior. It may not be as goodnJ >> as Alpha coulda/shoulda/woulda been, though time will tell, but it mustG >> pass muster with the VMS and Tru64 development teams before it'll be  >> let out of the cage.p >>7 >> > "Dan O'Reilly" <dano@process.com> wrote in messageoA >> > news:5.1.0.14.2.20010625085538.02818ea0@ntbsod.psccos.com...aM >> > > Ummmmmmm...pardon playing the devil's advocate here, but didn't DEC dob	 >> > thatmK >> > > with the VAX, and particularly with the Alpha?  Neither was a proven 2 >> > > technology when they were first released... >> > >> > >> > >> > >> >> --p >> --A >>P >> Netcom Class of '93, RIP Netcom!     <*>     hsiegel<->at<->pobox<->dot<->com   -- Alan   ------------------------------  % Date: Wed, 27 Jun 2001 12:14:07 -0400i2 From: rdeininger@mindspring.com (Robert Deininger)% Subject: Re: Compaq switches to IA-64eL Message-ID: <rdeininger-2706011214070001@user-2ive7go.dialup.mindspring.com>  3 In article <KAc$xH4mrDvj@eisner.encompasserve.org>, : Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:   > In articleA <rdeininger-2606011307440001@user-2ive7jq.dialup.mindspring.com>,94 rdeininger@mindspring.com (Robert Deininger) writes:K > > In article <9ha78i$qeo$5@info.cs.uofs.edu>, bill@cs.scranton.edu wrote:6 > >  > > L > >> Maybe, but once the port of VMS to IA64 takes on momentum how likely isK > >> it that new features will find their way into the Alpha version??  HowCH > >> many new features in the Alpha version found their way into the VAX > >> version?? > > M > > Quite a few new features have appered on the VAX.  The notable exceptionss, > > are the things around 64-bit addressing. > > G > > The compiler situation for VAX isn't quite as good as the OS case. e* > > Fortran 90 never made it, for example. > 9 > But the debugger support for Ada is far better on VAX !r  E Agreed.  But that seems to be due to general neglect of Ada at CompaqhI these days.  Actually it started under Digital.  I belive GNAT could have G worked with the VMS debugger, for the price of some enhancements in them+ debugger.  Digital declined to do the work.n  C C++ is having similar debugger pains on Alpha, but they are slowingtA getting fixed.  C++ is currently trendy, and gets more resources.t  dD > One problem report answer I received said it was because Alpha AdaC > was not on the latest GEM, and upgrading it to use the latest GEMe > is not in the cards. > F > But for IA64, I bet they will start with the (currently) latest GEM,F > so to port Ada at all they will have to upgrade it to the fixed GEM.6 > We might get VAX-parity on Alpha because of IA64 :-)   We can hope.  F It seems that the interfaces to this mystical thing called GEM are notF terribly well defined.  I've certainly never seen a hint that they areI public.  The IA64 port is a good chance to remedy that.  It's in Compaq'snH interest to do so, since language-uniformity is a strength of VMS, and a boon to the OS port itself.p  I The databases are also connected to GEM, and other products might benefitiJ from a well-defined interface to quality code generation.  And on IA64, it? will be even more important than on Alpha, from what I've read.I   -- t Robert Deininger rdeininger@mindspring.coms   ------------------------------  % Date: Wed, 27 Jun 2001 07:15:55 -0400s) From: "Neil Rieck" <n.rieck@sympatico.ca> R Subject: Re: Compaq Transfers Alpha to Intel after EV7 (was: Alpha design team...); Message-ID: <Dbj_6.28238$yy2.2802159@news20.bellglobal.com>p  @ More new info from http://www.eetimes.com/story/OEG20010625S0105   Highlights:c  L Compaq currently has some 500 microprocessor engineers and spends about $150K million annually to develop its internal processors. Effective immediately, K 200 of those designers will go to work for Intel, where it is expected thattK they will be able to implement their Alpha expertise into future iterationsmI of Intel's Itanium family. Eventually, the rest of Compaq's MPU designershH will become Intel employees. Marcello said the company will be receivingH some significant financial compensation from Intel, but he would give no details.   And...  J Compaq is currently working on the EV7 version of the Alpha chip, which isD expected to debut in the company's Marvel line of systems in 2003. AJ subsequent version of that design will also be released, which will simplyJ incorporate a process shrink. Marcello said that these parts, and existingK Alpha designs, will continue to be produced as long as there is demand from J existing customers, which he said could continue through 2012. "These will% be the last Alpha designs," he added.o  
 Neil Rieck Kitchener/Waterloo/Cambridge,i Ontario, Canada.! http://www3.sympatico.ca/n.rieck/d   ------------------------------    Date: 27 Jun 2001 10:45:13 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)nR Subject: Re: Compaq Transfers Alpha to Intel after EV7 (was: Alpha design team...)3 Message-ID: <XBRiM+Nh6d6y@eisner.encompasserve.org>s  g In article <3B39105D.255D7220@toyvax.Tucson.AZ.US>, Vance Haemmerle <vance@toyvax.Tucson.AZ.US> writes:u > Larry Kilgallen wrote: >> mi >> In article <3B380BBC.225603B@toyvax.Tucson.AZ.US>, Vance Haemmerle <vance@toyvax.Tucson.AZ.US> writes:e >> > Warren Spencer wrote: >> >L >> >> Capellas made it clear in the NYC announcement that they are licensingE >> >> Intel to use the Alpha technology on a non-exclusive basis.  My:O >> >> understanding is that Q *could* license others, but no doubt restrictions  >> >> apply. >> >= >> >   The transfer of employees isn't exactly non-exclusive.a >> vF >> It is in the sense that the employees can choose to work elsewhere.J >> SGI and Sun Microsystems both have facilities in Eastern Massachusetts. > J >   Oh, so the EV8 design team will freelance to other chip manufacturers?  A No, not freelance.  They are being "offered employment" at Intel.gB Here in the United States of America, they can accept that or seek? an offer from another employer.  Rumors are that the reason SGInA is setting up a facility in New England is to attract workers who : want to live here (including those who already live here).   ------------------------------  % Date: Wed, 27 Jun 2001 13:19:31 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca> Y Subject: Re: Compaq Transfers Alpha to Intel after EV7 (was: Alpha design team...) team..c, Message-ID: <3B3A159F.3F2FC310@videotron.ca>   Larry Kilgallen wrote:C > No, not freelance.  They are being "offered employment" at Intel.r  N What are the mechanics of this. Aren't their paycheques automatically start toN come from Intel, or will their Compaq jobs be terminated at the same time as a job offer from Intel arrives ?  N Would intel transfer employee by employee, or do a single mass transfer of the< payroll file and later on adjust each employee accordingly ?  I If an employee decides not to work for Intel, will he have to resign from- Compaq or from Intel ?   ------------------------------  % Date: Wed, 27 Jun 2001 14:39:19 -0300e) From: fabio_compaq@ep-bc.petrobras.com.brhY Subject: Re: Compaq Transfers Alpha to Intel after EV7 (was: Alpha designteam...) team...oL Message-ID: <OFDF7FD36E.0E0A5544-ON03256A78.0060CBC7@ep-bc.petrobras.com.br>  J I would like a job at Intel:  stock options, planning my career, work with high technologycI everyday, not being just a BSMOH (Bastard System Manager ofThe Hell).....,  K But Intel didnt decide  to install a plant here in Brazil yet.Pprobably AMDa will arrive here first.h   Regardsn   FC        > JF Mezei <jfmezei.spamnot@videotron.ca> em 27/06/2001 14:19:31  9 Favor responder a JF Mezei <jfmezei.spamnot@videotron.ca>i             Info-VAX@Mvb.Saic.Com       I Assunto: Re: Compaq Transfers Alpha to Intel after EV7 (was: Alpha designn#          team...) team...) team...)m     Larry Kilgallen wrote:C > No, not freelance.  They are being "offered employment" at Intel.t  K What are the mechanics of this. Aren't their paycheques automatically start  toI come from Intel, or will their Compaq jobs be terminated at the same timeh as a job offer from Intel arrives ?  J Would intel transfer employee by employee, or do a single mass transfer of theo< payroll file and later on adjust each employee accordingly ?  I If an employee decides not to work for Intel, will he have to resign from- Compaq or from Intel ?   ------------------------------  % Date: Wed, 27 Jun 2001 11:02:14 -0300n) From: fabio_compaq@ep-bc.petrobras.com.bru1 Subject: Compaq, Intel x Federal Trade Commission L Message-ID: <OFD04E9259.64A2F319-ON03256A78.004D0478@ep-bc.petrobras.com.br>   Click at  ' http://www.theinquirer.net/26060101.htm-   This should be true ?-   Fabio C.   ------------------------------  % Date: Wed, 27 Jun 2001 12:43:24 +0100 0 From: "Steve Kearney" <ste@the-neuk.demon.co.uk> Subject: DEC Colorwriter 1000aA Message-ID: <993642467.12220.0.nnrp-07.c1edbfcc@news.demon.co.uk>m  L I rescued one of these from the skip, it had a new-ish ribbon in it, and has: perfromed very well, if a bit noisy in a home environment.  6 Now, the ribbon is used up, and ISTR, quite expensive.  B Anyone know how much these ribbons are (uk sources reveal nothing)   Cheers   Stevec   ------------------------------  % Date: Wed, 27 Jun 2001 15:17:20 +0100e% From: Alan Greig <a.greig@virgin.net>n4 Subject: Re: DecTCP static route on vms for hobbists8 Message-ID: <6jqjjtg7s9erdp0tf8et50f2dc70t15p3l@4ax.com>  - On 25 Jun 2001 12:58:15 -0700,  (rob merritt)e wrote:merritt.robert@spsd.sk.cao   >Hiw >o: >I got my vax vms 72-1 hobbist CD and installed vms on my ? >vax 4000 model 50 the question I have is when configuring the -? >tcp it wont let me configure routing (set a static route to mynA >home Unix router/Nat(er)) so the ip operates on broadcast in its   B UCX/TCPIP provides full routing functionality although you need toF install the full license (which the hobby config provides and allows).9 Sounds like you may be using only the client UCX license.o  C >own subnet (192.168.0.0) is that by design so you cant get a free 36 >router out of the deal? or am I doing something wrong   -- Alan   ------------------------------  # Date: Wed, 27 Jun 2001 14:57:30 GMTb3 From: Dave Harrold <DRHarrold.nospam@earthlink.net> + Subject: Disk Cluster Size for Oracle Disks 8 Message-ID: <ihsjjtg28kc17q8a4innt8ain5nltkegrg@4ax.com>   Hi All,o  E We are running Oracle 7.3.3.6 on VMS 7.2-1H1 and our vendor said thatDE the disks that have the Oracle data files on it should have a clusteraE size that is a multiple of 16.  (Because Oracle does 8K transfers.)  o  F O.K., that seems reasonable to me, but my question is would having theA cluster size be 16 not matter what be better?  Some of our larger?F drives will have a cluster size of 112 by the multiple of 16 rule.  Is> that really as efficient? (I.e. does Oracle do 56K transfers?)  E And as a related question, the answer to the above questions seems toaF be "It Depends on your I/O size".  So, what tools can I use to measure the size of the I/Os?o   Thanks for the help.   Dave Harrold    V ======================================================================================V Dave Harrold                                          E-Mail: David_Harrold@Aurora.orgL Sr. Software Systems Engineer                         Phone : (414) 647-6204L Aurora Health Care                                    FAX   : (414) 647-4999I 3031 W. Montana Street                                Milwaukee, WI 53234r  X "A common mistake people make when trying to design something completely foolproof is to/ underestimate the ingenuity of complete fools."q   ------------------------------  % Date: Wed, 27 Jun 2001 16:29:50 +0100i% From: Alan Greig <a.greig@virgin.net>  Subject: Re: First lost sale8 Message-ID: <5qujjtgra9vlik8s9444nq7pk7jqkuf4d6@4ax.com>  C On Tue, 26 Jun 2001 00:32:41 -0500, "Rich Jordan" <rjordan@mcs.net>f wrote:  K >VAX upgrade, single node to 2-node Alpha SCSI cluster, supporting a CA appoJ >and custom code.  Quotes were going out this Friday,  with a certainty ofE >one or another option being purchased.  Customer called with lots oftK >questions and angst, and stated upgrade on hold, probably dead, due to theeM >Compaq announcement and their management reaction to it.  This site had just L >gotten its VMS confidence back up to reasonable levels, and the upgrade had- >displaced previous plans to move to Solaris.e > K >I know two nodes and storage is a flyspeck to Compaq, but it was importantn >to us.  Thanks a lot, Mikey C.e  F We've just terminated discussions to buy Alphaservers for a particularF plant running SAP. We were looking at Tru64 given the non-availability( of SAP on VMS. We are now looking at HP.  F I suspect we will cancel plans to upgrade some US VAX systems to AlphaD as contracts have not yet been signed. I'm just glad we migrated our" own site before this announcement.   >Sigh... >e >d   -- Alan   ------------------------------   Date: 27 Jun 2001 06:18:33 GMT) From: leslie@clio.rice.edu (Jerry Leslie)n Subject: Re: FreeVMS' Message-ID: <9hbtrp$h9g$1@joe.rice.edu>e  , John Eisenschmidt (jeisensc@aaas.org) wrote: :r1 : Would you prefer an OS written in RPG or PL/1? d :o One OS was written in PL/1...r  )    http://www.multicians.org/general.htmln  A   "Multics runs on special expensive CPU hardware that provides aaD    segmented, paged, ring-structured virtual memory. The system is aH    symmetric multiprocessor with shared physical and virtual memory. The,    operating system was programmed in PL/I."   --Jerry Leslie   ------------------------------    Date: 27 Jun 2001 00:21:06 -0700) From: P.Young@unsw.EDU.AU (Patrick Young)i Subject: Re: FreeVMS= Message-ID: <55f85d77.0106262321.3418c9f1@posting.google.com>-  
 Oh please...    E I have OpenVMS 7.2-1 source sitting right next to me in my bedroom asn2 I type this on my PC164/500 running OpenVMS 7.2-1.  > The source code for OpenVMS is not expensive (and a worthwhile investment).  C There are few secrets. As far as I am concerned OpenVMS is OPEN - I  haveE source. I can use the source code for my licensed hardware at work toe performID my work job function. In recent years Compaq has bent over backwards to make;3 OpenVMS available to everyone this is a good thing.e  A If OpenVMS goes under - we all know how it works - we can rebuildx
 (hopefully9 not on Intel though - not that we would have any choice).u   ------------------------------   Date: 27 Jun 2001 17:52:33 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)s Subject: Re: FreeVMS, Message-ID: <9hd6h1$2g9q$1@info.cs.uofs.edu>  # In article <sb38ed9b.052@aaas.org>,w.  John Eisenschmidt <jeisensc@aaas.org> writes: |>1 |> Would you prefer an OS written in RPG or PL/1?s |>  E What's wrong with PL/1??  One of the better OSes I worked with in theu% past was written primarily in PL/1.  g   bill   -- tJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   o   ------------------------------   Date: 27 Jun 2001 17:53:09 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)> Subject: Re: FreeVMS, Message-ID: <9hd6i5$2g9q$2@info.cs.uofs.edu>  / In article <3B396CF4.68010709@ne.mediaone.net>,d3  Monty Brandenberg <mcbinc@ne.mediaone.net> writes:i |> John Eisenschmidt wrote:e |> > g |> > e0 |> > Would you prefer an OS written in ... PL/1? |> d |> That would be Multics.r |>   And others.....d   bill   -- >J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   s   ------------------------------  % Date: Wed, 27 Jun 2001 09:38:26 -0400e- From: "Richard D. Piccard" <piccard@ohio.edu>p+ Subject: Re: FTP LIST problem. Help Please!s( Message-ID: <3B39E1D4.845EFDE8@ohio.edu>   John Santos wrote:   > [snip]  D > whenever I download something to my PC using WS_FTP, I get versionC > numbers on the output, which W2K treats as part of the file type,yF > so I need to rename them to change ".DOC;1" to ".DOC" before it willA > recognize it as a MS Word file.  Maybe this is a good thing ;-)dE > I'm using TCPWare V5.4's built-in FTP server on VMS.  How do I make ( > version numbers vanish on the PC side?  T There are some variations from version to version of WS_FTP, but I think you will beS able to figure it out after looking at the instructions I have prepared for our Webm Pagemasters, on-line atv  C                 http://www.ohiou.edu/pagemasters/memo85/ws_ftp.html,  M Steps 5 and 9 are what strips off the version numbers.  Some of the items aretS specific to our environment, but I suspect you will be able pick out what you need.   #                                 RDPs   --B ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  % Date: Wed, 27 Jun 2001 02:03:58 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>t Subject: Re: FUD, Message-ID: <3B39774D.4C009707@videotron.ca>   Roger Ivie wrote:9K > I'm not so sure. Had they done it slowly, there would be years of gripingiG > and complaining about how Compaq is _really_ committed to iVMS and isMH > just milking the Alpha customers while hiding what they're up to. This5 > way the outrage is all out in the open all at once.p  J Assuming it woudl take 18 months for the VMS group to port to IA64, CompaqM could have delayed the announcement of the death of Alpha by 2 years. At that M time, IA64 would have become a known entity and then customers would have hadnN an almost instant choice between the current IA64 and the current Alpha boxes.  L If IA64 does have much better performance, Compaq could then justify canningZ Alpha with statistics showing major customers switching to IA64 due to better performance.  N Remember that we are talking about serious applications and serious customers,L not your average windows weenie who stands in line all night in order to getN the latest version of Windows the very first day. Serious customers don't likeM suddent changes such as the bomb Compaq dropped, and serious customers do notd, like their IT supplier to break commitments.  M So it seems that Compaq isn't quite ready for prime time enterprise customers W because their PR is still very much PC focused and mishandles enterprise announcements.   K And Winkler, Mr "Windows will dominate the world" seems to be gaining power " inside of Compaq, not a good sign.   ------------------------------  # Date: Wed, 27 Jun 2001 11:58:34 GMTc. From: "Alphaman" <alphaman64@nixspam-home.com> Subject: Re: FUD; Message-ID: <KTj_6.11307$P5.3924053@news1.rdc1.tn.home.com>r  8 Terry C Shannon <shannon@world.std.com> wrote in message= news:Pine.SGI.4.21.0106260906170.5295-100000@world.std.com...sC > Well stated. This newsgroup benefits Sun, et al, far more than itp > benefits Compaq and VMS.  G Look, Terry -- you've had this news for what, a week?  More?  We got it-C Monday.  You had it spoon fed to you in the comfort of a teak linedbL conference room in plush leather chairs with all kinds of smiling Q standingD around, warmly comforting you.  We got it via c.o.v, compaq.com, theJ Inquirer, alphanews.net, or the Register.  We had to go find stuff out for
 ourselves.  F Put yourself in our position and understand that customers, EspeciallyJ OpenVMS customers, DON'T LIKE SURPRISES.  That's why we run OpenVMS, after all.  I Compaq bungled this one worse than AlphaNT.  Did they honestly think thatp" surprising people was a good idea?   Aaronn --> Aaron Sakovich  http://members.home.net/sakovich/alphaman.html> Make April 15 just another day:        http://www.fairtax.org/K "Oh my God, they killed Alpha!!!  You bastards!" (Anonymous Alpha Engineer)e   ------------------------------  % Date: Wed, 27 Jun 2001 13:30:51 +0100l  From: steven.reece@quintiles.com Subject: Re: FUDH Message-ID: <OF42A73B4F.2E7BE924-ON80256A78.00440329@qedi.quintiles.com>  J Calm down Aaron.  At some point _everybody_ would be surprised, except theD people that made the decision and the person that thought of it as a possibility in the first place.t  F Drip feeding the market wouldn't help as we'd go through cycles of "OhI look, there's gonna be two platforms running these O/Ses" followed by "Oh H dear, they've just killed off one of the architectures".  Compaq clearlyH couldn't gather all of the customers, potential customers and interestedI others together in their teak-lined (if indeed they are) offices and telllG them that way since (a) it would be too expensive and (b) someone wouldeF post it to a web site or newsgroup before some had had their meetings.  K Surprises are bound to happen.  In VMS land it would be more appropriate todK say that we don't like rapid change and we don't like things that lose datat or affect the status quo.s  K VMS Engineering were surprised and I would guess that Tru64 Engineering ande, all the other people around Compaq were too.  J Terry would have had whatever information he was granted access to under aJ NON DISCLOSURE AGREEMENT.  People tend to take those things seriously whenE they've got less money than the person or organisation asking for the>H signature.  Ignoring it does not do one's reputation, business or health very much good.u Steve.   Aaron Sakovich wrote:e >>>iG Look, Terry -- you've had this news for what, a week?  More?  We got it C Monday.  You had it spoon fed to you in the comfort of a teak linedpC conference room in plush leather chairs with all kinds of smiling Qt standingD around, warmly comforting you.  We got it via c.o.v, compaq.com, theJ Inquirer, alphanews.net, or the Register.  We had to go find stuff out for
 ourselves.  F Put yourself in our position and understand that customers, EspeciallyJ OpenVMS customers, DON'T LIKE SURPRISES.  That's why we run OpenVMS, after all.  I Compaq bungled this one worse than AlphaNT.  Did they honestly think thatG" surprising people was a good idea? <<<n   ------------------------------  % Date: Wed, 27 Jun 2001 15:40:14 +0100y% From: Alan Greig <a.greig@virgin.net>- Subject: Re: FUD8 Message-ID: <1rrjjt8hvt219ejm1c80eiq28l0mhasjou@4ax.com>  , On Wed, 27 Jun 2001 04:33:05 GMT, "Alphaman"$ <alphaman64@nixspam-home.com> wrote:  9 >Terry C Shannon <shannon@world.std.com> wrote in messaged> >news:Pine.SGI.4.21.0106260906170.5295-100000@world.std.com..., >> On Mon, 25 Jun 2001, Dean Woodward wrote: >>B >> > Um, guys? Anyone notice that Andrew hasn't had a single thingF >> > to say about the Alpha -> Intel deal?  He doesn't need to, you're) >> > all doing his job for him, as usual.s >>D >> Well stated. This newsgroup benefits Sun, et al, far more than it >> benefits Compaq and VMS.l >rL >Perhaps it's time for Compaq to listen to customers?  After all, it appears >their competitors are.   ? But Compaq did listen to customers. Capellas said he had talked-@ personally to lots of major Alpha customers and the response was6 "unbelievably positive". I loved that choice of words.  M >If Compaq doesn't like what's being said by their customers in this forum or6I >anyplace else, they should take a look in the mirror, not bitch and moanb >about the customers.n >pK >Maybe rather than saying "We are going to start porting to IA64", it wouldMG >have been better received if they'd said "Our initial port to IA64 hasoH >booted and is running at Spitbrook -- betas will be available within 12  F You know why I think that didn't  happen? Because I think they changedD their minds about killing  VMS stone dead at the same time as Alpha.F That remains an option for the future and probably the favoured optionB of many Compaq senior management but the door has not been slammed shut.   J >months.  Here is a demo of iVMS on IA64."  Maybe if they'd started sayingK >"Watch for great news in this space" and slowly let the cat out of the bagnI >instead of surprising everyone on Monday morning.  Again.  Maybe if theyrM >hadn't sold their soul to Barrett & Co. for some undisclosed "licensing fee"sK >to remove another 64 bit competitor from Inhel's path and had instead said J >they were going to a truly open multi-platform strategy.  Maybe if they'dC >gotten Larry Ellison to say "OpenVMS" on the same PAGE as "Tru64".o > I >Maybe if they hadn't chosen the one processor family more OpenVMS systemu  >managers HATE than any other... >oI >But, these are their choices.  Life goes on, and we are stuck with them,sD >like them or not.  What a great position for a customer to be in... >s >Aaron   -- Alan   ------------------------------  % Date: Wed, 27 Jun 2001 16:33:02 +0100a  From: steven.reece@quintiles.com Subject: Re: FUDH Message-ID: <OF1BCF4DB6.200EF5F9-ON80256A78.0055573B@qedi.quintiles.com>  & But did he say unbelieveable for whom?   Steve.   Alan Greig wrote:r@ >But Compaq did listen to customers. Capellas said he had talkedA >personally to lots of major Alpha customers and the response was,7 >"unbelievably positive". I loved that choice of words.    ------------------------------  % Date: Wed, 27 Jun 2001 12:46:00 -0300s) From: fabio_compaq@ep-bc.petrobras.com.br  Subject: Re: FUDL Message-ID: <OF363A524A.EB3AC139-ON03256A78.005693D7@ep-bc.petrobras.com.br>  ( Customers no ? CEO x CEO conversations !  
 F=E1bio C.        1 steven.reece@quintiles.com em 27/06/2001 12:33:025  , Favor responder a steven.reece@quintiles.com             Info-VAX@Mvb.Saic.Comr       Assunto: Re: FUD        & But did he say unbelieveable for whom?   Steve.   Alan Greig wrote:0@ >But Compaq did listen to customers. Capellas said he had talkedA >personally to lots of major Alpha customers and the response wasx7 >"unbelievably positive". I loved that choice of words.              =v   ------------------------------  % Date: Wed, 27 Jun 2001 12:54:42 -0400n2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: FUDL Message-ID: <rdeininger-2706011254440001@user-2ive7go.dialup.mindspring.com>  5 In article <3B39774D.4C009707@videotron.ca>, JF Mezei?% <jfmezei.spamnot@videotron.ca> wrote:l  L > Assuming it woudl take 18 months for the VMS group to port to IA64, CompaqO > could have delayed the announcement of the death of Alpha by 2 years. At thatrO > time, IA64 would have become a known entity and then customers would have hadlP > an almost instant choice between the current IA64 and the current Alpha boxes.  I They would have had to keep pouring money into EV8 for those 2 years.  Do G you think nobody would have noticed if they'd layed off the whole team,t4 and Intel had picked them all up the following week?   --   Robert Deininger rdeininger@mindspring.com    ------------------------------  # Date: Wed, 27 Jun 2001 17:03:05 GMTp= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)  Subject: Re: FUD0 Message-ID: <009FE291.F7E530F7@SendSpamHere.ORG>  ` In article <1rrjjt8hvt219ejm1c80eiq28l0mhasjou@4ax.com>, Alan Greig <a.greig@virgin.net> writes:- >On Wed, 27 Jun 2001 04:33:05 GMT, "Alphaman" % ><alphaman64@nixspam-home.com> wrote:= >=: >>Terry C Shannon <shannon@world.std.com> wrote in message? >>news:Pine.SGI.4.21.0106260906170.5295-100000@world.std.com...a- >>> On Mon, 25 Jun 2001, Dean Woodward wrote:g >>> C >>> > Um, guys? Anyone notice that Andrew hasn't had a single thing G >>> > to say about the Alpha -> Intel deal?  He doesn't need to, you'ret* >>> > all doing his job for him, as usual. >>> E >>> Well stated. This newsgroup benefits Sun, et al, far more than it  >>> benefits Compaq and VMS. >>M >>Perhaps it's time for Compaq to listen to customers?  After all, it appears  >>their competitors are. >5@ >But Compaq did listen to customers. Capellas said he had talkedA >personally to lots of major Alpha customers and the response waso7 >"unbelievably positive". I loved that choice of words.r  D ... and you believe him?  Sheesh, he could be a law(lie)yer with all8 of the untruths unleashed since the digital acquisition.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMs             O city, n., 1. a place where trees are cut down and streets are named after them.d   ------------------------------  , Date: Wed, 27 Jun 2001 13:51:28 +0200 (CEST): From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl>( Subject: Re: Full port of VMS to ItaniumJ Message-ID: <Pine.LNX.4.21.0106271343350.15007-100000@irys.stanpol.com.pl>  $ On Wed, 27 Jun 2001, Alphaman wrote:  4 >+Robert Deininger <rdeininger@mindspring.com> [...]D >+> DECnet V has been the subject of as much FUD as anything in thisK >+> newsgroup.  It isn't that bad.  The management interface is annoying at F >+> first, and the learning curve is non-trivial.  But I don't see any* >+> fundamental problems with the product. >+H >+My opinion is that if you have a product that smacks of English in itsE >+verbosity, why take a giant step backwards to an NCL-like language -    The response was here:1# "that is the OSI naming standard" !(  & >+that is anything but comprehensible? >+ >+ Show known line countersu [...]o >+ show routing child entity *    Definitely agree ! 5  Getting differrence in naming convention withing thew2 same network layer, regarding of the used protocol4 (SHOW CSMA vs. SHOW FDDI) is hm... misunderstanding. IMHO, of course.  8  May be possible having both convention available (like 7 in UCX) - but DECOMPAQ :) was not start the way; shame.h3 BTW: the problems with the "VMS/DCL syntax" in someg1  first TCPIP releases (some command doesn't work) 6  really irritates me, for the same reason: why someone7  must read tons of syntax, including the un*x one... :]   + >+[...]  This is _not_ intuitively obvious.6  	  Really !f   [...].. >+Why deliberately make a product non-obvious?  ( ..the advocacy may ask higher price ? ;)   [...]aL >+I find NCL to be the closest thing to a UNIX command line under VMS.  If I" >+wanted UNIX, I'd get a lobotomy.    :)       Regards - Gotfryd   -- eE =====================================================================aF $ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") - 		THEN EXCUSE/OBJECT=MEc. $!                        GS@stanpol.zabrze.plE =====================================================================g   ------------------------------  / Date: Wed, 27 Jun 2001 08:23:08 +0200 (MET DST)g& From: Rudolf Wingert <win@fom.fgan.de>) Subject: Re: Full port of VMS to Itanium. 6 Message-ID: <200106270618.IAA27560@sinet1.fom.fgan.de>   Hello,  H on Alpha we do know, what we have. A platform on which OpenVMS runs withI a very good speed (some applications run faster under OpenVMS then TRUE64aE on the same Alpha). But what's with the IA64. It is an complete other G design then Alpha, called EPIC. The software have to do things, that ithA does not before. IMHO the OS must be designed too, to support thenD software parralism. AFAIK OpenVMS is not. Also I think about all theG add ons, which have to be rewritten and will not be (e.g. DECwrite)!!!!rD If the M$ staff would be integrated in OpenVMS (Office, ...) may be  OpenVMS will have a chance.-   Regards Rudolf Wingert   ------------------------------  / Date: Wed, 27 Jun 2001 09:19:38 +0200 (MET DST)u& From: Rudolf Wingert <win@fom.fgan.de>) Subject: RE: Full port of VMS to Itanium.96 Message-ID: <200106270714.JAA27662@sinet1.fom.fgan.de>   Hello,   John Macallister wrotes:   >>>sK Why should one shop's Itanium be different from another's re the running of/E VMS any more than with Windows? Windows runs on any shop Pentiums,etc H because so many people use Windows and the market makes it worthwhile toJ cater for different hardware configurations. iVMS could be in a similar or better position. <<<n  E Why not!!! Compaq PCs are also different to the PCs of other vendors. C We have tried to insert a special PCI card, working on a lot of PCs0I and SGIs with PCI. Not working with Compaqs PCs. First we tried to insert F them on a server. The server did not boot. The special Compaq Bios didG not except this card. We did made a service call. The answer: In CompaqiK server you can use onle qualified PCI cards. Then we used a desktop PC fromfG Compaq. This PC we could boot. But during working with the PCI card, we F got a lot of unexspected errors. So our expirience with Compaq PCs is:C There are quite different to other. In case of this, OpenVMS may beoH (I don't believe that) run on Compaqs IA64 PCs, but not on other. I willH postulate, that next year Compaq will say, we have tried to port OpenVMSH to IA64. But we are so sorry,  our engineers where unable to do it (mean the managment did not want it).    Regards Rudolf Wingert   ------------------------------   Date: 27 Jun 2001 04:20 CDT ' From: carl@gerg.tamu.edu (Carl Perkins)e) Subject: RE: Full port of VMS to Itanium.m- Message-ID: <27JUN200104202646@gerg.tamu.edu>a  < John Macallister <J.Macallister1@physics.ox.ac.uk> writes...G }> > You'll be able to buy an Itanium system from "any computer shop". a } J }>Yes, but will VMS run on an "any shop" Itanium?  And will EDT be useableH }>on and "any shop" keyboard, or will we still need three fingers to hit	 }>"gold"?  } L }Why should one shop's Itanium be different from another's re the running ofF }VMS any more than with Windows? Windows runs on any shop Pentiums,etcI }because so many people use Windows and the market makes it worthwhile towK }cater for different hardware configurations. iVMS could be in a similar orr }better position.a }Johnb  F In case you didn't notice, NT on ALpha used a different "console" than VMS and True64.i  G - Will VMS-IA64 use the same BIOS as NT rather than somthing a lot liken   the current console software?d9 - Will VMS-IA64 function without some PALcode-like stuff?   C If both of these are "yes", then you may be able to run VMS-IA64 ont commodity IA64 hardware.  H If either, or both, are "no", then you will only be able to run VMS-IA64F on specially constructed motherboards which will almost certainly only be available from Compaq.e   --- Carl   ------------------------------  % Date: Wed, 27 Jun 2001 03:02:39 -0700m1 From: Vance Haemmerle <vance@toyvax.Tucson.AZ.US> ) Subject: Re: Full port of VMS to Itanium.a3 Message-ID: <3B394CCF.5617259E@toyvax.Tucson.AZ.US>w   Carl Perkins wrote:s  H > In case you didn't notice, NT on ALpha used a different "console" than > VMS and True64.u > I > - Will VMS-IA64 use the same BIOS as NT rather than somthing a lot likes! >   the current console software?u; > - Will VMS-IA64 function without some PALcode-like stuff?  > E > If both of these are "yes", then you may be able to run VMS-IA64 on  > commodity IA64 hardware. > J > If either, or both, are "no", then you will only be able to run VMS-IA64H > on specially constructed motherboards which will almost certainly only > be available from Compaq.-  -   And which choice do you think is realistic?A  D   Which options allows Compaq to continue to lock in their customers to their corporate whims?.   --B Vance Haemmerle               Internet   vance@toyvax.Tucson.AZ.USK Tucson, AZ                    Web        http://toyvax.Tucson.AZ.US/~vance/s   ------------------------------  % Date: Wed, 27 Jun 2001 11:36:33 +0100m8 From: John Macallister <J.Macallister1@physics.ox.ac.uk>) Subject: RE: Full port of VMS to Itanium.uN Message-ID: <35666012DF4CD411BE940090279FA240010BEFDA@ppnt41.physics.ox.ac.uk>  I Instead of worrying ( moaning and groaning ) about the VMS packages whichtJ may not be ported to VMS why not consider the possibility that a multitudeJ of products might be ported from Windows to VMS ? If iVMS includes the APII hooks of Windows porting from Windows to iVMS will not be a major hurdle.,  H Frozen products on VMS are in that state because it was not commerciallyI viable to maintain them; they're only there because it takes little or nogJ effort to keep them there. If Alpha images can be VESTed ( perhaps it willK be called INVESTed ? ) to run on Itanium many old VMS favourites may remain.
 available.  I The key issue with iVMS is not whether VMS is ported to Itanium/Intel buteG how well/completely the port is implemented i.e. across all flavours of0I Itanium/Intel , API hooks to provide the same Windows GUI and a marketing3H and licensing policy which will make iVMS available in any store selling
 computers.   John  B Name: John B. Macallister  E-mail: j.macallister1@physics.ox.ac.ukH Post: Nuclear and Astrophysics Laboratory, Keble Road, Oxford OX1 3RH,UKA Phone: +44-1865-273388 (direct)  273333 (reception)  273418 (Fax)"   ------------------------------  % Date: Wed, 27 Jun 2001 11:51:57 +0100O8 From: John Macallister <J.Macallister1@physics.ox.ac.uk>) Subject: RE: Full port of VMS to Itanium.tN Message-ID: <35666012DF4CD411BE940090279FA240010BEFDB@ppnt41.physics.ox.ac.uk>  , Anyone remember the AXP -> Alpha transition?  I When Alpha was first launched we were all told to refer to it as AXP. AXPiJ was forced down our throats although it was clear that we all were callingK it Alpha. I've always referred to AlphaVMS rather than VMS/AXP or whatever.tK For me the AXP -> Alpha transition occurred about 1 millisecond after firstcF learning about the new Alpha systems. I'm not sure when the "official"J transition took place but didn't cause any major perturbations as far as I know.o  = The AXP -> Alpha transition was another painless transition. a  ' Another two transitions spring to mind:   * The Blue Digital to Red Digital transtion.  ! The Digital to Compaq transition.a  L None of the above transitions caused any problems for any of our software as far as I can tell.  G With such a good record of transitions from from one VMS environment to K another it helps to instill some confidence that the transtion to iVMS will  be relatively smooth.r   John  B Name: John B. Macallister  E-mail: j.macallister1@physics.ox.ac.ukH Post: Nuclear and Astrophysics Laboratory, Keble Road, Oxford OX1 3RH,UKA Phone: +44-1865-273388 (direct)  273333 (reception)  273418 (Fax)    ------------------------------  % Date: Wed, 27 Jun 2001 04:24:35 -0700d1 From: Vance Haemmerle <vance@toyvax.Tucson.AZ.US>r) Subject: Re: Full port of VMS to Itanium. 3 Message-ID: <3B396003.19F7904C@toyvax.Tucson.AZ.US>    John Macallister wrote:e  # > The Digital to Compaq transition.   *   Painless?  We're still feeling the pain.   --B Vance Haemmerle               Internet   vance@toyvax.Tucson.AZ.USK Tucson, AZ                    Web        http://toyvax.Tucson.AZ.US/~vance/s   ------------------------------  % Date: Wed, 27 Jun 2001 12:13:28 +0100i% From: Alan Greig <a.greig@virgin.net>n) Subject: Re: Full port of VMS to Itanium.d8 Message-ID: <abfjjt8kub6nuv4l2rc886lv336sk4hi95@4ax.com>  5 On Mon, 25 Jun 2001 13:12:49 -0400, "Fred Kleinsorge" $ <kleinsorge@star.zko.dec.com> wrote:     >' >aL >Actually, the engineers here in Nashua seem, well, to be almost universallyI >positive about this.  At the same time as it was announced, we also were K >told our headcount would increase by a number that we will be hard pressedV* >to find engineers to fill quickly enough.  E And we wish you all the success in porting ahead of schedule with lowuF bug count but with as few shortcuts you/we might come to regret later,  ) If you can manage as much as possible of:e  E 1) Ability to run Alpha binaries without a manual VEST. Hey maybe you  can even manage VAX binaries!gE 2) DII COE work expanded to allow binary compatibility for common ABI  versions of Unix.m 3) Get the ISVs onsideE 4) A very, very, very early technology demonstration release on IA64.   E Then we might be going somewhere. Point 4 is maybe the most importantd1 of all because until this point it is vapourware.s  C Over and above all of this Compaq sales need to visit all customersw *RIGHT NOW*.     -- Alan   ------------------------------  % Date: Wed, 27 Jun 2001 12:19:53 +0100 % From: Alan Greig <a.greig@virgin.net>s) Subject: Re: Full port of VMS to Itanium.f8 Message-ID: <42gjjts9q7a33cfidbha9ql9b094bqn2dg@4ax.com>  5 On Mon, 25 Jun 2001 15:18:58 -0400, "Fred Kleinsorge"e$ <kleinsorge@star.zko.dec.com> wrote:   >e& >Robert Deininger wrote in message ... >aJ >>I'll keep asking, without expecting an answer.  Were you folks consulted/ >>about this VMS porting project ahead of time?' >> >t >rL >Only a handful of very senior people, some of whom were *highly* technical,K >were involved in the decision.  Oddly enough, the entire thing was startedgE >by a handful of our most senior technical HW people doing a analysisrI >projecting things out through the next 5-10 years.  It wasn't managementy >pushing it down.o  C No but management robbed investment and *real* marketing from Alpha.F delaying EV7 and reducing the number of entrenched systems at customerF sites. Thus management fiddled with the underlying variables to ensure> that the final technical decision could only go one way. In my
 opinion...  I >But very few of the folks in the trenches, are told of this type thing -R >mostly for legal reasons. >.K >We're digesting this, just like you are.  The good news is that we are allb@ >pretty much looking at this as something pretty fun/cool to do. >t >u >m   -- Alan   ------------------------------  % Date: Wed, 27 Jun 2001 13:06:13 +0100r% From: Alan Greig <a.greig@virgin.net> ) Subject: Re: Full port of VMS to Itanium.-8 Message-ID: <seijjt4r7la6m857ar579t3uv4gcu7l2f0@4ax.com>  = On 25 Jun 2001 18:35:54 -0400, jordan@lisa.gemair.com (JordanD Henderson) wrote:3  - >In article <9h8bl3$o4v@gap.cco.caltech.edu>,s4 >David Mathog <mathog@seqaxp.bio.caltech.edu> wrote: >>[snip] >>3 >>  ***COMPAQ MANAGEMENT WANTS THIS PORT TO FAIL***3 >> > K >That's as absurd as anything that's been posted here recently.  And that'so >saying a LOT.  F No it's not absurd but I would say "SOME OF COMPAQ MANAGEMENT WANT THEA PORT TO FAIL". Had all wanted it to fail it would never have beendF announced. Had all wanted it to succeed they'd have instructed porting) work to start some considerable time ago.e    I >People have been jumping up and down, red-in-the-face, screaming in thisaI >newsgroup for VMS on commodity hardware.  It looks like Compaq has takenrH >a HUGE step in that direction and many of the same people are screaming% >"woe is me, the end of VMS is nigh!"n  F But we wanted the port in advance of a possible Alpha cancellation. DoA you honestly believe there would be so much uncertainty about theS< future right now if  VMS was already up and running on IA64?   >nE >I remember a quote from the Commodore management when the Amiga diedeC >(effectively).  The manager was quoted as saying something to the nG >effect "Our staunch advocates in the community didn't do us any favorsy" >by being so shrill all the time." >n0 >People need to turn down the paranoia a little.  D I have had DEC tell me they would never drop the Jupiter project twoD weeks before they did. I have had Compaq tell me they would not dropB Alpha/NT two weeks before they did. I have had Compaq tell me they> would not drop Alpha one week before they did. On all of theseC occasions I believed it was most likely Compaq were lying (although7F unknowingly) to me and I was right. I have no track record of paranoia that I can see.   B DEC/Compaq have a proven track record of breaking promises made toD customers now and that's why the newsgroup is full of anger. Not the other way round.    
 >>Regards, >> >>David Mathog >>mathog@caltech.eduA >>Manager, sequence analysis facility, biology division, Caltech  L >>**************************************************************************L >>*                       RIP VMS & ALPHA                                  *L >>************************************************************************** >i >-Jordan Henderson >jordan@greenapple.com   -- Alan   ------------------------------  % Date: Wed, 27 Jun 2001 14:14:38 +0100u% From: Alan Greig <a.greig@virgin.net>i) Subject: Re: Full port of VMS to Itanium.t8 Message-ID: <t0mjjtk98h3fuq5ejcjll57t46nurur74p@4ax.com>  E On Tue, 26 Jun 2001 17:06:43 -0400, "Bill Todd" <billtodd@foo.mv.com>s wrote:   >e? >"Bill Gunshannon" <bill@triangle.cs.uofs.edu> wrote in messagec' >news:9hachg$111h$1@info.cs.uofs.edu...t >h >... >... >c3 >> What would it take to make VMS a mainstream OS??  >tK >At this point, a miracle of Biblical proportions:  Compaq has just assured  >that.  B How about a Compaq/Intel merger followed by a release of VMS whichA supported Office (possibly under Wine) plus all Linux/T64/Sloaris0E binaries, all Alpha binaries (including most privileged code) and VAX E user mode binaries shipping on single user workstations complete with0; Pathworks at less than the cost of NT on the same hardware.n  E However the above would probably meet your definition of a miracle of[ biblical proportions.b  7 I think you would agree that given Compaq's actions andsE pre-dispositions of some if its senor management that the discussions+E we are having here have been argued at senior Compaq level. That they+C didn't just take the pain right now and say VMS will continue to be A developed on Alpha for 3 more years (complete DII COE) then entertE maint. mode indicates to me that VMS must still have some significanta= support with some of the senior management or that some othertE significant factor forced their hand. I will continue to believe thatsC a miracle is possible for a while yet at least. But VMS engineeringnA and marketing must get the ball in play fast or they will fail by 	 default.      E >> First, it has to run on the same hardware as everything else, withu >> no price premium required. H >> Second, it has to be priced in the same catagory. (Yes, Linux and BSDG >> are free, but service and support cost real money.  I am  not sayingfF >> VMS must be free, but it has to be no more expensive than Win2000.)B >> Third and most important, it has to be taken out from under theI >> bushel basket and placed high oh a pedestal where everyone can see it.R# >> Marketing, marketing, marketing.y >> >> It can be done. >?F >Not any more.  Not that it was ever reasonable to expect it - but oneJ >*might* have expected Compaq to be able to recognize the unique strengthsF >assets like Alpha and VMS offered to higher-end applications and haveM >cultivated expansion in those areas, especially given the ROI one can expectGM >there.  And there's no reason whatsoever to expect them to be any less blind K >to VMS's strengths than they were to Alpha's (hell, Alpha at least *could*=M >have penetrated lower-end markets without any significant effort on Compaq'saD >part, running Linux:  *that's* how interested Compaq is in fielding  >non-Windows competition there). >o >... > C >> It's one thing to be negative about what Compaq has done, but it 3 >> doesn't mean we have to give up on VMS entirely.f > L >Yes, it does.  The only question is how long some people will take to admit >it. >M >- billU >a >n   -- Alan   ------------------------------    Date: 27 Jun 2001 09:53:36 -0500- From: koehler@encompasserve.org (Bob Koehler)n) Subject: Re: Full port of VMS to Itanium.m3 Message-ID: <XmOdbRkdPvbb@eisner.encompasserve.org>i  \ In article <3B38AFED.31B0476B@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > N > In terms of VMS on IA64, will Compaq provide the >>> prompt on all its Intel$ > machines from now on ? I doubt it.  H Piece of cake.  In the tradition of using obsolete technology as consoleC front ends, the first IA-64 to ship with VMS will probavkly have ani< Alpha EV5 front end.  Alpha already knows how to prompt >>>.  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporatione= NASA GSFC Flight Software       | Federal Sector, Civil GroupnE                                 | please remove ".aspm" when replyinge   ------------------------------  % Date: Wed, 27 Jun 2001 10:07:40 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca> ) Subject: Re: Full port of VMS to Itanium. * Message-ID: <3B39E8A8.DE9AB8@videotron.ca>   Alan Greig wrote:e+ > If you can manage as much as possible of:l > G > 1) Ability to run Alpha binaries without a manual VEST. Hey maybe youo > can even manage VAX binaries!e  D Personally, I think that they should focus on the reverse of the COEL initiative. They should port the VMS system services and run time library toM Linux, and port TPU to Linux. That will make it much easier for us to port of.L in-house applications to Linux and be done with VMS, allowing Compaq to shutN it down and forget about that pesky product that woudn't go away no matter how hard Compaq tried.   ------------------------------  % Date: Wed, 27 Jun 2001 08:08:58 -0600 % From: Dan O'Reilly <dano@process.com>w) Subject: Re: Full port of VMS to Itanium.IB Message-ID: <5.1.0.14.2.20010627080724.027934d8@ntbsod.psccos.com>  & At 08:07 AM 6/27/2001, JF Mezei wrote: >Alan Greig wrote:- > > If you can manage as much as possible of:n > > I > > 1) Ability to run Alpha binaries without a manual VEST. Hey maybe yout! > > can even manage VAX binaries!2 >NE >Personally, I think that they should focus on the reverse of the COEsM >initiative. They should port the VMS system services and run time library tomN >Linux, and port TPU to Linux. That will make it much easier for us to port ofM >in-house applications to Linux and be done with VMS, allowing Compaq to shutrO >it down and forget about that pesky product that woudn't go away no matter howr >hard Compaq tried.   J You know, if you put as much effort into trying to make something positiveL of what's going on as you are in slamming EVERYTHING constantly, we might beK able to move this whole thing forward in a positive way...sorry, but we are N all VERY aware you're angry about this, you don't have to keep up the constant$ barrage of intensely negative posts.   ------------------------------  % Date: Wed, 27 Jun 2001 10:15:08 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>c) Subject: Re: Full port of VMS to Itanium.f, Message-ID: <3B39EA68.9002B598@videotron.ca>  5 > >>  ***COMPAQ MANAGEMENT WANTS THIS PORT TO FAIL***e  G Compaq would much prefer to succeed in its endeavours, only to find thelK customers still leaving VMS. This way, Compaq can say " we did our best, weoC tried hard but VMS was doomed from the start, it wasn't our fault".,  L If Compaq purposefully fails the port or takes a very visible action against0 VMS, they will be accused to squandering the OS.  L Compaq won't kill VMS, it wants it to die by itself. Eventually the comatose patient dies by itself.N   ------------------------------  % Date: Wed, 27 Jun 2001 14:21:30 +0100l% From: Alan Greig <a.greig@virgin.net>r) Subject: Re: Full port of VMS to Itanium. 8 Message-ID: <ocnjjt0594250b8imdg2b459ehgm0q747a@4ax.com>  E On Tue, 26 Jun 2001 17:18:51 -0400, "Bill Todd" <billtodd@foo.mv.com>  wrote:     >> iVMS. >> >> Let's go trekking ... > C >Is Compaq paying you, or are you simply an idiot with a big mouth?M >A Is Sun paying you?   >- billm >e >> >> John  >>E >> Name: John B. Macallister  E-mail: j.macallister1@physics.ox.ac.ukiK >> Post: Nuclear and Astrophysics Laboratory, Keble Road, Oxford OX1 3RH,UKoD >> Phone: +44-1865-273388 (direct)  273333 (reception)  273418 (Fax) >l >    -- Alan   ------------------------------  % Date: Wed, 27 Jun 2001 11:31:12 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)) Subject: Re: Full port of VMS to Itanium.0L Message-ID: <rdeininger-2706011131140001@user-2ive7go.dialup.mindspring.com>  J In article <9hatao$lke$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> wrote:     > > It can be done.s > G > Not any more.  Not that it was ever reasonable to expect it - but oneaK > *might* have expected Compaq to be able to recognize the unique strengthsmG > assets like Alpha and VMS offered to higher-end applications and havedN > cultivated expansion in those areas, especially given the ROI one can expectN > there.  And there's no reason whatsoever to expect them to be any less blindL > to VMS's strengths than they were to Alpha's (hell, Alpha at least *could*N > have penetrated lower-end markets without any significant effort on Compaq'sE > part, running Linux:  *that's* how interested Compaq is in fieldingi! > non-Windows competition there).h  D Fred pointed out that the doubts about Alpha originated in the AlphaF development group, not from on high.  They lost confidence.  They wereH scared by Intel's shadow.  I don't know what...  But once that happened, how could Compaq continue?  = In contrast, I don't detect any loss of confidence at OpenVMSo4 engineering.  Your comparison doesn't quite hold up.  G Your doubts about future Compaq management, however, remain valid.  Not, proven, but very valid.8   -- t Robert Deininger rdeininger@mindspring.com-   ------------------------------  % Date: Wed, 27 Jun 2001 11:25:12 -0400o2 From: rdeininger@mindspring.com (Robert Deininger)) Subject: Re: Full port of VMS to Itanium.eL Message-ID: <rdeininger-2706011125140001@user-2ive7go.dialup.mindspring.com>  5 In article <3B38E2FA.3C08A4F5@videotron.ca>, JF Mezeip% <jfmezei.spamnot@videotron.ca> wrote:t   > Robert Deininger wrote:aK > > Nope.  Now you go too far.  Digital's migration from vax to alpha was aAN > > success.  95% of user-mode code was compile-and-go. The VMS tranistion was > > easy for most of us. > O > From a technical point of view, the PORT was easy. But migration is more than'O > porting source code. You obviously didn't migrate from MAC-68k to MAC-powerpcp% > did you ? You'd see the difference.   & I most certainly did migrate on MacOS.  H From a technical point of view, the VAX-Alpha port was NOT easy.  It wasH very hard work by very good people.  If they made it look easy, that's a measure of how good they are.s  J There was one decision that differed significantly from the Mac case.  VMSE has separate executables for both platforms, and can't emulate VAX ontI Alpha on-the-fly.  So on a Mac, you launch a 68k application, and it justtH runs, slowly.  On VMS, you get a message telling you it's the wrong kindG of executable.  The Mac style makes life easier at first, but it bogged,H down performance for years.  The OS itself retained lots of 68k code forI far too long, and all those deep layers of calls, with mode switches back:E and forth, turned some tasks into molasses in winter.  If Digital hadcB provided on-the-fly emulation, you can bet they would have used itE internally, and alpha wouldn't have seemed nearly as fast.  There areCG advantages in both methods, and in _some_ situations I'd prefer the Maca method on VMS.  E The MacOS dynamic recompilation took a lot of work to produce, and no F doubt delayed some other work.  Also, Apple knew they were weak in theD compiler department.  If Metrowerks hadn't shipped a quality PowerPCA compiler, the whole PowerMac project would have flopped.  DynamicmF recompilation was something of an insurance policy, and Apple made the5 most of it.  By itself, it wouldn't have been enough.o  @O > If the migration from VAX to Alpha was done so well, how come there are stillm > so many vaxes around ? > N > How many times did Digital change the business aspects of VEST ? how come it0 > didn't come free with all systems from day 1 ?  I Now you're not talking about the port, you're talking about Dilbert.  The + people running Digital all had pointy hair.o  I > How come it was cheaper for some customers to remain on VAX because theoN > product they were using had not been ported to Alpha and those customers didJ > not have access to VEST ? How come Digital didn't provide (for years) anP > upgrade path between the VAX-only Message Router and the Alpha Mailbus-400 andN > X.500 Directory products and expected customers to buy brand new licenses ofO > the 2 separate products to replace the one product they had on VAX ? How come G > many of the gateways (noyably MRGATE between MR and VMSMAIL) were notr > available on MAILBUS 400 ?   See Dilbert.  N > Remember that messaging used to be a key market for VMS where it had a clearK > lead over everyone else, but that was squandered when Alpha appeared, andrN > later when Palmer gave away the ship to Microsoft and stopped the project toE > port Allin-1 to NT because it would have competed against Exchange.-   Dilbert.  iM > Sorry, why should you want to be loyal to Intel ? What is there to be loyalnP > about the company that steals and then kills the architecture and products youJ > WERE (past tense) loyal to ? Intel has no intentions to do anything with	 > Alpha. u  / We really don't know Intel's intentions, do we?   G > Consider that the EV7 group is staying at Compaq to complete the work P > instead of going to Intel with Intel promising to complete the work. That says, > a lot about Intel's intentions with Alpha.  H No that's just common sense.  EV7 is very far along; disruptions at thisI point would be counter-productive.  Compaq has spent nearly all the money G that EV7 needs, and Compaq will reap the rewards.  Intel has no use forlI EV7 internally, and no product line that will use it directly.  EV7 couldo _only_ stay at Compaq.  J EV8 is the opposite.  Compaq saw the need to spend billions more to finishD the project, and they apparently became scared of Intel's well-hypedE shadow CPU.  They lost the confidence that they could see the projecthH through.  Maybe they know they're lousy management.  Intel at the momentI seems to have the money to complete a huge development project, but lacks0I the technology and know-how to keep their own business on track.  PoolingoC all the technology and people on one product line might allow it to D succeed and impress.  Once Compaq lost confidence, their only way toI salvage anything from EV8 was to sell it as well as possible, and as soontJ as possible.  If Compaq got a good enough price, it may be a good deal forF them.  If they were out-foxed like they have been in the past, it willH probably kill the company.  We really don't have the information at this point to know.  D I suspect porting VMS, and Tru64, and NSK, will cost a lot less thanJ finishing EV8 would have.  Once Compaq decided or realized that they wouldF finish EV8 badly, late, or not at all, continuing would have been slowJ suicide.  This _might_ be a cure, if they have learned from past stupidity' and manage the remaining products well.o    / > There is no longer a plurial in the word CPU.a  J There's still IBM.  And Sun.  And if they all get fat and stop innovating,J some far-east company none of us have heard today of will dominate the CPUG business in 20 years.  And Hoff and friends might be porting VMS to thec newly-popular Dragonium CPU.   > And yes, many of us are stuck  > with now useless skills.  J You've been saying the same about useless skills for months (or years), soC this didn't change anything for you.  And your skills aren't truelyc# useless unless you want them to be.n   -- n Robert Deininger rdeininger@mindspring.com    ------------------------------  + Date: Wed, 27 Jun 2001 15:32:30 +0000 (UTC)C' From: david20@alpha1.mdx.ac.uk (D.Webb)r) Subject: RE: Full port of VMS to Itanium. + Message-ID: <9hcuad$6p6$3@aquila.mdx.ac.uk>/   In article <35666012DF4CD411BE940090279FA240010BEFDA@ppnt41.physics.ox.ac.uk>, John Macallister <J.Macallister1@physics.ox.ac.uk> writes:iJ >Instead of worrying ( moaning and groaning ) about the VMS packages whichK >may not be ported to VMS why not consider the possibility that a multitudepK >of products might be ported from Windows to VMS ? If iVMS includes the API J >hooks of Windows porting from Windows to iVMS will not be a major hurdle. >a  J Why should Microsoft start publishing their API now. They never had in the past.,J When we had NT on Alpha and had FX!32 to translate intel binaries to Alpha? did that result in being able to run NT executables under VMS ?  Of course not.  J When Affinity first came out it sounded as though we would be able to get 7 Intel NT applications easily ported and running on VMS.aH What did we get ? An extremely expensive and incomplete Windows API fromJ a third party company which then had problems with Microsoft over getting  details of that API.  M History suggests that no Microsoft products will be ported to VMS as a resultTC of VMS running on the same platform as Microsoft Operating systems.r    
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  % Date: Wed, 27 Jun 2001 11:41:51 -0400a2 From: rdeininger@mindspring.com (Robert Deininger)) Subject: Re: Full port of VMS to Itanium.rL Message-ID: <rdeininger-2706011141530001@user-2ive7go.dialup.mindspring.com>  J In article <9hattq$mp7$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> wrote:  A > "Robert Deininger" <rdeininger@mindspring.com> wrote in messageeH > news:rdeininger-2606011102570001@user-2ive7jq.dialup.mindspring.com... >  > ...t > J > > Those engineers are the best chance to make a future intel CPU that is > > worth cheering for.  > N > It amazes me how much stock so many people appear to be placing in a productG > that Intel has not yet announced even a suggestion of an intention ofa
 > developing.h  J I'm not placing stock in it.  I'm saying it's possible.  Mainly to balanceI the shouting of folks who always look for the bad side of any situation. bJ (Not necessarily you.)  Intel ought to do much better, in technical terms,B with the Alpha assets.  They will also benefit by the removal of aD competing product, but evidently alpha was already in trouble insideJ Compaq. We just didn't know it yet. Intel didn't need to spend vast $$$ toI remove alpha, they only had to wait.  It seems to me that Intel wants anduJ needs more from this deal, and will use what they get as well as they can.  L > Let's see:  IA64 was announced at least 7 years ago, and has yet to appearL > in commercial quantities.  So *if* Intel wanted to incorporate *any* AlphaK > technology (that it doesn't already have) into a product, just when woulds% > such a product be likely to appear?   I You come close to making my point.  IA64 has been in trouble.  Intel knewoF it, and everyone else knew.  Intel needed a shot in the arm. This shotH seems likely to significantly improve the IA64 product line, in terms of both time and features.   t1 > It isn't Merced, and clearly won't be McKinley.c  , Agreed.  In fact I've already said the same.   > And whatever Intel buildseM > after McKinley is likely already pretty well set in concrete (using all thea@ > stuff they likely needed to steal from the HP implementation).  H Here I disagree.  McKinley+1 will likely change due to this acquisition.F Intel realized they were approaching some scary technical roadblocks. = They are just better at hiding their troubles than Compaq is.w   -- a Robert Deininger rdeininger@mindspring.comn   ------------------------------  % Date: Wed, 27 Jun 2001 13:08:23 -0400m- From: JF Mezei <jfmezei.spamnot@videotron.ca>n) Subject: Re: Full port of VMS to Itanium.,, Message-ID: <3B3A1304.16D18E86@videotron.ca>   Alan Greig wrote:  > That they.E > didn't just take the pain right now and say VMS will continue to beMC > developed on Alpha for 3 more years (complete DII COE) then enteraG > maint. mode indicates to me that VMS must still have some significantl? > support with some of the senior management or that some otherO' > significant factor forced their hand.n    K But the strategic reasons for not killing VMS may not be due to a desire to>L keep VMS, but rather the realisation that it is better to keep VMS *for now*L for a variety of reasons. Announcing the port of VMS and TRU64 to Intel is aN great win for Intel and shows great momentum for its new chip. Killing VMS nowH would have distracted from the fact that Tandem is being ported to IA64.  N Intel will be able to claim that its chips run the worlds most important stockN exchanges (and all the other critical applications which Tandem supports). Now is not the time to abandon VMS.   M Compaq will quietly pull out of VMS over a long period of time and attract asm# little attention to it as possible.-   ------------------------------  % Date: Wed, 27 Jun 2001 18:12:58 +0100M8 From: John Macallister <J.Macallister1@physics.ox.ac.uk>) Subject: RE: Full port of VMS to Itanium.AN Message-ID: <35666012DF4CD411BE940090279FA240010BEFDC@ppnt41.physics.ox.ac.uk>  G >History suggests that no Microsoft products will be ported to VMS as ae resultD >of VMS running on the same platform as Microsoft Operating systems.  J If third party vendors lead the way Microsoft may have to follow. Let's be optimistic.c   John  B Name: John B. Macallister  E-mail: j.macallister1@physics.ox.ac.ukH Post: Nuclear and Astrophysics Laboratory, Keble Road, Oxford OX1 3RH,UKA Phone: +44-1865-273388 (direct)  273333 (reception)  273418 (Fax)k   ------------------------------  % Date: Wed, 27 Jun 2001 14:42:16 -0300-) From: fabio_compaq@ep-bc.petrobras.com.br ) Subject: RE: Full port of VMS to Itanium.aL Message-ID: <OF1264170C.4C097B90-ON03256A78.00610561@ep-bc.petrobras.com.br>  5 I dont know the reasons you are allways condening M$.0@ Without them I can imagining  everybody using IBM 3270 terminals3 over  X-25 , reading Videotext  at home (1200 bps).i   Regards    FC        I John Macallister <J.Macallister1@physics.ox.ac.uk> em 27/06/2001 14:12:58   D Favor responder a John Macallister <J.Macallister1@physics.ox.ac.uk>             Info-VAX@Mvb.Saic.Comh      ) Assunto: RE: Full port of VMS to Itanium.L    G >History suggests that no Microsoft products will be ported to VMS as a  resultD >of VMS running on the same platform as Microsoft Operating systems.  J If third party vendors lead the way Microsoft may have to follow. Let's be optimistic.o   John  B Name: John B. Macallister  E-mail: j.macallister1@physics.ox.ac.ukH Post: Nuclear and Astrophysics Laboratory, Keble Road, Oxford OX1 3RH,UKA Phone: +44-1865-273388 (direct)  273333 (reception)  273418 (Fax)v   ------------------------------  % Date: Tue, 26 Jun 2001 23:35:43 -0700'+ From: "Dennis O'Connor" <dmoc@primenet.com>t  Subject: Re: IA64 Rocks My World- Message-ID: <9hbut6$j9v$1@nnrp2.phx.gblx.net>1  = "Douglas Siebert" <dsiebert@excisethis.khamsin.net> wrote ... " > check out the $3 billion in cash* > Intel is currently burning each quarter.  @ "Cash" Intel is "burning" ? What are you talking about ? LookingC http://biz.yahoo.com/z/a/i/intc.html and associated pages, Intel is D estimated by the analyst to do around US$6.3 billion in revenue thisA quarter,  and earn around US$750 million.  Cash reserves stand at'/ US$10 billion, and the debt/equity ratio is 3%.e  D Far from "burning cash", Intel continues to accumulate it, accordingG to the analysts, even as it continues to invest both inside and outsidesA the company. So, were you just ignorant of this fact, or were you-E spouting maliciously deceptive propaganda  ? You short on the stock ?l  9 I work for Intel, and like most Intel employees own stock < and/or options. But I don't speak for Intel, and the numbers* above are from publicly available sources. --3 Dennis O'Connor                   dmoc@primenet.comM. Vanity Web Page http://www.primenet.com/~dmoc/   ------------------------------  % Date: Wed, 27 Jun 2001 13:17:49 +0200n' From: Claude Limousin <limousin@lri.fr>   Subject: Re: IA64 Rocks My World% Message-ID: <3B39C0DD.C272F58@lri.fr>>   del cecchi wrote:t > 0 > Check out Northstar/Pulsar/ISTAR/Sstar series. >  > del cecchi   Hello,  E It seams that the SStar is not an SMT processor. It uses coarse-grain- multithreading,-= that is it executes only one thread at a time, switching on am long-latency memory operation.   Regards. -- l4 Claude LIMOUSIN - Equipe Architectures Paralleles    LRI - Bat. 490 e( Universite Paris XI  F-91405 Orsay Cedex9 Tel : +33-(0)1-69-15-42-22  -  Fax : +33-(0)1-69-15-65-86o   ------------------------------  # Date: Wed, 27 Jun 2001 13:00:59 GMT + From: Hugh Bonney <hfbonney@bolt.sonic.net>a  Subject: Re: IA64 Rocks My World4 Message-ID: <fOk_6.2751$hd2.27488@typhoon.sonic.net>  : In comp.arch Peter Boyle <pboyle@holyrood.ed.ac.uk> wrote:" : On Tue, 26 Jun 2001, Bill wrote:J :> I think you're selling yourself short.  After all, Alpha killed off oneL :> company and in 4 years came close to killing off another.  I give Intel 4	 :> years.o :>F : Or at least two successive ailing companies struggling to keep theirC : margins turned to Alpha to give them some nice big fat enterprisetB : turnover... only to discover high performance and high sales are : unrelated.  E     So what was Intel's plan to recover the billion dollars plus costeA 	of the IA-64 project? Will the lowered performance expectations e" 	for IA-64 increase sales perhaps?  C 	If profits, logic, ROI, and so on were most important, Intel wouldnA 	now drop the IA-64, write off the billion dollars, pay off a feweH 	customers expenses, and develop the Alpha with enthusiasm. With Intel'sC 	processing and money, they could economically sell the fastest cpulE 	on the planet for many years to come. The best they are likely to do-D 	with the IA-64 is a middling SPARC competitor and never recover itsA 	costs. Their only competitor and possible peer would be the IBM/tC 	Motorola Power4/G5. Intel used to have a much stronger case of NIHiC 	than it seems to have now. The development of the StrongARM/XScaleo, 	demonstrates that. The Alpha is better too.   	Hugh---   ------------------------------    Date: 27 Jun 2001 08:59:35 -0700) From: google@wot-club.org.uk (Chris Rijk)u  Subject: Re: IA64 Rocks My World= Message-ID: <7bc87260.0106270759.378d08ff@posting.google.com>.  ^ "del cecchi" <dcecchi@msn.com> wrote in message news:<BZa_6.158$wt2.7991@eagle.america.net>...0 > Check out Northstar/Pulsar/ISTAR/Sstar series.  E AFAIK That chip has "vertical threading" (or coarse grained threadingrB or whatever you want to call it). If I remember correctly it holdsA two thread states on the core, and swaps between them on L1 cacheeE misses (and other events I guess) with a 3 cycle swap penalty to movee5 between threads. I think it has a 5 stage pipeline...y  @ This isn't SMT, where multiple threads can be in all/most stages> of the pipeline at the same time. (though I'm sure people will? be picky with my description). VT can be very useful but not asy good as SMT I think.   ------------------------------  % Date: Wed, 27 Jun 2001 17:00:17 +0100 , From: Peter Boyle <pboyle@holyrood.ed.ac.uk>  Subject: Re: IA64 Rocks My WorldH Message-ID: <Pine.SOL.4.33.0106271632100.24259-100000@holyrood.ed.ac.uk>  ' On Wed, 27 Jun 2001, Hugh Bonney wrote:e  < > In comp.arch Peter Boyle <pboyle@holyrood.ed.ac.uk> wrote:$ > : On Tue, 26 Jun 2001, Bill wrote:L > :> I think you're selling yourself short.  After all, Alpha killed off oneN > :> company and in 4 years came close to killing off another.  I give Intel 4 > :> years.  > :>H > : Or at least two successive ailing companies struggling to keep theirE > : margins turned to Alpha to give them some nice big fat enterprise D > : turnover... only to discover high performance and high sales are > : unrelated. > G >     So what was Intel's plan to recover the billion dollars plus costnB > 	of the IA-64 project? Will the lowered performance expectations$ > 	for IA-64 increase sales perhaps?   No, they're not related :)    E > 	If profits, logic, ROI, and so on were most important, Intel would?C > 	now drop the IA-64, write off the billion dollars, pay off a fewTJ > 	customers expenses, and develop the Alpha with enthusiasm. With Intel's  B But as I've argued buyer confidence and perception is what counts.D Axing stuff, while logical, is partly what scared people off Compaq.E (NT anyone?). If Intel axe IA-64, they would just as easily axe Alpha A in another context. Customer confidence would be lost even beforea they started selling it.  > Intel didn't have to chop a flagship to start StrongArm sales.   PeterlE > 	processing and money, they could economically sell the fastest cpucG > 	on the planet for many years to come. The best they are likely to dopF > 	with the IA-64 is a middling SPARC competitor and never recover itsC > 	costs. Their only competitor and possible peer would be the IBM/vE > 	Motorola Power4/G5. Intel used to have a much stronger case of NIHsE > 	than it seems to have now. The development of the StrongARM/XScalee. > 	demonstrates that. The Alpha is better too. > 
 > 	Hugh--- >h >P >e  $ Peter Boyle	pboyle@physics.gla.ac.uk   ------------------------------  % Date: Wed, 27 Jun 2001 02:46:57 -0400g- From: JF Mezei <jfmezei.spamnot@videotron.ca>sF Subject: Re: If you operate VMS systems, what really are your choices?, Message-ID: <3B39815D.D32BE052@videotron.ca>   Howard S Shubs wrote:yP > 4) Given the warning, get out the next time I'm ready to purchase.  Meanwhile,/ > start moving to Linux, perhaps on an IBM box.n  M How credible is IBM's Linux involvement ?  If one were to choose an IBM-LinuxwN platform, would it benefit from the great IBM support when you have a problem,6 or is IBM's Linux strategy mostly just a PR exercise ?  K In other words, once you've decided to move to Linux for enterprise/serious M applications, who is the best vendor to switch to in terms of getting qualityn	 support ?o  G And in terms of disaster recovery type of setup, is there a significantpN difference between Linux and Solaris or do both rely on Veritas software to do  the disk replication/shadowing ?   ------------------------------  % Date: Wed, 27 Jun 2001 17:41:11 +1000c/ From: "Phil Howell" <phowell@snowyhydro.com.au>eF Subject: Re: If you operate VMS systems, what really are your choices?3 Message-ID: <f6g_6.12978$qJ4.507455@ozemail.com.au>e   <edited> > 1) Stick with Alphas.t( until the maintenance becomes uneconomic but probably won't buy any moree > 2) Make the leap to Itanium. not yet - has anyone seen one?, > 3) Given the advance warning, get out now. to either sun ultrasparc?e
 or ibm g4? (and get a brain transplant) > Which number are you and why?oA 4) those rack mounted proliants with xeon processors look nice :)  Phil   ------------------------------   Date: 27 Jun 2001 07:54:18 GMT3 From: gartmann@immunbio.mpg.de (Christoph Gartmann)bF Subject: Re: If you operate VMS systems, what really are your choices?0 Message-ID: <9hc3fa$kno$1@n.ruf.uni-freiburg.de>  t In article <260620012046403311%spencer@spaamfree.recneps.com>, David Spencer <spencer@spaamfree.recneps.com> writes:D >Okay, suppose you've got a lot of Alpha gear that's running VMS (orE >Tru64 for that matter).  Right about now you've got to be looking atn> >your choices down the road. As everybody knows, in the future? >you're going to need more computing capacity. Given the recent F >shocking news about Alpha going to Intel (and basically disappearing) >- what are your choices?  >i >1) Stick with Alphas. >0F >You could snap up systems as they're released up to the point that noB >new revisions are available. Then you go into the used market andE >add additional systems and keep clustering. This might work out okaynC >as long as you can keep getting parts and somebody to maintain theiH >systems. You might actually do pretty well on the used gear as a numberG >of folks would be swapping out old Alphas for Itaniums or other vendor  >gear... >  >2) Make the leap to Itanium.  >mG >You trust that Compaq and Intel know what they're doing. Hang in thereaG >with what you've got until the new iVMS systems are available. By 20030F >those Itanium systems will be as fast and as reliable as your currentE >(or the currently available) Alphas on the market. Then you make the(7 >conversion to the new hardware and keep on trucking...y >t+ >3) Given the advance warning, get out now.i >yI >You've decided against #1 because you're not sure you want to get lockedVE >into the same systems forever. Number 2 isn't for you either becauselH >you're not impressed by Intel's track record on this chip, and besides,A >if you're going to be doing a conversion why not interview othern	 >vendors?  >t >s >Which number are you and why?  J Quite simple: a combination of 1 and 2. I don't buy processors, I buy OSesM and software. So as long as I don't need more computing power I go for option K 1. When I need more power, I buy what's available and fits my requirements.nJ If the VMS hardware sold at this point is Alpha-based, I buy Alphas. If itH is Itanium-based I buy Itanium. Important to me is that I am able to mix# systems like with VAXen and Alphas.t  K Option 3 results in a big hassle. Why do it just because of assumptions? AsrO long as I am happy with what I have I don't see a need to leave the successfullSI route. What happens if VMS is ported to Itanium? It is fine. If it cannotuK be done, it will be known very soon. So either the Itanium will be modifieduH (there are still three years to achieve this!) or the Alpha chip will be produced further.g  N Again, the future of VMS doesn't depend on the type of hardware it runs on. It7 is a matter of software availability and functionality.i   Regards,
    Christoph e  H -- --------------------------------------------------------------------+H | Max-Planck-Institut fuer      Phone   : +49-761-5108-464   Fax: -452 |H | Immunbiologie                                                        |H | Postfach 1169                 Internet: gartmann@immunbio.mpg.de     |H | D-79011  Freiburg, FRG                                               |H +--------- http://www.immunbio.mpg.de/home/english/menue.html ---------+   ------------------------------   Date: 26 Jun 01 23:31:59 MDT" From: ivie@cc.usu.edu (Roger Ivie)F Subject: Re: If you operate VMS systems, what really are your choices?% Message-ID: <mjY4a$3ZI0X1@cc.usu.edu>   Z In article <4loijt8euraban7231o89f6v8iism2esju@4ax.com>, LBohan@dbc.spam_less..com writes:3 > On Tue, 26 Jun 2001 20:46:40 -0700, David Spencere >>- what are your choices? >> >>1) Stick with Alphas.s >>2) Make the leap to Itanium., >>3) Given the advance warning, get out now. > " > probably #1 and then, later  #2.	 > why...?4 >  >  1. VMS is VMS >    r( >  2. the transition from Vax to Alpha,   >     for us, if not quick, was  >     almost painless.  F Besides, what would you transition to that _isn't_ facing a transitionB itself? Windows? Moving to IA64. Unix? Everybody over there is in ? transition, as well. MacOS? Welcome to Unix. 390? There's a new + 64-bit architecture there, as well. AS/400?i  K It looks like option 3 is pretty much the same as option 2, except that younH get to do two transitions at once: to a new OS and to a new architecture with the new OS. --  N -------------------------+----------------------------------------------------3 Roger Ivie               | Ben Stein for president!  ivie@cc.usu.edu          | http://cc.usu.edu/~ivie/ | -----BEGIN GEEK CODE BLOCK-----. Version: 3.18 GP dpu s:+++ a C++ UB- P--- L- E--- W- N++ o-- K-- w--- > O M+ V+++ PS+++ PE++ Y+ PGP+ t++ 5++ X-- R tv++ b+++ DI+++ D-  G-- e++ h--- r+++ y+++ s ------END GEEK CODE BLOCK------    ------------------------------  % Date: Wed, 27 Jun 2001 08:09:01 -0400-' From: Howard S Shubs <howard@shubs.net>,F Subject: Re: If you operate VMS systems, what really are your choices?< Message-ID: <howard-70E72B.08090127062001@enews.newsguy.com>  , In article <3B39815D.D32BE052@videotron.ca>,/  JF Mezei <jfmezei.spamnot@videotron.ca> wrote:   O > How credible is IBM's Linux involvement ?  If one were to choose an IBM-LinuxcH > platform, would it benefit from the great IBM support when you have a 
 > problem,8 > or is IBM's Linux strategy mostly just a PR exercise ?   Why do you think it might be?f    M > In other words, once you've decided to move to Linux for enterprise/serious O > applications, who is the best vendor to switch to in terms of getting qualitye > support ?V  N Given history, IBM is pretty damn good.  What I'm trying to avoid is reliance  on Intel, after all.    I > And in terms of disaster recovery type of setup, is there a significantdN > difference between Linux and Solaris or do both rely on Veritas software to  > do" > the disk replication/shadowing ?  I The -proper- way to do RAID is in hardware, so I don't bother looking at h< software solutions.  Controller-based everything is The Way. -- w Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"   ------------------------------  % Date: Wed, 27 Jun 2001 09:23:28 -0400u- From: JF Mezei <jfmezei.spamnot@videotron.ca><F Subject: Re: If you operate VMS systems, what really are your choices?, Message-ID: <3B39DE4F.6CB92803@videotron.ca>   Christoph Gartmann wrote:oL > Quite simple: a combination of 1 and 2. I don't buy processors, I buy OSes > and software.o    M Most people buy software and then an OS (the later usually implies a hardwarey platform as well).  N The problem with what is happening with VMS is that the uncertainty of the VMSN platform for the next few years will result in fewer people making investmentsM in VMS, and that will result in fewer applications being ported to VMS, which2B will result in fewer people making investments in VMS etc etc etc.  N So while Compaq will officially continue to make VMS available and support it,N it probably won't do much more than is required to make VMS a viable platform, (eg: attract applications).t  N Does anyone here beleive for a minute that part of the $500 million investmentL to buy software/support firms might include some firms that are dedicated toN VMS (such as buying PMDF, Process Software, perhaps buying Rdb back etc etc ?)N ?  That would be very good news if Compaq did that because it would be putting= its own money where its mouth is. (actually Intel's money...)o   ------------------------------   Date: 27 Jun 2001 14:16:06 GMT# From: dQdelQlutrQX@XQXentQeract.comsF Subject: Re: If you operate VMS systems, what really are your choices?+ Message-ID: <9hcpr6$ce5$1@bob.news.rcn.net>.  X On Tue, 26 Jun 2001 20:46:40 -0700, David Spencer <spencer@spaamfree.recneps.com> wrote: > ...n > - what are your choices? > 1) Stick with Alphas.@ > .... > 2) Make the leap to Itanium. > ...s, > 3) Given the advance warning, get out now.   For me, it's 1 until:eC   a. The port of VMS to Itanium is good enough to really be able to-$      get our jobs done properly, andF   b. The price/performance of a new Itanium/VMS system is better than =      the many used Alpha/VMS systems that will inevitably be        available.t
 Then, it's 2.i  > We made the leap from VAX to Alpha pretty easily and got a big! improvement in price/performance.   E I don't see any reason to go to 3 unless the port gets screwed up so i< badly that we can't trust Itanium/VMS to ever run our stuff.  C I really don't understand some of the fervor in the arguments I've eC read.  Do you really care about the underlying chip running in the a( machine as long as it runs VMS properly?   -- i? Dale Dellutri -- dQdelQlutrQX@XQXentQeract.com (no Q's, no X's)i   ------------------------------  % Date: Wed, 27 Jun 2001 11:24:36 -0300n) From: fabio_compaq@ep-bc.petrobras.com.briF Subject: Re: If you operate VMS systems, what really are your choices?L Message-ID: <OF7A2D59F9.D825A045-ON03256A78.004F1BC2@ep-bc.petrobras.com.br>  4 I would like SAP for OpenVMS or iVMS,  under Itanium  	 Only thist   Fabios        J dQdelQlutrQX@XQXentQeract.com@shell-3.enteract.com> em 27/06/2001 11:16:06  / Favor responder a dQdelQlutrQX@XQXentQeract.come  A Enviado Por:   "Dale A. Dellutri" <ddellutr@shell-3.enteract.com>                Info-VAX@Mvb.Saic.Comm      F Assunto: Re: If you operate VMS systems, what really are your choices?    1 On Tue, 26 Jun 2001 20:46:40 -0700, David Spencer & <spencer@spaamfree.recneps.com> wrote: > ...  > - what are your choices? > 1) Stick with Alphas.t > ...  > 2) Make the leap to Itanium. > ...t, > 3) Given the advance warning, get out now.   For me, it's 1 until: C   a. The port of VMS to Itanium is good enough to really be able to $      get our jobs done properly, andE   b. The price/performance of a new Itanium/VMS system is better than0<      the many used Alpha/VMS systems that will inevitably be      available.-
 Then, it's 2.2  > We made the leap from VAX to Alpha pretty easily and got a big! improvement in price/performance.r  D I don't see any reason to go to 3 unless the port gets screwed up so< badly that we can't trust Itanium/VMS to ever run our stuff.  B I really don't understand some of the fervor in the arguments I'veB read.  Do you really care about the underlying chip running in the( machine as long as it runs VMS properly?   --? Dale Dellutri -- dQdelQlutrQX@XQXentQeract.com (no Q's, no X's)    ------------------------------    Date: 27 Jun 2001 10:35:47 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) F Subject: Re: If you operate VMS systems, what really are your choices?3 Message-ID: <dHgBPz3nGUYK@eisner.encompasserve.org>j  e In article <f6g_6.12978$qJ4.507455@ozemail.com.au>, "Phil Howell" <phowell@snowyhydro.com.au> writes:c
 > <edited> >> 1) Stick with Alphas.   >> 2) Make the leap to Itanium.w  - >> 3) Given the advance warning, get out now.s  C > 4) those rack mounted proliants with xeon processors look nice :)p  D 5) Use Itanium along with Alpha and Vax because a software developer1    needs to support anything customers might use.e   ------------------------------    Date: 27 Jun 2001 10:35:53 -0500- From: koehler@encompasserve.org (Bob Koehler)nF Subject: Re: If you operate VMS systems, what really are your choices?3 Message-ID: <PRZSi01r23mn@eisner.encompasserve.org>a  t In article <260620012046403311%spencer@spaamfree.recneps.com>, David Spencer <spencer@spaamfree.recneps.com> writes:E > Okay, suppose you've got a lot of Alpha gear that's running VMS (orwF > Tru64 for that matter).  Right about now you've got to be looking at? > your choices down the road. As everybody knows, in the futurec@ > you're going to need more computing capacity. Given the recentG > shocking news about Alpha going to Intel (and basically disappearing)  > - what are your choices? >  > 1) Stick with Alphas.e   > 2) Make the leap to Itanium.  , > 3) Given the advance warning, get out now.   > Which number are you and why?s  = 4) Get a VAX.  For some folks they're still the right answer.   F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporationb= NASA GSFC Flight Software       | Federal Sector, Civil Group E                                 | please remove ".aspm" when replyingf   ------------------------------  % Date: Wed, 27 Jun 2001 07:40:13 -0700a  From: Jon <jsmyth69@hotmail.com>F Subject: Re: If you operate VMS systems, what really are your choices?2 Message-ID: <nO85O49M5R9jpHMJw+Rj+t16wvUC@4ax.com>  4 David Spencer <spencer@spaamfree.recneps.com> wrote:  D >Okay, suppose you've got a lot of Alpha gear that's running VMS (orE >Tru64 for that matter).  Right about now you've got to be looking at > >your choices down the road. As everybody knows, in the future? >you're going to need more computing capacity. Given the recentIF >shocking news about Alpha going to Intel (and basically disappearing) >- what are your choices?r >  >1) Stick with Alphas. >oF >You could snap up systems as they're released up to the point that noB >new revisions are available. Then you go into the used market andE >add additional systems and keep clustering. This might work out okay C >as long as you can keep getting parts and somebody to maintain theIH >systems. You might actually do pretty well on the used gear as a numberG >of folks would be swapping out old Alphas for Itaniums or other vendor  >gear... >i >2) Make the leap to Itanium.  > G >You trust that Compaq and Intel know what they're doing. Hang in therehG >with what you've got until the new iVMS systems are available. By 2003uF >those Itanium systems will be as fast and as reliable as your currentE >(or the currently available) Alphas on the market. Then you make theh7 >conversion to the new hardware and keep on trucking...  >n+ >3) Given the advance warning, get out now.i >tI >You've decided against #1 because you're not sure you want to get locked E >into the same systems forever. Number 2 isn't for you either becausenH >you're not impressed by Intel's track record on this chip, and besides,A >if you're going to be doing a conversion why not interview other 	 >vendors?c >e >o >Which number are you and why?  C  #3 is what my company is taking.  Once word of the change got out,oF our salespeople started squaking about not being able to make a profitD off of any intel sales.  The execs have made an announcement that weD are now looking at selling ONLY ibm systems.  I've convinced them toD adopt a wait and see view, but it doesn't look good here.  We have aC LOT of clients on VMS, I'd hate to see them all get told to migrate  over to AIX.   ------------------------------  # Date: Wed, 27 Jun 2001 15:24:33 GMT 2 From: seibel_r@localhost.localdomain (Rich Seibel)F Subject: Re: If you operate VMS systems, what really are your choices?; Message-ID: <slrn9jjukt.esr.seibel_r@localhost.localdomain>   L On Wed, 27 Jun 2001 02:46:57 -0400, JF Mezei <jfmezei.spamnot@videotron.ca>  wrote: >Howard S Shubs wrote:G >> 4) Given the warning, get out the next time I'm ready to purchase.  ?
 >> Meanwhile,r0 >> start moving to Linux, perhaps on an IBM box. >sN >How credible is IBM's Linux involvement ?  If one were to choose an IBM-LinuxO >platform, would it benefit from the great IBM support when you have a problem,r7 >or is IBM's Linux strategy mostly just a PR exercise ?  >bK Our local Linux User's Group just had a presentation from an IBMer.  IBM is-H spending $1.3 billion US over the next couple of years.  Project includeI porting major IBM products to Linux, for example, MQSeries; contributing  G mature technologies to the Linux base, for example, JFS; and building a5K world class customer support organization for Linux.  IBM is not going intocF the distribution building business, they will support 4 existing majorG distributions.  They plan on have all 4 available on all their hardwarerG platforms.  One or more is already available on their PCs, RS6000s, andaG mainframes.  Information is available on thier web site, but not all inrC one place, thus you could spend considerable time searching it out.-  L >In other words, once you've decided to move to Linux for enterprise/seriousN >applications, who is the best vendor to switch to in terms of getting quality
 >support ? >eJ There are several vendors that will sell you OS support.  From above, IBM L is intent on leading this pack.  Probably not a bad choice since IBM alreadyK has demonstrated compentence in supporting the enterprise and will probablySI be more help than most in supporting applications, as well as, operating nH systems, however, probably not OpenVMS.  The Q seems to want to get intoI this arena, but their strong ties to MicroSoft will make it difficult foro them to be OS agnostic.a  G Disclaimer:  I do not directly or indirectly work for IBM, though I am AI guilty of using their products.  I used to have the same contempt for IBMtJ that many of you now reserve for M$ (and I share that contempt).  But, IBMK has changed.  I believe due to the DOJ antitrust case in the early 80s, theoK messy divorce from M$, and, mainly due to having ethical business people in $ the upper echelons of their company.  H >And in terms of disaster recovery type of setup, is there a significantO >difference between Linux and Solaris or do both rely on Veritas software to dot! >the disk replication/shadowing ?'I Look at the Linux 2.4 kernel.  I think you will find, either already, or a? soon everything you want.  I believe Solaris already does this.d   -- iD --------------------------------------------------------------------D Rich Seibel, Software Engineer                 (314)579-0066 ext 220D Object Computing, Inc.                           seibel_r@ociweb.comD Need ACE training?                      See http://www.theaceorb.comD --------------------------------------------------------------------   ------------------------------  % Date: Wed, 27 Jun 2001 10:33:20 -0500,1 From: "David J. Dachtera" <djesys.nospam@fsi.net> F Subject: Re: If you operate VMS systems, what really are your choices?& Message-ID: <3B39FCBF.9DFCBE1@fsi.net>  * fabio_compaq@ep-bc.petrobras.com.br wrote: > 6 > I would like SAP for OpenVMS or iVMS,  under Itanium  H "I would like" a million bucks. No one's going to give it to me, I gotta go out and get it.   -- w David J. Dachterai dba DJE Systems, http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/   F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.,   ------------------------------  % Date: Wed, 27 Jun 2001 15:30:26 +0100e  From: steven.reece@quintiles.comF Subject: Re: If you operate VMS systems, what really are your choices?H Message-ID: <OF523A8F05.5355F7F9-ON80256A78.004F6859@qedi.quintiles.com>  A You have this in common with many I suspect, Alan Greig included.o  J Thinking of my two former employers, both of them moved important servicesK to SAP and both moved off VMS.  One went to Intel (but still on Compaq) and J the other I believe went to Sun with a centralised approach, tossing theirH distributed VMS approach along the way.  They were past the 11th hour atH rolling out a new VMS environment and had the AlphaServer 4100s ready to2 roll out to two of their sites, before canning it.  5 Non are so blind as those who do not want to see.....a   Steve.   Fabio wrote: >>>m4 I would like SAP for OpenVMS or iVMS,  under Itanium  	 Only thist <<<w   ------------------------------  # Date: Wed, 27 Jun 2001 12:46:15 GMTn. From: "Duane Sand" <duane.sand@mindspring.com>$ Subject: Re: Intel/Alpha announcment@ Message-ID: <rAk_6.134521$%i7.90354977@news1.rdc1.sfba.home.com>   "John Macallister" wroteG > ... The VAX->Alpha transition was relatively painless for most (99%?)n > well-written user code. I > The reason that some packages were not converted completely from VAX to J > Alpha was not the difficulty of conversion but rather that the companiesA > concerned did not believe it to be commercially worthwhile. ...   D NSK customers went through a similar CISC-->RISC migration about theE same time as the VMS migration.  But on NSK, the transition was 100%,iK totally painless, and you never needed to get any cooperation or permissionoI from the application vendor or Tandem.  Everything just ran.  Nothing was  leftI behind, except for some very ancient comm devices.  How come it wasn't asw nice and complete for VMS users?-  # NSK provided three migration paths:-  @ 1. run old binaries via an interpreter; no preprocessing needed.D 2. run old binaries faster via a Vest-like translator; automatic, no prog-specific hints needed;:   can be easily done by any user.J 3. change source to be more portable, and recompile with native compilers.  > All existing operating system interfaces were carried forward.  B Does VMS on Alpha lack #1?  Is #2 nontrivial to use or extra cost?  H We're designing the similar migration aids for NSK on IA64.  I'd like to learn from the VMS experience.  +     -- Duane Sand,  Compaq NonStop Division7   ------------------------------    Date: 27 Jun 2001 11:31:38 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)o$ Subject: Re: Intel/Alpha announcment3 Message-ID: <0WRC4r1y+Qtz@eisner.encompasserve.org>   q In article <rAk_6.134521$%i7.90354977@news1.rdc1.sfba.home.com>, "Duane Sand" <duane.sand@mindspring.com> writes:l >  > "John Macallister" wroteH >> ... The VAX->Alpha transition was relatively painless for most (99%?) >> well-written user code.J >> The reason that some packages were not converted completely from VAX toK >> Alpha was not the difficulty of conversion but rather that the companies'B >> concerned did not believe it to be commercially worthwhile. ... > F > NSK customers went through a similar CISC-->RISC migration about theG > same time as the VMS migration.  But on NSK, the transition was 100%,oM > totally painless, and you never needed to get any cooperation or permissionaK > from the application vendor or Tandem.  Everything just ran.  Nothing wasr  D In VMS circles at the time, many software products were priced basedE on the power of the underlying machine.  DEC ensured that third party-D (and their own) products would not be fooled when they made a systemC call to determine the nature of the machine.  DEC went out of theireC way to force their own business model (Alpha licenses are different A from VAX licenses) into the License Management Facility.  That isd* aside from more technical reasons (below).   > leftK > behind, except for some very ancient comm devices.  How come it wasn't ash > nice > and complete for VMS users?b > % > NSK provided three migration paths:  > B > 1. run old binaries via an interpreter; no preprocessing needed.  D This never hit the streets on VMS, although it could have. A closely; related capability -- running an interpreter/emulator afterw@ a cursory preprocessing step to affirm intentions _was_ released> as part of VEST, but was not documented in that fashion due to; performance considerations.  I believe the intention was to = avoid having people running on Alpha say "the performance was 2 not so great".  That capability works to this day.  F > 2. run old binaries faster via a Vest-like translator; automatic, no > prog-specific hints needed;s" >  can be easily done by any user.  A The VEST translator only handled images created on VAX/VMS 4.0 ormC later (6.0 was being released at the time Alpha and VEST came out).tD This was a conscious decision made after polling customers regarding? how many of them had images that old to which they had lost the.> sources (missing source code was a major justification for the VEST project).    ? Guardian programmers perhaps always retain source, but many VAX4= customers were scientists and other n'ere do well's who value:< their actual job function higher than doing the backups :-).  < Ada programs on VAX could not be VESTed to Alpha, because in< building the Ada compiler for Alpha, DEC switched from their< old VAX-specific tasking engine in the run-time library to a= Posix-compliant engine called DECthreads, also used for otherm< languages.  They did not see any benefit in building special? Alpha tasking support just for VESTed programs, perhaps becausee= they felt most Ada customers had taken care not to lose their  source.d  < Program specific hints are generally not _required_ by VEST,= they just improve performance.  The only case I have heard of = that violates this generality is the TECO text editor that isl> part of VMS itself.  TECO was written in VAX Assembly language= (Macro-32) and the weird coding tricks it used confounded thet< Macro-32 Compiler for Alpha.  Some parts of it also were not? even handled properly by VEST (in particular, deciding what was-? code and what was data), so hints had to be provided to achieve0 correctness.  L > 3. change source to be more portable, and recompile with native compilers.  D In most cases on VMS, the "change the source" step was not required.A The one exception was the C programming language, because DEC wasVC also in the process of switching to ANSI C at the time, and it tooknB them a long time to get all the backward compatibility features of@ the new compiler in place.  The old compiler was never ported toB Alpha, and DEC underestimated how sloppy coding from C programmers can be..  @ > All existing operating system interfaces were carried forward.  8 That is true on VMS also, for any documented interfaces.7 Undocumented interfaces are even subject to change from ' version to version on a given platform.w  D > Does VMS on Alpha lack #1?  Is #2 nontrivial to use or extra cost?  A I believe #1 was not promoted because it would undercut the basice performance message.  D Some of the same appearance-of-performance reasons also apply to #2,? but also there was a question of the rights of third parties toeA prevent their code from being translated to another architecture.lA Another issue was whether third parties would support VESTings of B their code when the user had a problem, if the third party had not been the one to do the VESTing.   J > We're designing the similar migration aids for NSK on IA64.  I'd like to  > learn from the VMS experience. > - >     -- Duane Sand,  Compaq NonStop Divisionu  2 As we want to learn from your experience.  Thanks.   ------------------------------  # Date: Wed, 27 Jun 2001 16:47:21 GMT . From: "Duane Sand" <duane.sand@mindspring.com>$ Subject: Re: Intel/Alpha announcment@ Message-ID: <t6o_6.134649$%i7.90552925@news1.rdc1.sfba.home.com>   "Larry Kilgallen" wroterF > Some of the same appearance-of-performance reasons also apply to #2,<         [using VEST to port VAX VMS binaries onto Alpha, and>          why wasn't this universally applied to all VAX stuff]A > but also there was a question of the rights of third parties to C > prevent their code from being translated to another architecture. C > Another issue was whether third parties would support VESTings oftD > their code when the user had a problem, if the third party had not! > been the one to do the VESTing.p  @ On NSK, we followed HP's example and shipped a binary translator= without asking our lawyers whether some software vendor might C object about copyright violation, about making derivative works, or H applying de-compilation techniques despite software license boilerplate.F No vendor ever objected.  After all, it greatly increased their sales, gettingsE them onto a surviving higher performance platform in exactly the sameuC market space and customer base, with no software development effort F (and usually no new software support issues).   I think system vendorsE have some lattitude about automatic morphing tools.  No one complainsgG to Intel that Athlon or Pentium 4 hardware translates Pentium code into E cached risc micro ops on the fly.  No application vendor complains tohD Transmeta that Crusoe software translates Pentium code into vliw ops in main memory on the fly.   ------------------------------  % Date: Wed, 27 Jun 2001 12:49:53 -0400F2 From: rdeininger@mindspring.com (Robert Deininger)$ Subject: Re: Intel/Alpha announcmentL Message-ID: <rdeininger-2706011249540001@user-2ive7go.dialup.mindspring.com>  G In article <rAk_6.134521$%i7.90354977@news1.rdc1.sfba.home.com>, "Duane ( Sand" <duane.sand@mindspring.com> wrote:   > "John Macallister" wroteI > > ... The VAX->Alpha transition was relatively painless for most (99%?)  > > well-written user code.oK > > The reason that some packages were not converted completely from VAX toiL > > Alpha was not the difficulty of conversion but rather that the companiesC > > concerned did not believe it to be commercially worthwhile. ...  > F > NSK customers went through a similar CISC-->RISC migration about theG > same time as the VMS migration.  But on NSK, the transition was 100%,dM > totally painless, and you never needed to get any cooperation or permissioneK > from the application vendor or Tandem.  Everything just ran.  Nothing wasn > leftK > behind, except for some very ancient comm devices.  How come it wasn't ass > nice > and complete for VMS users?t  E NSK was at Tandem, which was apparently better managed than Digital. aI Digital often made decisions designed to push customers where they didn't   want to go.  Did Tandem do that?  % > NSK provided three migration paths:e > B > 1. run old binaries via an interpreter; no preprocessing needed.F > 2. run old binaries faster via a Vest-like translator; automatic, no > prog-specific hints needed;o" >  can be easily done by any user.L > 3. change source to be more portable, and recompile with native compilers. > @ > All existing operating system interfaces were carried forward. > D > Does VMS on Alpha lack #1?  Is #2 nontrivial to use or extra cost?  M VMS on alpha doesn't have #1.  I don't know if that's technical or political.   J #2 was provided, but it hasn't been kept up to date.  VAX binaries createdH under recent versions of VMS won't VEST, as I understand it.  But if youF created them recently, you should have the source code, and you shouldI compile for alpha directly.  This was probably a reasonable choice, given,+ that every piece of maintenace costs money.h  $ #3 is clearly the prefered solution. > J > We're designing the similar migration aids for NSK on IA64.  I'd like to  > learn from the VMS experience. > - >     -- Duane Sand,  Compaq NonStop Divisionm  A Good Grief!  Please get on the blower and start talking with youreI counterparts in VMS and Unix engineering.  You're allowed to do that now,t aren't you?   M Duane, meet Hoff.  Hoff, meet Duane.  I hope to meet you both someday myself.   F I'm always a little shocked when I see folks with compaq.com addressesB come here for technical information.  I guess it's a symptom of anF incomplete digestion of the acquired companies.  I realize you're also@ looking for an outside perspective, but that's no substitute forC Compaq-internal collaboration and training.  There ought to be many2I opportunities to share the workload in the IA64 port.  I wish you all theh
 best of luck.4   --   Robert Deininger rdeininger@mindspring.comt   ------------------------------    Date: 27 Jun 2001 13:12:17 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) $ Subject: Re: Intel/Alpha announcment3 Message-ID: <IyuBzePMDQRl@eisner.encompasserve.org>w  q In article <t6o_6.134649$%i7.90552925@news1.rdc1.sfba.home.com>, "Duane Sand" <duane.sand@mindspring.com> writes:j >  > "Larry Kilgallen" wroteIG >> Some of the same appearance-of-performance reasons also apply to #2,P> >         [using VEST to port VAX VMS binaries onto Alpha, and@ >          why wasn't this universally applied to all VAX stuff]B >> but also there was a question of the rights of third parties toD >> prevent their code from being translated to another architecture.D >> Another issue was whether third parties would support VESTings ofE >> their code when the user had a problem, if the third party had notm" >> been the one to do the VESTing. > B > On NSK, we followed HP's example and shipped a binary translator? > without asking our lawyers whether some software vendor mighttE > object about copyright violation, about making derivative works, ortJ > applying de-compilation techniques despite software license boilerplate.H > No vendor ever objected.  After all, it greatly increased their sales,	 > gettinglG > them onto a surviving higher performance platform in exactly the same E > market space and customer base, with no software development effortnH > (and usually no new software support issues).   I think system vendorsG > have some lattitude about automatic morphing tools.  No one complainsrI > to Intel that Athlon or Pentium 4 hardware translates Pentium code into G > cached risc micro ops on the fly.  No application vendor complains totF > Transmeta that Crusoe software translates Pentium code into vliw ops > in main memory on the fly.  A But in the VMS world, there is the issue of lying to the softwareyA on the new machine about the machine capacity.  I presume the NSKhA typical pricing model for third party software must be different.h   ------------------------------    Date: 27 Jun 2001 13:19:51 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) $ Subject: Re: Intel/Alpha announcment3 Message-ID: <yQ6RauCDIIiR@eisner.encompasserve.org>    In article <rdeininger-2706011249540001@user-2ive7go.dialup.mindspring.com>, rdeininger@mindspring.com (Robert Deininger) writes:u  C > Good Grief!  Please get on the blower and start talking with yourSK > counterparts in VMS and Unix engineering.  You're allowed to do that now,-
 > aren't you?- > O > Duane, meet Hoff.  Hoff, meet Duane.  I hope to meet you both someday myself.e > H > I'm always a little shocked when I see folks with compaq.com addressesD > come here for technical information.  I guess it's a symptom of anH > incomplete digestion of the acquired companies.  I realize you're alsoB > looking for an outside perspective, but that's no substitute forE > Compaq-internal collaboration and training.  There ought to be many K > opportunities to share the workload in the IA64 port.  I wish you all the. > best of luck.p  C For my part, I think it is crucial that he get outside perspective. B Hoff does.  Duane might even be a total expert on what was done to? build Alpha VMS and VEST, but be wondering how much was clearly. communicated to the customers.  E Anyhow, it is good to have someone here to settle occasional disputesg" about how Tandem machines work :-)   ------------------------------  # Date: Wed, 27 Jun 2001 17:26:15 GMTo. From: "Duane Sand" <duane.sand@mindspring.com>$ Subject: Re: Intel/Alpha announcment@ Message-ID: <XGo_6.134665$%i7.90588883@news1.rdc1.sfba.home.com>   "Robert Deininger" wroteK > Digital often made decisions designed to push customers where they didn't0" > want to go.  Did Tandem do that?  , We wish we could nudge them along sometimes.I Himalaya customers love to plug in additional processors whenever there's7G another peak-volume day at the stock market.  But they are always leerypE about being the first one to put a new model into production service. E They are always leery about installing a "new" software release, eveneJ after it's collected dust for two years.  Most of the application software baseF is still running via binary translation from 16-bit stack machine codeD rather than rebuilding via Mips native-mode compilers.  An extremelyI conservative lot; if it's not broken, they don't touch it.  The answer too mostC any operational shortcoming is typically: just add more processors.   C We learned that upward compatibility and smooth migration paths ared very important.y  ? It also helped that we've always had a single main product line D in hardware and software.  That was a side effect of this particular< mixed hardware/software approach to maximum fault tolerance.   ------------------------------  , Date: Wed, 27 Jun 2001 12:29:19 +0200 (CEST): From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl> Subject: Re: Itanium HW REF MAN J Message-ID: <Pine.LNX.4.21.0106271221020.15007-100000@irys.stanpol.com.pl>  & On 26 Jun 2001, Malcolm Dunnett wrote: [...] B >+   OTOH, if Intel were to decide today to scrap IA64 and go with@ >+Alpha they'd be right on track. Of course Alphas won't run x86C >+code today, but Intel could keep selling Pentiums for a few years,? >+and could put their ertswhile Itanium engineers onto the taskdB >+of designing an x86 compatibility mode into a future Alpha chip.  7  You say, the experience of COMPAQ with IA-32 in Alpha d# emulation is here something worth ?e:  Pentium(&++) mostly emulates "real X86" instructions, the: differrence if that is done in external (to chip) emulator1 or internal micro- or PAL-code must not be big :)e4  At least the BIOS emulation in AlphaStation accepts/ most of video cards (in text mode, of course) ! ;  *If* the "compatibility mode" will be get as a "additional 7 feature" build in something-like-PAL - then no problem.s9  And Intel says (some years ago) that starting with IA-64o? (Merced) *will* allow x86 compatibility, but here will be *NOT* ( a way to asking for high X86 efficiency.=  As long as the '86 will not start to be the "first priority". - IMHO no problem.   >+ :-)    Regards - Gotfryd   -- -E =====================================================================lF $ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") - 		THEN EXCUSE/OBJECT=ME . $!                        GS@stanpol.zabrze.plE =====================================================================d   ------------------------------  % Date: Wed, 27 Jun 2001 07:12:06 -0400.) From: "Neil Rieck" <n.rieck@sympatico.ca>  Subject: Re: Itanium HW REF MAN-; Message-ID: <28j_6.28208$yy2.2800962@news20.bellglobal.com>   > "Malcolm Dunnett" <nothome@spammers.are.scum> wrote in message& news:CV41Z4DsFgPd@malvm5.mala.bc.ca...+ > In article <3B37FA2F.EA3D316D@wi.rr.com>,o [snip] >wB >    OTOH, if Intel were to decide today to scrap IA64 and go with@ > Alpha they'd be right on track. Of course Alphas won't run x86C > code today, but Intel could keep selling Pentiums for a few yearsd? > and could put their ertswhile Itanium engineers onto the taskvB > of designing an x86 compatibility mode into a future Alpha chip. >aC IA-64 technology doesn't run x86 code either. I'm still looking for L information I stumbled onto a couple of years back, but the block diagram ofL the Merced chip showed three EPIC cores and a Pentium core on one substrate.I The EPIC logic will run the new stuff while the Pentium core runs the olde stuff.  K The potential marketing scam here is that non-techies (and most management)tL will be presented SPEC marks written for the EPIC sub-system but most people( will be running old code on the Pentium.  J AFAIC, x86 emulation for Alpha might be the better way to go (smaller die,- lower power, lower cooling requirements, etc)d  
 Neil Rieck Kitchener/Waterloo/Cambridge,g Ontario, Canada.! http://www3.sympatico.ca/n.rieck/g   ------------------------------  % Date: Wed, 27 Jun 2001 15:02:06 +0100u% From: Alan Greig <a.greig@virgin.net>t Subject: Re: Itanium HW REF MANe8 Message-ID: <jjpjjtcoqv2uan8f2juo3osn6m5noepbfq@4ax.com>  @ On Tue, 26 Jun 2001 02:55:31 GMT, Scott Vieth <svieth@wi.rr.com> wrote:  F >The chips that will be running VMS aren't even designed yet.  Are you >looking for a" >reference manual from the future?  F The chips which might provide additional VMS support are several years@ away but it is a mistake to assume that iVMS will not run on the= current chips or McKinley at worst,  VMS engineering has saideB previously that they could port VMS to the initial IA64 chip givenA sufficient resources, It would be madness to start a port now for 4 which the hardware is a minimum of three years away.   >-scott  >r >Tom Linden wrote: >e! >> Anybody know ehere to get one?    -- Alan   ------------------------------    Date: 27 Jun 2001 10:58:31 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)  Subject: Re: Itanium HW REF MAN 3 Message-ID: <7NRSvBe6vXOY@eisner.encompasserve.org>   g In article <28j_6.28208$yy2.2800962@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes:   M > The potential marketing scam here is that non-techies (and most management)iN > will be presented SPEC marks written for the EPIC sub-system but most people* > will be running old code on the Pentium.  > And they deserve poor performance if they believe manufacturer' benchmarks rather than their own tests.i  L > AFAIC, x86 emulation for Alpha might be the better way to go (smaller die,/ > lower power, lower cooling requirements, etc)e  < I do not believe Compaq ever had the legal right to do that.< I believe the right of AMD in this regard is only via a very convoluted path.   ------------------------------  % Date: Wed, 27 Jun 2001 08:19:24 -0700e! From: Tom Linden <tom@kednos.com>  Subject: RE: Itanium HW REF MANy9 Message-ID: <CIEJLCMNHNNDLLOOGNJIKENACNAA.tom@kednos.com>    > -----Original Message-----B > From: Larry Kilgallen [mailto:Kilgallen@eisner.decus.org.nospam]( > Sent: Wednesday, June 27, 2001 8:59 AM > To: Info-VAX@Mvb.Saic.Comc! > Subject: Re: Itanium HW REF MANi >  > D > In article <28j_6.28208$yy2.2800962@news20.bellglobal.com>, "Neil ' > Rieck" <n.rieck@sympatico.ca> writes:  > D > > The potential marketing scam here is that non-techies (and most 
 > management)fA > > will be presented SPEC marks written for the EPIC sub-system   > but most peopler, > > will be running old code on the Pentium. > @ > And they deserve poor performance if they believe manufacturer) > benchmarks rather than their own tests.n > A > > AFAIC, x86 emulation for Alpha might be the better way to go h > (smaller die,o1 > > lower power, lower cooling requirements, etc)  > > > I do not believe Compaq ever had the legal right to do that.> > I believe the right of AMD in this regard is only via a very > convoluted path. >   & Actually they did, it was called FX!32   ------------------------------    Date: 27 Jun 2001 11:50:26 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)t Subject: RE: Itanium HW REF MAN 3 Message-ID: <zFb9+2aqVAPD@eisner.encompasserve.org>s  ] In article <CIEJLCMNHNNDLLOOGNJIKENACNAA.tom@kednos.com>, Tom Linden <tom@kednos.com> writes:V >  >  >> -----Original Message-----aC >> From: Larry Kilgallen [mailto:Kilgallen@eisner.decus.org.nospam]e) >> Sent: Wednesday, June 27, 2001 8:59 AMq >> To: Info-VAX@Mvb.Saic.Com" >> Subject: Re: Itanium HW REF MAN >> . >> -E >> In article <28j_6.28208$yy2.2800962@news20.bellglobal.com>, "Neil r( >> Rieck" <n.rieck@sympatico.ca> writes: >> uE >> > The potential marketing scam here is that non-techies (and most 9 >> management)B >> > will be presented SPEC marks written for the EPIC sub-system  >> but most people- >> > will be running old code on the Pentium.o >>  A >> And they deserve poor performance if they believe manufacturerl* >> benchmarks rather than their own tests. >> sB >> > AFAIC, x86 emulation for Alpha might be the better way to go  >> (smaller die,2 >> > lower power, lower cooling requirements, etc) >> e? >> I do not believe Compaq ever had the legal right to do that. ? >> I believe the right of AMD in this regard is only via a very  >> convoluted path.n >>   > ( > Actually they did, it was called FX!32  E FX!32 was a software emulation rather than a hardward implementation.    ------------------------------  % Date: Wed, 27 Jun 2001 14:02:30 -0300l) From: fabio_compaq@ep-bc.petrobras.com.brw Subject: Itanium Logo.L Message-ID: <OF57C7A462.73D69549-ON03256A78.005B2810@ep-bc.petrobras.com.br>   Clickm  ' http://www.theinquirer.net/27060113.htmr   Sdsa   F=E1bio Cardoso=   ------------------------------  % Date: Wed, 27 Jun 2001 09:02:21 -0700l! From: Tom Linden <tom@kednos.com> * Subject: Itanium, non-issue, stop the mail9 Message-ID: <CIEJLCMNHNNDLLOOGNJIIENGCNAA.tom@kednos.com>t  I Almost the only people effected are us poor compiler writers, the rest ofs
 you won't seetK anything, thanks to us.  Who cares what the underlying processor is as longt as it works well,oH and I have to believe that it will.  Don't cry for the loss of alpha, itJ wasn't that great anyway, but then none of you knew that anyway, thanks to the compilers.  > So what if you have to recompile your applications.  Big deal.  K This has consumed altogether too much bandwidth, i wish we had 2 lists, one3 for serious4 stuff and one for BS   ------------------------------  % Date: Wed, 27 Jun 2001 13:25:09 -0300l) From: fabio_compaq@ep-bc.petrobras.com.brt. Subject: Re: Itanium, non-issue, stop the mailL Message-ID: <OF2CAE00F8.9F98DFF9-ON03256A78.005A1A7F@ep-bc.petrobras.com.br>  H A lot of jobs for developers (????) will be appearing in the next weeks= :r  
 I suggest:   a) www.jobserve.come b) www.plantrecruit.come c) www.dice.comt d) www.monster.com   What more ?e  
 F=E1bio C.        2 Tom Linden <tom@kednos.com> em 27/06/2001 13:02:21  - Favor responder a Tom Linden <tom@kednos.com>%             Info-VAX@Mvb.Saic.Come      * Assunto: Itanium, non-issue, stop the mail    H Almost the only people effected are us poor compiler writers, the rest = of
 you won't seeeH anything, thanks to us.  Who cares what the underlying processor is as = long as it works well,sH and I have to believe that it will.  Don't cry for the loss of alpha, i= t H wasn't that great anyway, but then none of you knew that anyway, thanks=  tot the compilers.  > So what if you have to recompile your applications.  Big deal.  H This has consumed altogether too much bandwidth, i wish we had 2 lists,=  one for seriousa stuff and one for BS           =o   ------------------------------    Date: 27 Jun 2001 13:06:25 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)n. Subject: Re: Itanium, non-issue, stop the mail3 Message-ID: <opIzcsOup6rJ@eisner.encompasserve.org>S  ] In article <CIEJLCMNHNNDLLOOGNJIIENGCNAA.tom@kednos.com>, Tom Linden <tom@kednos.com> writes:n  M > This has consumed altogether too much bandwidth, i wish we had 2 lists, one " > for serious stuff and one for BS  A But that is not an issue for comp.os.vms, only for those who have A chosen to receive it via email.  I would suggest switching to use  a regular newsgroup interface.   ------------------------------  % Date: Wed, 27 Jun 2001 11:19:26 -0600 4 From: "Michael D. Ober" <mdo.@.wakeassoc.com.nospam>. Subject: Re: Itanium, non-issue, stop the mail3 Message-ID: <JAo_6.1474$hz1.207511@news.uswest.net>r  D Actually, the question of having two NGs is valid.  One would be forJ technical issues and the other for General issues.  I frequently find thisG NG gets overloaded with non-tech stuff, making it difficult to use as a  technical group. --
 Mike Ober.  F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message- news:opIzcsOup6rJ@eisner.encompasserve.org...cF > In article <CIEJLCMNHNNDLLOOGNJIIENGCNAA.tom@kednos.com>, Tom Linden <tom@kednos.com> writes: >nK > > This has consumed altogether too much bandwidth, i wish we had 2 lists,r onei$ > > for serious stuff and one for BS >iC > But that is not an issue for comp.os.vms, only for those who havenC > chosen to receive it via email.  I would suggest switching to usee  > a regular newsgroup interface.   ------------------------------  % Date: Wed, 27 Jun 2001 13:25:23 -0400 + From: John Eisenschmidt <jeisensc@aaas.org>i. Subject: Re: Itanium, non-issue, stop the mail# Message-ID: <sb39deda.087@aaas.org>g  E I agree, this week has been rough. I have to archive mail from this =9J mailing list daily, since I routinely get over 150 messages (over 400 on = Monday).  L But as far as Usenet goes - better too many than none. comp.unix.tru64 has =& generated about 13 messages this week.  J >>> "Michael D. Ober" <mdo.@.wakeassoc.com.nospam> 06/27/2001 1:19:26 PM = >>>uD Actually, the question of having two NGs is valid.  One would be forJ technical issues and the other for General issues.  I frequently find thisG NG gets overloaded with non-tech stuff, making it difficult to use as aw technical group. --
 Mike Ober.  F "Larry Kilgallen" <Kilgallen@eisner.decus.org.nospam> wrote in message- news:opIzcsOup6rJ@eisner.encompasserve.org...oF > In article <CIEJLCMNHNNDLLOOGNJIIENGCNAA.tom@kednos.com>, Tom Linden <tom@kednos.com> writes: >vF > > This has consumed altogether too much bandwidth, i wish we had 2 = lists, one $ > > for serious stuff and one for BS >iC > But that is not an issue for comp.os.vms, only for those who havelC > chosen to receive it via email.  I would suggest switching to usev  > a regular newsgroup interface.   ------------------------------  % Date: Wed, 27 Jun 2001 13:42:48 -0300l) From: fabio_compaq@ep-bc.petrobras.com.bra Subject: iVMS under Stratus L Message-ID: <OF7C5AC2A5.8568FB9D-ON03256A78.005BCF8A@ep-bc.petrobras.com.br>  / It  will be soon if they begin to use Itanium !d     Regardse   FC   ------------------------------  % Date: Wed, 27 Jun 2001 10:06:41 +0100c% From: Alan Greig <a.greig@virgin.net>o" Subject: Re: Marketing Rantings #38 Message-ID: <0e8jjtobbdimquepgp0ca4vo2ngbkesu86@4ax.com>  F On Fri, 22 Jun 2001 21:29:26 -0400, Hamlyn Mootoo <univms@bigfoot.com> wrote:  G >Why did UNIX, and lately LINUX become so popular? Early on, UNIX usage G >was pervasive on many a college campus in the U.S. I still remember my7E >first experience working with the ed editor on UNIX running on a PDPyG >11/44 at college. This is AFTER having been exposed to TOPS-10 runningID >on the DEC 10, which had vastly superior computing power and betterE >editors (I sometimes miss TECO).  So many engineers, who would latere $ teco :== $teco32_tv  $ teco make love Not war? *ex$$b   -- Alan   ------------------------------  * Date: Wed, 27 Jun 2001 07:07:36 +0105 (AM) From: XIfU792JE@msn.comr Subject: Notice - Message-ID: <0GFL007DG6BP9E@mx.east.saic.com>   A We are Loan Specialists.....Tap into our huge network of Lenders!n   For U.S.A. Homeowners Only  0 Interest Rates have Dropped....Start Saving Now!  # We Will Shop The Best Loan For You!e  O Are you in debt? Need extra cash? We can get you the loan you need. Regardless iO of whether you have good or bad credit, we can help you.We specialize in First  L and Second Mortgages, including loans that other lenders turn down. Funding P borrowers with less than perfect credit is our specialty. We have loan programs  that are unheard of.  = CLICK HERE FOR ALL DETAILS http://usuarios.tripod.es/bravt40/e  C ===================================================================mT REMOVAL INSTRUCTIONS: You may automatically remove yourself from any future mailings= by clicking here. mailto:geopsti@uole.com?subject=delete-mort    ------------------------------  % Date: Wed, 27 Jun 2001 05:40:06 -04001) From: "Neil Rieck" <n.rieck@sympatico.ca>s Subject: Re: NYSE:; Message-ID: <zOh_6.21623$lk5.1517086@news20.bellglobal.com>0  1 "john nixon" <jnixon@cfl.rr.com> wrote in message"9 news:vk5U6.432190$fs3.68102873@typhoon.tampabay.rr.com...tG > Anybody know what kind of computer system the New York Stock Exchangee uses?nI > All trading has been halted due to a "computer glitch".  Of course thatr couo > ld mean almost anything. >eL I know the Toronto Stock Exchange (TSE) is running on aging Tandem boxes andD they were waiting for new hardware (reportedly Alpha based lock-stepJ technology). Oops. I guess they'll be waiting for MIPS based machines now.  
 Neil Rieck Kitchener/Waterloo/Cambridge,t Ontario, Canada.! http://www3.sympatico.ca/n.rieck/l   ------------------------------  % Date: Wed, 27 Jun 2001 13:16:50 +0200e5 From: Martin Knoblauch <Martin.Knoblauch@TeraPort.de>' Subject: Re: NYSEd+ Message-ID: <3B39C0A2.B262DE13@TeraPort.de>r   Neil Rieck wrote:s >  > >yN > I know the Toronto Stock Exchange (TSE) is running on aging Tandem boxes andF > they were waiting for new hardware (reportedly Alpha based lock-stepL > technology). Oops. I guess they'll be waiting for MIPS based machines now. >   G  Looking for "lockstep alpha" on Google, I found the following, kind ofo amusing, link.  4  http://www.internetwk.com/news0998/news092198-7.htm    F  Anyway, one thing I never really understood/researched is whether theC MIPS/R10K CPUs in the current Himalayas offer any hw-assistance for2G lockstep mode. Or was this something always wanted to have and wouldn'tnB get from MIPS after SGI/MIPS [temporarily] decided to stop further/ development of high-end MIPS CPUs? Any insight?a   MartinB ------------------------------------------------------------------B Martin Knoblauch         |    email:  Martin.Knoblauch@TeraPort.de7 TeraPort GmbH            |    Phone:  +49-89-510857-309l7 C+ITS                    |    Fax:    +49-89-510857-111i5 http://www.teraport.de   |    Mobile: +49-170-4904759    ------------------------------   Date: 27 Jun 2001 12:27:19 GMT7 From: woodacre@scala.reading.sgi.com (Michael Woodacre)h Subject: Re: NYSEt. Message-ID: <9hcjf7$jqi28$1@fido.engr.sgi.com>  c In article <3B39C0A2.B262DE13@TeraPort.de>, Martin Knoblauch <Martin.Knoblauch@TeraPort.de> writes:* |> Neil Rieck wrote: |> > w |> > >Q |> > I know the Toronto Stock Exchange (TSE) is running on aging Tandem boxes anddI |> > they were waiting for new hardware (reportedly Alpha based lock-stepoO |> > technology). Oops. I guess they'll be waiting for MIPS based machines now.e |> > A |> gJ |>  Looking for "lockstep alpha" on Google, I found the following, kind of |> amusing, link.s |> t7 |>  http://www.internetwk.com/news0998/news092198-7.htm= |> = |> =I |>  Anyway, one thing I never really understood/researched is whether the"F |> MIPS/R10K CPUs in the current Himalayas offer any hw-assistance forJ |> lockstep mode. Or was this something always wanted to have and wouldn'tE |> get from MIPS after SGI/MIPS [temporarily] decided to stop further:2 |> development of high-end MIPS CPUs? Any insight?  . The R10K CPUs do have h/w support for lockstep   |> 6	 |> Martin2E |> ------------------------------------------------------------------rE |> Martin Knoblauch         |    email:  Martin.Knoblauch@TeraPort.dea: |> TeraPort GmbH            |    Phone:  +49-89-510857-309: |> C+ITS                    |    Fax:    +49-89-510857-1118 |> http://www.teraport.de   |    Mobile: +49-170-4904759   --      Michael S. Woodacre o woodacre@sgi.com   i Phone: +44 118 925 7846n   ------------------------------  % Date: Wed, 27 Jun 2001 14:40:00 +0200g5 From: Martin Knoblauch <Martin.Knoblauch@TeraPort.de>a Subject: Re: NYSEd+ Message-ID: <3B39D420.E590843F@TeraPort.de>    Michael Woodacre wrote:d >  > |>K > |>  Anyway, one thing I never really understood/researched is whether theIH > |> MIPS/R10K CPUs in the current Himalayas offer any hw-assistance forL > |> lockstep mode. Or was this something always wanted to have and wouldn'tG > |> get from MIPS after SGI/MIPS [temporarily] decided to stop furthere4 > |> development of high-end MIPS CPUs? Any insight? > 0 > The R10K CPUs do have h/w support for lockstep >  Hi Michael,n  F  is anybody besides Tandem using that feature in systems? I definitely2 never cared about it when I was working at SGI :-)   Martin -- rB ------------------------------------------------------------------B Martin Knoblauch         |    email:  Martin.Knoblauch@TeraPort.de7 TeraPort GmbH            |    Phone:  +49-89-510857-309a7 C+ITS                    |    Fax:    +49-89-510857-11155 http://www.teraport.de   |    Mobile: +49-170-4904759c   ------------------------------  % Date: Wed, 27 Jun 2001 09:45:24 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>r Subject: Re: NYSEa, Message-ID: <3B39E372.68C8CC7C@videotron.ca>   Neil Rieck wrote:sN > I know the Toronto Stock Exchange (TSE) is running on aging Tandem boxes andF > they were waiting for new hardware (reportedly Alpha based lock-stepL > technology). Oops. I guess they'll be waiting for MIPS based machines now.  N I thought TSE was on aging IBM platform. I know that after Digital had won theL Montreal Stock Exchange, they tried to go for the TSE, but failed (includingM internal reasons where employees's infighting to get the sales quota resulted J in no cooperation between the two Digital offices and also resulted in theH loss of another financial institution contract and the loss of a Digital- customer). As I recall, IBM had the machines.8   ------------------------------   Date: 27 Jun 2001 15:11:58 GMT7 From: woodacre@scala.reading.sgi.com (Michael Woodacre)h Subject: Re: NYSEh. Message-ID: <9hct3u$js9c0$1@fido.engr.sgi.com>  c In article <3B39D420.E590843F@TeraPort.de>, Martin Knoblauch <Martin.Knoblauch@TeraPort.de> writes:  |> Michael Woodacre wrote: |> >   |> > |>eN |> > |>  Anyway, one thing I never really understood/researched is whether theK |> > |> MIPS/R10K CPUs in the current Himalayas offer any hw-assistance forlO |> > |> lockstep mode. Or was this something always wanted to have and wouldn'tgJ |> > |> get from MIPS after SGI/MIPS [temporarily] decided to stop further7 |> > |> development of high-end MIPS CPUs? Any insight?a |> > ,3 |> > The R10K CPUs do have h/w support for lockstepe |> > m |> Hi Michael, |> iI |>  is anybody besides Tandem using that feature in systems? I definitely 5 |> never cared about it when I was working at SGI :-)     N Just Tandem. They provided engineering support to help put the logic into bothO the R4400 and the R10K. It's fondly refered to as 'Tandem mode' within MIPS/SGIa   Cheers,_ Mike   |> 8	 |> Martin0 |> -- E |> ------------------------------------------------------------------ E |> Martin Knoblauch         |    email:  Martin.Knoblauch@TeraPort.dee: |> TeraPort GmbH            |    Phone:  +49-89-510857-309: |> C+ITS                    |    Fax:    +49-89-510857-1118 |> http://www.teraport.de   |    Mobile: +49-170-4904759   -- e    Michael S. Woodacre   woodacre@sgi.com   n Phone: +44 118 925 7846    ------------------------------  % Date: Wed, 27 Jun 2001 13:41:47 -0300r) From: fabio_compaq@ep-bc.petrobras.com.bri. Subject: Re: Offical Compaq/Intel AnnouncementL Message-ID: <OF6B7438BD.65EABAD4-ON03256A78.005BA6B8@ep-bc.petrobras.com.br>  < This page still static.... no new links ... Are they alive ?   http://www.alphapowered.com-   Regards-     FC   ------------------------------  + Date: Wed, 27 Jun 2001 10:02:11 +0000 (UTC) , From: Pawel Krawczyk <anti_kravietz@ceti.pl> Subject: OpenVMS on MicroVAX?P, Message-ID: <9hcav3$vo2$1@druid.ceti.com.pl>  J Hello, I've just got a MicroVAX 3600 with VMS 5.x. The machine is equippedD with Ethernet adapter, two disks of 600 MB each and a tape drive. IsG this hardware enough to install hobbyist OpenVMS?  I've found that it's2J distributed on CD-ROM and I only have the tape.  Is it possible to installE from tape or to obtain some cheap CD drive compatible with DEC's one?l  H I'm also looking for any people in Poland using VMS who could help a bit with the system.   -- e4 Pawe Krawczyk *** home: <http://ceti.pl/~kravietz/>3 security: <http://ipsec.pl/>  *** fidonet: 2:486/23b   ------------------------------  % Date: Wed, 27 Jun 2001 07:26:26 -0400o  From: John Santos <JOHN@egh.com>! Subject: Re: OpenVMS on MicroVAX?u/ Message-ID: <1010627071152.38769A@Ives.egh.com>   * On Wed, 27 Jun 2001, Pawel Krawczyk wrote:  L > Hello, I've just got a MicroVAX 3600 with VMS 5.x. The machine is equippe= drF > with Ethernet adapter, two disks of 600 MB each and a tape drive. IsI > this hardware enough to install hobbyist OpenVMS?  I've found that it'srL > distributed on CD-ROM and I only have the tape.  Is it possible to instal= lXG > from tape or to obtain some cheap CD drive compatible with DEC's one?- >=20J > I'm also looking for any people in Poland using VMS who could help a bit > with the system. >=20 > --=20u8 > Pawe=B3 Krawczyk *** home: <http://ceti.pl/~kravietz/>5 > security: <http://ipsec.pl/>  *** fidonet: 2:486/23t  H I have a very similar system at home; it works fine.  The VAX 3600 isn't@ the fastest VAX ever by a long way, but it is much faster then a MicroVAX-II.  F CD-ROM drives for this system are problematical.  SCSI controllers areC very expensive for this or any Qbus system, and IDE controllers arelC non-existent.  The 3 choices are 1) cluster with another system (an'F Alpha?) with a CD-ROM drive.  (You can't do a system installation thatE way, unless you copy the CD to the second hard drive on your VAX, andDE install from there.)  2) get an InfoServer with CD-ROM drive (I thinknD used Infoservers can be found fair cheap on Ebay, etc.)  3) Copy the@ files from the CD via a network.  (You may be able to find LinuxC software that will read an ODS-2 disk, and use it to read the CD on C a Linux-based PC and FTP to the VAX, copying the essential files toaE [0,0] on one of your disks and doing the upgrade/install from there.)s  C I guess it is likely your tape drive is a TK50 or a TK70.  If it isOC either of these, it would probably be easier to install from a TK50oB kit.  Maybe someone would be able to loan you one, or someone withC both a CD-ROM drive and a TK50 would be able to create one for you. C TK50 (especially) and TK70 are slow, but you should only have to do A it once!  (VMS V7.3, just released, is the last version that wille be shipped on TK50's.)  E ** Someone (Hoff?) mentioned recently that there will be a LAD servermF available in OpenVMS Alpha soon.  (LAD is the Local Area Disk protocolC used by InfoServers to serve CD's to the network.)  I'm not sure ifsB it is there in VMS V7.3 or is something on the freeware or is justE coming soon.  This would give a 4th method from installing from CD's.l  8 Hope you can find someone near by to help you with this.   --=20k John Santosa Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Wed, 27 Jun 2001 09:51:10 -0400h- From: JF Mezei <jfmezei.spamnot@videotron.ca> ! Subject: Re: OpenVMS on MicroVAX?o, Message-ID: <3B39E4CC.5B3C5C55@videotron.ca>   Pawel Krawczyk wrote:0 > L > Hello, I've just got a MicroVAX 3600 with VMS 5.x. The machine is equippedF > with Ethernet adapter, two disks of 600 MB each and a tape drive. Is4 > this hardware enough to install hobbyist OpenVMS?   N Yes it is enough. You didn't mention how much memory you have though, but I amM able to run 2 machines each with 16 mb of ram (but large page files). One hasiM TCPIP services and DECwindows running, and the other has ALLIN1 and plenty oft my own software running.   > I've found that it's2 > distributed on CD-ROM and I only have the tape.   G Almost any old CDrom drive (SCSI) will work. I am not familiar with the9K physical characteristics of that box, does it have a SCSI adaptor ? If not,:+ then installation will be more problematic.D   ------------------------------    Date: 27 Jun 2001 07:58:20 -0700' From: Doran167W@aol.com (Doran Werling)f! Subject: Re: OpenVMS on MicroVAX?f= Message-ID: <d7aafdca.0106270658.756167a9@posting.google.com>w  ` Pawel Krawczyk <anti_kravietz@ceti.pl> wrote in message news:<9hcav3$vo2$1@druid.ceti.com.pl>...L > Hello, I've just got a MicroVAX 3600 with VMS 5.x. The machine is equippedF > with Ethernet adapter, two disks of 600 MB each and a tape drive. IsI > this hardware enough to install hobbyist OpenVMS?  I've found that it'scL > distributed on CD-ROM and I only have the tape.  Is it possible to installG > from tape or to obtain some cheap CD drive compatible with DEC's one?v > J > I'm also looking for any people in Poland using VMS who could help a bit > with the system.   Pawel:  D This machine will run hobbyist VMS just fine. Unfortunatly, there isC no SCSI bus on a 3600 Microvax. So a CD-ROM is out of the question.gC You will have to use your tape drive (I would recommend copying thed) savesets to disk first) for the installs.s   Regards,
 Doran Werlingi RW/SCS Inc.t   ------------------------------  % Date: Wed, 27 Jun 2001 16:04:45 +01000  From: steven.reece@quintiles.com! Subject: Re: OpenVMS on MicroVAX?nH Message-ID: <OF84EC6C5A.ADF823E7-ON80256A78.005270AC@qedi.quintiles.com>   Untrue. K There was, IIRC, a Q-bus variant of the RRD40 CD drive, although the drivesh1 themselves were pretty slow by present standards.eK There are third party SCSI adapters for Q-bus, just as there is Compaq (neehJ Digital's) KZQSA which will support SCSI CD-ROMs and SCSI tapes (but would+ not be supported for SCSI disk operations).KG Then there's the potential for hooking a drive up to the backplane of ac% BA350 with an HSD05 in the top of it.   G There may not be a cheap option for connecting a SCSI CD-ROM to a Q-busk? system like the MicroVAX 3600, but there are options available.    Steve.   Doran Werling wrote: >>>nD This machine will run hobbyist VMS just fine. Unfortunatly, there isC no SCSI bus on a 3600 Microvax. So a CD-ROM is out of the question.vC You will have to use your tape drive (I would recommend copying then) savesets to disk first) for the installs.  <<<e   ------------------------------  % Date: Wed, 27 Jun 2001 13:28:11 -0400b- From: JF Mezei <jfmezei.spamnot@videotron.ca>O! Subject: Re: OpenVMS on MicroVAX?F, Message-ID: <3B3A17A7.59BD2030@videotron.ca>   re: lack of CD drive.n  M Could the chap mount the hobbyist CD on a PC and copy the savesets to the VMS M machine with KERMIT and then perform the install ? He said he had 2 drives oneL the VAX. Perhaps one could contain the savesets and the other the VMS system which would then be zapped ?   so:a< 1- create standalone backup from the existing system on tapeN 2- use kermit to transfer the VMS savesets to the second drive (and settin the right file attributes)# 3- boot standalone backup from taper< 4- backup/image from the "B" saveset on disk 2 to the disk 1L 5- reboot which will install the rest of the VMS system from disk 2 to disk1   ------------------------------  % Date: Wed, 27 Jun 2001 12:04:06 +0100   From: steven.reece@quintiles.comQ Subject: Re: OT answering, was RE: How to see who causes execessiveloginfailures.bH Message-ID: <OFE88A7A1A.A1E52DC6-ON80256A78.003CA6B7@qedi.quintiles.com>  * I'm not a bit sure of where that would be. :-)c   Steve.   Louis Schneider wrote :9 >>>eF I have quite a large vat of used bits which has accumulated over time.$ WHere can I send them for recycling?  " >This saves bandwidth and helps toB > reduce the worldwide shortage of bits, dashes, periods and other > punctuation. <<<    ------------------------------  % Date: Wed, 27 Jun 2001 12:11:10 +0000o  From: Steve.Spires@yellgroup.com, Subject: Question re: Oracle and OpenVMS 7.3/ Message-ID: <00256A78.0042F32E.00@quegw01.btyp>u   cc:  bcc:L Contact:   Tel: 3063  -  IS - Infrastructure, 1st Floor, Bridge Street Plaza  # Question re: Oracle and OpenVMS 7.3L     Hi all,:  J Is anyone out there using the following; OpenVMS V7.3 and Oracle [Classic]K 8.1.7, or can someone help me navigate the Oracle website to find somethingyM which will tell me what versions of VMS and what versions of Oracle have beenj tested together?  M The reason? Our DBA's have been told they they should not run Oracle 8.1.7 on I OpenVMS V7.3, and I have a node which has been upgraded to V7.3 and which6P requires Oracle to be upgraded. The DBA's have the power, and I might have to go; back a release VMS wise, which isn't going to be trivial...a   Steve Spires     [Information] -- PostMaster:D This transmission is intended solely for the addressee(s) and may beL confidential. If you are not the named addressee, or if the message has beenP addressed to you in error, you must not read, disclose, reproduce, distribute or use this transmission.  L Delivery of this message to any person other than the named addressee is notH intended in any way to waive confidentiality.  If you have received thisF transmission in error please contact the sender or delete the message.  
 Thank you.   ------------------------------  % Date: Wed, 27 Jun 2001 02:11:57 -0400t- From: JF Mezei <jfmezei.spamnot@videotron.ca>u? Subject: Re: Question to Charlie Matco - reply to Terry Shannon , Message-ID: <3B39792C.CC6CD6B6@videotron.ca>   Rob Young wrote:J >         The bit about Itanics being more expensive?  So what?  DeerfieldK >         will be out in 12 months or so and you'll see IA64 parts approachbN >         Pentium IV prices if you expect IA64 to ever make it to the desktop.) >         Something Alpha could never do.s  N A few years ago, a former Digital employee comparted IA64 to Alpha. One of theL very convincing arguments was that IA64 would require more physical space on@ the chip because it is a very complex chip with lots of goodies.  H The bigger the chip, the more there are chances for a small defect whichL reduces the maximum Mhz rating for that chip. In other words, the bigger theF chip, the lower the yields, the higher the cost per chip, and the feweK quanities of chips that run fast enough you can produce. Alpha, by having aKL reduced instruction set with no attempt at emulating legacy architecture canK be condensed more, and they can then concentrate on perforance improvementsr. such as pipelining, branch prediction etc etc.  K Obviously, Intel has now succeeded in producing an IA64 that has acceptablerF yields, but by no means cheaper than the low demand Alpha. But the bigF question si whether Intel will be able to produce IA64 in large enoughN quantities with high enough yields to satisfy demand (hence bring down price).E As long as demand will remain higher than supply, Ia64 will remain anu expensive chip.n  M When intel makes a big 8086 wafer, it might get one 1.7ghz 8086 out, and manyoD CPUs of lower speed that it can sell for the consumer retail market.  K But when Intel makes an IA64 wafer, what happens if it gets only a few CPUs P that have high enough speed rating, and the rest are too slow to be marketable ?   ------------------------------  % Date: Wed, 27 Jun 2001 02:28:09 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>h? Subject: Re: Question to Charlie Matco - reply to Terry Shannont( Message-ID: <9hbu7f$3ds$1@pyrite.mv.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:hE6MHVj3HP6S@eisner.encompasserve.org...uK > In article <9hbqk2$up$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com>o writes:  >p > >oK > > I've addressed the above not-yet-even-vaporware elsewhere, so I'll just-G > > remind people that *should* it ever materialize its special-purpose. natureD > > (if it indeed is Alpha-specific in some way) will likely make it anythingC > > but cheap (not to mention that run-of-the-mill Itanics are more.	 expensive  > > than Alphas already).7   ...-  B > There are hooks in there to make PA-RISC work.  A few more hooksC > in the architecture itself to make NSK/Tru64/VMS work, won't mean:C > much and it surely won't be two separate architectures.  You have @ > any reason to support your assertion there will be a "fork" inE > the architecture?  IA64 "vanilla" and IA64 "special" for the Compaqe+ > handicapped?  Where do you get that idea?   H It's Kerry who seems intent on promoting the warmth and fuzziness of hisI 'Alpha/IA64-2' might-someday-be-vaporware, which he certainly seems to be K presenting as something considerably more Alpha-ized (another of his terms,dI IIRC) than just the addition of a few hooks.  If a few hooks is extent of L the Alpha-ization, it probably won't take Intel more than 3 years to includeJ them, and they probably won't drive up the price at all (but of course theI result will also perform like IA64 rather than the hybrid super-chip that-C Kerry and/or others so rosily describe, so one can count on at bestKK performance comparable to what same-generation Alphas would have provided).a   >T7 > The bit about Itanics being more expensive?  So what?p  D It's a data point, and the only one we have.  But we do have Intel'sI expressed interest in developing IA64 as an entree to a space with highereK price-points, which at least offers a clue about how it would like to priceC that architecture over time.     DeerfieldwC > will be out in 12 months or so and you'll see IA64 parts approachdF > Pentium IV prices if you expect IA64 to ever make it to the desktop.  J Why should we expect that?  Intel has even less reason to push IA64 at theC desktop than Compaq had with Alpha, because Intel *already* makes alL processor in that space and thus can preserve its higher-margin IA64 product' without leaving the low-end unoccupied.o  F Not to mention the real possibility that the only way to keep AMD fromL blowing Intel's doors off in that space will be to continue high-performance IA32 development there.d  ! > Something Alpha could never do.   J One of the few good decisions DEC and Compaq made:  there was no reason toF fight in that space with the existing, well-entrenched occupants givenG ownership of a product with such a great command of a far-higher-margino space.   - bill   >4 > Rob8 >@   ------------------------------  % Date: Wed, 27 Jun 2001 09:40:04 +0100M% From: Alan Greig <a.greig@virgin.net>e? Subject: Re: Question to Charlie Matco - reply to Terry Shannon 8 Message-ID: <9n6jjt0mpr1h310q2clj2nkaccfis8n8mk@4ax.com>  1 On Tue, 26 Jun 2001 22:21:08 -0400, "Main, Kerry"m <Kerry.Main@compaq.com> wrote:   >tH >I personally think the idea of OpenVMS strengths going up against Win64K >offerings is great .. each OS gets to compete on scalability, availablity,sI >performance on a similar HW platform. [No, I have no idea how similar orm# >identical these platforms will be]y  F Capellas was asked this question and he said it was their intention toB produce Alphaservers which could run the entire Compaq OS family -F eventually even including NSK. Galaxy features would be ported so thatF you could have VMS, T64, NT, NSK all running in the same box. At least& that's the aim. according to Capellas. -- Alan   ------------------------------  # Date: Wed, 27 Jun 2001 11:45:55 GMTi. From: "Alphaman" <alphaman64@nixspam-home.com>? Subject: Re: Question to Charlie Matco - reply to Terry Shannon1; Message-ID: <THj_6.11300$P5.3917039@news1.rdc1.tn.home.com>8  4 Main, Kerry <Kerry.Main@compaq.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF4A19466@kaoexc01.americas.cpqcorp.net...; > Was I surprised at the announcement? Sure - everyone was.2  J Why is being surprised by an announcement goodness?  Why not do things the@ traditional way -- NDA's, migration, slow changes, condition the1 marketplace, survey customers, sway the consumer?>  L Instead, in one lump, OpenVMS people are being told they have to swallow theF one processor they hate the most in the world in exchange for the bestJ processor in the world.  The "marketing giant" we thought might be a great> hope for Alpha turns out to be a worse marketeer than Digital.   Mediocrity rules,i Aaron> --> Aaron Sakovich  http://members.home.net/sakovich/alphaman.html> Make April 15 just another day:        http://www.fairtax.org/K "Oh my God, they killed Alpha!!!  You bastards!" (Anonymous Alpha Engineer)n   ------------------------------  % Date: Wed, 27 Jun 2001 10:04:42 -0400l- From: JF Mezei <jfmezei.spamnot@videotron.ca> ? Subject: Re: Question to Charlie Matco - reply to Terry Shannonp, Message-ID: <3B39E7F7.3CA52EED@videotron.ca>   Alphaman wrote: L > processor in the world.  The "marketing giant" we thought might be a great@ > hope for Alpha turns out to be a worse marketeer than Digital.  G The problem is ours. We hoped so much that Compaq bought Digital to fix.L Digital's marketing problems and that VMS would be unleashed and become once@ again a mainstream OS that we were blinded by the harsh reality:  T 	Compaq never intended to keep any of the "Digital" stuff except the services stuff.    M Palmer should have been sacked 3 years before the Compaq takeover and someonehK witha vision to rebuild Digital brought in. We would be better off today if M Digital had simply liquidated itself and sold off all its parts individually,aH as it had begun to do under Palmer. VMS woudl have either been killed or* purchased by someone who really wanted it.  K As it stands, Palmer didn't do his "delete *.*;*" job completely and Compaq:J was stuck with remnants of Digital it would have prefered not getting, and: those are the remnants that are the hardest to get rid of.   ------------------------------  % Date: Wed, 27 Jun 2001 11:10:41 -0300h) From: fabio_compaq@ep-bc.petrobras.com.bre? Subject: Re: Question to Charlie Matco - reply to Terry ShannoneL Message-ID: <OF71FD3447.8810CBFF-ON03256A78.004DC988@ep-bc.petrobras.com.br>  A I dont know who is this Charlie Matco which everybody talks here,a< but I would like to read an interview from Ken Olsen at CNET& saying about what Compaq did with DEC.   Fabio C.        > JF Mezei <jfmezei.spamnot@videotron.ca> em 27/06/2001 11:04:42  9 Favor responder a JF Mezei <jfmezei.spamnot@videotron.ca>b             Info-VAX@Mvb.Saic.Comt      ? Assunto: Re: Question to Charlie Matco - reply to Terry Shannonl     Alphaman wrote:aF > processor in the world.  The "marketing giant" we thought might be a greate@ > hope for Alpha turns out to be a worse marketeer than Digital.  G The problem is ours. We hoped so much that Compaq bought Digital to fixoG Digital's marketing problems and that VMS would be unleashed and becomet once@ again a mainstream OS that we were blinded by the harsh reality:  H      Compaq never intended to keep any of the "Digital" stuff except the services stuff.e    E Palmer should have been sacked 3 years before the Compaq takeover andV someone K witha vision to rebuild Digital brought in. We would be better off today ife? Digital had simply liquidated itself and sold off all its partsi
 individually,SH as it had begun to do under Palmer. VMS woudl have either been killed or* purchased by someone who really wanted it.  K As it stands, Palmer didn't do his "delete *.*;*" job completely and CompaqsJ was stuck with remnants of Digital it would have prefered not getting, and: those are the remnants that are the hardest to get rid of.   ------------------------------  % Date: Wed, 27 Jun 2001 10:41:24 -0400-- From: "Richard D. Piccard" <piccard@ohio.edu>0? Subject: Re: Question to Charlie Matco - reply to Terry Shannonu( Message-ID: <3B39F095.FF83B401@ohio.edu>  * fabio_compaq@ep-bc.petrobras.com.br wrote:  C > I dont know who is this Charlie Matco which everybody talks here,.   [snip]  N Years ago Terry Shannon wrote a column with that by-line, rather in the manner of  "Robert X. Cringely" on PCs (see. http://www.execpc.com/~shepler/cringely.html).                           RDPy   --B ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  % Date: Wed, 27 Jun 2001 10:06:06 -0500r1 From: "David J. Dachtera" <djesys.nospam@fsi.net>o? Subject: Re: Question to Charlie Matco - reply to Terry Shannono' Message-ID: <3B39F65E.23AC537E@fsi.net>-   "Bradford J. Hamilton" wrote:5 >  > Hi Terry,  > L > I understand that the last 36 hours has been very trying for all involved. > Q > I don't think that there is anyone (c.o.v. posters, COMPAQ, even Intel) *wants*eU > to destroy VMS.  I *do* think that a lot of the "negativity" seen in this NG arisest1 > from the *way* in which the news was delivered.p   For myself, I'd tend to agree.  E Not that doing it doesn't make sense - we've been beating them bloodylG about VMS on Intel since news of Emerald first appeared. That's not the  point.  E The point is that it makes sense for Itanic, Itanic-capable mobos anda VMS to "grow-up" together:  < o There are no commercially viable Itanic chips as of today.E o For the prototype chips that exist, mobo designs are still in flux.eH o VMS on Itanic is today a challenge, as opposed to the impossibility it was once thought to be.O  G Just as Alpha, Alpha mobos and AXP/VMS grew from VAX/VMS V5.4-2, so nowe8 Itanic, Itanic mobos and OpenVMS-IA64 can grow together.  E Taken together, this could be the most serious threat to M$ since the- rise of Linux.  H ...but yes, perception being everything, the presentation is likely more2 responsible for the reaction than the news itself.   -- 3 David J. Dachtera0 dba DJE Systems. http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/s  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.h   ------------------------------   Date: 27 Jun 01 09:44:44 MDT" From: ivie@cc.usu.edu (Roger Ivie)? Subject: Re: Question to Charlie Matco - reply to Terry Shannonk% Message-ID: <vpl4i4cOKBCO@cc.usu.edu>o  \ In article <3B39792C.CC6CD6B6@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes:J > The bigger the chip, the more there are chances for a small defect whichN > reduces the maximum Mhz rating for that chip. In other words, the bigger theH > chip, the lower the yields, the higher the cost per chip, and the feweM > quanities of chips that run fast enough you can produce. Alpha, by having aiN > reduced instruction set with no attempt at emulating legacy architecture canM > be condensed more, and they can then concentrate on perforance improvementsm0 > such as pipelining, branch prediction etc etc.  3 By that argument, they should be moving VMS to ARM.i -- lN -------------------------+----------------------------------------------------3 Roger Ivie               | Ben Stein for president!p ivie@cc.usu.edu          | http://cc.usu.edu/~ivie/ | -----BEGIN GEEK CODE BLOCK-----  Version: 3.18 GP dpu s:+++ a C++ UB- P--- L- E--- W- N++ o-- K-- w--- > O M+ V+++ PS+++ PE++ Y+ PGP+ t++ 5++ X-- R tv++ b+++ DI+++ D-  G-- e++ h--- r+++ y+++ s ------END GEEK CODE BLOCK------b   ------------------------------  % Date: Wed, 27 Jun 2001 16:59:09 +0200- From: Magnus M <mmad@tips.se> Y Subject: Re: Question to Charlie Matco - reply to Terry Shannon (and some general commentn& Message-ID: <3B39F4BD.5020906@tips.se>   Bill Todd wrote:  8 > "Main, Kerry" <Kerry.Main@compaq.com> wrote in messageN > news:BE56C50EA024184DAF48F0B9A47F5CF4A19466@kaoexc01.americas.cpqcorp.net... >    > I > I've addressed the above not-yet-even-vaporware elsewhere, so I'll justcL > remind people that *should* it ever materialize its special-purpose natureK > (if it indeed is Alpha-specific in some way) will likely make it anythingaK > but cheap (not to mention that run-of-the-mill Itanics are more expensive, > than Alphas already).0 >  > - bill >  >       H Bill, as someone who very rarely posts to comp.os.vms (or should I call I it comp.os.vms.advocacy?) but has been around since the Info-VAX days in  E the 80s I think you are off the mark here.. Have you ever been loggedn1 onto an "Itanic"? Tested some of your code on it? A While we all probably agree that Alpha is superior technology andaC a much cleaner design in nearly all respects, the fact remains thatcC even the current "late and slow" Itanium v1 is quite a performer inbD some specific areas (integer code not being one of them, clearly)...      5 Ex: Memory bandwidth on "Billybox" IA64 servers (try aE testdrive.compaq.com's Linux64 Blazer box with some basic C code) is  3 higher than on a EV67 ES40 with ideal interleave...t@ That's a gen-1 product, with immature GNU compilers... SpecFP is@ on par with EV68 for this inferior chip... (DS20E EV68 833: 784,
 Itanium: 701)   A Given these facts, I find it a bit early to write it off as nevert< being able to match Alpha perfomance, EV8 with its SMT glory@ hasn't exactly taped out either (re: post-McKinley designs being complete vapourware)?.    B I honestly believe that Terry Shannons account of an analysis that; says Alpha (given the difference in R/D spending between a o@ bean-counter-dense Compaq and Intel, and fab latency) would have? lost its performance edge right after McKinley _might_ be true.-& (ref: his SKC posting on Compaqs site)    = With all the EV7 tapeout delays (noting that EV7 is "just" an:C optimized EV6 core at heart with no radical technology steps taken) B perhaps the analysis is correct, and perhaps it wasn't done solelyF by evil marketoid droids with an intrinsic wish to kill Alpha, perhaps9 (Gasp!) actual DECpaq chip designers were involved... :-)p      ? Furthermore I'd bet that unless there is _delibarate_ poisoningt; of the required BIOS/console interfaces to prevent VMS from = running on non-Compaq IA64 designs the boxes in question willp> be quite cheap, which in theory should even please some of the- "Affordable VMS systems NOW!!!!" crowd... :-)i  ? As Hoff said, perhaps this will be a golden opportunity to worki> on some of the weak areas of VMS in terms of hardware support,; well-known filesystem and I/O issues, SMP granularity etc..g  A There is real work ahead in Nashua, and in the words of D.Cutler, D "When all is said and done, more is typically said than done". There? are fewer placer where his quote is more true than the current a comp.os.vms crowd... :-)  : Of couuse, I'm pissed/upset about Alpha going away and the; possible futures that were wasted along the way, but I feel :   compelled to look at Alpha vs Itanium HW futures from an@ engineers perspective right now (I'm already starting to read up?   on the instruction set) than participate in some of the more  - spectacular FUD-generating paranoia portrayeds+ in this newsgroup over the last few days...e  . Back to writing (Yes, on VMS) code... regards,     /magnusa   ------------------------------   Date: 27 Jun 2001 10:32 CDTk' From: carl@gerg.tamu.edu (Carl Perkins)gY Subject: Re: Question to Charlie Matco - reply to Terry Shannon (and some general comment.- Message-ID: <27JUN200110325605@gerg.tamu.edu>p   mmad@tips.se writes...@ }As Hoff said, perhaps this will be a golden opportunity to work? }on some of the weak areas of VMS in terms of hardware support, < }well-known filesystem and I/O issues, SMP granularity etc.. }  }/magnus  D I think that this revisting of known problematic areas is one of the= few actual good things that I have seen in this deal, so far.m  F On the other hand, in keepig with the current dark mood in these partsF it would have been nice if they could have spent significant errort on, such issues without the need to do the port.  E On the other other hand, it does not surprise me that VMS engineeringdF find this turn of events interesting. They are, after all, programmersC and this is a fine opportunity for them to get to do some extensive C programming - particularly in parts of the OS that they may not getaD to mess with much. So they get to fiddle while everyone else wonders if Rome is burning.a   --- Carl   ------------------------------  % Date: Wed, 27 Jun 2001 12:41:39 -0300w) From: fabio_compaq@ep-bc.petrobras.com.brtY Subject: Re: Question to Charlie Matco - reply to Terry Shannon (and somegeneral commentslL Message-ID: <OF8BB15099.76A624F6-ON03256A78.0056184B@ep-bc.petrobras.com.br>   Like to have for example:h   a) USB b) FireWireaC c) A tool / compiler to develop OpenVMS Device Drivers more easily.s   RegardsA   FC        8 carl@gerg.tamu.edu (Carl Perkins) em 27/06/2001 13:32:00  3 Favor responder a carl@gerg.tamu.edu (Carl Perkins)(             Info-VAX@Mvb.Saic.Comj      I Assunto: Re: Question to Charlie Matco - reply to Terry Shannon (and some,          general comments)     mmad@tips.se writes...@ }As Hoff said, perhaps this will be a golden opportunity to work? }on some of the weak areas of VMS in terms of hardware support,h< }well-known filesystem and I/O issues, SMP granularity etc.. }o }/magnus  D I think that this revisting of known problematic areas is one of the= few actual good things that I have seen in this deal, so far.e  F On the other hand, in keepig with the current dark mood in these partsF it would have been nice if they could have spent significant errort on, such issues without the need to do the port.  E On the other other hand, it does not surprise me that VMS engineeringrF find this turn of events interesting. They are, after all, programmersC and this is a fine opportunity for them to get to do some extensive C programming - particularly in parts of the OS that they may not get D to mess with much. So they get to fiddle while everyone else wonders if Rome is burning.r   --- Carl   ------------------------------    Date: 27 Jun 2001 02:06:39 -0500+ From: young_r@encompasserve.org (Rob Young)u' Subject: Re: Question to Charlie Matco.l3 Message-ID: <njouO4LeWBAF@eisner.encompasserve.org>'  R In article <9hbrrf$24p$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes: >    > ; > Can this truly be the same Rob Young who has made so manynN > admiring-to-the-point-of-adulation statements about future Alpha performanceI > (especially in comparison to future IA64 performance) for lo these manygK > years?  Are we witnessing a deathbed conversion (so to speak - I hope not-
 > literally)?- >   > 	Absolutely the same Rob Young.  Searching for the disconnect?  ? 	As you know, the 6000+ emails in my inbox and outbox have beenr< 	kicking around Compaqction stuff over the last 18 months or/ 	so.  How many of them from me regarding Linux?8  : 	The problem is Dell.  If Dell didn't exist, Compaq and HP; 	would be fat dumb and happy.  Because of Dell , PC marginsa> 	are suicidal and Server margins are heading there.  Compaq is? 	forced to become IBM.  Compaq is anticipating growing services[ 	40%, or so they say.s  @ 	Ditching Alpha is radical.  Sometimes with cancer , you lop offA 	a breast (can I say tit or will the nasty scanner get me again?)h   	Enough being cutesy.t  A 	My hope had been that EV8 would be far enough above the fray ande? 	radical enough to make it all worthwhile.  I think the problemaB 	is that the 200K+ tpmC target market is too small for that, mabyeC 	that is an over simplification.  But someone was looking 3-4 years 0 	out and attempting to decide what it all means.  > 	I love my Alpha architecture and alpharob as an email address? 	will be a neat keepsake in a few years :-).  But hey, what ared* 	you going to do?  VMS is VMS is VMS.  :-)    F > Rather than accept the conventional-wisdom-de-jour, I prefer to baseI > projections on more stable data.  And the only part of that data that's L > changed very recently is Compaq's platform of choice for VMS, which reallyK > has no impact on my belief that Alpha would have been likely to enjoy *atnI > least* a modest lead over Itanic for many years - based on the relative N > strengths and projected directions of the architectures, and largely throughL > reading the conclusions of people better able to evaluate those than I am. >   H 	Yeah, modest lead.   And I think that is where the shouting took place.D 	But someone must have said, "you will be in so much trouble 4 years, 	from now, you'll be like Sun Microsystems."  = 	This future strategy stuff is very very difficult I am sure.w= 	That is why I am/was so hot and heavy on to the Linux angle."; 	Tacking in IBM's wake there... let IBM spend the money and-* 	pick off the crumbs.  The Linux API, etc.   				Robz   ------------------------------  % Date: Wed, 27 Jun 2001 02:54:00 -0400-' From: "Bill Todd" <billtodd@foo.mv.com>3' Subject: Re: Question to Charlie Matco.w( Message-ID: <9hbvnv$7g7$1@pyrite.mv.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:njouO4LeWBAF@eisner.encompasserve.org....   ...   ; > The problem is Dell.  If Dell didn't exist, Compaq and HP < > would be fat dumb and happy.  Because of Dell , PC margins? > are suicidal and Server margins are heading there.  Compaq isb@ > forced to become IBM.  Compaq is anticipating growing services > 40%, or so they say. >sA > Ditching Alpha is radical.  Sometimes with cancer , you lop offhB > a breast (can I say tit or will the nasty scanner get me again?)  K Yeah, but usually the one with the cancer (the PC space, for Compaq) ratheraG than the healthy one (the non-PC space, despite absymal neglect in manym areas).o   ...e  H > > Rather than accept the conventional-wisdom-de-jour, I prefer to baseK > > projections on more stable data.  And the only part of that data that'stG > > changed very recently is Compaq's platform of choice for VMS, whichs reallyI > > has no impact on my belief that Alpha would have been likely to enjoy- *at K > > least* a modest lead over Itanic for many years - based on the relativecH > > strengths and projected directions of the architectures, and largely throughDJ > > reading the conclusions of people better able to evaluate those than I am.  > >s >i > Yeah, modest lead.  L What I said above was "*at least* a modest lead":  that's assuming that IA64J continued to find as-yet-unidentified performance potentialities (comparedL with Alpha's much-better-defined ones) so that it could keep within shouting	 distance.e  G That's the worst-case scenario for Alpha:  better performance against a:C competitor of comparable price (Intel doesn't lower prices, it justnI assumes - correctly in the case of IA32 - that enough people will buy its J products at price-parity and even some price/performance disadvantage thatA its maximum profit point is at less than 100% market share).  ThetD *best-case* scenario for Alpha is *far* better performance against aI competitor who never grabbed the expected market share because Alpha (andsE Power, and even SPARC) stood up rather than caved in before the fightt started.  I As I said elsewhere, it's really reminiscent of DEC's VMS -> NT migration K strategy:  NT's dominance of the world was perceived as inevitable, and DECeL acted accordingly.  But the past 5 or 6 years haven't followed anything likeJ the expected path (no thanks to DEC and Compaq, but SUN and Linux and evenL IBM get a lot of credit), and if DEC had acted differently 7 or so years agoK (by effectively deploying VMS down into the low-mid-range and supporting itsI *actively*) we wouldn't be talking about Compaq, or NT, or IA64 today (atd< least in any manner of significance to DEC, VMS, and Alpha).  J DEC took the 'safe' ("God!  Don't bet the company!  Just go along and pickI up the crumbs.") way out back then, just as Compaq is now.  I suspect thel results will be similar.   - bill   ------------------------------  % Date: Wed, 27 Jun 2001 10:36:07 +0100m% From: Alan Greig <a.greig@virgin.net> ' Subject: Re: Question to Charlie Matco..8 Message-ID: <qj9jjt08i7so7gm01fuqosuv0030u6baef@4ax.com>  D On 27 Jun 2001 01:10:03 -0500, young_r@encompasserve.org (Rob Young) wrote:  B >	Nonesense.  Part of the rationale behind Alpha getting set aside? >	was a careful study of where IA64 will be in 3-5 years.  They=C >	concluded the performance differential will be marginal.  You canyA >	call into question that reasoning... but you can bet they spent   F Call it into question? You are the one who rammed down our throats how? superior Alpha was  and kept pointing us at all the Compaq (and:E others) white papers which proved this. Thus you insisted Alpha wouldcE never be dropped and anybody believing it would must be nuts. You are D the one who insisted NSK would never be on IA64. You are the one who6 insisted an IA64 VMS port would be next to impossible.    N >> Imagine if the a "pentium bug" crops up on IA64 next week and makes the big	 >> news.   >PB >	Yeah, imagine that.  Imagine if a meteor hits the Ross Ice Shelf> >	melting it and people in Flordia drown because of that.  Or = >	imagine if a new virulent virus pops up that makes HIV looke >	like a cold... imagine that.  ; Just a few weeks ago you would have probably used the IntellE reliability issue against the IA64. Now you ridicule this argument, IoA wish you would back off slightly here. I know we have to find theMC positives so please don't irritate me enough to dredge through your F old postings and throw them all back in your face. You were one of the9 most anti IA64 posters in this group until very recently.s    > >	promising us it gets much better and IDF in February shockedC >	a few people when they found out how fast McKinley will be going.t  C When I posted just this question about Mckinley you ridiculed it asr  well. Now it's all wonderful eh?  A >	Who knows about Madison?  Problem was/is for all others is thatgA >	Intel is far too strong.  It is almost as if many are forced toe> >	adopt their architecture because they surely can't afford to@ >	spend the money to compete against them.  Very few precedents , >	like that in the world... very few indeed. >.0 Now that is something I can entirely agree with!     >				Rob   -- Alan   ------------------------------  % Date: Wed, 27 Jun 2001 09:28:10 +0100e% From: Alan Greig <a.greig@virgin.net>t Subject: Re: Rdb troll8 Message-ID: <d36jjt4hanp5taokajk4bujoqdfpk6he7c@4ax.com>  D On 27 Jun 2001 00:58:21 -0500, young_r@encompasserve.org (Rob Young) wrote:  < >	I guess the assumption will be that everyone inside of VMSA >	engineering will be absolutely dead silent about the "non-port" ? >	of VMS to IA64?  Such that 6, 8, 12 months out no one outsidea, >	of VMS engineering will be none the wiser? >,? >	In other words, the bee-hive of activity involving the actualhA >	porting process will never take place and we won't know a thing  >	about that non-activity? >h6 >	Come on... surely you can do better than that for a   >	conspiracy theory.  Sheesh....  C Come off it Rob. Compaq could easily fund the port and then drop itpD before release. And  yes this does make sense if if Compaq's currentD intentions are damage limitation rather than a released port. Taking> Compaq's word on the matter is not helpful at this stage in my opinion.   >A >				Rob   -- Alan   ------------------------------  % Date: Wed, 27 Jun 2001 14:34:52 +0100   From: steven.reece@quintiles.com Subject: RE: Rdb trollH Message-ID: <OFAEFA4A7E.5AEE05EB-ON80256A78.004A66B2@qedi.quintiles.com>  $ I guess this really is a troll then.  I Personally speaking, I would doubt that RDB users would migrate to Oracle-E anything.  Oracle RDB has a large installed base with some very loyalLI customers.  I would expect that customers forced off of RDB would look at9D other offerings, including Ingres from that other wonderful software* company that dare not speak its name......   Doug Hipenbecker commented : >>>3J Oracle could care less as most Oracle RDB customers will migrate to OracleI RDBMS.  However, the same cannot be said about keeping the hardware branda! Compaq for the database platform.  <<<    ------------------------------    Date: 27 Jun 2001 10:39:32 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)  Subject: RE: Rdb troll3 Message-ID: <YPW89JnFx1N2@eisner.encompasserve.org>i   In article <DD11CB6FEB21D41184510004ACA3715304C906C8@mbsus228.mbc.com>, "Hipenbecker, Doug" <Hipenbecker.Doug@MBCO.COM> writes: M > I think the Compaq "Bliss on Windows" stance raises a valid suspicion abouto( > Compaq's true intentions with OpenVMS.  = Whereas I think "Bliss on Windows" was an excuse Oracle foundn> convenient when they wanted to get out of a business.  (I also= think it is a business they should not have been in - the Rdba8 strength is its tight coupling to the operating system.)  > Note that there is no supported Bliss on VMS, yet Oracle seems to be able to build Rdb.   ------------------------------    Date: 27 Jun 2001 08:38:01 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)e Subject: RE: Rdb troll, Message-ID: <6ko$ZEo1P2i9@malvm5.mala.bc.ca>  I In article <OFAEFA4A7E.5AEE05EB-ON80256A78.004A66B2@qedi.quintiles.com>, 0&     steven.reece@quintiles.com writes: > K > Personally speaking, I would doubt that RDB users would migrate to OraclenG > anything.  Oracle RDB has a large installed base with some very loyal,K > customers.  I would expect that customers forced off of RDB would look ateF > other offerings, including Ingres from that other wonderful software, > company that dare not speak its name...... > F      Except that Oracle has several "incentives" to switch from Rdb to Oracle "classic":   I      Rdb licenses can be exchanged for Oracle Classic ( there are variouseK rules and conditions that apply to this, but in the best case scenario it'sy a direct swap at no cost ).   J      Oracle has released SQL*Net for Rdb, which allows Rdb databases to beM accessed via SQL*Net. This allows one to write a program which can use eithersB Rdb or Oracle as the back end simply by changing a connect string.  J     (Of course these first 2 also would facilitate a switch from Oracle toG     Rdb, but I don't Oracle expects many customers to want to do that )t  L      Oracle has a "standard edition" of Oracle classic which is much cheaperH than Oracle "Eneterprise edition" or Oracle Rdb. If you are running yourI database on a system with 4 or less processors and don't need some of theeK fancy features of Oracle this can cut your licensing cost by something likef 80%d  L    And, as you state, if the alternative vendor is the company that dare notJ speak its name I know I'd certainly choose the lesser of the two evils and do business with Oracle.   ------------------------------  # Date: Wed, 27 Jun 2001 17:49:31 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: Rdb troll1 Message-ID: <L0p_6.207$rc5.5565@news.cpqcorp.net>a  e In article <BMa_6.12311$qJ4.502287@ozemail.com.au>, "Phil Howell" <phowell@snowyhydro.com.au> writes:s  9 :The reason for Oracle not continuing development of Rdb8l< :for I86 processors was that Compaq would not support bliss.      AFAIK, Bliss for Windows NT.    A   Bliss compilers will be a requirement for the OpenVMS IPF port.   G :There is bliss in vms so to port it to IA64 they will need a compiler.v# :Can we expect a resurgence of Rdb?r  &   You'd have to ask Oracle about that.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Wed, 27 Jun 2001 15:05:42 GMTo& From: "Rich B." <richb500@hotmail.com>& Subject: ROSS GemBase on OpenVMS Alpha< Message-ID: <aDm_6.117336$v5.8869752@news1.rdc1.ct.home.com>  F I have a client running an order application from ROSS Systems.  It isJ written in GemBase.  We have a need for it to interface with IBM MQSeries.  H 1) Is it possible for them to call external C functions from GemBase and) pass parameters to and from the routines?   J 2) If so, what is the GemBase keyword for doing this (I need to know where to send them in the docsets?)n  I 3) They have told me that they do not believe that it is possible to calliH external routines, but they can invoke DCL commands (some CLI call) thatJ spawn a subprocess to execute... This would be an OK workaround if we haveL to use it, but with this CLI routine, can you pass parameters and/or command< qualifiers to the call? They have indicated that you cannot.   Thank you in advance,c -Richr   ------------------------------  % Date: Wed, 27 Jun 2001 11:48:55 -0400 0 From: "Syltrem" <syltrem@videotron.ca.spammenot>* Subject: Re: ROSS GemBase on OpenVMS Alpha5 Message-ID: <Ofn_6.40102$TW.201962@tor-nn1.netcom.ca>F  L That was a long shot. Probably not a lot of people are using Gembase. BTW it also runs on other platforms.g  H You can use the CALL statement to call a 3GL external program. They mustF also declare the routine with EXTERNAL statement in their DML program.I I have not done it yet so I can't say for sure but from what I coule read,H the 3GL program really should be a function returning a status code as a	 longword.   E Then you have to build a shared image with your routine in there. ThenG EXTERNAL statement (mentionned above) indicated the name of this sharedg  image + the name of the routine.  H That's fairly simple, especially if you are familiar with the concept of shared images.   --   Syltrem ; http://pages.infinit.net/syltrem (OpenVMS related web site)h    > "Rich B." <richb500@hotmail.com> a crit dans le message news:1 aDm_6.117336$v5.8869752@news1.rdc1.ct.home.com... H > I have a client running an order application from ROSS Systems.  It isL > written in GemBase.  We have a need for it to interface with IBM MQSeries. > J > 1) Is it possible for them to call external C functions from GemBase and+ > pass parameters to and from the routines?i >aL > 2) If so, what is the GemBase keyword for doing this (I need to know where > to send them in the docsets?)R > K > 3) They have told me that they do not believe that it is possible to call0J > external routines, but they can invoke DCL commands (some CLI call) thatL > spawn a subprocess to execute... This would be an OK workaround if we haveF > to use it, but with this CLI routine, can you pass parameters and/or command>> > qualifiers to the call? They have indicated that you cannot. >m > Thank you in advance,t > -Richn >f >u >i >s >e   ------------------------------  % Date: Wed, 27 Jun 2001 11:52:23 -0400 0 From: "Syltrem" <syltrem@videotron.ca.spammenot>* Subject: Re: ROSS GemBase on OpenVMS Alpha5 Message-ID: <9kn_6.40104$TW.201959@tor-nn1.netcom.ca>    I forgot your 3rd question:fF You can do whatever you like with CLI including passing parameters. ToD receive parameters you would have to define logical names within theL subprocess and retrieve the values with the GET_SCV function (I think that's
 the name).   --   Syltremm; http://pages.infinit.net/syltrem (OpenVMS related web site)P    > "Rich B." <richb500@hotmail.com> a crit dans le message news:1 aDm_6.117336$v5.8869752@news1.rdc1.ct.home.com...iH > I have a client running an order application from ROSS Systems.  It isL > written in GemBase.  We have a need for it to interface with IBM MQSeries. >yJ > 1) Is it possible for them to call external C functions from GemBase and+ > pass parameters to and from the routines?  >dL > 2) If so, what is the GemBase keyword for doing this (I need to know where > to send them in the docsets?)l >rK > 3) They have told me that they do not believe that it is possible to calleJ > external routines, but they can invoke DCL commands (some CLI call) thatL > spawn a subprocess to execute... This would be an OK workaround if we haveF > to use it, but with this CLI routine, can you pass parameters and/or command > > qualifiers to the call? They have indicated that you cannot. >a > Thank you in advance,  > -Richt >  >  >  >y >r   ------------------------------  % Date: Wed, 27 Jun 2001 12:58:24 -0300i) From: fabio_compaq@ep-bc.petrobras.com.brn* Subject: Re: ROSS GemBase on OpenVMS AlphaL Message-ID: <OF4AF9486F.94E19FAE-ON03256A78.0057A39D@ep-bc.petrobras.com.br>  6 Petrobras still using GEMBASE and probalbly we will be= using for a long time. I hope Ross at least port the softwaref1 to OpenVMS/Itanium ..... if Oracle port RDB too !    Fabio C.        A "Syltrem" <syltrem@videotron.ca.spammenot> em 27/06/2001 12:48:55o  < Favor responder a "Syltrem" <syltrem@videotron.ca.spammenot>             Info-VAX@Mvb.Saic.Come      * Assunto: Re: ROSS GemBase on OpenVMS Alpha    H That was a long shot. Probably not a lot of people are using Gembase. B= TW it also runs on other platforms.   H You can use the CALL statement to call a 3GL external program. They mus= t	F also declare the routine with EXTERNAL statement in their DML program.H I have not done it yet so I can't say for sure but from what I coule re= adH the 3GL program really should be a function returning a status code as = ag	 longword.s  E Then you have to build a shared image with your routine in there. The.H EXTERNAL statement (mentionned above) indicated the name of this shared=    image + the name of the routine.  H That's fairly simple, especially if you are familiar with the concept o= f  shared images.   --   SyltremM; http://pages.infinit.net/syltrem (OpenVMS related web site)     @ "Rich B." <richb500@hotmail.com> a =E9crit dans le message news:1 aDm_6.117336$v5.8869752@news1.rdc1.ct.home.com... H > I have a client running an order application from ROSS Systems.  It i= spB > written in GemBase.  We have a need for it to interface with IBM	 MQSeries.a >eH > 1) Is it possible for them to call external C functions from GemBase = andd+ > pass parameters to and from the routines?  >mF > 2) If so, what is the GemBase keyword for doing this (I need to know wheren > to send them in the docsets?)e >rH > 3) They have told me that they do not believe that it is possible to = callH > external routines, but they can invoke DCL commands (some CLI call) t= hataH > spawn a subprocess to execute... This would be an OK workaround if we=   haveF > to use it, but with this CLI routine, can you pass parameters and/or commandu> > qualifiers to the call? They have indicated that you cannot. >i > Thank you in advance,  > -Richa >  >a >  >u >g             =t   ------------------------------  % Date: Wed, 27 Jun 2001 11:56:42 -0400h+ From: John Eisenschmidt <jeisensc@aaas.org> * Subject: Re: ROSS GemBase on OpenVMS Alpha# Message-ID: <sb39ca0e.062@aaas.org>a  K We use Ross Classic here. Our conversion to Ross RenCS was ... a failure, = G so I'm sorry but I can't help on that. They still have over 100 RenCS =o/ developers working there - have you asked them?y   http://www.rossinc.con=20n  I >>> "Syltrem" <syltrem@videotron.ca.spammenot> 06/27/2001 11:48:55 AM >>>aK That was a long shot. Probably not a lot of people are using Gembase. BTW =t it also runs on other platforms.e  H You can use the CALL statement to call a 3GL external program. They mustF also declare the routine with EXTERNAL statement in their DML program.I I have not done it yet so I can't say for sure but from what I coule readiH the 3GL program really should be a function returning a status code as a	 longword.   E Then you have to build a shared image with your routine in there. ThehG EXTERNAL statement (mentionned above) indicated the name of this sharedi  image + the name of the routine.  H That's fairly simple, especially if you are familiar with the concept of shared images.   --   Syltrem*; http://pages.infinit.net/syltrem (OpenVMS related web site)a    @ "Rich B." <richb500@hotmail.com> a =E9crit dans le message news:1 aDm_6.117336$v5.8869752@news1.rdc1.ct.home.com...uH > I have a client running an order application from ROSS Systems.  It isD > written in GemBase.  We have a need for it to interface with IBM =	 MQSeries.- >-J > 1) Is it possible for them to call external C functions from GemBase and+ > pass parameters to and from the routines?e >tH > 2) If so, what is the GemBase keyword for doing this (I need to know = where0 > to send them in the docsets?)r >oH > 3) They have told me that they do not believe that it is possible to = callJ > external routines, but they can invoke DCL commands (some CLI call) thatI > spawn a subprocess to execute... This would be an OK workaround if we =	 haveF > to use it, but with this CLI routine, can you pass parameters and/or commando> > qualifiers to the call? They have indicated that you cannot. >w > Thank you in advance,a > -Rich  >p >( >: >t >s   ------------------------------  % Date: Wed, 27 Jun 2001 08:55:36 -0400d( From: "Thomas Steuver" <steuver@nku.edu>1 Subject: Re: Software to create PDF files on OVMSn/ Message-ID: <tjjlva3blcno5b@corp.supernews.com>    Craig,  K Thanks for the reply. I did the steps you listed below for the .tgz versionp and I get the following error:  . Can't locate strict.pm in @INC (@INC contains:! perl_root:[lib.VMS_AXP.5_00503] peJ erl_root:[lib] perl_root:[lib.site_perl.VMS_AXP] perl_root:[lib.site_perl] .) atn txt2pdf.pl line 15.s8 BEGIN failed--compilation aborted at txt2pdf.pl line 15. %RMS-E-FNF, file not found  @ This is the same error message I got when I tried the .zip file.  K I also tried the C version and got a bunch of errors during the compile. DoI8 you have the .exe file for Alpha that you could send me?  
 Thanks again,  Tome  A "Craig A. Berry" <craigberry@DELETETHIS.mac.com> wrote in messageu2 news:5.1.0.14.0.20010626124847.02a596a0@exchi01...5 > "Thomas Steuver" <steuver@nku.edu> wrote in messagec+ news:<tjf2i717r2lk56@corp.supernews.com>... G > > I've downloaded txt2pdf 5.0.  I have Perl 5 installed on my OpenVMSs (Alpha)tI > > system.  The VMS doc file included with txt2pdf is bad.  I can't makefG > > anything work.  Does anyone have an easier procedure to get txt2pdfa workinge > > on the OVMS system?i >lL > What does "can't make anything work" mean?  Did you get error messages?  IK > just tried it and it seemed quite simple.  You do need gunzip and vmstar,eJ > both on the freeware CD I believe.  (If you download the zip version forG > Windows, the line breaks will probably be wrong for VMS.)  I followed- these- > steps: >e > Download txt2pdf.tar.gz from9 >         <http://www.sanface.com/archive/txt2pdf.tar.gz>b >o1 > rename to txt2pdf.tgz to avoid invald file spec@ >. > $ gunzip txt2pdf.tgz > $ vmstar -xf txt2pdf.tar > $ set default [.TXT2PDF-5_0]' > $ perl txt2pdf.pl sys$login:login.com  >rH > I then had a file called login.pdf in my login directory, which indeedL > turned out to be a valid PDF version of my login.com, suitable for viewingJ > with XPDF under DECWindows or Acrobat Reader on other platforms.  I have noH > idea how good the documentation is since I didn't bother to look at it :-). >eL > This was with Perl 5.5.3, though I suspect it'd work with any version Perl 5. >bJ > You do have to define the logical name TXT2PDFCFG to to make it find the configuration file ifn< > you're not running from the directory where txt2pdf lives. >mL > Someone mentioned the C freeware txt2pdf by P.G. Womack (confusingly namedK > the same but not related to the Sanface product).  I just tried it and itsI > worked great, though it doesn't have any of the spiffy features Sanface-J > does.  The Womack version doesn't do any argument handling so you'd have to > invoke it something like:e >g0 > $ pipe mcr []txt2pdf < myfile.txt > myfile.pdf >u   ------------------------------  % Date: Wed, 27 Jun 2001 11:58:38 -0500,3 From: "Jay E. Morris" <morris@thorin.brooks.af.mil>-. Subject: StorageWorks MSL 5026SL Tape Library+ Message-ID: <9hd3qg$1c$1@leo.brooks.af.mil>   I Ok, looks like we might be going to 2 shifts which means that I've got touK reduce my nightly backup time.  I've already played all the software trickstI (block size, quotas, etc) so I've got to go to a faster drive.  CurrentlyaJ using a TZ88 that we swap tapes in everyday.  The backup of the productionI databases take about 3+ hours for about 50GB.  Yes, we run verify.  These L are Mumps databases so we have to take the production software down. BecauseL of the increased workload we're expecting I think the databases will grow toG about 80-100GB.  The TZ88 ain't gonna cut it.  There's bunches of batchnL processing that has to occur after backup and before 1st shift.  Rest of theG backup can take all day far as I'm concerned, as long as the productionl system is back up in time.   I'm runing:c, AlphaServer 2100 (no, I didn't forget the A), AlphaServer 1000 (no, I didn't forget the A) RA3000 OpenVMS 7.2-1 (7.3 rsn)nJ The Alphas have the QLogic ISP1020 SCSI which are connected to the RA3000.  I have KZPBA-CX cards available.  K So I'm thinking about using the StorageWorks MSL 5026SL Tape Library with 1aI drive (mainly because of the throughput but size counts).  So I'm looking  for:  $ Good/bad experience with this thing.L Is it going to work with this setup (I'm a little confused because the specsD for the SDLT drive itself shows the KZPBA but the library only shows3 3X-KZPEA-DB and this won't work in the 1000/2100*.)6 Other backup suggestions.   L *but if the drive itself works with the KZPBA then I may still be stuck with8 changing tapes.  Or use it as an excuse for a new Alpha.  
 Jay E. Morrisg, System Software Specialist (Sys/Net Manager) General Dynamics, WTSt! Lead, Medical Information Systemsl8 Epidemiological Surveillance Division (AFIERA/SDE (MIS)) Brooks AFB, TX   ------------------------------    Date: 27 Jun 2001 05:17:33 -0700# From: dooleys@snowy.net.au (dooley)" Subject: Re: TCL in OpenVMSe= Message-ID: <1ca82fc6.0106270417.7765c699@posting.google.com>l  c "Sundaram P" <sundaramp@hotmail.com> wrote in message news:<quNZ6.123$rc5.4605@news.cpqcorp.net>...y > Hi,e > 5 > I wrote a c program to create a new command in TCL.f > $ > The source for which is as follows > N > ************************************************************random.c********9 > *******************************************************n >  > #include "tcl.h" >  > #include <stdlib.h>i > G > int RandomCmd(ClientData clientData,Tcl_Interp *interp,int argc, chare > *argv[]);  > % > int Myrand_Init(Tcl_Interp *interp)d >  > {  > ? > Tcl_CreateCommand(interp, "rand", RandomCmd,(ClientData)NULL,n > (Tcl_CmdDeleteProc *)NULL);n >  > return TCL_OK; >  > }w > G > int RandomCmd(ClientData clientData, Tcl_Interp *interp,int argc,chare
 > *argv[]) >  > {c >  > int rand, error; >  > int range = 0; >  > if (argc > 2) {a > + > interp->result = "Usage: random ?range?";p >  > return TCL_ERROR;e >  > }h >  > if (argc == 2) { > 6 > if (Tcl_GetInt(interp, argv[1], &range) != TCL_OK) { >  > return TCL_ERROR;, >  > }0 >  : > }  >  > rand = random(); >  > if (range != 0) {o >  > rand = rand % range; >  > }g > & > sprintf(interp->result, "%d", rand); >  > return TCL_OK; >  > }. > N > ************************************************************random.c********9 > *******************************************************I > 9 > I created a shareable image using the following commandI > 2 > link random,myrand.opt/opt /shareable=myrand.exe >  > where myrand.opt isM > N > ************************************************************myrand.opt******; > *********************************************************  >  > tclshr/shareable > ; > symbol_vector=(Myrand_Init=Procedure,RandomCmd=Procedure)- > N > ************************************************************myrand.opt******; > *********************************************************n >  >  > B > But when i load the exe in the tcl shell using the load command. >  > load myrand.exe myrand > A > the tcl shell is crashing and the following error is displayed.  > N > ************************************************************systemerror*****< > ********************************************************** > * > %SYSTEM-F-IVLOGNAM, invalid logical name > 1 > %TRACE-F-TRACEBACK, symbolic stack dump followse > ) > image module routine line rel PC abs PCI > % > 0 FFFFFFFF80476818 FFFFFFFF80476818u > F > TCLSHR TCLVMSLOAD TclLoadFile 7431 00000000000001AC 000000000008AABC > C > TCLSHR TCLLOAD Tcl_LoadCmd 4535 0000000000000458 00000000000849C8o > A > TCLSHR TCLBASIC Tcl_Eval 8251 00000000000015D4 000000000008E574e > L > TCLSHR TCLHISTORY Tcl_RecordAndEval 7239 0000000000000378 0000000000093778 > @ > TCLSHR TCLMAIN Tcl_Main 2665 000000000000056C 000000000009602C > > > TCLSH TCLAPPINIT main 1429 00000000000000B0 00000000000300B0 > = > TCLSH TCLAPPINIT __main 0 000000000000005C 000000000003005C  >  > 0 FFFFFFFF87BA53D4 FFFFFFFF8 > N > ************************************************************systemerror*****< > ********************************************************** > / > The help /message command gives the followingA > F > ************************************************************Help forF > Error*************************************************************** >   > IVLOGNAM, invalid logical name > # > Facility: SYSTEM, System Servicesa > K > Explanation: A name string exceeds the maximum length permitted, or has aM > = > length of 0, or is longer than the specified maximum length  > @ > logical name string, table name string, or equivalence string. > : > Logical names are limited to a length of 255 characters; > ; > global section names are limited to 43 characters; common( > = > event flag, process names, and cluster names are limited toa > > > 15 characters. An error can be returned when a name table is > > > defined and the name for the new name table contains invalid > 
 > characters.s > H > User Action: If the error occurs during command processing, verify the > = > command. If the error occurs during execution of a program,e > > > check that the character string descriptors pointing to name > ' > strings indicate the correct lengths.e > F > ************************************************************Help forF > Error*************************************************************** > $ > I'm using TCL7.5 on OpenVms 7.2.1. > ; > The same program works quite well in Tru64Unix . TCL v8.2  > : > when i create a shared image using the following command > , > cc -shared random.c -ltcl -lm -o myrand.so >  > Can somebody please help me. > 	 > regardsa > 
 > SundaramC vms can get paranoid about shared images that it doesn't know abouta) try either copying the image to sys$shares- or define an executive mode logical name likeo0 $define/sys/exec myrand mydisk:[mydir]myrand.exe Phil   ------------------------------  , Date: Wed, 27 Jun 2001 13:31:07 +0200 (CEST): From: "Gotfryd Smolik, VMS lists" <gotfryd@stanpol.com.pl>: Subject: Re: The death of VMS has been greatly exaggeratedJ Message-ID: <Pine.LNX.4.21.0106271322310.15007-100000@irys.stanpol.com.pl>  & On 26 Jun 2001, Malcolm Dunnett wrote:  2 >+In article <tji3n47ge8e60b@news.supernews.com>, - >+    "John Vottero" <John@mvpsi.com> writes:e >+> C >+> 32 bit processors are a dead end for general purpose computing.v >+C >+    Which problem in particular do you see 32bit processors being  >+inadequate for?p  @  Some popular-graphics operation (inluding e-photo) and at least real-time video.9 FYI: last weekend have do something in the category on my@8  friends, and 1/8 GB RAM looks like something too small.  > >+                Will those problems need to be solved by the" >+average desktop system customer?   *DEFINITELY*7  The time you think that home PC has lower "comp-power"u! then b.ex. office one was before.r9  Today's at least part - but *the* part buys the high-end 7 (read: costly) hardware - require (or at least ask) for 6 something where see 2..4 GB architecture is a barrier.9  Resolution (available in X86) like "composition address" 5 makes more problem that resolves; segmentation can bes, a nightmare, non-flat paged area the same...    Regards - Gotfryd   -- wE =====================================================================aF $ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") - 		THEN EXCUSE/OBJECT=MEa. $!                        GS@stanpol.zabrze.plE =====================================================================:   ------------------------------    Date: 27 Jun 2001 09:40:42 -0500- From: koehler@encompasserve.org (Bob Koehler)4: Subject: Re: The death of VMS has been greatly exaggerated3 Message-ID: <koBxgZHscqX4@eisner.encompasserve.org>l  \ In article <3B390D63.35E0165B@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes:  I > 1-VMS is not a strategic product. It is there only because it generates.	 > profitse  H I'm sure we all would run out own businesses our own way, but in my book+ "generates profits" IS a startegic product.e  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporationl= NASA GSFC Flight Software       | Federal Sector, Civil GrouptE                                 | please remove ".aspm" when replyingw   ------------------------------    Date: 27 Jun 2001 09:42:05 -0500- From: koehler@encompasserve.org (Bob Koehler)=: Subject: Re: The death of VMS has been greatly exaggerated3 Message-ID: <rt881zrRvI8O@eisner.encompasserve.org>o  X In article <3B392528.A01C7435@infopuls.com>, Christof Brass <brass@infopuls.com> writes: > A > While there is some truth in your observation it lacks the main.> > difference: All the other migrations include an HW emulationA > (i.e. a proof by technique) that almost all apps will run rightfB > there from the beginning. With the Alpha -> IA63 transition this > isn't the case.9  > There was no hardware emulation in the VAX -> Alpha migration.  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporation = NASA GSFC Flight Software       | Federal Sector, Civil GroupmE                                 | please remove ".aspm" when replyingo   ------------------------------  % Date: Wed, 27 Jun 2001 15:54:39 +0100o% From: Alan Greig <a.greig@virgin.net>s: Subject: Re: The death of VMS has been greatly exaggerated8 Message-ID: <t6sjjt4kh6ivv118k0l5msq9rfl5ve8ujk@4ax.com>  @ On Tue, 26 Jun 2001 10:47:25 GMT, system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) wrote:c  l >In article <qtSZ6.6051$P5.2432774@news1.rdc1.tn.home.com>, "Alphaman" <alphaman64@nixspam-home.com> writes:
 >{...snip...}oI >>Compaq management LACK.  Compaq will go down in history as the PC clone C >>manufacturer that was handed a golden opportunity and botched it.t >  >Hear hear!!!  -  E I'm in fantasy land here but I'm waiting for the CNN interview in tencF years time where Winkler when asked: "Who could have predicted in 2000E that VMS not Windows would dominate the market." and Winkler replies:oE "(laughs) And we came within a few months of killing it off back thenh' too but I found religion just in time."C  F You can read all or nothing into Winkler's cryptic email to me of justF a few months ago saying "regarding VMS I have found religion". For theF moment I'm going to take that at face value. Note he did not say to me* "regarding Alpha I have found religion"...  D If Winkler is really the brains behind Compaq it is his head we need to get inside.  C I consider much of what has happened up to now to be a disaster butaC assume they stay on course. In a couple of years time we could haveu< the leading desktop/server manufacturer and the leading chip= manufacturer with the best OS (VMS of course) perhaps jointlyaE promoted, Was it an accident that Capellas' memo talks about VMS thenn< immediately says "compelling linux strategy". A bullet proofA commercial OS pushed by both Compaq and Intel that could also runi: Linux ABI code *might* just grab significant market share.  B Despite Winkler's subservience to Microsoft I suspect he'd love toD fight them after years of kneeling but only if there was a chance of success,  C Alternately Compaq might not exist as such in two years, Six monthsp; from now there will be enough signs to conclude either way.  -- Alan   ------------------------------  % Date: Wed, 27 Jun 2001 12:14:55 -0400h% From: "John Vottero" <John@mvpsi.com>m: Subject: Re: The death of VMS has been greatly exaggerated/ Message-ID: <tjk1j99u64spe1@news.supernews.com>   > "Malcolm Dunnett" <nothome@spammers.are.scum> wrote in message& news:MFVbm5gV2I4b@malvm5.mala.bc.ca...1 > In article <tji3n47ge8e60b@news.supernews.com>,n- >     "John Vottero" <John@mvpsi.com> writes:s > >LC > > 32 bit processors are a dead end for general purpose computing.w >aC >     Which problem in particular do you see 32bit processors being > > inadequate for? Will those problems need to be solved by the" > average desktop system customer? >   L It's not that all (or even many) problems need more than 32 bits.  It's thatJ most computers are used to do more than one thing.  A 32 bit chip can onlyG address 4GB of RAM.  Every day another pointy haired boss says "Tell megJ again why I can't put more than 4GB of RAM in the server.", "Can't we just" by machine with more DIMM slots?".  H In a few years, we'll all be wondering how we ever got by with less than 64GB of RAM.   ------------------------------  % Date: Wed, 27 Jun 2001 12:17:34 -0400[% From: "John Vottero" <John@mvpsi.com>i: Subject: Re: The death of VMS has been greatly exaggerated/ Message-ID: <tjk1o8gvn8e028@news.supernews.com>   : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B394270.6AD34733@videotron.ca... > John Vottero wrote:nJ > > bits by Intel (AMD is trying though).  Intel effectively announced the endoL > > of life of IA32 when they announced IA64.  It will be a long time before; > > they stop manufacturing IA32 but it's still a dead end.0 >9D > When Digital embarked on the ALpha project, we knew that VAX woudl
 eventuallyK > be retired. But Digital continued developpement of VAX for quite a while,P and G > afterwards continued to build systems based on VAX chips built in oned largexG > batch. The official word on the decommisionning of VAX was last year.i >pJ > We know that IA32 will eventually be history, but it is not history yet. PCH > makers are still making it, intel is still fabbing it and I would very much= > doubt that new faster 8086s aren't already in the pipeline.   J I completely agree, that's the point I was trying to make.  IA32 is in theG same position that VAX was in.  Everyone knows it's a dead-end but it'ss unknown how far the road goes.   ------------------------------  % Date: Wed, 27 Jun 2001 13:00:41 -0400b- From: JF Mezei <jfmezei.spamnot@videotron.ca>i: Subject: Re: The death of VMS has been greatly exaggerated+ Message-ID: <3B3A1136.834D23F@videotron.ca>l   Bob Koehler wrote:J > I'm sure we all would run out own businesses our own way, but in my book- > "generates profits" IS a startegic product.r  M Not if you do not see this as your core competency and not if you beleive thea5 product won't be generating profits in the long term.o   ------------------------------    Date: 27 Jun 2001 09:46:46 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)o: Subject: Re: The death of VMS has been greatly exaggerated, Message-ID: <O2J2uOVSjkfB@malvm5.mala.bc.ca>  0 In article <tjk1j99u64spe1@news.supernews.com>, *    "John Vottero" <John@mvpsi.com> writes: > N > It's not that all (or even many) problems need more than 32 bits.  It's thatL > most computers are used to do more than one thing.  A 32 bit chip can onlyI > address 4GB of RAM.  Every day another pointy haired boss says "Tell me L > again why I can't put more than 4GB of RAM in the server.", "Can't we just$ > by machine with more DIMM slots?". > F     It's not so much the server market I was addressing as the desktopQ market. How many desktop systems need more than 4GB? Most of ours are doing quiteoM nicely with 128MB, maybe 256MB for the "power users". I certainly expect thatqR to grow, but I don't see any major need for more than 32bits on the desktop in the9 next 5 years or so ( ie no big rush to EOL the Pentium ).a   ------------------------------  % Date: Wed, 27 Jun 2001 18:00:01 +0000o3 From: "Atom e-City Ltd." <webmaster@translaweb.com>t Subject: Translation Services 7 Message-ID: <20010627180001.10780.qmail@translaweb.com>r   Dear Sir or Madam,  , For your translation needs, choose the best!  F Call for qualified translators all over the world through our transla= tion agency.  F Atom e-City is specializing in Software Localization in different lan=F guages. So far, we have worked on many IT related topics, especially =$ =66rom English into French, such as:  % - Lotus Notes & Domino Server manuals 1 - Microsoft manuals and online training documentsmF - JDEdwards software localization (related to warehouses flows manage= ment) 3 - BNP-Paribas (secured networks audits & documents)0; - Soci=E9t=E9 G=E9n=E9rale Group (IT Purchasing agreements)0F - many other files and manuals dealing with ASP, Perl, C++ and other =0 languages, UNIX Servers, network, printing, etc.  F Take advantage of the Internet and contact us for a FREE ESTIMATE bas=( ed on your documents, files or web site.  F We deal with a wide range of formats and we can provide almost any fo=F rm of localization for your software, games, manuals, trade presentat=
 ions, etc.  F We ensure high quality translations performed by the most highly skil=7 led translators, each working into their mother tongue.v  F Just contact us to access all the available languages and specialisat= ions!   F Check out our web site to consult our complete list of services and C=: OMPETITIVE RATES and request a FREE and accurate estimate:4 http://www.translamail.com/cgi-bin/aec.cgi?index%2CE  F Besides, for your business letters, e-mail messages and any plain tex=F t documents, make the most of our dynamic translation system to recei=& ve your translation in less than 12h !1 Visit Translamail at : http://www.translamail.como  F Our procedure for handling urgent projects is unrivalled thanks to ou=F r internally developed ordering application, which removes all delays=F  caused by intermediaries, so that your documents are sent directly t=% o the translators and your recipient.*  F Join the many clients who have faith in the Quality of our services a=B nd, like them, benefit from the best translations at a fair price!    F If you do not wish to receive e-mail promotions from us, just click b= elow:iF http://www.translaweb.com/cgi-bin/unsubscribe.cgi?Info-VAX@Mvb.Saic.C= om   ------------------------------  % Date: Wed, 27 Jun 2001 12:59:34 -0400n" From: "Hal Kuff" <kuff@tessco.com>. Subject: USer Record in Accounting File - HOW?O Message-ID: <F6C8DF1CE6742FCF.DD966B67C89EF423.7D6F7002BC914310@lp.airnews.net>   K I'm looking for some sample code (VMS-BASIC) would be nice to send a recordeH to the accounting file... looks like $SNDJBC, but don't seem to see what item list needs to be built....f   ------------------------------    Date: 27 Jun 2001 05:37:18 -0700  From: alanb@cloud9.net (Alan B.)0 Subject: Re: VMS 7.3/Alpha boot bugcheck problem< Message-ID: <88599d89.0106270437.32c132c@posting.google.com>   "Koska, John C. (LNG-MBC)" <John.C.Koska@lexisnexis.com> wrote in message news:<3D35AD137AAAD411A6BA0008C7B1B12D01602160@MBCALBEXC03.BENDER.COM>...* > > -----Original Message-----G > > From: Jean-Francois Marchal [mailto:jean-francois.marchal@x9000.fr] ( > > Sent: Monday, June 25, 2001 12:40 PM > > To: Info-VAX@Mvb.Saic.Como4 > > Subject: Re: VMS 7.3/Alpha boot bugcheck problem > >  > > 5 > > woulnt't it be an allocation class = 0 question ?* > > Jean-Franois Marchal* > > X9000 - LYON (FR)b > >  > D > The Compaq OpenVMS folks thought of that, and dialed in to take a E > look at my system to confirm for themselves.  The allocation class *E > on the system of question is 1, so I do not believe this to be the  
 > problem. >  > :) jck     > John Koska > Matthew Bender & Co., Inc. -$ >   A Member of the LexisNexis Group > 1275 Broadwayn > Albany, NY  12204r > USAd > 518-487-3255 > John.C.Koska@lexisnexis.com* > , > "I post personal opinion only, and all the, > disclaimers one could imagine apply.  That* > includes, I speak for myself only and my, > views in no way represent my employer(s)."  D CPQ informs me that if system_check is not 0, 7.3 may bugcheck...per VMS engineering.   Alan   ------------------------------  % Date: Wed, 27 Jun 2001 09:43:28 -04000. From: "Kenneth Randell" <kenr@datametrics.com>0 Subject: Re: VMS 7.3/Alpha boot bugcheck problem+ Message-ID: <9hcnt1$46i$1@bob.news.rcn.net>0  L Well yes, setting SYSTEM_CHECK to 1 turns non-fatal (e.g., RMS, cmexec code)/ exceptions into fatal ones, among other things.l  @ They didn't happen to tell you WHY 7.3 would bugcheck, did they?   Ken Randell0  + Alan B. <alanb@cloud9.net> wrote in messageP6 news:88599d89.0106270437.32c132c@posting.google.com...K > "Koska, John C. (LNG-MBC)" <John.C.Koska@lexisnexis.com> wrote in message*I news:<3D35AD137AAAD411A6BA0008C7B1B12D01602160@MBCALBEXC03.BENDER.COM>...*  > > > -----Original Message-----I > > > From: Jean-Francois Marchal [mailto:jean-francois.marchal@x9000.fr]** > > > Sent: Monday, June 25, 2001 12:40 PM > > > To: Info-VAX@Mvb.Saic.Com*6 > > > Subject: Re: VMS 7.3/Alpha boot bugcheck problem > > >i > > >e7 > > > woulnt't it be an allocation class = 0 question ?t > > > Jean-Franois Marchale > > > X9000 - LYON (FR), > > >  > > E > > The Compaq OpenVMS folks thought of that, and dialed in to take a F > > look at my system to confirm for themselves.  The allocation classF > > on the system of question is 1, so I do not believe this to be the > > problem. > >t
 > > :) jck >t >; > > John Koska  > > Matthew Bender & Co., Inc. -& > >   A Member of the LexisNexis Group > > 1275 Broadwaya > > Albany, NY  12204m > > USAs > > 518-487-3255 > > John.C.Koska@lexisnexis.com  > >i. > > "I post personal opinion only, and all the. > > disclaimers one could imagine apply.  That, > > includes, I speak for myself only and my. > > views in no way represent my employer(s)." >tF > CPQ informs me that if system_check is not 0, 7.3 may bugcheck...per > VMS engineering. >e > Alan   ------------------------------  % Date: Wed, 27 Jun 2001 11:52:49 -0400o> From: "Koska, John C. (LNG-MBC)" <John.C.Koska@lexisnexis.com>0 Subject: RE: VMS 7.3/Alpha boot bugcheck problemM Message-ID: <3D35AD137AAAD411A6BA0008C7B1B12D01602167@MBCALBEXC03.BENDER.COM>    > -----Original Message-----2 > From: alanb@cloud9.net [mailto:alanb@cloud9.net]( > Sent: Wednesday, June 27, 2001 8:37 AM > To: Info-VAX@Mvb.Saic.Comd2 > Subject: Re: VMS 7.3/Alpha boot bugcheck problem >  > <SNIP> > F > CPQ informs me that if system_check is not 0, 7.3 may bugcheck...per > VMS engineering. >  > Alan  D Thanks for that tidbit.  I just checked what system_check was on my < 2100A.  It is at 0, so I believe the problem lies elsewhere.  J A this point, it does not appear to be allocation class, system_check, or G a fragemented system disk. (I did a backup/image and restore via tape, 1J and still have bugcheck when system disk is enabled for volume shadowing.)  F My thought is that there is some interaction between the Mylex DAC960 . controller and volume shadowing a system disk.  G I have sent a full system dumpfile to Compaq, so hopefully they will beh3 able to ascertain in some time what the problem is.    :) jck
 John Koska Matthew Bender & Co., Inc. -"   A Member of the LexisNexis Group
 1275 Broadwaym Albany, NY  12204  USAn 518-487-3255 John.C.Koska@lexisnexis.com   * "I post personal opinion only, and all the* disclaimers one could imagine apply.  That( includes, I speak for myself only and my* views in no way represent my employer(s)."   ------------------------------  % Date: Wed, 27 Jun 2001 12:51:00 -0400 2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: VMS on IA64L Message-ID: <rdeininger-2706011251000001@user-2ive7go.dialup.mindspring.com>  5 In article <3B38DEE0.EE77EBC4@videotron.ca>, JF Mezeie% <jfmezei.spamnot@videotron.ca> wrote:a   > Hoff Hoffman wrote:o > > J > >   I've had about twenty-four hours to (start to) come up to speed, and> > >   I'm off looking at architectural-level issues right now. > 
 > Mr Hoffman,= > P > What I would be interested in knowing is whether the current IA64 architectureH > has any show stoppers to prevent porting of VMS, and if so, what those > features are.=  I Hmm.  How much time will you allow Hoff for this evaluation?  The rest of- the day at least, I hope.9   ;-)-   -- r Robert Deininger rdeininger@mindspring.com    ------------------------------  # Date: Wed, 27 Jun 2001 11:14:51 GMTk. From: "Duane Sand" <duane.sand@mindspring.com>$ Subject: Re: VMS on IA64 (technical)@ Message-ID: <Lej_6.134407$%i7.90306133@news1.rdc1.sfba.home.com>  / "JF Mezei" <jfmezei.spamnot@videotron.ca> wroteeL > When VMS was ported to Alpha, they had to design the Alpha chip to support VMSuC > (both for booting, as well as special instructions and PAL code).- >-K > When Compaq decided to move NSK to Alpha, they had to change the Alpha to . > include that lock step stuff to support NSK. >AL > Does anyone know for sure whether IA64 could support both VMS and NSK "out ofH > the box" or would Compaq have to pay Intel megabucks to change IA64 to include I > the features needed to support VMS and NSK ? (obviously, they would usee Alpha  > as currency for payment).  > G > If VMS and NSK are to be ported on IA64 "as is", how much in terms ofo softwareA > engineering and reliability compromises might have to be made ?f  J No functionality compromises at all.  Total binary compatibility is always	 possible,.I at some performance level.  "Native" performance levels probably requires  sourceI recompilation; on NSK and Tru64 (and hopefully VMS) no application sourceg changes.  H McKinley and following iterations of IA64 already include one additional outputJ pin signal needed for our lock stepping.  Intel added this for Tandem, the
 first time we-I were porting Himalaya/NSK onto Merced (before Compaq acquired Digital andt Alpha).AI The bigger requirement for lock stepping a pair of chips is that the chip  internal? logic design be entirely deterministic and predictable, with no- ill-determined "don'teH care" signals and no hard-to-initialize internal state.  Intel says they design all theirK chips to that standard anyhow, because this also reduces the time needed tor	 test eacha: newly-fabbed die.  We shall see.  Lock-stepped systems are exquisitely-demandingnI chip testers.  Chip designers assume their designs are more deterministicn	 than they I actually are. With Mips, every chip generation had new problems to slowlym root outJ by testing.  Our use of EV7 hadn't reached that stage yet, but we probably	 did delaya? EV7's and EV8's logic designers somewhat.   (Sorry about that!)   K IA64's instruction set and address space and priv features are adequate forw NSK, Tru64,wI and very probably for VMS too; it was designed to support many commercialm operating systems.J IA64 comes with low-level noninterruptible millicode layers called PAL and
 SAL, quiteB similar to Alpha's PAL.   It's all documented (at great length) at
 Intel.com.  K IA64 code looks very bloated compared to Alpha, but that inefficiency won'tS	 matter ifnI Intel's future chips have much faster and bigger caches than anyone else.d And they will.I The first Merced/Itanium chip was very late and slow, earning lots of bada
 press, butJ this proves nothing about what subsequent Intel/HP teams may pull off.  We
 shall see.I Compiling well for IA64 is difficult and requires new engineering and newa	 research.cK Intel was hungry for Alpha's proven chip design talent and compiler talent.u  F Intel wanted neither the Alpha chip family nor Compaq's cash; just our
 talent and our switchover to IA64.l  I Compaq wants to preserve and grow all of its enterprise operating systemsoG customer bases far into the future with competitive leading-performancei systems.5 (You're more profitable for us than the PC division.)tI Who makes the core chip inside is not so important, as long as it is fastt andaK continues to grow faster at competitive rates.  In enterprise systems, whatp mattersnC more to you and us is software compatibility, functionality, systemo performance,E and assured long term futures.  We know how to arrange very practicale softwareL migrations when it becomes necessary, as proven by the migrations of VMS and NSKdI application bases ten years ago.  It's now becoming necessary again.  Thes revenuecJ from modest numbers of Alpha-based systems have never been enough to coverJ the increasing engineering costs of designing Alpha chips.  Not in Digital days,>K not now, and not in the future.   That dream had to end.  The only questionr was F when to face the pain and move onto something sustainable.  With Intel parts, the costsJ of sustained chip design progress will be shared across a vastly increased number of systems.r  <   -- Duane Sand,  (not speaking for) Compaq NonStop Division   ------------------------------    Date: 27 Jun 2001 10:38:52 -0500- From: koehler@encompasserve.org (Bob Koehler)a$ Subject: Re: VMS on IA64 (technical)3 Message-ID: <RX0w8ADYlmWU@eisner.encompasserve.org>   H Anyone care to guess if TECO will survive?  I understand TECO was VESTedF which turned up a lot of bugs in VEST.  That's not exactly the same as  having a portable source around.  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences CorporationT= NASA GSFC Flight Software       | Federal Sector, Civil GroupoE                                 | please remove ".aspm" when replying.   ------------------------------  % Date: Wed, 27 Jun 2001 15:56:13 +0100o  From: steven.reece@quintiles.com$ Subject: Re: VMS on IA64 (technical)H Message-ID: <OF0F7D5D3A.E9846988-ON80256A78.00518562@qedi.quintiles.com>   Christof commented : > Buildings.  6 That's what I referred to as a Property Portfolio. :-)     Paul Sture commented :9 >The comments about one building vs another in one of thed9 >Inquirer articles this weekend had me intrigued. I'm noti7 >familiar with the significance of either building, but  >still remain intrigued...  H But that was at the stage where TheInquirer was still suggesting it as aC very strong probability.  If it's all above board and has no hiddeno
 meanings :  G Hudson was sold to Intel with the Digital deal on the FAB (as one would A expect).  The Alpha team that was still in house at Compaq was ineJ Shrewsbury which they were suggesting was near enough to Hudson as to makeH it a simple move for the staff involved since Compaq appeared to want to! retain their Shrewsbury facility.gI I don't know if there's anything else of Compaq in Shrewsbury besides the0E Alpha team.  Whatever happens though, Compaq would want to have theirdJ designers on EV7 working under a Compaq roof incase the brown smelly stuff hit the fan I would imagine.   Steve.   ------------------------------  % Date: Wed, 27 Jun 2001 12:12:17 -0400n, From: "Richard Whalen" <WhalenR@process.com>$ Subject: Re: VMS on IA64 (technical)+ Message-ID: <9hd0l2$1r7$1@news.process.com>c  K The Alpha design team moved from Hudson to Shrewsbury when the FAB was sold-	 to Intel. H The Shrewsbury facility also houses half of StorageWorks and part of the services group.:  - <steven.reece@quintiles.com> wrote in messageeB news:OF0F7D5D3A.E9846988-ON80256A78.00518562@qedi.quintiles.com... >1 >wI > Hudson was sold to Intel with the Digital deal on the FAB (as one wouldnC > expect).  The Alpha team that was still in house at Compaq was intL > Shrewsbury which they were suggesting was near enough to Hudson as to makeJ > it a simple move for the staff involved since Compaq appeared to want to# > retain their Shrewsbury facility.GK > I don't know if there's anything else of Compaq in Shrewsbury besides the.G > Alpha team.  Whatever happens though, Compaq would want to have theirtL > designers on EV7 working under a Compaq roof incase the brown smelly stuff > hit the fan I would imagine. >2 > Steve. >"   ------------------------------    Date: 27 Jun 2001 09:59:29 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)5E Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)-3 Message-ID: <UjY7MfSdZNKl@eisner.encompasserve.org>0  \ In article <3B3945E9.80E2050C@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes:  L > Had Compaq continued to develop Alpha until IA64 was capable of runnng VMSH > (port included), then the perceptiosn would have been quite different.  D As I read the schedule, Compaq _will_ be continuing to develop AlphaA until IA64 is ready, just not beyond that (i.e., not to EV8 whicho' would have been delivered beyond that).o   ------------------------------   Date: 27 Jun 2001 10:08 CDTu' From: carl@gerg.tamu.edu (Carl Perkins)sE Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)z- Message-ID: <27JUN200110085796@gerg.tamu.edu>t  = Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes...E] }In article <3B3945E9.80E2050C@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes:t } M }> Had Compaq continued to develop Alpha until IA64 was capable of runnng VMSaI }> (port included), then the perceptiosn would have been quite different.  } E }As I read the schedule, Compaq _will_ be continuing to develop AlphaaB }until IA64 is ready, just not beyond that (i.e., not to EV8 which( }would have been delivered beyond that).  F The problem with this theory is that it makes a very strong assumptionE about when IA64 with be ready. What if it is late? Will Compaq revivetG the EV8? Of course not - it will not have been developed and would take I more than a year to push into production even if they threw lots of money H at it. By specifically killing off the Alpha line at the end of the nextF generation, they have drawn a line in the sand. But Compaq has nothingD to do with determining when the line is crossed - it is out of their hands and in Intel's hands.   H If you think upgrades to VMS capable systems come slow now, and they do,J what if the IA64 that is faster than the last EV7 revision (EV79, I think)J is delayed by a year or three? Or do you propose switching to an IA64 that2 is slower than the then currently available Alpha?  G That would be bad. Also bad, but obsucured since it will never actuallypD show up, is what if the IA64 that is used is significantly slower atE integer and floating point work, and has a smaller I/O bandwidth than  the EV8 would have had?   I If either (or even both) of these happens, it would clearly be better fortH all the relevant OSes if EV8 were to be built. But that choice is gone - it will not be developed.a  F If everythig goes according to plan, VMS will keep right on doing whatE VMS does and will have a useful upgrade path. If anything goes wrong,7E VMS (and True64 and NSK) is stuck without an upgrade path for as long E as it takes Intel to get the IA64 running faster than the last Alpha.eI Considering that slips of as much as 2 years seem to happen to processorssF a lot in recent years it seesm foolish to count on not only coming outD on the current schedule, but actually accelerating the schedule likeJ they want to (or probably need to, if IA64 is to pass Alpha in performance in the next 3 years or so).s   --- Carl   ------------------------------    Date: 27 Jun 2001 11:39:39 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen).E Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)i3 Message-ID: <oMFXoMsePTuR@eisner.encompasserve.org>y  W In article <27JUN200110085796@gerg.tamu.edu>, carl@gerg.tamu.edu (Carl Perkins) writes:o? > Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes...c_ > }In article <3B3945E9.80E2050C@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes:O > } O > }> Had Compaq continued to develop Alpha until IA64 was capable of runnng VMSfK > }> (port included), then the perceptiosn would have been quite different.I > } G > }As I read the schedule, Compaq _will_ be continuing to develop Alpha D > }until IA64 is ready, just not beyond that (i.e., not to EV8 which* > }would have been delivered beyond that). > H > The problem with this theory is that it makes a very strong assumptionG > about when IA64 with be ready. What if it is late? Will Compaq revivelI > the EV8? Of course not - it will not have been developed and would takeeK > more than a year to push into production even if they threw lots of moneyrJ > at it. By specifically killing off the Alpha line at the end of the nextH > generation, they have drawn a line in the sand. But Compaq has nothingF > to do with determining when the line is crossed - it is out of their > hands and in Intel's hands.   F If IA64 is not ready, Compaq will have to keep on selling Alpha EV78s.   ------------------------------  % Date: Wed, 27 Jun 2001 12:50:54 -0300e) From: fabio_compaq@ep-bc.petrobras.com.br E Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)9L Message-ID: <OFEE737EC3.59C2E1C7-ON03256A78.0056FDB8@ep-bc.petrobras.com.br>   Alpha  ? Who needs it  ??o  3 Just see the "state-of-art"  powered by Intel ! ! !1  H http://www.compaq.com/newsroom/PressPaq/062601/images/TaskSmart_W2200.j= pg  
 F=E1bio C.            H Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) em 27/06/2001 13:39= :39   E Favor responder a Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)o             Info-VAX@Mvb.Saic.Com       E Assunto: Re: Wailing and moaning... (was: Question to Charlie Matco.)     F In article <27JUN200110085796@gerg.tamu.edu>, carl@gerg.tamu.edu (Carl Perkins) writes:? > Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes...t8 > }In article <3B3945E9.80E2050C@videotron.ca>, JF Mezei& <jfmezei.spamnot@videotron.ca> writes: > }eH > }> Had Compaq continued to develop Alpha until IA64 was capable of ru= nnng VMSnH > }> (port included), then the perceptiosn would have been quite differ= ent. > }0H > }As I read the schedule, Compaq _will_ be continuing to develop Alpha=  D > }until IA64 is ready, just not beyond that (i.e., not to EV8 which* > }would have been delivered beyond that). > H > The problem with this theory is that it makes a very strong assumptio= n H > about when IA64 with be ready. What if it is late? Will Compaq revive=  H > the EV8? Of course not - it will not have been developed and would ta= keH > more than a year to push into production even if they threw lots of m= oneyH > at it. By specifically killing off the Alpha line at the end of the n= extDH > generation, they have drawn a line in the sand. But Compaq has nothin= ggF > to do with determining when the line is crossed - it is out of their > hands and in Intel's hands.   F If IA64 is not ready, Compaq will have to keep on selling Alpha EV78s.         =    ------------------------------  % Date: Wed, 27 Jun 2001 13:09:51 -0400k- From: JF Mezei <jfmezei.spamnot@videotron.ca>sE Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.) , Message-ID: <3B3A135B.89FFF08B@videotron.ca>   Larry Kilgallen wrote:F > As I read the schedule, Compaq _will_ be continuing to develop AlphaC > until IA64 is ready, just not beyond that (i.e., not to EV8 whichl) > would have been delivered beyond that).   M No, Compaq is completing development of Alpha, irrespective of when IA64 willeL be ready. So if IA64 is delayed by a few years, Compaq won't be adding a new version of alpha to keep up.   ------------------------------  % Date: Wed, 27 Jun 2001 13:11:10 -0400b+ From: John Eisenschmidt <jeisensc@aaas.org>rE Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)a# Message-ID: <sb39db75.039@aaas.org>o  A I'm not worried. Neither Intel nor MS has ever missed a deadline.t  < What's that you say? Merced should have shipped 5 years ago?   Figures.  E >>> JF Mezei <jfmezei.spamnot@videotron.ca> 06/27/2001 1:09:51 PM >>>- Larry Kilgallen wrote:F > As I read the schedule, Compaq _will_ be continuing to develop AlphaC > until IA64 is ready, just not beyond that (i.e., not to EV8 which6) > would have been delivered beyond that)..  J No, Compaq is completing development of Alpha, irrespective of when IA64 = willJ be ready. So if IA64 is delayed by a few years, Compaq won't be adding a = newo version of alpha to keep up.   ------------------------------  % Date: Wed, 27 Jun 2001 13:14:28 -0400o+ From: "Main, Kerry" <Kerry.Main@compaq.com> E Subject: RE: Wailing and moaning... (was: Question to Charlie Matco.)nR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF48DBF01@kaoexc01.americas.cpqcorp.net>   JF,   K >> No, Compaq is completing development of Alpha, irrespective of when IA64tK will be ready. So if IA64 is delayed by a few years, Compaq won't be adding & a new version of alpha to keep up. <<<  H How do you know this? I am certain no one on this list from Compaq could answer that question.S  H HP extended and bumped up PA because IA64 was late. Why could not Compaq extend EV7 in the same manner?   Regardsi  
 Kerry Main Senior Consultants Compaq Canada Inc. Professional Servicesp Voice: 613-592-4660M Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----4 From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca] Sent: June 27, 2001 1:10 PMh To: Info-VAX@Mvb.Saic.ComrE Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)      Larry Kilgallen wrote:F > As I read the schedule, Compaq _will_ be continuing to develop AlphaC > until IA64 is ready, just not beyond that (i.e., not to EV8 which ) > would have been delivered beyond that).n  H No, Compaq is completing development of Alpha, irrespective of when IA64 willL be ready. So if IA64 is delayed by a few years, Compaq won't be adding a new version of alpha to keep up.   ------------------------------  % Date: Wed, 27 Jun 2001 13:22:41 -0400r2 From: rdeininger@mindspring.com (Robert Deininger)E Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)oL Message-ID: <rdeininger-2706011322410001@user-2ive7go.dialup.mindspring.com>  5 In article <3B3A135B.89FFF08B@videotron.ca>, JF Mezeio% <jfmezei.spamnot@videotron.ca> wrote:f   > Larry Kilgallen wrote:H > > As I read the schedule, Compaq _will_ be continuing to develop AlphaE > > until IA64 is ready, just not beyond that (i.e., not to EV8 whichs+ > > would have been delivered beyond that).  > O > No, Compaq is completing development of Alpha, irrespective of when IA64 willlN > be ready. So if IA64 is delayed by a few years, Compaq won't be adding a new > version of alpha to keep up.  I That specifically contradicts what Compaq has said.  EV7 followed by EV78WJ and EV79.  If there's a need, they can likely continue the process shrinksJ and other incremental improvements.  EV710?  EV7A?  As you contantly point@ out, incremental improvements have done pretty well by the 8086.  I Are you ever optimistic about anything?  It must be an ordeal just to get, up in the morning.   -- a Robert Deininger rdeininger@mindspring.com    ------------------------------  % Date: Wed, 27 Jun 2001 13:23:24 -0400e+ From: John Eisenschmidt <jeisensc@aaas.org>eE Subject: RE: Wailing and moaning... (was: Question to Charlie Matco.)p# Message-ID: <sb39de60.085@aaas.org>-  L Because HP is still in control of the PA-RISC line. Compaq just gave Alpha =$ to Intel, and with it their control.  K Once that transfer is complete, and EV7 is out the door, you can bet 100% = I of the remaining Alpha team will be working on Itanic/McKinley/whatever =s IA-64 chip they have.=20  C >>> "Main, Kerry" <Kerry.Main@compaq.com> 06/27/2001 1:14:28 PM >>>l JF,n  H >> No, Compaq is completing development of Alpha, irrespective of when = IA64F will be ready. So if IA64 is delayed by a few years, Compaq won't be = adding& a new version of alpha to keep up. <<<  H How do you know this? I am certain no one on this list from Compaq could answer that question.e  H HP extended and bumped up PA because IA64 was late. Why could not Compaq extend EV7 in the same manner?   Regardss  
 Kerry Main Senior Consultante Compaq Canada Inc. Professional Servicess Voice: 613-592-4660w Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com=20      -----Original Message-----7 From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]=20i Sent: June 27, 2001 1:10 PMs To: Info-VAX@Mvb.Saic.Com=20E Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)e     Larry Kilgallen wrote:F > As I read the schedule, Compaq _will_ be continuing to develop AlphaC > until IA64 is ready, just not beyond that (i.e., not to EV8 whicho) > would have been delivered beyond that).t  H No, Compaq is completing development of Alpha, irrespective of when IA64 willJ be ready. So if IA64 is delayed by a few years, Compaq won't be adding a = newv version of alpha to keep up.   ------------------------------    Date: 27 Jun 2001 13:49:27 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)hE Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)t3 Message-ID: <kLG85kMqFZIn@eisner.encompasserve.org>s  \ In article <3B3A135B.89FFF08B@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > Larry Kilgallen wrote:G >> As I read the schedule, Compaq _will_ be continuing to develop Alpha-D >> until IA64 is ready, just not beyond that (i.e., not to EV8 which* >> would have been delivered beyond that). > O > No, Compaq is completing development of Alpha, irrespective of when IA64 willsN > be ready. So if IA64 is delayed by a few years, Compaq won't be adding a new > version of alpha to keep up.  I If adequate performing version of IA64 is not available yet, what does it-& matter that people are stuck on EV78 ?   ------------------------------    Date: 27 Jun 2001 13:51:32 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)uE Subject: RE: Wailing and moaning... (was: Question to Charlie Matco.)n3 Message-ID: <0P+KHSK0Y7YX@eisner.encompasserve.org>   ? No, Compaq just allowed Intel to use Compaq technology and hire:D certain Compaq people without a fistfight.  Compaq still owns Alpha,3 and could, for instance, hire IBM to design an EV8.d  Q In article <sb39de60.085@aaas.org>, John Eisenschmidt <jeisensc@aaas.org> writes:SN > Because HP is still in control of the PA-RISC line. Compaq just gave Alpha =& > to Intel, and with it their control. > M > Once that transfer is complete, and EV7 is out the door, you can bet 100% =rK > of the remaining Alpha team will be working on Itanic/McKinley/whatever =u > IA-64 chip they have.=20 > D >>>> "Main, Kerry" <Kerry.Main@compaq.com> 06/27/2001 1:14:28 PM >>> > JF,w > I >>> No, Compaq is completing development of Alpha, irrespective of when =  > IA64H > will be ready. So if IA64 is delayed by a few years, Compaq won't be = > adding( > a new version of alpha to keep up. <<< > J > How do you know this? I am certain no one on this list from Compaq could > answer that question.  > J > HP extended and bumped up PA because IA64 was late. Why could not Compaq  > extend EV7 in the same manner? > 	 > Regardsn >  > Kerry Main > Senior Consultanti > Compaq Canada Inc. > Professional Servicess > Voice: 613-592-4660l > Fax  :  819-772-7036! > Email: Kerry.Main@Compaq.com=20a >  >  > -----Original Message-----9 > From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]=20V > Sent: June 27, 2001 1:10 PM- > To: Info-VAX@Mvb.Saic.Com=20G > Subject: Re: Wailing and moaning... (was: Question to Charlie Matco.)B >  >  > Larry Kilgallen wrote:G >> As I read the schedule, Compaq _will_ be continuing to develop AlphagD >> until IA64 is ready, just not beyond that (i.e., not to EV8 which* >> would have been delivered beyond that). > J > No, Compaq is completing development of Alpha, irrespective of when IA64 > willL > be ready. So if IA64 is delayed by a few years, Compaq won't be adding a = > news > version of alpha to keep up. >  -- eN ==============================================================================N Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> ClustersN ==============================================================================   ------------------------------  + Date: Wed, 27 Jun 2001 11:38:18 +0000 (UTC)u' From: david20@alpha1.mdx.ac.uk (D.Webb)y$ Subject: Re: Wailing and moaning....+ Message-ID: <9hcgja$37j$1@aquila.mdx.ac.uk>-  o In article <lFvLl5Tv6P7O@eisner.encompasserve.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes::V >In article <9hagob$dck$1@aquila.mdx.ac.uk>, david20@alpha1.mdx.ac.uk (D.Webb) writes: >rM >> Looking at some posts in comp.sys.dec and comp.unix.tru64 the TRU64 peoplejI >> are concerned about how TRU64 will survive on IA64 in competition withl. >> the other Unix systems being ported there.  >n4 >That is what makes for good software - competition.    H But one of the reasons for buying TRU64 rather than other Unix's was theG fact it ran on the Alpha chip. This was a selling point in certain higho performance computing markets.  
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------    Date: 27 Jun 2001 10:17:10 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)D$ Subject: Re: Wailing and moaning....3 Message-ID: <ZPP$E2hhF5UF@eisner.encompasserve.org>   U In article <9hcgja$37j$1@aquila.mdx.ac.uk>, david20@alpha1.mdx.ac.uk (D.Webb) writes:tq > In article <lFvLl5Tv6P7O@eisner.encompasserve.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:uW >>In article <9hagob$dck$1@aquila.mdx.ac.uk>, david20@alpha1.mdx.ac.uk (D.Webb) writes:, >>N >>> Looking at some posts in comp.sys.dec and comp.unix.tru64 the TRU64 peopleJ >>> are concerned about how TRU64 will survive on IA64 in competition with/ >>> the other Unix systems being ported there. e >>5 >>That is what makes for good software - competition.f >  > J > But one of the reasons for buying TRU64 rather than other Unix's was theI > fact it ran on the Alpha chip. This was a selling point in certain highe  > performance computing markets.  < And now they will have to survive on software quality alone,= meaning there is no opportunity for Tru64 Development to restn> on the laurels of the chip designers.  That can only be a good@ thing for software quality.  The basic principle I am interestedA in is software quality, rather than Tru64 success.  The same goesA for VMS.   ------------------------------    Date: 27 Jun 2001 11:45:35 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)s$ Subject: Re: Wailing and moaning....3 Message-ID: <jXGQDvgIhDPW@eisner.encompasserve.org>r  j In article <5.1.0.14.2.20010627080724.027934d8@ntbsod.psccos.com>, Dan O'Reilly <dano@process.com> writes:( > At 08:07 AM 6/27/2001, JF Mezei wrote: >>Alan Greig wrote: . >> > If you can manage as much as possible of: >> >J >> > 1) Ability to run Alpha binaries without a manual VEST. Hey maybe you" >> > can even manage VAX binaries! >>F >>Personally, I think that they should focus on the reverse of the COEN >>initiative. They should port the VMS system services and run time library toO >>Linux, and port TPU to Linux. That will make it much easier for us to port ofaN >>in-house applications to Linux and be done with VMS, allowing Compaq to shutP >>it down and forget about that pesky product that woudn't go away no matter how >>hard Compaq tried. > L > You know, if you put as much effort into trying to make something positiveN > of what's going on as you are in slamming EVERYTHING constantly, we might beM > able to move this whole thing forward in a positive way...sorry, but we areaP > all VERY aware you're angry about this, you don't have to keep up the constant& > barrage of intensely negative posts.  F When JF Mezei spoiled DECUServe with total negativity a few years ago,I eventually he gave up and went away.  Good things come to those who wait.e   ------------------------------  % Date: Wed, 27 Jun 2001 13:30:47 -0400s- From: JF Mezei <jfmezei.spamnot@videotron.ca>K$ Subject: Re: Wailing and moaning...., Message-ID: <3B3A1843.F1979717@videotron.ca>   Larry Kilgallen wrote:H > When JF Mezei spoiled DECUServe with total negativity a few years ago,K > eventually he gave up and went away.  Good things come to those who wait.   L You should note that I have seen been proven right with the argument of thatJ time ( Halon extinguishers) but I didn't rub it in but I do not beleive in" personal attacks on public forums.   ------------------------------    Date: 27 Jun 2001 10:06:29 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) E Subject: Re: Wailing and moaning.... (was: Question to Charlie Matco)t3 Message-ID: <pONpKCrmnUxj@eisner.encompasserve.org>   l In article <THj_6.11300$P5.3917039@news1.rdc1.tn.home.com>, "Alphaman" <alphaman64@nixspam-home.com> writes:6 > Main, Kerry <Kerry.Main@compaq.com> wrote in messageN > news:BE56C50EA024184DAF48F0B9A47F5CF4A19466@kaoexc01.americas.cpqcorp.net...< >> Was I surprised at the announcement? Sure - everyone was. > L > Why is being surprised by an announcement goodness?  Why not do things theB > traditional way -- NDA's, migration, slow changes, condition the3 > marketplace, survey customers, sway the consumer?s > N > Instead, in one lump, OpenVMS people are being told they have to swallow theH > one processor they hate the most in the world in exchange for the best > processor in the world.?  ! You have confused IA64 with IA32.w   ------------------------------   Date: 27 Jun 2001 06:47 CDT6' From: carl@gerg.tamu.edu (Carl Perkins)1, Subject: Re: What about performance issues??- Message-ID: <27JUN200106473949@gerg.tamu.edu>   + prosullivan@aol.com (PROSULLIVAN) writes...sA }>It has been said here that VMS performance, particularly I/O is , }>considerably slower than under other OSes. } M }Digital's own spec ratings for Alpha were different if the alpha was runningaN }vms or (then digital unix). Guess which one was rated slower? Guess which one }was more resilient?  G Actually, the one and only time (that I know of) I saw SPEC ratings foraH VMS and Digital Unix (as it was called at the time - this was at least 5E years ago) on identical hardware the results were mixed: DU was ratednE somthing around 2% faster on the integer benchmark, but VMS was rateddE somthing around 1% faster on the floating point benchmark. The entirelB discrepancy is well within the range you can attribute to compiler variations.d   --- Carl   ------------------------------  % Date: Wed, 27 Jun 2001 12:02:04 +0100n% From: Alan Greig <a.greig@virgin.net>h2 Subject: Re: What does Alphas dead means for VMS ?8 Message-ID: <c5fjjtgnkib143q1u9v0vhilhbcjnd0nvo@4ax.com>  2 On Tue, 26 Jun 2001 01:36:43 +0200, Christof Brass <brass@infopuls.com> wrote:      > A >This NSK/Himalaya zick-zack course is a slight proof that nobodyeA >at Compaq thought about that "solution" earlier. That big changea> >without much planing ahead doesn't seem to be a good starting >point.   ? Yes they had thought about it. At least a small team of WInklerIF loyalists had been talking to Intel loyalists in secret for quite someB time. Or do you think they just came up with the idea last Friday?     -- Alan   ------------------------------  % Date: Wed, 27 Jun 2001 08:18:40 -0400m' From: Howard S Shubs <howard@shubs.net>. Subject: Re: Why not port?< Message-ID: <howard-009160.08184027062001@enews.newsguy.com>  = In article <4ce97a1a.0106262145.698c25f4@posting.google.com>, $  lyngwyst@aol.com (Jay Braun) wrote:  H > I just completed a port of a VMS application to Linux.  Sure, it was aB > lot of work, but we no longer have to worry about the whims of aC > single company like Compaq.  Also, most Linux tools are free, and = > there are plenty of books available on a variety of topics.- > G > Applications and organizations are all unique, and a move to Linux ordG > some other popular OS might not be for you.  UNIX and Linux are dirtynA > words to many of this newsgroups' regulars.  But if you can getoE > yourself beyond the "religious" issues, you might add years to yourt > applications' life cycles.  M Yup.  I really like VMS.  I've spent a lot of time working on skills related  J to VMS.  I find VMS superior to everything else I've seen or heard of for C large tasks.  It's also more reliable than anything else I've seen.,  M Big fucking deal: I lose, since VMS's market is and has been shrinking badly dI and the world is moving toward Microsoft and UNIX.  Given that I despise wM Microsoft's operating system attempts, that leaves me with UNIX.  Good thing b? my favorite personal OS, MacOS, is heading in that direction...-  K You can fight it, you can complain about it, you can bury your head in the  N sand, but VMS is and has been toast.  This last bit where VMS now needs to be M ... surprise! ported to Yet Another Architecture, which won't happen, is the a final straw.  @ We can't go back to the 20 years starting in 1978.  It's -over-.    G > Of what use is a better OS -- assuming VMS is better -- if it runs onr > very few architectures?   N Or only on doomed ones.  Personally, I preferred VAX over Alpha.  It was much  easier to program. -- q Howard S ShubsD "Run in circles, scream and shout!"  "I hope you have good backups!"   ------------------------------  # Date: Wed, 27 Jun 2001 17:06:21 GMT 2 From: seibel_r@localhost.localdomain (Rich Seibel) Subject: Re: Why not port?; Message-ID: <slrn9jk4k4.esr.seibel_r@localhost.localdomain>m  B On 26 Jun 2001 22:45:21 -0700, Jay Braun <lyngwyst@aol.com> wrote:G >I just completed a port of a VMS application to Linux.  Sure, it was arA >lot of work, but we no longer have to worry about the whims of acB >single company like Compaq.  Also, most Linux tools are free, and< >there are plenty of books available on a variety of topics. > F This is the voice of reason.  The signs are everywhere. Open Source isG the future of commodity software.  Yes, there will still be proprietaryvE software, but it will be, as it should, used to implement a company'soE value-added properties of their business.  How long has it been since-F a word processor or an accounting package gave a company an edge over B its competitors?  We are now starting to view OSs in the same way.  F >Applications and organizations are all unique, and a move to Linux orF >some other popular OS might not be for you.  UNIX and Linux are dirty@ >words to many of this newsgroups' regulars.  But if you can getD >yourself beyond the "religious" issues, you might add years to your >applications' life cycles.v >pF >Of what use is a better OS -- assuming VMS is better -- if it runs on >very few architectures?     -- eD --------------------------------------------------------------------D Rich Seibel, Software Engineer                 (314)579-0066 ext 220D Object Computing, Inc.                           seibel_r@ociweb.comD Need ACE training?                      See http://www.theaceorb.comD --------------------------------------------------------------------   ------------------------------  % Date: Wed, 27 Jun 2001 10:29:20 -0400y- From: "Richard D. Piccard" <piccard@ohio.edu>t* Subject: Re: [OT] but now UK vs US English( Message-ID: <3B39EDC2.1311EF43@ohio.edu>   Paul Sture wrote:t   >,   [snip]  M > ensuring (oops - shouldn't that be insuring in US English?) that UK English-% > is shortly going to be a dead duck.0  O I am almost certainly not a typical American in my usage of English, but I haveiI always used "insuring" when there is a financial transaction involved, an.8 "insurance policy," and "ensuring" as "to make certain."  #                                 RDPo --B ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  % Date: Wed, 27 Jun 2001 12:21:16 +0100e  From: steven.reece@quintiles.com  Subject: Re: [OT] Climate changeH Message-ID: <OF465CBB81.8BC60555-ON80256A78.003E0409@qedi.quintiles.com>  F An addition to this thread is the article that I saw on the front of aK "newspaper" in the UK yesterday.  Apparently there are investigations going I on as to where new nuclear power stations could be located within the UK.eH A site near Bristol is apparently being considered, as are a few others.G The aim of the work would be to reduce the consumption of fossil fuels.2   Steve.   Bob Koehler wrote/quoted : >>>MK >> At least with a fusion reactor (and I look forward to them), if anything J >> goes wrong the whole thing stops faster than you can think about it, no4 >> Chernobyl style melt downs like fission reactors. >sH > There are fission reactor designs that have the same feature.  If they get4J > hotter, they get less reactive and tend to slow down.  I don't think any4 > of these newer designs have been built in the U.S.  E Design in is nice, but in fission the basic process tends to build on4E itself and can simply run aways when something goes wrong (safety andfI backup systems can fail), whereas in fusion the basic process is severaly39 unstable so when anything goes wrong it just plain stops.y <<<a   ------------------------------    Date: 27 Jun 2001 10:34:33 -0700. From: jordan@greenapple.com (Jordan Henderson)V Subject: [OT] IBM Slow and sclerotic?  ( Was Re: Compaq's Alpha design team for sale?)= Message-ID: <51d39066.0106270934.2d8e4528@posting.google.com>t  ] Christof Brass <brass@infopuls.com> wrote in message news:<3B390C36.46CD3176@infopuls.com>...n > Jordan Henderson wrote:i > > 0 > > In article <3B37B32B.E8B44081@infopuls.com>,/ > > Christof Brass  <brass@infopuls.com> wrote:s > > >Jordan Henderson wrote: > > >>3 > > >> In article <3B364CE6.14193DE2@infopuls.com>,b2 > > >> Christof Brass  <brass@infopuls.com> wrote: > > >> >JF Mezei wrote:i	 > > >> >>i > > >> >> Dirk Munk wrote:R > > >> >> > So let's hope that Compaq has more sense than selling of the Alpha. ItR > > >> >> > may generate money for the shareholders for now, but it can't generateM > > >> >> > money in future anymore either. Some managers seem to forget thatn@ > > >> >> > customers pay you money, and you pay shareholders. .	 > > >> >>oX > > >> >> A big part of the announcement was that Compaq was going to spend $500 millionV > > >> >> bucks to buy service/solutions companies (guess where that money is going toM > > >> >> come from ????) and grow service/solutions revenus by 40% per year. 	 > > >> >>iU > > >> >> Their bet is that they can grow the services/solutions business faster thani< > > >> >> the Alpha-based business will go away (VMS/Tru64).	 > > >> >>eJ > > >> >> And after the transformation, Compaq will be back to itself as aX > > >> >> Microsoft/Intel company with no pesky leftovers from Digital to get in the way: > > >> >> of its three-some relationship with its masters.	 > > >> >> T > > >> >> And when Capellas is booted out, Winkler will probably replace him to seal* > > >> >> Compaq's faith as an NT company.	 > > >> >> V > > >> >> In the end, I would be much more happy if IBM were to buy Alpha. If IBM wereV > > >> >> to buy Alpha, it would be because IBM intends to make it succesful. If Intel: > > >> >> buys Alpha, it is to burry it as fast as it can. > > >> >E > > >> >Sorry, IBM has no useful piece of SW developed by its own. NouF > > >> >useful OS, no Server SW, no apps. IBM is a sclerotic, slow and0 > > >> >visionless company - the least VMS need. > > >> > > > >>H > > >> I've often suspected you are out of touch with reality, but now I# > > >> know you are waay out there.2 > > >  > > >Si tacuisses ...X > > >i- > > >> Let's see, useful SW developed by IBM:  > > >>3 > > >>         DB/2     - performance leading RDBMS @ > > >>         ViaVoice - arguably the best voice recognition SW7 > > >>         MQSeries - best queueing architecture SWhP > > >>         Important Linux enhancements like Journaling FS (many other Linux > > >>         enhancements).t% > > >>         Best JIT Java compiler E > > >>         WebSphere - arguably best integrated Web product suite  > > >a@ > > >Useless piece of shit. I know of several projects that onlyA > > >"work" (sort of) because many (really many) IBM "consultant" 8 > > >work on the project. Never mention this crap again. > > >s > > F > > How incredibly dismissive of you.  Software that's widely regardedE > > as best-in-class or nearly is relegated to "Useless piece of ..."0: > > status by that great Industry Observer Christof Brass. > > > Completely wrong - I'm a practioneer, a person who uses thisB > kind of stuff. BTW I have an analysis of reward degreeded MIT CS? > which shows clearly why this SW is a piece of shit. There hastA > been recently an asessment of WebSphere and another Applicationd> > Server in one of the most wide spread international computer; > magazins where WebSphere lost on every single point. It'sdB > unmanagable, unreliable and very expensive. Any evidence of your
 > ratings? >   
 How about:  "     http://www.realwareawards.com/  E     http://www.zdnet.com/pcmag/stories/reviews/0,6755,2713481,00.html   <     http://www.siia.net/events/awards/2001codies/winner.html  2     http://biz.yahoo.com/iw/010502/0101026581.html  4     http://www.linuxworldexpo.com/event-sub-03.shtml  ? Now, I have to admit that I have no first hand experience with  = Websphere, and I think you'd have to admit that yourself.  I s; just go by what's said in the press on such things, and thei? above looks pretty impressive.  Hardly worthy of the "worthlessn piece of shit".3  : I note that you failed to address _any_ of the other SW I 8 mentioned.  I guess I have to assume that you are taking? back the statement "IBM has no useful piece of SW developed by >	 its own."<  6 I would guess that a highly performing, cross platform= database like DB/2 would be useful to someone.  Or, a really  = good JIT Java compiler might be of some use to a Java user oro; developer.  Then, if you need voice recognition, you've gote6 two realistic choices now, L&H (ha! would you bet your; application on software from a bunch of managers in jail onf< fraud?) or ViaVoice, from IBM.  ViaVoice sounds useful, too.= A journaling file system might be useful to some Linux users.c  9 I know that where I work, we are finding a lot of use fory
 MQ Series.  9 Admit it, your statement that "IBM has no useful piece ofo8 SW developed by its own." is just a ridiculous sweeping & statement that you now cannot justify.  D > > I'll mention the above portfolio again and ask you, who has moreF > > "vision" (this thing that you won't define but insist that I don't9 > > understand) in as many areas of Software development?  > > H > > >>         Lotus Domino - developed after they bought Lotus.  WidelyF > > >>                 regarded as the best Web-based collaboration SW >  > Again: who developed that? > @ > > >You obviously don't seem to know yet which company is still- > > >developing Notes ... (no it's *not* IBM)J > > >  > > M > > IBM folded Lotus into their overall software marketing strategy long ago.>' > > The current Lotus CEO is an IBM'er.u > @ > But Lotus isn't developing Notes - you obviously don't seem to@ > know the basics, sorry. Please try to answer my question. WhatA > you wrote isn't an answer but mere an organisational fact whichr) > I already detailed in my previous post.o >   F This is not an example of SW developed by IBM, true, but it is a good > example of a company that is not slow or sclerotic.  A lot of D companies buy technology and bury them (MS), or mismanage them (CA), but IBM has done neither..  L > > At least you should give IBM credit for buying and cultivating Lotus, ifI > > you think there's anything there worthwhile...  Buying and developingiM > > good brands is hardly what you would expect of a slow, sclerotic company.w > @ > No, this is the only thing that this kind of company could do:: > buy other companies and live from their ideas. Any other# > definition of "vision" available?h > C > > >Given these gross errors I'm not inclined to discuss the other ? > > >SW pieces. I also doubt that you really understood my post-> > > >(maybe some other posts also) because you are listing HW. > > >.N > > >> Oh the hardware side, it's again, too long a list, but some highlights: > > >>" > > >>         Semiconductor tech. > > >>                 Coppere. > > >>                 worlds-best lithography= > > >>                 worlds-fastest demonstrated transistor C > > >>                 "Stretched" Silicon for 35% performance gaint > > >> > > >>         StorageR > > >>                 TravelStar HDs - best laptop HDs (these things are amazing)% > > >>                 Microdrive HDs-I > > >>                 "Pixie Dust" promises 4x improvement in HD densityr > > >> > > M > > I notice you completely skipped over the world-beating HW technology thatC > > IBM develops.s > 2 > I note that you still didn't understand my post. >   B In your post you accuse IBM of being slow and sclerotic.  Somehow,B I think this image is at odds with a company that develops some of the world's finest HW.  E But, then, I have to admit, I don't understand your post.  See below..  K > > >> More proof that IBM isn't sclerotic?  They are the dominant ServicesiO > > >> and Consulting vendor in the world.  You know, where Compaq want's to beaP > > >> now?  IBM didn't used to be so big in Services and Consulting, passing up' > > >> EDS and others a few years back.  > > >p> > > >Band waggon effect. Do you really understand what you areE > > >talking about? Have you ever set up a business relationship withrB > > >IBM under current economical constraints? The work IBM people@ > > >deliver is more than miserable. I could list some very well< > > >known Web sites that have been developed by IBM and are= > > >served/maintained by them. To say the least: close to beuB > > >useless, slow, buggy, badly designed both from an ergonomicalC > > >point of view but also from an aesthetical point of view - ando@ > > >BTW their Web sites aren't really available at some time at> > > >night - ever heard of Internet and 24 hours availability? > > >xB > > >IBM offers mediocre service for outstanding rates to managersD > > >that aren't responsible for the money they spent, mostly public@ > > >institutes etc.. Do you remember the IBM performance at the# > > >Atlanta Olympic Games? Do you?d > > >  > > E > > Pretty old news.  I remember the Sydney Olympics and it was fine.t > @ > Every company with that amount of money will get it once done.A > But as another poster mentioned DEC achieved much, much more inh5 > the HW design area with much less money than Untel.d > N > > I also think the Tennis sites are quite excellent.  The web was relativelyJ > > young at Atlanta and they were trying to do things that had never beenK > > done before, in terms of volume and content turnover.  Excuse a company>J > > for taking risks, I guess...  Hardly a hallmark of a sclerotic firm to > > take risks and fail. > ; > The Web wasn't that new at that time and a bunch of othero6 > companies did similar services in an excellent way.   ? The Web wasn't that new in the Summer of 1996???  Well, I guessgB Tim Berners-Lee did have some pages up in 1991.  Seriously though,@ how many times has the Internet doubled in users since then?  OnD the other hand, the Web was experiencing rapid growth in those days.  ? Again, IBM attempted a site that had unprecedented hits at the aB time and experienced some problems.  Sounds like a risk taker, not: something you would expect from a slow, sclerotic company.  A Got anything more recent than 5 years ago of how bad the IBM web 2. sites are?  How about a really recent example?     http://www.wimbledon.com/   E Seems like a pretty good site to me.  Well laid out, lots of features F easy to navigate, fast searches.  Do you have an example of a _better_/ sports event site?  Why is your example better?r  @ >                                                     Networking9 > was always the black whole at IBM - do you remember TR?u  A Do you remember how deftly IBM got out of networking devices justy@ before the market completely dropped out?  Leaving Cisco and the= optical companies gasping for air?  Hardly a move by a slow, o sclerotic company.  A > It's fairly telling that you don't answer to my questions aboutl? > having dealt personally in a business realtionship with IBM -o > BTW the name stinks also.  >   ? IBM is probably the most recognized brand in all of IT.  They'de= be crazy to change it.  Oh, I know, how about something like  # "Accenture", that'd be more snappy.e  A I have dealt personally with IBM consultants, but I don't want toIA share these experiences in a public forum.  Leave it to say that tA I've dealt with much worse, even from other big consulting firms.c  C > > A lot of clients are unhappy with the service they get from bigaH > > consulting firms.  I can tell you horror stories about them all, butI > > mediocre is defined by comparison with others.  What large consulting 5 > > firm consistently outperforms IBM on assignments?  > @ > This is really a hard question (I know some answers because ofB > my own consulting work but I'm not supposed to reveal this factsA > as you might understand). The problem with big companies is QA.eA > You might have luck and get some good people but you might haveiA > bad luck and stuck with a hord of idiots costing you 2000.- US$h@ > per day and working like beginners. But generally observed IBM> > is doing a lot of business with paying managers to buy theirA > services (or with other tricks of influencing decision makers -s; > I know about 10 stories because I have close friends thatn; > expierenced that) and not with their outstanding quality.t= > Compared with their portfolio IBM is doing a miserable job.rB > Think about the fact that they offer a full range of services in< > almost each area of IT related business. They get a lot of> > contracts because they offer this full range of service, not > because their quality. > L > > >> Now, who is it that has MORE vision than IBM?  Maybe they aren't thatN > > >> quick to react, but it's hard to move fast when you are the biggest.  IM > > >> think they do a really good job of being fast while being the biggest.h > > >i > > >Steve Jobs. > > >e > > L > > Oh, Steve Jobs is the biggest?  I didn't realize his turnaround of Apple > > had been so successful.a > A > Irony in your position is the least you can afford. I mentionedr@ > him as an example to let you understand what the word "vision"= > could also mean besides your narrow minded and - honestly -h, > quite a bit wrong understanding of vision.A > If you had a little knowledge of what has happened at Apple I'mr@ > sure you wouldn't have written that. Honestly I don't see much> > sense in explaining that to you also. I suggest that you get> > familiar with IT industry history. Then you come back and we" > will continue to exchange ideas. >   E I was just pointing out how difficult it is for IBM to move fast (and F I think they do a pretty good job) when you are so large, and you giveF me a counter example of someone who represents a much smaller company.@ If there's any irony, it's because you want to keep changing the subject.  L > > So, when I ask you who, as an organization, has more vision than IBM andJ > > you come up with the one person who is synonymous with vision.  OK, soE > > perhaps Steve Jobs has more "vision" than IBM as an organization.( > B > An organisation cannot have a vision. Multiple visions of peopleA > working at one company will destroy the effect of *the vision*.yA > It really seems that you didn't understand the effect of havings > *a vision* for the employees.t >   C OK.  Now I see!  An organization cannot have a vision.  So when your@ said that IBM is "visionless" you were just stating a tautology!  M > > Now, what large IT companies have more vision, in as many fields, as IBM? J > > Who does world beating hardware chip development, world class softwareH > > development (sorry, I mentioned those "pieces of crap" again...) AND/ > > widely recognized best-of-breed consulting?- > 8 > Almost every other comany. Thanks for asking that easy > questions. >   B But wait, now you are saying that almost every other company (all C organizations) show more vision than IBM.  How can you show more ofe? something that you can't have at all by your own definitions.  e  @ I have to admit that I don't understand your post, as you accuse@ me of above.  But then, it appears you don't understand what you/ are saying either, so I can perhaps be excused.r  A It's really hard to get a definition of "vision" out of you, but c? I'm getting it bit-by-bit in what you say about it.  You avoid dB the dictionary definition below, you know, where you say it's not B "seeing into the future or prophesy".  The dictionary definition IC  associate with the word vision is "foresight", which is synonomousnA with being able to see into the future.  Please, tell me, what doa _you_ mean by vision?e  3 > > >> >Would you like to be VMS IBM's second OS/2?o > > >>R > > >> OS/2's failure wasn't a lack of vision.  They poured unbelievable resourcesH > > >> into OS/2 and just couldn't make it go against the MS juggernaut.N > > >> Vision would have been if they hadn't tried, or really, if they saw the6 > > >> writing was on the wall and abandoned it early. > > >> > > >> -Jordan Henderson > > >> jordan@greenapple.com > > >-B > > >It seems that we have a misunderstanding as to the meaning of? > > >the word "vision". You seem to regard it like something asaC > > >prophecy or beeing able to view into the future. I don't agreegB > > >on that definition. And BTW OS/2 was ruined besides others byC > > >IBM's marketing. They even didn't allowed Lotus do implement ai= > > >Notes client when they had bought that company. Any morec > > >examples necessary? > > >m > > E > > Oh, yes, a Lotus client would have certainly saved OS/2.  PerhapsrD > > that was IBM just showing sense in not throwing good money afterC > > bad. Perhaps Lotus had a definite market strategy that requiredoD > > a certain number of realistic seats before investment.  WhateverC > > this "vision" thing means to you - you criticize my use without ? > > saying what it is you mean yourself - I doubt that it meanse > > foolhardy. > : > Again, your post reveals a great lack of knowledge in ITA > history. At the time IBM acquired Lotus OS/2 wasn't dead at allr: > besides what IBM did against it. It is like the harm DEC= > management did to VMS. If this is your definition of vision 7 > you're probably the only person with that definition.y >   : IBM bought Lotus in July of 1995.  By this time, OS/2 had : been almost completely abandoned in the Enterprise.  Sure,< they sold a lot of $89.95 boxes in 1994-95 to home and SOHO = users, but by late 1995, the companies that had adopted OS/2,4@ by and large, were moving away from OS/2 toward NT in a big way 5 and the future looked very bleak for Enterprise OS/2.p  : Lotus notes is an Enterprise tool, selling into Enterprise8 accounts.  No point in selling for a platform that's not* used in Enterprise accounts, now is there?  ; > > >Sorry, I observed that you get from time to time posts ) > > >questioning your knowledge of facts.  > > = > > Mostly by Andrew Harrison.  I guess a man is known by his : > > adversaries. Questioning yes, substantiating a lack of2 > > attention to facts is something else entirely. > > A > > I've observed that your judegement is often questioned.  But,>E > > it's irrelevant to this conversation what others have questioned.> > > > Not often and always by the same people. Could you give some > examples?s >   E Well, Andrew Harrison, for one.  There are others, particularly those - who would defend some things about UNIX here.   D Now, who questions my knowledge of facts except Andrew Harrison and E yourself.  Are you saying that Andrew was correct on those occassions # and incorrect when criticizing you?M  D > > It's just a silly debating technique you use because you've been> > > caught making an absurd statement about IBM being slow and@ > > sclerotic that you can't back up with _facts_, just lot's of8 > > empty epithets like "pieces of shit" and "mediocre". > @ > Incredible. You obviously forgot that you introduced this type > of arguing. Incredible.  >   = Hardly.  I didn't make sweeping generalizations using highly  = charged rhetoric that I couldn't back up.  I questioned your t> judgement and gave a lot of specific examples to disprove your< generalizations.  Specific examples that you have failed to # address, for the most part, at all.c  @ > BTW I have first, second and third hand experience of what I'mA > talking. I have been in touch with Micro$hit products which alloA > have been introduced into the market by IBM. Deciding to buy anWB > OS for the PC from a company like Micro$hit and even not knowingB > that this company has nothing to offer but instead in turn would? > buy this product from another company is neither a symptom oft= > vision nor a strategic decision that reveals much brain letb? > alone something completely different than slow and sclerotic.l >   > Oh, now here's an example that's 20 years old!  I believe that? IBM has almost completely reorganized about twice since then.  c> I believe that _all_ of the SW products that I mentioned above5 as being useful were developed since then.  They grew 6 to be the dominant services organization in that time.  ? About par for you.  A 5 year old example at how bad they are atm> Web Site management (which is like 50 years in Internet-time),> and a 20 year old decision.  That decision, BTW, was driven by> their frantic quest to field the original IBM PC before Apple ? fielded a new generation.  Again, hardly an accusation of being = slow and sclerotic that you make bad decisions in the heat ofe- trying to get something to market right away.   @ > While I mentioned a lot of facts to prove my point of view you; > are only *defending* their failures. Where are the reallyr/ > compelling and convincing positive examples??t >   < I've had the tough job of proving a negative.  You said that? (paraphrase) "IBM has no useful SW they developed on their own.n< They are slow, sclerotic and visionless".  I've had to prove this was not true.  ; Fortunately, you used universal generalizations that can be > disproved with specific examples.  I gave specific examples of= useful software, and how they are not, particularly in the HWt> domain, a slow, sclerotic and visionless company.  In the caseA of useful SW, you've only chosen to address Websphere at all, andvB I've now countered that with my own reasons for thinking that it'sB at least _useful_.  In the case of the HW, proving that IBM is not; slow and sclerotic, you've not given any rebuttal _at all_.   ? It seems the onus is on you to show how the SW examples I gave e= above are "useless".  Also, you need to justify how IBM is a  @ slow and sclerotic company in the face of a lot of evidence thatA they are actually quite innovative, particularly in the HW arena.o  C > > >                                     I wouldn't go that far asoE > > >you did in the first sentence of your post where you rated me as E > > >beeing out of touch with reality. But it seems that you are verygC > > >bad informed on the topics you accidentally decided to talk tou > > >me. > > . > > Nothing accidental at all, all on purpose. > ? > It would a good idea then - if done on purpose - to study the 4 > topic a little bit in advance you're gone talk on.   I could say the same to you.   >  > > -Jordan Hendersono > > jordan@greenapple.comd   -Jordan Henderson  jordan@greenapple.coma   ------------------------------   End of INFO-VAX 2001.354 ************************