1 INFO-VAX	Mon, 03 Dec 2001	Volume 2001 : Issue 671       Contents:P 7368           Would you like to lose weight while you sleep?                  1' AS4100 for VMS Hobbyist in Chicago area  Re: IEQ11 Driver VMS$ Installing Netscape from Hobbyist CD KFPSA compatibility 
 McKinley Info  Re: McKinley Info  NCL equivalent of NCP command? RE: Needed Information Re: Needed Information! Re: No surprise about Tru64 death ! Re: No surprise about Tru64 death ! Re: No surprise about Tru64 death ! Re: No surprise about Tru64 death ! Re: No surprise about Tru64 death ! Re: No surprise about Tru64 death ! Re: No surprise about Tru64 death ! Re: No surprise about Tru64 death G Q: Tool or script to remove nonprinting characters from a SET HOST log?  Re: RECALL does not workE Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org . Re: the Compaq pseudo-technical spin continues. Re: the Compaq pseudo-technical spin continues. Re: the Compaq pseudo-technical spin continues. Re: the Compaq pseudo-technical spin continues. Re: the Compaq pseudo-technical spin continues. Re: the Compaq pseudo-technical spin continues. Re: the Compaq pseudo-technical spin continues) Re: The real story about Alpha's death ?? ) Re: The real story about Alpha's death ?? ) Re: The real story about Alpha's death ?? ) Re: The real story about Alpha's death ?? / Re: Using CMS$LIB to create a list of libraries L Re: Why does file access preformance over WAN depend greatly on the command?4 Re: why not a communityDeveloped[tm] version of VMS?  F ----------------------------------------------------------------------   Date: Mon, 3 Dec 2001 06:41:12% From: 4112921travelincentives@aol.com Y Subject: 7368           Would you like to lose weight while you sleep?                  1 ) Message-ID: <200112022247.OAA16768@rs213>   6  As seen on NBC, CBS, CNN, and even Oprah! The health : discovery that actually reverses aging while burning fat, < without dieting or exercise! This proven discovery has even 9 been reported on by the New England Journal of Medicine.  : Forget  aging and dieting forever! And it's Guaranteed!      Click here:  http://ultimatehgh.81832.com  . Would you like to lose weight while you sleep! No dieting!  No hunger pains! No Cravings! No strenuous exercise! Change your life forever!    100% GUARANTEED!  + 1.Body Fat Loss            82% improvement. ( 2.Wrinkle Reduction     61% improvement., 3.Energy Level              84% improvement.* 4.Muscle Strength         88% improvement.* 5.Sexual Potency          75% improvement., 6.Emotional Stability       67% improvement./ 7.Memory                       62% improvement.   ; ***********************************************************   . Click here to see another weight loss product: http://weighout.81832.com   , You are receiving this email as a subscriber$ to the Opt-In America Mailing List. . To remove yourself from all related maillists, just click here:/ mailto:pac2server@btamail.net.cn?Subject=REMOVE    ------------------------------  # Date: Mon, 03 Dec 2001 05:09:10 GMT . From: brown_du@eisner.decus.org (Duncan Brown)0 Subject: AS4100 for VMS Hobbyist in Chicago area8 Message-ID: <3c0b0510.32300643@news.directvinternet.com>  E I picked up a couple of lightly used AlphaServer 4100 5/400's a while C back.  I've built up one heck of a VMS Hobbyist machine for myself, D but then I still have this complete running extra one left over.  MyD son loaded Redhat on it, realized what a complete waste of time thatC was (long story) and then gave up.  Since he no longer wants it and F it's just taking up space, I thought I'd offer it up to some other VMSC Hobbyist type in the area, who wants a little more "oomph" than the = typical AlphaStation 200 or whatever most people are running.   F This was basically used for a few months and then put in storage for 3C years before I got it.  It's got a single 400MHz (4MB cache) CPU in > it, with 512MB of memory.  It's got a TZ88 DLT and a couple ofF RZ29B-VWs in one split-bus wide shelf fed by two SCSI controllers, andE 3 RZ29B-VW's in another split-bus wide shelf fed by a 3-channel SWXCR D RAID controller.  (It has the bulkhead connector and third cable, ifE you wanted to run it to the other half of the other shelf.)  It comes @ with a PC-style DEC keyboard and 3-button mouse, but no monitor.  B If you want the system but not all the parts (eg you have some 9GBD drives and don't need the 4.3GB ones) I'd be more than happy to keepA what you don't need, as spares for my other system, and lower the C price.  If you want a base VMS 7.1 doc set with it, it's all yours!   D I'm in the Chicago area and can't imagine trying to ship this thing.C I'm willing to drive a ways to help with transport, but if you come C here you can see it run.  (It's got Redhat on the loose drives, and > VMS 7.2 running on the RAID drives.)  I won't sell this to anyD equipment resellers, only to a fellow VMS hobbyist.  I didn't botherF to get the VMS licenses transferred, but if that's important to you weB can probably make that happen from the original owner.  Make me anE offer - I don't need anywhere near the prices that the real resellers A get for these things, but I do have some bucks tied up in them...   E Here are some pictures (sorry for the crummy digital camera quality!)   0 http://www.backglass.org/duncan/as4100_cab_1.jpg0 http://www.backglass.org/duncan/as4100_cab_2.jpg1 http://www.backglass.org/duncan/as4100_cables.jpg . http://www.backglass.org/duncan/as4100_cpu.jpg1 http://www.backglass.org/duncan/as4100_sh_dev.jpg 6 http://www.backglass.org/duncan/as4100_sh_config_1.jpg6 http://www.backglass.org/duncan/as4100_sh_config_2.jpg3 http://www.backglass.org/duncan/as4100_test_mem.jpg    Duncan   ------------------------------   Date: 2 Dec 2001 19:14:04 -0800   From: srf23@yahoo.com (SteveF23) Subject: Re: IEQ11 Driver VMS = Message-ID: <e8f65efb.0112021914.3e591388@posting.google.com>   5 I actually need the IEQ11 - and Compaq is not willing 1   to dig it up.  Yes I know that it is an ancient &  artifact, but mine is a long story.    X "Hans Vlems" <hvlems@iae.nl> wrote in message news:<sZoO7.63$d21.191@typhoon.bart.nl>...= > IIRC there is a difference between the IEX11 and the IEQ11. = > Both interfaces connect to the IEEE bus (aka as the HP-IB). > > The IEQ11 is a Q-bus controller, the IEX11 is a SCSI device. > > > The source code for the IEQ11 is gone, the IEX11 sources are0 > still available (at least in the Netherlands).I > We had the IEX-11 driver modified for VMS V7.1 (by Compaq) and it works  > fine. D > I'm not sure I can post the source code legally, but you could ask? > for the modified drivers at Compaq. The price was reasonable.  >  > Hans Vlems >  > - > SteveF23 <srf23@yahoo.com> wrote in message 9 > news:e8f65efb.0112011733.3df6c7f9@posting.google.com... ? > > I am involved in a project using an IEQ11, on VMS using the A > >  IEX driver.  I have the IEX driver binaries and license, but @ > >  I would like to see the source code to the driver.  Anybody8 > >  out there have the source in a attic or somewhere ?   ------------------------------  # Date: Sun, 02 Dec 2001 18:21:56 GMT 0 From: William Barnett-Lewis <wlewis@mailbag.com>- Subject: Installing Netscape from Hobbyist CD + Message-ID: <3C0A7143.BF1236AD@mailbag.com>   B I'm still pretty new to VMS so I'm probably missing something veryF obvious. I had to reinstall the OS and did that just find. I am loggedD in under DEC Windows as System and have the hobbyist cd mounted. The@ machine is a VAXstation 4000 VLC with 24mb RAM and 1gb of disk.   G I copy the netscape self expanding file to my system disk and "Run" it. E It goes to completion. But then when I attempt to "Run" the resulting + .exe file, I get an Access violation error.   ; %SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual , address=FFFFFFFF, PC=005B14D2, PSL =0BC00000  < There is also a trace back that I can give if it is useful.   B Is there anything obvious I am missing? Any clues? Should I try toC download it or another browser? Any hints or tips happily accepted.    TIA,   William  --  * You better watch out    What you wish for;+ It better be worth it   So much to die for. -                                 Courtney Love    ------------------------------  # Date: Mon, 03 Dec 2001 00:30:18 GMT  From: dittman@dittman.net  Subject: KFPSA compatibility9 Message-ID: <uIzO7.386$lI5.814392@paloalto-snr2.gtei.net>   > Is the KFPSA compatible with the PWS 500au?  My system doesn't= see the board, which makes me suspect the board is bad, but I / thought I'd check before contacting the seller.  --   Eric Dittman dittman@dittman.net = Check out the DEC Enthusiasts Club at http://www.dittman.net/    ------------------------------   Date: 2 Dec 2001 20:45:46 -0600 + From: young_r@encompasserve.org (Rob Young)  Subject: McKinley Info3 Message-ID: <cRdjpZzUrRHc@eisner.encompasserve.org>   A Paul DeMone has highlighted McKinley core info from the upcoming   ISSC over at RealWorld Tech.  L He seems to be impressed.   There are also other interesting tidbits in that thread.    				Rob    ---   g http://www.realworldtech.com/forums/index.cfm?action=detail&PostNum=428&Thread=3&entryID=3222&roomID=13   $ L1 caches: 16 KB each. L1 dcache is: - quad ported (2R+2W)  - 4 way set associative (IIRC)? - only accessible by integer load/stores (FP go straight to L2)  - 1 cycle load-use latency. - 19.2 GB/s R + 19.2 GB/s W bandwidth @1.2 GHz   L2 cache: 256 KB - quad ported, 5 cycle latency - ECC protected    L3 cache: 3.0 MB2 - 12 cycle latency, 76.8 GB/s bandwidth at 1.2 GHz> - can load, store 128 byte cache line every 4 clocks (implying5 separate 256 bit read, write buses between L2 and L3)  - ECC protected.  @ All in all, the McKinley has a very impressive cache hierarchy.    ------------------------------  # Date: Mon, 03 Dec 2001 04:22:21 GMT * From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: McKinley InfoB Message-ID: <16DO7.222877$dk.15201337@bin1.nnrp.aus1.giganews.com>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:cRdjpZzUrRHc@eisner.encompasserve.org...  > B > Paul DeMone has highlighted McKinley core info from the upcoming > ISSC over at RealWorld Tech. >  > He seems to be impressed.   9 With the cache hierarchy, as distinguished from the core.   3    There are also other interesting tidbits in that 	 > thread.   @ Indeed.  I particularly liked Paul's later comments on the core:  G "EPIC/VLIW isn't the best soution, or even a very good solution. But it H doesn't suck by large enough margin that keep it from being a commercialG success (and the x86 gives us a prime example of how much architectural K "suckage" that semi manufacturing economics, software compatibility network H effects, and much bigger wallets can make up for). If EPIC fails it willH only be to x86 and going with Alpha instead won't overturn that result."  G However, in suggesting that 'manufacturing economics' can have the same F impact on Itanic that they've had on IA32 I think he's not taking intoF account the rather different characteristics of the server product andJ market, where the cost of the processor is a far less important issue thanH it is with PCs.  And he also may be giving inordinate weight to whateverJ (presumably IA32) software compatibility Itanic brings to the table, sinceH said software reportedly runs at 100 MHz Pentium speeds (perhaps 200 MHzL Pentium speeds when Madison arrives) and, perhaps more importantly, consumesI full time-slices on the processor while doing so (so, for example, if you L ran *only* IA32 software on it and spent little time in the kernel, not onlyK would each application run at such speeds but you couldn't run many more of H them than you could on an early Pentium without bogging things down evenC more - a situation only partially ameliorated when you run a mix of ' applications many of which are 32-bit).   H Also, I think he may underestimate just how much more baggage EPIC makesJ Itanic carry than even x86 carries.  That baggage is not hard to see:  allA you have to do is compare power requirements (2 - 4 times that of L comparably-performing chips) or core sizes (e.g., elsewhere in the thread heI notes that the McKinley core, exclusive of caches, is 3 times the size of  EV68's).  H Those are large enough handicaps that I believe there's still legitimateJ doubt about Intel's ability to make it 'a commercial success' - especiallyH in the quantities that would need to be sold just to repay Intel for theJ money it has already sunk into it (that being one reasonable definition ofL 'commercial success', I believe).  As long as IBM doesn't fumble POWER4, theI only Itanic that has a chance of competing with it on the high end is the J vapor product that the Alpha team may come up with around 2006, which is aI *long* time to hold on with nothing but a turkey to field.  And if Hammer L lives up to even most of its promise, Itanic won't do well lower-down eitherK (for that matter, IA32 will be extremely cost-effective low-end competition , for it for at least the next several years).  F x86 succeeded by being introduced into a near-vacuum, where no similarG system products existed (or at least were perceived to exist) and IBM's D marketing clout and ability to establish new-product legitimacy wereH overwhelming assets.  Itanic is being introduced into maturing markets -L with well-entrenched players (IBM, SUN) in the upper ranges and *completely*K established competition (IA32, with Hammer well-positioned to capitalize on K its compatibility at full native speed) at the low end:  the exact opposite L of a vacuum.  Whether marketing clout can surmount the significant intrinsic7 handicaps Itanic brings to the table is far from clear.    - bill   ------------------------------  $ Date: Mon, 3 Dec 2001 08:46:16 +0530$ From: "upadhyaya" <ups@hotvoice.com>' Subject: NCL equivalent of NCP command? 0 Message-ID: <F7CO7.37$BK1.1134@news.cpqcorp.net>   Hi, J What is the NCL equivalent of DEFINE EXEC RECEIVE PIPE QUOTA (NCP command)J for DECnet phase V? If I change the RECEIVE PIPE QUOTA on a machine havingH DECnet phase V, do I need to reboot or restart DECnet?. If yes (I mean IK have to restart DECnet) then what is the command to restart DECnet phase V?    Thanks, 	 Upadhyaya    ------------------------------  $ Date: Sun, 2 Dec 2001 20:47:37 -0500* From: WILLIAM WEBB <WWEBB1@email.usps.gov> Subject: RE: Needed Information - Message-ID: <0033000043396556000002L062*@MHS>    =0AWebsearch, m'dear:    http://www.openvms.compaq.com/   will show you lots of things.   ) And the ABC rating system isn't any more.   6 That's been replaced by what's called Common Criteria.   HTH    WWWebb   -----Original Message-----/ From: Info-VAX-Request@Mvb.Saic.Com at INTERNET ) Sent: Saturday, December 01, 2001 9:33 PM B To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET Subject: Needed Information     E I'm looking for some information about VMS, the history of it, NOS/OS ? family of products for it, most current version, minimum system D requirements, recommended environment, recommended use, advantages &C disadvantages, hardware platforms, licensing issues, c2 compliance,   security features, future of it.   Quote of the day: 9 For every action there is an equal and opposite reaction.  - Albert Einstein     1 File item 2 original document name: Not specified ! File item 2 document type: PCDATA  File item 2 size (bytes): 58370 File item 3 original document name: image001.jpg! File item 3 document type: PCDATA  File item 3 size (bytes): 6281=    ------------------------------  # Date: Mon, 03 Dec 2001 01:46:25 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>  Subject: Re: Needed Information ' Message-ID: <3C0AD983.5961FB96@fsi.net>   @ Please don't post HTML or graphics (binary info.) to a text-only
 newsgroup.   Take a look at the OpenVMS FAQ:   5 http://www.openvms.compaq.com/wizard/openvms_faq.html   G That's about the best place to start. After that, OpenVMS documentation  is on-line at:  " http://www.openvms.compaq.com/doc/   --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/u   ------------------------------  " Date: Sun, 2 Dec 2001 23:02:49 GMT- From: Terry C Shannon <shannon@world.std.com>S* Subject: Re: No surprise about Tru64 deathC Message-ID: <Pine.SGI.4.30.0112021800130.7028-100000@world.std.com>i  % On Sun, 2 Dec 2001, John Smith wrote:a  M > For those of you who have access to subscription access to www.idc.com, seer > L > And Then There Were Three: Compaq Drops IA64 Tru64 Unix Plans     Oct 1999 > Doc #20624  C Yep, the death (or shelving) of the Bravo project. Said project was F reactivated on June 26 and the resulting code booted on IPF some weeksH back. All for naught, unless the clustering and RAS components have been3 IPF-fied, thus enabling a faster strap-on to HP-UX.o   ------------------------------  % Date: Sun, 02 Dec 2001 21:10:10 -0500r- From: JF Mezei <jfmezei.spamnot@videotron.ca>w* Subject: Re: No surprise about Tru64 death, Message-ID: <3C0ADEFC.DD078B93@videotron.ca>   Bill Todd wrote:M > 'All for naught' ... *if* the merger goes through - or if the merger fails,eN > Curly & Co. get the boot, and Alpha is resurrected.  But if the merger failsN > and the IPF migration idiocy survives, then Compaq will either port Tru64 or  > be left without a viable Unix.    K Now that Compaq has announced its true colours and killed Alpha and Tru64, sN Tru64 is relegated to the installed base until they migrate to a platform that  doesn't have a death wish on it.  H If the merger fails, Compaq is still stuck with the image that it had noK problems killing Tru64 and Alpha. Compaq does not have long term stamina to-L rebuild Tru64's credibility. It will probably have to merge Tru64 with Linux instead of HP-UX.r  L Had the Compaq stock continued to thumble, the odds of the merger would haveL continued to go down as investors would havbe woken up to the sad managementK of Compaq/HP. But last friday, Compaq's stock closed higher than $10, so mycF guess is that investors have forgotten about the merger and no seriousO opposition will mount, allowing the paperwork to go through. It is a done deal.    ------------------------------  # Date: Mon, 03 Dec 2001 00:40:29 GMTn* From: "Bill Todd" <billtodd@metrocast.net>* Subject: Re: No surprise about Tru64 deathB Message-ID: <1SzO7.113739$uB.15979574@bin3.nnrp.aus1.giganews.com>  : "Terry C Shannon" <shannon@world.std.com> wrote in message= news:Pine.SGI.4.30.0112021800130.7028-100000@world.std.com...  >u >o' > On Sun, 2 Dec 2001, John Smith wrote:  > K > > For those of you who have access to subscription access to www.idc.com,P seey > > I > > And Then There Were Three: Compaq Drops IA64 Tru64 Unix Plans     Octy 1999 > > Doc #20624 >%E > Yep, the death (or shelving) of the Bravo project. Said project was*H > reactivated on June 26 and the resulting code booted on IPF some weeksJ > back. All for naught, unless the clustering and RAS components have been5 > IPF-fied, thus enabling a faster strap-on to HP-UX.e  K 'All for naught' ... *if* the merger goes through - or if the merger fails, L Curly & Co. get the boot, and Alpha is resurrected.  But if the merger failsL and the IPF migration idiocy survives, then Compaq will either port Tru64 or be left without a viable Unix.   - bill   ------------------------------  $ Date: Sun, 2 Dec 2001 20:07:56 -0500) From: "Mike Foley" <mikiefoley@yahoo.com>v* Subject: Re: No surprise about Tru64 death/ Message-ID: <u0ljticr2fu3fd@corp.supernews.com>t  5 "Bill Todd" <billtodd@metrocast.net> wrote in messagei< news:1SzO7.113739$uB.15979574@bin3.nnrp.aus1.giganews.com...  F > 'All for naught' ... *if* the merger goes through - or if the merger fails,H > Curly & Co. get the boot, and Alpha is resurrected.  But if the merger failssK > and the IPF migration idiocy survives, then Compaq will either port Tru64e or  > be left without a viable Unix.  H     Bill, that parrot is dead. Pining for the fjords. Kaput. Done. Over. Move     on please.  H     Alpha is NOT going to be rebirthed or born-again. IPF may not be theF     finest example of an CPU design (I happen to like Hammer from whatJ     I've read) but it's the CPU VMS is using. Intel has ALOT more money toF     drive costs of IA-64 down. In addition, it wouldn't surprise me if CompaqH     is getting $$ from Intel to help fund the port and eventually MARKET VMS.  K     Remember Bill, this is a business. You're not going to get the EV8 teamy backI     together because it's "the right thing to do" or for any other reason  for that*     matter. It's just not going to happen.   --   mike Former VMS group system managerh* Former technical marketing engineer at API   ------------------------------  # Date: Mon, 03 Dec 2001 01:20:48 GMT * From: "Bill Todd" <billtodd@metrocast.net>* Subject: Re: No surprise about Tru64 deathA Message-ID: <QrAO7.29756$tf5.1617407@bin5.nnrp.aus1.giganews.com>r  4 "Mike Foley" <mikiefoley@yahoo.com> wrote in message) news:u0ljticr2fu3fd@corp.supernews.com...l >o7 > "Bill Todd" <billtodd@metrocast.net> wrote in messagel> > news:1SzO7.113739$uB.15979574@bin3.nnrp.aus1.giganews.com... >yH > > 'All for naught' ... *if* the merger goes through - or if the merger > fails,J > > Curly & Co. get the boot, and Alpha is resurrected.  But if the merger > failsbG > > and the IPF migration idiocy survives, then Compaq will either portd Tru64c > or" > > be left without a viable Unix. >dJ >     Bill, that parrot is dead. Pining for the fjords. Kaput. Done. Over. > Move >     on please.  G No, thanks:  I still think there's an excellent chance that Compaq willpJ either suffer a complete change in management or go out of business and beJ broken up for parts, either of which will open possibilities not currently seen as acceptable.c   >s7 >     Alpha is NOT going to be rebirthed or born-again.-  C Hmmm.  While I don't know for a fact, my guess would be that ItanicoG enthusiasts at SGI and HP likely said similar things when the deaths of1  PA-RISC and MIPS were announced.  I But the future is by definition uncertain.  If Itanic sinks, or even justpK can be clearly seen to be a forever-second-class architecture, exactly what I is Compaq going to do as an alternative to resurrecting Alpha just as SGIoK and HP resurrected their architectures?  If the alternative is going out of G business, it's just amazing how many 'impossible' things turn out to beE feasible after all.l    IPF may not be theIH >     finest example of an CPU design (I happen to like Hammer from whatL >     I've read) but it's the CPU VMS is using. Intel has ALOT more money toH >     drive costs of IA-64 down. In addition, it wouldn't surprise me if > CompaqJ >     is getting $$ from Intel to help fund the port and eventually MARKET > VMS. >hH >     Remember Bill, this is a business. You're not going to get the EV8 team > backK >     together because it's "the right thing to do" or for any other reason 
 > for that, >     matter. It's just not going to happen.  L Well, if Itanic tanks, the question is what else they'll be doing.  I'm sureJ Intel would like them to work on a replacement, but given a choice betweenE that and EV8 what each would do is by no means a foregone conclusion.   E And that doesn't address the possibility that EV8 is far enough alongi& already for the EV7 team to finish it.  H Of course, if Itanic actually does tank, Intel might find developing EV8, *itself* to be the most attractive Plan B...   - bill   ------------------------------  # Date: Mon, 03 Dec 2001 02:06:57 GMTo  From: cjt <cheljuba@prodigy.net>* Subject: Re: No surprise about Tru64 death+ Message-ID: <3C0ADE11.2D4B9E7E@prodigy.net>a   Bill Todd wrote: > 6 > "Mike Foley" <mikiefoley@yahoo.com> wrote in message+ > news:u0ljticr2fu3fd@corp.supernews.com...  > >I9 > > "Bill Todd" <billtodd@metrocast.net> wrote in messages@ > > news:1SzO7.113739$uB.15979574@bin3.nnrp.aus1.giganews.com... > >1J > > > 'All for naught' ... *if* the merger goes through - or if the merger
 > > fails,L > > > Curly & Co. get the boot, and Alpha is resurrected.  But if the merger	 > > failsoI > > > and the IPF migration idiocy survives, then Compaq will either porte > Tru64  > > or$ > > > be left without a viable Unix. > >tL > >     Bill, that parrot is dead. Pining for the fjords. Kaput. Done. Over. > > Move > >     on please. > I > No, thanks:  I still think there's an excellent chance that Compaq willmL > either suffer a complete change in management or go out of business and beL > broken up for parts, either of which will open possibilities not currently > seen as acceptable.   H I would say there's an excellent chance both will happen, in that order.   >  > >e9 > >     Alpha is NOT going to be rebirthed or born-again.a > E > Hmmm.  While I don't know for a fact, my guess would be that Itanic-I > enthusiasts at SGI and HP likely said similar things when the deaths ofn" > PA-RISC and MIPS were announced.  K Reviving an architecture for a few last gasps doesn't address the issue of   credibility in the marketplace.l   > K > But the future is by definition uncertain.  If Itanic sinks, or even justpM > can be clearly seen to be a forever-second-class architecture, exactly what K > is Compaq going to do as an alternative to resurrecting Alpha just as SGIuM > and HP resurrected their architectures?  If the alternative is going out of I > business, it's just amazing how many 'impossible' things turn out to bey > feasible after all.P >  >  IPF may not be theyJ > >     finest example of an CPU design (I happen to like Hammer from whatN > >     I've read) but it's the CPU VMS is using. Intel has ALOT more money toJ > >     drive costs of IA-64 down. In addition, it wouldn't surprise me if
 > > CompaqL > >     is getting $$ from Intel to help fund the port and eventually MARKET > > VMS. > > J > >     Remember Bill, this is a business. You're not going to get the EV8 > team > > backM > >     together because it's "the right thing to do" or for any other reasonb > > for that. > >     matter. It's just not going to happen. > N > Well, if Itanic tanks, the question is what else they'll be doing.  I'm sureL > Intel would like them to work on a replacement, but given a choice betweenG > that and EV8 what each would do is by no means a foregone conclusion.g > G > And that doesn't address the possibility that EV8 is far enough alonge( > already for the EV7 team to finish it. > J > Of course, if Itanic actually does tank, Intel might find developing EV8. > *itself* to be the most attractive Plan B... >  > - bill   I think you're in fantasy land.t   ------------------------------  # Date: Mon, 03 Dec 2001 03:30:58 GMTm* From: "Bill Todd" <billtodd@metrocast.net>* Subject: Re: No surprise about Tru64 deathB Message-ID: <SlCO7.114919$uB.16092362@bin3.nnrp.aus1.giganews.com>  - "cjt" <cheljuba@prodigy.net> wrote in messagea% news:3C0ADE11.2D4B9E7E@prodigy.net.... > Bill Todd wrote: > >n8 > > "Mike Foley" <mikiefoley@yahoo.com> wrote in message- > > news:u0ljticr2fu3fd@corp.supernews.com...n > > >i; > > > "Bill Todd" <billtodd@metrocast.net> wrote in messagevB > > > news:1SzO7.113739$uB.15979574@bin3.nnrp.aus1.giganews.com... > > >aL > > > > 'All for naught' ... *if* the merger goes through - or if the merger > > > fails,G > > > > Curly & Co. get the boot, and Alpha is resurrected.  But if then merger > > > failsrK > > > > and the IPF migration idiocy survives, then Compaq will either port 	 > > Tru64r > > > or& > > > > be left without a viable Unix. > > >MH > > >     Bill, that parrot is dead. Pining for the fjords. Kaput. Done. Over. 
 > > > Move > > >     on please. > > K > > No, thanks:  I still think there's an excellent chance that Compaq willlK > > either suffer a complete change in management or go out of business and  beD > > broken up for parts, either of which will open possibilities not	 currentlyo > > seen as acceptable.o >-J > I would say there's an excellent chance both will happen, in that order. >n > >w > > >e; > > >     Alpha is NOT going to be rebirthed or born-again.h > > G > > Hmmm.  While I don't know for a fact, my guess would be that ItanicnK > > enthusiasts at SGI and HP likely said similar things when the deaths ofe$ > > PA-RISC and MIPS were announced. >oL > Reviving an architecture for a few last gasps doesn't address the issue of! > credibility in the marketplace.   K My point was merely that what seems inevitable one day may not be the next.t  J Alpha is in some ways both considerably more easily revivable than PA-RISCH and MIPS (since it hasn't been in the coffin nearly as long as they wereJ before being revived) and considerably more worthwhile to revive (since itJ has an evolutionary path far into the future - certainly much more than 'aE few last gasps', with at least the next major step well on the way tohH completion).  So an earnest, fully-backed revival effort that could takeH advantage of the Alpha talent still at Compaq plus any they could entice$ back would not lack for credibility.  I Unless, of course, you meant the credibility of its owner.  But a revivaltJ attempt wouldn't be likely to occur under current management, and whateverG followed that would have to establish credibility on all fronts anyway.o   >a > >uH > > But the future is by definition uncertain.  If Itanic sinks, or even justJ > > can be clearly seen to be a forever-second-class architecture, exactly whatI > > is Compaq going to do as an alternative to resurrecting Alpha just as- SGIhL > > and HP resurrected their architectures?  If the alternative is going out ofK > > business, it's just amazing how many 'impossible' things turn out to bep > > feasible after all.s > >  > >  IPF may not be thetL > > >     finest example of an CPU design (I happen to like Hammer from whatG > > >     I've read) but it's the CPU VMS is using. Intel has ALOT more  money toL > > >     drive costs of IA-64 down. In addition, it wouldn't surprise me if > > > CompaqG > > >     is getting $$ from Intel to help fund the port and eventuallyC MARKET
 > > > VMS. > > >.L > > >     Remember Bill, this is a business. You're not going to get the EV8 > > team
 > > > backH > > >     together because it's "the right thing to do" or for any other reason > > > for that0 > > >     matter. It's just not going to happen. > >rK > > Well, if Itanic tanks, the question is what else they'll be doing.  I'mp sureF > > Intel would like them to work on a replacement, but given a choice betweenmI > > that and EV8 what each would do is by no means a foregone conclusion.e > >-I > > And that doesn't address the possibility that EV8 is far enough alongw* > > already for the EV7 team to finish it. > >hL > > Of course, if Itanic actually does tank, Intel might find developing EV80 > > *itself* to be the most attractive Plan B... > >-
 > > - bill >s! > I think you're in fantasy land.b  I So what are *your* suggestions for what will happen if Itanic sinks or at I least terminally flounders (due to lackadaisical speed coupled with 2 - 3nC times the power requirements of its competitors), then?  Intel willrJ certainly need a 64-bit replacement, and so will Compaq - and while CompaqJ might find it in Hammer (porting there might be an attractive alternative,L assuming customers would go along - though scaling beyond 8 processors might2 be a problem), that's not a real option for Intel.   - bill   ------------------------------  # Date: Mon, 03 Dec 2001 04:12:25 GMTi  From: cjt <cheljuba@prodigy.net>* Subject: Re: No surprise about Tru64 death+ Message-ID: <3C0AFB7B.75194E59@prodigy.net>i   Bill Todd wrote: >  <snip> > K > So what are *your* suggestions for what will happen if Itanic sinks or at K > least terminally flounders (due to lackadaisical speed coupled with 2 - 3mE > times the power requirements of its competitors), then?  Intel willoL > certainly need a 64-bit replacement, and so will Compaq - and while CompaqL > might find it in Hammer (porting there might be an attractive alternative,N > assuming customers would go along - though scaling beyond 8 processors might4 > be a problem), that's not a real option for Intel. >  > - bill  L Good question.  By then they might be in a position to keep their lines busy& making 700 MHz Pentiums for the X-Box.   ------------------------------  # Date: Mon, 03 Dec 2001 06:44:16 GMToL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")P Subject: Q: Tool or script to remove nonprinting characters from a SET HOST log?8 Message-ID: <00A05F0B.56294229@SSRL04.SLAC.STANFORD.EDU>   Comp.os.vmsers --   I I remember vaguely reading something about a tool or script specifically s= designed to clean up the log files you get from SET HOST/LOG.e  , Can somebody point me toward one of those?    3 (VMS on Alpha, 7.2-1, not that I think it matters.)v   Thanks,    -- Alanc  O ===============================================================================o0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056HM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-02100O ===============================================================================t   ------------------------------  $ Date: Sun, 2 Dec 2001 02:04:35 -00001 From: "Chris Townley" <news@townleyc.demon.co.uk>h! Subject: Re: RECALL does not work @ Message-ID: <1007343115.713.0.nnrp-12.d4e45fa5@news.demon.co.uk>  : "Hunter Goatley" <goathunter@goatley.com> wrote in message* news:3c0700e8.12870116@news.process.com...H > On Thu, 29 Nov 2001 18:34:07 -0500, David Froble <davef@tsoft-inc.com> wrote: >hE > >Speculating.  I'd think that RECALL is implemented in the terminalrH > >driver, and such is not used in batch jobs, thus no capability there. > >,J > The terminal driver does support command-line recall, but only one line.J > DCL's RECALL buffer is pure DCL code.  (I used to have (well, it's stillF > there, but few people need it these days) a program that would patchF > DCL to extend the command recall buffer from 20 commands to 63 (VAX) > or more (Alpha). >  > Hunter  I I think you will find the 20 limit went out years ago, wasnt it VMS 5.0 ?a   -- Chrism   ------------------------------  $ Date: Sun, 2 Dec 2001 12:26:09 -0500  From: John Santos <JOHN@egh.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org6 Message-ID: <1011202122316.16710A-100000@Ives.egh.com>  $ On 2 Dec 2001, Peter da Silva wrote:  5 > In article <By3SEWQlq8KJ@eisner.encompasserve.org>,a. > Rob Young <young_r@encompasserve.org> wrote:< > > 	Past history is not an indicator of future performance. > F > You do realise that this statement basically overturns the scientficG > method, the industrial revolution, the enlightenment, the development H > of iron, bronze, and flint-knapped tools, farming, astronomy, and justD > about everything else that separates conscious, reasoning man from > voiceless animals. > K > Yes, I know that "Past history is not an indicator of future performance"cJ > has become a cliche, but you do know what it really means, don't you? itM > means "we're not actually promising that you'll make money, so if you don'tnJ > you can't sue us". It doesn't really mean what it says. Of *course* pastJ > history is an indication of future performance. If it wasn't, then thereH > would be no point in bothering trying to make any kind of predictions,$ > however tenuous, about the future.  G And furthermore, whoever is saying "past history is not an indicator of B future performance" wants you to believe that past history *is* anE indicator of future performance.  Otherwise, why would they be citing: past history at you?  E It's like when someone says "It's not the money."  That means it *is* 
 the money.   -- . John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------   Date: 2 Dec 2001 15:33:02 -0600o+ From: young_r@encompasserve.org (Rob Young) N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org3 Message-ID: <C3ZUDhwJw9gv@eisner.encompasserve.org>p  X In article <VA.000004d5.b9923ba7@bluewin.ch>, Paul Sture <paul.sture@bluewin.ch> writes:F > In article <bW9TwrKrqoK$@eisner.encompasserve.org>, Rob Young wrote:[ >> In article <VA.000004d1.b42c0ee4@bluewin.ch>, Paul Sture <paul.sture@bluewin.ch> writes:g >> hR >> > Cynical response: With a recession now on (and that's now official in the US R >> > according to the paper I was reading the other day), one could simply wait a Q >> > couple of years or so until prices and wages hit rock bottom, then go for a l2 >> > full port of everything to another platform.  >> YG >>  But I think you are backwards.  Wages don't shrink over here duringeF >>  a recession, they just don't increase (i.e. last time this pinchedG >>  me... only time actually ... I got a 3% pay raise... I believe thath >>  was 1991). >>Q > Sorry Rob, but this side of the pond, things are rather different. Try changing1Q > jobs and I think you'll find yourself looking at a substantial pay cut, and mayeQ > well have to relocate too. Try being unemployed (although I would not wish thatmE > on anyone I know) for a few months and see what you'll then accept.c >   @ 	Yes... that hurts and wages do contract in that case.  So maybe1 	the contraction is seen greatest due to layoffs.7  E >>  Hardware decline in prices?  Somewhat.  But because of the bottomeJ >>  line cost ($$$) , migrations normally don't occur during a contraction >>  in the economy.e >>  P > No? I'll assure you that plenty of UK companies did the VAX to Alpha migrationL > during a full blown recession, the likes of which, apparently, you haven't > experienced. >   D 	That wasn't the $$$ I was referring to.  Those migrations are cheapA 	in comparison and often necessary.  (i.e. aging under performinga@ 	hardware).  The migration I *thought* you were referring to was 	away from VMS.    				Robk   ------------------------------  # Date: Sun, 02 Dec 2001 16:36:53 GMTe& From: "Jeff Killeen" <Jeff@IDM-IO.com>7 Subject: Re: the Compaq pseudo-technical spin continuese7 Message-ID: <FMsO7.897$Vj6.118932@typhoon2.gnilink.net>   5 "Bill Todd" <billtodd@metrocast.net> wrote in message ; news:aM8O7.33875$ox2.2458188@bin4.nnrp.aus1.giganews.com...uE > Perhaps it's your view of Alpha's market that is skewed rather thane Alpha'ss > direction.  H When reading any of Todd's postings pay very very close attention to the2 above statement.  It is the foundation of his POV.  E 1) Ask yourself if his POV of where the market is headed matches your J application environment.  If it doesn't what he is posting is poppycock as* it relates to your production environment.  L 2) Remember the generation of IA64 processors that will replace Alpha shouldI be as fast as today's Alpha processors.  Ask yourself does my application  mix need more than that.  G What then follows is a usual debate about price/performance but that isrG nothing but pure opinion.  Always pay close attention to his statementseK because they have built-in assumptions, that are treated as fact and havingkL universal applicability, about the production environment.  Make up your own4 mind as to whether it applies to your environment...   ------------------------------  $ Date: Sun, 2 Dec 2001 19:55:22 +0100$ From: "Dr. Dweeb" <Dweeb@nospam.com>7 Subject: Re: the Compaq pseudo-technical spin continuesd/ Message-ID: <xSuO7.91$Dc2.3219@news.get2net.dk>   J Yet another Larry Post completely devoid of reference to the post to which
 it responds !d   Dweeb.1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messagea1 news:FMsO7.897$Vj6.118932@typhoon2.gnilink.net...s >*7 > "Bill Todd" <billtodd@metrocast.net> wrote in message-= > news:aM8O7.33875$ox2.2458188@bin4.nnrp.aus1.giganews.com... G > > Perhaps it's your view of Alpha's market that is skewed rather thana	 > Alpha's- > > direction. >EJ > When reading any of Todd's postings pay very very close attention to the4 > above statement.  It is the foundation of his POV. >sG > 1) Ask yourself if his POV of where the market is headed matches yoursL > application environment.  If it doesn't what he is posting is poppycock as, > it relates to your production environment. >gG > 2) Remember the generation of IA64 processors that will replace Alphah shouldK > be as fast as today's Alpha processors.  Ask yourself does my applications > mix need more than that. >rI > What then follows is a usual debate about price/performance but that is I > nothing but pure opinion.  Always pay close attention to his statements F > because they have built-in assumptions, that are treated as fact and havingJ > universal applicability, about the production environment.  Make up your ownu6 > mind as to whether it applies to your environment... >h >l >p >p   ------------------------------  % Date: Sun, 02 Dec 2001 16:47:43 -0500n- From: JF Mezei <jfmezei.spamnot@videotron.ca>e7 Subject: Re: the Compaq pseudo-technical spin continuesd, Message-ID: <3C0AA16D.D6B46E19@videotron.ca>   Jeff Killeen wrote:sN > 2) Remember the generation of IA64 processors that will replace Alpha shouldK > be as fast as today's Alpha processors.  Ask yourself does my applicationc > mix need more than that.    L Still one generation behind what Alpha will be doing by then. But this isn'tM about whether IA64 will one day be able to outperform the 8086 or old alphas.rH It is about Compaq working hard to generate excuses to ditch products itM doesn't want to promote/market. And like it or not, VMS is the last remainingrJ such product on the chopping block now that Alpha and Tru64 have had their life terminated.   ------------------------------  " Date: Sun, 2 Dec 2001 23:18:04 GMT- From: Terry C Shannon <shannon@world.std.com>e7 Subject: Re: the Compaq pseudo-technical spin continuestC Message-ID: <Pine.SGI.4.30.0112021812340.7028-100000@world.std.com>r  # On Sat, 1 Dec 2001, JF Mezei wrote:4   > "Terry C. Shannon" wrote: M > > puzzle together... virtually everything Compaq will tell you under NDA isoM > > available in public domain forums if you know where to look. EV7 is real.n3 > > Marvel is real, and both are alive and kicking.k > N > Was it Windows-64 that was real on Alpha before Compaq and Microsoft decidedN > it wasn't worth the effort to productize since Alpha wasn't being marketed ? >a  J Yep, Win64 was real on Alpha at the last Innovate US show, April 1999. TheE decision not to productize actually was impacted by things other thanEH Alpha marketing or lack thereof. A plan to render NT more robust via theG extension of VMS cluster file system (done but not delivered) and an NTdI version of the NonStop SQL/MX database (in development but not completed)t0 was in the works; the top brass pulled the plug.  H And down the drain went Alpha's opportunity to be the reference platform
 for Win64.   ------------------------------  # Date: Sun, 02 Dec 2001 22:06:18 GMTr& From: "Jeff Killeen" <Jeff@IDM-IO.com>7 Subject: Re: the Compaq pseudo-technical spin continues 7 Message-ID: <uBxO7.1162$Cv.112579@typhoon1.gnilink.net>   : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3C0AA16D.D6B46E19@videotron.ca... > Jeff Killeen wrote:oI > > 2) Remember the generation of IA64 processors that will replace Alphas shouldA > > be as fast as today's Alpha processors.  Ask yourself does myi application  > > mix need more than that. >@H > Still one generation behind what Alpha will be doing by then. But this isn'tgG > about whether IA64 will one day be able to outperform the 8086 or old  alphas. J > It is about Compaq working hard to generate excuses to ditch products itE > doesn't want to promote/market. And like it or not, VMS is the last6	 remainingrL > such product on the chopping block now that Alpha and Tru64 have had their > life terminated.  H Spin - pure spin - it assumes that the reason why this was done was someH emotional bias against these products.  Unfortunately like many commentsH here it does not allow that the decision was driven by business factors.F And by business factors it also means ROI given the total risk for the) investment and the total possible reward.o  I Like it or not a company today that is asking the investment community toeJ support it has a tough road if its is asking for support in a product lineC that will not achieve the status of being number 1 or number 2 in adJ _growing_ market space.  That is because of the Fortune 100 business dogma! as preached by GE's Jack Welch...    ------------------------------  $ Date: Sun, 2 Dec 2001 19:40:13 -0500) From: "Mike Foley" <mikiefoley@yahoo.com> 7 Subject: Re: the Compaq pseudo-technical spin continuesm/ Message-ID: <u0lip4hipul5da@corp.supernews.com>h  K     I think there was more to that arguement than Alpha not being marketingSI     correctly. Methinks there was a bit of a pissing contest going on andiF     The Cape* took all his toys and went home. Just my guess anyways..       *Enricoa     mike  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3C097317.F6667299@videotron.ca... > "Terry C. Shannon" wrote:oJ > > puzzle together... virtually everything Compaq will tell you under NDA isG > > available in public domain forums if you know where to look. EV7 iso real.b3 > > Marvel is real, and both are alive and kicking.y > F > Was it Windows-64 that was real on Alpha before Compaq and Microsoft decidedaL > it wasn't worth the effort to productize since Alpha wasn't being marketed ?o   ------------------------------  # Date: Mon, 03 Dec 2001 00:54:49 GMT * From: "Bill Todd" <billtodd@metrocast.net>7 Subject: Re: the Compaq pseudo-technical spin continuesaB Message-ID: <t3AO7.113835$uB.15988925@bin3.nnrp.aus1.giganews.com>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messager1 news:uBxO7.1162$Cv.112579@typhoon1.gnilink.net...f< > "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message( > news:3C0AA16D.D6B46E19@videotron.ca... > > Jeff Killeen wrote:bK > > > 2) Remember the generation of IA64 processors that will replace Alphao > shouldC > > > be as fast as today's Alpha processors.  Ask yourself does my 
 > application  > > > mix need more than that. > >dJ > > Still one generation behind what Alpha will be doing by then. But this > isn'ttI > > about whether IA64 will one day be able to outperform the 8086 or old 	 > alphas.lL > > It is about Compaq working hard to generate excuses to ditch products itG > > doesn't want to promote/market. And like it or not, VMS is the last  > remaining H > > such product on the chopping block now that Alpha and Tru64 have had theira > > life terminated. >sJ > Spin - pure spin - it assumes that the reason why this was done was someJ > emotional bias against these products.  Unfortunately like many commentsJ > here it does not allow that the decision was driven by business factors.H > And by business factors it also means ROI given the total risk for the+ > investment and the total possible reward.i >tK > Like it or not a company today that is asking the investment community totL > support it has a tough road if its is asking for support in a product lineE > that will not achieve the status of being number 1 or number 2 in aiL > _growing_ market space.  That is because of the Fortune 100 business dogma# > as preached by GE's Jack Welch...m  H Exactly which growing market space is VMS going to be #1 or #2 in, Jeff?L Especially given the way Compaq handles it.  The reason some of those peopleL who really wouldn't care whether they ran VMS on Alpha or on Itanic are veryJ worried is because the reasoning Compaq claims it used to get rid of AlphaC seems very similarly applicable to VMS whenever they may choose to.e  L Of course, Curly is clearly no Jack Welch (in fact, he seems a lot more likeG his Stooge namesake) - so even if he tries to apply Welch's dogma he'lltL likely fail as badly as he has elsewhere over the past 2+ years.  People whoG like pat solutions usually don't understand that very often the 'dogma' I works more because of the unusual competence of the man promoting it thano. because of any intrinsic validity it may have.   - bill   ------------------------------  % Date: Sun, 02 Dec 2001 20:25:10 +0100 1 From: John McLean <mcleanj@swissonline.delete.ch>e2 Subject: Re: The real story about Alpha's death ??5 Message-ID: <3C0A8016.B347199D@swissonline.delete.ch>t  > Being cheeky and adding something extra to me own post ... :-)   John McLean wrote: >  > Brannon Batson wrote:  > >  ....   > >7C > > One problem.  No Alpha people were moved over until mid-August.a > >o > > Brannon1 > > not speaking for Intel > G > Not a huge problem.  Things will still be looking better for the last H > quarter of 2001.  It would have been nice to round 'em up and move 'emF > out sooner but ...  Maybe better to get all the bad news over in oneI > quarter anyway.  I can't push Intel too hard, after all they are takingl" > them off my hands for nothing... >  > John > F > PS. If Compaq had saved one quarter of the estimated annual costs ofA > Alpha in 3Q, it would have changed the loss of $68 million intoA$ > something that was a small profit.    C On reflection, not being able to include the reduced expenditure onS4 Alpha in the 3rd may have been Capellas's game plan.  H With the expenditure included in Q3 Compaq lost $68 million.  With  lossH like this of course the board would have to approve the merger with HP. H Compaq looks to be in dire straits; they need someone to save them.  Did4 someone say "bonuses if the merger goes through" ???  # And in the last quarter of 2001 ...@H the expense of Alpha is removed, the company makes a profit and basks inH glorious light of stock prices that have come back from the dead.  ProofA that Compaq can make money in a tough market !  Who says we can't.F compete with Dell ?  Proof that the market approves of the merger withH HP !  Shame on those who doubted us !   Reputations of Capellas, Winkler) and others (including Fiorina) are saved.s     John McLeann   ------------------------------  " Date: Sun, 2 Dec 2001 22:58:05 GMT- From: Terry C Shannon <shannon@world.std.com>.2 Subject: Re: The real story about Alpha's death ??C Message-ID: <Pine.SGI.4.30.0112021755260.7028-100000@world.std.com>   $ On 1 Dec 2001, Brannon Batson wrote:  p > John McLean <mcleanj@swissonline.delete.ch> wrote in message news:<3C095DFA.B2612EFB@swissonline.delete.ch>...
 > > [snip] > >nJ > > Now if he get it moving fast and get those people over to Intel beforeL > > the end of June, then the savings can start from the 3rd quarter of thisI > > year (Jul-Sep).  The PC segment is being hammered this year - alreadytK > > almost $250 million lost - and the savings will prop up the bottom line2 > > just nicely. >rA > One problem.  No Alpha people were moved over until mid-August.o >o  H Good point! But note that the 25 June decision did enable CPQ to do someE creative 2FQ accounting, thus meeting their earnings expectations (orc6 coming close thereto) despite a hefty revenue decline.   ------------------------------  # Date: Mon, 03 Dec 2001 01:42:23 GMTi1 From: "David J. Dachtera" <djesys.nospam@fsi.net>b2 Subject: Re: The real story about Alpha's death ??' Message-ID: <3C0AD891.9A5D4232@fsi.net>    John McLean wrote: > [snip]J > If he can get rid of Alpha, then he can save about $350 million per year > off the bottom line.  C Unless "Curly's a dope!", as quoted from a musical number ina ThreeaE Stooges film, doesn't hold water. He can add $350 million back to the E bottom line; but to do it, he's gotta kill their Alpha-only cash cowsrG Tru64 and VMS, thus SUBTRACTING $5 billion from the bottom line, endingn up seriously in the red! c  9 You think Enron is in trouble? You ain't seen *SHIT* yet!r  3 >  More to the point, if he can announce it to takeoB > effect in a few years, then he's saved money during that time onJ > development (which for now produces no profit) and even if Compaq has toI > pay for its processors in five years, he probably won't be around to beT > held accountable.h  H The only way that logic works, since IA64 is still unviable, is to startB with an IA32 port, then step back up to 64 bits when Intel finally delivers a saleable IPF CPU.   -- . David J. Dachterau dba DJE Systemsl http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/s   ------------------------------  % Date: Mon, 03 Dec 2001 07:09:16 +0100l1 From: John McLean <mcleanj@swissonline.delete.ch>o2 Subject: Re: The real story about Alpha's death ??5 Message-ID: <3C0B170C.57A5C119@swissonline.delete.ch>    "David J. Dachtera" wrote: >  > John McLean wrote:
 > > [snip]L > > If he can get rid of Alpha, then he can save about $350 million per year > > off the bottom line. > E > Unless "Curly's a dope!", as quoted from a musical number ina Three G > Stooges film, doesn't hold water. He can add $350 million back to thetG > bottom line; but to do it, he's gotta kill their Alpha-only cash cows'I > Tru64 and VMS, thus SUBTRACTING $5 billion from the bottom line, ending  > up seriously in the red!  A Not at all.  Switching them to IPF in a few years will work.  The F current state of Alpha, with enhancements that are close to completionH (and thus development costs will be paid for in the income) are all that8 customers need to carry on with until IPF is available.    > ; > You think Enron is in trouble? You ain't seen *SHIT* yet!  > 5 > >  More to the point, if he can announce it to takeeD > > effect in a few years, then he's saved money during that time onL > > development (which for now produces no profit) and even if Compaq has toK > > pay for its processors in five years, he probably won't be around to be$ > > held accountable.l > J > The only way that logic works, since IA64 is still unviable, is to startD > with an IA32 port, then step back up to 64 bits when Intel finally > delivers a saleable IPF CPU.  > You're forgetting about the "momentum" from various EV7 steps.  @ I'm not an accountant but it seems to me that he has looked at aC long-term asset and decided that it is a short-term liability.  HishG solution helps Compaq's financial state now, helps the merger talks nowmC ... and what happens in 3 or 4 or 5 years (when VMS is on IPF - and 9 there's no Tru64 anymore) will be someone else's problem.o      John   ------------------------------  # Date: Mon, 03 Dec 2001 04:25:23 GMTV, From: "Paul Dennis" <comedyox@earthlink.not>8 Subject: Re: Using CMS$LIB to create a list of librariesF Message-ID: <T8DO7.15394$Ao6.1323281@newsread1.prod.itd.earthlink.net>  ! <paddy.o'brien@zzz.tg.nsw.gov.au>a   > I cannot agree with this.o  < This is untested but I'm pretty sure it'll show the problem.   $ cre/dir [.cms1]  $ cre/dir [.cms2]h% $ cre a.c,1.c,2.c,3.c,4.c,descrip.mmss main() {} ^Z 1(){}  ^Z 2(){}i ^Z 3(){}t ^Z 4(){}  ^Z a.exe : 1.obj,-n     2.obj,-s     3.obj,-s	     4.obj      link a,1,2,3,4 ^z $ cmsr cre lib [.cms1] "" cre lib [.cms2] "" cre ele/keep %.c "fill cms2" set lib [.cms1]l cre ele %.c "fill cms1"a cre ele/keep descrip.mms ""s set lib [.cms2]o cre ele descrip.mms "" cre class c1 ins gen *.* c1 ""  set lib [.cms1]l cre class c1 ins gen *.* c1 ""u
 reser 1.c,2.ch repl 1.c,2.c "replace in cms 1"  cms cre class c2 ""s ins gen/super 1.c,2.c c2 ""v set lib [.cms1],[.cms2]h& $ mms/from/cms/macr="cmsflags=/gen=c2"  B The build should bomb out saying it can't find class C2 in [.CMS2]  J I'm ready to take a royal kicking on this but the way I see it, I'll learnC something in the process and my life'll be a lot easier afterwards.b  ( If I'm wrong, that is - and I hope I am.   .pd.   ------------------------------  # Date: Sun, 02 Dec 2001 22:38:47 GMTk! From: Ian Parker <parker@gol.com>tU Subject: Re: Why does file access preformance over WAN depend greatly on the command?<& Message-ID: <gPxBqLAW6fC8EwtD@gol.com>  < In article <3c026f81.29477957@news.demon.co.uk>, Jim Johnson4 <Jim.Johnson@software-exploration.nospam.com> writes >Alan, >oA >You've just encountered the SQO optimization for DAP/FAL in RMS.i >oF >SQO (Sequential-only) is a bit set in the FAB on open when the callerE >knows that it will never randomly read a record.  TYPE knows that isoF >the case, and '@' knows it isn't (e.g. handling of GOSUBs and GOTOs). >kE >For the network access, SQO is used to initiate a bulk data transferlG >protocol that doesn't send back any ACK messages until the eof is hit. @ >This means that the server can pack in as many data messages as7 >possible, and just keep sending them until it is done.h >dE >If SQO isn't used, then a much slower protocol that is essentially ac* >request-response pair per record is used. >t% >That's the difference you're seeing.c >e >Fwiw, >Jim.h >i > ? >On 26 Nov 2001 08:17:17 -0800, SPAMSINK2001@YAHOO.COM (Alan E.a >Feldman) wrote: >h >>Hello, >>B >>I have trouble running a command file across the ocean. The file; >>resides on node 1. When I run it on node 1, it runs fine.  >>= >>Node 2 is on the same LAN as node 1. When I run the commandlA >>@NODE1::TO.COM on node 2, it takes longer, but not much longer.1 >>H >>Node 3 is across an ocean. When I log in to node 3 and run the commandD >>@NODE1::TO.COM, it takes much, much longer. But when I TYPE it, it >>only takes a little longer.l >>G >>This is summarized in the following table (times given in hh:mm:ss.ccc
 >>format): >> >>-- >>< >>Command            | Node 1 | Node 2 |  Node 3 | Node 4  |< >>                   | (same) | (LAN)  |  (WAN)  | (LAN)   |< >>                   |        |        |IP tunnel|IP tunnel|< >>-------------------+--------------------------------------8 >>TYPE NODE1::TO.COM |   0.22 |   0.54 |    4.61 |  1.648 >>   @ NODE1::TO.COM |   0.24 |   2.34 | 2:37.97 |  5.42 >> >>(Node 3 is across an ocean.) >>F >>Now, my question is, if it takes only 4.61 seconds to type it acrossH >>the WAN, why does it take more than 157 seconds to execute it when the1 >>normal execution time is only about .2 seconds?s >>G >>The node 4 column represents two nodes that are in the same room, buteE >>on two different IP subnets, connected via a DECnet over IP tunnel.rH >>Apparently, the problem is associated with going overseas via the WAN. >>G >>We are using default DECnet settings. The WAN consists of a shared T1oA >>line and a timeplex at each end. We are using TCPWARE V5.3 withEC >>DECnet-over-IP tunnels. We are running VMS 6.1 and 6.2 and DECnet D >>phase IV, but version mismatches between any two test nodes do not? >>affect this problem. Can anyone explain this and/or make somea" >>recommendations for improvement? >>E >>We have a similar problem with one of our applications. It needs toiG >>open and read an overseas file and it takes much longer than the time E >>it would take to simply copy it over with the DCL COPY command. (IteG >>needs to open for synchronization purposes.) Some of this may have tosF >>do with the application updating other machines, but it appears thatH >>most of it is due to a problem similar to, or the same as, the problem- >>that makes @ take much longer over the WAN.o >># >>Thanks in advance for your help. - >> >>Disclaimer: JMHO >>Alan E. FeldmanM >>afeldman&gfigroup.com< >f >Jim Johnson >Software Exploration, Ltd.o* >(remove '.nospam' from the reply address)  H And the solution that I use, if circumstances permit, is for the commandG procedure to copy itself down to the local node and then run this localfE copy.  It can make a big performance difference for a small amount oft
 extra coding.l   Regardsd   -- e
 Ian Parker   ------------------------------  % Date: Sun, 02 Dec 2001 16:54:22 -0700d+ From: "Barry Treahy, Jr." <Treahy@mmaz.com>b= Subject: Re: why not a communityDeveloped[tm] version of VMS?u' Message-ID: <3C0ABF2E.9050508@mmaz.com>t  & --------------0904070209050304030903019 Content-Type: text/plain; charset=us-ascii; format=flowedo Content-Transfer-Encoding: 7bitt   Volker Kerkhoff wrote:  > >>VMS just works - where's the emotional satisfaction in that? >> >w >volker@pa:~ > uptimeaA >  3:19pm  up 24 days,  7:08,  1 user,  load average: 0.26, 0.12,h >0.04r >o hinj:/var/log# uptime E   4:41pm  up 85 days, 22:42,  1 user,  load average: 0.00, 0.00, 0.00o   V3100$ sh sys/netnM VAX/VMS V5.5-2  on node V3100   2-DEC-2001 16:55:53.50   Uptime  179 08:56:08t   fLinux, Unix, VMS, they are all 'real' operating systems with with real uptime statistics that cannot be reflected by what you see because they numbers like other sites with even larger counts do not represent 'controlled' shutdown decisions or decisions that have nothing to do with the HW, SW, or OS such as complete loss of power and expired UPS batteries.   My W2K server BSOD on my four times last week but even when it isn't fussy, it is still not reliable and I'm lucky if I get two weeks, that is for NT/W2k servers that do more than serve or a file or handle a printer request.   Long ago, the religious wars were over VMS vs. Unix, now it is about real OS's against toys and sadly enough, the toys are winning or have won, depending on how pessimistic one chooses to be.i   Regards,   Barryn      & --------------090407020905030403090301) Content-Type: text/html; charset=us-asciia Content-Transfer-Encoding: 7bit.   <html> <head> </head>  <body> Volker Kerkhoff wrote:<br>H <blockquote type="cite" cite="mid:3C0A3964.2ED4D00@kerkhoff.homeip.net">   <blockquote type="cite">W     <pre wrap="">VMS just works - where's the emotional satisfaction in that?<br></pre>E     </blockquote>      <pre wrap=""><!----><br>volker@pa:~ &gt; uptime<br>  3:19pm  up 24 days,  7:08,  1 user,  load average: 0.26, 0.12,<br>0.04<br><br></pre>s     </blockquote>t     <pre class="moz-signature" cols="$mailwrapcol">hinj:/var/log# uptime<br>  4:41pm  up 85 days, 22:42,  1 user,  load average: 0.00, 0.00, 0.00<br><br>V3100$ sh sys/net<br>VAX/VMS V5.5-2  on node V3100   2-DEC-2001 16:55:53.50   Uptime  179 08:56:08<br> <br>Linux, Unix, VMS, they are all 'real' operating systems with with real uptime statistics that cannot be reflected by what you see because they numbers like other sites with even larger counts do not represent 'controlled' shutdown decisions or decisions that have nothing to do with the HW, SW, or OS such as complete loss of power and expired UPS batteries.<br><br>My W2K server BSOD on my four times last week but even when it isn't fussy, it is still not reliable and I'm lucky if I get two weeks, that is for NT/W2k servers that do more than serve or a file or handle a printer request.<br><br>Long ago, the religious wars were over VMS vs. Unix, now it is about real OS's against toys and sadly enough, the toys are winning  h or have won, depending on how&nbsp;pessimistic one chooses to be.<br><br>Regards,<br><br>Barry<br></pre>     <br>     </body>k     </html>h  ( --------------090407020905030403090301--   ------------------------------   End of INFO-VAX 2001.671 ************************