1 INFO-VAX	Mon, 25 Jun 2001	Volume 2001 : Issue 350       Contents:P Re: Affordable VMS Workstations... All of a Sudden Alpha Looks	More Competitive	( Re: Altavista search engine for OpenVMS?( Re: Altavista search engine for OpenVMS? Re: Any people use KEA! 420 ?   Re: API web page: what's wrong ?* CNN news report about Compaq restructuring' Compaq ditches Alpha, what does API do?  Re: Compaq kills Alpha Re: Compaq kills Alpha  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 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 proves their incompetence$ RE: Compaq proves their incompetence$ Re: Compaq proves their incompetence1 Compaq Solutions Alliance web site now accessible 5 Re: Compaq Solutions Alliance web site now accessible  Compaq switches to IA-64 Re: Compaq switches to IA-64 Re: Compaq switches to IA-64 Re: Compaq switches to IA-642 Compaq to phase out computer lines not using IntelE Compaq Transfers Alpha to Intel after EV7 (was: Alpha design team...) I Re: Compaq Transfers Alpha to Intel after EV7 (was: Alpha design team...) ( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( RE: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( RE: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( RE: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( RE: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( RE: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( RE: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?( Re: Compaq's Alpha design team for sale?& Re: Compaq: 180 Days of Transformation& Re: Compaq: 180 Days of Transformation& Re: Compaq: 180 Days of Transformation& Re: Compaq: 180 Days of Transformation& Re: Compaq: 180 Days of Transformation& Re: Compaq: 180 Days of Transformation& Re: Compaq: 180 Days of Transformation& RE: Compaq: 180 Days of Transformation& Re: Compaq: 180 Days of Transformation Re: cool add Re: cool add Re: cool add Re: DECnet Phase IV router
 Re: DECss7" EMC fibre disk on ES40 + VMS 7.2-1P Error message question:    %AMDS-W-BADLANADR, bad LAN address form on line: EIA0 f$getqui Re: f$getqui Re: f$getqui Re: f$getqui FA items Re: FreeVMS " Re: FTP LIST problem. Help Please! 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: Future support of VAX-VMS  RE: Future support of VAX-VMS  Re: Future support of VAX-VMS  RE: Future support of VAX-VMS + Re: Gap in this forum between March and May * Guys, IT is done! Read this and be scared!. Re: Guys, IT is done! Read this and be scared!. Re: Guys, IT is done! Read this and be scared!! Re: H-P EOLs PA-RISC Architecture ! Re: H-P EOLs PA-RISC Architecture 4 Re: How to see who causes execessive login failures. 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: Intel/Alpha announcment  Itanium HW REF MAN@ job: (recruiter) NYC: Solaris/OpenVMS or Tru64 admin (recruiter)D Re: job: (recruiter) NYC: Solaris/OpenVMS or Tru64 admin (recruiter) Re: Marketing Rantings #3  Re: Marketing Rantings #3  RE: Marketing Rantings #3  RE: Marketing Rantings #3  Re: Marketing Rantings #3 + Memo:  Re: MACRO:include externals how to ? / Re: Memo:  Re: MACRO:include externals how to ?  not about Itanium  Question about DCPS  Re: Question about DCPS  Re: Question to Charlie Matco. Re: Question to Charlie Matco. Re: Question to Charlie Matco. Re: Question to Charlie Matco. Re: Question to Charlie Matco. Re: Question to Charlie Matco. Re: Question to Charlie Matco. Req VMS Tutorial Re: Req VMS Tutorial Re: Req VMS TutorialP RE: Reward for the first of the next 50 posts: which company	shouldbuy VMS VMS VP RE: Reward for the first of the next 50 posts: which company	shouldbuy VMS VMS VJ Re: Reward for the first of the next 50 posts: which company shouldbuy VMS Shared SCSI-Bus Question(s)  Re: Shared SCSI-Bus Question(s)  Sherlock Holmes Museum Sherlock Holmes Museum# Some good news about VMS on Itanium  Re: stopping autoboot on 433au Re: stopping autoboot on 433au
 Target->Batch ( Re: The end of Computer Associates ????? Vax Service Centre VAX-11/780 boot disk needed # 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 7.3/Alpha boot bugcheck problem ' RE: VMS 7.3/Alpha boot bugcheck problem ' Re: VMS 7.3/Alpha boot bugcheck problem   Re: VMS applications on the web? Re: VMS on IA64 (technical)  Re: VMS on IA64 (technical)  Re: VMS on IA64 (technical)  Re: VMS on IA64 (technical)  Re: VMS on IA64 (technical)  Re: VMS on IA64 (technical)  Re: VMS on IA64 (technical)  Re: VMS on IA64 (technical)  Re: VMS on IA64 (technical) % What does Alphas dead means for VMS ? ) Re: What does Alphas dead means for VMS ? ) Re: What does Alphas dead means for VMS ? ) Re: What does Alphas dead means for VMS ? ) Re: What does Alphas dead means for VMS ? ) Re: What does Alphas dead means for VMS ? ) Re: What does Alphas dead means for VMS ? ) Re: What does Alphas dead means for VMS ? ) Re: What does Alphas dead means for VMS ? ) Re: What does Alphas dead means for VMS ? ) Re: What does Alphas dead means for VMS ?  Re: [OT] Climate change  Re: [OT] Climate change  Re: [OT] Climate change   F ----------------------------------------------------------------------  % Date: Mon, 25 Jun 2001 07:59:27 -0400 6 From: Tom BOURKE <bourke_tm@mailhub.davork.com.nospam>Y Subject: Re: Affordable VMS Workstations... All of a Sudden Alpha Looks	More Competitive	 ? Message-ID: <B75C9FDF.C590%bourke_tm@mailhub.davork.com.nospam>    Read this...  L > Itanium Clone - code named Alpha - from the Clever PC people at Compaq !!!  + I heard about the news announcement this AM   D Basically Compaq can't support the development of the Alpha chipset.: So it is to die, with OpenVMS and Tandem moving to Itanium  E > 64Bits and only $1325 US - whats more - it will run WIndows NT !!!!   G Might be closer to the truth than the tongue in cheek humour suggested!   * Just give medium sized 'q' a few months...   Tom    ------------------------------    Date: 25 Jun 2001 09:37:53 -0700$ From: cass_glavce@hotmail.com (Cass)1 Subject: Re: Altavista search engine for OpenVMS? = Message-ID: <aa361a34.0106250837.4275abd4@posting.google.com>   = A search and retrieval tool that works natively on OpenVMS is E SearchKey PRO, a Java-based search engine for Intra/Internet servers. " Check it out at: www.searchkey.com   Cass  f Mark Daniel <mark.daniel@wasd.vsm.com.au> wrote in message news:<3B1059C4.3C58D1A1@wasd.vsm.com.au>...I > For any interested an in-development kit of SWISH-E indexing and search I > package refered to elsewhere in this thread has been placed on the WASD   > download page in the BETA area >   >   http://wasd.vsm.com.au/wasd/ > = > Please refer SWISH-E port queries to Jean-Franois Pironne  > (jfp@altavista.net). >  > Jean-Franois PIRONNE wrote:  > >  > > System@nospam.com wrote: > > > R > > > In article <rdeininger-2205012307470001@user-2iveats.dialup.mindspring.com>, > > > : > > > Robert Deininger <rdeininger@mindspring.com> writes: > > > > L > > > >Marc Krellenstein, CTO of NorthernLight, spoke at today's AlphaServerK > > > >Diamond Forum.  NorthernLight does sell their indexing and searching P > > > >software to corporate customers, and it does run on (only) VMS.  They canN > > > >index html or just about any other data format.  No idea what it costs.
 > > > ---8<--  > > > S > > > Thank you all for your responses (and sorry for the stupid anonymous address. J > > > Our policy does not allow forum postings under a Corporate account).5 > > > I will check and evaluate all of the responses.  > > > R > > > Does this mean that noone around developped a more powerful search tool than. > > > the DCL Search facility? I am surprized. > > >  > > 0 > > I have successfully port SWISH-E on OpenVMS. > > H > > SWISH-E is a tool for indexing files, there is filter for HTML, XML,, > > postscript, GIF, and many other formats. > > I > > More information can be found on http://sunsite.berkeley.edu/SWISH-E/  > > > > > My port is integrate in the developement version of swish.H > > Daily snapshots are at http://sunsite.berkeley.edu:4444/swish-daily/	 > > which C > > should be getting rather stable -- but considered a development . > > version since changes are stil being made. > > F > > For example i have indexed all the OpenVMS, Rdb,... documentations > > L > > A library is build so it is easly to integrate it into an other program. > > I > > Mark Daniel, the author of WASD, has buid a CGI program (SWISHESI) to  > > query a SWISH-E dababase.  > > ? > > You can find a demonstration on http://StarLet.DeltaTel.RU/  > > H > > My port is currently partial: only local files are indexed, the http9 > > part use a script PERL ans i haven't all the modules.  > > N > > > I just copied the FREEWARE CD v4 onto a VMS disk and browsed through it. > > > No more success. > > >  > > > Now, a question:S > > > Assuming you take over a system management position and the previous folk has O > > > left very far away without easy ways to communicate, what would you do to 
 > > > know5 > > > what is where on your brand new cluster system?  > > > + > > > $ type/page [*...]*.com on all disks?  > > >  > > > SM > > > U > > >  -----  Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web  ----- S > > >   http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups O > > >    NewsOne.Net prohibits users from posting spam.  If this or other posts R > > > made through NewsOne.Net violate posting guidelines, email abuse@newsone.net   ------------------------------    Date: 25 Jun 2001 12:56:30 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) 1 Subject: Re: Altavista search engine for OpenVMS? 3 Message-ID: <$yD$VbZ1KUMP@eisner.encompasserve.org>   d In article <aa361a34.0106250837.4275abd4@posting.google.com>, cass_glavce@hotmail.com (Cass) writes:? > A search and retrieval tool that works natively on OpenVMS is G > SearchKey PRO, a Java-based search engine for Intra/Internet servers.   C That isn't really native, as VMS has only the Java Virtual Machine,  no native Java compiler.   ------------------------------    Date: 25 Jun 2001 12:02:18 -05009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow) & Subject: Re: Any people use KEA! 420 ?3 Message-ID: <PcKWSGabyGv6@eisner.encompasserve.org>   i In article <00ac01c0fc2c$040b8bc0$d347bfc8@valdemir>, "Valdemir J. Santos" <valdemir-@uol.com.br> writes: J > I=B4d like to know if is there any person in this group using KEA! 420 = > for OpenVMS.  3 Please turn off your MIME/HTML when posting here...   L Yes! I'm connected through it right now. Simply, it's the best emulator I'veB found. I recently ran the VTTEST suite by it, and found prety good@ compliance in all areas. Very much the opposite of Hyperterm :-(  L > I=B4d like learn how to create little macros to automatically connect in = > the system,=20   Not needed.   ( > open and read data in files, etc...=20    Haven't done anything like this.   ------------------------------    Date: 25 Jun 2001 06:51:34 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) ) Subject: Re: API web page: what's wrong ? 3 Message-ID: <$Si6ZFtnGZBU@eisner.encompasserve.org>   \ In article <3B36CBF8.DB774BDA@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > What is wrong with the page: > @ > http://www.alpha-processor.com/products/21264a-processor.shtml > 8 > (look for the section on operating systems supported).  ' It depends on what you mean by "wrong".   E I believe the list of operating systems support is probably accurate.   F I was once told that by and large the serious VMS customers (those whoG bring the most revenue to DEQ) want to buy boxes made by the OS vendor,  not those from API.   C If you think this is "wrong" in that it should be changed, you will B have to change the basic economics of the situation. Or perhaps an announcement from Compaq will.   ------------------------------  % Date: Mon, 25 Jun 2001 07:11:24 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 3 Subject: CNN news report about Compaq restructuring , Message-ID: <3B371C59.BAA4AFFB@videotron.ca>  . http://cnnfn.cnn.com/2001/06/25/europe/compaq/  L Essentially Compaq going to imitate IBM and sell packaged softare and suportG solutions instead of just hardware. Will invest $500 million to acquire = companies, and expect to save $200 million from cost cutting.   K No mention of Alpha. But it seems to be an important business story for the 
 day (so far).    ------------------------------  % Date: Mon, 25 Jun 2001 10:36:42 -0500 + From: Christopher Smith <csmith@amdocs.com> 0 Subject: Compaq ditches Alpha, what does API do?L Message-ID: <3B55D7F383B0D31197D9009027541CBF0D9D1FD8@cmiexch1.cmi.itds.com>  J I don't understand as well as I should the relationship between Compaq andJ API.  I have been under the impression, though, that API is independent ofB Compaq, and manufactures Alpha chips for lots of different things.  K What I don't know is this:  Was all Alpha development done by Compaq still? ! Will it now all be done by Intel?   6 Anyone care to guess what happens to API in this mess?   Regards,   Chris   ! Christopher Smith, Perl Developer  Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");  '       ------------------------------   Date: 25 Jun 2001 15:19:38 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)  Subject: Re: Compaq kills Alpha , Message-ID: <9h7kqa$2nug$1@info.cs.uofs.edu>  5 In article <fuIZ6.124787$367.3742199@news.chello.at>, '  Wolfgang Rupp <rupp@chello.at> writes:   |> B.Eckstein <be@cli.de> wrote:> |> > http://www.compaq.com/newsroom/presspaq/062501/index.html |>  C |> > "Compaq also said it will consolidate its entire 64-bit family 9 |> > of servers on the Itanium processor family by 2004."  |>  : |> > That's it. Alpha's dead. Bad job you did, Michael :-( |>  ' |> You're probably right, that's it :-(   ; Of course, this means congratulations are in order for it's @ grandfather.  The PDP-11 architecture has now not only outlasted the VAX, but also the Alpha.  - Looks like I backed the right horse.....  :-)    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>   O   ------------------------------  # Date: Mon, 25 Jun 2001 15:44:35 GMTd$ From: Wolfgang Rupp <rupp@chello.at> Subject: Re: Compaq kills Alpha 5 Message-ID: <D%IZ6.125394$367.3762687@news.chello.at>   B In comp.sys.dec Bill Gunshannon <bill@triangle.cs.uofs.edu> wrote:  = > Of course, this means congratulations are in order for it'sgB > grandfather.  The PDP-11 architecture has now not only outlasted > the VAX, but also the Alpha.  @ Well, in two years - let's see if Mentec still makes them in two? years. However, the thought that I suggest management to buy myt> 11/23+ back into active service on reasons of "proven platform3 with development potential" has something to it :-)e  
 Wolfgang Ruppe   ------------------------------   Date: 25 Jun 2001 14:36:10 GMT3 From: vance@alumni.caltech.edu (Vance R. Haemmerle) ) Subject: Compaq proves their incompetencep, Message-ID: <9h7i8q$bld@gap.cco.caltech.edu>  G   It looks like Compaq has proven today that they are a souless company F with no business or management experience to execute on anything save F exporting intellectual property to other companies.  Last month I madeF the mistake of buying their stock because I figured the price was at aF year low and things couldn't get worse.  Today's announcemet proves meB wrong and today I've corrected my portfolio by selling all my CPQ.  C   That Compaq would choose to turn over their entire company to the E Intel side of the business that they are having such a hard time with J vs. Dell, etc. portends their future as just another box maker and forever an also ran.  I   God save their customers.  I can't figure how right minded person would = recommend a company that can't commit or execute on anything.s   -- Vance Haemmerle  vance@alumni.caltech.edu   ------------------------------   Date: 25 Jun 2001 14:44:47 GMT3 From: vance@alumni.caltech.edu (Vance R. Haemmerle) - Subject: Re: Compaq proves their incompetencef, Message-ID: <9h7iov$bsl@gap.cco.caltech.edu>     And another thing... :)g  H   Turning over the future of the company to an unproven chip is Compaq'sF way to turn over all responsiblity of their high-end systems to eventsJ out of their control.  It's the easiest way for managers who can't executeB to have someone else to blame when the chip fails to come through.  E   Obviously these events today guarantee IA64 MONOPOLY status and thesH FTC should look into this deal.  Their previous restrictions on the saleF of the Alpha FAB to Intel was not enough to stop Intel and Compaq from1 removing the competition given by the Alpha chip.    -- Vance Haemmerleg vance@alumni.caltech.edu   ------------------------------  % Date: Mon, 25 Jun 2001 08:57:10 -0600 % From: Dan O'Reilly <dano@process.com>?- Subject: Re: Compaq proves their incompetence B Message-ID: <5.1.0.14.2.20010625085538.02818ea0@ntbsod.psccos.com>  K Ummmmmmm...pardon playing the devil's advocate here, but didn't DEC do thatrD with the VAX, and particularly with the Alpha?  Neither was a proven+ technology when they were first released...o  0 At 08:44 AM 6/25/2001, Vance R. Haemmerle wrote: >   And another thing... :)  >nJ >   Turning over the future of the company to an unproven chip is Compaq'sG >way to turn over all responsiblity of their high-end systems to events K >out of their control.  It's the easiest way for managers who can't executekC >to have someone else to blame when the chip fails to come through.a >AG >   Obviously these events today guarantee IA64 MONOPOLY status and the$I >FTC should look into this deal.  Their previous restrictions on the salerG >of the Alpha FAB to Intel was not enough to stop Intel and Compaq fromV2 >removing the competition given by the Alpha chip. >u >--r >Vance Haemmerle >vance@alumni.caltech.edu    ------I +-------------------------------+---------------------------------------+lI | Dan O'Reilly                  |                                       |oI | Principal Engineer            |  "Why should I care about posterity?  |MI | Process Software              |   What's posterity ever done for me?" | I | http://www.process.com        |                    -- Groucho Marx    |dI +-------------------------------+---------------------------------------+-   ------------------------------  % Date: Mon, 25 Jun 2001 10:58:23 -0400o From: William_Bochnik@acml.com- Subject: Re: Compaq proves their incompetence/> Message-ID: <OF502D1EE7.AD35F40E-ON85256A76.00523492@acml.com>  0 difference being that the VAX->ALPHA was inhouse      a                                                                                                  oa                     "Dan                                                                         pa                     O'Reilly"                    To:  Info-VAX@Mvb.Saic.Com                      ta                     <dano@process                cc:                                             ea                     .com>                Subject:     Re: Compaq proves their incompetence       aa                                                                                                  .a                     06/25/2001                                                                   ea                     10:57 AM                                                                     la                                                                                                  Va                                                                                                  f      ? Ummmmmmm...pardon playing the devil's advocate here, but didn'tS DEC do thati= with the VAX, and particularly with the Alpha?  Neither was am proven+ technology when they were first released...   0 At 08:44 AM 6/25/2001, Vance R. Haemmerle wrote: >   And another thing... :)> >cA >   Turning over the future of the company to an unproven chip isA Compaq's@ >way to turn over all responsiblity of their high-end systems to events= >out of their control.  It's the easiest way for managers who 
 can't executel: >to have someone else to blame when the chip fails to come through. > ? >   Obviously these events today guarantee IA64 MONOPOLY status  and the @ >FTC should look into this deal.  Their previous restrictions on the sale; >of the Alpha FAB to Intel was not enough to stop Intel andn Compaq fromM2 >removing the competition given by the Alpha chip. >e >--  >Vance Haemmerle >vance@alumni.caltech.educ   ------I +-------------------------------+---------------------------------------+ ! | Dan O'Reilly                  |  | ; | Principal Engineer            |  "Why should I care aboutd
 posterity?  | > | Process Software              |   What's posterity ever done
 for me?" |? | http://www.process.com        |                    -- Groucho 	 Marx    | I +-------------------------------+---------------------------------------+           F ______________________________________________________________________  : The information contained in this transmission may contain< privileged and confidential information and is intended only< for the use of the person(s) named above. If you are not the< intended recipient,  or an employee or agent responsible for? delivering this message to the intended recipient,  any review,e@ dissemination, distribution or duplication of this communication> is strictly prohibited. If you are not the intended recipient,A please contact the sender immediately by reply e-mail and destroy # all copies of the original message.p   ------------------------------  % Date: Mon, 25 Jun 2001 09:13:32 -0600n% From: Dan O'Reilly <dano@process.com>a- Subject: Re: Compaq proves their incompetencedB Message-ID: <5.1.0.14.2.20010625090752.027f70a0@ntbsod.psccos.com>  6 At 08:58 AM 6/25/2001, William_Bochnik@acml.com wrote:  1 >difference being that the VAX->ALPHA was inhouse   G So were the RA60 or the RA81 - and ask anybody who had recalls on thosejN technologies.  I worked in the Advanced Technology Disk Business at DEC duringL the RA81 HDA recall, and we processed literally thousands thru per day.  ForM that matter, ask the COBOL compiler writers about the VAX 8600.  The originaltG CPU was missing an instruction mode that turned out the COBOL guys usedrI extensively.  I also had extensive (and EXPENSIVE!!!) experience with the.I solid-state drives ("non-rotating media" - I love it!!!!) in StorageworksaM that had 100% failure rates in a highly mission-critical application I workede on.     What I'm saying here is twofold:  / 1. DEC didn't always equal outstanding quality.r  N 2. Do you REALLY think that the VMS people (or TRU64, or NSK, for that matter)L would accept a product that wasn't absolutely reliable?  I give them a wholeI lot more credit than that.  That's at least one of the reasons for takinggO 2 or 3 years to turn out a baseline product.   And even then, I don't seriously 0 expect them to be production-ready at that time.     >"Dant7 >                     O'Reilly"                    To: d > Info-VAX@Mvb.Saic.Comn7 >                     <dano@process                cc:   >dJ >                     .com>                Subject:     Re: Compaq proves  > their incompetence >  > @ >Ummmmmmm...pardon playing the devil's advocate here, but didn't >DEC do that> >with the VAX, and particularly with the Alpha?  Neither was a >provenu, >technology when they were first released... >i1 >At 08:44 AM 6/25/2001, Vance R. Haemmerle wrote:  > >   And another thing... :)n > >uC > >   Turning over the future of the company to an unproven chip isf	 >Compaq'saB > >way to turn over all responsiblity of their high-end systems to >events ? > >out of their control.  It's the easiest way for managers whoo >can't execute< > >to have someone else to blame when the chip fails to come	 >through.n > >oA > >   Obviously these events today guarantee IA64 MONOPOLY statusi >and theB > >FTC should look into this deal.  Their previous restrictions on	 >the sale.= > >of the Alpha FAB to Intel was not enough to stop Intel andn >Compaq from4 > >removing the competition given by the Alpha chip. > >e > >--t > >Vance Haemmerle > >vance@alumni.caltech.edux >a >------eJ >+-------------------------------+---------------------------------------+" >| Dan O'Reilly                  | >|< >| Principal Engineer            |  "Why should I care about >posterity?  |? >| Process Software              |   What's posterity ever donet >for me?" |p@ >| http://www.process.com        |                    -- Groucho
 >Marx    |J >+-------------------------------+---------------------------------------+ >d >s >  >  > G >______________________________________________________________________i > ; >The information contained in this transmission may contain = >privileged and confidential information and is intended onlyv= >for the use of the person(s) named above. If you are not theo= >intended recipient,  or an employee or agent responsible forr@ >delivering this message to the intended recipient,  any review,A >dissemination, distribution or duplication of this communicationo? >is strictly prohibited. If you are not the intended recipient,-B >please contact the sender immediately by reply e-mail and destroy$ >all copies of the original message.   ------I +-------------------------------+---------------------------------------+hI | Dan O'Reilly                  |                                       |-I | Principal Engineer            |  "Why should I care about posterity?  |@I | Process Software              |   What's posterity ever done for me?" |nI | http://www.process.com        |                    -- Groucho Marx    | I +-------------------------------+---------------------------------------+o   ------------------------------  % Date: Mon, 25 Jun 2001 10:19:02 -0500 6 From: "David Moczygemba" <David.Moczygemba@UDPinc.COM>- Subject: Re: Compaq proves their incompetencer@ Message-ID: <8BIZ6.44437$Mq.1848437@e420r-sjo3.usenetserver.com>  G IMHO, Agreed that neither VAX nor Alpha processor was proven when first0? released, as a proven first release is an oxymoronic statement.l  I Regardless, the difference here is that VAX to Alpha was a 32bit to 64bitrH evolutionary step, whereas,  Alpha to IA64, is a proven 64bit to unknown 64bit side-step. -do  2 "Dan O'Reilly" <dano@process.com> wrote in message< news:5.1.0.14.2.20010625085538.02818ea0@ntbsod.psccos.com...H > Ummmmmmm...pardon playing the devil's advocate here, but didn't DEC do thatF > with the VAX, and particularly with the Alpha?  Neither was a proven- > technology when they were first released...o   ------------------------------  % Date: Mon, 25 Jun 2001 16:10:42 +0100m  From: steven.reece@quintiles.com- Subject: Re: Compaq proves their incompetencenH Message-ID: <OFEB874AFD.60F5F308-ON80256A76.00533EFC@qedi.quintiles.com>  I That may be, but in the case of Digital the control of the processor chip ? was still within Digital Equipment Corporation, not with Intel.o Steve.   Dan O'Reilly wrote:u >>>:K Ummmmmmm...pardon playing the devil's advocate here, but didn't DEC do thatsD with the VAX, and particularly with the Alpha?  Neither was a proven+ technology when they were first released...i  0 At 08:44 AM 6/25/2001, Vance R. Haemmerle wrote:J >   Turning over the future of the company to an unproven chip is Compaq'sG >way to turn over all responsiblity of their high-end systems to events K >out of their control.  It's the easiest way for managers who can't executeaC >to have someone else to blame when the chip fails to come through.r <<<h   ------------------------------  % Date: Mon, 25 Jun 2001 09:36:01 -0600 % From: Dan O'Reilly <dano@process.com>n- Subject: Re: Compaq proves their incompetenceeB Message-ID: <5.1.0.14.2.20010625093524.02790618@ntbsod.psccos.com>  O Read my first response to this, WRT the RA60, the RA81, the VAX 8600.  All were00 under the control of DEC.  And all had problems.  8 At 09:10 AM 6/25/2001, steven.reece@quintiles.com wrote:    J >That may be, but in the case of Digital the control of the processor chip@ >was still within Digital Equipment Corporation, not with Intel. >Steve.e >p >Dan O'Reilly wrote: > >>>oL >Ummmmmmm...pardon playing the devil's advocate here, but didn't DEC do thatE >with the VAX, and particularly with the Alpha?  Neither was a proveno, >technology when they were first released... > 1 >At 08:44 AM 6/25/2001, Vance R. Haemmerle wrote:-L > >   Turning over the future of the company to an unproven chip is Compaq'sI > >way to turn over all responsiblity of their high-end systems to eventseM > >out of their control.  It's the easiest way for managers who can't execute E > >to have someone else to blame when the chip fails to come through.d ><<<   ------I +-------------------------------+---------------------------------------+aI | Dan O'Reilly                  |                                       |sI | Principal Engineer            |  "Why should I care about posterity?  |eI | Process Software              |   What's posterity ever done for me?" | I | http://www.process.com        |                    -- Groucho Marx    |iI +-------------------------------+---------------------------------------+k   ------------------------------  % Date: Mon, 25 Jun 2001 11:47:38 -0400n2 From: rdeininger@mindspring.com (Robert Deininger)- Subject: Re: Compaq proves their incompetencelL Message-ID: <rdeininger-2506011147390001@user-2ivebei.dialup.mindspring.com>  E In article <9h7iov$bsl@gap.cco.caltech.edu>, vance@alumni.caltech.edu  (Vance R. Haemmerle) wrote:t   >   And another thing... :)n > J >   Turning over the future of the company to an unproven chip is Compaq'sH > way to turn over all responsiblity of their high-end systems to eventsL > out of their control.  It's the easiest way for managers who can't executeD > to have someone else to blame when the chip fails to come through.  : Very good point.  They wash their hands of responsibility.   -- - Robert Deininger rdeininger@mindspring.comh   ------------------------------  % Date: Mon, 25 Jun 2001 12:00:00 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)- Subject: Re: Compaq proves their incompetencecL Message-ID: <rdeininger-2506011200010001@user-2ivebei.dialup.mindspring.com>  F In article <5.1.0.14.2.20010625090752.027f70a0@ntbsod.psccos.com>, Dan" O'Reilly <dano@process.com> wrote:     " > What I'm saying here is twofold: > 1 > 1. DEC didn't always equal outstanding quality.C > P > 2. Do you REALLY think that the VMS people (or TRU64, or NSK, for that matter)N > would accept a product that wasn't absolutely reliable?  I give them a wholeK > lot more credit than that.  That's at least one of the reasons for takingiG > 2 or 3 years to turn out a baseline product.   And even then, I don'tl	 seriouslya2 > expect them to be production-ready at that time.  H I trust the VMS folks.  But will Compaq give them the enormous resources this project will require?  @ VMS development is going to slow down as the porting effort gets# underway.  That's not a good thing.-  D Alpha development will slow down. There won't be the expected fasterD systems beyond the next generation.  VMS won't be ready on Intel forG several years.  As with the early days of alpha systems, there won't belJ competitive high-performance VMS platforms.  That, combined with continued8 Compaq non-marketing, will likely hurt VMS market share.  G There may well be light at the end of the tunnel.  It's a long tunnel.  E VMS engineering builds a damn good train, but Compaq is the engineer.r  H This might be the first (or second or third) move in the Palmer gambit. * Make Compaq small enough to be gobbled up.  I Sigh.  Cheer me up.  Please tell me one good thing that Compaq managementy( has ever done.  What are they good at?    G On the bright side, VMS engineering is holding some very strong cards. eI VMS is mostly written in HLLs these days, including device drivers.  OncesI good compilers are available (a huge job in itself), a lot of VMS will go  without changes.  I And VMS has done this before.  This will be the second major architecture J change for the OS.  The first one was (we hope) a learning experience, andH today's code base has more portability designed in than in the VAX days.  J MacOS survived an architecture change, and proved that it's hard.  VMS did5 the same.  Can VMS make it look easy the second time?a   -- n Robert Deininger rdeininger@mindspring.coma   ------------------------------  % Date: Mon, 25 Jun 2001 12:37:31 -0300 ) From: fabio_compaq@ep-bc.petrobras.com.brt- Subject: Re: Compaq proves their incompetenceeL Message-ID: <OFCA8B1C62.D5BF5856-ON03256A76.0055C7B2@ep-bc.petrobras.com.br>   Look  H If this "portability" really works, may be we can Run OpenVMS under Hp,=  	 Dell, etce   F=E1bio Cardosot        D vance@alumni.caltech.edu (Vance R. Haemmerle) em 25/06/2001 11:36:10  ? Favor responder a vance@alumni.caltech.edu (Vance R. Haemmerle)l             Info-VAX@Mvb.Saic.Com-      ) Assunto: Compaq proves their incompetence     H   It looks like Compaq has proven today that they are a souless company=  E with no business or management experience to execute on anything saveoF exporting intellectual property to other companies.  Last month I madeF the mistake of buying their stock because I figured the price was at aF year low and things couldn't get worse.  Today's announcemet proves meB wrong and today I've corrected my portfolio by selling all my CPQ.  C   That Compaq would choose to turn over their entire company to thepE Intel side of the business that they are having such a hard time witheH vs. Dell, etc. portends their future as just another box maker and fore= verc an also ran.  H   God save their customers.  I can't figure how right minded person wou= ld= recommend a company that can't commit or execute on anything.C   -- Vance Haemmerled vance@alumni.caltech.edu           =e   ------------------------------  # Date: Mon, 25 Jun 2001 16:12:10 GMTq= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) - Subject: Re: Compaq proves their incompetenced0 Message-ID: <009FE0F8.8671F2D3@SendSpamHere.ORG>  b In article <9h7i8q$bld@gap.cco.caltech.edu>, vance@alumni.caltech.edu (Vance R. Haemmerle) writes:H >  It looks like Compaq has proven today that they are a souless companyG >with no business or management experience to execute on anything save  G >exporting intellectual property to other companies.  Last month I made G >the mistake of buying their stock because I figured the price was at a-G >year low and things couldn't get worse.  Today's announcemet proves meuC >wrong and today I've corrected my portfolio by selling all my CPQ.C   Good for you!  i    D >  That Compaq would choose to turn over their entire company to theF >Intel side of the business that they are having such a hard time withK >vs. Dell, etc. portends their future as just another box maker and forever 
 >an also ran.   G I saw the problems with VLIW with a MultiFlow (RIP) machine.  I have no H faith in this EPIC blunder.  So much for the 25 year life span of Alpha.    J >  God save their customers.  I can't figure how right minded person would> >recommend a company that can't commit or execute on anything.  G Emperor Bill must be falling off his seat and rolling on the floor withhH this news.  Any impediment to his eventually taking over all computerdomH has just been annihilated.  I'm just glad I own my home outright, have aG goodly sum stashed away, and some very wealth relatives with my name at $ the top of their bequeathment lists.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM              O city, n., 1. a place where trees are cut down and streets are named after them.    ------------------------------   Date: 25 Jun 2001 16:25:48 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)- Subject: Re: Compaq proves their incompetence , Message-ID: <9h7omc$c0i@gap.cco.caltech.edu>  b In article <9h7iov$bsl@gap.cco.caltech.edu>, vance@alumni.caltech.edu (Vance R. Haemmerle) writes:F >  Obviously these events today guarantee IA64 MONOPOLY status and the" >FTC should look into this deal.    \ It certainly looks like an attempt to eliminate competition through extra-competitive means.  H But interestingly enough there's still an outside chance that Compaq mayJ have picked the wrong horse.  Assuming the Hammer series appears in timelyJ fashion it may well turn out that the transition from 32 bit x86 -> 64 bitI x86 code is so trivial that people upgrade that way.  Intel loses, Compaq E loses HUGE, and AMD walks away with all the marbles.   Of course, thepD chances of this happening are fairly slim since both Dell and CompaqR are so locked into Intel that they'll likely refuse to build any machines with theJ AMD processors until and unless some other competitor beats them to death G with it.  And HP isn't likely to go with AMD either.  So with somethingdD like 85% of the server market locked into Intel it would have to be I somebody like Gateway to carry AMD into battle.  Or something completely  & out of the blue, like Fujitsu or Sony.  ( >Their previous restrictions on the saleG >of the Alpha FAB to Intel was not enough to stop Intel and Compaq from_2 >removing the competition given by the Alpha chip.  H The problem with the earlier FTC action was that they did not take into E account, or more likely could not do anything about, the problem thataE Digital/Compaq would simply refuse to place Alpha in competition withr Intel. i   Regards,   David Mathog mathog@caltech.edu? Manager, sequence analysis facility, biology division, Caltech uJ **************************************************************************J *                       RIP VMS & ALPHA                                  *J **************************************************************************   ------------------------------  % Date: Mon, 25 Jun 2001 17:20:24 +0100:- From: Tim Llewellyn <tim.llewellyn@bbc.co.uk>-- Subject: Re: Compaq proves their incompetencep) Message-ID: <3B3764C8.F826C793@bbc.co.uk>m   Robert Deininger wrote:   G > In article <9h7iov$bsl@gap.cco.caltech.edu>, vance@alumni.caltech.eduh > (Vance R. Haemmerle) wrote:d >c > >   And another thing... :)I > >eL > >   Turning over the future of the company to an unproven chip is Compaq'sJ > > way to turn over all responsiblity of their high-end systems to eventsN > > out of their control.  It's the easiest way for managers who can't executeF > > to have someone else to blame when the chip fails to come through. >o< > Very good point.  They wash their hands of responsibility.  D and admit by their own actions their incompetance to actually manage a real technical project.n  E Anyway, on the bright side, these outsourcing deals produce plenty of D nice cosy middle-management jobs on eaither side of the divide whereG all the dead wood useless gits and gals who gave up programming becausemE they were no good, moved into management, ruined a few projects there L and consequently get sidetracked into somewhere where they can "do no harm",
 can hang out.r   :-(s  ? I wouldn't care so much if it didn't affect my career prospects G (on the market soon, maybe I better take a job quick rather than have a 	 holiday).   --l6 Tim Llewellyn, OpenVMS Infrastructure, Remarcs Project0 MedAS at the BBC, Whiteladies Road, Bristol, UK.A Email tim.llewellyn@bbc.co.uk. Home tim.llewellyn@cableinet.co.uk   A I speak for myself only and my views in no way represent those ofp MedAS or the BBC.a   ------------------------------  % Date: Mon, 25 Jun 2001 17:28:23 +0100h- From: Tim Llewellyn <tim.llewellyn@bbc.co.uk>g- Subject: Re: Compaq proves their incompetence4) Message-ID: <3B3766A7.3B28DA41@bbc.co.uk>   * fabio_compaq@ep-bc.petrobras.com.br wrote:   > Look >eI > If this "portability" really works, may be we can Run OpenVMS under Hp,o > Dell, etcn >l  H A large part of VMS's stability is due to the limited number of hardware configurations, whichg1 makes testing all configurations at least doable.o  M I have 2 Dell PC's. I wouldn't wanna run VMS on the quality of hardware thanks you.   >a > Fbio CardosoY    --i6 Tim Llewellyn, OpenVMS Infrastructure, Remarcs Project0 MedAS at the BBC, Whiteladies Road, Bristol, UK.A Email tim.llewellyn@bbc.co.uk. Home tim.llewellyn@cableinet.co.ukr  A I speak for myself only and my views in no way represent those ofn MedAS or the BBC.n   ------------------------------  % Date: Mon, 25 Jun 2001 11:56:46 -0500-+ From: Christopher Smith <csmith@amdocs.com>O- Subject: RE: Compaq proves their incompetencegL Message-ID: <3B55D7F383B0D31197D9009027541CBF0D9D1FDB@cmiexch1.cmi.itds.com>   > -----Original Message-----6 > From: Tim Llewellyn [mailto:tim.llewellyn@bbc.co.uk]  ? > A large part of VMS's stability is due to the limited number -
 > of hardware- > configurations, which-3 > makes testing all configurations at least doable._  > > I have 2 Dell PC's. I wouldn't wanna run VMS on the quality  > of hardware thankn > you.  H Hear hear.  Now, not to be too defeatist yet.  It is possible to make anD Intel-based system work.  Sequent did some amazing things (as far as/ hardware), for instance, with cheap Intel CPUs.o   Regards,   Chriso  ! Christopher Smith, Perl Developern Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");y 'o  i   ------------------------------    Date: 25 Jun 2001 10:48:10 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)p- Subject: Re: Compaq proves their incompetence-, Message-ID: <xEJNISi9gaYM@malvm5.mala.bc.ca>  C In article <5.1.0.14.2.20010625085538.02818ea0@ntbsod.psccos.com>,  *    Dan O'Reilly <dano@process.com> writes:  M > Ummmmmmm...pardon playing the devil's advocate here, but didn't DEC do that F > with the VAX, and particularly with the Alpha?  Neither was a proven- > technology when they were first released...x > J     Isn't that a bit different - those were their chips and their survivalH depended on making them work. Does Intel *need* IA64 to succeed or couldE they survive by continuing to crank out enhancements to Pentium? It'sRD often stated that nobody needs 64bits on the desktop and Intels doneE quite well so far being a producer of desktop processors. Sure they'dlE like to go after the big server market with IA64, but it's probably as' small percentage of their total market.e   ------------------------------    Date: 25 Jun 2001 11:24:33 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) : Subject: Compaq Solutions Alliance web site now accessible3 Message-ID: <4Z49jsfYVSQ9@eisner.encompasserve.org>8  A For those ISVs who had given up on the Compaq Solutions Alliance,eC I note today that they have changed their website so that it can bet3 read from secured browsers.  http://csa.compaq.com/h  N ==============================================================================N Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> ClustersN ==============================================================================   ------------------------------  # Date: Mon, 25 Jun 2001 16:30:59 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)u> Subject: Re: Compaq Solutions Alliance web site now accessible0 Message-ID: <009FE0FB.276B2B83@SendSpamHere.ORG>  o In article <4Z49jsfYVSQ9@eisner.encompasserve.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:oB >For those ISVs who had given up on the Compaq Solutions Alliance,D >I note today that they have changed their website so that it can be4 >read from secured browsers.  http://csa.compaq.com/ >nO >==============================================================================sO >Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> Clusters O >==============================================================================,   It still coughs up:0  4 No proper message information found in database for 5 crz_restrict_displayMozilla/3.03Gold (X11; I; OpenVMS0  V7.2-1 AlphaServer DS20 500 MHz)    . for me.   http://csa.compaq.com/ -> Useless... --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMd             O city, n., 1. a place where trees are cut down and streets are named after them.n   ------------------------------    Date: 25 Jun 2001 12:07:06 -0500- From: koehler@encompasserve.org (Bob Koehler)e! Subject: Compaq switches to IA-64t3 Message-ID: <tOQ$grlL8MBg@eisner.encompasserve.org>v  H In the late 70's, DEC introduced the new VAX architecture "for the 80s".? It managed to make it most of the way through the 90s, althoughrE declining.  In the early 90s DEC introduced the Alpha, and claimed to D hope to get 15 years from it.  That would take us through the middleG aughts.  It is not entirely to early to be looking for the replacement,eG if a promising chip has been announced and there is a lot of work to do'H to keep the old cash generating software alive, it may be a good time to get started.  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporation = NASA GSFC Flight Software       | Federal Sector, Civil Group E                                 | please remove ".aspm" when replying    ------------------------------    Date: 25 Jun 2001 12:32:19 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)-% Subject: Re: Compaq switches to IA-64-3 Message-ID: <UqjcvlabkKSb@eisner.encompasserve.org>-  c In article <tOQ$grlL8MBg@eisner.encompasserve.org>, koehler@encompasserve.org (Bob Koehler) writes:: > J > In the late 70's, DEC introduced the new VAX architecture "for the 80s".A > It managed to make it most of the way through the 90s, althoughcG > declining.  In the early 90s DEC introduced the Alpha, and claimed to F > hope to get 15 years from it.  That would take us through the middleI > aughts.  It is not entirely to early to be looking for the replacement,yI > if a promising chip has been announced and there is a lot of work to doiJ > to keep the old cash generating software alive, it may be a good time to > get started.  G In sailboat match racing, this is called "covering".  The boat in fronttG moves to whichever side of the course the boat behind has chosen.  That-G way a sudden wind shift will not change their lead by favoring the sidegF of the course they are not on.  If Itanium fails, VMS will be no worse off than HP-UX.s   ------------------------------  # Date: Mon, 25 Jun 2001 16:55:08 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)c% Subject: Re: Compaq switches to IA-64r0 Message-ID: <009FE0FE.86E84F17@SendSpamHere.ORG>  o In article <UqjcvlabkKSb@eisner.encompasserve.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:rd >In article <tOQ$grlL8MBg@eisner.encompasserve.org>, koehler@encompasserve.org (Bob Koehler) writes: >> oK >> In the late 70's, DEC introduced the new VAX architecture "for the 80s". B >> It managed to make it most of the way through the 90s, althoughH >> declining.  In the early 90s DEC introduced the Alpha, and claimed toG >> hope to get 15 years from it.  That would take us through the middlepJ >> aughts.  It is not entirely to early to be looking for the replacement,J >> if a promising chip has been announced and there is a lot of work to doK >> to keep the old cash generating software alive, it may be a good time toa >> get started.b >eH >In sailboat match racing, this is called "covering".  The boat in frontH >moves to whichever side of the course the boat behind has chosen.  ThatH >way a sudden wind shift will not change their lead by favoring the sideG >of the course they are not on.  If Itanium fails, VMS will be no worsee >off than HP-UX.  G And in a Marathon (such as the NY) there is only one winner and all the G others are, technically, the losers.  I'd rather be at the front of them9 race than the safety in numbers in the company of losers.  --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM?            bO city, n., 1. a place where trees are cut down and streets are named after them.r   ------------------------------  + Date: Mon, 25 Jun 2001 17:31:32 +0000 (UTC)a' From: david20@alpha1.mdx.ac.uk (D.Webb)M% Subject: Re: Compaq switches to IA-64 + Message-ID: <9h7shk$gor$1@aquila.mdx.ac.uk>d  c In article <tOQ$grlL8MBg@eisner.encompasserve.org>, koehler@encompasserve.org (Bob Koehler) writes:' >oI >In the late 70's, DEC introduced the new VAX architecture "for the 80s".v@ >It managed to make it most of the way through the 90s, althoughF >declining.  In the early 90s DEC introduced the Alpha, and claimed toE >hope to get 15 years from it.  That would take us through the middle H >aughts.  It is not entirely to early to be looking for the replacement,H >if a promising chip has been announced and there is a lot of work to doI >to keep the old cash generating software alive, it may be a good time tof
 >get started.i >     7 As I recall Alpha was supposed to last 25 years not 15.t  
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  % Date: Mon, 25 Jun 2001 13:22:15 -0000e- From: wspencer@nospam.ap.org (Warren Spencer)M; Subject: Compaq to phase out computer lines not using Intel 3 Message-ID: <90CB5605Awspenceraporg@207.126.101.97>e   Terry was right; big news:  - http://biz.yahoo.com/rf/010625/n25216200.htmle   ws   -- s Warren Spencer <<< My opinions are my own >>>   ------------------------------    Date: 25 Jun 2001 08:33:22 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)tN Subject: Compaq Transfers Alpha to Intel after EV7 (was: Alpha design team...)3 Message-ID: <23G+ts2tGHlI@eisner.encompasserve.org>   K The story is up at http://www.compaq.com/newsroom/pr/2001/pr2001062501.htmla   ------------------------------    Date: 25 Jun 2001 09:08:30 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) R Subject: Re: Compaq Transfers Alpha to Intel after EV7 (was: Alpha design team...)3 Message-ID: <HOp9S4c9oTi1@eisner.encompasserve.org>   B http://www.compaq.com/newsroom/pr/2001/pr2001062501.html now says:  >      Compaq and Intel to Accelerate Enterprise Server Roadmaps  G      Compaq to Transfer Technology to Intel and Move Its 64-bit Servers E      to Intel Itanium Processor Family, Vows to Redefine Enterprise.  			     Server Price/Performance  F      NEW YORK, June 25, 2001 - Compaq Computer Corporation (NYSE: CPQ)F      and Intel Corporation today announced a multi-year agreement thatC      accelerates availability of next-generation enterprise servers H      based on the Intel Itanium processor family. Compaq will transferE      key enterprise processor technology to Intel and consolidate itsI=      entire 64-bit server family on the Itanium architecture.   G      The companies will work together to expand marketplace adoption ofpH      the Itanium processor family. Compaq will build on that high-volume8      platform to provide its customers with unparalleled      price/performance.h  G      Today's technology and marketing agreement joins Compaq's advancedtH      systems engineering expertise and large installed base with Intel'sG      leading microprocessor design and world-class volume manufacturingiD      capabilities. Compaq will develop the broadest family of serverF      productsfrom supercomputers to Web serversthat all operate on aB      single microprocessor architecture, the Itanium architecture.H      Compaq customers will benefit from the most advanced system designsE      at the lowest possible cost with complete investment protection.         Announcement Overview  )      Details of the announcement include:o  B      * Compaq will consolidate its entire 64-bit family of serversC        onto the Itanium microprocessor architecture by 2004. In onetE        bold stroke, Compaq is extending its 10 years of leadership in C        64-bit computing for the next decade and beyond. Compaq willfD        deliver an additional generation of Alpha technology (EV7) toD        advance system performance prior to the new generation of the@        Itanium-based systems, for which the company will provide>        tools and support for a smooth customer transition. The>        company will also design and build new NonStop Himalaya<        systems based on MIPS chip technology until the first@        shipments of Itanium-based systems are available in 2004.  ?      * The new family of Compaq enterprise servers will support.D        Tru64 UNIX, OpenVMS, and NonStop Kernel, complementing the=        company's market leadership in Windows 2000 and Linux.s  B      * Compaq is transferring significant Alpha microprocessor and9        compiler technology, tools and resources to Intel.e  D      * Compaq will immediately begin to port Tru64 UNIX, OpenVMS andD        NonStop Kernel operating systems and development tools to theA        Itanium processor family. Operating system and applicationtD        development tools compatibility protects customers' long-termA        investments in Tru64 UNIX, OpenVMS, and NonStop Kernel, ashD        well as advancing the capabilities for Windows 2000 and Linux        on ProLiant.r  D      * Compaq and Intel have agreed to joint engineering development>        focused on advanced parallelism for high-end computing.  E      "The bottom line is: we are creating great customer value," saidoC      Michael Capellas, chairman and CEO of Compaq. "Our move to the_E      Itanium architecture provides customers and independent softwarehG      vendors with the most compelling roadmap to next-generation servereG      technology. Customers get increased performance, price/performanceuH      and application support. This reinforces our commitment to customerH      investment protection as well as providing the best path for futureG      growth. We believe Intel's architecture is the best choice for the*E      enterprise, and for our customers this is truly the best of both 
      worlds."   C      "We are delighted that the market segment leader in enterprise*F      servers is bringing its high-end systems expertise to the ItaniumG      processor family," said Craig Barrett, president and CEO of Intel.->      "This agreement with Compaq furthers our shared vision of=      delivering customer value by advancing high-performance,nH      high-volume building blocks. Our agreement will bring higher levelsE      of performance, availability and scalability to systems based on #      the Itanium processor family."m  H      Compaq customers and software vendors such as Black and Decker, theD      London Stock Exchange and Oracle Corporation said today's movesF      will strengthen their current and long-term investments in CompaqC      systems based on Intel's architecture. "Oracle is very excited.G      about Compaq Tru64 UNIX coming to the Intel platform. Intel, Tru64o;      UNIX, and Oracle9i and Real Application Clusters is anoG      unprecedented combination," said Lawrence J. Ellison, chairman andnC      CEO of Oracle Corporation. (See additional industry commentarye      attached to this release)        Technology Transfer  F      Under the multi-year technology agreement, Compaq is transferringH      significant Alpha tools and engineering resources to Intel, as wellE      as granting licenses to Compaq's Alpha microprocessor technologyc      and compilers.   :      Over the next couple of years, several hundred CompaqB      microprocessor engineers, compiler experts and infrastructureH      employees will be offered employment with Intel. A portion of theseD      engineers will remain with Compaq to complete a next-generationH      Alpha microprocessor development effort currently underway but will@      transfer to Intel as their projects are completed. Compaq'sH      transfer of technology and resources to Intel is expected to resultD      in an acceleration and enhancement of Intel's Itanium processor
      roadmap.B  E      The companies are investing in a multi-year marketing program tokH      enable software vendors and Compaq's installed base of customers toA      move their applications to servers incorporating the Itaniumt      processor family.  ,      AlphaServer, NonStop, ProLiant Roadmaps  F      Compaq said it will continue to design and build new AlphaServerE      systems based on current and upcoming Alpha processor technologysD      through 2003. The company plans to upgrade the current high-endH      AlphaServer GS Series with a 1 GHz Alpha processor this summer. TheB      next-generation EV7 Alpha processor, which is currently underA      development, will power a new AlphaServer system planned for-!      introduction late next year.e  C      Compaq also will design and build new NonStop Himalaya systemsoG      based on MIPS chip technology until the first shipments of Itanium5<      processor-based Himalaya systems are available in 2004.  A      The company added that it will also continue to aggressivelywH      advance its ProLiant server roadmap based on the Itanium processor,9      with the first Itanium-based systems due in Q3 2001.e  E      Compaq, the market-leading provider of industry standard servers B      using the Intel architecture, will continue its commitment toH      deliver a rich roadmap of 32-bit Intel architecture-based ProLiantG      servers to meet customers' scale-out and scale-up requirements. To C      address customers' scale-out requirements, Compaq will offer aoH      broad range of ProLiant servers including future generations of itsH      ultra-dense servers, the forthcoming hyper-dense blade architecture@      servers, and other modular server form factors. Compaq willG      continue to meet customers' scale-up requirements with current andcC      future generations of its popular ProLiant 8-way servers usingaG      Intel 32-bit architecture, as well as developing a 32-way ProLiant.2      server based on the Itanium processor family.  G      "We will continue to invest aggressively in scale-up and scale-out B      of Microsoft technology," Michael Capellas said. "And we will>      continue to work closely with Microsoft to drive the nextC      generation of Web services and Web delivery through Microsoft.i
      NET."        About Intel  F      Intel, the world's largest chip maker, is leading manufacturer ofA      computer, networking, and communication products. AdditionalaB      information about Intel is available at http://www.intel.com.        About Compaqo  D      Compaq Computer Corporation, a Fortune Global 100 company, is a@      leading global provider of technology and solutions. CompaqE      designs, develops, manufactures, and markets hardware, software,:C      solutions, and services, including industry-leading enterprise E      computing solutions, fault-tolerant business-critical solutions, A      and communications products, commercial desktop and portableg>      products, and consumer PCs that are sold in more than 200F      countries. Information on Compaq and its products and services is(      available at http://www.compaq.com.        Notes:=  G      Today's press release contains forward-looking statements based onoH      current expectations or beliefs, as well as a number of assumptionsG      about future events. These statements are not historical facts and-E      are subject to factors and uncertainties that could cause actual =      results to differ materially from those described in thecG      forward-looking statements. The forward-looking statements address9D      a variety of subjects including, for example, the timing of theB      adoption by Compaq of the Itanium processor family, continuedH      AlphaServer and NonStop Himalaya systems development by Compaq, theA      timing of porting by Compaq of certain operating systems and @      development tools to the Itanium processor environment, theG      expected date of the transfer of technology and engineers to Intel=G      and the potential benefits of the transfer. The following factors,mG      among others, could cause actual results to differ materially from=G      those described in these forward-looking statements: the risk thatmF      the adoption by Compaq of the Itanium processor family is delayedC      or is otherwise not successful, the risk that the Compaq Alphac<      tools, engineering resources and technology will not beD      successfully integrated by Intel, and increased competition andF      technological changes in the industries in which Compaq and IntelF      compete. For a detailed discussion of these and other statements,G      please refer to Intel and Compaq's filings with the Securities andtF      Exchange Commission, including the Annual Reports on Form 10-K ofF      each of Intel and Compaq for 2000, Quarterly Reports on Form 10-QC      for the most recently ended quarter, and Intel's 2001 Businesse(      Update release issued June 7, 2001.   ------------------------------  % Date: Mon, 25 Jun 2001 02:10:30 -0400u' From: "Bill Todd" <billtodd@foo.mv.com>e1 Subject: Re: Compaq's Alpha design team for sale?e( Message-ID: <9h6kej$6pg$1@pyrite.mv.net>  - "John Santos" <JOHN@egh.com> wrote in message 0 news:1010624234351.38769A-100000@Ives.egh.com..." > On Mon, 25 Jun 2001, mulp wrote: >- > >-1 > > "John Santos" <JOHN@egh.com> wrote in messageo4 > > news:1010623234633.38769B-100000@Ives.egh.com...I > > > If VMS is ported to IA64, I would expect Compaq to do as good a job L > > > of ensuring compatibility as DEC did with the Alpha port.  If they do, > >-J > > Why would you expect that?  Are you unaware of the number of engineersK > > laidoff in the past 7-8 years, the number of key people that have left,- ofJ > > the number of products sold off (to be abandoned/milked), of the nuber ofH > > people who left vms related product work to work on Windows or unix. > F > Historical precedent.  What evidence do you have that they won't?  IE > don't know the numbers of engineers who have left.  Do you?  Why ifcE > you think these numbers are relevent don't you post them instead oft@ > asking me for them?  I think you are talking through your hat.C > Do you have inside information that Alpha is actually going to bee- > sold, or are you just spreading fertilizer?a  D You might want to consider that the source is someone who has workedK intimately in and/or with DEC (and more recently the DEC portion of Compaq) A central engineering - RSX, then VMS, then both VMS and Unix - for H approximately 25 years.  I don't know whether he has absolutely accurateL numbers to give you, but he sure as hell is in a position to reel off a list! of most of the significant names.i   - bill   ------------------------------  # Date: Mon, 25 Jun 2001 08:19:05 GMTe. From: "mulp" <michaelpettengill@earthlink.net>1 Subject: Re: Compaq's Alpha design team for sale?uB Message-ID: <ZtCZ6.408$AV6.56680@newsread2.prod.itd.earthlink.net>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:1EVpZH1maSiP@eisner.encompasserve.org... > > You make it sound that clustering over Ethernet at this time> > is a bad thing.  Guess you aren't keeping current.  Take the; > time to peel through this, it includes CI, Fast Ethernet,t3 > Gigabit Ethernet, FDDI, ATM , and Memory Channel.   I Yeah, I'm a little out of the game; I haven't been involved in setting uprI the VMScluster environment used to hammer storage and interconnect for 10u weeks.  J But I was the person who designed the lab and network where the VMSclusterL testing has been done for the past decade.  I setup and managed the 20 or soJ switches ranging from 10 meg Ethernet, to GIGAswitch/FDDI, GIGAswitch/ATM,H 100 meg, and gigabit Ethernet switches.  And 150 CI drops, 250-350 Fibre. Channel drops, 12 Fibre Channel switches, etc.  H Oh, and I know from experience that the failure rate on non-DEC EthernetK switches is rather high, but what's a few undetected data corruptions everyoJ now and then.  Personally, I wouldn't trust any LAN switch without testingH it, but you won't find much in the way of test tools that are capable of9 detecting the bugs in the leading switches on the market.    ------------------------------  % Date: Mon, 25 Jun 2001 11:05:02 +0200e5 From: Martin Knoblauch <Martin.Knoblauch@TeraPort.de>-1 Subject: Re: Compaq's Alpha design team for sale?i+ Message-ID: <3B36FEBE.5A5C6769@TeraPort.de>n   Robert Deininger wrote:h > F > In article <CIEJLCMNHNNDLLOOGNJIOECFCNAA.tom@kednos.com>, Tom Linden > <tom@kednos.com> wrote:l > M > > Compaq certainly didn't buy Digital because of Alpha.  It was the serviceh > > organization thatkJ > > they wanted.  I suspect that the cost to keep pace with Intel is high. > > Never understood4 > > why Digital didn't pursue the mips architecture. > K > DEC used MIPS in some systems, and apparently found it lacking.  Alpha ishJ > clearly light-years ahead of MIPS.  It's hard to say where MIPS would beH > today if active development had continued.  But Alpha is nothing to be
 > ashamed of.a >   F  "light years ahead" seems to be a bit of exaggeration. Maybe a factorA of two. At least for SpecCPU, the efficiency of MIPS (measured in D Spec/MHz, whatever that means) seems to be slightly better for MIPS.  C  Not to say that Alpha is bad. Not at all. Both architectures` main F problem is not prformance. In both cases it is Applications, Marketing and managment stupidity.  H  But before starting to worry seriously, lets see what happens today :-)   Martin -- (B ------------------------------------------------------------------B Martin Knoblauch         |    email:  Martin.Knoblauch@TeraPort.de7 TeraPort GmbH            |    Phone:  +49-89-510857-30967 C+ITS                    |    Fax:    +49-89-510857-111o5 http://www.teraport.de   |    Mobile: +49-170-4904759-   ------------------------------    Date: 25 Jun 2001 06:39:08 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) 1 Subject: Re: Compaq's Alpha design team for sale?s3 Message-ID: <goUo6sFCrAeU@eisner.encompasserve.org>h  \ In article <3B36B5FB.5590D2AA@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes:  M > Think of it this way: Compaq donates Alpha to Intel. Intel starts to add togP > IA64 what it takes to port NSK and VMS. But in doing so, it also enables NT to" > take advantage of those features  E Waiting for that to happen could mean a long successful life for VMS.e   ------------------------------  % Date: Mon, 25 Jun 2001 07:03:12 -0400l) From: "Neil Rieck" <n.rieck@sympatico.ca>m1 Subject: Re: Compaq's Alpha design team for sale?-9 Message-ID: <TTEZ6.2567$l45.606180@news20.bellglobal.com>s  > "Malcolm Dunnett" <nothome@spammers.are.scum> wrote in message& news:pNUIa5X406sE@malvm5.mala.bc.ca...   [snip]  F >    But you then assume that all the existing Alpha products would beJ > ported to a new architecture. There were certainly products on VAX whichG > never got ported - many of the people who are still running VAXen are J > doing so for that very reason. I've heard BASIC almost didn't get portedK > to Alpha - if it hadn't made it we'd still be a VAX shop ( or more likelyTI > we'd now be running Solaris or something of that ilk ). Some stuff onlyeJ > exists because it's been VESTed ( eg FMS ). Will there be a VEST (AEST?)4 > for IA64 than can translate the translated images?   [snip]  F Back in 1986 our IS/IT group forced us to use VAX-BASIC. At the time II thought this was a limitation (we wanted Pascal) but then discovered thathC VAX-BASIC had many Fortran features as well as built-in support foraK Sequential, Relative and Indexed file types. The VAX-BASIC product name waseE changed to DEC-BASIC and now Compaq BASIC, and we're currently (2001)  migrating these apps to Alpha.  ? http://www.openvms.compaq.com/commercial/basic/basic_index.htmll  
 Neil Rieck Kitchener/Waterloo/Cambridge,s Ontario, Canada.! http://www3.sympatico.ca/n.rieck/s   ------------------------------    Date: 25 Jun 2001 08:16:23 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)i1 Subject: Re: Compaq's Alpha design team for sale? 3 Message-ID: <cZbTJ1YY4P2r@eisner.encompasserve.org>   C Today the Inquirer says at http://www.theinquirer.net/2506alpha.htm @ that Compaq has confirmed it is transferred Alpha development to- Intel but not yet released financial details.A   ------------------------------    Date: 25 Jun 2001 08:19:37 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) 1 Subject: Re: Compaq's Alpha design team for sale?p3 Message-ID: <kRVvT41A0MGO@eisner.encompasserve.org>m  = http://www.compaq.com/ right now has a new pointer that says:e  H     "Live Webcast of Compaq and Intel Announcement: Today at 9 a.m. EDT"   That link points to:  : 	http://www.compaq.com/newsroom/presspaq/062501/index.html   which right now gives me:T   	404 Object Not Found    ------------------------------  + Date: Mon, 25 Jun 2001 12:21:31 +0000 (UTC) 9 From: Roar =?iso-8859-1?Q?Thron=E6s?= <roart@nvg.ntnu.no>n1 Subject: Re: Compaq's Alpha design team for sale?o- Message-ID: <9h7acb$7sv$1@tyfon.itea.ntnu.no>m  . JF Mezei <jfmezei.spamnot@videotron.ca> wrote:  K : Microsoft realises that NT isn't quite ready for prime time, so it allows N : Compaq to keep the mission critical stuff on Tandem and what is left of VMS.O : And it is to Microsoft's advantage to have Compaq retain these customer untilr7 : NT is ready otherwise those customers will go to Sun.s  9 BTW, how is it going for Windows Datacenter on big "PC"s?   O : Dell can't bring customers to Microsoft. Only Compaq can deliver the types ofeN : customers that Microsoft doesn't yet have. MS knows it can't count on IBM toG : deliver mission critical customers to NT. But it can count on Compaq.l  M : Think of it this way: Compaq donates Alpha to Intel. Intel starts to add torP : IA64 what it takes to port NSK and VMS. But in doing so, it also enables NT to  H The CPU itself might be one thing, but the hardware NSK runs on is quite special.  O : take advantage of those features and also provide fault tolerant features. SotO : donating Alpha and Alpha engineers to Intel will allow intel to shape IA64 sooK : that NT can also become more fault tolerant and eventually take over from ' : customers who were on Tandem and VMS.e  O : So essentially, Compaq's job is to keep VMS and NSK customers locked in untilh7 : NT is ready for prime time. That is the way I see it.r  0 Assuming it will be ready, and ever catching up., Regarding Compaq giving technology to MS: It@ might also be a trick, since there may be severe difficulties in? integrating more advanced things into NT or changing NT itself.a  K Compaq (and the two bought companies DEC and Tandem) and IBM are (and were)bJ both hardware and os/software companies, and they seem to thereby have had8 advantages building systems and highly reliable systems.   Like: L DEC started VAX and VMS in 1975, and VAX was finished late 1977 and VMS came early 1978.d  I 386 came in 1985, 386 PCs became popular in 1988, in 1988 Gates wanted tod8 fully support it and make a new os, in 1993 Win NT came.  D Will DEC/Tandem as easily (or ever) have developed their clustering/G reliability stuff (respectively) without both hw and sw/os divisions inn their company?   -- t
 -Roar Throns    ------------------------------    Date: 25 Jun 2001 09:14:30 -05009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow)m1 Subject: Re: Compaq's Alpha design team for sale?c3 Message-ID: <YmBnVR2kjRNs@eisner.encompasserve.org>o  [ In article <3B339F63.1588BD0@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: = > Larry Kilgallen quoted someone else from another newsgroup:rJ >> > Do you think that, backed by another vendor and not Compaq, Alpha hasG >> > a better chance? Imagine its technical excellence, coupled with anxH >> > owner who is really committed to it, and knows the art of marketing >> > and selling?t > P > I say yes. Compaq has done nothing to leverage the Alpha asset. It is a littleO > jewel that is kept hidden in the chest and not made to work for shareholders.IO > So a company that is capable of buying Alpha, making a very public commitmenteL > quickly followed by actions/advertising and cheap alpha based computers to5 > fill the gap would gain credibility rather quickly.T  J If this had been done back in 1997, when digital sold Intel it's FAB, thenK Alpha could already be the Pentium successor.  Instead it's heading for the A trash-can, and we'll be stuck with IA64, for better or for worse.f  L Surely there must be some chip vendor who could have supported and developedJ Alpha as a competitor to IA64, to the benefit of all. Anyone except AMD of' course, which is where Palmer landed...g   ------------------------------    Date: 25 Jun 2001 09:19:04 -05009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow) 1 Subject: Re: Compaq's Alpha design team for sale?o3 Message-ID: <ZXHSdpDY3Y5k@eisner.encompasserve.org>i  g In article <zNPY6.47086$uR5.5160526@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes: H > I don't know why companies play the game of "let's focus on only a fewN > products to maximize profits". This turns them into "one trick ponies" whichL > makes them more vulnerable to failure. In essence, that's what happened toN > Nortel; they decided to focus on the optical networking market which quicklyK > saturated and then hit the wall during the "dot com" melt down. Companies G > shouldn't ever shut down profitable revenue sources. All those little  > profits do add up.  J I recall my trip to ZKO when DEC adopted the "one company one strategy oneK solution" and dumped everything but VMS (i.e. all the PDP-11 stuff). In RSX-K land there was an easter basket with the slogan "one egg one basket" on it.m  N > So I'm left with just one question; "Just what the hell is Compaq thinking?"   Compaq thinking? Military Intelligence.
 Jumbo Shrimp!n   ------------------------------  % Date: Mon, 25 Jun 2001 09:24:46 -0400r  From: John Santos <JOHN@egh.com>1 Subject: Re: Compaq's Alpha design team for sale?u6 Message-ID: <1010625091652.38769A-100000@Ives.egh.com>  % On Mon, 25 Jun 2001, Bill Todd wrote:i   > / > "John Santos" <JOHN@egh.com> wrote in message.2 > news:1010624234351.38769A-100000@Ives.egh.com...$ > > On Mon, 25 Jun 2001, mulp wrote: > >s > > >n3 > > > "John Santos" <JOHN@egh.com> wrote in messagey6 > > > news:1010623234633.38769B-100000@Ives.egh.com...K > > > > If VMS is ported to IA64, I would expect Compaq to do as good a jobeN > > > > of ensuring compatibility as DEC did with the Alpha port.  If they do, > > >hL > > > Why would you expect that?  Are you unaware of the number of engineersM > > > laidoff in the past 7-8 years, the number of key people that have left,  > ofL > > > the number of products sold off (to be abandoned/milked), of the nuber > ofJ > > > people who left vms related product work to work on Windows or unix. > >yH > > Historical precedent.  What evidence do you have that they won't?  IG > > don't know the numbers of engineers who have left.  Do you?  Why ifaG > > you think these numbers are relevent don't you post them instead ofcB > > asking me for them?  I think you are talking through your hat.E > > Do you have inside information that Alpha is actually going to beh/ > > sold, or are you just spreading fertilizer?  > F > You might want to consider that the source is someone who has workedM > intimately in and/or with DEC (and more recently the DEC portion of Compaq)sC > central engineering - RSX, then VMS, then both VMS and Unix - foraJ > approximately 25 years.  I don't know whether he has absolutely accurateN > numbers to give you, but he sure as hell is in a position to reel off a list# > of most of the significant names.r >  > - bill  C I gathered that he was a long-time DEccie from his other posts, buteB a) he didn't say so and b) I can't recall ever having heard of him@ before yesterday.  So as far as I'm concerned, he has zero track record.c  C Plenty of other people claiming to know everything about everythingCC have popped up on this newsgroup in the past, and many of them havet$ turned out to be nothing but trolls.  C His first post (at least in the order that my news server presentedr= them was a response to one of my posts, in which he asks me ab> question that I had already ansered in the very next sentence.   -- u John Santosa Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------    Date: 25 Jun 2001 09:24:21 -05009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow)d1 Subject: Re: Compaq's Alpha design team for sale?t3 Message-ID: <NEs7YPQBTFTN@eisner.encompasserve.org>   Z In article <lpi9jt472dsbotidin25o0e73e4k55ejmb@4ax.com>, LBohan@dbc.spam_less..com writes:% > if the Intel buy of Alpha is true, n1 > and by implication, eventually, OVMS/NSK/Tru64 o! > IA64 porting efforts, I wonder:d > * > What hdw/PAL features might need adding + > to IA64 in order that it would play well   > with OVMS/NSK? > 2 > how long it might take for a IA64 OVMS to reach ) > performance parity, with an Alpha OVMS.e  I Not long at all, since Intel will no doubt pull the plug on further Alpha' development.   ------------------------------    Date: 25 Jun 2001 09:29:47 -05009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow)B1 Subject: RE: Compaq's Alpha design team for sale?a3 Message-ID: <K+qjfhLCTYM6@eisner.encompasserve.org>$  ] In article <CIEJLCMNHNNDLLOOGNJIOECFCNAA.tom@kednos.com>, Tom Linden <tom@kednos.com> writes:-K > Compaq certainly didn't buy Digital because of Alpha.  It was the serviceh > organization thatoH > they wanted.  I suspect that the cost to keep pace with Intel is high. > Never understood2 > why Digital didn't pursue the mips architecture.    L They did. The DECserver family that preceeded Alpha was MIPS based. Remember ULTRIX?    ------------------------------    Date: 25 Jun 2001 09:27:05 -05009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow)o1 Subject: Re: Compaq's Alpha design team for sale?s3 Message-ID: <p$Hh+gijmSWC@eisner.encompasserve.org>   U In article <3B34C276.94380BAB@home.com>, Sean O'Banion <seanobanion@home.com> writes:lE > "If  after all the 'We support Alpha', Compaq can give away or sellwJ > Alpha, what's to stop them from dropping VMS or Tru64 just like they didF > NT/Alpha?  Where does that put us in 3 to 5 years?" says management.J > Even if the distrust simply stalls decisions for a year or so that go toH > VMS or Tru64 in any case, the resulting dip in sales would also become > more FUD-fuel. > J > My company has a very large "Buy Compaq" contract, that mostly covers NTG > servers, and VMS and Tru64 help support the management wisdom of thattF > decision.  But it is just a likely that, if Compaq is seen to be notH > trustworthy, next year they could easily go to Dell for the NT serversE > (which was already "decided" and then shot down), and VMS and Tru64fG > would be viewed as platforms to get away from very soon.  We just now-J > are getting management to trust that VMS is viable option, especially in@ > light of the number of in-house failed projects to replace it. > F > If the thrust of this is for Compaq to be less like HP and more like. > Gateway (or Dell), why not just buy Gateway?  J I remember when I was a DECcie, and there were constant comments about DECL buying Compaq. At the rate Compaq is going, they may soon be called Gateway.< Or Dell. Either one of those could use a service company :-)   ------------------------------  % Date: Mon, 25 Jun 2001 09:02:25 -0500l+ From: Christopher Smith <csmith@amdocs.com>a1 Subject: RE: Compaq's Alpha design team for sale?eL Message-ID: <3B55D7F383B0D31197D9009027541CBF0D9D1FD0@cmiexch1.cmi.itds.com>   > -----Original Message-----6 > From: Terry C Shannon [mailto:shannon@world.std.com]  H > Whether you like or hate Intel, the firm is no slouch when it comes toF > marketing, Doh, maybe mindshare actually is a prerequisite to market > share!  L Yep, all VMS needs is a group of disco-space-suit-guys and some questionable special-effects. ;)h   Regards,   Chrise  ! Christopher Smith, Perl DeveloperE Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");a ',  w   ------------------------------    Date: 25 Jun 2001 10:07:25 -0500+ From: young_r@encompasserve.org (Rob Young) 1 Subject: Re: Compaq's Alpha design team for sale?h3 Message-ID: <UEzhrjLwjwk8@eisner.encompasserve.org>   s In article <ZtCZ6.408$AV6.56680@newsread2.prod.itd.earthlink.net>, "mulp" <michaelpettengill@earthlink.net> writes:e > : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:1EVpZH1maSiP@eisner.encompasserve.org...<? >> You make it sound that clustering over Ethernet at this timek? >> is a bad thing.  Guess you aren't keeping current.  Take thee< >> time to peel through this, it includes CI, Fast Ethernet,4 >> Gigabit Ethernet, FDDI, ATM , and Memory Channel. > K > Yeah, I'm a little out of the game; I haven't been involved in setting upsK > the VMScluster environment used to hammer storage and interconnect for 10l > weeks. > L > But I was the person who designed the lab and network where the VMSclusterN > testing has been done for the past decade.  I setup and managed the 20 or soL > switches ranging from 10 meg Ethernet, to GIGAswitch/FDDI, GIGAswitch/ATM,J > 100 meg, and gigabit Ethernet switches.  And 150 CI drops, 250-350 Fibre0 > Channel drops, 12 Fibre Channel switches, etc. > J > Oh, and I know from experience that the failure rate on non-DEC EthernetM > switches is rather high, but what's a few undetected data corruptions everyML > now and then.  Personally, I wouldn't trust any LAN switch without testingJ > it, but you won't find much in the way of test tools that are capable of; > detecting the bugs in the leading switches on the market.  >   > 	Oh... my apologies.  What do you recommend for interconnects, 	given a choice if Alpha only?   				Rob    ------------------------------  % Date: Mon, 25 Jun 2001 09:38:46 -0500|+ From: Christopher Smith <csmith@amdocs.com>-1 Subject: RE: Compaq's Alpha design team for sale?0L Message-ID: <3B55D7F383B0D31197D9009027541CBF0D9D1FD4@cmiexch1.cmi.itds.com>   > -----Original Message-----6 > From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]  ? > Terry Shannon says that we shouldn't be worrying. However, I s
 > do not haven@ > confidence in VMS being handled properly by Compaq because so  > far Compaq= > hasn't yet proven to me that I can blindly trust Compaq to n > take the right > decisions for VMS.   [snip]  < > Do you trust Compaq to pitch a VMS solution to a customer  > when an NT solutionV
 > exists ?  I No, I don't believe Compaq has earned my trust so far.  Terry Shannon, onNH the other hand, has, so I'll take him at his word until more information- comes to light that will make things clearer.0   Regards,   Chrism    ! Christopher Smith, Perl Developerr Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");  '       ------------------------------  # Date: Mon, 25 Jun 2001 15:17:13 GMTe From: LBohan@dbc.spam_less..comh1 Subject: Re: Compaq's Alpha design team for sale?t8 Message-ID: <0ukejtoh2uqhlc8c97lmv8n02ps5b15utt@4ax.com>  0 On Fri, 22 Jun 2001 06:13:57 -0400, "Neil Rieck" <n.rieck@sympatico.ca> wrote:i  F >Compaq's Alpha design team for sale? Let's hope this is only a rumor! >g( >http://www.theinquirer.net/22060101.htm >c >Neil Rieckn >Kitchener/Waterloo/Cambridge, >Ontario, Canada. " >http://www3.sympatico.ca/n.rieck/  7 so..., in theory, in 4-5 years, we might able to buy a r6 DELL (or IBM) IA64 server to run VMS on ... go figure.  / I would've liked to see a commitment as far as d/ EV8, to raise the bar for IA64 to meet/exceed, l if nothing else.   ------------------------------  % Date: Mon, 25 Jun 2001 09:21:21 -0600t% From: Dan O'Reilly <dano@process.com>w1 Subject: Re: Compaq's Alpha design team for sale?nB Message-ID: <5.1.0.14.2.20010625092015.027e1d20@ntbsod.psccos.com>  7 At 09:17 AM 6/25/2001, LBohan@dbc.spam_less..com wrote:m  / >I would've liked to see a commitment as far asa/ >EV8, to raise the bar for IA64 to meet/exceed,a >if nothing else.1  O Remember, Intel gets all the Alpha stuff - including plans and engineers.  They:N know what side of their bread is buttered, and I personally think it's a givenI that a fair amount of Alpha technology will show up in next-gen Itaniums.l     ------I +-------------------------------+---------------------------------------+oI | Dan O'Reilly                  |                                       |eI | Principal Engineer            |  "Why should I care about posterity?  |yI | Process Software              |   What's posterity ever done for me?" |DI | http://www.process.com        |                    -- Groucho Marx    |nI +-------------------------------+---------------------------------------+n   ------------------------------    Date: 25 Jun 2001 11:23:30 -0500- From: koehler@encompasserve.org (Bob Koehler)l1 Subject: Re: Compaq's Alpha design team for sale?o3 Message-ID: <7Jl4mK6nXv8A@eisner.encompasserve.org>2  ` In article <pNUIa5X406sE@malvm5.mala.bc.ca>, nothome@spammers.are.scum (Malcolm Dunnett) writes:  K >    If Compaq doesn't commit on day 1 of the announcement of any IA64 porttJ > that absolutely everything that runs on Alpha today will be ported ( andH > in a timely fashion ) then I think many of us will have lots to worry  > about.  H I just want to know when we get the BLISS compiler.  And will it have to% support call gates as a linkage type?   F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporationg= NASA GSFC Flight Software       | Federal Sector, Civil GrouppE                                 | please remove ".aspm" when replyingv   ------------------------------    Date: 25 Jun 2001 11:27:38 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)h1 Subject: Re: Compaq's Alpha design team for sale? 3 Message-ID: <6J3D46feSEG6@eisner.encompasserve.org>   Z In article <0ukejtoh2uqhlc8c97lmv8n02ps5b15utt@4ax.com>, LBohan@dbc.spam_less..com writes:  9 > so..., in theory, in 4-5 years, we might able to buy a e8 > DELL (or IBM) IA64 server to run VMS on ... go figure.  E Nobody promised that, just like VMS does not support Alphas from API.s  1 > I would've liked to see a commitment as far as  1 > EV8, to raise the bar for IA64 to meet/exceed,   > if nothing else.  5 If EV8 were late, it would be costly with no benefit.tJ If successor IA64 chips are late or underperformant, Compaq can sell EV7s.   ------------------------------    Date: 25 Jun 2001 08:17:45 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)r1 Subject: Re: Compaq's Alpha design team for sale?e, Message-ID: <+avj5pdVtbRa@malvm5.mala.bc.ca>  : In article <TTEZ6.2567$l45.606180@news20.bellglobal.com>, .    "Neil Rieck" <n.rieck@sympatico.ca> writes: > H > Back in 1986 our IS/IT group forced us to use VAX-BASIC. At the time IK > thought this was a limitation (we wanted Pascal) but then discovered thatnE > VAX-BASIC had many Fortran features as well as built-in support for M > Sequential, Relative and Indexed file types. The VAX-BASIC product name wasuG > changed to DEC-BASIC and now Compaq BASIC, and we're currently (2001)s  > migrating these apps to Alpha. > G     I agree that Compaq BASIC is a good language, I use it extensively.s  N     My point was that it seems to get limited respect within Compaq. I've beenM told ( sorry I can't remember the source ) that it was a last minute decisionaL to port it to Alpha and that it wasn't in the original game plan. My concern< is the same thing could happen in the Alpha-IA64 transition.  K     FMS is another product I worry about. I understand it also wasn't going F to be ported, until they realized that All-in-1 needed it. FMS was notG recoded for Alpha it was just VESTed. Will it be possible to re-VEST ita  to run on IA64? Will it be done?  M     Even if neither of these specifics is a problem there's still the generalnM issue of all the historical baggage VMS carries. As long as one stayed on VAXnK that wasn't a problem - the code just continued to run. Any change to a neweM processor introduces the possibility that stuff one relies on may not survivec the conversion.A  O     The announcement appears to say that Compaq will quit building AlphaserversnN at the end of 2003 ("Compaq also said it will continue to design and build newL AlphaServer systems based on current and upcoming Alpha processor technologyG through 2003"). If that's accurate it doesn't leave a lot of time to dodO all the necessary conversion work. At best it would suggest we shouldn't expect M any significant new work to be done on VMS during that time, I'd suspect IA64 1 conversion would take up all available resources.l   ------------------------------  % Date: Mon, 25 Jun 2001 12:27:07 -0300-) From: fabio_compaq@ep-bc.petrobras.com.br 1 Subject: RE: Compaq's Alpha design team for sale?.L Message-ID: <OFCA7F06AB.1AC102C7-ON03256A76.0054B3DE@ep-bc.petrobras.com.br>  B It  is time for Compaq or Intel to donate a few Compaq Alpha...and ItaniumserversI to the Universities to help in the portability of applications. So Compaq 	 or Intel,wD will have a great pool of developers able to work in OpenVMS, TRu64,	 Himalaya.e  K At least I believe Intel or Compaq, will merge the three operating systems.n   Regardsa   FC        < Christopher Smith <csmith@amdocs.com> em 25/06/2001 11:02:25  7 Favor responder a Christopher Smith <csmith@amdocs.com>              Info-VAX@Mvb.Saic.Como      1 Assunto: RE: Compaq's Alpha design team for sale?p     > -----Original Message-----6 > From: Terry C Shannon [mailto:shannon@world.std.com]  H > Whether you like or hate Intel, the firm is no slouch when it comes toF > marketing, Doh, maybe mindshare actually is a prerequisite to market > share!  ? Yep, all VMS needs is a group of disco-space-suit-guys and somef questionable special-effects. ;)t   Regards,   Chrish  ! Christopher Smith, Perl Developery Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");m 'o   ------------------------------    Date: 25 Jun 2001 08:39:38 -0700+ From: tadams@gpc.peachnet.edu (Terry Adams)01 Subject: Re: Compaq's Alpha design team for sale?w= Message-ID: <3a39c898.0106250739.398b01f5@posting.google.com>   = IT's Sold.   Compaq announced today that they have sold their5D Alpha technology to Intel and will be focusing its server platforms > all on Intel.  It also announced a re-focusing on Services andK Sofware.  I read this as .... we are getting out of the HARDWARE/PROCESSOR s	 business.e  7 Attaching websites with articles on Intel announcement.h  G http://dailynews.yahoo.com/h/nm/20010625/tc/tech_compaq_intel_dc_1.htmlw  @ http://www.intel.com/pressroom/archive/releases/20010625corp.htm  R http://investor.cnet.com/investor/news/newsitem/0-9900-1028-6367418-0.html?tag=ats   Terry Adamsn Former DECie   ------------------------------   Date: 25 Jun 2001 15:42:16 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)1 Subject: Re: Compaq's Alpha design team for sale?I, Message-ID: <9h7m4o$c0i@gap.cco.caltech.edu>  o In article <IA4MAQNGofF8@eisner.encompasserve.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:mu >In article <Pine.SGI.4.21.0106222348250.27043-100000@world.std.com>, Terry C Shannon <shannon@world.std.com> writes:  >bK >> It matters not to me what engine is under the hood of my VMSmobile. What I >> *does* matter is the affordability of the solution. And if one were towJ >> speculate about VMS on IPF chips, one might conclude that said hardware= >> would dramatically reduce the entry cost to VMS computing.l >5F >The quality of my VMS machines depends very little on the cost of theG >chips.  It depends enormously on the cost (quality) of the surroundingsC >hardware, which is _standardized_ and officially tested by the VMSa >development group.m >sE >If VMS ran on something as popular as x86, it would waste great gobsnB >of VMS development group effort chasing after problems in various >hardware implementations.   It's soooooo obvious.m  E Assuming for the minute that there's any truth to Compaq's "port VMS"pK statement then you can can damn well bet the farm that the ONLY Intel based J machines it will run on will be sold by Compaq.  Compaq will find some wayI or other to lock the OS to their hardware.  Perhaps they'll put some sortaE of proprietary PALcode like doohicky in the boot ROMS.  Or their bus nJ drivers will only work with a certain glue chip which, coincidentally, is  only found in Compaq systems.:  G But I'm not even that sanguine.  Compaq is happy to take VMS customers cH money but their support has never been better than lukewarm.  And the Q J must be asking themselves now what, if any software from other vendors forI VMS would make the transition ot the Intel chip.  The 3rd party software tI market for OpenVMS is in precipitous decline, and how many of those shopseG are going to invest in this transition?   Process, maybe Oracle, and...I Yeah, it's a really SHORT list.e  L Sure, this is the ideal opportunity to put VMS up against other OS's on the I same hardware.  But Compaq has a NO-COMPETE clause against Microsoft (as wK apparently they did with Intel), or at least they act that way, and there's-7 no reason whatsoever to expect anything new from them.    I My fearful prognostication is that this announcement will completely tanklI Alpha sales.  It's way worse than the preannouncement by Digital of AlphaoH during the VAX reign.  Then they let the cat out of the bag a year earlyH but they were at least well on their way to an actual product.  But hereI we've got nothing but Capellas's fond hopes to rely on.  We're at least 3u? years of heavy labor by a small army of software engineers frome? Tru64/VMS/Tandem on Intel.   Who the heck is going to buy AlphahK based products knowing that they're being phased out and knowing that this LI transition is at this point nothing but vapor?  In comparison Sun and IBM0J look every so comfortable and safe.  And once all the customers have gone I Capellas will say "look, we don't need to port after all, there's nobody m using our software anymore".  K And I still think the antitrust issues are going to be a problem.   Even ifII the FTC has somehow been mollified (and given the obvious anticompetitive,H aspects of this transfer, that's really hard to believe) Sun and AMD areH still going to scream bloody murder.  Possibly IBM and HP too.  If legalK action is possible, legal action will be employed.  Slow up this transitionTI by a year or two and we're looking at something like 5 years of purgatoryf$ for the Compaq enterprise products.    Regards,   David Mathog mathog@caltech.edu? Manager, sequence analysis facility, biology division, Caltech f   ------------------------------   Date: 25 Jun 2001 15:56:35 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)1 Subject: Re: Compaq's Alpha design team for sale?a, Message-ID: <9h7mvj$c0i@gap.cco.caltech.edu>  o In article <U81NEHVnflMD@eisner.encompasserve.org>, Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes: q >In article <rl0Z6.588$m6.649474@typhoon.ne.mediaone.net>, "Terry C. Shannon" <terryshannon@mediaone.net> writes:f >> tB >> "David Mathog" <mathog@seqaxp.bio.caltech.edu> wrote in message) >> news:9h0iaa$7ov@gap.cco.caltech.edu...  >eG >>> Exactly!  What better way to carve out market share than to cause auK >>> potential competitor to suddenly go into stasis.  The Alpha wouldn't berK >>> dead, exactly, but just in that zombie state usually associated with CA-H >>> software products, in which there is high cost and zero development. >>>tL >>> That's why I find it so hard to believe that the FTC would ever sign off >> onD >>> this deal. >> DM >> I can't comment on these rumours, but the rationale is pretty good. And if L >> the rumours are true, the FTC issue probably has been dealt with already. >eB >Those from outside the US should bear in mind that there is a newE >administration in Washington since DEC sold the Hudson FAB to Intel.l9 >I don't know the details of the FTC appointment process.s  J Damn, I knew there was something more to the scandal involving Karl Rove'sJ attachment to Intel that was important.  From the LA Times June 18, 2001:   G   "Rove owned at least $100,000 in Intel stock when he met with company-F    executives March 12 at the White House.  He has said that he merelyL    referred them to others in the administration and does not recall raisingG    their concerns about a proposed merger and other matters with Bush.".;                                               ^^^^^^^^^^^^^a  J The merger was not the current Alpha action, it was something to do with a? Dutch company.   Anyone know what "those other matters" were?  o   Regards,  m David Mathog mathog@caltech.edu? Manager, sequence analysis facility, biology division, Caltech iJ **************************************************************************J *                                RIP VMS                                 *J **************************************************************************   ------------------------------    Date: 25 Jun 2001 12:11:10 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) 1 Subject: RE: Compaq's Alpha design team for sale?n3 Message-ID: <42XRx+$wwG7p@eisner.encompasserve.org>0  x In article <OFCA7F06AB.1AC102C7-ON03256A76.0054B3DE@ep-bc.petrobras.com.br>, fabio_compaq@ep-bc.petrobras.com.br writes:D > It  is time for Compaq or Intel to donate a few Compaq Alpha...and > ItaniumserversK > to the Universities to help in the portability of applications. So Compaqt > or Intel,iF > will have a great pool of developers able to work in OpenVMS, TRu64, > Himalaya.P  F Isn't X-windows a large enough burden of university-developed softwareF to impose on the world?  Remember Fred Kleinsorge's comments about the  protocol being basically broken.   ------------------------------    Date: 25 Jun 2001 12:19:03 -0500- From: koehler@encompasserve.org (Bob Koehler)?1 Subject: Re: Compaq's Alpha design team for sale?a3 Message-ID: <2F2s0CC1H71c@eisner.encompasserve.org>e  a In article <9h7m4o$c0i@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu (David Mathog) writes:F  G > Assuming for the minute that there's any truth to Compaq's "port VMS" M > statement then you can can damn well bet the farm that the ONLY Intel based 2 > machines it will run on will be sold by Compaq.   F Actualy the size of the changes needed to get on an Intel architectureH may be so big that this may be the opportunity to re-engineer the deviceG driver and printer symbiont design so that support of popular but shorto& lived peripherals will become cheaper.  H A device driver is already something that plugs into the VMS kernel, howF about something that plugs into a port driver to provide disk specificD data so that lots of USB or Firewire disks can readly operate?  (And7 the plugins downloadable from Compaq's handy web site.)   ? A plug in for printer symbionts so the latest HP printer can beu( supported within days instead of months?  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporationc= NASA GSFC Flight Software       | Federal Sector, Civil GroupaE                                 | please remove ".aspm" when replyingi   ------------------------------  % Date: Mon, 25 Jun 2001 11:11:53 -0500 ' From: Thomas G Wirt <twirt@kittles.com>e1 Subject: Re: Compaq's Alpha design team for sale?i+ Message-ID: <3B3762C9.AC6F2452@kittles.com>K   David Mathog wrote:i >Major snipo >  > K > My fearful prognostication is that this announcement will completely tankmK > Alpha sales.  It's way worse than the preannouncement by Digital of Alpha J > during the VAX reign.  Then they let the cat out of the bag a year earlyJ > but they were at least well on their way to an actual product.  But hereK > we've got nothing but Capellas's fond hopes to rely on.  We're at least 3cA > years of heavy labor by a small army of software engineers fromDA > Tru64/VMS/Tandem on Intel.   Who the heck is going to buy Alpha7L > based products knowing that they're being phased out and knowing that this0 > transition is at this point nothing but vapor?  H I think that you might be wrong here.  Lots of people will what the bestH Alpha VMS system they can get so that they can put off the transition toE Itainium VMS as long as possible.  While this certainly has it's drawmE backs, it seems likely to me given the near religious feelings of VMS- customers for there system.-   >  In comparison Sun and IBMK > look every so comfortable and safe.  And once all the customers have gone J > Capellas will say "look, we don't need to port after all, there's nobody > using our software anymore". > M > And I still think the antitrust issues are going to be a problem.   Even if K > the FTC has somehow been mollified (and given the obvious anticompetitive-J > aspects of this transfer, that's really hard to believe) Sun and AMD areJ > still going to scream bloody murder.  Possibly IBM and HP too.  If legalM > action is possible, legal action will be employed.  Slow up this transition7K > by a year or two and we're looking at something like 5 years of purgatorya% > for the Compaq enterprise products.cD They keep saying that this deal is non-exclusive.  This, or at leastG they feel, shields them from government regulation.  My question is 'Is D this deal open to IBM, AMD, or other chip makers?'.  It sounds to me2 like it is open to other companies in theory only.   Thomas Wirto Systems Manager  Kittle's Home Furnishingst   ------------------------------  % Date: Mon, 25 Jun 2001 12:38:15 -0300-) From: fabio_compaq@ep-bc.petrobras.com.br-1 Subject: Re: Compaq's Alpha design team for sale?nL Message-ID: <OFA2E924AF.8E15F2A8-ON03256A76.0055DEFA@ep-bc.petrobras.com.br>  ' Intel should acquire OpenVMS team too !e   Fabio.        8 "Dan O'Reilly" <dano@process.com> em 25/06/2001 12:21:21  3 Favor responder a "Dan O'Reilly" <dano@process.com>o             Info-VAX@Mvb.Saic.Comc      1 Assunto: Re: Compaq's Alpha design team for sale?     7 At 09:17 AM 6/25/2001, LBohan@dbc.spam_less..com wrote:t  / >I would've liked to see a commitment as far asp/ >EV8, to raise the bar for IA64 to meet/exceed,5 >if nothing else.l  I Remember, Intel gets all the Alpha stuff - including plans and engineers.o TheyH know what side of their bread is buttered, and I personally think it's a givendI that a fair amount of Alpha technology will show up in next-gen Itaniums.e     ------I +-------------------------------+---------------------------------------+ I | Dan O'Reilly                  |                                       | I | Principal Engineer            |  "Why should I care about posterity?  | I | Process Software              |   What's posterity ever done for me?" |eI | http://www.process.com        |                    -- Groucho Marx    |tI +-------------------------------+---------------------------------------+e   ------------------------------   Date: 25 Jun 2001 16:37:03 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)w1 Subject: RE: Compaq's Alpha design team for sale?r, Message-ID: <9h7pbf$2nug$3@info.cs.uofs.edu>  3 In article <K+qjfhLCTYM6@eisner.encompasserve.org>,i<  kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow) writes:` |> In article <CIEJLCMNHNNDLLOOGNJIOECFCNAA.tom@kednos.com>, Tom Linden <tom@kednos.com> writes:N |> > Compaq certainly didn't buy Digital because of Alpha.  It was the service |> > organization thatK |> > they wanted.  I suspect that the cost to keep pace with Intel is high.I |> > Never understoodr5 |> > why Digital didn't pursue the mips architecture.  |>   |> hO |> They did. The DECserver family that preceeded Alpha was MIPS based. Remembern
 |> ULTRIX?  D Remember it??  I have it running in the lab next door.  It continuedB to run on and be developed for the VAX long after the MIPS version was abandoned.  B Are you sure there were ever Servers that were MIPS based??  All IC remember were DECStaions which were desktop boxes that mirrored theeD functionality of the VAXStation family (and not very well, but then,A I'm biased).  The only thing I find in a web search for the term o! "DECServer" are terminal servers.    bill   -- nJ 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>   a   ------------------------------  + Date: Mon, 25 Jun 2001 16:40:50 +0000 (UTC)n' From: david20@alpha1.mdx.ac.uk (D.Webb)h1 Subject: Re: Compaq's Alpha design team for sale?'+ Message-ID: <9h7pii$fst$1@aquila.mdx.ac.uk>r  j In article <5.1.0.14.2.20010625092015.027e1d20@ntbsod.psccos.com>, Dan O'Reilly <dano@process.com> writes:8 >At 09:17 AM 6/25/2001, LBohan@dbc.spam_less..com wrote: >a0 >>I would've liked to see a commitment as far as0 >>EV8, to raise the bar for IA64 to meet/exceed, >>if nothing else. >-P >Remember, Intel gets all the Alpha stuff - including plans and engineers.  TheyO >know what side of their bread is buttered, and I personally think it's a givenmJ >that a fair amount of Alpha technology will show up in next-gen Itaniums. >e >i  8 But it is hard to see how the SMT features of EV8 can be* incorporated into an EPIC based IA64 chip.  N From http://www.realworldtech.com/page.cfm?ArticleID=RWT011601000000&PageNum=6  H "On the other hand, applying SMT techniques to IA-64 appears very, very E  difficult. Not only do IA-64 implementations deliberately avoid the oB  superscalar implementation infrastructure that SMT builds on, theI  huge architected state of IA-64 (128 GPRs, 128 FP registers etc.) would eF  mean support for extra threads would greatly increase the size and/orG  number of physical register files which could hurt clock rates. Other sI  complex elements like the register stack engine would likely have to be rH  replicated on a per thread basis. It is ironic that an SMT enabled EPICG  MPU would need to accrue far more hardware complexity than that which  /  Schlansker and Rau originally sought to avoid.o "-  @ It looks like Intel gets to kill SMT before it becomes a threat.  H Porting VMS and Tru64 to IA-64 wouldn't in itself be a bad thing howeverK selling Alpha to Intel (who will almost certainly kill it) at the same time0 appears insane.m  N (also Compaq appears to have flip-flopped on this - how many months ago was it/ they cancelled the porting of Tru64 to IA-64 ?)   F From what I have seen so far this appears to be Compaq's suicide note.    
 David Webb VMs and Unix team leader CCSS Middlesex University   ------------------------------    Date: 25 Jun 2001 13:19:31 -0400/ From: jordan@lisa.gemair.com (Jordan Henderson)a1 Subject: Re: Compaq's Alpha design team for sale?h* Message-ID: <9h7rr3$c4a$1@lisa.gemair.com>  3 In article <ZXHSdpDY3Y5k@eisner.encompasserve.org>,m: Bob Kaplow <kaplow_r@eisner.encompasserve.org.mars> wrote:h >In article <zNPY6.47086$uR5.5160526@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes:I >> I don't know why companies play the game of "let's focus on only a fewgO >> products to maximize profits". This turns them into "one trick ponies" whichoM >> makes them more vulnerable to failure. In essence, that's what happened tofO >> Nortel; they decided to focus on the optical networking market which quickly L >> saturated and then hit the wall during the "dot com" melt down. CompaniesH >> shouldn't ever shut down profitable revenue sources. All those little >> profits do add up.d >tK >I recall my trip to ZKO when DEC adopted the "one company one strategy onesL >solution" and dumped everything but VMS (i.e. all the PDP-11 stuff). In RSXL >land there was an easter basket with the slogan "one egg one basket" on it. >mO >> So I'm left with just one question; "Just what the hell is Compaq thinking?"t >  >Compaq thinking?  >Military Intelligence.u >Jumbo Shrimp!  ' Industry-Standard Enterprise Computing!e   ------------------------------   Date: 25 Jun 2001 17:26:23 GMT- From: Joe Heimann <heimann@nog.ecs.umass.edu>d1 Subject: Re: Compaq's Alpha design team for sale?t, Message-ID: <9h7s7v$5ak$1@odo.ecs.umass.edu>  2 Bill Gunshannon <bill@triangle.cs.uofs.edu> wrote:5 > In article <K+qjfhLCTYM6@eisner.encompasserve.org>,t> >  kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow) writes:b > |> In article <CIEJLCMNHNNDLLOOGNJIOECFCNAA.tom@kednos.com>, Tom Linden <tom@kednos.com> writes:P > |> > Compaq certainly didn't buy Digital because of Alpha.  It was the service > |> > organization thatM > |> > they wanted.  I suspect that the cost to keep pace with Intel is high.e > |> > Never understoodl7 > |> > why Digital didn't pursue the mips architecture.n > |> a > |>  Q > |> They did. The DECserver family that preceeded Alpha was MIPS based. Remembert > |> ULTRIX?  F > Remember it??  I have it running in the lab next door.  It continuedD > to run on and be developed for the VAX long after the MIPS version > was abandoned.  D > Are you sure there were ever Servers that were MIPS based??  All IE > remember were DECStaions which were desktop boxes that mirrored theaF > functionality of the VAXStation family (and not very well, but then,C > I'm biased).  The only thing I find in a web search for the term .# > "DECServer" are terminal servers.a  H Yes, there were servers based on the MIPS.  We still have a 5400 runningH in the back room for the last few Ultrix only pieces of software.  ThereF were also the 5500, 5800 and 5900 servers.  DEC dropped development onI these when the MIPS was dropped due to problems and the ALPHA was broughtgI out with OSF/1 and VMS.  Search for DECsystem, that is the model name for  the MIPS based servers.r   Joe Heimann    heimann@ecs.umass.edu    ------------------------------  # Date: Mon, 25 Jun 2001 08:24:09 GMTn. From: "mulp" <michaelpettengill@earthlink.net>/ Subject: Re: Compaq: 180 Days of Transformation/B Message-ID: <JyCZ6.410$AV6.57392@newsread2.prod.itd.earthlink.net>  I "Peter L. Montgomery" <Peter-Lawrence.Montgomery@cwi.nl> wrote in messagei news:GFGyK7.IqH@cwi.nl... J >      Glancing at some of these, Compaq says they are committed to Alpha.; > But why did they need to revise so many documents Sunday?w  I Microsoft "revised" them.  Microsoft didn't design the database that hold.I web pages to include the original document date, so everytime you fetch anL page its a "new" page with the current timestamp.  This means you can't tell4 whether a page was update last week or last century.   ------------------------------  # Date: Mon, 25 Jun 2001 08:35:25 GMTM. From: "mulp" <michaelpettengill@earthlink.net>/ Subject: Re: Compaq: 180 Days of TransformationoB Message-ID: <hJCZ6.395$MK4.55788@newsread1.prod.itd.earthlink.net>  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B3690E9.CBD181EF@videotron.ca...J > Wrong. Microsoft is being nice to Compaq by not giving PocketPC licenses toK > other major players. Remember that WinCE was a real dud of a failure. Butt  L Yeah, you fell for the Compaq version of Microsoft statement of exclusivity,: without listening to the Casio version and the HP version.  I Look at this page and tell me that Compaq has an exclusive deal on PocketK PC:l  4 http://www.microsoft.com/mobile/pocketpc/default.asp  K If Michael Dell told Bill Gates that he would increase the number of Pocket ? PC license fees by 10, Dell would get an exclusive license too.e   ------------------------------  # Date: Mon, 25 Jun 2001 13:18:13 GMTe, From: jra@dorothy.msas.net (Jay R. Ashworth)/ Subject: Re: Compaq: 180 Days of Transformations1 Message-ID: <slrn9jedvn.cjl.jra@dorothy.msas.net>b  6 *Right* in the middle of the appendectomy, mulp turned    to Hawkeye and me and said:K > "Peter L. Montgomery" <Peter-Lawrence.Montgomery@cwi.nl> wrote in messagea > news:GFGyK7.IqH@cwi.nl...uL > >      Glancing at some of these, Compaq says they are committed to Alpha.= > > But why did they need to revise so many documents Sunday?s > K > Microsoft "revised" them.  Microsoft didn't design the database that holduK > web pages to include the original document date, so everytime you fetch aiN > page its a "new" page with the current timestamp.  This means you can't tell6 > whether a page was update last week or last century.  4 That reply sounds like the handwave of the century.   F Why don't you expand it about 3 paragraphs, so I won't think you don't# know what you're talking about, eh?l   Cheers,  -- jra -- oN Jay R. Ashworth                                                jra@baylink.com) Member of the Technical Staff     Baylinka/ The Suncoast Freenet         The Things I ThinknN Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015  L    OS X: Because making Unix user-friendly was easier than debugging Windows   ------------------------------    Date: 25 Jun 2001 09:51:32 -05009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow)h/ Subject: Re: Compaq: 180 Days of Transformations3 Message-ID: <QaklW2kD11wt@eisner.encompasserve.org>*  a In article <9gvmr7$l66@gap.cco.caltech.edu>, mathog@seqaxp.bio.caltech.edu (David Mathog) writes:Su > In article <VDvY6.3048$wU6.3394363@typhoon.ne.mediaone.net>, "Terry C. Shannon" <terryshannon@mediaone.net> writes:- >>  >>The Transformation memo per seN >>addresses issues like simplification, consolidation, expense reduction, etc.J >>The sort of things you would expect Capellas to emphasize in the current >>market climate.  > G > Or rather, exactly the sorts of things you'd expect a visionless beanrJ > counter like Capellas to emphasize.  The 180 day spin tells me that thisJ > can hardly be anything else besides another reorg.  Which means that theF > first one didn't do the job, which by my general observations of CEOJ > effectiveness, most likely means that this one won't do anything either.K > Ie, for CEOs it's "If at first you don't succeed, fail, fail again."  ThetL > good ones get it right the first time - the bad ones never get it right.  J > The really amazing thing is how long the boards of corporations will let > these guys flounder. 0    1 Perhaps it's time to "prepare three envelopes"...K   ------------------------------  # Date: Mon, 25 Jun 2001 13:48:45 GMT ) From: Bob Willard <bobwbsgs@mediaone.net> / Subject: Re: Compaq: 180 Days of Transformationo, Message-ID: <3B374163.D1CCCD49@mediaone.net>   "Jay R. Ashworth" wrote: > 8 > *Right* in the middle of the appendectomy, mulp turned  >    to Hawkeye and me and said:M > > "Peter L. Montgomery" <Peter-Lawrence.Montgomery@cwi.nl> wrote in messageo > > news:GFGyK7.IqH@cwi.nl...hN > > >      Glancing at some of these, Compaq says they are committed to Alpha.? > > > But why did they need to revise so many documents Sunday?m > > M > > Microsoft "revised" them.  Microsoft didn't design the database that holdaM > > web pages to include the original document date, so everytime you fetch awP > > page its a "new" page with the current timestamp.  This means you can't tell8 > > whether a page was update last week or last century. > 5 > That reply sounds like the handwave of the century.  > H > Why don't you expand it about 3 paragraphs, so I won't think you don't% > know what you're talking about, eh?-  E If you examine the EV7 docs which are dated 6/25/01 on the compaq.comoF site, you will see that many of them were written much earlier and, asB mulp implies, have not been revised in spite of the reported date.C E.g., the Nov'99 HPCwire interview with Ty Rabe, now dated 6/25/01.- -- - Cheers, Bob    ------------------------------    Date: 25 Jun 2001 09:59:39 -05009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow)a/ Subject: Re: Compaq: 180 Days of TransformationK3 Message-ID: <VhSFYMayD4Et@eisner.encompasserve.org>f  u In article <U%vZ6.3605$Bp1.476335@newsread2.prod.itd.earthlink.net>, "mulp" <michaelpettengill@earthlink.net> writes:c< > "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message( > news:3B343964.547DFDE7@videotron.ca... >> "Terry C. Shannon" wrote:6 >> > Any ideas on a suitable replacement for Capellas? >> >> Michael Dell. > G > You're joking, right?  Michael Dell invested in a proprietary storagelN > company where the stock was way over priced because of the dot com fad.  ButN > he doesn't invest in cloning the iPaq so that he can boast about taking thatL > market away from Compaq.  There is nothing unique about the iPaq that Dell1 > can't buy except for the Compaq and iPaq logos.i > L > He also took a real long time to return to AMD for chips; if Dell had beenK > shipping Athlon systems for the past year, they would been number 1 in PCaL > sales six months earlier and Compaq would be unable to avoid taking a loss3 > quarter after having laid off 30% of the company.d >  >  -- e  * 	Bob Kaplow	NAR # 18L	TRA # "Ctrl-Alt-Del"  N Kaplow Klips & Baffle:	http://www.nira.chicago.il.us/Leading_Edge/MayJun00.pdf; NIRA:	http://www.nira.chicago.il.us	NAR:	http://www.nar.org   O "We find that adult supervision stifles our natural creativity" J. Fox  4/27/01a  , 		>>>>>   Boycot Yahoo's censorship!   <<<<<  I The only thing truly indecent or offensive on the Internet is censorship.S   ------------------------------  % Date: Mon, 25 Jun 2001 10:14:11 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)/ Subject: Re: Compaq: 180 Days of TransformationaL Message-ID: <rdeininger-2506011014120001@user-2ivebei.dialup.mindspring.com>  H In article <slrn9jedvn.cjl.jra@dorothy.msas.net>, jra@baylink.com wrote:  8 > *Right* in the middle of the appendectomy, mulp turned  >    to Hawkeye and me and said:M > > "Peter L. Montgomery" <Peter-Lawrence.Montgomery@cwi.nl> wrote in messagei > > news:GFGyK7.IqH@cwi.nl...sN > > >      Glancing at some of these, Compaq says they are committed to Alpha.? > > > But why did they need to revise so many documents Sunday?1 > > M > > Microsoft "revised" them.  Microsoft didn't design the database that holdiM > > web pages to include the original document date, so everytime you fetch apP > > page its a "new" page with the current timestamp.  This means you can't tell8 > > whether a page was update last week or last century. > 6 > That reply sounds like the handwave of the century.  > H > Why don't you expand it about 3 paragraphs, so I won't think you don't% > know what you're talking about, eh?o  E It's true that many compaq web pages always show the current date.  IsF don't know whether that's a microsoft "feature", or a compaq corporate rule.    -- b Robert Deininger rdeininger@mindspring.comg   ------------------------------  % Date: Mon, 25 Jun 2001 09:30:39 -0500d+ From: Christopher Smith <csmith@amdocs.com>i/ Subject: RE: Compaq: 180 Days of Transformation-L Message-ID: <3B55D7F383B0D31197D9009027541CBF0D9D1FD3@cmiexch1.cmi.itds.com>   > -----Original Message-----2 > From: Christof Brass [mailto:brass@infopuls.com]  A > Mentioning VMS in that way is probably as bad as dumping Alpha.r? > This is the time to open source VMS. And it's time to developsB > Beta the Alpha successor which is fully compatible. Nobody needs6 > IA64 with its wrongly designed EPIC instruction set.  G I agree completely here.  IA64 is a mistake, and should be dead by now.- Unfortunately, it is not. :/  @ > According to the Register the deal is complete: Intel gets the@ > Alpha technique, development team and the compiler developers.> > There will nothing left at Compaq to have any influence. TheA > situation will be exactly the same as with current Intel HW: nom@ > differentiating factor. As the good people at Compaq will then? > be gone there is nobody to compete with other companies whichm) > are sucessful in the enterprise market.   G That may be good.  If we look on the bright side of this, Intel does dosK quite a bit of marketing on their chips.  They even still do development on J things that have been acquired from other companies (ARM?)  Maybe Intel isK in a position to do more for Alpha than Compaq...  Perhaps even a low-powerU6 Alpha for notebooks... handhelds?  That would be nice.  I I'm not sure what to expect, but I hope Intel wouldn't be so stupid as to $ just discard the Alpha in this case.   Regards,   Chrisr    ! Christopher Smith, Perl Developer  Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");n 'o   ------------------------------  % Date: Mon, 25 Jun 2001 12:42:33 -0500 1 From: "David J. Dachtera" <djesys.nospam@fsi.net> / Subject: Re: Compaq: 180 Days of Transformationc' Message-ID: <3B377809.36E89EBC@fsi.net>    David Mathog wrote:  > u > In article <VDvY6.3048$wU6.3394363@typhoon.ne.mediaone.net>, "Terry C. Shannon" <terryshannon@mediaone.net> writes:d > >i! > >The Transformation memo per se-O > >addresses issues like simplification, consolidation, expense reduction, etc.xK > >The sort of things you would expect Capellas to emphasize in the current- > >market climate. > G > Or rather, exactly the sorts of things you'd expect a visionless beancJ > counter like Capellas to emphasize.  The 180 day spin tells me that thisJ > can hardly be anything else besides another reorg.  Which means that theF > first one didn't do the job, which by my general observations of CEOJ > effectiveness, most likely means that this one won't do anything either.F > Ie, for CEOs it's "If at first you don't succeed, fail, fail again."  A I'd make that, "If at first you succeed, blunder, blunder again."i   --   David J. Dachterai dba DJE Systemsu http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/e  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.M   ------------------------------  # Date: Mon, 25 Jun 2001 10:55:45 GMTs= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)l Subject: Re: cool add/0 Message-ID: <009FE0CC.523A65F8@SendSpamHere.ORG>  P In article <3B35ED77.A055E264@wi.rr.com>, Scott Vieth <svieth@wi.rr.com> writes: >It's there. >Look again....  >a >-Scotta  J The little banner ads change with every access.  Which ad location are youJ are referring to?  The top animation or the animation in the side bar?  IfJ you give me a hint, a few refreshes might find the animation you see among the ever changing selections.    --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMi            tO city, n., 1. a place where trees are cut down and streets are named after them.e   ------------------------------  % Date: Mon, 25 Jun 2001 17:07:41 +0200i2 From: martin@radiogaga.harz.de (Martin Vorlaender) Subject: Re: cool add ; Message-ID: <3b3753bd.524144494f47414741@radiogaga.harz.de>d  > Brian Schenkenberger, VAXman- (system@SendSpamHere.ORG) wrote:( > Scott Vieth <svieth@wi.rr.com> writes: > >It's there. > >Look again....e >nL > The little banner ads change with every access.  Which ad location are you > are referring to?   E The ad he is referring to is an SWF file - a Flash movie. You'll needw  some PC "technology" to view it.   cu,    Martin -- PJ One OS to rule them all       | Martin Vorlaender  |  VMS & WNT programmer7 One OS to find them           | work: mv@pdv-systeme.de J One OS to bring them all      |   http://www.pdv-systeme.de/users/martinv/> And in the Darkness bind them.| home: martin@radiogaga.harz.de   ------------------------------    Date: 25 Jun 2001 11:29:55 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)c Subject: Re: cool addt3 Message-ID: <eTyerlFHYzNI@eisner.encompasserve.org>a  p In article <3b3753bd.524144494f47414741@radiogaga.harz.de>, martin@radiogaga.harz.de (Martin Vorlaender) writes:@ > Brian Schenkenberger, VAXman- (system@SendSpamHere.ORG) wrote:) >> Scott Vieth <svieth@wi.rr.com> writes:S >> >It's there.P >> >Look again.... >>M >> The little banner ads change with every access.  Which ad location are you> >> are referring to? > G > The ad he is referring to is an SWF file - a Flash movie. You'll needg" > some PC "technology" to view it.  H Not just PC, I read it on my Macintosh, but Brian cannot read it on VMS.   ------------------------------  % Date: Mon, 25 Jun 2001 09:33:52 +0200g= From: Oswald Knoppers <Oswald.Knoppers@contrastmediagroep.nl>a# Subject: Re: DECnet Phase IV routerc5 Message-ID: <3B36E960.8D3F6BB2@contrastmediagroep.nl>e   Hamlyn Mootoo wrote: > H > I believe it's normal to only see one adjacency.  This is based on theG > costs set by the Cisco's on their interfaces when DECnet was enabled.AI > If your network people increase the cost of the one your seeing, higheriH > than the other one, the other should become the new adjacency you see.  B No it is the router priority. The one with the highest will be theG designated router. If priorities are the same, the one with the highest'  address will be the one you see.   Oswald   ------------------------------  % Date: Mon, 25 Jun 2001 18:43:09 +0200e From: eugs <eugs2k@yahoo.com>  Subject: Re: DECss7 ( Message-ID: <3B376A1D.60EAA92@yahoo.com>   Hi,   \     You could send me a mail with your questions and I would be happy to answer them. I work with DECss7.   eugs   "Ruslan R. Laishev" wrote:   > Hello All!Z >         Is there who have an expirience with this product? I'm need a little consutlitngW > related to MTP API. I'd like to use it for some project,  DECss7 is very expensive atw< > the time and I'm need to get some knowledge before buy it. > -- > Cheers, Ruslan.rA > +----------------pure personal opinion------------------------+m; >     RADIUS Server for OpenVMS project - www.radiusvms.come8 >       vms-isps@dls.net - Forum for ISP running OpenVMS+ >                 Mobile: +7 (901) 971-3222    ------------------------------    Date: 25 Jun 2001 01:11:14 -0700+ From: rob.johnson@bigfoot.com (Rob Johnson) + Subject: EMC fibre disk on ES40 + VMS 7.2-1e= Message-ID: <8b460d3f.0106250011.5cc5f02f@posting.google.com>   2 Does  anyone have the above configuration working?D I have an ES40 with a KGPSA-CA connected to an EMC switch (16 port),C which is then connected to an EMC (8430). The EMC is visible on theeD switch, as far as I know ( it appears in the nameserver gui, or if I enter nsShow using telnet)C but the VMS box just hangs when I try to boot it when it is pluggedmF into the switch. (It'll boot OK when it isn't plugged into the switch)B I've applied the FIBRE_SCSI patch, along with UPDATE,PCSI and SYS.   TIAh   Rob.   ------------------------------    Date: 25 Jun 2001 00:12:32 -0700' From: piet@timmers-it.nl (Piet Timmers)rY Subject: Error message question:    %AMDS-W-BADLANADR, bad LAN address form on line: EIA0t= Message-ID: <be44b12d.0106242312.281290bf@posting.google.com>1   $ @amds$startup restart"  H  Copyright (c) 1995 Digital Equipment Corporation. All rights reserved. ? %AMDS-I-RMSHUT, stopping Data Provider processing for this nodet4 %AMDS-S-RMSUCCESS, Data Provider shutdown successful  H  Copyright (c) 1995 Digital Equipment Corporation. All rights reserved. @ %AMDS-I-RMSTART, starting Data Provider processing for this node5 %AMDS-W-BADLANADR, bad LAN address form on line: EIA0 , %AMDS-I-LOADSECDB, loading security database3 %AMDS-S-RMSUCCESS, Data Provider startup successful   1 Any suggestion what this means, and how to solve?s  
 Greetings,   Piet Timmers   ------------------------------  % Date: Mon, 25 Jun 2001 17:06:19 +1000c< From: "Antony Wardle" <antony.wardle@nospam.optusnet.com.au> Subject: f$getqui B Message-ID: <3b36e26f$0$25510$7f31c96c@news01.syd.optusnet.com.au>  : Anyone got a quick com procedure that will look in a batch queue for a job call bob?   7 I am having problems getting my head around the variouso qualifiers.:  F What I am trying to go is to figure out is if an entry is in the batch* queue call bob, then don't submit another.   cheers   antony   ------------------------------  % Date: Mon, 25 Jun 2001 19:33:31 +0010r% From: paddy.o'brien@zzz.tg.nsw.gov.aue Subject: Re: f$getquiq5 Message-ID: <01K571IV0PIA001XO5@tgmail.tg.nsw.gov.au>q   Antony Wardle wrote:  ; >Anyone got a quick com procedure that will look in a batcht >queue for a job call bob? >v8 >I am having problems getting my head around the various >qualifiers. >oG >What I am trying to go is to figure out is if an entry is in the batchs+ >queue call bob, then don't submit another.i  C So where are you in .au?  I'll write you a procedure for a beer :-)e  - I'm not quite sure what you are trying to do.t  2 You can do something at DCL (in a .COM file) like 2 $ show queue/batch/all/output=myfile.lis sys$batch  & You can then parse that file from DCL.  M Alternatively, another solution was in a recent thread to re-submit from the mI COM file when it ran using (a partial answer) f$environment("procedure").T  L Slightly more re-definition and I'll score that beer.  But don't I remember L you from an NZ address?  In which case I'll need the ticket from Sydney too  :-)b   Regards, Paddy   Paddy O'Brien, Transmission Development,n
 TransGrid, PO Box A1000, Sydney South,  NSW 2000, Australiaa   Tel:   +61 2 9284-3063 Fax:   +61 2 9284-3050& Email: paddy.o'brien@zzz.tg.nsw.gov.au  M Either "\'" or "\s" (to escape the apostrophe) seems to work for most people,t; but that little whizz-bang apostrophe gives me little spam.c   ------------------------------  # Date: Mon, 25 Jun 2001 14:23:34 GMTt2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: f$getqui>0 Message-ID: <GPHZ6.81$rc5.3834@news.cpqcorp.net>   In article <3b36e26f$0$25510$7f31c96c@news01.syd.optusnet.com.au>, "Antony Wardle" <antony.wardle@nospam.optusnet.com.au> writes:r; :Anyone got a quick com procedure that will look in a batchb :queue for a job call bob?  G   No, but there are examples of calling f$getqui in the DCL manual and i    at the Ask The Wizard website.  G :What I am trying to go is to figure out is if an entry is in the batchr+ :queue call bob, then don't submit another.m  E   The easiest approach is a one-slot queue, BOBQ or some such.  More fE   advanced would be a scheduling package -- commercial, or something gB   like the Freeware Kronos package.  Also available are autostart E   queues and a self-resubmitting job -- the first thing the job does  I   is (re)submit itself /AFTER=tomorrow+fudge, then it processes its work. K   Scanning a queue for a specified entry name would be possible, but would  F   not be the approach I would choose -- I'd probably look for a unique+   logfile name or procedure name or such...9  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: 25 Jun 2001 08:19:25 -0700- From: afeldman@gfigroup.com (Alan E. Feldman)c Subject: Re: f$getquie= Message-ID: <af1e4ce6.0106250719.4026db24@posting.google.com>u   "Antony Wardle" <antony.wardle@nospam.optusnet.com.au> wrote in message news:<3b36e26f$0$25510$7f31c96c@news01.syd.optusnet.com.au>...< > Anyone got a quick com procedure that will look in a batch > queue for a job call bob?n > 9 > I am having problems getting my head around the variousw
 > qualifiers.d > H > What I am trying to go is to figure out is if an entry is in the batch, > queue call bob, then don't submit another. >  > cheers >  > antony  : If your username is the same as that for the job BOB, then  
 $    SET NOONs $    SHOW ENTRY BOBd $    SEVERITY = $SEVERITYi $    SHOW SYMBOL SEVERITYnD $    ON WARNING THEN EXIT !or whatever your usual error checking is.+ $    IF (.NOT.SEVERITY) THEN SUBMIT BOB.COM   F The symbol SEVERITY will be an odd number if true (BOB is in the batchA queue) or even if false (BOB is not in the batch queue). Then, ifmA SEVERITY is FALSE, then BOB is not running and the procedure willi submit BOB.COM.,  B [NOTE: This will not tell you if the job is actually executing; itF will only tell you that it is in a queue. It might instead be pending, timed, holding, or retained.]n  D If you are a different user and you know the username that` BOB runs under:  
 $    SET NOONo$ $    SHOW ENTRY BOB /USER=username   $    SEVERITY = $SEVERITYg $    SHOW SYMBOL SEVERITYcD $    ON WARNING THEN EXIT !or whatever your usual error checking is.: $    IF (.NOT.SEVERITY) THEN SUBMIT BOB.COM /USER=username  E If neither of the above is acceptable, copy and modify example 3 fromtA HELP LEXICALS F$GETQUI Examples. (Well, it's example 3 on my V6.1  HELP.)   Disclaimer: JMHO Alan E. FeldmanD afeldman@gfigroup.com    ------------------------------  % Date: Mon, 25 Jun 2001 02:19:05 -0400 0 From: "Sharkonwheels" <tonym@compusourceDOT.net> Subject: FA itemsdA Message-ID: <0FAZ6.34260$9r1.2404582@e3500-atl1.usenetserver.com>d  
 Check out:  L http://cgi6.ebay.com/aw-cgi/eBayISAPI.dll?ViewListedItems&userid=sharkonwhee ls  " For some nifty DEC items, such as:  / Original pdp11/34 manual, and accessory manualst& VMS/Vax 4.4 Source code Microfiche set# MicroVax II Hardware Owner's Manuali Tk50 Diagnostic tapes for MVII  : More stuff coming, such as TK50 tapes with SQL, RAF, etc..E More manuals, for VMS, Ultrix, Ultrix-32, DECsation 2100/3100 Owner's- manual,-+ etc... Lotsa' stuff! Keep your eyes peeled!0     Tony    tonym -AT- compusource -DOT- net   ------------------------------  % Date: Mon, 25 Jun 2001 17:34:42 +0200e# From: Damien WYART <dwyart@noos.fr>. Subject: Re: FreeVMS) Message-ID: <9h7lmi$56s$1@quark.noos.net>m  ; * bertrand@perceval.cnam.fr (BERTRAND Jol) in comp.os.vms:t   > It was the mach kernel.    Mmmm.a  D > We can reuse a microkernel to begin (as Mach4 used in the previous > FreeVMS project).   E Even if he misses some (important) points, Linus is not totally wrongtF when he says Mach is confusing and not-so-well designed. As a startingF point for a new *good* (as a VMS clone shoud be) OS, I would not trust it so much.o -- d Damien WYART / dwyart@noos.frl   ------------------------------    Date: 25 Jun 2001 07:57:26 -0500 From: briggs@encompasserve.org+ Subject: Re: FTP LIST problem. Help Please!n3 Message-ID: <NLstynYGjzAe@eisner.encompasserve.org>w  Y In article <1010622182951.38769E-100000@Ives.egh.com>, John Santos <JOHN@egh.com> writes:o& > On Fri, 22 Jun 2001, JF Mezei wrote:Q >> However, I am not sure, but aren't there 2 separate commands FTP commands sentm >> to a server ? >> wO >> One to get a parsable file list, and one to get a "text" file list. It seemsoK >> that the command being sent by your FTP client asks for a text file list.# >> instead of a parsable file list.- > K > That would be nice, but AFAIK it doesn't exist.  There is absolutely *NO*sK > standard for the info returned by an FTP DIR (or LS, which is a synonym).F   JF is correct.  G The actual FTP commands are "LIST" and "NLST".  Those are sent down therB control connection from client to server.  Most command line styleA FTP clients send the "LIST" command when the user keys in a "DIR"eE request.  Most command line style FTP clients send the "NLST" commandsB when user keys in a "LS" request.  The two are most definitely not	 synonyms.I  J The "LIST" command requests a detailed file listing.  Many GUI FTP clientsF use this command so that they can display a pretty file listing.  With) protection masks and file sizes and such.   ? The "NLST" command requests a simple file listing.  Names only.    See RFC 959i  C Some GUI clients have settable options to choose which command willl be used.   	John Briggs   ------------------------------  % Date: Mon, 25 Jun 2001 14:18:02 +0100 8 From: John Macallister <J.Macallister1@physics.ox.ac.uk>% Subject: Full port of VMS to Itanium.tN Message-ID: <35666012DF4CD411BE940090279FA240010BEFC5@ppnt41.physics.ox.ac.uk>  J Today's announcement says that there will be a "Full port of ... VMS .. to Itanium ... starting now." .    J That, to me, appears to be a fairly positive commitment to the longer term future of VMS.  5 The Powerpoint slides of the announcement are at URL:o  = http://www.compaq.com/hps/ipf-enterprise/download/webcast.pptp     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: Mon, 25 Jun 2001 10:41:14 -0300-) From: fabio_compaq@ep-bc.petrobras.com.br ) Subject: Re: Full port of VMS to Itanium.fL Message-ID: <OFFB99FC77.F49E9947-ON03256A76.0049F747@ep-bc.petrobras.com.br>  E I believe will happend all that troubles of porting the VAX to Alpha.07 A lot of companies will not port from Alpha to Itanium.n  H Bad point of view:   I believe a lot of customres will jump to long-time
 processors:                                      as SPARC or Power PC.  F Good point of view:  I can improve my value $$$ in the market  because OpenVMS J                                        professionals will become much more rares .....      Regardsa   FC        I John Macallister <J.Macallister1@physics.ox.ac.uk> em 25/06/2001 10:18:02d  D Favor responder a John Macallister <J.Macallister1@physics.ox.ac.uk>             Info-VAX@Mvb.Saic.Comy      % Assunto: Full port of VMS to Itanium.,    J Today's announcement says that there will be a "Full port of ... VMS .. to Itanium ... starting now." .    J That, to me, appears to be a fairly positive commitment to the longer term future of VMS.  5 The Powerpoint slides of the announcement are at URL:y  = http://www.compaq.com/hps/ipf-enterprise/download/webcast.pptr     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)a   ------------------------------  # Date: Mon, 25 Jun 2001 15:54:09 GMTM& From: "john nixon" <jnixon@cfl.rr.com>) Subject: Re: Full port of VMS to Itanium.y> Message-ID: <B8JZ6.49814$_T2.12747849@typhoon.tampabay.rr.com>  C I have finally, after 10 years or so of trying, finally prodded ouraF development group (kicking and screaming)  into converting from VAX toG Alpha.  Last week, we ordered several Alpha's to replace our VAX 7860s.d- The conversion should be completed this year.a  ! What a kick in the pants this is!i   I hope I still have a job.  I I hope Compaq starts yelling from the rooftops how quickly they will portyB VMS to Itanium, and how easy the port from AlphaVMS  will be.  TheG competitors are already spreading the word that Alpha (and thus VMS) is  dead.i  6 <fabio_compaq@ep-bc.petrobras.com.br> wrote in messageF news:OFFB99FC77.F49E9947-ON03256A76.0049F747@ep-bc.petrobras.com.br...G > I believe will happend all that troubles of porting the VAX to Alpha.e9 > A lot of companies will not port from Alpha to Itanium.f >1J > Bad point of view:   I believe a lot of customres will jump to long-time > processors< >                                      as SPARC or Power PC. >oH > Good point of view:  I can improve my value $$$ in the market  because	 > OpenVMSnL >                                        professionals will become much more
 > rares .....o >l >e	 > Regards  >c > FC >t >i >i > K > John Macallister <J.Macallister1@physics.ox.ac.uk> em 25/06/2001 10:18:02  > F > Favor responder a John Macallister <J.Macallister1@physics.ox.ac.uk> >  >  >t >       Info-VAX@Mvb.Saic.Com/ >w >v >s' > Assunto: Full port of VMS to Itanium.s >i >tL > Today's announcement says that there will be a "Full port of ... VMS .. to > Itanium ... starting now." . >  >gL > That, to me, appears to be a fairly positive commitment to the longer term > future of VMS. >@7 > The Powerpoint slides of the announcement are at URL:4 >4? > http://www.compaq.com/hps/ipf-enterprise/download/webcast.ppta >e >w > John >rD > Name: John B. Macallister  E-mail: j.macallister1@physics.ox.ac.ukJ > Post: Nuclear and Astrophysics Laboratory, Keble Road, Oxford OX1 3RH,UKC > Phone: +44-1865-273388 (direct)  273333 (reception)  273418 (Fax)o >r >o >  >a >r >r >g >? >    ------------------------------    Date: 25 Jun 2001 12:09:13 -0500- From: koehler@encompasserve.org (Bob Koehler) ) Subject: Re: Full port of VMS to Itanium.a3 Message-ID: <6B64wRYwLYcv@eisner.encompasserve.org>-  x In article <OFFB99FC77.F49E9947-ON03256A76.0049F747@ep-bc.petrobras.com.br>, fabio_compaq@ep-bc.petrobras.com.br writes:  J > Bad point of view:   I believe a lot of customres will jump to long-time > processors< >                                      as SPARC or Power PC.  9 I think both PowerPC and IA-64 will easily outlive SPARC.h  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporation = NASA GSFC Flight Software       | Federal Sector, Civil GrouptE                                 | please remove ".aspm" when replyingu   ------------------------------  % Date: Mon, 25 Jun 2001 09:07:47 -0700 ! From: Tom Linden <tom@kednos.com>-) Subject: RE: Full port of VMS to Itanium.u9 Message-ID: <CIEJLCMNHNNDLLOOGNJIOEGECNAA.tom@kednos.com>j  D Think of it as a truck, it is the load that you are carrying that is
 important,J provide of course that the truck performs to specs.  You just traded in anH old on for a newer one, which will at some point be replaced again,  andH MAYBE it won't have such severe alignement requirements.  That's how you sell it and keep your job. :->   > -----Original Message------ > From: john nixon [mailto:jnixon@cfl.rr.com] % > Sent: Monday, June 25, 2001 8:54 AM  > To: Info-VAX@Mvb.Saic.Coms+ > Subject: Re: Full port of VMS to Itanium.o >i >-E > I have finally, after 10 years or so of trying, finally prodded our.H > development group (kicking and screaming)  into converting from VAX toI > Alpha.  Last week, we ordered several Alpha's to replace our VAX 7860s.-/ > The conversion should be completed this year.. >n# > What a kick in the pants this is!c >E > I hope I still have a job. >eK > I hope Compaq starts yelling from the rooftops how quickly they will portoD > VMS to Itanium, and how easy the port from AlphaVMS  will be.  TheI > competitors are already spreading the word that Alpha (and thus VMS) is  > dead.h >M8 > <fabio_compaq@ep-bc.petrobras.com.br> wrote in messageH > news:OFFB99FC77.F49E9947-ON03256A76.0049F747@ep-bc.petrobras.com.br...I > > I believe will happend all that troubles of porting the VAX to Alpha.(; > > A lot of companies will not port from Alpha to Itanium.p > >tL > > Bad point of view:   I believe a lot of customres will jump to long-time > > processors> > >                                      as SPARC or Power PC. > >lJ > > Good point of view:  I can improve my value $$$ in the market  because > > OpenVMSf= > >                                        professionals willo > become much more > > rares .....  > >r > >  > > Regards) > >  > > FC > >m > >o > >t > >A9 > > John Macallister <J.Macallister1@physics.ox.ac.uk> emr > 25/06/2001 10:18:02d > >AH > > Favor responder a John Macallister <J.Macallister1@physics.ox.ac.uk> > >a > >i > >  > >       Info-VAX@Mvb.Saic.Com  > >D > >M > >,) > > Assunto: Full port of VMS to Itanium.  > >  > >-@ > > Today's announcement says that there will be a "Full port of > ... VMS .. tot  > > Itanium ... starting now." . > >v > >sB > > That, to me, appears to be a fairly positive commitment to the
 > longer termg > > future of VMS. > >-9 > > The Powerpoint slides of the announcement are at URL:1 > >0A > > http://www.compaq.com/hps/ipf-enterprise/download/webcast.pptu > >: > >t > > John > >DF > > Name: John B. Macallister  E-mail: j.macallister1@physics.ox.ac.ukL > > Post: Nuclear and Astrophysics Laboratory, Keble Road, Oxford OX1 3RH,UKE > > Phone: +44-1865-273388 (direct)  273333 (reception)  273418 (Fax)  > >t > >  > >g > >o > >o > >r > >  > >  > >t >i >n   ------------------------------  % Date: Mon, 25 Jun 2001 13:05:36 -0400 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>0) Subject: Re: Full port of VMS to Itanium..0 Message-ID: <acKZ6.98$rc5.4164@news.cpqcorp.net>  H I believe that the VAX port probably was the most tramatic for everyone.L Going from Alpha to IPF (Itanium Processor Family) will be less tramatic.  II believe that if you have gotten to Alpha, odds are it will be a recompilei and go.o  J Were you buying Alpha?  Or were you buying VMS?  I think that in the grandJ scheme of things, you were buying OpenVMS for the things that it brings toL the table... if we could build a VAX that was as fast as Alpha - you'd still
 be on VAX.  J While I am, and remain, an Alpha supporter.  You now will have a chance to& see VMS on a "open" hardware platform.      8 fabio_compaq@ep-bc.petrobras.com.br wrote in message ...F >I believe will happend all that troubles of porting the VAX to Alpha.8 >A lot of companies will not port from Alpha to Itanium. >yI >Bad point of view:   I believe a lot of customres will jump to long-timer >processorse; >                                     as SPARC or Power PC.b > G >Good point of view:  I can improve my value $$$ in the market  because  >OpenVMSK >                                       professionals will become much more1 >rares ..... >i >p >Regards >z >FC. >. >. >  >iJ >John Macallister <J.Macallister1@physics.ox.ac.uk> em 25/06/2001 10:18:02 >uE >Favor responder a John Macallister <J.Macallister1@physics.ox.ac.uk>- >- >- >- >      Info-VAX@Mvb.Saic.Com >1 >: >3& >Assunto: Full port of VMS to Itanium. >  >fK >Today's announcement says that there will be a "Full port of ... VMS .. tor >Itanium ... starting now." .0 >5 >7K >That, to me, appears to be a fairly positive commitment to the longer termt >future of VMS.t >r6 >The Powerpoint slides of the announcement are at URL: >c> >http://www.compaq.com/hps/ipf-enterprise/download/webcast.ppt >a >n >Johnq >iC >Name: John B. Macallister  E-mail: j.macallister1@physics.ox.ac.ukmI >Post: Nuclear and Astrophysics Laboratory, Keble Road, Oxford OX1 3RH,UK B >Phone: +44-1865-273388 (direct)  273333 (reception)  273418 (Fax) >t >e >  >Q >  >e >c >    ------------------------------    Date: 25 Jun 2001 13:20:13 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)l) Subject: Re: Full port of VMS to Itanium.m3 Message-ID: <nFiK3RTiIYXW@eisner.encompasserve.org>e  i In article <UiKZ6.100$rc5.3751@news.cpqcorp.net>, "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:n  M > Actually, the engineers here in Nashua seem, well, to be almost universallyrJ > positive about this.  At the same time as it was announced, we also wereL > told our headcount would increase by a number that we will be hard pressed+ > to find engineers to fill quickly enough.F  H I have my doubts about the quality of work from two-headed engineers :-)   ------------------------------  % Date: Mon, 25 Jun 2001 13:12:49 -0400n5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>-) Subject: Re: Full port of VMS to Itanium.:1 Message-ID: <UiKZ6.100$rc5.3751@news.cpqcorp.net>m   john nixon wrote in message ...gD >I have finally, after 10 years or so of trying, finally prodded ourG >development group (kicking and screaming)  into converting from VAX to2H >Alpha.  Last week, we ordered several Alpha's to replace our VAX 7860s.. >The conversion should be completed this year. > " >What a kick in the pants this is! >b >I hope I still have a job.h >a    D For the next several years, Alpha is arguably the best HW available.B Remember, we will continue and implement the EV7 family and systemF platforms.  If you get from VAX to Alpha, the "port" to IPF should, weL believe, be a recompile & relink.  It is also a 99.8% probability that there! will be mixed cluster capability.R  J >I hope Compaq starts yelling from the rooftops how quickly they will portC >VMS to Itanium, and how easy the port from AlphaVMS  will be.  ThelH >competitors are already spreading the word that Alpha (and thus VMS) is >dead.    K Actually, the engineers here in Nashua seem, well, to be almost universallytH positive about this.  At the same time as it was announced, we also wereJ told our headcount would increase by a number that we will be hard pressed) to find engineers to fill quickly enough.g  G Having ported VMS once, we know we can do it again.  There will be somehJ challenges ahead, but we don't know of any show-stoppers.  We'll know justK how "easy" it is in a little while.  The OS has some significant challengesNI that most user code doesn't know or care about (like the console program,H etc).I   ------------------------------  % Date: Mon, 25 Jun 2001 12:28:00 -0500 + From: Christopher Smith <csmith@amdocs.com>I) Subject: RE: Full port of VMS to Itanium. L Message-ID: <3B55D7F383B0D31197D9009027541CBF0D9D1FDD@cmiexch1.cmi.itds.com>   > -----Original Message-----< > From: Fred Kleinsorge [mailto:kleinsorge@star.zko.dec.com]  @ > Were you buying Alpha?  Or were you buying VMS?  I think that  > in the grand@ > scheme of things, you were buying OpenVMS for the things that  > it brings to; > the table... if we could build a VAX that was as fast as y > Alpha - you'd still  > be on VAX.  J That's an interesting remark, but what exactly does Itanic have that AlphaJ does not?  I assume it should be significantly cheaper... I only hope thatI there aren't holes in the design so large that even VMS engineering can't,K work around them.  I do have lots of respect for the VMS engineering group.f  < > While I am, and remain, an Alpha supporter.  You now will  > have a chance to( > see VMS on a "open" hardware platform.  6 I'll believe that when I see the platform become open.   Regards,   ChrisV  ! Christopher Smith, Perl Developero Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");a '   e   ------------------------------  % Date: Mon, 25 Jun 2001 13:35:27 -0400 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>,) Subject: Re: Full port of VMS to Itanium.M1 Message-ID: <8EKZ6.105$rc5.4286@news.cpqcorp.net>r  K Who knows Larry, maybe they'll figure out how to bend the contractor rules,t, and we can get you and your 3 heads back ;-)      $ Larry Kilgallen wrote in message ...D >In article <UiKZ6.100$rc5.3751@news.cpqcorp.net>, "Fred Kleinsorge"% <kleinsorge@star.zko.dec.com> writes:e >gB >> Actually, the engineers here in Nashua seem, well, to be almost universallyEK >> positive about this.  At the same time as it was announced, we also were2E >> told our headcount would increase by a number that we will be harda presseda, >> to find engineers to fill quickly enough. >>I >I have my doubts about the quality of work from two-headed engineers :-)m   ------------------------------  % Date: Mon, 25 Jun 2001 12:58:18 -0400l5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>w& Subject: Re: Future support of VAX-VMS0 Message-ID: <i5KZ6.95$rc5.3969@news.cpqcorp.net>  I The announcement is too new to be able to provide any real information to K you.  I would expect to begin to see some concrete statements in probably at
 month (IMHO).f  I Our VAX customers are important to us (even though we would like it if weoE could turn them all into Alpha - or now Itanium - sites running VMS).         = JF Mezei wrote in message <3B368264.5ED53B4E@videotron.ca>... L >With the rumoured impending death of Alpha and rumoured migration of VMS toF >IA64, this will put quite a but of strain on the Compaq VMS engineers havingK >to port VMS to a platform which was not designed to support VMS. And then,h& >having to support VMS on 3 platforms. >fK >Will Compaq take this opportunity to say that 7.3 will be the last versiono of >VMS for VAX ?   ------------------------------  % Date: Mon, 25 Jun 2001 12:07:15 -0500-+ From: Christopher Smith <csmith@amdocs.com>r& Subject: RE: Future support of VAX-VMSL Message-ID: <3B55D7F383B0D31197D9009027541CBF0D9D1FDC@cmiexch1.cmi.itds.com>  D I, for one, actually have the letter that was sent to me, by Compaq,L pledging to support VMS on the VAX "through the year 2010" with "preventive,1 performance optimization, and remedial services."i  K I wouldn't take it as a good sign at all if they decided that they won't doi that after all.c   Regards,   Chris   ! Christopher Smith, Perl Developeri Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");  'l      > -----Original Message-----< > From: Fred Kleinsorge [mailto:kleinsorge@star.zko.dec.com]  = > The announcement is too new to be able to provide any real - > information to@ > you.  I would expect to begin to see some concrete statements  > in probably aF > month (IMHO).o  > > Our VAX customers are important to us (even though we would  > like it if wemG > could turn them all into Alpha - or now Itanium - sites running VMS).p  ? > JF Mezei wrote in message <3B368264.5ED53B4E@videotron.ca>...a; > >With the rumoured impending death of Alpha and rumoured l > migration of VMS to H > >IA64, this will put quite a but of strain on the Compaq VMS engineers > having? > >to port VMS to a platform which was not designed to support   > VMS. And then,( > >having to support VMS on 3 platforms.  = > >Will Compaq take this opportunity to say that 7.3 will be r > the last version > of > >VMS for VAX ?   ------------------------------  % Date: Mon, 25 Jun 2001 13:17:54 -0400s5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>s& Subject: Re: Future support of VAX-VMS1 Message-ID: <GnKZ6.102$rc5.4244@news.cpqcorp.net>u  D Did anywhere in my note I indicate otherwise?  I'll repeat, "Our VAXJ customers are important to us".  I would expect us to provide "support VMS@ on the VAX "through the year 2010" with "preventive, performance' optimization, and remedial services."".w      " Christopher Smith wrote in messageC <3B55D7F383B0D31197D9009027541CBF0D9D1FDC@cmiexch1.cmi.itds.com>...aE >I, for one, actually have the letter that was sent to me, by Compaq,4@ >pledging to support VMS on the VAX "through the year 2010" with "preventive,2 >performance optimization, and remedial services." >mL >I wouldn't take it as a good sign at all if they decided that they won't do >that after all. >4	 >Regards,7 >4 >Chris >a" >Christopher Smith, Perl Developer >Amdocs - Champaign, ILi >  >/usr/bin/perl -e ' @ >print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n"); >' >l >. >> -----Original Message----- = >> From: Fred Kleinsorge [mailto:kleinsorge@star.zko.dec.com]m >t= >> The announcement is too new to be able to provide any realI >> information to @ >> you.  I would expect to begin to see some concrete statements >> in probably a >> month (IMHO). >y> >> Our VAX customers are important to us (even though we would >> like it if weH >> could turn them all into Alpha - or now Itanium - sites running VMS). >r@ >> JF Mezei wrote in message <3B368264.5ED53B4E@videotron.ca>...; >> >With the rumoured impending death of Alpha and rumouredr >> migration of VMS toI >> >IA64, this will put quite a but of strain on the Compaq VMS engineers1	 >> havingn? >> >to port VMS to a platform which was not designed to support  >> VMS. And then, ) >> >having to support VMS on 3 platforms.r >w= >> >Will Compaq take this opportunity to say that 7.3 will ben >> the last version  >> ofM >> >VMS for VAX ?    ------------------------------  % Date: Mon, 25 Jun 2001 12:31:55 -0500o+ From: Christopher Smith <csmith@amdocs.com> & Subject: RE: Future support of VAX-VMSL Message-ID: <3B55D7F383B0D31197D9009027541CBF0D9D1FDE@cmiexch1.cmi.itds.com>  K My reply was more to JF's question earlier of 7.3 being the last version to/L support VAX.  I was pointing out that after making that commitment, it would$ look very bad if that were the case.  / I suppose I should have made myself more clear.w   Regards,   Chris   ! Christopher Smith, Perl Developere Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");  '   t   > -----Original Message-----< > From: Fred Kleinsorge [mailto:kleinsorge@star.zko.dec.com]  F > Did anywhere in my note I indicate otherwise?  I'll repeat, "Our VAX@ > customers are important to us".  I would expect us to provide  > "support VMSB > on the VAX "through the year 2010" with "preventive, performance) > optimization, and remedial services."".-   ------------------------------  # Date: Mon, 25 Jun 2001 14:18:21 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)4 Subject: Re: Gap in this forum between March and May0 Message-ID: <NKHZ6.80$rc5.3436@news.cpqcorp.net>  W In article <tjd7q87hutdr73@news.supernews.com>, "John Vottero" <John@mvpsi.com> writes:o> :"Didier Morandi" <Didier.Morandi@Compaq.com> wrote in message% :news:3B3622BA.D2A80003@Compaq.com... I :> I am looking for the thread on the "know a number of records in a filel :> in one line".  	   Didier,-  E   You have access to this information and to an internal Compaq news oD   server for news access, and to the news archives and search engine>   at Google, and to the InfoVAX archive referenced in the FAQ.      Hoff  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: Mon, 25 Jun 2001 14:06:22 GMTo' From: kerkhoff@gmx.de (Volker Kerkhoff)r3 Subject: Guys, IT is done! Read this and be scared!a0 Message-ID: <3b374471.28240778@news.bcn.ttd.net>  @ http://www.intel.com/pressroom/archive/releases/20010625corp.htm   Alpha, Rest In Peace.   D Volker Kerkhoff and other express their mourning for the dead of our beloved Alpha Chip.    ------------------------------  % Date: Mon, 25 Jun 2001 10:27:26 -0400i+ From: John Eisenschmidt <jeisensc@aaas.org>o7 Subject: Re: Guys, IT is done! Read this and be scared!i# Message-ID: <sb371213.047@aaas.org>o  ! I think I hear the music dying...e  E That does it! I'm giving my notice today, and I'm going to work the =e& fryalator at Wendy's. Screw IT/IS/MIS!  @ >>> Volker Kerkhoff <kerkhoff@gmx.de> 06/25/2001 10:06:22 AM >>>C http://www.intel.com/pressroom/archive/releases/20010625corp.htm=20r   Alpha, Rest In Peace.=20  D Volker Kerkhoff and other express their mourning for the dead of our beloved Alpha Chip.a   ------------------------------  % Date: Mon, 25 Jun 2001 10:17:44 -0700o+ From: "Barry Treahy, Jr." <Treahy@mmaz.com>E7 Subject: Re: Guys, IT is done! Read this and be scared! ' Message-ID: <3B377237.F3EFD73@mmaz.com>    Volker Kerkhoff wrote:  B > http://www.intel.com/pressroom/archive/releases/20010625corp.htm >  > Alpha, Rest In Peace.l >eF > Volker Kerkhoff and other express their mourning for the dead of our > beloved Alpha Chip.   ? Call me pig-headed, but I've done my best to avoid making majorpC compromises by depending on Microsloth, their inferior products and G vaporware strategies.  With all of the problems Intel has had releasing G a 64 bit processor, and the initial introduction of a chip that appears E inferior to the Alpha, it appears that Compaq is making a major error/< staking the future of their non-Windoze business on Itanium.  = For Compaq to state that VMS will be running on a replacementoE architecture based on Itanium smells strongly of vaporware once againIE and perhaps is an indirect method of abandoning that business knowingaF full and well that VMS folks, as well as the other non-Windoze people,B will not or cannot make the move because their applications didn'tD survive the porting.  How many people are still stuck on VAX systemsF because of this exact problem?  With Intel and Compaq in the same bed,@ if their do minimize their non-Windoze business further, forcingG continued migration to other OS's, doesn't it sound as if a third partyk0 might also be in that same bed?  Say Microsloth?  9 I must have watched 'Conspiracy Theory' too many times...e   Barry3 --  ? Barry Treahy, Jr  *  Midwest Microwave  *  Vice President & CIO   A E-mail: Treahy@mmaz.com * Phone: 480/314-1320 * FAX: 480/661-7028    ------------------------------    Date: 25 Jun 2001 11:38:23 -0500- From: koehler@encompasserve.org (Bob Koehler)a* Subject: Re: H-P EOLs PA-RISC Architecture3 Message-ID: <4AzDLMhq6bEV@eisner.encompasserve.org>w  \ In article <3B3632DF.4C4A1855@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > CSABA HARANGOZO wrote:2 >>         Good luck to HP... they will need it... > O > Considering that Compaq is about to embark on the same philosophy of a singletI > processor for all, your wish of good luck to HP also applies to Compaq.t > H > The big winner in this might be IBM with its PowerPc chip (and Apple).  I Steve JObs isn't tht dumb.  All he need to port OS X is big endian mode. YH Anybody know if IA-64 is bi-endian?  (Would make HP's jobs easier, too.)  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporationo= NASA GSFC Flight Software       | Federal Sector, Civil GrouptE                                 | please remove ".aspm" when replyinge   ------------------------------    Date: 25 Jun 2001 11:37:10 -0500- From: koehler@encompasserve.org (Bob Koehler)e* Subject: Re: H-P EOLs PA-RISC Architecture3 Message-ID: <0Xm5vFZ7KsPU@eisner.encompasserve.org>l  l In article <ZPlZ6.238$DJ4.36606@nostril.pacific.net.au>, CSABA  HARANGOZO   <csabah@zipworld.com.au> writes:, > Jerry Leslie <leslie@clio.rice.edu> wrote: > J >>   "After 20 years, Hewlett-Packard has finalized its exit strategy fromJ >>    the microprocessor business and hopes to train its channel to become- >>    experts on Intel's 64-bit architecture.a > * > 	Good luck to HP... they will need it... > 						   Cheers,    Csaba0  C Good luck to their HPARC customers.  If they support the HPARC basehB systems as they migrate to IA-64 for as long as they supported 68K4 customers while they migrated to HPARC, EOL is doom.  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporationc= NASA GSFC Flight Software       | Federal Sector, Civil Group E                                 | please remove ".aspm" when replyingt   ------------------------------    Date: 24 Jun 2001 23:35:09 -0700' From: piet@timmers-it.nl (Piet Timmers)l= Subject: Re: How to see who causes execessive login failures.l= Message-ID: <be44b12d.0106242235.22ee00c3@posting.google.com>c   "Ren?Schelbaum" <rene.schelbaum@datakom.at> wrote in message news:<3b320403$0$17510$6e365a64@newsreader02.highway.telekom.at>... > Hello! > L > It might as well be a port that has autoconnect to a service and (limited)N > modem control enabled and no or a defective modem connected. I had a similarI > problem a couple of years ago and it took quite a while to find out thee	 > reason.  > 	 > regardsF >  >  > Ing. Ren Schelbaumq >  > Datakom Austria GmbH > Betrieb Datenmehrwertdienste > Wiedner Hauptstrae 73 > 1040 Wien  >  Thanks,   ? The problem was a terminalserver port with autoconnect enabled.j
 Greetings,   Piet Timmers   ------------------------------  % Date: Mon, 25 Jun 2001 09:29:02 -0400n2 From: "Sue Skonetski" <susan.skonetski@compaq.com>  Subject: Intel/Alpha announcment0 Message-ID: <n0HZ6.77$rc5.3672@news.cpqcorp.net>  E Please look at this web site for some details on today's announcment.p   Please note the following.  J The new family of Compaq enterprise servers will support  Tru64 Unix, Open& VMS, and NonStop Kernel, complementing9 the company's market leadership in Windows 2000 and Linux                               .  @ http://www.intel.com/pressroom/archive/releases/20010625corp.htm   Suey   ------------------------------    Date: 25 Jun 2001 08:41:37 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett) $ Subject: Re: Intel/Alpha announcment, Message-ID: <1qcM09BXJA05@malvm5.mala.bc.ca>  1 In article <n0HZ6.77$rc5.3672@news.cpqcorp.net>, n8     "Sue Skonetski" <susan.skonetski@compaq.com> writes: > L > The new family of Compaq enterprise servers will support  Tru64 Unix, Open( > VMS, and NonStop Kernel, complementing; > the company's market leadership in Windows 2000 and Linux   >                              . > I    That's good news, but not complete enough. Will *every* Compaq product J which is sold for Alpha VMS today ( or last week ) be ported to IA64? WillK they all be available by January 2004? Do they have commitments from OracleuI to meet that schedule ( Oracle appear to be "excited" about Tru64 on IA64 I but didn't mention if they cared VMS would be available there )? Will alldE existing LP licenses be transferrable to IA64 at no cost ( to systems-G of comparable size)? [anyone who went through a VAX to Alpha transitionm will understand this question]  M    Will Compaq provide assistance to 3rd party vendors to move their products1H to IA64? Will IA64 ports be a straight "recompile and link" or will someO programs require substantial changes ( eg device drivers and privileged code )?u  K    I don't expect the answers are necessarily available today, but I wondereH how long it will be before such a detailed roadmap might be available soI that customers can start planning their transition ( or exit ) strategey.'E Personally I'd like to see a public beta test of IA64 VMS and layeredyE products as soon as possible ( and cheap VMS capable IA64 systems foraE development ) for *all* customers - not just CSA partners or the ilk.aD The sooner customers can see this stuff for themselves the sooner we- can assess how viable the strategy is for us.   N    I'm sorry if this sounds overly negative. I think that overall the strategyK is the only viable one - Alpha has been losing momentum and I don't see howpM Compaq could have afforded to continue with it. It's just a shame they didn'toK realize this several years ago and start development then ( or did they andAG just not tell anyone? ). In any case the next 2.5 years are going to be- "interesting".   ------------------------------  # Date: Mon, 25 Jun 2001 15:44:05 GMTo= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)-$ Subject: Re: Intel/Alpha announcment0 Message-ID: <009FE0F4.99D35F5E@SendSpamHere.ORG>  e In article <n0HZ6.77$rc5.3672@news.cpqcorp.net>, "Sue Skonetski" <susan.skonetski@compaq.com> writes:rF >Please look at this web site for some details on today's announcment. >d >Please note the following >zK >The new family of Compaq enterprise servers will support  Tru64 Unix, Openl' >VMS, and NonStop Kernel, complementing : >the company's market leadership in Windows 2000 and Linux >                             .  >rA >http://www.intel.com/pressroom/archive/releases/20010625corp.htme >t >Sue >i    I You realize that your job you love so well is in jeopardy?  Folks to thisnJ day can't seem to fathom Alpha and I'm still seeing folks cringe and cowerI to the prospects of porting to Alpha.  VMS will see a demise of EPIC pro-c portion now!  ) Feels good to be sold down the river, eh?.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMf             O city, n., 1. a place where trees are cut down and streets are named after them.t   ------------------------------  % Date: Mon, 25 Jun 2001 17:00:13 +0100i8 From: John Macallister <J.Macallister1@physics.ox.ac.uk>$ Subject: RE: Intel/Alpha announcmentN Message-ID: <35666012DF4CD411BE940090279FA240010BEFC7@ppnt41.physics.ox.ac.uk>  D Before becoming overexcited (or doom-laden) about any Alpha to IntelF conversion it may be helpful to consider a comparison of the Alpha and Itanium instruction sets.h  A The VAX->Alpha transition was relatively painless for most (99%?)o well-written user code.   G The reason that some packages were not converted completely from VAX to H Alpha was not the difficulty of conversion but rather that the companiesJ concerned did not believe it to be commercially worthwhile. There may be aF different attitude to converting to Intel as it's hard to believe thatJ anyone could take the view that converting software to run on Intel is not commercially viable. m   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)t   ------------------------------  % Date: Mon, 25 Jun 2001 17:15:17 +0100m- From: Tim Llewellyn <tim.llewellyn@bbc.co.uk>n$ Subject: Re: Intel/Alpha announcment) Message-ID: <3B376395.1EE8CC1E@bbc.co.uk>i  & "Brian Schenkenberger, VAXman-" wrote:  g > In article <n0HZ6.77$rc5.3672@news.cpqcorp.net>, "Sue Skonetski" <susan.skonetski@compaq.com> writes: H > >Please look at this web site for some details on today's announcment. > >  > >Please note the following > >oM > >The new family of Compaq enterprise servers will support  Tru64 Unix, Openf) > >VMS, and NonStop Kernel, complementing < > >the company's market leadership in Windows 2000 and Linux! > >                             .> > > C > >http://www.intel.com/pressroom/archive/releases/20010625corp.htmt > >f > >Sue > >I >,K > You realize that your job you love so well is in jeopardy?  Folks to this L > day can't seem to fathom Alpha and I'm still seeing folks cringe and cowerK > to the prospects of porting to Alpha.  VMS will see a demise of EPIC pro-r > portion now!  H Many people fear what they can't or won't understand. VMS is a technicalR solution that requires people to engage brain rather than just point, click, pray, reboot.o  A Was it your comment about a billion flies? Seems approriate here.g   >  >K+ > Feels good to be sold down the river, eh?w >e   you mean a second time?r     --6 Tim Llewellyn, OpenVMS Infrastructure, Remarcs Project0 MedAS at the BBC, Whiteladies Road, Bristol, UK.A Email tim.llewellyn@bbc.co.uk. Home tim.llewellyn@cableinet.co.uki  A I speak for myself only and my views in no way represent those ofa MedAS or the BBC.1   ------------------------------  % Date: Mon, 25 Jun 2001 13:10:28 -0300 ) From: fabio_compaq@ep-bc.petrobras.com.brp$ Subject: Re: Intel/Alpha announcmentL Message-ID: <OF1EE64170.6B852202-ON03256A76.0058CE95@ep-bc.petrobras.com.br>  8 Lets try to convince Compaq to sell OpenVMS to Intel ! !   Fabio C.        E system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) em 25/06/2001a 12:44:05  I Favor responder a system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)              Info-VAX@Mvb.Saic.Comt      $ Assunto: Re: Intel/Alpha announcment    @ In article <n0HZ6.77$rc5.3672@news.cpqcorp.net>, "Sue Skonetski"$ <susan.skonetski@compaq.com> writes:F >Please look at this web site for some details on today's announcment. >  >Please note the following >nK >The new family of Compaq enterprise servers will support  Tru64 Unix, OpenO' >VMS, and NonStop Kernel, complementingn: >the company's market leadership in Windows 2000 and Linux >                             .s >nA >http://www.intel.com/pressroom/archive/releases/20010625corp.htme >o >Sue >     I You realize that your job you love so well is in jeopardy?  Folks to thisMJ day can't seem to fathom Alpha and I'm still seeing folks cringe and cowerI to the prospects of porting to Alpha.  VMS will see a demise of EPIC pro-u portion now!  ) Feels good to be sold down the river, eh?p   --2 VAXman- OpenVMS APE certification number: AAA-0001 VAXman(at)TMESIS(dot)COM  I city, n., 1. a place where trees are cut down and streets are named after- them.e   ------------------------------  # Date: Mon, 25 Jun 2001 16:43:54 GMTs= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)5$ Subject: Re: Intel/Alpha announcment0 Message-ID: <009FE0FC.F5031D3B@SendSpamHere.ORG>  Y In article <3B376395.1EE8CC1E@bbc.co.uk>, Tim Llewellyn <tim.llewellyn@bbc.co.uk> writes:f >  >i' >"Brian Schenkenberger, VAXman-" wrote:a >fh >> In article <n0HZ6.77$rc5.3672@news.cpqcorp.net>, "Sue Skonetski" <susan.skonetski@compaq.com> writes:I >> >Please look at this web site for some details on today's announcment.r >> > >> >Please note the followingr >> >N >> >The new family of Compaq enterprise servers will support  Tru64 Unix, Open* >> >VMS, and NonStop Kernel, complementing= >> >the company's market leadership in Windows 2000 and LinuxO" >> >                             . >> >D >> >http://www.intel.com/pressroom/archive/releases/20010625corp.htm >> > >> >Suew >> > >>L >> You realize that your job you love so well is in jeopardy?  Folks to thisM >> day can't seem to fathom Alpha and I'm still seeing folks cringe and coweraL >> to the prospects of porting to Alpha.  VMS will see a demise of EPIC pro- >> portion now!D >NI >Many people fear what they can't or won't understand. VMS is a technicalnS >solution that requires people to engage brain rather than just point, click, pray,@ >reboot. >rB >Was it your comment about a billion flies? Seems approriate here.  J Yes.  Only this time it's eat shit or famine.  As Homer Simpson might say:
 Hmmm... shit!-   >  >> >>, >> Feels good to be sold down the river, eh? >> >  >you mean a second time?  @ This time we're too dangerously close to the mouth of the river.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM-            <O city, n., 1. a place where trees are cut down and streets are named after them.V   ------------------------------   Date: 25 Jun 2001 17:04:49 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)$ Subject: RE: Intel/Alpha announcment, Message-ID: <9h7qvh$fql@gap.cco.caltech.edu>   In article <35666012DF4CD411BE940090279FA240010BEFC7@ppnt41.physics.ox.ac.uk>, John Macallister <J.Macallister1@physics.ox.ac.uk> writes:hE >Before becoming overexcited (or doom-laden) about any Alpha to Intel G >conversion it may be helpful to consider a comparison of the Alpha and, >Itanium instruction sets. >hB >The VAX->Alpha transition was relatively painless for most (99%?) >well-written user code. - >-H >The reason that some packages were not converted completely from VAX toI >Alpha was not the difficulty of conversion but rather that the companies K >concerned did not believe it to be commercially worthwhile. There may be aiG >different attitude to converting to Intel as it's hard to believe that K >anyone could take the view that converting software to run on Intel is notf >commercially viable.   K The question is whether VMS can survive the transition at all - and plenty 2L of reason that Compaq itself doesn't want it too.  (Hey, then they can just E sell Microsoft software and forget about OS development altogether). -G There's enough uncertainty here to sink the product of a solid company,JD never mind a meathead outfit like Compaq.  (That's the Archie BunkerJ definition of meathead - "Dead from the neck up".)   We may well find thatI rather than convert to VMS/IA64 3rd party vendors will throw in the towel I and convert instead to Linux/ IA64 or Windows???/IA64.  The code will endo. up running on the hardware but not on the OS.    Regards,   David Mathog mathog@caltech.edu? Manager, sequence analysis facility, biology division, Caltech hJ **************************************************************************J *                       RIP VMS & ALPHA                                  *J **************************************************************************   ------------------------------  % Date: Mon, 25 Jun 2001 07:58:24 -0700n! From: Tom Linden <tom@kednos.com>S Subject: Itanium HW REF MANm9 Message-ID: <CIEJLCMNHNNDLLOOGNJIGEFNCNAA.tom@kednos.com>r   Anybody know ehere to get one?   ------------------------------  % Date: Mon, 25 Jun 2001 10:57:09 -0400V From: Kaye <kaye@cisny.com>rI Subject: job: (recruiter) NYC: Solaris/OpenVMS or Tru64 admin (recruiter)a) Message-ID: <3B375145.830C8E60@cisny.com>y  , This is a multi-part message in MIME format.& --------------8CCAC42224DD409C07F1FEA9* Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bite  A Please accept my apologies in advance if this posting is severely  against the ng rules:l  F A financial sector client of mine, located in midtown Manhattan, NY isE seeking a senior systems administrator. The position's duties includeeD 24X7 on call support, monitoring distributed systems infrastructure,G creating and updating support documentation, server maintenance, server H backup/restore, build and maintain server and other related peripherals,B as well as representing the team on firm initiatives, and managing various projects.e  @ The postion supports sites in both midtown Manhattan and central Westchester.  B The candidate should have 3+ years of experience with Sun Solaris.E Knowledge of Veritas (or EMC), as well as Shell Scripting (C/Bourne), 9 and NIS/NFS. In addition, the applicant must be have goodrD knowledge/experience with OpenVMS and/or Tru64. Individual should beH familiar with operational disciplines such as Problem Management, ChangeA Management, Network/Server Monitoring, Systems Monitoring, Server G Backups/Restores, Multi Platform Integration/Communication, and Projects Management.)  H Salary to about 115K, plus bonus, contributory 401K, excellent benefits,+ very profession though casual environment. i  E No H1-B transfers, and a strong reluctance to relocate a candidate oni$ the client's part. Sorry about that.  B All responses treated with the greatest confidentiality, referrals greatly appreciated.   Thanks,: Art5 -- r/ Arthur Kaye                      v.212-293-4353j/ Concepts in Staffing             f.212-652-0789D/ 9 E. 37th St. 2nd Floor          kaye@cisny.coma New York, NY 10013 212-725-0300& --------------8CCAC42224DD409C07F1FEA9- Content-Type: text/x-vcard; charset=us-ascii;<  name="kaye.vcf" Content-Transfer-Encoding: 7bita" Content-Description: Card for Kaye  Content-Disposition: attachment;  filename="kaye.vcf"   begin:vcard 
 n:Kaye;Arthurt tel;fax:212-656-0789 tel;work:212-293-4353h x-mozilla-html:FALSE url:www.cisny.comy+ org:Concepts in Staffing;Technical Services03 adr:;;9 E. 37th St. 2nd Floor;New York;NY;10016;USAo version:2.1b email;internet:kaye@cisny.como title:Sr. Vice President fn:Arthur Kaye	 end:vcardh  ( --------------8CCAC42224DD409C07F1FEA9--   ------------------------------  % Date: Mon, 25 Jun 2001 12:12:22 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)M Subject: Re: job: (recruiter) NYC: Solaris/OpenVMS or Tru64 admin (recruiter) L Message-ID: <rdeininger-2506011212220001@user-2ivebei.dialup.mindspring.com>  F In article <3B375145.830C8E60@cisny.com>, Kaye <kaye@cisny.com> wrote:  C > Please accept my apologies in advance if this posting is severely  > against the ng rules:-  - No objection, except we don't like MIME here.c  H > A financial sector client of mine, located in midtown Manhattan, NY isG > seeking a senior systems administrator. The position's duties include F > 24X7 on call support, monitoring distributed systems infrastructure,I > creating and updating support documentation, server maintenance, serverdJ > backup/restore, build and maintain server and other related peripherals,D > as well as representing the team on firm initiatives, and managing > various projects.i > B > The postion supports sites in both midtown Manhattan and central > Westchester. > D > The candidate should have 3+ years of experience with Sun Solaris.G > Knowledge of Veritas (or EMC), as well as Shell Scripting (C/Bourne),,; > and NIS/NFS. In addition, the applicant must be have goodoF > knowledge/experience with OpenVMS and/or Tru64. Individual should beJ > familiar with operational disciplines such as Problem Management, ChangeC > Management, Network/Server Monitoring, Systems Monitoring, Server I > Backups/Restores, Multi Platform Integration/Communication, and Projectd
 > Management., > J > Salary to about 115K, plus bonus, contributory 401K, excellent benefits,- > very profession though casual environment. c > G > No H1-B transfers, and a strong reluctance to relocate a candidate on-& > the client's part. Sorry about that.  I One point you omitted.  Since this is a NYC financial company, don't evenlE bother to apply unless you already work for a NYC financial company. aH Skills don't matter. If you're not in the club, the recruiter won't even< take your calls, let alone forward your resume the the firm.   -- r Robert Deininger rdeininger@mindspring.com    ------------------------------  # Date: Mon, 25 Jun 2001 09:59:42 GMT + From: "Darren Peacock" <daz005@hotmail.com> " Subject: Re: Marketing Rantings #3@ Message-ID: <iYDZ6.158251$ff.1221217@news-server.bigpond.net.au>   VMS IA64 Low cost workstation.  : My money is on the announcement internally on June 25 USA.  * Wintel is about to get a serious shake-up.  G Java on VMS gives us back world class development products product likeIG Borland Jbuilder, Apache Org, gives us state of the art Jakarta Projectl products. Tomcat,James,Jmeter L  And COE gives us the opportunity to give people an opportunity to look at aK lower TCO than most Server PLatforms, and the Application vendors a serious H alternative to easily port their applications  and of course the 20 year commitment.?  3 It all sounds like a great plan is coming together.w      @ "cstranslations" <cstranslations@email.msn.com> wrote in message# news:ewVyOoC$AHA.291@cpmsnbbsa07...c >hA > "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messagei5 > news:S_VY6.561$m6.494677@typhoon.ne.mediaone.net...a > >o= > Now, if VMS was to be ported to another 64-bit architecture)G > > (preferably one that will enjoy tremendous market penetration), then rulese > ofL > > the game might change. More places for VMS to run (imagine VMS on a DellH > > Itanium server, hehehe), and less ISV concern about Alpha longevity. > >oK > > Folks in this forum have long asked for an architectural port of VMS (IhL > > suggested same to Jesse Lipcon back in '94, alas DEC listened to GartnerL > > Group (Probability Factor that Analyst was wearing Armani Suit: 0.9) andK > > bought into their specious Affinity Scheme. But what goes around, comestG > > around. And as for an architectural port, like the saying goes, "bev	 > carefule. > > what you wish for, you just might get it." >n >a> > You've been dropping "hints" here, there, and everywhere (in comp.os.vms)...- >-6 > So Terry, what is it that you've been trying to say? >n >a   ------------------------------  % Date: Mon, 25 Jun 2001 06:45:23 -0400c- From: JF Mezei <jfmezei.spamnot@videotron.ca>r" Subject: Re: Marketing Rantings #3, Message-ID: <3B371642.25E99AB4@videotron.ca>   Darren Peacock wrote:t  > VMS IA64 Low cost workstation.< > My money is on the announcement internally on June 25 USA., > Wintel is about to get a serious shake-up. > I > Java on VMS gives us back world class development products product likepI > Borland Jbuilder, Apache Org, gives us state of the art Jakarta Project  > products. Tomcat,James,Jmeter     M But consider what happens to VMS during the transition. VMS is now recovering J from a serious murder attempt and not yet very strong.   And since Jave onJ VMS/Alpha hasn't brough billions of new customers, do you expect that JAVAG will attract billions of new customers on VMS because it runs on IA64 ?o    5 > It all sounds like a great plan is coming together.h  G But my opinion is that Compaq is drawing a great plan that will benefitT. Microsoft more than it will benefit VMS users.   ------------------------------  % Date: Mon, 25 Jun 2001 08:58:05 -0500-+ From: Christopher Smith <csmith@amdocs.com>1" Subject: RE: Marketing Rantings #3L Message-ID: <3B55D7F383B0D31197D9009027541CBF0D9D1FCF@cmiexch1.cmi.itds.com>   > -----Original Message-----1 > From: Hamlyn Mootoo [mailto:univms@bigfoot.com]e  G > original had been written in BLISS !!!!  A lot of "NT Administrators"i< > are tired of getting bashed by their UNIX /IBM OS/DEC VMS  > counterparts,t> > and want to learn something other than point and click.  As   J Can you cite a reference for this data? :)  It would be good news to me if9 some of the kiddies wanted to shed their training wheels.    Regards,   Chrisi  ! Christopher Smith, Perl Developerc Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");e 's  '   ------------------------------  % Date: Mon, 25 Jun 2001 09:06:56 -0500 + From: Christopher Smith <csmith@amdocs.com>m" Subject: RE: Marketing Rantings #3L Message-ID: <3B55D7F383B0D31197D9009027541CBF0D9D1FD1@cmiexch1.cmi.itds.com>  J I can't be the only one who thinks that this entire response sounds like a big hint, can I?   Regards,   Chris-  ! Christopher Smith, Perl Developer2 Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");t 'e  g   > -----Original Message-----; > From: Terry C. Shannon [mailto:terryshannon@mediaone.net]e  = > You can only sell a product for which there is a need, and n > apps availabilityt> > and the current Alpha and VAX platform dependence limit the 
 > addressable : > market for VMS. Now, if VMS was to be ported to another  > 64-bit architecturer4 > (preferably one that will enjoy tremendous market  > penetration), the rules of= > the game might change. More places for VMS to run (imagine   > VMS on a Dell F > Itanium server, hehehe), and less ISV concern about Alpha longevity.  @ > Folks in this forum have long asked for an architectural port  > of VMS (I @ > suggested same to Jesse Lipcon back in '94, alas DEC listened  > to Gartner< > Group (Probability Factor that Analyst was wearing Armani  > Suit: 0.9) and< > bought into their specious Affinity Scheme. But what goes  > around, comesc< > around. And as for an architectural port, like the saying  > goes, "be carefulg, > what you wish for, you just might get it."   ------------------------------    Date: 25 Jun 2001 10:21:41 -05009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow) " Subject: Re: Marketing Rantings #33 Message-ID: <IPfeC0pwzYFt@eisner.encompasserve.org>r  V In article <3B33F0F6.96F2BBA6@bigfoot.com>, Hamlyn Mootoo <univms@bigfoot.com> writes:H > Sys Admin with several commercial UNIXes including OSF/1 slash DigitalJ > Unix slash Name of the Month) was by neccesity/force.  I had heard about    , Looks like the next name for Tru64 is LINUX!   ------------------------------  % Date: Mon, 25 Jun 2001 11:46:46 +0100a From: paul.beaudoin@hsbc.com4 Subject: Memo:  Re: MACRO:include externals how to ?E Message-ID: <OF6F0A0D04.8A7340D0-ON80256A76.003A37C5@systems.uk.hsbc>i  ! Yep - that is not very difficult:   8 Create your 'def' module containing something like this:           $DEFINI EMUCNTDEF,$GBLD ; Counter monitor section. This is where process store event counts.G ; Used to display the running system and for the AUTOTUNER to determine. ; system params. ; GlobalB $EQU    CNT_GBL_C_SIZE          4       ; Size of section in pages ; Constantsb ; States! $EQU    CNT_STA_C_OFF           0.! $EQU    CNT_STA_C_ON            1n! $EQU    CNT_STA_C_HIB           2i! $EQU    CNT_STA_C_WAT           3,! $EQU    CNT_STA_C_RUN           4o: $EQU    CNT_STA_C_WFL           5       ; Wait for flag(s)   .d .n
  And so on  "         $DEFEND EMUCNTDEF,$GBL,DEF
         .ENDMr   Place this in a macro library:   $LIBR/CREATE/MACRO MYLIB.MLB $LIBR/INSERT MYLIB MYMODULEe  ; In your program include (before data definitions and code):h  -         .LIBRARY        /SYS$LIBRARY:LIB.MLB/w-         .LIBRARY        /disk:[dir]MYLIB.MLB/w6         MYMODULE                       ; The constants  e At compile/assembly time references to the symbols (CNT_STA_C_ON) will be replaced with the value (1)M  
 To change:   Edit the file  and then:   $LIBR/REPLACE MYLIB MYMODULE   Hope this helpsh     Paul        D ********************************************************************B  This message and any attachments are confidential to the ordinaryB  user of the e-mail address to which it was addressed and may also>  be privileged. If you are not the addressee you may not copy,8  forward, disclose or use any part of the message or itsC  attachments and if you have received this message in error, pleasewB  notify the sender immediately by return e-mail and delete it from
  your system.o  =  Internet communications cannot be guaranteed to be secure or>A  error-free as information could be intercepted, corrupted, lost,q>  arrive late or contain viruses. The sender therefore does not?  accept liability for any errors or omissions in the context ofi?  this message which arise as a result of Internet transmission.   >D  Any opinions contained in this message are those of the author and ?  are not given or endorsed by the HSBC Group company or office  =  through which this message is sent unless otherwise clearly tA  indicated in this message and the authority of the author to so r3  bind the HSBC entity referred to is duly verified.f  D ********************************************************************   ------------------------------  % Date: Mon, 25 Jun 2001 17:52:15 +0400a4 From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU>8 Subject: Re: Memo:  Re: MACRO:include externals how to ?0 Message-ID: <3B37420F.9380E804@SMTP.DeltaTel.RU>   Thanks.i     paul.beaudoin@hsbc.com wrote:m > # > Yep - that is not very difficult:  > : > Create your 'def' module containing something like this: >   >         $DEFINI EMUCNTDEF,$GBLF > ; Counter monitor section. This is where process store event counts.I > ; Used to display the running system and for the AUTOTUNER to determinea > ; system params.
 > ; GlobalD > $EQU    CNT_GBL_C_SIZE          4       ; Size of section in pages
 > ; Constants2
 > ; States# > $EQU    CNT_STA_C_OFF           0.# > $EQU    CNT_STA_C_ON            1l# > $EQU    CNT_STA_C_HIB           2v# > $EQU    CNT_STA_C_WAT           3c# > $EQU    CNT_STA_C_RUN           41< > $EQU    CNT_STA_C_WFL           5       ; Wait for flag(s) >  > .c > .a >  And so on > $ >         $DEFEND EMUCNTDEF,$GBL,DEF >         .ENDMp >   > Place this in a macro library: >  > $LIBR/CREATE/MACRO MYLIB.MLB > $LIBR/INSERT MYLIB MYMODULEi > = > In your program include (before data definitions and code):r > / >         .LIBRARY        /SYS$LIBRARY:LIB.MLB/a/ >         .LIBRARY        /disk:[dir]MYLIB.MLB/e8 >         MYMODULE                       ; The constants > g > At compile/assembly time references to the symbols (CNT_STA_C_ON) will be replaced with the value (1)i >  > To change: >  > Edit the file  and then: >  > $LIBR/REPLACE MYLIB MYMODULE >  > Hope this helpsc >  > Paul > F > ********************************************************************D >  This message and any attachments are confidential to the ordinaryD >  user of the e-mail address to which it was addressed and may also@ >  be privileged. If you are not the addressee you may not copy,: >  forward, disclose or use any part of the message or itsE >  attachments and if you have received this message in error, pleaseeD >  notify the sender immediately by return e-mail and delete it from >  your system.h > ? >  Internet communications cannot be guaranteed to be secure orhC >  error-free as information could be intercepted, corrupted, lost, @ >  arrive late or contain viruses. The sender therefore does notA >  accept liability for any errors or omissions in the context oflA >  this message which arise as a result of Internet transmission.* > E >  Any opinions contained in this message are those of the author and @ >  are not given or endorsed by the HSBC Group company or office> >  through which this message is sent unless otherwise clearlyB >  indicated in this message and the authority of the author to so5 >  bind the HSBC entity referred to is duly verified.i > F > ********************************************************************   -- d Cheers,eF +OpenVMS [Sys|Net] HardWorker........................................+E  Russia,Delta Telecom Inc,                    Cel:  +7 (901) 971-3222tE  191119,St.Petersburg,Transportny per. 3                     116-32225F +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm +   ------------------------------  % Date: Mon, 25 Jun 2001 17:07:37 +0200== From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>a Subject: not about Itanium) Message-ID: <3B3753B9.7A565533@gtech.com>l  ) http://xforce.iss.net/alerts/advise80.phpd   Arne   ------------------------------  % Date: Mon, 25 Jun 2001 11:04:52 +0200s7 From: Alain Chappuis <alain.chappuis@medecine.unige.ch>b Subject: Question about DCPS1 Message-ID: <3B36FEB4.B0F50288@medecine.unige.ch>    Hello,9 I have a printer DECLaser 2200 connected on a port seriest& of our AS255 which uses protocol DCPS.; This printer broke down, no spare part available to repair.    My question is: = is it possible to connect for example an HP laserjet 4000 PS?t by using DCPS?9 if so, somebody would have it an example of configurationi DCPS for this kind of printer.   Many thanks in advance.n Alain. --D +----------------------+-------------------------------------------+D | Alain Chappuis       | Responsable: E-mail; cmu.unige.ch         |D | Analyste programmeur | WEB    : www.medecine, ebn, jid, Sifm     |D | Universite de Geneve | E-mail : Alain.Chappuis@unige.ch          |D | Centre Medical Univ. | Phone  : +41 (22) [70]25.073              |D | 1, Rue Michel-Servet | FAX    : +41 (22) 347.33.34 ou 702.58.58  |K | CH-1211 Geneve 4     | http://cmub.unige.ch/www/si/alain.html    |       rD +----------------------+-------------------------------------------+   ------------------------------    Date: 25 Jun 2001 12:10:33 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER)  Subject: Re: Question about DCPS( Message-ID: <3b370e19@news.kapsch.co.at>  k In article <3B36FEB4.B0F50288@medecine.unige.ch>, Alain Chappuis <alain.chappuis@medecine.unige.ch> writes:o: >I have a printer DECLaser 2200 connected on a port series' >of our AS255 which uses protocol DCPS.e< >This printer broke down, no spare part available to repair.  ' IIRC, it used to have a CANON engine...t   >My question is: c> >is it possible to connect for example an HP laserjet 4000 PS? >by using DCPS?9  & Yup (with a more recent DCPS version). DCPS V2.0 is current.y  : >if so, somebody would have it an example of configuration >DCPS for this kind of printer.;  N Serial or LAT or TCPIP-Stream (or TCPIP-LPD, which is not supported by DCPS) ?   -- a< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-8882< <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------    Date: 25 Jun 2001 01:50:49 -0500+ From: young_r@encompasserve.org (Rob Young)6' Subject: Re: Question to Charlie Matco.:3 Message-ID: <cOMTxzKay4xF@eisner.encompasserve.org>o  \ In article <3B36C09F.318C1BE9@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > Mister Matco,e > , > Hopefully your dog Muttco is doing well... > N > However, considering the rumours floating around, I have a question for you. > N > The 180 days of transformation memo has been made public. This memo does notN > seem to bode well for VMS and Alpha. Yet, you have stated that VMS customers > have nothing to worry about. > 6 > You obviously have additional information, correct ? > P > Based *ONLY* on that 180 day memo, do you agree that VMS customers have reasonJ > to fear a long period of uncertainty during some form of transition to a > industry standard platform ?  B 	Charlie may or not be available... but this is Usenet , a private 	conversation it ain't!)  B 	Think about that last paragraph that you are proposing.  We spentD 	a few years speculating on that as far as HP was/is concerned.  The@ 	VMS folks are pretty unique in that they have gone through this< 	once already, from VAX to Alpha and there is still a ton of= 	VAX stuff out there.  Did Sun have a field day attempting toC? 	FUD up the VAX to Alpha transition?  Did they slip in and grab ; 	VAX customers?  Sure they did... and it is happening todaye 	too.e  @ 	Compaq is taking a chance, you say?  Maybe not.  Maybe they can> 	speak the one platform voice 3 years from now.  Much like Sun? 	is today.  Sun will be on a big loser, Compaq will be on a bigY@ 	winner as the Alpha transitions to IA64.  If that is what is toF 	take place.  Shoot, maybe some future Alpha has an IA64 compatability@ 	mode!  Either way, the volume leader is Intel... if VMS runs on: 	the volume leader, maybe I finally get a VMS box at home.   				Robg   ------------------------------  % Date: Mon, 25 Jun 2001 02:47:28 -04000- From: JF Mezei <jfmezei.spamnot@videotron.ca>5' Subject: Re: Question to Charlie Matco.n, Message-ID: <3B36DE7F.7487024F@videotron.ca>   Rob Young wrote:I >         VMS folks are pretty unique in that they have gone through thisnE >         once already, from VAX to Alpha and there is still a ton ofu >         VAX stuff out there. o  K The problem is that VMS was a lot stronger starting the transition to Alphae8 than it is now, supposedly starting the IA64 transition.  F Furthermore, VMS->Alpha was clearly seen as a performance improvement.K Alpha->IA64 is seen as a downgrade and giving up on a superior chip becauseeL Compaq admits defeat in the face of a chip that is barely out in the market.    H >         is today.  Sun will be on a big loser, Compaq will be on a big2 >         winner as the Alpha transitions to IA64.  M If the snail is the only remaining contestant in the race, do you consider ithL a winner ? Just because everyone else has dropped out because they were leadM to beleive that the snail was going to win for sure, it doesn't mean that the  snail is good.    N I do not know what sort of compromises will have to be made for VMS to abandonI Alpha and run on commodity low quality architecture. How will that affectS# Galaxy , the boot loader etc etc ?.e  J How long will it take before VMS engineers such as Huff can publicly speak about this project ?  O >         take place.  Shoot, maybe some future Alpha has an IA64 compatabilitysI >         mode!  Either way, the volume leader is Intel... if VMS runs onaC >         the volume leader, maybe I finally get a VMS box at home.c    J It remains to be seen if IA64 boxes will become de-facto standard for homeM machines. The companies may decide to do a "Digital" and keep IA64 out of the H smaller machines in onder to prevent large shops from buying cheap IA64sK instead of large multi-million dollar IA64s with the same processing power.t  E Remember that we are talking about IA64 having a near monopoly of all1J processors from the desktop to the supercomputers with no competition everL coming forth. A bit like setting the gauge for all railroads in a continent.I Once done, nobody else will build different gauge railway, except in verya limited remote cases.o  K Alpha was seen as the only possible true competitor to IA64. By killing it, 5 Compaq is permanently changing the face of computing.l   ------------------------------    Date: 25 Jun 2001 11:42:05 -0500- From: koehler@encompasserve.org (Bob Koehler) ' Subject: Re: Question to Charlie Matco. 3 Message-ID: <NivvMO9g2uTm@eisner.encompasserve.org>s  a In article <cOMTxzKay4xF@eisner.encompasserve.org>, young_r@encompasserve.org (Rob Young) writes:   ) > 	Did Sun have a field day attempting toaA > 	FUD up the VAX to Alpha transition?  Did they slip in and grab  > 	VAX customers?   F So does Sun think they can stand alone on the already behind the curveD SPARC*?  Or will they face the music and move us all toward a singleD architecture universe?  At least they can start with a Solaris which aleeady runs on Intel.  1 * - for Andrew:  yes I know its still competitiveR  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporationr= NASA GSFC Flight Software       | Federal Sector, Civil GroupdE                                 | please remove ".aspm" when replying    ------------------------------    Date: 25 Jun 2001 11:55:20 -0500- From: koehler@encompasserve.org (Bob Koehler)d' Subject: Re: Question to Charlie Matco.f3 Message-ID: <6URAdhbG6Syd@eisner.encompasserve.org>e  \ In article <3B36DE7F.7487024F@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > H > Furthermore, VMS->Alpha was clearly seen as a performance improvement.M > Alpha->IA64 is seen as a downgrade and giving up on a superior chip because-  > Alpha->IA64 may be seen by many as a cost/performance upgrade,E especially for VMS users if it can be made to run on at least a large3 subset of the systems shipping.D  @ Or it may be viewed as a purchase cost improvement.  Even if theE performace is not the same a PC price can be a driving factor.  A lot?H of the power of my 2 year old Pentium isn't in use; I only have a coupleG apps which strain my 8 year old Alpha.  My work could easily be done onrE an IA-64 that's just a bit faster than my Pentium, and a lot of otherm folks can live with this, too.  G Compaq has made a major commitment in engineering dollars in announcingaD the port of VMS.  I don't know the IA-64, but if it's like any otherC Intel descended from the 8086, they'll have to deal with call gatesiG instead of exceptions to change modes, and virtual memory management by G page but memory protection by segment.  Those are no small issues.  I'dhH really like to hear from Compaq up front how they are going to deal withF this (Mach maybe?).  Sounds like VMS engineering will have to hire.  I expect similar issues for NSK.  F What I don't understand is Compaq's commitment to port Tru64.  Where'sF the market for one more UNIX on what will be a popular platform?  TheyH can possibly get there first since Tru64 is absolutely 64 bit clean, butC can they create and hold onto a lead better than DEC did by gettinge< OSF/1 out on Alpha?  Why not just continue to resell SCO and preconfigured Linux boxes?  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporationo= NASA GSFC Flight Software       | Federal Sector, Civil GroupgE                                 | please remove ".aspm" when replyinge   ------------------------------  % Date: Mon, 25 Jun 2001 12:17:54 -0400:2 From: rdeininger@mindspring.com (Robert Deininger)' Subject: Re: Question to Charlie Matco. L Message-ID: <rdeininger-2506011217540001@user-2ivebei.dialup.mindspring.com>  5 In article <3B36DE7F.7487024F@videotron.ca>, JF Mezei-% <jfmezei.spamnot@videotron.ca> wrote:   G > Remember that we are talking about IA64 having a near monopoly of alleL > processors from the desktop to the supercomputers with no competition everN > coming forth. A bit like setting the gauge for all railroads in a continent.K > Once done, nobody else will build different gauge railway, except in veryo > limited remote cases.p > M > Alpha was seen as the only possible true competitor to IA64. By killing it,N7 > Compaq is permanently changing the face of computing._  J I mostly agree, except nothing is permanent.  If Intel ends up with a nearJ monopoly, they will get fatter and sloppier.  They'll stop enhancing theirF CPUs, begin investing money in sidelines, and go to sleep.  Eventually someone will knock them down.o  G The ONLY way to maintain a monopoly in an open market is to keep movingd: ahead.  Without competitors, I don't think that is likely.  J Intel may do very well for a while, and computing may stagnate.  Not good.   -- B Robert Deininger rdeininger@mindspring.com    ------------------------------  % Date: Mon, 25 Jun 2001 12:08:48 -0400B+ From: John Eisenschmidt <jeisensc@aaas.org>M' Subject: Re: Question to Charlie Matco. # Message-ID: <sb3729ed.064@aaas.org>m  & Another Unix on a popular port indeed.  L Is everyone aware that last week NetBSD announced a successful port to the =G AMD Sledgehammer? The CPU that doesn't exist yet? Not to mention 1000 = K different Linux distributions (well, Redhat with a different web browser, =i but don't tell them that).  E The only reason to port it are the intangibles, working clustering, =iD software RAID, a decent 64bit C compiler (things that keep Solaris = installed on Ultra Sparcs).a  F >>> Bob Koehler <koehler@encompasserve.org> 06/25/2001 12:55:20 PM >>>L In article <3B36DE7F.7487024F@videotron.ca>, JF Mezei <jfmezei.spamnot@vide= otron.ca> writes:n >=20H > Furthermore, VMS->Alpha was clearly seen as a performance improvement.G > Alpha->IA64 is seen as a downgrade and giving up on a superior chip =u becauset  > Alpha->IA64 may be seen by many as a cost/performance upgrade,E especially for VMS users if it can be made to run on at least a largei subset of the systems shipping.   @ Or it may be viewed as a purchase cost improvement.  Even if theE performace is not the same a PC price can be a driving factor.  A lotCH of the power of my 2 year old Pentium isn't in use; I only have a coupleG apps which strain my 8 year old Alpha.  My work could easily be done onhE an IA-64 that's just a bit faster than my Pentium, and a lot of other* folks can live with this, too.  G Compaq has made a major commitment in engineering dollars in announcing D the port of VMS.  I don't know the IA-64, but if it's like any otherC Intel descended from the 8086, they'll have to deal with call gates G instead of exceptions to change modes, and virtual memory management byaG page but memory protection by segment.  Those are no small issues.  I'd H really like to hear from Compaq up front how they are going to deal withF this (Mach maybe?).  Sounds like VMS engineering will have to hire.  I expect similar issues for NSK.  F What I don't understand is Compaq's commitment to port Tru64.  Where'sF the market for one more UNIX on what will be a popular platform?  TheyH can possibly get there first since Tru64 is absolutely 64 bit clean, butC can they create and hold onto a lead better than DEC did by getting_< OSF/1 out on Alpha?  Why not just continue to resell SCO and preconfigured Linux boxes?  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences CorporationD= NASA GSFC Flight Software       | Federal Sector, Civil Group E                                 | please remove ".aspm" when replyingn   ------------------------------  + Date: Mon, 25 Jun 2001 17:40:51 +0000 (UTC)Y' From: david20@alpha1.mdx.ac.uk (D.Webb) ' Subject: Re: Question to Charlie Matco. + Message-ID: <9h7t33$gor$2@aquila.mdx.ac.uk>c   In article <rdeininger-2506011217540001@user-2ivebei.dialup.mindspring.com>, rdeininger@mindspring.com (Robert Deininger) writes:g6 >In article <3B36DE7F.7487024F@videotron.ca>, JF Mezei& ><jfmezei.spamnot@videotron.ca> wrote: >  >aK >I mostly agree, except nothing is permanent.  If Intel ends up with a near*K >monopoly, they will get fatter and sloppier.  They'll stop enhancing theireG >CPUs, begin investing money in sidelines, and go to sleep.  Eventuallyv >someone will knock them down. >eH >The ONLY way to maintain a monopoly in an open market is to keep moving; >ahead.  Without competitors, I don't think that is likely.  >oK >Intel may do very well for a while, and computing may stagnate.  Not good.r >   F But who is going to have enough money to design and FAB a new chip to 7 compete with Intel even if they do get fat and sloppy ?c    
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  % Date: Mon, 25 Jun 2001 17:13:26 +0200e. From: "Jose Carlos Duclos" <duclos@arrakis.es> Subject: Req VMS Tutoriali* Message-ID: <3b3754f0$1_3@news.arrakis.es>  3 I'm looking for a good VMS-VAX tutorial in Interneto  B I've been looking for it but I haven't found anything interesting.   Thanks   ------------------------------  % Date: Mon, 25 Jun 2001 12:08:11 -0400i2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: Req VMS Tutorial L Message-ID: <rdeininger-2506011208120001@user-2ivebei.dialup.mindspring.com>  ? In article <3b3754f0$1_3@news.arrakis.es>, "Jose Carlos Duclos". <duclos@arrakis.es> wrote:  5 > I'm looking for a good VMS-VAX tutorial in Internett > D > I've been looking for it but I haven't found anything interesting.    ? Your best starting point is the VMS FAQ, which you can find via+H www.openvms.compaq.com.  It will also point you to the VMS documentationJ set, which is available on the web.  You may want to read the introductory user-level manuals.e   -- D Robert Deininger rdeininger@mindspring.como   ------------------------------  # Date: Mon, 25 Jun 2001 17:06:09 GMT-2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: Req VMS Tutoriald0 Message-ID: <5cKZ6.97$rc5.4111@news.cpqcorp.net>  [ In article <3b3754f0$1_3@news.arrakis.es>, "Jose Carlos Duclos" <duclos@arrakis.es> writes:e4 :I'm looking for a good VMS-VAX tutorial in Internet  I   Please check the OpenVMS FAQ -- specifically the section "DOC11. Where q9   can new users find tutorial information about OpenVMS?"a  H   Note: "VMS-VAX" is more commonly refered to as "OpenVMS VAX", and thisF   trivia may well help you better understand when you are reading the    available materials.  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: Mon, 25 Jun 2001 08:41:11 -05004+ From: Christopher Smith <csmith@amdocs.com>tY Subject: RE: Reward for the first of the next 50 posts: which company	shouldbuy VMS VMS V-L Message-ID: <3B55D7F383B0D31197D9009027541CBF0D9D1FCC@cmiexch1.cmi.itds.com>   > -----Original Message-----6 > From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]% > Sent: Friday, June 22, 2001 6:05 PMp > To: Info-VAX@Mvb.Saic.Com6G > Subject: Re: Reward for the first of the next 50 posts: which company. > shouldbuy VMS VMS VMSv >  >  > John Eisenschmidt wrote:E > > >>> Christof Brass <brass@infopuls.com> 06/22/2001 3:29:28 PM >>>eF > > > I personally know a few (very few) managers with more brain thanF > > > most of their employees. These people don't watch TV (one or two  < > > I agree. That's why my manager is someone who does know  > what she's doing.v  < > Self selection.  Of course, the few VMS sites that remain  > have managementn@ > which have been able to resist the tidal wave of brainwashing  > to go UNIX/NT.9 > So if course, if you are a VMS shop, you will see that E > managers are smart.   J Well, being one of the contributors to the downside of this thread, I feelG compelled to state here that my managers for at least two levels up (mytJ manager, and his) are very competent people, and know their business.  I'mI even told (and have no reason not to believe) that they've both done some G programming in the past.  They also know when to ask questions, though,M+ unfortunately, we aren't a VMS shop here.  m  G In fact, we are so dependant upon NT that it makes me sick.  Of course,mI myself -- and several people over my head -- I have no bearing on companyd policy at large...  H As with any large company there are other things as well, including someH Unix, and s/390 that I know of.  I've been told we have some VMS systemsI around somewhere but have never spoken to anyone who works with them yet.a  J I'm sure one day somebody will call me because the disk has been filled onF one of them and I'm the only one left in the company with VMS on their	 resume ;),  = > But i have lost customers becasue when the new manager was r > brought in, he wasG > convinced that the organisation HAD to go ALL microsoft with the onlyl@ > exception: ADOBE Page Maker and Framemaker. His reasoning was  > that by goingt> > all microsoft, he was sure of having the right applications  > available, and bes; > able to find lots of people to hire because that is what S > people are trained   Let me be the first to say:g  " Idiot. (Him, not you, of course :)  > > And you know what the microsoft weenies do: "yeah, I can do  > that with just a: > PC and a single user version of Access , mplemeted in 3  > weeks". Then, when? > they start to look at the project, they realise that they'll   > need a server : > farm, quite a few copies of MS-SQL, hires twice as many  > weenies and that the; > precvt will take 2 years instead of 2 weeks, but by that l > time, the guy waso> > already hired and decision made to go that way. I have seen  > that happen many times.h  C .. and you know that when / if it ever gets done -- even if it's onw schedule, it's garbage.I  G Something Christof said once about building a house from feces comes totJ mind.  It's possible, but I wouldn't want to live in one, nor would I want to make one.  G > And this is where the entry-level cost of VMS is so important for its  > survival.    Can't argue there.  = > If you are going to restrict VMS only to those shops where o > managers are the@ > old-style where technical is more important, you will find an  > ever narrowing > potential customer base.  L I honestly blame microshaft for this.  I don't know whether it's their idea,I or they're giving people what they think they want, but it really doesn'tA matter.t  = > Computers used to be handled by scientists. Now, decisions   > are made by bean; > counters who don't know how to quantify the advantage of   > SYSMAN to manage> > multiple machines. But they do know the advantage of coming  > under budget for? > the hardware/software acquisition bu going Wintel, and don't   > care so much= > about a project taking much longer because that is a human i > resources issue, > not a purchasing issue.h  J Ahh, yes:  "The company's concern is not mine, so long as *I* look good on paper!"i  C At this point, I really should make it clear that I can, in no way,  officially speak for Amdocs.   Regards,   Chrisr    ! Christopher Smith, Perl Developera Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");c 'c   ------------------------------  % Date: Mon, 25 Jun 2001 08:50:02 -0500y+ From: Christopher Smith <csmith@amdocs.com>eY Subject: RE: Reward for the first of the next 50 posts: which company	shouldbuy VMS VMS V L Message-ID: <3B55D7F383B0D31197D9009027541CBF0D9D1FCE@cmiexch1.cmi.itds.com>   > -----Original Message-----2 > From: Christof Brass [mailto:brass@infopuls.com]  A > UNIX vs VMS fight outside this NG. I really feel sad about thate? > people who don't know nothing about VMS are fighting for UNIXs< > .... (you know what I'm asking for to do with these *four*< > letter replacement dots) in this NG. This is an incredible0 > insult of VMS if an OS can be insulted at all.  H Some people -- outside of this newsgroup -- will fight for unix, becauseH it's the best option they know of.  That's the truly sad part... that soI many people are completely unaware that VMS could be a real and permanenti- solution to some of their technical problems.    Regards,   Chrish  ! Christopher Smith, Perl Developerc Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");- '-   ------------------------------  # Date: Mon, 25 Jun 2001 10:50:28 GMT.= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)eS Subject: Re: Reward for the first of the next 50 posts: which company shouldbuy VMS.0 Message-ID: <009FE0CB.9506E52D@SendSpamHere.ORG>  N In article <VA.000003e2.065ba199@sture.ch>, Paul Sture <paul@sture.ch> writes:: >In article <009FDF3E.EA2C4910@SendSpamHere.ORG>, VAXman-  >Brian Schenkenberger wrote: >y >[snip]d >> eE >> I read news with Madgoat NEWSRDR.  It's a textual newsreader and IaE >> find it much easier to read and less problematic than Netscape.  IaF >> suggest you give it a try.  The nicest feature with NEWSRDR is thatG >> I can invoke an editor that I am both comfortable and familiar with -	 >> using.- >-D >Does NEWSRDR provide the ability to work offline, as in downloading1 >a whole newsgroup's unread messages in one shot?e >aD >I am coming from the angle of minimum dialup connection times here.B >Netscape on VMS doesn't cut that, as it will grab the headers butB >wants to be online for the text of each message I choose to read. >rC >Experience tells me it is far cheaper to download the lot and hangy >up as soon as possible.  C That's a question for the NEWSRDR developer.  I have never used anyaC dialup, dump, and hangup software features due to the nature of my  % dedicated connection to the internet.l --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMI            eO city, n., 1. a place where trees are cut down and streets are named after them.a   ------------------------------  , Date: Mon, 25 Jun 2001 15:58:53 +0200 (CEST)- From: Freddy Meerwaldt <frederik@freddym.org>t$ Subject: Shared SCSI-Bus Question(s)K Message-ID: <Pine.LNX.4.21.0106251542200.16133-100000@firewall.freddym.org>s   G'afternoon,  B I have some trouble with an AlphaServer 400 4/233 and a VAXstation 4000/60.B I recently tried to connect both machines using a shared SCSI-Bus.' I do now have a test-config as follows:   E Internal SCSI Bus of VAXstation: Toshiba SCSI CD-ROM (not terminated)u& Internal SCSI Bus of Alpha: Terminated  2 control_scsi_term on the Alpha is set to external.; The Host Adapter ID of the VAXstation is 6, of the Alpha 7.   A The Internal SCSI Bus on the VS4000 (for those who don't know theeG 4000-series of machines) is only _one_ bus, starting from the contollerlC having connectors for internal devices, going to the external port.    So I have the following Scheme:S  B VS4000 --internal--> CD-ROM -->external Connector->Alphaserver 400" Mainboard--internal--> Terminator.  J My problem is, as soon as I boot a 7.3 Stabackit from the VAXstation (with3 the Alpha powered on), I get the following message:f  D %SYSTEM-I-MOUNTVER, SABKUP$DKA400: is offline, Mount verification in	 progress.e  D %SYSTEM-I-MOUNTVER, SABKUP$DKA400: has completed mount verification.  = I get the above messages before and after the device-listing.-5 I can see the device from both the Alpha and the VAX.-  G I assume I keep on having some problems regarding the SCSI-Termination.A= Or (is this possible??) one of the machines doesn't support a  shared-scsi-bus?B Or (is this possible, too??) that one of the machines don't have aC termination on the mainboard (is the VS4000/60 terminated onboard?)i   Many many thanks in advance ande
 Best Regards,: 	Freddy    -- lN Geek Code 3.1: GCS s+: a--- C+++ UBOU+++ P-- E--- W++ N w--- V++ PGP- t? 5? tv  J ==========================================================================D  Frederik Meerwaldt  ICQ: 83045387  Homepage: http://www.freddym.orgC  Bavaria/Germany              OpenVMS and Unix Howtos and much moretI  Solaris, HP/UX, AIX, NetBSD, OpenBSD, IRIX, Tru64, OpenVMS, Ultrix, BeOSi   ------------------------------  % Date: Mon, 25 Jun 2001 12:06:36 -0400l2 From: rdeininger@mindspring.com (Robert Deininger)( Subject: Re: Shared SCSI-Bus Question(s)L Message-ID: <rdeininger-2506011206360001@user-2ivebei.dialup.mindspring.com>  
 In articleG <Pine.LNX.4.21.0106251542200.16133-100000@firewall.freddym.org>, Freddyn' Meerwaldt <frederik@freddym.org> wrote:o   > G'afternoon, > D > I have some trouble with an AlphaServer 400 4/233 and a VAXstation
 > 4000/60.D > I recently tried to connect both machines using a shared SCSI-Bus.) > I do now have a test-config as follows:   J There's no support in VMS VAX for shared SCSI.  Sorry.  I doubt you'll getC this to work.  VMS probabably has enough diagnostics to recognize a ' problem and refuse the bus altogether. i  H The 4000/60 is proably of an age where the SCSI controller chip(s) don'tJ understand "target" mode, so it won't like receiving commands from anotherF bus master.  That could likely be patched up in software, but I'm sure" it's not done in standard VAX VMS.  I Even on alpha, only a subset of host-based and add-on controllers supportsJ shared SCSI.  Target mode is a prerequisite, as is some level of standards; compliance to make the port driver work with finite effort.   G You'll have to give each machine its own SCSI bus, and server the disksa across a VMS cluster.i   -- l Robert Deininger rdeininger@mindspring.comd   ------------------------------  % Date: Mon, 25 Jun 2001 17:51:48 +0100c, From: Sherlock Holmes <londonlinks@mail.com> Subject: Sherlock Holmes Museum 5 Message-ID: <E15EZaC-0002BX-00@carbon.btinternet.com>j   <html>   <head>N <title>The Sherlock Holmes Museum - 221b Baker Street, London, England</title>" <script LANGUAGE="JavaScript"><!-- window.open('http://www.london-link.to/images/sherlock.gif','sherlock','height=145,width=115,resizable=no,scrollbars=no,menubar=no,status=no');y //--></script> </head>b   <body bgcolor="#FFFFFF">  W <p align="center"><font size="5" color="#800000"><strong>The Sherlock Holmes Museum<br>e7 221b Baker Street, London, England.</strong></font></p>a  V <p align="center"><font color="#800000" size="4">Please add our link to your web page. Thank you.<br>Y </font><font size="5" color="#800000"><a href="http://www.london-link.to/Sherlock_Holmes"uH target="_blank">http://www.london-link.to/Sherlock_Holmes</a></font></p>  Y <p align="center"><font size="5"><a href="http://www.london-link.to/Sherlock_Holmes"><imgoR src="http://www.london-link.to/images/holmesanimated.gif" width="110" height="136"F alt="&quot;Visit the Sherlock Holmes Museum&quot;" border="0"></a></p> </font>  </body>d </html>m   ------------------------------  % Date: Mon, 25 Jun 2001 18:53:41 +0100s/ From: Sherlock Holmes <londonlinks@address.com>a Subject: Sherlock Holmes Museumd, Message-ID: <E15EaY5-00028W-00@protactinium>   <html>   <head>N <title>The Sherlock Holmes Museum - 221b Baker Street, London, England</title>" <script LANGUAGE="JavaScript"><!-- window.open('http://www.london-link.to/images/sherlock.gif','sherlock','height=145,width=115,resizable=no,scrollbars=no,menubar=no,status=no');, //--></script> </head>    <body bgcolor="#FFFFFF">  W <p align="center"><font size="5" color="#800000"><strong>The Sherlock Holmes Museum<br>i7 221b Baker Street, London, England.</strong></font></p>-  V <p align="center"><font color="#800000" size="4">Please add our link to your web page. Thank you.<br>Y </font><font size="5" color="#800000"><a href="http://www.london-link.to/Sherlock_Holmes" H target="_blank">http://www.london-link.to/Sherlock_Holmes</a></font></p>  Y <p align="center"><font size="5"><a href="http://www.london-link.to/Sherlock_Holmes"><imgjR src="http://www.london-link.to/images/holmesanimated.gif" width="110" height="136"F alt="&quot;Visit the Sherlock Holmes Museum&quot;" border="0"></a></p> </font>e </body>i </html>c   ------------------------------  % Date: Mon, 25 Jun 2001 12:43:23 -0400>- From: "Peter Weaver" <peter.weaver@stelco.ca>t, Subject: Some good news about VMS on Itanium4 Message-ID: <YSJZ6.256278$Z2.2998587@nnrp1.uunet.ca>  & Two good points about the latest news;  F 1. We have something to talk about that does not involve SUV's, Global Waming, Wal-Mart...l  G 2. The reason we were told that we had to use Compaq Analyze instead ofyJ DECEvent was that DECEvent could not handle the newer Alphas. Now that theI Alphas are seeing their EOL perhaps Compaq will give us back DECEvent andi finally kill Compaq Analyze.   :)   ------------------------------  % Date: Mon, 25 Jun 2001 20:43:47 +1000p< From: "Antony Wardle" <antony.wardle@nospam.optusnet.com.au>' Subject: Re: stopping autoboot on 433auiB Message-ID: <3b371564$0$25509$7f31c96c@news01.syd.optusnet.com.au>    Control P is always a good idea.  , I take it the machine also has a halt button on it somewhere ?    antony  ? "Martin Vorlaender" <martin@radiogaga.harz.de> wrote in messaget5 news:3b368267.524144494f47414741@radiogaga.harz.de...h$ > Tom Linden (tom@kednos.com) wrote:A > > Anybody remember how to stop autoboot on PWS 433au and 533au,1 > > I tried F2 F6 F8, ^C ^Z ^D >n > ^P  (IIRC) >r > cu,n
 >   Martin > --F >                        |  Martin Vorlaender  |  VMS & WNT programmer3 >   OpenVMS: When you    |  work: mv@pdv-systeme.denG >   KNOW where you want  |     http://www.pdv-systeme.de/users/martinv/': >   to go today.         |  home: martin@radiogaga.harz.de   ------------------------------  % Date: Mon, 25 Jun 2001 10:03:06 -0700b% From: Dean Woodward <deanw@rdrop.com>h' Subject: Re: stopping autoboot on 433aum) Message-ID: <3B376ECA.D286CD68@rdrop.com>n   Antony Wardle wrote: > " > Control P is always a good idea. > . > I take it the machine also has a halt button > on it somewhere ?i  9 The DPWS series was mistakenly built in the PeeCee image-e it's got a *reset* button.   -- r8 Dean Woodward   |    Real computers have HALT buttons...B deanw@rdrop.com | (Real OS's don't HALT until you tell 'em to. ;-)D ----------------+---------------------------------------------------= '66 Duc 250 - '85 Yam FJ1100 - '00 Kaw KLR650 - '01 Apr Falco    ------------------------------    Date: 25 Jun 2001 07:48:51 -0700 From: rgriffen@my-deja.com (RG)a Subject: Target->Batch= Message-ID: <d03af9e1.0106250648.60de35d7@posting.google.com>m  @ Anyone still using Target->Batch for batch scheduling on a VAX??  D I could really do with getting hold of a manual - we are using V4.3. Can anyone help?  @ Also, has anyone any experience in setting up a new Target-BatchA database concurrent with an existing one? Here's the scenario....c  D We have an existing target-batch set up that is very complicated andD was created by someone who is about to leave the company. We want toD set up a very much simpler schedule, but do not want to create it inF the current target-batch idx files as these are huge and are suspectedB of being corrupt. The idea is to create a new set of IDX files andF with the new schedule and leave the other set up in place until we are> happy to go with the new one. Any help or advice would be much appreciated.   Dick   ------------------------------    Date: 25 Jun 2001 10:16:52 -05009 From: kaplow_r@eisner.encompasserve.org.mars (Bob Kaplow)o1 Subject: Re: The end of Computer Associates ????? 3 Message-ID: <ZjOtLk29m+NW@eisner.encompasserve.org>r  x In article <OFF90740C9.D1703937-ON03256A73.004295D9@ep-bc.petrobras.com.br>, fabio_compaq@ep-bc.petrobras.com.br writes:= > http://news.cnet.com/news/0-1003-200-6347455.html?tag=cd_mhp  > Expired. Try http://news.cnet.com/news/0-1003-202-6340499.html   ------------------------------  % Date: Mon, 25 Jun 2001 12:08:26 +0100O, From: Ted Allwood <support@leva.leeds.ac.uk> Subject: Vax Service Centreb3 Message-ID: <009FE0F8.00AECC1B.15@leva.leeds.ac.uk>   D Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP> writes:   L > Here in the UK, asking to speak to Field Service, instead of whatever theyO > are called these days, is a good way to get a puzzled response from the other  > end of the telephone.a > N > (This is not a CPQ thing, I encountered it while DEC was still DEC, at leastM > at my local office, Leeds, when that was a local office. I don't know abouts > elsewhere in the UK.)o  F It seems that perhaps there is still a Service Centre in Leeds, albeit? in premises on Kirkstall Road that are somewhat down-market 8-)o@ Details at www.mech-eng.leeds.ac.uk/support/images/misc/vax2.jpg   Regards, Ted    -- aK Support@leva.leeds.ac.uk                                Tel:  0113 233 2167d+ www.mech-eng.leeds.ac.uk/support/index.htmlvG School of Mechanical Engineering,  University of Leeds,  Leeds  LS2 9JTk   ------------------------------  % Date: Mon, 25 Jun 2001 12:47:47 -0500l- From: "Richard W. Schauer" <rws@enteract.com>f$ Subject: VAX-11/780 boot disk neededK Message-ID: <Pine.BSF.4.21.0106251242550.73930-100000@shell-2.enteract.com>    Hi-e  J I have a VAX-11/780 in need of the boot disk for the console processor.  IH would like to run the machine, as it's in excellent condition except forG this missing disk.  If anyone has one they no longer need or can spare,uJ please let me know.  Also if this is the sort of thing that still might beI available from Compaq, let me know where to find it because I haven't hade	 any luck.s   Thanks,  Richard Schauert rws@enteract.com   ------------------------------    Date: 25 Jun 2001 03:57:51 -0700  From: alanb@cloud9.net (Alan B.), Subject: VMS 7.3/Alpha boot bugcheck problem< Message-ID: <88599d89.0106250257.70767b1@posting.google.com>  C I upgraded an Alphastation 200 from 7.2-1 to 7.3, and it bugchecked A with a "PROGCONE,  No such process" bug check. The condition code F translates to a "directory not found" error with the LANACP process. IE called CSC and they said they had a report of this problem, but wouldp not give me any futher details.o  % Does anyone know anything about this?n  	  Regards,    Alan Burgs   ------------------------------  % Date: Mon, 25 Jun 2001 09:53:15 -0400s  From: John Santos <JOHN@egh.com>0 Subject: Re: VMS 7.3/Alpha boot bugcheck problem6 Message-ID: <1010625094523.38769B-100000@Ives.egh.com>   On 25 Jun 2001, Alan B. wrote:  E > I upgraded an Alphastation 200 from 7.2-1 to 7.3, and it bugcheckedVC > with a "PROGCONE,  No such process" bug check. The condition code H > translates to a "directory not found" error with the LANACP process. IG > called CSC and they said they had a report of this problem, but would ! > not give me any futher details.e > ' > Does anyone know anything about this?  >  >  Regards,A
 >   Alan Burg   H I have had PROCGONE bugchecks on two separate occasions during VMS boot.D Both times it was due to excessive fragmentation of some file loadedD early in the bootstrap.  Discussed this with DEC/Compaq support, andE they said that the loader would fail if the retrieval pointers didn'tg? fit in the first header block, though in at least one case, thegE problematic file had over 40 retrieval pointers, but only one header.c  . Anyway, defragging the disk fixed the problem.  F (I don't remeber how we identified the problem file.  It may have been1 obvious from the context or from the crash dump.)    -- l John SantosA Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Mon, 25 Jun 2001 11:15:00 -04009> From: "Koska, John C. (LNG-MBC)" <John.C.Koska@lexisnexis.com>0 Subject: RE: VMS 7.3/Alpha boot bugcheck problemM Message-ID: <3D35AD137AAAD411A6BA0008C7B1B12D01602159@MBCALBEXC03.BENDER.COM>R   > -----Original Message-----2 > From: alanb@cloud9.net [mailto:alanb@cloud9.net]% > Sent: Monday, June 25, 2001 6:58 AM0 > To: Info-VAX@Mvb.Saic.Com>. > Subject: VMS 7.3/Alpha boot bugcheck problem > E > I upgraded an Alphastation 200 from 7.2-1 to 7.3, and it bugchecked.C > with a "PROGCONE,  No such process" bug check. The condition code H > translates to a "directory not found" error with the LANACP process. IG > called CSC and they said they had a report of this problem, but wouldb! > not give me any futher details.  > ' > Does anyone know anything about this?  >  >  Regards, 
 >   Alan Burgu >,  ? I have a ticket open with Compaq on this, since about June 8th.p  E In my case, it was a 2100A and it would bugcheck only when the systemaF disk was host-based volume shadowed.  If SHADOW_SYS_DISK is set to 0,  then things are fine.t  I I am sending a full system dump file to Compaq for analysis.  The thoughtrF at this end is that it may be an interaction between the Mylex DAC960 H 3-channel RAID disk controller, and volume shadowing of the system disk.  J Perhaps I should defrag the system disk to see if it resolves the problem H from what I see in post from John Santos at Evans Griffiths & Hart, Inc.K I think I will try before I send the system dump file, and report back here9+ since there is some interest in this topic.:  H All of my other Alpha systems have upgraded flawlessly (AlphaStation 200 4/166, rI and two AlphaServer 4100's) with volume shadowing of system disk and datau disks.   :) jck
 John Koska Matthew Bender & Co., Inc. -"   A Member of the LexisNexis Group
 1275 Broadwayv Albany, NY  12204c USAe 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)." g   ------------------------------  % Date: Mon, 25 Jun 2001 11:47:02 -0400i  From: John Santos <JOHN@egh.com>0 Subject: RE: VMS 7.3/Alpha boot bugcheck problem6 Message-ID: <1010625113824.38769A-100000@Ives.egh.com>  4 On Mon, 25 Jun 2001, Koska, John C. (LNG-MBC) wrote:   > > -----Original Message-----4 > > From: alanb@cloud9.net [mailto:alanb@cloud9.net]' > > Sent: Monday, June 25, 2001 6:58 AMi > > To: Info-VAX@Mvb.Saic.Com 0 > > Subject: VMS 7.3/Alpha boot bugcheck problem > > G > > I upgraded an Alphastation 200 from 7.2-1 to 7.3, and it bugchecked1E > > with a "PROGCONE,  No such process" bug check. The condition codeeJ > > translates to a "directory not found" error with the LANACP process. II > > called CSC and they said they had a report of this problem, but wouldM# > > not give me any futher details.j > > ) > > Does anyone know anything about this?n > > 
 > >  Regards,2 > >   Alan Burgi > >l > A > I have a ticket open with Compaq on this, since about June 8th.e > G > In my case, it was a 2100A and it would bugcheck only when the systemiH > disk was host-based volume shadowed.  If SHADOW_SYS_DISK is set to 0,  > then things are fine.t > K > I am sending a full system dump file to Compaq for analysis.  The thoughttH > at this end is that it may be an interaction between the Mylex DAC960 J > 3-channel RAID disk controller, and volume shadowing of the system disk. > L > Perhaps I should defrag the system disk to see if it resolves the problem J > from what I see in post from John Santos at Evans Griffiths & Hart, Inc.M > I think I will try before I send the system dump file, and report back herea- > since there is some interest in this topic.4  K Hmmm.  I think if you hit the "fragmented file" problem, it wouldn't matter3I at all if the disk was shadowed or not.  So if the problem goes away withoE a non-shadowed system disk, I think you must have hit something else.v  H But if you are just sitting waiting for a response from Compaq, it mightE be worth trying.  Even if it doesn't work, you'll still end up with a D defragged idsk and a backup (assuming you use the backup and restore method to defrag the disk.)n  J > All of my other Alpha systems have upgraded flawlessly (AlphaStation 200	 > 4/166, iK > and two AlphaServer 4100's) with volume shadowing of system disk and datan > disks.  J I've done a MV 3600 and an Alpha 2000 so far, with no problems.  (But also no shadowing.)   > :) jck > John Koska   --   John Santos: Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Mon, 25 Jun 2001 12:08:37 -0400=> From: "Koska, John C. (LNG-MBC)" <John.C.Koska@lexisnexis.com>0 Subject: RE: VMS 7.3/Alpha boot bugcheck problemM Message-ID: <3D35AD137AAAD411A6BA0008C7B1B12D0160215C@MBCALBEXC03.BENDER.COM>l   > -----Original Message-----) > From: John Santos [mailto:JOHN@egh.com]-& > Sent: Monday, June 25, 2001 11:47 AM > To: Info-VAX@Mvb.Saic.Coml2 > Subject: RE: VMS 7.3/Alpha boot bugcheck problem >. > <snip> >. e > > > Hmmm.  I think if you hit the "fragmented file" problem, it  > wouldn't mattern= > at all if the disk was shadowed or not.  So if the problem 1 > goes away withG > a non-shadowed system disk, I think you must have hit something else.n   Agreed.   : > But if you are just sitting waiting for a response from  > Compaq, it mightG > be worth trying.  Even if it doesn't work, you'll still end up with aoF > defragged idsk and a backup (assuming you use the backup and restore > method to defrag the disk.)   C Ending up with a defragged system disk and a backup was my thought oF indeed, since I have not done one yet. (Bad system manager. Bad doggieH  <grin>  )  So as I type, the CD booted system is backing up with verifyJ to tape, and I will turn it around once done.  Then I'll try one last bootE with a shadowed system disk, before I'm off to cut Compaq the system sB dumpfile to tape and snailmail.  Thanks for reminding me to finish/ the upgrade procedure! (backup new system disk)m  G For me, going without volume shadowed system disk on this system is note@ a big deal, since it is hardware mirrored anyway with the Mylex I controller.  But it did initially create some fear of upgrading my other  F systems, since I have other systems where it would be a big deal.  ButH so far (2 systems later) no problems.  A 4100 and GS160 left.  The GS160K looks like it will be a little more interesting from reading release notes.5   :) jck
 John Koska Matthew Bender & Co., Inc. -"   A Member of the LexisNexis Group
 1275 Broadwayk Albany, NY  12204E 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)."   ------------------------------  % Date: Mon, 25 Jun 2001 18:39:34 +0200"> From: "Jean-Francois Marchal" <jean-francois.marchal@x9000.fr>0 Subject: Re: VMS 7.3/Alpha boot bugcheck problem. Message-ID: <9h7pea$hhm$1@reader1.imaginet.fr>  1 woulnt't it be an allocation class = 0 question ?o Jean-Franois Marchal0 X9000 - LYON (FR)/  H "Koska, John C. (LNG-MBC)" <John.C.Koska@lexisnexis.com> a crit dans le
 message news:lB 3D35AD137AAAD411A6BA0008C7B1B12D0160215C@MBCALBEXC03.BENDER.COM... > > -----Original Message-----+ > > From: John Santos [mailto:JOHN@egh.com]i( > > Sent: Monday, June 25, 2001 11:47 AM > > To: Info-VAX@Mvb.Saic.ComS4 > > Subject: RE: VMS 7.3/Alpha boot bugcheck problem > >.
 > > <snip> > >. > >-? > > Hmmm.  I think if you hit the "fragmented file" problem, it0 > > wouldn't matterH> > > at all if the disk was shadowed or not.  So if the problem > > goes away withI > > a non-shadowed system disk, I think you must have hit something else.s >s	 > Agreed.B >r; > > But if you are just sitting waiting for a response fromt > > Compaq, it mightI > > be worth trying.  Even if it doesn't work, you'll still end up with a1H > > defragged idsk and a backup (assuming you use the backup and restore > > method to defrag the disk.)> > D > Ending up with a defragged system disk and a backup was my thoughtH > indeed, since I have not done one yet. (Bad system manager. Bad doggieJ >  <grin>  )  So as I type, the CD booted system is backing up with verifyL > to tape, and I will turn it around once done.  Then I'll try one last bootF > with a shadowed system disk, before I'm off to cut Compaq the systemD > dumpfile to tape and snailmail.  Thanks for reminding me to finish1 > the upgrade procedure! (backup new system disk)h >oI > For me, going without volume shadowed system disk on this system is not A > a big deal, since it is hardware mirrored anyway with the MylexuJ > controller.  But it did initially create some fear of upgrading my otherH > systems, since I have other systems where it would be a big deal.  ButJ > so far (2 systems later) no problems.  A 4100 and GS160 left.  The GS160F > looks like it will be a little more interesting from reading release notes. >h > :) jck > John Koska > Matthew Bender & Co., Inc. -$ >   A Member of the LexisNexis Group > 1275 Broadway  > Albany, NY  12204r > USAt > 518-487-3255 > John.C.Koska@lexisnexis.comE >e, > "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: Mon, 25 Jun 2001 10:46:26 -0400 , From: "Phil Hudson" <phil.hudson@compaq.com>) Subject: Re: VMS applications on the web?o0 Message-ID: <b6IZ6.86$rc5.3911@news.cpqcorp.net>   Ian,K     I don't know if you are aware of it, but there is already a developmenta tool putH     out by the OpenVMS group that solves the problem that you mentioned. It takesF     a slightly different, more robust, approach to solving the problem however.   TheJ     product, Compaq BridgeWorks, allows you to describe your OpenVMS basedI     applications, then automatically wraps them as either Java/EJB or COMI objects.F     Once accessible as either a Java or COM entity, they can be easily
 accessibleI     through a Web Browser/Web Server.   The types of OpenVMS 'items' thatW caneI     be wrapped include: 3GL routines, ACMS Tasks, Batch (DCL) Procedures,. and I     and text files.    Note that it can wrap items on Alpha & VAX OpenVMSa V6.2+.       Oh, by the way, it's free.  9     For more information, please click on the link below:o    K http://www.openvms.compaq.com/commercial/bridgeworks/bridgeworks_index.html:   Thanks,t Phil Hudsony# (Compaq BridgeWorks Engineering PL)a    B "Ian Burgess" <ccburgess@uqstu.jdstory.uq.edu.au> wrote in message( news:9gu58j$obk$1@bunyip.cc.uq.edu.au...E > In a world where web access is becoming dominant, what do you think  > of this as a project? ...d >.? > In the past we have used menu systems based on real terminals-A > or terminal emulators.  This interface is foreign to newcomers, ; > so perhaps it is time to look at a web based alternative.- >-I > This project would provide tools so that an application developer couldm easilyD > make existing VMS applications accessable to users who need only a browser. >.A > The user needs to be authenticated, then selects an applicationn > from a menu. >o; > For an application run in batch the user would use a form./ >  [input data file] - browse locally to uploadr( >  [email] - for log file or output file3 >  [parameters] - and maybe other Submit qualifierse >i >  [submit] button >i@ > The submit would use some of the capabilities of DEC SchedulerA > to wrap the command procedure to be processed and deal with thea > log file.m >r > Would it be useful?a > Would it be feasible?u >nA > This is an embryo only.  I wonder if it could be developed intoi4 > something that would give VMS a new lease of life? >aF > It is way beyond my resources, but I hope someone somewhere may find > the idea useful.
 > Ian Burgessn > University of Queensland! > I.Burgess @ its . uq . edu . au- > www.its.uq.edu.au-   ------------------------------  # Date: Mon, 25 Jun 2001 08:24:57 GMT.+ From: "Darren Peacock" <daz005@hotmail.com>o$ Subject: Re: VMS on IA64 (technical)@ Message-ID: <tzCZ6.157976$ff.1218065@news-server.bigpond.net.au>  % High Performance Application Sites...e  E Most of the Stock Exchnages around the world as a starter some of thewI Largest Phone companies, Billing systems. Shesh but we dont need facts toe- get in the road of this one. Banks, Smelting.-  E Benchmarks posted in this Newsgroup by Sunshines. I pulled one of themD Benchmark to pieces, and flat out not correct and was simply posted.  K On the Linux front sure , add 2000 transaction from 50 users across Apache,cK and the Linux box fails, it in fact stops. Its all about Load, the more yout load the stability shines thru.    Cheers   Darren Peacock        5 "T. S. Murphy" <murphyts@swbell.net> wrote in message * news:IAfZ6.207$E97.208161@nnrp2.sbc.net...A > "Robert Deininger" <rdeininger@mindspring.com> wrote in messagelH > news:rdeininger-2306012213110001@user-2ive69s.dialup.mindspring.com... > K > > I disagree.  Many VMS applications ARE performance-critical.  And VAXesr/ > > don't run a very big percentage these days.s >lH > I'm almost certain that a majority of VMS systems in service are still	 > VAX'es./ >gK > Seriously, what high performance applications are running on VMS? For the D > relatively small market which Alpha does have for high performance< > computing, most of the systems are running Linux or Tru64. > G > > Though I might agree if you said VMS performance concerns are often,J > > system-wide, not simple CPU power.  Emulators generally give lousy CPUI > > performance, but you might arrange to keep most of the underlying I/O4J > > performance.  Except the traditional Intel-based system doesn't handle I/Of% > > terribly well in the first place.r >IJ > Of course, from benchmarks posted on this newsgroup in the past, we knowJ > that a Celeron running Linux outperforms VMS/Alpha on disk I/O by one or twolL > orders of magnitude. A Pentium 4 system has a much better memory subsystem= > than any Alpha, and the same I/O system as any Alpha (PCI).e >nE > > I think JF was talking about _software_ reliability.  Alpha + VMS- PALcode-L > > contain some features that make VMS much easier to write.  Specifically,K > > the VMS code base from VAX was easier to port because of these features2 inL > > alpha. Many software wheels did NOT have to be re-invented, implemented,K > > and debugged.  The result was VMS on alpha sooner and better than wouldi! > > otherwise have been the case.o >nK > While true, it is not clear than PALcode offers an advantage which cannot  beJ > leveraged on a generic architecture with a software layer between the OS and  > the processor. >h >n >    ------------------------------  # Date: Mon, 25 Jun 2001 08:46:43 GMT2+ From: "Darren Peacock" <daz005@hotmail.com> $ Subject: Re: VMS on IA64 (technical)@ Message-ID: <TTCZ6.158025$ff.1218247@news-server.bigpond.net.au>  & I am almost certain , you have no idea  8 With VMS on IA64 it allows a new platform to run vms on.  G   I for one welcome a new platform which will be lower cost, and if theeL number of IA32 out there. Compaq has the opportunity to place Tru 64 and VMS/ on those platforms. Great stuff which ever way.     5 "T. S. Murphy" <murphyts@swbell.net> wrote in messageh* news:IAfZ6.207$E97.208161@nnrp2.sbc.net...A > "Robert Deininger" <rdeininger@mindspring.com> wrote in messageGH > news:rdeininger-2306012213110001@user-2ive69s.dialup.mindspring.com... >uK > > I disagree.  Many VMS applications ARE performance-critical.  And VAXess/ > > don't run a very big percentage these days.i >hH > I'm almost certain that a majority of VMS systems in service are still	 > VAX'es.l >,K > Seriously, what high performance applications are running on VMS? For theiD > relatively small market which Alpha does have for high performance< > computing, most of the systems are running Linux or Tru64. > G > > Though I might agree if you said VMS performance concerns are often-J > > system-wide, not simple CPU power.  Emulators generally give lousy CPUI > > performance, but you might arrange to keep most of the underlying I/O J > > performance.  Except the traditional Intel-based system doesn't handle I/Op% > > terribly well in the first place.3 >AJ > Of course, from benchmarks posted on this newsgroup in the past, we knowJ > that a Celeron running Linux outperforms VMS/Alpha on disk I/O by one or twodL > orders of magnitude. A Pentium 4 system has a much better memory subsystem= > than any Alpha, and the same I/O system as any Alpha (PCI).0 >oE > > I think JF was talking about _software_ reliability.  Alpha + VMSs PALcodecL > > contain some features that make VMS much easier to write.  Specifically,K > > the VMS code base from VAX was easier to port because of these featuresl inL > > alpha. Many software wheels did NOT have to be re-invented, implemented,K > > and debugged.  The result was VMS on alpha sooner and better than wouldw! > > otherwise have been the case.e >hK > While true, it is not clear than PALcode offers an advantage which cannot  beJ > leveraged on a generic architecture with a software layer between the OS andr > the processor. >i >a >l   ------------------------------  % Date: Mon, 25 Jun 2001 09:54:21 -0400a2 From: rdeininger@mindspring.com (Robert Deininger)$ Subject: Re: VMS on IA64 (technical)L Message-ID: <rdeininger-2506010954220001@user-2ivebei.dialup.mindspring.com>  < In article <yIwZ6.159$0G.8079@nnrp1.sbc.net>, "T. S. Murphy" <murphts@swbell.net> wrote:i  L > The aformentioned GCHE does 6.4 GB/s for memory bandwidth (23% faster thanN > the DS20E) , 5 GB/s I/O bandwidth (over 800% faster than the DS20E), and hasL > six PCI-X buses (+1 legacy PCI bus), versus 2 on the DS20E - and these are: > PCI-X, not the legacy PCI buses that the DS20E supports.  E NIce comparison of a "forthcoming" system to a nearly 2 year old one.b   -- h Robert Deininger rdeininger@mindspring.comY   ------------------------------   Date: 25 Jun 2001 14:54:09 GMT* From: bdwheele@indiana.edu (Brian Wheeler)$ Subject: Re: VMS on IA64 (technical)2 Message-ID: <9h7jah$k11$1@jetsam.uits.indiana.edu>  0 In article <oKfZ6.208$E97.211776@nnrp2.sbc.net>,- 	"T. S. Murphy" <murphyts@swbell.net> writes:77 > "Stanley F. Quayle" <stan@stanq.com> wrote in message:) > news:3B3520A3.5539.2CBFC7F@localhost...g > A >> By the way, Alpha emulators do exist for Intel platforms.  But,E >> there's not a lot of incentive to do that, since you can still get * >> Alphas.  That's not the case for VAXen. > J > Is there seriously an Alpha emulator for Intel (x86?) platforms? A quick" > Google search turned up nothing. > M > There is definitely an incentive for that from the point of view of cost. IgN > bet a good Alpha emulator (i.e. doing dynamic code translation) running on aM > Pentium 4 would be fast - at least, much faster than an equivalently priced M > Alpha system. Since the I/O system of a PC and an Alpha system are so closeoK > (both have PCI), it would make much more sense to emulate an Alpha than asF > VAX (whose I/O system is entirely alien to the PC's). Though from anH > architecture point of view, emulating a RISC instruction set on a CISCD > computer poses some interesting challenges as far as optimization. >  >   N I've thought about writing one, but never had the time to tinker with it.  TheI PCI mapping does help quite a bit, and since the instructions are 32-bits O they'll fit nicely in an x86 register....its just those darned 64-bit things :)n   Brian    ------------------------------   Date: 25 Jun 2001 16:04:16 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)s$ Subject: Re: VMS on IA64 (technical), Message-ID: <9h7ne0$2nug$2@info.cs.uofs.edu>  , In article <3B362F8B.D2870AE6@videotron.ca>,0  JF Mezei <jfmezei.spamnot@videotron.ca> writes: |> Phil Howell wrote:t# |> > I almost certain you are wrong O |> > The price of maintenance on VAXen made is cost effective to move to alphass |> > many years ago  |> eM |> But the low cost of second hand VAXes has made is cheaper t just buy spare 1 |> machines and not pay for hardware maintenance.t  B Not to mention the general robustness of the machines.  Like their< predecesor, "they take a lickin' and keep on tickin'"!!  :-)   bill   -- mJ 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>   .   ------------------------------  % Date: Mon, 25 Jun 2001 16:59:25 +0100l- From: Tim Llewellyn <tim.llewellyn@bbc.co.uk> $ Subject: Re: VMS on IA64 (technical)) Message-ID: <3B375FDD.9A0ABA6C@bbc.co.uk>-   Phil Howell wrote:  7 > "T. S. Murphy" <murphyts@swbell.net> wrote in messageo, > news:IAfZ6.207$E97.208161@nnrp2.sbc.net...C > > "Robert Deininger" <rdeininger@mindspring.com> wrote in messageAJ > > news:rdeininger-2306012213110001@user-2ive69s.dialup.mindspring.com... > >eM > > > I disagree.  Many VMS applications ARE performance-critical.  And VAXes,1 > > > don't run a very big percentage these days.j > >RJ > > I'm almost certain that a majority of VMS systems in service are still > > VAX'es.i > >   > I almost certain you are wrongL > The price of maintenance on VAXen made is cost effective to move to alphas > many years ago  I assuming you have management who actually give a damn  and care to manage 
 change rather M than do nothing. Certainly not the case in many VMS installations that are in  stable state* or run-down-before-migrating-off-vms mode.  N Eg annual maint on VAX 4000-100 systems will cost more than a new DS10 server, but M mgmt refused to consider upgrade due to impleding SAP installation. Guess whoc is involvedoL with the new app? Starts with E, ends in S. They could just give me a budget and I'd have> pocketed the spare cash :-). Oh well, if life was that easy...   >, > Phil > <rest snipped>   --6 Tim Llewellyn, OpenVMS Infrastructure, Remarcs Project0 MedAS at the BBC, Whiteladies Road, Bristol, UK.A Email tim.llewellyn@bbc.co.uk. Home tim.llewellyn@cableinet.co.ukh  A I speak for myself only and my views in no way represent those ofi MedAS or the BBC.e   ------------------------------  % Date: Mon, 25 Jun 2001 17:04:21 +0100o- From: Tim Llewellyn <tim.llewellyn@bbc.co.uk> $ Subject: Re: VMS on IA64 (technical)) Message-ID: <3B376105.8E8B3610@bbc.co.uk>e   JF Mezei wrote:w   > "T. S. Murphy" wrote:oJ > > I'm almost certain that a majority of VMS systems in service are still > > VAX'es.l > K > But now that VAXes are no longer sold, I suspect that VAX usres will have L > migrate. And with Alpha effectively dead if we are to beleive the rumours,  H Compaq are marketting refurbed VAXes in the UK for people who need them,9 so they are no longer making VAXen but they do sell them.    > O > those VAX users won't have much VMS to migrate to in the next couple of yearse! > until VMS on IA64 is available.-  K yup, this sounds like VERY bad news for Tru64 and VMS, just when we thoughtr things were turning round.  8 Winkler's newfound religion was obviously IA64 no Alpha.   >o >mN > Would you migrate from vax to Alpha today, knowing that Alpha is going to be9 > phased out and you'll have to migrate to IA64 shortly ?N >R  I Nah, well only if my life or money depended on it and there were no othere as reliable options5   >A5 > The timing to kill Alpha is very bad in my opinion..  K I cannot believe it is really a mistake. Compaq is now ready to rip out the D the heart of the company formerly known as Digital, and spin off allO innovation to others. I guess they feel they can write-off wildfire development  somewhere in the deal,  8 Mike Winkler, I wanna metaphorically poke your eyes out.   --6 Tim Llewellyn, OpenVMS Infrastructure, Remarcs Project0 MedAS at the BBC, Whiteladies Road, Bristol, UK.A Email tim.llewellyn@bbc.co.uk. Home tim.llewellyn@cableinet.co.uke  A I speak for myself only and my views in no way represent those oft MedAS or the BBC.g   ------------------------------  % Date: Mon, 25 Jun 2001 12:23:09 -0400  From: William_Bochnik@acml.com$ Subject: Re: VMS on IA64 (technical)> Message-ID: <OF62201F73.E9628A98-ON85256A76.0059EC83@acml.com>  = Tim, or anyone else out there, care to list what Compaq "got"c@ when they bough Digital, and out of those products/services list" what's left?  I bet it's not much.   :-(  sad state of affairsi      c                                                                                                    dc                     Tim Llewellyn                                                                   c                     <tim.llewellyn@                To:  Info-VAX@Mvb.Saic.Com                      sc                     bbc.co.uk>                     cc:                                             hc                                            Subject:     Re: VMS on IA64 (technical)                ec                     06/25/2001                                                                     4c                     12:04 PM                                                                       ec                                                                                                    Gc                                                                                                                JF Mezei wrote:i   > "T. S. Murphy" wrote:c@ > > I'm almost certain that a majority of VMS systems in service	 are stilln > > VAX'es.  >nA > But now that VAXes are no longer sold, I suspect that VAX usres 	 will have,? > migrate. And with Alpha effectively dead if we are to beleivem the rumours,  = Compaq are marketting refurbed VAXes in the UK for people who.
 need them,9 so they are no longer making VAXen but they do sell them.,   >t? > those VAX users won't have much VMS to migrate to in the nextg couple of yearst! > until VMS on IA64 is available.t  @ yup, this sounds like VERY bad news for Tru64 and VMS, just when
 we thought things were turning round.  8 Winkler's newfound religion was obviously IA64 no Alpha.   >  >l? > Would you migrate from vax to Alpha today, knowing that AlphaI is going to be9 > phased out and you'll have to migrate to IA64 shortly ?  >i  @ Nah, well only if my life or money depended on it and there were no other as reliable options    >w5 > The timing to kill Alpha is very bad in my opinion.r  ? I cannot believe it is really a mistake. Compaq is now ready tos rip out theA@ the heart of the company formerly known as Digital, and spin off allf: innovation to others. I guess they feel they can write-off wildfire development somewhere in the deal,  8 Mike Winkler, I wanna metaphorically poke your eyes out.   --6 Tim Llewellyn, OpenVMS Infrastructure, Remarcs Project0 MedAS at the BBC, Whiteladies Road, Bristol, UK.A Email tim.llewellyn@bbc.co.uk. Home tim.llewellyn@cableinet.co.uk   A I speak for myself only and my views in no way represent those oft MedAS or the BBC.d            F ______________________________________________________________________  : The information contained in this transmission may contain< privileged and confidential information and is intended only< for the use of the person(s) named above. If you are not the< intended recipient,  or an employee or agent responsible for? delivering this message to the intended recipient,  any review,p@ dissemination, distribution or duplication of this communication> is strictly prohibited. If you are not the intended recipient,A please contact the sender immediately by reply e-mail and destroye# all copies of the original message.r   ------------------------------  % Date: Mon, 25 Jun 2001 17:30:33 +0100t  From: steven.reece@quintiles.com$ Subject: Re: VMS on IA64 (technical)H Message-ID: <OFCB3CFC95.79046B7E-ON80256A76.005A3DF2@qedi.quintiles.com>  C I would imagine that, excluding Services and Products, Compaq got :l   A huge property portfolio;I Financial resources of Digital (including their various leasing companiest' that were, I believe, in-house funded);  People;u* What would otherwise be known as Goodwill;- Access to the Digital databases of customers;t Installed base of customers; Usergroup (DECUS/Encompass/CUO)   J At least some of the property portfolio is still there, as are some of the people.o Steve.   William Bochnik asked: >>>1= Tim, or anyone else out there, care to list what Compaq "got"e@ when they bough Digital, and out of those products/services list" what's left?  I bet it's not much.   :-(  sad state of affairss <<<s   ------------------------------  % Date: Mon, 25 Jun 2001 15:01:39 +0200l From: "B.Eckstein" <be@cli.de>. Subject: What does Alphas dead means for VMS ?# Message-ID: <3B373633.80009@cli.de>o  > "Compaq also said it will consolidate its entire 64-bit family4 of servers on the Itanium processor family by 2004."  9 http://www.compaq.com/newsroom/presspaq/062501/index.htmlm  9 As there is no VMS an IA64 it it dead by 2004, isn't it ?n   ------------------------------    Date: 25 Jun 2001 09:24:09 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)e2 Subject: Re: What does Alphas dead means for VMS ?3 Message-ID: <W8$C63pUlqzJ@eisner.encompasserve.org>i  D In article <3B373633.80009@cli.de>, "B.Eckstein" <be@cli.de> writes:@ > "Compaq also said it will consolidate its entire 64-bit family6 > of servers on the Itanium processor family by 2004." > ; > http://www.compaq.com/newsroom/presspaq/062501/index.htmll > ; > As there is no VMS an IA64 it it dead by 2004, isn't it ?   ) Not if one believes the press release at:h  9 	http://www.compaq.com/newsroom/pr/2001/pr2001062501.htmle  M "Compaq will immediately begin to port Tru64 UNIX, OpenVMS and NonStop KerneleJ  operating systems and development tools to the Itanium processor family."   ------------------------------  % Date: Mon, 25 Jun 2001 15:40:47 +0200f5 From: Martin Knoblauch <Martin.Knoblauch@TeraPort.de>i2 Subject: Re: What does Alphas dead means for VMS ?+ Message-ID: <3B373F5F.5017EC54@TeraPort.de>c   Larry Kilgallen wrote: > F > In article <3B373633.80009@cli.de>, "B.Eckstein" <be@cli.de> writes:B > > "Compaq also said it will consolidate its entire 64-bit family8 > > of servers on the Itanium processor family by 2004." > >h= > > http://www.compaq.com/newsroom/presspaq/062501/index.html  > > = > > As there is no VMS an IA64 it it dead by 2004, isn't it ?- > + > Not if one believes the press release at:M > B >         http://www.compaq.com/newsroom/pr/2001/pr2001062501.html > O > "Compaq will immediately begin to port Tru64 UNIX, OpenVMS and NonStop Kernel L >  operating systems and development tools to the Itanium processor family."  ?  but who is going to port the applications? Actually, from thathH perspective Tru64 maybe the worst off. Why should one port to IA64/Tru64B if you can have already ported Unices from HP, IBM and then Linux?  E  NSK is probably the safest, as there maybe some stuff that is really-> unique, provided that there will be hardware to use/expose it.  G  VMS is somehow in the middle. What does VMS offer to applications thateF you couldn't find in either the variety of Unices, or NSK if it has to be really highly available.o  3  In any case, application availability will decide.f   Martin -- oB ------------------------------------------------------------------B Martin Knoblauch         |    email:  Martin.Knoblauch@TeraPort.de7 TeraPort GmbH            |    Phone:  +49-89-510857-309c7 C+ITS                    |    Fax:    +49-89-510857-111o5 http://www.teraport.de   |    Mobile: +49-170-4904759.   ------------------------------  # Date: Mon, 25 Jun 2001 14:33:46 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)2 Subject: Re: What does Alphas dead means for VMS ?0 Message-ID: <eZHZ6.83$rc5.3791@news.cpqcorp.net>  D In article <3B373633.80009@cli.de>, "B.Eckstein" <be@cli.de> writes:? :"Compaq also said it will consolidate its entire 64-bit familyl5 :of servers on the Itanium processor family by 2004."r :u: :http://www.compaq.com/newsroom/presspaq/062501/index.html :o: :As there is no VMS an IA64 it it dead by 2004, isn't it ?  <   "The new Compaq Itanium servers will support ... OpenVMS."  D   OpenVMS is porting to IA64.  (And now off to reword my FAQ VMS11.)  PC   Please visit the OpenVMS website: http://www.openvms.compaq.com/ uD   (as I expect more links will be going up there), and particularly     visit the following web pages:  :     http://www.compaq.com/hps/ipf-enterprise/overview.html9     http://www.compaq.com/hps/ipf-enterprise/openvms.htmls  =   At least some of y'all wanted OpenVMS on Intel, and well...f  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: 25 Jun 2001 14:37:14 GMT1 From: JONESD@er6.eng.ohio-state.edu (David Jones)h2 Subject: Re: What does Alphas dead means for VMS ?: Message-ID: <9h7iaq$qrl$1@charm.magnus.acs.ohio-state.edu>  D In article <3B373633.80009@cli.de>, "B.Eckstein" <be@cli.de> writes:@ > "Compaq also said it will consolidate its entire 64-bit family6 > of servers on the Itanium processor family by 2004." >i; > http://www.compaq.com/newsroom/presspaq/062501/index.htmli >a< >> As there is no VMS an IA64 it it dead by 2004, isn't it ? >0* >Not if one believes the press release at: > : >	http://www.compaq.com/newsroom/pr/2001/pr2001062501.html >gN >"Compaq will immediately begin to port Tru64 UNIX, OpenVMS and NonStop KernelK > operating systems and development tools to the Itanium processor family."w  C Mostly, I believe the disclaimer in the 'notes' section at the end:2  I "These statements are not historical facts and are subject to factors andeM uncertainties that could cause actual results to differ materially from those-- described in the forward-looking statements."e        < David L. Jones               |      Phone:    (614) 292-6929- Ohio State University        |      Internet:DL 140 W. 19th St. Rm. 231a     |               jonesd@er6s1.eng.ohio-state.edu: Columbus, OH 43210           |               vman+@osu.edu  + Disclaimer: Dogs can't tell it's not bacon.)   ------------------------------  % Date: Mon, 25 Jun 2001 08:56:07 -060004 From: "Michael D. Ober" <mdo.@.wakeassoc.com.nospam>2 Subject: Re: What does Alphas dead means for VMS ?1 Message-ID: <9iIZ6.705$Ln6.91190@news.uswest.net>2  G I suspect it means that CPQ is getting out of the HW design/fabrication D business.  Intel has been looking for a partner to help break the M$H monopoly on their processors, and VMS may be just what Intel needs to doG this.  Don't forget that the Itanium will probably be around for only aoF couple of years - it's replacement is close to pre-fab - and that it'sH successor may have the additional instructions needed to make a VMS port	 feasible.y   --
 Mike Ober.  > "David Jones" <JONESD@er6.eng.ohio-state.edu> wrote in message4 news:9h7iaq$qrl$1@charm.magnus.acs.ohio-state.edu...F > In article <3B373633.80009@cli.de>, "B.Eckstein" <be@cli.de> writes:B > > "Compaq also said it will consolidate its entire 64-bit family8 > > of servers on the Itanium processor family by 2004." > >o= > > http://www.compaq.com/newsroom/presspaq/062501/index.htmln > >o> > >> As there is no VMS an IA64 it it dead by 2004, isn't it ? > >m, > >Not if one believes the press release at: > > < > > http://www.compaq.com/newsroom/pr/2001/pr2001062501.html > >lI > >"Compaq will immediately begin to port Tru64 UNIX, OpenVMS and NonStopi KernelD > > operating systems and development tools to the Itanium processor family." >-E > Mostly, I believe the disclaimer in the 'notes' section at the end:u >.K > "These statements are not historical facts and are subject to factors and7I > uncertainties that could cause actual results to differ materially from, thosee/ > described in the forward-looking statements."i >o >l >o >t> > David L. Jones               |      Phone:    (614) 292-6929/ > Ohio State University        |      Internet:a  > 140 W. 19th St. Rm. 231a     | jonesd@er6s1.eng.ohio-state.edua< > Columbus, OH 43210           |               vman+@osu.edu >o- > Disclaimer: Dogs can't tell it's not bacon.i   ------------------------------  % Date: Mon, 25 Jun 2001 11:24:24 -0400a+ From: John Eisenschmidt <jeisensc@aaas.org>i2 Subject: Re: What does Alphas dead means for VMS ?# Message-ID: <sb371f7a.046@aaas.org>i  I Do I think it's a good idea for OpenVMS to run on commodity hardware? Yesy  D Do I think it's a good idea for the robber-barrons of out-of-order =K execution to control and bury possibly the greatest microprocessor design =9 in human history? No.l  I >>> Hoff Hoffman <hoffman@xdelta.zko.dec.nospam> 06/25/2001 10:33:46 AM =s >>>DD In article <3B373633.80009@cli.de>, "B.Eckstein" <be@cli.de> writes:? :"Compaq also said it will consolidate its entire 64-bit family75 :of servers on the Itanium processor family by 2004."i :r= :http://www.compaq.com/newsroom/presspaq/062501/index.html=202 :1: :As there is no VMS an IA64 it it dead by 2004, isn't it ?  <   "The new Compaq Itanium servers will support ... OpenVMS."  D   OpenVMS is porting to IA64.  (And now off to reword my FAQ VMS11.) =20tE   Please visit the OpenVMS website: http://www.openvms.compaq.com/=20sF   (as I expect more links will be going up there), and particularly=20    visit the following web pages:  =     http://www.compaq.com/hps/ipf-enterprise/overview.html=20w<     http://www.compaq.com/hps/ipf-enterprise/openvms.html=20  =   At least some of y'all wanted OpenVMS on Intel, and well...   L  ---------------------------- #include <rtfaq.h> --------------------------= ---aL       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com =   =20dL  --------------------------- pure personal opinion ------------------------= ---iL    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.co= m'   ------------------------------  % Date: Mon, 25 Jun 2001 11:43:53 -0400,2 From: rdeininger@mindspring.com (Robert Deininger)2 Subject: Re: What does Alphas dead means for VMS ?L Message-ID: <rdeininger-2506011143530001@user-2ivebei.dialup.mindspring.com>  0 In article <eZHZ6.83$rc5.3791@news.cpqcorp.net>,$ hoffman@xdelta.zko.dec.nospam wrote:  F > In article <3B373633.80009@cli.de>, "B.Eckstein" <be@cli.de> writes:A > :"Compaq also said it will consolidate its entire 64-bit familyc7 > :of servers on the Itanium processor family by 2004."  > :6< > :http://www.compaq.com/newsroom/presspaq/062501/index.html > :o< > :As there is no VMS an IA64 it it dead by 2004, isn't it ? > > >   "The new Compaq Itanium servers will support ... OpenVMS." > F >   OpenVMS is porting to IA64.  (And now off to reword my FAQ VMS11.) >  vE >   Please visit the OpenVMS website: http://www.openvms.compaq.com/ uF >   (as I expect more links will be going up there), and particularly " >   visit the following web pages: > < >     http://www.compaq.com/hps/ipf-enterprise/overview.html; >     http://www.compaq.com/hps/ipf-enterprise/openvms.htmlu > ? >   At least some of y'all wanted OpenVMS on Intel, and well...u  ( Hoff, I suspect you can't answer this...  G Did anyone in Compaq management ask you folks about the time and effortr4 required to port VMS, before they made this decsion?   -- e Robert Deininger rdeininger@mindspring.comI   ------------------------------  % Date: Mon, 25 Jun 2001 11:46:29 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)2 Subject: Re: What does Alphas dead means for VMS ?L Message-ID: <rdeininger-2506011146300001@user-2ivebei.dialup.mindspring.com>  C In article <9iIZ6.705$Ln6.91190@news.uswest.net>, "Michael D. Ober"l# <mdo.@.wakeassoc.com.nospam> wrote:f  I > I suspect it means that CPQ is getting out of the HW design/fabricationWF > business.  Intel has been looking for a partner to help break the M$J > monopoly on their processors, and VMS may be just what Intel needs to doI > this.  Don't forget that the Itanium will probably be around for only a.H > couple of years - it's replacement is close to pre-fab - and that it'sJ > successor may have the additional instructions needed to make a VMS port > feasible.0  J If the Itanium' successor is to support VMS in a nice way, it will have toI be significantly delayed.  I can't see Intel doing that, since Itanium is H something of a dog and the next chip is the promised dragon-slayer.  ButH we are talking about significant design changes, I think.  It's too late in the process.s  6 So it will have to wait for the successor's successor.   --   Robert Deininger rdeininger@mindspring.com    ------------------------------   Date: 25 Jun 01 10:08:23 MDT" From: ivie@cc.usu.edu (Roger Ivie)2 Subject: Re: What does Alphas dead means for VMS ?% Message-ID: <K2SoHQ$y4fjg@cc.usu.edu>.  e In article <eZHZ6.83$rc5.3791@news.cpqcorp.net>, hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes: ? >   At least some of y'all wanted OpenVMS on Intel, and well...   ) A case of "be careful what you wish for"?   D I'll have to give this one a wait and see before I start complainingE too much. I was skeptical about the transition to Alpha until I had aME chance to work with Alpha/VMS; I was using VAX/VMS 3 fiche when I hadeD a question about what the kernel was doing and it was still accurateG enough to be helpful. Most of my device drivers moved from VAX to Alpha E with minor changes despite their being of the "bonk VMS over the head E and steal its wallet" variety. The support for device drivers in C isaF so good that it's been several years since I even _considered_ doing aG device driver in Macro32; moving those drivers to Itanium/VMS should bevH easier than moving the Macro32 ones to Alpha (except, of course, for theJ ones which rely on intimate knowledge of the PCI bridge chipset to provideH a FORTRAN-mappable array to get to I/O, but those ones are a pain in the5 butt whenever the PCI bridge chipset changes anyway).  -- eN -------------------------+----------------------------------------------------3 Roger Ivie               | Ben Stein for president!t ivie@cc.usu.edu          | http://cc.usu.edu/~ivie/ | -----BEGIN GEEK CODE BLOCK-----l 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+++   ------END GEEK CODE BLOCK------n   ------------------------------  % Date: Mon, 25 Jun 2001 10:35:55 -0600h4 From: "Michael D. Ober" <mdo.@.wakeassoc.com.nospam>2 Subject: Re: What does Alphas dead means for VMS ?1 Message-ID: <IMJZ6.52$AE2.241622@news.uswest.net>y  I I suspect you're right about this, unless Intel and Compaq engineers have L been working together for some time now.  I remember the Alpha had to have aD handful of instructions added to the original design to support VMS;J hopefully this won't be true with regards to the IA64 instructions, or VMS# will be in for a really rough port.w --
 Mike Ober.  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in message F news:rdeininger-2506011146300001@user-2ivebei.dialup.mindspring.com...E > In article <9iIZ6.705$Ln6.91190@news.uswest.net>, "Michael D. Ober" % > <mdo.@.wakeassoc.com.nospam> wrote:n >sK > > I suspect it means that CPQ is getting out of the HW design/fabricationyH > > business.  Intel has been looking for a partner to help break the M$L > > monopoly on their processors, and VMS may be just what Intel needs to doK > > this.  Don't forget that the Itanium will probably be around for only aaJ > > couple of years - it's replacement is close to pre-fab - and that it'sL > > successor may have the additional instructions needed to make a VMS port
 > > feasible.s > L > If the Itanium' successor is to support VMS in a nice way, it will have toK > be significantly delayed.  I can't see Intel doing that, since Itanium isAJ > something of a dog and the next chip is the promised dragon-slayer.  ButJ > we are talking about significant design changes, I think.  It's too late > in the process.p >e8 > So it will have to wait for the successor's successor. >i > -- > Robert Deininger > rdeininger@mindspring.comh   ------------------------------    Date: 25 Jun 2001 10:14:55 -0500- From: koehler@encompasserve.org (Bob Koehler)   Subject: Re: [OT] Climate change3 Message-ID: <MQZ0pnTf1G8O@eisner.encompasserve.org>p   In article <rdeininger-2106011851400001@user-2iveav3.dialup.mindspring.com>, rdeininger@mindspring.com (Robert Deininger) writes:,5 > In article <VoNf2ph$oaYt@eisner.encompasserve.org>,a0 > koehler@encompasserve.org (Bob Koehler) wrote: > K >> 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. > L > There are fission reactor designs that have the same feature.  If they getJ > 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 oniE itself and can simply run aways when something goes wrong (safety and5J backup systems can fail), whereas in fusion the basic process is severaly 9 unstable so when anything goes wrong it just plain stops.p  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporationl= NASA GSFC Flight Software       | Federal Sector, Civil GroupcE                                 | please remove ".aspm" when replying6   ------------------------------  % Date: Mon, 25 Jun 2001 10:54:07 -0400t2 From: rdeininger@mindspring.com (Robert Deininger)  Subject: Re: [OT] Climate changeL Message-ID: <rdeininger-2506011054080001@user-2ivebei.dialup.mindspring.com>  3 In article <MQZ0pnTf1G8O@eisner.encompasserve.org>,d. koehler@encompasserve.org (Bob Koehler) wrote:   > In articleA <rdeininger-2106011851400001@user-2iveav3.dialup.mindspring.com>,r4 rdeininger@mindspring.com (Robert Deininger) writes:7 > > In article <VoNf2ph$oaYt@eisner.encompasserve.org>,g2 > > koehler@encompasserve.org (Bob Koehler) wrote: > > M > >> At least with a fusion reactor (and I look forward to them), if anythingeL > >> goes wrong the whole thing stops faster than you can think about it, no6 > >> Chernobyl style melt downs like fission reactors. > > N > > There are fission reactor designs that have the same feature.  If they getL > > hotter, they get less reactive and tend to slow down.  I don't think any6 > > of these newer designs have been built in the U.S. > G > Design in is nice, but in fission the basic process tends to build on G > itself and can simply run aways when something goes wrong (safety andvL > backup systems can fail), whereas in fusion the basic process is severaly ; > unstable so when anything goes wrong it just plain stops.b  I Fission doesn't build on itself if the neutron production falls below theoE break-even point.  Put the control rods farther in, and it slows down,F (except at Chernoble, see below).  Similarly, some new reactor designsC waste more neutrons if they get too hot, which also puts them belowWC break-even.  These changes in reactivity are fairly gradual, partly J because of the delayed neutrons from uranium fission.  That's what I meantF by self-regulating.  They don't stop instantly, but they begin slowing down right away.  D True, a fusion reactor seems all-or-nothing, and any deviation wouldH likely kill the reaction.  But perhaps that's because we're used to themI not working at all, and hope they barely work some time soon.  Mightn't a0E practical, working fusion reactor have enough potential reactivity to-G cause quite a mess in the process of shutting down?  I haven't seen any D studies of _inherent_ safety in these reactor designs.  Is it just a generally-assumed hand-wave?  H Remember, the fusion reaction is a H-bomb is not stable or sustainable. J It's killing itself from the first moment.  But it sure does a lot of harm in the process.   J (Skipable semi-technical fission aside:  Some of the neutrons from UraniumC aren't emitted immediately, but are delayed by 30 seconds or so.  ArJ typical reactor is sub-critical if you only count the prompt neutrons, andC the extra delayed neutrons are enough to bring it to the break-even4I point.  To increase the output of the reactor, you have to go just beyondbJ the break-even point.  If the extra neutrons are the slow ones, the outputJ changes fairly slowly.  For example, read the description of Fermi's firstC start-up of CP-1 in "The Making of the Atomic Bomb" by Rhodes.  ThecG doubling time was very long.  The slow neutrons make reactor managementnG much easier; you don't have to react instantly to changing situations.)u  A Chernobyl was an interesting illustration of the blessing of slowaI neutrons.  Apparently the control rod system had a built-in stupidity, to-H save money.  As the control rods were withdrawn, the space they occupiedH filled with water.  Better is to attach something inert to the bottom ofE the control rods, so that water can't come in.  Water is ordinarily a6J neutron moderator; it slows neutrons down and makes them more effective atI causing fission.  But the confused operators at Chernobyl got the reactornI so far out of kilter, pressures and temperatures were such that the wateraH wasn't a moderator, but rather a damper.  When they paniced, and put allH the control rods in at once, the rods pushed that water out of the core,H and it _increased_ the reactivity so much that the prompt neutrons aloneF made the reactor super-critical.  The doubling time for prompt-neutronG fission was a fraction of a second, and none of the systems (or people)pH had time to react.  The sudden heat release blew the lid off the reactor vessel.n  C One of the many sad features of Chernobly was that this control rodoI problem was known in advance. They decided it was ok since normal reactore: parameters didn't come close to the problem region.  Dumb.  ) Moral: prompt-critical is Very Bad Thing.a  A Now back to mourning the lack of brains in Compaq's management...l   -- s Robert Deininger rdeininger@mindspring.com    ------------------------------  % Date: Mon, 25 Jun 2001 17:28:08 +0200n5 From: Martin Knoblauch <Martin.Knoblauch@TeraPort.de>j  Subject: Re: [OT] Climate change+ Message-ID: <3B375888.E17094F1@TeraPort.de>a   Robert Deininger wrote:o > 5 > In article <MQZ0pnTf1G8O@eisner.encompasserve.org>,-0 > koehler@encompasserve.org (Bob Koehler) wrote: >  > > In articleC > <rdeininger-2106011851400001@user-2iveav3.dialup.mindspring.com>,a6 > rdeininger@mindspring.com (Robert Deininger) writes:9 > > > In article <VoNf2ph$oaYt@eisner.encompasserve.org>,h4 > > > koehler@encompasserve.org (Bob Koehler) wrote: > > >oO > > >> At least with a fusion reactor (and I look forward to them), if anythingsN > > >> goes wrong the whole thing stops faster than you can think about it, no8 > > >> Chernobyl style melt downs like fission reactors. > > >oP > > > There are fission reactor designs that have the same feature.  If they getN > > > hotter, they get less reactive and tend to slow down.  I don't think any8 > > > of these newer designs have been built in the U.S. > >sI > > Design in is nice, but in fission the basic process tends to build on<I > > itself and can simply run aways when something goes wrong (safety and-M > > backup systems can fail), whereas in fusion the basic process is severaly = > > unstable so when anything goes wrong it just plain stops.o > K > Fission doesn't build on itself if the neutron production falls below the G > break-even point.  Put the control rods farther in, and it slows downoH > (except at Chernoble, see below).  Similarly, some new reactor designsE > waste more neutrons if they get too hot, which also puts them below E > break-even.  These changes in reactivity are fairly gradual, partlyeL > because of the delayed neutrons from uranium fission.  That's what I meantH > by self-regulating.  They don't stop instantly, but they begin slowing > down right away. >   @  I wouldn't call the "Hight Temperature Thorium Reactor" new :-(A Unfortunatelly, it was never developed into series production ...    Martin --  B ------------------------------------------------------------------B Martin Knoblauch         |    email:  Martin.Knoblauch@TeraPort.de7 TeraPort GmbH            |    Phone:  +49-89-510857-309a7 C+ITS                    |    Fax:    +49-89-510857-111c5 http://www.teraport.de   |    Mobile: +49-170-4904759    ------------------------------   End of INFO-VAX 2001.350 ************************