1 INFO-VAX	Mon, 26 Nov 2001	Volume 2001 : Issue 657       Contents:; Re: "Why Great Companies Fail": Includes DEC (perhaps HP ?) ; Re: "Why Great Companies Fail": Includes DEC (perhaps HP ?)  Re: Comparison of defragmenters  Re: DEC C Error on GS v7.03  Re: dnsquery, Re: DSSI VAXcluster manual on line anywhere? Re: F$GETQUI wildcard bug??  Re: F$GETQUI wildcard bug??  Re: IBM to bid for CPQ ?? 6 Re: IPF Calling Standard (was: ISV's and VMS on Intel)' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me?  Re: Life After Alpha Re: Life After Alpha Marvel is near newsreaders... Re: NTP under TCPIP V5.1@ Re: Of Bogusity and Benchmarketeering (was Re: Life After Alpha)@ Re: Of Bogusity and Benchmarketeering (was Re: Life After Alpha)@ Re: Of Bogusity and Benchmarketeering (was Re: Life After Alpha)" Pawz software and Capacity Planner& Re: Pawz software and Capacity Planner. Re: Server vs. Workstation:  You Make The Call9 Re: Solaris: ready for prime time?  Keep your VMS system. E 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 E 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 E 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 E 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 E 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 E 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 E 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 E 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 E 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 E 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 E 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 E 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 E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org / Re: Using CMS$LIB to create a list of libraries / Re: Using CMS$LIB to create a list of libraries ; Re: VMS on IBM power chip would make IBM No. 1 in high end! ; Re: VMS on IBM power chip would make IBM No. 1 in high end!   F ----------------------------------------------------------------------  # Date: Sun, 25 Nov 2001 19:12:39 GMT * From: "Bill Todd" <billtodd@metrocast.net>D Subject: Re: "Why Great Companies Fail": Includes DEC (perhaps HP ?)A Message-ID: <HobM7.93073$qx2.5872414@bin5.nnrp.aus1.giganews.com>   6 "Jerry Leslie" <leslie@clio.rice.edu> wrote in message! news:9tr8bb$pi3$1@joe.rice.edu...  > From:  > 8 >    http://news.cnet.com/news/0-1003-201-7943716-0.html6 >    Why great companies fail -  Tech News -  CNET.com >  >    By strategy+business  >    Special to CNET News.com $ >    November 25, 2001, 6:00 a.m. PT > 9 >   "The inspiration for Clayton M. Christensen's seminal K >    theory on disruptive technology came from watching Digital Equipment's I >    fall in 1988. How could the management team that had been rightfully I >    lauded for its brilliance by every popular business publication have  >    stumbled so badly?   H Partly because it didn't listen to people who *did* see what was coming.J It's called hubris, and current Compaq management has it in spades (though with far less justification).    > H >    As Digital's star fell, the business press blamed the ineptitude ofH >    the company's management. But Christensen observed that every other5 >    minicomputer company collapsed at the same time.   J Well, yuh:  competing with DEC in minis (vs., e.g., workstations) was hardG enough back then, and if DEC didn't see where it should be heading it's J hardly surprising that others didn't either (or if they did felt unable toL move in that direction before it was 'legitimized' by someone more respectedA in the industry - as, e.g., happened when IBM introduced its PC).     Since no one colludesJ >    to fail, something more was at work. He concluded that the reason forH >    the implosion of the minicomputer industry was not just the rise ofE >    the personal computer, but what the PC represented: a disruptive F >    technology to which the minicomputer companies could not respond.  ; They certainly *could* have responded, they just failed to.    > A >    His theory of disruptive technology became the basis of "The J >    Innovator's Dilemma: When New Technologies Cause Great Firms to Fail"+ >    (Harvard Business School Press, 1997).   > It was indeed a good read (MuLP lent me his copy a while ago).   ...   K >    A company can do all the right things--listen to its customers, invest K >    in research and development, compete aggressively--and yet fall victim G >    to a new technology or business plan that seemed, at first, almost  >    irrelevant.  H If that happens, then by definition the company was *not* 'doing all theI right things':  failing to understand the relevance of something you know I about is incompetent, whereas getting blind-sided by some technology that ; appears out of the blue without warning is merely bad luck.    >  >    [snip]  > E >    Businesses get blindsided because they focus on their best, most I >    profitable customers and ignore other potential markets or customers ! >    seeking lower-cost products.   I Once again, that's not being blind-sided, that's being incompetent.  Andy B Grove has the right viewpoint on this:  only the paranoid survive.   ...   D >    You can invest to create the new growth business while the coreH >    business is still growing, because new business units don't need toI >    get big fast. But when the core business stops growing, investing to 5 >    create new growth businesses becomes impossible.   I Which makes it all the more mystifying why a company would *deliberately* J ignore a core business while that business was still robust and had a goodD deal of growth potential, and instead focus on another core businessK (definitely *not* a 'new' business opportunity) with far less profit and no  greater potential.    To prop up the stock K >    price, managers have to turn down the screws on everybody. That forces H >    them to cancel all the projects that would lead to future growth in, >    order to drop money to the bottom line.  F Yup.  As I've said before, Capellas doesn't seem to have a clue how toC *make* money, he just thinks he knows how to *save* it (but with no G comprehension of the consequences).  This article seems to suggest that I Carly has the same problem, which at least explains why they get along so 1 well (shared incompetence must be a strong bond).     This is HP's dilemma today.I >    Once a company's growth has stopped, the game as we have known it is ! >    over. It's a scary thing..."   G What's scary is the waste of its existing talent and opportunity:  just H because a company has stopped growing doesn't mean it couldn't transform itself with better management.   > J > The statement about "growth has stopped" could also apply to a company's8 > viewpoint about a product, such as Compaq's about VMS.  " Same comment applies here as well.   - bill   ------------------------------  % Date: Sun, 25 Nov 2001 12:15:23 -0800 2 From: "Randy Park" <rjpark@mindspring.nospaam.com>D Subject: Re: "Why Great Companies Fail": Includes DEC (perhaps HP ?)3 Message-ID: <9trjip$i5v$1@nntp9.atl.mindspring.net>   4 Jerry Leslie <leslie@clio.rice.edu> wrote in message! news:9tr8bb$pi3$1@joe.rice.edu...  > From:  > 8 >    http://news.cnet.com/news/0-1003-201-7943716-0.html6 >    Why great companies fail -  Tech News -  CNET.com >  >    By strategy+business  >    Special to CNET News.com $ >    November 25, 2001, 6:00 a.m. PT > 9 >   "The inspiration for Clayton M. Christensen's seminal K >    theory on disruptive technology came from watching Digital Equipment's I >    fall in 1988. How could the management team that had been rightfully I >    lauded for its brilliance by every popular business publication have  >    stumbled so badly?      [snip]  6 I've always felt that one of the major reasons Digital: fell from grace was that it failed to recognized the shift7 in value from hardware to software.  What made Vaxes so : successful in the 1980s was VMS not the computer hardware.% Apple Computer made the same mistake.   6 Making the transition from a company that manufactures7 iron to a company that creates intellectual property is 9 a big step.  One that DEC execs weren't prepared to make. 6 Now the world is stuck with ad hoc software instead of! software that is well engineered.    ------------------------------    Date: 26 Nov 2001 10:09:23 +0800, From: Paul Repacholi <prep@prep.synonet.com>( Subject: Re: Comparison of defragmenters- Message-ID: <87u1vi2sh8.fsf@prep.synonet.com>   ) Rick Dyson <Rick-Dyson@UIowa.EDU> writes:   M > Can/will DFO defragment "open" files?  That is, big database files open for N > both read/write operations by an application.  Files up to multi-GB in size, > filling 40-70% of a disk...   F If the file is open, or has the 'nomove' bit, DFO will leave it alone.D A file that big is not worth trying to defrag, copy it off and back.   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda. @                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Mon, 26 Nov 2001 05:24:59 GMT - From: "Richard L. Dyson" <rickdyson@home.com> $ Subject: Re: DEC C Error on GS v7.03( Message-ID: <3C01D22A.2404B7DD@home.com>   Martin Vorlaender wrote: > . > Richard L. Dyson (rickdyson@home.com) wrote:J > > I am working on getting GS v7.03 working for my OpenVMS systems.  I amK > > using Compaq C v6.4-008 on an OpenVMS/Alpha v7.2-1 system.  I get quite N > > a way into the build when I get the following errors that are entirely new
 > > to me: > [...] @ > > CC/NODEBUG/OPTIMIZE/DECC/PREFIX=ALL/NESTED_INCLUDE=PRIMARY -1 > > /NAME=(AS_IS,SHORT)/DEFINE=("HAVE_MKSTEMP") - J > > /INCLUDE=([.obj] ,[.src]) /OBJECT=[.obj]gdevpdfo.obj  [.src]gdevpdfo.cG > > Assertion failure:  Deleting instruction with DefinesRoutineCtx set  > > Instruction:O > > COD INSTRUCTION  BNE  : NEXT=0109B848, PREV=0109B498, LOCATOR={17224:1-30},  > > S...H > >          DEFINES_ROUTINE_CTX, OPCODE=66, NOT_IN_CURRENT_RTN, OP1=R1, > > OP2=Targ... E > > %GEM-F-ASSERTION, Deleting instruction with DefinesRoutineCtx set + > >       Does anyone have any suggestions?  > D > I haven't seen this before, either. But given the "PEEPHOLE" clue:0 > How does it go if you compile it /NOOPTIMIZE ?  
 Hi Martin,  D 	I did not think very hard on the problem, but with your suggestion,K I ran it manually once with /NoOptimize and it compiled cleanly without any  error.  A 	Now, I just have to figure out how to force that one into the GS < build script without making it true for EVERY source file...  G 	Thanks, now I should be able to continue on until the next problem. :)    Rick   ------------------------------  # Date: Sun, 25 Nov 2001 20:30:40 GMT 3 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk>  Subject: Re: dnsquery / Message-ID: <3C015435.BF32E792@cableinet.co.uk>   6 UCX/TCP IP Services has nslookup, if that is any help.  C $  @sys$startup:tcpip$define_commands  ! Use UCX not TCPIP if V4 or  below  $  nslookup ( Default Server:  server.name.removed.com Address:  a.b.c.d    > www.compaq.com  Server:  server.name.removed.com Address:  a.b.c.d    Name:    www.compaq.com  Address:  161.114.19.252   >    Regards    Michael Austin wrote:  >  > OpenVMS 7.2-1  > TCPIP 5.0A > H > Has anyone ported the unix dnsquery tool to OpemVMS.  It allows one to4 > find out if a particular domain name is available. >  > Thanks > Michael Austin   --   Tim.Llewellyn@cableinet.co.uk     C Standard disclaimer applies. My views in no way represent those of  ! my employers or service provider.    ------------------------------  % Date: Sun, 25 Nov 2001 23:33:17 +0000 1 From: Robert DiRosario <rdirosario@starpower.net> 5 Subject: Re: DSSI VAXcluster manual on line anywhere? - Message-ID: <3C017FBD.C616B51A@starpower.net>    > What do you want to know? / Mostly just looking for additional information.   N I had my 4000/100 open last week and noticed some jumpers on the DSSI card.  I/ assume those set the ID of the DSSI controller.   G I noticed the system board looked a lot like my 3100/90, so I opened my J 3100/90 and found it has the Q-Bus connectors on it!  Did DEC use the same? system board for both system and just install different EPROMS?    Robert   Alfred Falk wrote:  M > Robert DiRosario <rdirosario@starpower.net> wrote in news:3BFD810F.C40802F4  > @starpower.net:  > # > > Is the DEC manual  EK-410AB-MG, 6 > > "DSSI VAXcluster Installation and Troubleshooting"" > > available on the web anywhere? > > 5 > > I just picked up a VAX/VMS 7.1 CD set from e-bay, 9 > > with the documentation CD.  Will it be on the doc CD?  > > 8 > > This is my hobby, so $85 for a manual is a bit high. > > : > > I'm not sure there's any information I need from it  I, > > just found it referenced in the VMS FAQ. > ; > Chances are you don't need it.  What do you want to know?  > B > ----------------------------------------------------------------B >   A L B E R T A         Alfred Falk               falk@arc.ab.caB > R E S E A R C H         Information Systems Dept   (780)450-5185- >   C O U N C I L         250 Karl Clark Road 3 >                         Edmonton, Alberta, Canada ! > http://www.arc.ab.ca/   T6N 1E4 " > http://www.arc.ab.ca/staff/falk/   ------------------------------  % Date: Sun, 25 Nov 2001 19:26:07 -0000 3 From: "Malcolm" <malcolm@neverness.freeserve.co.uk> $ Subject: Re: F$GETQUI wildcard bug??. Message-ID: <9trgfj$5kk$1@news7.svr.pol.co.uk>  ; "Alan E. Feldman" <SPAMSINK2001@YAHOO.COM> wrote in message 7 news:343f30ae.0111241412.7046e47c@posting.google.com...   ! > > > $ <commands using F$GETQUI>  > > > $ SPAWN SHOW QUEUE& > > > $ <more commands using F$GETQUI> > > > 7 > > > This works because it creates a separate process.  > > > L > > Yeah, but I'm just interested in getting the queue name through F$GETQUII > > and nothing else. Spawning would involve the overhead of creating the  > > process  > H > OK, how about $ SPAWN /NOSYMBOLS/NOLOGICALS/NOKEYPAD SHOW QUEUE <blah> > F > It runs more than twice as fast on my box than a plain SPAWN. But it > may still be to slow for you.   % Ah, but no spawning is even faster ;)    >  > From another post of yours: D > > But, I got it working in the end by putting the queue names in aF > > comma-separated list, then working on the list. Until I run into a	 situation B > > where the total list of queue names (and commas) exceeds 2,048 characters,  > > this should work OK. > E > Did you assemble this list using F$GETQUI or did you create them by F > typing? I think you will run into trouble at around 1000 characters, > not 2048.  > K No, it's assembled using F$GETQUI, then a loop picks out each element using 
 F$ELEMENT.  K I am unlikely to actually exceed 2,048 characters... but if I did, I have a  workaround for that:%     - Check length of QLIST variable. 6     - IF (f$length(qlist) + f$length(qname) ).ge. 2046
     - THEN     - Add two commas in a row       - Start new variable QLIST_2  I You can then check for an empty element being returned by F$ELEMENT, then ! switch to the next list variable.t  H > How often do you add, rename, or delete queues? You could perhaps keepH > the queues organized in a database that is updated whenever you changeF > queues. Each database would be a file that has one queue per line in > it for each site.QI Hmmm, yeah. But putting it in the queue is better. If necessary (which it H probably wouldn't be) I could change our applications to check the queueL characteristics and restrict users to queues in their group. [In practice, I) would use ACLs because they're easier...]    > E > Is there a problem with doing all the F$GETQUI calls before runninge
 > SHOW QUEUE?:D No. Works fine if you create a list, then read through it element by element.   >  > Just some more ideas.m >eD 'sokay. Helps to bounce ideas of other people... Anyone tried to use characteristics like this?  L The only problem is that you can't apply characteristics to a generic queue.  I Maybe I could use identifiers and ACLs, then read the ACLs for each queuen! and use the IDENTIFIER portion...  > -- > Disclaimer: JMHO > Alan E. Feldman  > afeldman&gfigroup.com   	 -Malcolm.P   ------------------------------  # Date: Sun, 25 Nov 2001 21:26:15 GMT-3 From: Tim Llewellyn <tim.llewellyn@cableinet.co.uk> $ Subject: Re: F$GETQUI wildcard bug??/ Message-ID: <3C016141.2EBC8BF5@cableinet.co.uk>P   Malcolm wrote: > = > "Alan E. Feldman" <SPAMSINK2001@YAHOO.COM> wrote in messagee9 > news:343f30ae.0111241412.7046e47c@posting.google.com...- > # > > > > $ <commands using F$GETQUI>w > > > > $ SPAWN SHOW QUEUE( > > > > $ <more commands using F$GETQUI> > > > >.9 > > > > This works because it creates a separate process.a > > > >6N > > > Yeah, but I'm just interested in getting the queue name through F$GETQUIK > > > and nothing else. Spawning would involve the overhead of creating thep
 > > > processe > >eJ > > OK, how about $ SPAWN /NOSYMBOLS/NOLOGICALS/NOKEYPAD SHOW QUEUE <blah> > >oH > > It runs more than twice as fast on my box than a plain SPAWN. But it! > > may still be to slow for you.  > ' > Ah, but no spawning is even faster ;)p  G so, as someone else suggested, use F$GETQUI with FREEZE_CONTEXT to graba the infoF you need inside your loop rather than parsing the output of SHOW QUEUE as you are doing now.   regardse -- h Tim.Llewellyn@cableinet.co.uk  r  C Standard disclaimer applies. My views in no way represent those of r! my employers or service provider.    ------------------------------    Date: 26 Nov 2001 11:27:03 +0800, From: Paul Repacholi <prep@prep.synonet.com>" Subject: Re: IBM to bid for CPQ ??- Message-ID: <87d7262ovs.fsf@prep.synonet.com>-  / JF Mezei <jfmezei.spamnot@videotron.ca> writes:r   > cjt wrote:  F > > IMHO, if that is the case, then the industry should thumb its nose
 > > at Intel.   $ > > No sole source should be a goal.  > > Yeah.  Interesting that having more than one source of AlphaC > processors was extremely important for Digital, but Intel, due to.A > its monopoly position doesn't need to be bothered with multiple-' > sourcing of its architectues anymore.o  A Funny to remember that the main reason IBM rejected the 68000 forjC the PC was untel could offer a second source. Does the US Mil stills demand second source for chips?b   -- p< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.r@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------    Date: 26 Nov 2001 10:32:46 +0800, From: Paul Repacholi <prep@prep.synonet.com>? Subject: Re: IPF Calling Standard (was: ISV's and VMS on Intel) - Message-ID: <87pu662re9.fsf@prep.synonet.com>m  , John Reagan <john.reagan@compaq.com> writes:  E > This is the same logic that lead us to use ELF/DWARF as object fileb	 > format.a  ? So we lose the stuff in the VMS obj formats? Or will you extendn ELF to fill the gaps?   @ Where is the logic in this btw? This means re-visiting the image2 activator and the security fun that that involves.   -- b< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.m@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------    Date: 26 Nov 2001 11:02:10 +0800, From: Paul Repacholi <prep@prep.synonet.com>0 Subject: Re: Is it a DEC C problem, or is it me?- Message-ID: <87heri2q19.fsf@prep.synonet.com>B  ) David Mathog <mathog@caltech.edu> writes:d  A > The flip side also occurs.  A couple of days ago I ran into theeF > strangest thing I've ever seen a compiler do.  The free command line@ > version of the Borland C/C++ compiler for windows was throwingD > dozens of warnings about unused variables (this on a piece of codeD > that compiles and runs essentially everywhere else without so muchC > as a warning, including on Windows with other compilers.)  All ofh= > these warnings went away when all optimization was disabledeF > completely.  That was strange enough that I gave up on that compiler. > right then and there (Cygwin worked anyway.)  > Not that strange if you consider that with the /noopt compile,; the compiler did not have the information to determine thata the variable was not used. s   -- -< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.t@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Mon, 26 Nov 2001 15:10:26 +0010 ' From: <paddy.o'brien@zzz.tg.nsw.gov.au> 0 Subject: Re: Is it a DEC C problem, or is it me?5 Message-ID: <01KB5X7V8QS2000R2T@tgmail.tg.nsw.gov.au>    Paul Repacholi wrote:r  * >David Mathog <mathog@caltech.edu> writes: >cB >> The flip side also occurs.  A couple of days ago I ran into theG >> strangest thing I've ever seen a compiler do.  The free command line A >> version of the Borland C/C++ compiler for windows was throwingsE >> dozens of warnings about unused variables (this on a piece of codeeE >> that compiles and runs essentially everywhere else without so muchtD >> as a warning, including on Windows with other compilers.)  All of> >> these warnings went away when all optimization was disabledG >> completely.  That was strange enough that I gave up on that compilers/ >> right then and there (Cygwin worked anyway.)n >l? >Not that strange if you consider that with the /noopt compile, < >the compiler did not have the information to determine that >the variable was not used.     M The Fortran compilers on VAX (old) and Alpha both have no problems issuing a rQ warning regarding unused variables on /opt=level=0.  The compiler should be able  K to create its internal cross reference regardless of the optimisation, and a thence ascertain unused status.   J David, I would assume that all these compilers are capable of giving this N warning.  It's just a case of what the default behaviour is (Alpha Fortran it K has to be turned on, whereas VAX is on by default),  there is presumably a dI qualifier (switch) something like /warn=nounused.  Strange that there is  H different behaviour for optimised or not (unless Paul is correct in his M statement for that compiler).  And it is just a warning so you should have a a compilation.  O We like to see these warnings to remove the variables.  Decreases the verbiage sQ of the declaration area.  For us, these have tended to arise as code is modified e> over the years and some functionality moved to another module.   Regards, Paddy   ------------------------------  % Date: Sun, 25 Nov 2001 14:35:15 -0800-' From: David Mathog <mathog@caltech.edu>1 Subject: Re: Life After AlphaP+ Message-ID: <3C017223.BD6C0D7F@caltech.edu>:   "Terry C. Shannon" wrote:l  M > Compaq *does* have an alternate plan, sort of. EV78 is in production today,tI > early EV78 silicon powers the 32-way Marvel boxes CPQ is fooling around$N > with. EV79 is just a process shrink. The E7 generation could be re-spun into5 > EV710 and perhaps EV711 if the need arose to do so.-    D Which sounds an awful lot like the series of stopgap measures HP has been resorting to C with it's PA-RISC architecture ever since it got into bed with (ande caught something nasty from) Intel.   Regards,   David Mathog mathog@caltech.edu   ------------------------------  # Date: Mon, 26 Nov 2001 02:00:25 GMTt- From: Terry C Shannon <shannon@world.std.com>  Subject: Re: Life After AlphavC Message-ID: <Pine.SGI.4.30.0111252100010.7295-100000@world.std.com>   ( On Sun, 25 Nov 2001, David Mathog wrote:   > "Terry C. Shannon" wrote:z >tO > > Compaq *does* have an alternate plan, sort of. EV78 is in production today, K > > early EV78 silicon powers the 32-way Marvel boxes CPQ is fooling aroundsP > > with. EV79 is just a process shrink. The E7 generation could be re-spun into7 > > EV710 and perhaps EV711 if the need arose to do so.e >a >EF > Which sounds an awful lot like the series of stopgap measures HP has > been resorting tooE > with it's PA-RISC architecture ever since it got into bed with (anda > caught something > nasty from) Intel. >p   Ah, you noticed that too! ;-}u   ------------------------------  % Date: Mon, 26 Nov 2001 07:52:31 +0100n) From: "Pio Baettig" <baettig@hotmail.com>E Subject: Marvel is nearl+ Message-ID: <3c01e5dc@siufuxsun02.unifr.ch>a   Hi# I just found the following article.p$ It leaves open one question however:2 Will EV7 really "only" be an EV68 core with 1.75MB/ of L2 cache or am I misunderstanding something?    Piol   From: ' http://www.theinquirer.net/25110106.htmn pictures are there "f! Compaq's Alpha Marvel a Ramboosta     Fourteen days left in motor city% By Eva Glass, 25/11/2001 13:04:53 BST 9 "The hunter gets captured by the game " - The Marvelettes K THE TALEBAN are reduced to cowering in the Stygian blackness of the deepesteD and most remote caverns that lie beneath the inhospitable terrain of Afghanistan.6 Compaq moles have to hide underground too, these days.L But, every once in a while, both terrorists and moles must surface. And thatH was the case in the foothills of the American Rocky Mountains during theK recently-concluded Supercomputing 2001 high performance technical computingr8 conference in Denver, CO, writes Eva Glass in Las Vegas.F Defying Taliban artillery and Hellfire-equipped Predator UAVs from theL Compaq Intelligence Agency (CIA), our mole surfaced from her Denver boltholeJ to share with INQUIRER readers what appears to be the most detailed Marvel slideware seen to date. J The mole uploaded the slide to Qapellas One, stationed over Houston, whichI then transmitted the data to Crypto-Qapellas Two, in geo-stationary orbit  over the INQUIRER bunker.e   Eva's X-Ray SpexK This - as hacks love to say - has been long-awaited. The AlphaServer Marvel L EV7 family sweeps from the desktop to the data centre and uses the Alpha EV7: microchip, has IO7 support chips and Rambus memory arrays.J What is IO7? It translates traffic on the IO bus either one AGP or AGP/Pro' 4X bus and to three PCI or PCI-X buses.eI The whole purpose of the EV7 Marvel is so that if you want a uniprocessor K system at what Compaq calls low-cost but which you can expect to pay an ARMdK and a LEG for, or a four way SMP (symmetric multiprocessing system) or event6 a 128 way system, you can have it. At the right price.I As we have reported earlier this year, the EV7 includes an EV68 chip corei2 and 1.75MB of level two cache in the same package.  L It uses both Rambus memory and controllers and has a switched fabric so thatK it can be connected to another four EV7 chips as well as the system IO bus. J Q will introduce a two way tower system it calls the Marvelette which willJ support up to 32GB of error correcting memory per MPU, include support forH five PCI-X/PCI slots, and one AGP 4X slot, two internal hot plug drives,J support for two hot plug disk drives, a remote power management system and support for N+1.K You can build an 8-way Marvel system from this system's building blocks andd( have up to eight AGP slots and the rest./ A 16 way system is built up using 8-way blocks. K There's also a 128-way model supported - called MarvelMax - which builds onp two 64-way GS640 systems.lL Compaq is offering upgrades from its DS series to its MarvelRack system, andJ has ambitious plans to move its ES series to MarvelOffice systems with its> high end AlphaServer GS jumping to a Marvel Enterprise system.K Perhaps not totally amazingly, the chassis, system drawers and the like are- Proliant compatible.  "0   ------------------------------  # Date: Mon, 26 Nov 2001 06:00:11 GMTu" From: Rotten178 <bdjr76@yahoo.com> Subject: newsreaders...-) Message-ID: <3C01DA46.315BC3FC@yahoo.com>   D Grr... I'm looking for a good newsreader for OpenVMS. Anyone got any/ suggestions or somewhere to even start looking.c  C I did a search on Google but all the links I visited were all dead.S   -- o3 SCHIZAM and it happens, not with a bang but with a e whisper.   ------------------------------  # Date: Sun, 25 Nov 2001 21:47:52 GMT ) From: martin.hunt@inl.co.nz (Martin Hunt) ! Subject: Re: NTP under TCPIP V5.1P6 Message-ID: <3c015e62.5956174@news.wlg.netlink.net.nz>  D On Fri, 23 Nov 2001 20:02:21 +0100, Michael Joosten <joost@c-lab.de> wrote:   >Martin Hunt wrote:C >> aG >> I have recently upgraded a VAX from TCPIP services V4.2 to V5.1 (ECO > >> 3). NTP was working fine before, but now is having problemsC >> synchronising with an NTP server. The log file doesn't give muchlH >> information compared with the old version, but when I set the logical@ >> TCPIP$NTP_LOG_LEVEL to 6, I get heaps of messages, including: >> m> >> invalid packet header 202.36.63.50 0x80 0.098969 453.170639 >> rI >> Occasionally, the VAX manages to synchronise, but more often it fails.- >> -F >> The "peer" command in the ntpq program shows the following, which II >> presume means it hasn't been able to contact the server (documentationyB >> is a bit poor on this, and makes reference to a unix manual for >> further information!).  >>  I >>      remote           refid      st t when poll reach   delay   offsetw >> dispaQ >> ==============================================================================0H >> 202.36.63.50    0.0.0.0         16 u   26   64    0     0.00    0.000
 >> 16000.0 >> b >?G >reach(ability) 0 means that there were no response from the server forAD >more than 8 times the poll rate (64 seconds). The 'reach' figure isH >actually an octal bit mask that is shifted once a response comes in, soD >377 shows perfect connectivity, 177 that the last response has been >missed and so on. > F >This looks like a protocol version conflict. Do you know what type ofI >NTP proto version your NTP server uses? Perhaps you could change the NTPw >config on your VMS box to readt  B I am trying to synchronise with another VAX running TCPIP services@ V4.2. That in turn synchronises quite happily with an ntp serverD running on NT4. I have also tried synchronising directly with the NT4 server, which work occasionally but usually doesn't. >r >server 202.36.63.50 version 2 >,7 >instead? (or was it '3' or '1' instead, I'm not sure).n  E I have tried the version keyword (with both version 1 and version 2),a# but it doesn't make any difference.t  F The stratum should be fine - the other VAX reports itself as a stratumC 2 server. (Or is it reporting the NT server as stratum 2 - it's notc clear from the log?).g     ---  Martin Hunti Systems Administrator0 Independent Newspapers Limited
 Wellington New Zealandg   ------------------------------  # Date: Sun, 25 Nov 2001 20:44:05 GMTu& From: "Jeff Killeen" <Jeff@IDM-IO.com>I Subject: Re: Of Bogusity and Benchmarketeering (was Re: Life After Alpha) 8 Message-ID: <pKcM7.2469$3n6.170319@typhoon1.gnilink.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in message ; news:Ae9M7.92132$qx2.5751781@bin5.nnrp.aus1.giganews.com...a  K > I suggest that Compaq seems to have missed the fact that *not* continuingiH > efforts past EV7 *also* appears not to be economically prudent.  I.e., thatG > in toting up the numbers it neglected to evaluate the impact on salesnK > (especially during the period when Alpha's operating systems were not yet J > available on Itanic) that the Alphacide would have.  Given that the cost ofB > continued development, even as stated by Compaq, would have been
 relativelyG > minor compared with the profits that Alpha had until the announcementnI > returned, that appears to have been a decisive error (or indicates thata thel: > decision was driven by issues other than economic ones).  J Will never know the impact now because of the FUD the HP merger introduced into the data...   ------------------------------  # Date: Sun, 25 Nov 2001 21:17:20 GMTl* From: "Bill Todd" <billtodd@metrocast.net>I Subject: Re: Of Bogusity and Benchmarketeering (was Re: Life After Alpha)e< Message-ID: <AddM7.39775$YD.3403038@news2.aus1.giganews.com>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messagep2 news:pKcM7.2469$3n6.170319@typhoon1.gnilink.net... > 7 > "Bill Todd" <billtodd@metrocast.net> wrote in message-= > news:Ae9M7.92132$qx2.5751781@bin5.nnrp.aus1.giganews.com...  > B > > I suggest that Compaq seems to have missed the fact that *not*
 continuingJ > > efforts past EV7 *also* appears not to be economically prudent.  I.e., > thatI > > in toting up the numbers it neglected to evaluate the impact on sales4I > > (especially during the period when Alpha's operating systems were notI yet L > > available on Itanic) that the Alphacide would have.  Given that the cost > ofD > > continued development, even as stated by Compaq, would have been > relativelyI > > minor compared with the profits that Alpha had until the announcementnK > > returned, that appears to have been a decisive error (or indicates that  > the < > > decision was driven by issues other than economic ones). > L > Will never know the impact now because of the FUD the HP merger introduced > into the data...  I Given that *most* of Q3 had passed before the announcement, I suspect the J impact could easily be measured if anyone in Compaq wished to and is to at* least some degree visible even externally.   - bill   ------------------------------  # Date: Sun, 25 Nov 2001 21:39:58 GMTl& From: "Jeff Killeen" <Jeff@IDM-IO.com>I Subject: Re: Of Bogusity and Benchmarketeering (was Re: Life After Alpha)v8 Message-ID: <OydM7.2524$3n6.169173@typhoon1.gnilink.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in messagee6 news:AddM7.39775$YD.3403038@news2.aus1.giganews.com...K > Given that *most* of Q3 had passed before the announcement, I suspect thetL > impact could easily be measured if anyone in Compaq wished to and is to at, > least some degree visible even externally.  K There was a drop off in the VAX business after the Alpha announcement. What L we will never know is what the recovery would have been absent the HP merger( announcement.  The data is contaminated.  H If we used your logic of observing the first post quarter result at this? point in time the Alpha announcement would have seen foolish...h   ------------------------------  # Date: Mon, 26 Nov 2001 02:53:32 GMTi* From: John Polcari <JPolcari@Mediaone.net>+ Subject: Pawz software and Capacity Planner + Message-ID: <3C01AF00.1060403@Mediaone.net>   H I am shopping around for some performance tools that might help make my G job a little easier, does anybody know and would recommend a goof peice G of software that runs on a Alpha Openvms system, running 7.1 of VMS. I  E was checking out Capacity Planner and also pawzs, are these products m* worth pursuing or should I look elsewhere?   Thanks,I JOhn   ------------------------------  % Date: Mon, 26 Nov 2001 04:18:00 -0000r= From: "David McKenzie" <david.mckenzie@spitfire0.demon.co.uk>:/ Subject: Re: Pawz software and Capacity PlannerEB Message-ID: <1006748276.19142.0.nnrp-12.c1edba74@news.demon.co.uk>  L Don't pursue PAWZ, is my personal experience. It is no where near as capableL as DECps, and may even be dead. DECps still seems to be the best product out@ there, even if it is owned by the anti-christ (CA with dyslexia)   -- David McKenzie Charon Consulting (Australia) ( david.mckenzie@mig.spitfire0.demon.co.uk   (But who wants a Mig?)   ! 7 "John Polcari" <JPolcari@Mediaone.net> wrote in messagel% news:3C01AF00.1060403@Mediaone.net... I > I am shopping around for some performance tools that might help make my-I > job a little easier, does anybody know and would recommend a goof peiceoH > of software that runs on a Alpha Openvms system, running 7.1 of VMS. IF > was checking out Capacity Planner and also pawzs, are these products, > worth pursuing or should I look elsewhere? >o	 > Thanks,I > JOhn >h   ------------------------------    Date: 26 Nov 2001 07:36:58 +0800, From: Paul Repacholi <prep@prep.synonet.com>7 Subject: Re: Server vs. Workstation:  You Make The Calle- Message-ID: <87bshq4e3p.fsf@prep.synonet.com>m  ) Rick Dyson <Rick-Dyson@UIowa.EDU> writes:t  F >     For the purposes of licensing the Compaq CSLG/ESL, they define a2 > "system" as a server *OR* five (5) workstations.  iC >     Can anyone help me "officially" clarify whether the followinguA > Digital/Compaq hardware are either a 'server' or 'workstation'?   2 The ruke is (was) if it has a video, it is a WS.   >     DEC 3000/400 >     Alpha 3000/500 >     XP1000
 >     ES45 >     ES40 68/833w  C So shove a PCI S3 in there! All of them where sold both as servers,C and as WSs.     >     uVAX 3300   < I think even with a dragon in there, this one is a server...   --  < Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.a@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------    Date: 26 Nov 2001 10:03:57 +0800, From: Paul Repacholi <prep@prep.synonet.com>B Subject: Re: Solaris: ready for prime time?  Keep your VMS system.- Message-ID: <87y9ku2sqa.fsf@prep.synonet.com>I  / koehler@encompasserve.org (Bob Koehler) writes:   / >   After all, Solaris is a modern UNIX, right?o  7 RIGHT, now, what is the 4 letter word in that sentence?l   -- s< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.g@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  % Date: Sun, 25 Nov 2001 14:50:00 -0500c( From: Bill Gunshannon <bill@cs.uofs.edu>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.orgB Message-ID: <20011125144639.V13614-100000@server2.cs.scranton.edu>  + On Sun, 25 Nov 2001, Terry C Shannon wrote:s   >r >l- > On Sun, 25 Nov 2001, Bill Gunshannon wrote:e > 1 > > On Sun, 25 Nov 2001, Joann Difrancesco wrote:f > >o > > >tP > > > Mr. Fenwick is a senior system architect, not a marketing droid, hence his? > > > absence from this forum shouldn't be all that surprising.a > > >h > >eN > > Do I take it then that you see Hoff as a marketing-droid??  (Or any of the0 > > other Compaq worker-bees who frequent here!) > >c >sL > Nothing in Ms. DiFrancesco's assertion would seem to me to be an aspersionG > against Hoff or any of the other CPQ technical folks who take it uponmG > themselves to participate in this forum... usually on their own time. G > Anyone who knows Hoff knows that Hoff is not a marketing droid. 'Nuffb > said.f >e   Terry,I    Far be it from me to denigrate Hoff, he's one of the most knowledgableeK VMS gurus I have ever had contact with and has helped me in many instances.-  K    I read the above to say anybody who was not a marketing-droid should nota be expected to be here.h   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   |> Scranton, Pennsylvania   |         #include <std.disclaimer.h>   ------------------------------  # Date: Sun, 25 Nov 2001 14:52:58 GMTi& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org7 Message-ID: <eB7M7.1535$zf.140266@typhoon2.gnilink.net>i  5 "Paul Sture" <paul.sture@bluewin.ch> wrote in messagei' news:VA.000004cb.9559044c@bluewin.ch...n  K > But we've moved on from that model. If a change of chip means porting, it- is no H > longer true that customers only look at "server to server for the same > dollars".  >jF > Want a real life example? We have an application which we considered portingwG > from VMS a couple of years ago. The estimated cost came in at several  millionwJ > dollars, although the project leader told me it could easily run to much moreE > than that due to the application's complexity. So it stayed on VMS.s >oJ > Force us to port it due to a different chip and yes, we might well spend tensE > of millions doing that (think testing, testing, testing, as well as  developmentc > and more testing).  K Paul I agree with the above but where you lost me is what you said below...A  = > However if we feel _forced_ to port by Compaq/HP decisions,tF > you can bet a large chunk of that sum we are going to go Sun / IBM / whatever" > else is available at that point.  G If the port to the next generation Compaq server is nothing more than auG source code compile why would Sum/IBM factor in which would trigger thei5 painful port you have outlined as being unacceptable?o  B > So from the perspective as a customer with a heavy investment in applications( > which satisfy our business needs today  J We strongly agree and if you read my earlier postings a key factor here isJ preservation of the existing application base.  If Compaq fails to deliverH on its "Golden Blanket" program I would fully agree a Sun/IBM port is inL order.  But if they do deliver it would seem to me that the only cost of the port is a recompile...   ------------------------------  # Date: Sun, 25 Nov 2001 20:16:05 GMTf& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org7 Message-ID: <9kcM7.1663$zf.152659@typhoon2.gnilink.net>f  5 "Bill Todd" <billtodd@metrocast.net> wrote in messaged; news:N88M7.116892$dk.8572547@bin1.nnrp.aus1.giganews.com... H > I have not heard much yet about post-Marvel plans, so can't comment inH > detail (pointers to information would be appreciated).  It's certainly easyG > to understand that *if* one is given the edict from above (or somehowRK > concludes from a brain-fart of one's own) that a server architecture musteK > accommodate both Alpha and Itanic processing components, then the abilityh toJ > take advantage of Alpha's strengths is significantly crippled and use ofG > Alpha processors may indeed not provide the performance boost that it  couldeD > in an architecture better tailored to take advantage of it.  That, however,L > just calls the premise into question rather than validates the conclusion.  L Or maybe the decision was made to use a common server architecture to try toF save the economic viability of Alpha.  If Alpha had to go it alone the7 economic death knell would have been sounded earlier...s   ------------------------------  # Date: Sun, 25 Nov 2001 20:31:13 GMTy& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org7 Message-ID: <lycM7.1668$zf.153390@typhoon2.gnilink.net>y  5 "David Froble" <davef@tsoft-inc.com> wrote in messagee& news:3C011B3F.4060602@tsoft-inc.com...H > Could you explain how being 'ex' and 'bitter' make anyone more or less > 'right' or 'wrong'?o  F It makes their judgement questionable because their analysis is highlyI emotional - you can see it dripping throughout the postings.  Add to thatBK taking a very strong public position for a protracted period of time and itsK becomes difficult to objectively step back.  Finally add to that not havinggG any vested economic interest being neither a current Compaq customer or - having an installed base of VMS applications.e  F But what really calls the "right" or "wrong" of recent statements intoK question was the recent admission that little was known about future serveroI designs beyond the current Alpha products.  If one is trashing Compaq allpL over all the place for its business decision one should fully understand theL design direction of the entire server and not just the chip.  The first timeL I saw the Quick Blade design one of the first questions I asked was couldn'tI someone just plug more blades in to equal the power of Alpha.  Now that IlG see there wasn't a clue about where server design was heading the false0G logic that was used to make many statements can be seen,.  The logic ise2 still false but the thought process is revealed...   ------------------------------  % Date: Sun, 25 Nov 2001 15:58:18 -0500r- From: JF Mezei <jfmezei.spamnot@videotron.ca>eN Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org, Message-ID: <3C015B69.1DD6AC70@videotron.ca>   Bill Todd wrote:H > I have not heard much yet about post-Marvel plans, so can't comment in8 > detail (pointers to information would be appreciated).  M But isn't it a given that there won't be post marvel follow-ons ? Once EV7 is2I out, Compaq isn't going to improve Alpha except for a few speed bumps andtG after that, Compaq will only produce wintel servers which, until NT can2L actaully take advantage of wildfire type systems, will be just more replicas of existing servers.  7 At the current of losses, how long can Compaq survive ?a   ------------------------------  % Date: Sun, 25 Nov 2001 16:15:25 -0500P- From: JF Mezei <jfmezei.spamnot@videotron.ca>dN Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org, Message-ID: <3C015F6B.5872D6B6@videotron.ca>   Jeff Killeen wrote:fI > If the port to the next generation Compaq server is nothing more than a,I > source code compile why would Sum/IBM factor in which would trigger thee7 > painful port you have outlined as being unacceptable?o  N Be careful. As time progresses, all sort of little annoying facts will prop upN which may not make it a simple recompile.  Consider that VAX-C support will beN dropped. Consider that VAXes in in IA64 cluster may not be supported. How manyK more of these tidbits will come out of the woodwork between now and the day & where Compaq wants you to drop Alpha ?   ------------------------------    Date: 26 Nov 2001 04:03:16 +0800, From: Paul Repacholi <prep@prep.synonet.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org- Message-ID: <87snb24nzv.fsf@prep.synonet.com>e  ( "Jeff Killeen" <Jeff@IDM-IO.com> writes:  7 > "Bill Todd" <billtodd@metrocast.net> wrote in messageP= > news:S8XL7.85804$qx2.5290221@bin5.nnrp.aus1.giganews.com...h  A > > >  It was Fenwick's team that came to the conclusion that thee< > > > Alpha based follow-on to the Wildfire wouldn't offer aA > > > sufficient performance advantage over the IA64 servers thate  > > > Compaq is also developing.   > > Wrongo.e  F > Given the choice between believing a self-admitted bitter ex-DigitalF > employee and a the chief designer of the TurboLaser and the WildfireF > I will take the word of Mr. Fenwick.  Rather than pointless debate IB > will trust readers to make up their own mind as to who is a more > credible source...  F I have also been told the same by previous and current VMS engineering and Alpha engineering people.r  6 Sorry I don't qualify as a bitter ex-Digital employee.   -- n< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.4@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------  # Date: Sun, 25 Nov 2001 21:15:12 GMTq* From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.orgA Message-ID: <AbdM7.94305$qx2.5969798@bin5.nnrp.aus1.giganews.com>I  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messageo1 news:lycM7.1668$zf.153390@typhoon2.gnilink.net...g   ...r  H > But what really calls the "right" or "wrong" of recent statements intoF > question was the recent admission that little was known about future server, > designs beyond the current Alpha products.  K By all appearances I know, or at least understand, the yet-to-appear MarvelnI generation of products better than you do, so once again you seem to haveaC missed that next generation completely and moved directly on to the H as-yet-completely-vaporous Blade product set (though given your apparentL level of technical expertise assuming that you actually understand the plans7 for those products in any real sense would seem risky).>     If one is trashing Compaq allhJ > over all the place for its business decision one should fully understand thes> > design direction of the entire server and not just the chip.  I Understanding the advantages Alpha offers in Marvel takes one out to 2005oK (since that's the earliest that Intel can bring to market a version of IA641H that could even compete with EV7 and thus substitute for it in a 'blade'L product, let alone offer what EV8 would have).  Since Intel's IA64 road mapsK don't extend that far out, it seems just a tad over-confident to base one'ssK company's entire future on committing to those yet-to-be-defined (let alonerI designed) processors rather than, say, a design as well under way as EV8.)     The first timeE > I saw the Quick Blade design one of the first questions I asked was  couldn't? > someone just plug more blades in to equal the power of Alpha.   K Ah, yes.  Sounds like the same kind of 'logic' that leads a bean-counter totG believe that products are interchangeable or management to believe thats people are.s  J Without attempting to imbue you with the technical education you so sorely= lack, I'll simply point out the fallacy of suggesting that 2N K half-performance processors can equal the performance of N full-performancecL processors on any work-load that does not partition into some multiple of 2NE roughly equal and nearly-independent tasks - even with zero switching-L overhead (which I suspect has not yet been achieved).  And the added expenseK of having twice as many 'blade' boards (and commensurately larger switches)p. because each one has only half the capability.     Now that II > see there wasn't a clue about where server design was heading the falseYI > logic that was used to make many statements can be seen,.  The logic isb4 > still false but the thought process is revealed...  J There is nothing inherent in the design of a 'blade' system that prohibitsK it from leveraging the strengths of EV7 and EV8 - unless it's crippled withtE the requirement of supporting IA64 as well (rather than making that arH separate product even if using similar technology - assuming that such aJ product would have a market given the superiority of the Alpha-based one).J So the logic that invites questioning is the decision to do so rather thanB take advantage of Alpha's current and easily-continued leadership.   - bill   ------------------------------  # Date: Sun, 25 Nov 2001 21:33:52 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org7 Message-ID: <4tdM7.1687$zf.155977@typhoon2.gnilink.net>u  5 "Bill Todd" <billtodd@metrocast.net> wrote in messagep; news:AbdM7.94305$qx2.5969798@bin5.nnrp.aus1.giganews.com...CL > Without attempting to imbue you with the technical education you so sorely? > lack, I'll simply point out the fallacy of suggesting that 2N-< > half-performance processors can equal the performance of N full-performanceK > processors on any work-load that does not partition into some multiple ofe 2N, > roughly equal and nearly-independent tasks  4 Don't put words in mouth - I have never said that...   ------------------------------  # Date: Sun, 25 Nov 2001 21:52:56 GMTe& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org7 Message-ID: <YKdM7.1689$zf.156979@typhoon2.gnilink.net>c  5 "Bill Todd" <billtodd@metrocast.net> wrote in message); news:AbdM7.94305$qx2.5969798@bin5.nnrp.aus1.giganews.com...gL > Without attempting to imbue you with the technical education you so sorely? > lack, I'll simply point out the fallacy of suggesting that 2Nd< > half-performance processors can equal the performance of N full-performanceK > processors on any work-load that does not partition into some multiple ofn 2NG > roughly equal and nearly-independent tasks - even with zero switchingeF > overhead (which I suspect has not yet been achieved).  And the added expenseNC > of having twice as many 'blade' boards (and commensurately larger 	 switches):0 > because each one has only half the capability.  ; Bill someone suggested via Email I ask you this question...D  K Please share with us your understanding of Compaq's QuickBlade strategy and/K in particular how the environment will handle work load.  For you to making L statements like you are making you must have a keen understanding has to howJ QuickBlade will handle work loads.  Please note I said QuickBlade strategy and didn't said Server or OS...    ------------------------------  # Date: Sun, 25 Nov 2001 22:14:13 GMT * From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.orgA Message-ID: <V2eM7.94807$qx2.6012891@bin5.nnrp.aus1.giganews.com>-  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messagee1 news:YKdM7.1689$zf.156979@typhoon2.gnilink.net...  > 7 > "Bill Todd" <billtodd@metrocast.net> wrote in message = > news:AbdM7.94305$qx2.5969798@bin5.nnrp.aus1.giganews.com...aG > > Without attempting to imbue you with the technical education you sob sorelyA > > lack, I'll simply point out the fallacy of suggesting that 2Nr> > > half-performance processors can equal the performance of N > full-performanceJ > > processors on any work-load that does not partition into some multiple of > 2NI > > roughly equal and nearly-independent tasks - even with zero switchingeH > > overhead (which I suspect has not yet been achieved).  And the added	 > expense E > > of having twice as many 'blade' boards (and commensurately larger9 > switches) 2 > > because each one has only half the capability. > = > Bill someone suggested via Email I ask you this question...- >eI > Please share with us your understanding of Compaq's QuickBlade strategye andwF > in particular how the environment will handle work load.  For you to makingJ > statements like you are making you must have a keen understanding has to howdL > QuickBlade will handle work loads.  Please note I said QuickBlade strategy! > and didn't said Server or OS...d  L As I indicated elsewhere, I don't know any details about it, though 'blades'E have been mentioned enough that one can infer some things about theircI character.  As I also said elsewhere, I'd welcome information about where H Compaq's particular 'blade' approach is documented and would be happy to* comment in more detail after I've read it.  F The comments I made above, however, are generic to all multi-processorH systems (even SMP, though ccNUMA seems to be getting hard to avoid theseJ days and I suspect is at least as much a part of Compaq blades as it is of1 the current Wildfire and future Marvel products).k   - bill   ------------------------------  # Date: Sun, 25 Nov 2001 22:22:53 GMT * From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org@ Message-ID: <1beM7.55105$8q.9089312@bin2.nnrp.aus1.giganews.com>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messages1 news:4tdM7.1687$zf.155977@typhoon2.gnilink.net...w >n7 > "Bill Todd" <billtodd@metrocast.net> wrote in messageh= > news:AbdM7.94305$qx2.5969798@bin5.nnrp.aus1.giganews.com...mG > > Without attempting to imbue you with the technical education you soi sorelyA > > lack, I'll simply point out the fallacy of suggesting that 2Na> > > half-performance processors can equal the performance of N > full-performanceJ > > processors on any work-load that does not partition into some multiple of > 2N. > > roughly equal and nearly-independent tasks >w6 > Don't put words in mouth - I have never said that...  K A statement worthy of a Compaq lie.  Indeed, you never said *exactly* that:V what you said was:  I "The first time I saw the Quick Blade design one of the first questions IeI asked was couldn't someone just plug more blades in to equal the power of  Alpha."   H If you can't see the concept-equivalence between the two statements, I'mB sure others can.  In particular, the case of N = 1 is particularlyH interesting for a single-threaded application, since you can't equal theE performance of an Alpha no matter *how* many Itanics you throw at theaG problem (and by induction similar problems occur for higher values of N 0 where the load is not cleanly 2N-partitionable).   - bill   ------------------------------  # Date: Sun, 25 Nov 2001 20:07:21 GMTa& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org8 Message-ID: <ZbcM7.2433$3n6.167785@typhoon1.gnilink.net>  I Folks - If you are reading few of the postings in this thread please readn this one...t  5 "Bill Todd" <billtodd@metrocast.net> wrote in messageo: news:b08M7.54525$8q.8866035@bin2.nnrp.aus1.giganews.com...  K > Jeff has no clue about this area.  The 'follow-on' to Wildfire is Marvel,u  J It as a typo Bill but bitter people react this way - I understand - moving on...s  F > And (to address some FUD from another portion of the discussion) theC > suggestion that Itanic-based servers will be able to offer bettergJ > cost/performance metrics than Alpha-based servers holds no water either.I > Not only will it take something like twice as many Itanic processors to J > provide equivalent performance (and server prices usually rise more thanJ > linearly with the number of processors, due to the added effort required toL > glue them together effectively - *especially* lacking the kinds of on-chipJ > support that EV7 provides but Itanic does not), but the price differenceJ > between an N-processor Alpha box and an N-processor Itanic box (offeringG > dramatically less capability) should be minimal for anything but very5 small.I > values of N, because processor prices (assuming that Itanic's ever *do*l comeG > down) just don't contribute much to the cost of a mid-range or largerd	 > server.r  F Well well well - at long last Todd acknowledges that the IA64 could be4 configured to provide the same performance as Alpha.  J Folks more than anything else the above argument from Todd should make you9 question his fundamental understanding of this subject...o  H 1) What drives the costs of this class of server is NOT the actual chipsF used in the box but the R&D costs.  The actual cost to manufacture the+ server is a fraction of what they sell for.e  J 2) If you look at the number of N-Processor Alpha servers Compaq sells andI compare that to the number of N-Processor Proliant boxes Compaq sells yousI quickly realize to potential spread R&D costs over a much larger base - ah6 larger base than most, it not all, of its competitors.  L 3) Compaq is moving to QuickBlade servers with InfiniBand fabric. The designK is very much optimized to allow the easy addition of CPU power.  You shouldeD be able to get a NDA presentation from your salesperson on the firstL generation of QuickBlade servers.  (BTW Compaq sells more dense rack serversI than HP, Dell, and Sun combined today).  The QuickBlade servers today areo only the first step.  G 4) Compaq is going to have to sink the R&D dollars into developing hightH performance N-Processor IA64 anyway.  It was not a choice between CompaqF spending the dollars designing Alpha or IA64 servers.  It was a choiceI between IA64 and Alpha or just IA64.  The money saved in R&D costs can besI passed on by Compaq to make the additional server blades you will need non& more expensive than the Alpha systems.  L Even if we accept Todd's contention that it will take two IA64 processors toL equal one Alpha processor the cost won't be any higher because the R&D costs' will be spread over a much larger base.l  J Folks mid to high level server pricing is NOT a function of you add up theK cost of the chips, then decide your profit, and slap a price on the system.iJ There use to be VAX systems that the actual cost to manufacture them was 8F percent of what they sold for.  Todd in his own perverse way has finalF focused the discussion on R&D costs versus manufacturing costs were it should have been all along.p  I > So to suggest that users would not have been willing to pay a 'premium'n for I > better technology is a red herring:  Alpha servers can and could in thecH > future offer significantly better raw cost/performance at the hardwareJ > level - meaning that *Itanic* systems would be those demanding a premiumG > (and making the additional advantages offered by the better operatingS) > systems on Alpha platforms pure gravy).g  K Not at the unit volumes IA64 servers can spread their R&D costs over versusm the unit volumes for Alpha...,   ------------------------------  # Date: Sun, 25 Nov 2001 20:12:41 GMTt& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org8 Message-ID: <ZgcM7.2440$3n6.166486@typhoon1.gnilink.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in message2; news:N88M7.116892$dk.8572547@bin1.nnrp.aus1.giganews.com...uH > I have not heard much yet about post-Marvel plans, so can't comment in8 > detail (pointers to information would be appreciated).  L Compaq was free with the information about QuickBlade at CETS.  Contact yourG salesperson for a NDA on the first generation of QuickBlade servers.  I E understand Bill that since you are NOT a current Compaq customer withKL installed Compaq hardware that may be a problem for you.  Maybe you can findL a real Compaq customer who has a vested interest in this technology who will be willing to take you along...v   ------------------------------  # Date: Mon, 26 Nov 2001 01:24:31 GMT * From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org@ Message-ID: <jRgM7.55246$8q.9186376@bin2.nnrp.aus1.giganews.com>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messaget2 news:ZgcM7.2440$3n6.166486@typhoon1.gnilink.net... >s7 > "Bill Todd" <billtodd@metrocast.net> wrote in message = > news:N88M7.116892$dk.8572547@bin1.nnrp.aus1.giganews.com...eJ > > I have not heard much yet about post-Marvel plans, so can't comment in: > > detail (pointers to information would be appreciated). >mI > Compaq was free with the information about QuickBlade at CETS.  Contacte yourI > salesperson for a NDA on the first generation of QuickBlade servers.  IaG > understand Bill that since you are NOT a current Compaq customer withtI > installed Compaq hardware that may be a problem for you.  Maybe you can  findI > a real Compaq customer who has a vested interest in this technology whol will! > be willing to take you along...   L Ah - so this is a special secret sauce that people will *really* like (trust2 you on that) when it appears a few years from now.  L Right.  IIRC so was Merced, until it turned out to be an utter dud.  Then soL was McKinley, until the clock speed got slashed from 1.4 GHz to 1.0 GHz (andK counting).  Then, briefly, so was Madison until people realized that it wasiI just a warmed-over McKinley.  Now so is whatever the Alpha team will haveD* had a chance to influence come 2005 or so.  H Customers seem to be expressing a preference for something more tangibleH here.  Or at least a credible plan to create it.  Guess you haven't been paying attention.a   - bill   ------------------------------   Date: 26 Nov 2001 01:19:44 GMT& From: peter@abbnm.com (Peter da Silva)N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org% Message-ID: <9ts5bg$3vt@web.nmti.com>u  C In article <Pine.SGI.4.30.0111251144071.5290-100000@world.std.com>,4/ Terry C Shannon  <shannon@world.std.com> wrote:nI > Alpha may well have had no difficulty attracting customers away from anoK > exercise in rearranging the deck chairs on the Itanic, but note that saidaB > Alpha customers would be limited to VMS and Tru64 staterooms, or, > doule-bunks in the Linux steerage section.   As opposed to what? NT on IA64?   M While I'm sorry NT on Alpha was abandoned from a purely marketing standpoint,rM I still have no use for NT on anything but IA32. NT is good for running Win32 : apps on a more reliable OS platform, but that's about all.   -- y+  `-_-'   In hoc signo hack, Peter da Silva.tE   'U`    "A well-rounded geek should be able to geek about anything."cL                                                        -- nicolai@esperi.org          Disclaimer: WWFD?   ------------------------------  # Date: Mon, 26 Nov 2001 01:54:53 GMTe- From: Terry C Shannon <shannon@world.std.com>eN Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.orgC Message-ID: <Pine.SGI.4.30.0111252051350.7295-100000@world.std.com>2  % On Sun, 25 Nov 2001, Bill Todd wrote:e   > < > "Terry C Shannon" <shannon@world.std.com> wrote in message? > news:Pine.SGI.4.30.0111251144071.5290-100000@world.std.com...e >f > ...  > K > > Alpha may well have had no difficulty attracting customers away from anmM > > exercise in rearranging the deck chairs on the Itanic, but note that saidnD > > Alpha customers would be limited to VMS and Tru64 staterooms, or. > > doule-bunks in the Linux steerage section. > E > Well, since we're examining all possibilities here, do you have anynM > knowledge that Microsoft would refuse to resurrect Win64 on Alpha if Compaq M > footed the bill?  Sure, it would make the Compaq leadership that let it getcM > axed look bad, but they already look bad enough to get summarily fired so at > little more wouldn't matter. >p  H No first-hand knowledge, but I have it on pretty good authority that theI topic was broached about a year ago. Didn't get too far. Since that time,rI the vast majority of the pro-Microsoft contingent at CPQ has been purged.l  M > Win64 was reportedly already running in field test 2+ years ago on Alpha asdJ > 64-bit Win2K (A.K.A. NT 5.0), and continued in development internally onK > Alpha at least until Itanic platforms appeared.  Given that Windows XP is N > A.K.A. NT 5.1, the work required to get 64-bit XP running on Alpha should beL > trivial, at least compared with that required to port Windows to any other > platform.n >h  G Indeed it was running... I saw it at the last Innovate. That would havel been April 1999 in Houston.h  F And of course, Build 2128 of Win2K for Alpha is floating around, ummm, here and there and everywhere.   ------------------------------  # Date: Mon, 26 Nov 2001 01:57:30 GMTl- From: Terry C Shannon <shannon@world.std.com> N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.orgC Message-ID: <Pine.SGI.4.30.0111252056230.7295-100000@world.std.com>e  + On Sun, 25 Nov 2001, Bill Gunshannon wrote:t  - > On Sun, 25 Nov 2001, Terry C Shannon wrote:r >e > >n > >e/ > > On Sun, 25 Nov 2001, Bill Gunshannon wrote:d > >e3 > > > On Sun, 25 Nov 2001, Joann Difrancesco wrote:  > > >u > > > > R > > > > Mr. Fenwick is a senior system architect, not a marketing droid, hence hisA > > > > absence from this forum shouldn't be all that surprising.  > > > >8 > > >5P > > > Do I take it then that you see Hoff as a marketing-droid??  (Or any of the2 > > > other Compaq worker-bees who frequent here!) > > >m > > N > > Nothing in Ms. DiFrancesco's assertion would seem to me to be an aspersionI > > against Hoff or any of the other CPQ technical folks who take it uponoI > > themselves to participate in this forum... usually on their own time.sI > > Anyone who knows Hoff knows that Hoff is not a marketing droid. 'Nuff 	 > > said.a > >  >r > Terry,K >    Far be it from me to denigrate Hoff, he's one of the most knowledgable-M > VMS gurus I have ever had contact with and has helped me in many instances.l >"M >    I read the above to say anybody who was not a marketing-droid should nota > be expected to be here.- >   J No big deal... if this is the worst misinterpretation either you or I make' this week, it'll be a good week indeed!5   cheers,8   terry sa   ------------------------------  # Date: Sun, 25 Nov 2001 21:44:30 GMTl& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org8 Message-ID: <2DdM7.2530$3n6.170599@typhoon1.gnilink.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in message ; news:AbdM7.94305$qx2.5969798@bin5.nnrp.aus1.giganews.com...sL > There is nothing inherent in the design of a 'blade' system that prohibitsH > it from leveraging the strengths of EV7 and EV8 - unless it's crippled withG > the requirement of supporting IA64 as well (rather than making that acJ > separate product even if using similar technology - assuming that such aL > product would have a market given the superiority of the Alpha-based one).  K Interesting that someone who admits he knows knowing of the intended design J can make such firm statements.  Then again begining constrained by knowingD what Compaq was actually doing has not been a problem in the past...   ------------------------------  # Date: Sun, 25 Nov 2001 21:52:24 GMT-& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org8 Message-ID: <sKdM7.2541$3n6.170670@typhoon1.gnilink.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in message ; news:AbdM7.94305$qx2.5969798@bin5.nnrp.aus1.giganews.com...7L > Without attempting to imbue you with the technical education you so sorely? > lack, I'll simply point out the fallacy of suggesting that 2Np< > half-performance processors can equal the performance of N full-performanceK > processors on any work-load that does not partition into some multiple ofe 2NG > roughly equal and nearly-independent tasks - even with zero switchingNF > overhead (which I suspect has not yet been achieved).  And the added expenseoC > of having twice as many 'blade' boards (and commensurately largers	 switches)i0 > because each one has only half the capability.  ; Bill someone suggested via Email I ask you this question...h  K Please share with us your understanding of Compaq's QuickBlade strategy and K in particular how the environment will handle work load.  For you to makingdL statements like you are making you must have a keen understanding has to howJ QuickBlade will handle work loads.  Please note I said QuickBlade strategy and didn't said Server or OS...o   ------------------------------  # Date: Mon, 26 Nov 2001 02:37:58 GMTn* From: "Bill Todd" <billtodd@metrocast.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org< Message-ID: <9WhM7.40301$YD.3566763@news2.aus1.giganews.com>  1 "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message 2 news:ZbcM7.2433$3n6.167785@typhoon1.gnilink.net...K > Folks - If you are reading few of the postings in this thread please reado
 > this one...a >b7 > "Bill Todd" <billtodd@metrocast.net> wrote in messagen< > news:b08M7.54525$8q.8866035@bin2.nnrp.aus1.giganews.com... >,E > > Jeff has no clue about this area.  The 'follow-on' to Wildfire is  Marvel,e >tL > It as a typo Bill but bitter people react this way - I understand - moving > on...a  J Well, competent people don't repeat 'a typo' multiple times (twice in eachK of your three posts - surely you had the opportunity to correct them in the I second or third?).  Pardon me for responding to what you said so clearly.d   >uH > > And (to address some FUD from another portion of the discussion) theE > > suggestion that Itanic-based servers will be able to offer betterwL > > cost/performance metrics than Alpha-based servers holds no water either.K > > Not only will it take something like twice as many Itanic processors to5L > > provide equivalent performance (and server prices usually rise more thanL > > linearly with the number of processors, due to the added effort required > toF > > glue them together effectively - *especially* lacking the kinds of on-chipaL > > support that EV7 provides but Itanic does not), but the price differenceL > > between an N-processor Alpha box and an N-processor Itanic box (offeringI > > dramatically less capability) should be minimal for anything but veryt > smalltK > > values of N, because processor prices (assuming that Itanic's ever *do*a > comeI > > down) just don't contribute much to the cost of a mid-range or largers > > server.n >sH > Well well well - at long last Todd acknowledges that the IA64 could be6 > configured to provide the same performance as Alpha.  K In some applications.  Give me the right application, and I could configure J a bunch of J11s to provide the same performance as an Alpha (e.g., if SETIG runs on the 11...).  Let *me* specify the application, and you couldn'tbH configure a hundred Itanics to provide the same performance as an Alpha.  A You're an idiot, Jeff.  Must you insist on being one so publicly?-   >-L > Folks more than anything else the above argument from Todd should make you; > question his fundamental understanding of this subject...n >KJ > 1) What drives the costs of this class of server is NOT the actual chipsH > used in the box but the R&D costs.  The actual cost to manufacture the- > server is a fraction of what they sell for.l  J By George, you got one right!  Unfortunately, you then as usual proceed to* draw completely false conclusions from it.   >tL > 2) If you look at the number of N-Processor Alpha servers Compaq sells andK > compare that to the number of N-Processor Proliant boxes Compaq sells yousK > quickly realize to potential spread R&D costs over a much larger base - an8 > larger base than most, it not all, of its competitors.  E Let's see:  we can choose between selling half a million Proliants atnH near-zero profit (but boy, did we spread out the R&D cost) or, say, 100KJ Alphas at a rather tidy profit (even with much higher per-unit R&D costs).. Well, Compaq seems to agree with your logic...  E During the dot-com boom last year Proliant profits indeed did improve F markedly (funny about how many people bought them who turned out to beJ incompetent at running a business).  But alas, they followed it right downI again as well, while Alpha profits just chugged along smoothly until June  25th, despite Compaq's neglect.m   > G > 3) Compaq is moving to QuickBlade servers with InfiniBand fabric. Thel designF > is very much optimized to allow the easy addition of CPU power.  You shouldF > be able to get a NDA presentation from your salesperson on the firstF > generation of QuickBlade servers.  (BTW Compaq sells more dense rack serversn) > than HP, Dell, and Sun combined today).o  K (BTW, the other difference is that *those* vendors actually seem to make atW& least a modest profit in that market.)  "   The QuickBlade servers today are > only the first step.  J 'QuickBlade servers *today*'?  I'm impressed:  they're already up for saleE and *still* secret?  And they already have those not-even-yet-definedpH Itanics inside that might actually compete with Alpha (once we know what they might look like)?  I I didn't realize that even Infiniband hardware was available now.  Or didsI you misspeak yet again?  Surely you're not selling vaporware here:  afterkG all, Compaq had been vigorously promoting the virtues of EV8 - not eventK under NDA - for years before they defined it to be not worth completing, soeK something that can't be talked about publicly might be even more subject tos radical change...s   > I > 4) Compaq is going to have to sink the R&D dollars into developing high & > performance N-Processor IA64 anyway.  I Why?  Exactly where is the market for a high-end, low-performance server, K when there'll be at least one high-end, *high*-performance system availablenJ from IBM - and another available from Compaq as long as Alphas continue toB be developed - and indeed yet another from HP as long as they keepJ developing PA-RISC - and even another from SGI, since they've committed toK continue to develop MIPS indefinitely now after having been burned so badly ) waiting for Itanic to get out of drydock?q  = (And I could say that people who really *do* want a high-end,RI low-performance server have always appeared to have a distinct preferencee+ for SUN, but that would be a cheap shot...)   E You may recall that Sequent (among others) made a respectable, thoughhI comparatively small, business out of creating high-tech IA32 systems.  At J least those systems had the advantage of using relatively high-performanceG processors at their cores - but they still didn't exactly take over ther: world, because better alternatives were usually available.  $   It was not a choice between CompaqH > spending the dollars designing Alpha or IA64 servers.  It was a choice& > between IA64 and Alpha or just IA64.  L One of the very few choices Compaq could have made that would have been even  stupider than those it did make.  %   The money saved in R&D costs can beiK > passed on by Compaq to make the additional server blades you will need nos( > more expensive than the Alpha systems.  E I'm afraid that will depend wholly on the *sales volume* those bladesrI attain.  And unless Compaq can afford to sell them at a major loss for an2H indefinite but guaranteed-lengthy period until they have built up a muchJ larger base than, say, POWER4 will have accumulated by then (just as IntelJ is selling Merceds at a loss today, though even so their volume is minimalG and the acceptance curve appears *very* slow), that just isn't going toc happen.   E Both you and Compaq have taken IA64 dominance to be a given, when the L evidence points increasingly toward IA64 being the next iAPX432 (with HammerC being the next x86 and changes in the high end still occurring only K gradually).  If you posit that dominance, your scenario at least makes some I sense - but as in other areas it's your *premise* that's a major problem.r  H It seems very likely that Compaq will *never* recoup any significant R&DK costs associated with Itanic:  it can't compete at the high end with POWER4eL and whatever other existing processor lines are kept alive, it can't competeL at the low end with IA32 (let alone Hammer), and if Compaq slashes prices toJ try to change this the R&D costs *won't* be recovered (indeed, such a moveK seems almost preordained, since it's exactly the same 'strategy' Compaq has.) used to lose money on PCs for years now)..  J The rest of your drivel merely repeated your misconceptions above, so that does it for this round.8   - bill   ------------------------------  # Date: Sun, 25 Nov 2001 22:54:57 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org8 Message-ID: <5FeM7.2601$3n6.171707@typhoon1.gnilink.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in messaget: news:1beM7.55105$8q.9089312@bin2.nnrp.aus1.giganews.com... >u3 > "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message 3 > news:4tdM7.1687$zf.155977@typhoon2.gnilink.net...  > >a9 > > "Bill Todd" <billtodd@metrocast.net> wrote in messaget? > > news:AbdM7.94305$qx2.5969798@bin5.nnrp.aus1.giganews.com... I > > > Without attempting to imbue you with the technical education you sot > sorelyC > > > lack, I'll simply point out the fallacy of suggesting that 2N @ > > > half-performance processors can equal the performance of N > > full-performanceL > > > processors on any work-load that does not partition into some multiple > of > > 2N0 > > > roughly equal and nearly-independent tasks > >K8 > > Don't put words in mouth - I have never said that... >hG > A statement worthy of a Compaq lie.  Indeed, you never said *exactly*r that:e > what you said was: >bK > "The first time I saw the Quick Blade design one of the first questions I K > asked was couldn't someone just plug more blades in to equal the power ofv	 > Alpha.":  C Where in that statement did I ever suggest that two .5X performanceF; processors would equal the performance of one 1X processor?g  F As I said putting words in my mouth and jumping to wild assumptions...   ------------------------------  # Date: Sun, 25 Nov 2001 23:16:13 GMTw& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org8 Message-ID: <1ZeM7.2603$3n6.172470@typhoon1.gnilink.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in messagel; news:V2eM7.94807$qx2.6012891@bin5.nnrp.aus1.giganews.com... E > As I indicated elsewhere, I don't know any details about it, though  'blades'G > have been mentioned enough that one can infer some things about their K > character.  As I also said elsewhere, I'd welcome information about where.J > Compaq's particular 'blade' approach is documented and would be happy to, > comment in more detail after I've read it.  F There is a QuickBlade NDA's available for Compaq customers.  Being NDAG material one must be cautious about how far one can go. I would suggest : anyone who is interested in this get the NDA presentation.  H > The comments I made above, however, are generic to all multi-processorJ > systems (even SMP, though ccNUMA seems to be getting hard to avoid theseL > days and I suspect is at least as much a part of Compaq blades as it is of3 > the current Wildfire and future Marvel products).e  K The QuickBlade strategy is based on high density server packaging which has H different groups and types of servers for different workloads all in theE same rack.  It is based on resource provisioning and dynamic resourcenJ allocation.  It is geared towards the typical commercial environment whereK many different types of jobs need to be handled at once.  It is designed toeH be have the different groups of servers built into a high density singleD rack.  Initially there could be many blades in a rack with many moreF processors (do not read that as _all_ processors being tightly coupledJ together).  It is a highly managed set of computing resources in rack withJ shared storage.  The first family is due soon but the ultimate design thatC we be the follow-on for Alpha customers will come later.  Pay closea8 attention to the code names "wind", "fire", and "ice"...   ------------------------------  # Date: Mon, 26 Nov 2001 05:44:48 GMT & From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org8 Message-ID: <kFkM7.2742$3n6.180846@typhoon1.gnilink.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in messageN6 news:9WhM7.40301$YD.3566763@news2.aus1.giganews.com... >s3 > "Jeff Killeen" <Jeff@IDM-IO.com> wrote in messageiJ > > Well well well - at long last Todd acknowledges that the IA64 could be8 > > configured to provide the same performance as Alpha. >lC > In some applications.  Give me the right application, and I could 	 configureoL > a bunch of J11s to provide the same performance as an Alpha (e.g., if SETII > runs on the 11...).  Let *me* specify the application, and you couldn'tdJ > configure a hundred Itanics to provide the same performance as an Alpha. >wC > You're an idiot, Jeff.  Must you insist on being one so publicly?d  B I understand anyone who disagrees with the sage Todd is an idiot -@ considering the source of the statement I find it reaffirming...  L > > 1) What drives the costs of this class of server is NOT the actual chipsJ > > used in the box but the R&D costs.  The actual cost to manufacture the/ > > server is a fraction of what they sell for.  > L > By George, you got one right!  Unfortunately, you then as usual proceed to, > draw completely false conclusions from it. >r > >gJ > > 2) If you look at the number of N-Processor Alpha servers Compaq sells and I > > compare that to the number of N-Processor Proliant boxes Compaq sells  youpK > > quickly realize to potential spread R&D costs over a much larger base -u ao: > > larger base than most, it not all, of its competitors. >iG > Let's see:  we can choose between selling half a million Proliants atgJ > near-zero profit (but boy, did we spread out the R&D cost) or, say, 100KL > Alphas at a rather tidy profit (even with much higher per-unit R&D costs).0 > Well, Compaq seems to agree with your logic...  K I think Compaq would disagree with you about the profits they are making on G the 8-way Proliants.  One needs to very careful about mixing the AccesssF Business Unit, with the uniProcessor Proliant business, with the N-WayB Proliant business.  But that is not important for this discussion.  K You missed the point again - Compaq is going to sink the R&D costs into the>H high performance box for IA64 no matter what.  If it builds an Alpha boxL that is added R&D costs.  If it runs OVMS and Tru64 on those IA64 boxes thatI means more sales against already sunk R&D costs.  Keep in mind I disagreebK with your claim, despite your personal best efforts to make it happen, thataJ OVMS business will be destroyed by this.  Only time will time which one of us is right.  G > During the dot-com boom last year Proliant profits indeed did improvetH > markedly (funny about how many people bought them who turned out to beL > incompetent at running a business).  But alas, they followed it right downK > again as well, while Alpha profits just chugged along smoothly until Juneo! > 25th, despite Compaq's neglect.c  D Care to reference a public source on this?  I have heard data to theI contrary.  Last spring the business critical server division was breaking-- even.  Also that the 8-ways are making money.:  I > > 3) Compaq is moving to QuickBlade servers with InfiniBand fabric. TheI > designH > > is very much optimized to allow the easy addition of CPU power.  You > shouldH > > be able to get a NDA presentation from your salesperson on the firstH > > generation of QuickBlade servers.  (BTW Compaq sells more dense rack	 > serverst+ > > than HP, Dell, and Sun combined today).s >oJ > (BTW, the other difference is that *those* vendors actually seem to make at( > least a modest profit in that market.)  J Again it is my understanding that Compaq is idea making money off the high density Intel server products.  $ >   The QuickBlade servers today are > > only the first step. >hL > 'QuickBlade servers *today*'?  I'm impressed:  they're already up for saleG > and *still* secret?  And they already have those not-even-yet-definedrJ > Itanics inside that might actually compete with Alpha (once we know what > they might look like)?  ) The first generation isn't that far away.w  K > I didn't realize that even Infiniband hardware was available now.  Or didoK > you misspeak yet again?  Surely you're not selling vaporware here:  after I > all, Compaq had been vigorously promoting the virtues of EV8 - not evenlJ > under NDA - for years before they defined it to be not worth completing, soJ > something that can't be talked about publicly might be even more subject to > radical change...   H Did I say the first generation QuickBlade servers would have Infiniband?H Haven't I said in a bunch of postings that these QuickBlades are NOT the) ones that will be the follow-on to Alpha?e  K > > 4) Compaq is going to have to sink the R&D dollars into developing highe( > > performance N-Processor IA64 anyway. > K > Why?  Exactly where is the market for a high-end, low-performance server,tC > when there'll be at least one high-end, *high*-performance systemi	 available1L > from IBM - and another available from Compaq as long as Alphas continue toD > be developed - and indeed yet another from HP as long as they keepL > developing PA-RISC - and even another from SGI, since they've committed toG > continue to develop MIPS indefinitely now after having been burned soe badlyh+ > waiting for Itanic to get out of drydock?e  K Because whether you chose to acknowledge it or not Compaq has a viable, and K from what I heard profitable, N-way high performance Intel server business. I Of course your question is a when did you stop beating your wife questiontC because it contains an assertion that Intel equals low performance.   I Bill you just don't realize how much you sound like the IBM guys did when G VMS clusters first hit the market.  They were claiming there was no wayhJ clusters of VAX systems would ever deliver the production capacity becauseD of their low performance.  Its like the early 1980's all over again.J Clusters of systems will never replace big iron.  Oh how we have forgotten our roots...  K PA-RISC?  Really?  Did the death of HP3000 series last week bring about the( end of that?  J > It seems very likely that Compaq will *never* recoup any significant R&DF > costs associated with Itanic:  it can't compete at the high end with POWER4F > and whatever other existing processor lines are kept alive, it can't competeeK > at the low end with IA32 (let alone Hammer), and if Compaq slashes pricest toL > try to change this the R&D costs *won't* be recovered (indeed, such a moveI > seems almost preordained, since it's exactly the same 'strategy' Compaqu hasf+ > used to lose money on PCs for years now).l  I Mr. Gates is in the poor house right now because people will always pay adK premium for better technology over just good enough technology at commoditysD prices.  Yes Mr. Todd your POV is one the history of this market hasE validated over and over again.  BTW - Do you click your ruby slipperso* together and wish you were back in Kansas?   ------------------------------  # Date: Mon, 26 Nov 2001 05:34:00 GMTo& From: "Jeff Killeen" <Jeff@IDM-IO.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org8 Message-ID: <cvkM7.2740$3n6.180664@typhoon1.gnilink.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in message 6 news:9WhM7.40301$YD.3566763@news2.aus1.giganews.com... >t3 > "Jeff Killeen" <Jeff@IDM-IO.com> wrote in message J > > Well well well - at long last Todd acknowledges that the IA64 could be8 > > configured to provide the same performance as Alpha. >rC > In some applications.  Give me the right application, and I couldi	 configureoL > a bunch of J11s to provide the same performance as an Alpha (e.g., if SETII > runs on the 11...).  Let *me* specify the application, and you couldn'toJ > configure a hundred Itanics to provide the same performance as an Alpha. >DC > You're an idiot, Jeff.  Must you insist on being one so publicly?e  B I understand anyone who disagrees with the sage Todd is an idiot -@ considering the source of the statement I find it reaffirming...  L > > 1) What drives the costs of this class of server is NOT the actual chipsJ > > used in the box but the R&D costs.  The actual cost to manufacture the/ > > server is a fraction of what they sell for.m >nL > By George, you got one right!  Unfortunately, you then as usual proceed to, > draw completely false conclusions from it. >  > > J > > 2) If you look at the number of N-Processor Alpha servers Compaq sells and I > > compare that to the number of N-Processor Proliant boxes Compaq sellsr you K > > quickly realize to potential spread R&D costs over a much larger base -t ah: > > larger base than most, it not all, of its competitors. >nG > Let's see:  we can choose between selling half a million Proliants ateJ > near-zero profit (but boy, did we spread out the R&D cost) or, say, 100KL > Alphas at a rather tidy profit (even with much higher per-unit R&D costs).0 > Well, Compaq seems to agree with your logic...  K I think Compaq would disagree with you about the profits they are making onfG the 8-way Proliants.  One needs to very careful about mixing the AccessrF Business Unit, with the uniProcessor Proliant business, with the N-WayB Proliant business.  But that is not important for this discussion.  K You missed the point again - Compaq is going to sink the R&D costs into thetH high performance box for IA64 no matter what.  If it builds an Alpha boxL that is added R&D costs.  If it runs OVMS and Tru64 on those IA64 boxes thatI means more sales against already sunk R&D costs.  Keep in mind I disagreeeK with your claim, despite your personal best efforts to make it happen, thatnJ OVMS business will be destroyed by this.  Only time will time which one of us is right.  G > During the dot-com boom last year Proliant profits indeed did improverH > markedly (funny about how many people bought them who turned out to beL > incompetent at running a business).  But alas, they followed it right downK > again as well, while Alpha profits just chugged along smoothly until JuneA! > 25th, despite Compaq's neglect.l  D Care to reference a public source on this?  I have heard data to theI contrary.  Last spring the business critical server division was breaking - even.  Also that the 8-ways are making money.d  I > > 3) Compaq is moving to QuickBlade servers with InfiniBand fabric. Thet > designH > > is very much optimized to allow the easy addition of CPU power.  You > shouldH > > be able to get a NDA presentation from your salesperson on the firstH > > generation of QuickBlade servers.  (BTW Compaq sells more dense rack	 > serverso+ > > than HP, Dell, and Sun combined today).s >iJ > (BTW, the other difference is that *those* vendors actually seem to make at( > least a modest profit in that market.)  J Again it is my understanding that Compaq is idea making money off the high density Intel server products.  $ >   The QuickBlade servers today are > > only the first step. >uL > 'QuickBlade servers *today*'?  I'm impressed:  they're already up for saleG > and *still* secret?  And they already have those not-even-yet-defined J > Itanics inside that might actually compete with Alpha (once we know what > they might look like)?  ) The first generation isn't that far away.   K > I didn't realize that even Infiniband hardware was available now.  Or did K > you misspeak yet again?  Surely you're not selling vaporware here:  aftereI > all, Compaq had been vigorously promoting the virtues of EV8 - not evenCJ > under NDA - for years before they defined it to be not worth completing, soJ > something that can't be talked about publicly might be even more subject to > radical change...d  H Did I say the first generation QuickBlade servers would have Infiniband?H Haven't I said in a bunch of postings that these QuickBlades are NOT the) ones that will be the follow-on to Alpha?   K > > 4) Compaq is going to have to sink the R&D dollars into developing hight( > > performance N-Processor IA64 anyway. >iK > Why?  Exactly where is the market for a high-end, low-performance server,nC > when there'll be at least one high-end, *high*-performance systemq	 availableiL > from IBM - and another available from Compaq as long as Alphas continue toD > be developed - and indeed yet another from HP as long as they keepL > developing PA-RISC - and even another from SGI, since they've committed toG > continue to develop MIPS indefinitely now after having been burned sos badly8+ > waiting for Itanic to get out of drydock?   K Because whether you chose to acknowledge it or not Compaq has a viable, and K from what I heard profitable, N-way high performance Intel server business.gI Of course your question is a when did you stop beating your wife questionbC because it contains an assertion that Intel equals low performance.@  I Bill you just don't realize how much you sound like the IBM guys did wheniG VMS clusters first hit the market.  They were claiming there was no way J clusters of VAX systems would ever deliver the production capacity becauseD of their low performance.  Its like the early 1980's all over again.J Clusters of systems will never replace big iron.  Oh how we have forgotten our roots...  K PA-RISC?  Really?  Did the death of HP3000 series last week bring about thea end of that?  J > It seems very likely that Compaq will *never* recoup any significant R&DF > costs associated with Itanic:  it can't compete at the high end with POWER4F > and whatever other existing processor lines are kept alive, it can't compete.K > at the low end with IA32 (let alone Hammer), and if Compaq slashes pricesy toL > try to change this the R&D costs *won't* be recovered (indeed, such a moveI > seems almost preordained, since it's exactly the same 'strategy' Compaqr hasd+ > used to lose money on PCs for years now).h  I Mr. Gates is in the poor house right now because people will always pay asK premium for better technology over just good enough technology at commodity D prices.  Yes Mr. Todd your POV is one the history of this market hasE validated over and over again.  BTW - Do you click your ruby slippers"* together and wish you were back in Kansas?   ------------------------------  # Date: Sun, 25 Nov 2001 21:02:38 GMT7, From: "Paul Dennis" <comedyox@earthlink.not>8 Subject: Re: Using CMS$LIB to create a list of librariesD Message-ID: <O%cM7.5133$WC1.577345@newsread2.prod.itd.earthlink.net>   "Larry Kilgallen"  >w > HELP CMS SET LIBRARY >gE > From what I see of the results, multiple simultaneous libraries areg > fully supported. >c  H Although, using multiple CMS libraries does compromise the usefulness of classes in some cases.  0 Say you're piggybacking one library off another:   $ cms set lib myproj$, prod$  H If you wanted to bounce off class V54 in PROD$, the class V54 would alsoD need to exist in MYPROJ$ for MMS to be able to process it correctly.  D WAG: but even if you wrote loads of DCL/MMS to manage classes acrossI multiple CMS libraries, (i.e. manipulate CMSFLAGS on a per target basis - < YUK!) you'd not be able to use ~ sources anymore, would you?  = Just a stumbling block I came across when using search lists.m   .pd.   ------------------------------  % Date: Mon, 26 Nov 2001 14:42:44 +0010 ' From: <paddy.o'brien@zzz.tg.nsw.gov.au>i8 Subject: Re: Using CMS$LIB to create a list of libraries5 Message-ID: <01KB5W9II62A000RT2@tgmail.tg.nsw.gov.au>c   Paul Dennis wrote:   >"Larry Kilgallen" >> >> HELP CMS SET LIBRARYn >>F >> From what I see of the results, multiple simultaneous libraries are >> fully supported.e >> > I >Although, using multiple CMS libraries does compromise the usefulness ofr >classes in some cases.t >i1 >Say you're piggybacking one library off another:n >r >$ cms set lib myproj$, prod$( >nI >If you wanted to bounce off class V54 in PROD$, the class V54 would also E >need to exist in MYPROJ$ for MMS to be able to process it correctly.  >eE >WAG: but even if you wrote loads of DCL/MMS to manage classes acrosswJ >multiple CMS libraries, (i.e. manipulate CMSFLAGS on a per target basis -= >YUK!) you'd not be able to use ~ sources anymore, would you?- >-> >Just a stumbling block I came across when using search lists.   I cannot agree with this.:  K We have 8 CMS libraries for our main applications, and 5 CMS libraries for  M utility type modules, e.g. sparse algorithms, graphics and general utilities..  Q The utilities are used by various of the applications, and the general utilities  C by all.  One application references 6 libraries in the search list.l  K Yes, we use DCL/MMS to handle at least 80% of our usage for creating local vQ builds, system builds, classes, etc.  We have no problem with re-creating a full a7 program of an earlier class of any of the applications.o   I don't understand your point:= >YUK!) you'd not be able to use ~ sources anymore, would you?   M We maintain CMS reference libraries for source code because this is what the sQ debug version is pointing to.  But, this is only a copy of the latest generation gO for each element.  A class refers to a specific generation of that element and iO this information is available only in the CMS library itself.  Thus, the class ): must reference ~ source and a particular generation of it.  O The only problem I have had with classes is trying to recreate a class where I tJ had done a rename on the module.  We had started doing this when changing P modules to Fortran free-format .FOR to .F90.  Renaming is taboo, we just accept O that if we want to look at the generation history, we may have to do so in two  	 modules. r  L We have been running like this for about 8 years now, with no problems with P classes (or than that just detailed).  I initially wrote some quick and dirties H in DCL to generate MMS scripts and CMS libraries from the .TLBs that we Q previously used.  Two of us then took a bit of time out to put together some DCL a5 scripts to automate much of this stuff transparently.R   Regards, Paddy   ------------------------------    Date: 26 Nov 2001 08:03:57 +0800, From: Paul Repacholi <prep@prep.synonet.com>D Subject: Re: VMS on IBM power chip would make IBM No. 1 in high end!- Message-ID: <873d324cuq.fsf@prep.synonet.com>.  , John Reagan <john.reagan@compaq.com> writes:   > Bob Ceculski wrote: H > > If IBM bought Compaq they could use either alpha or power or a combo? > > to run VMS and rule the high end ... linux is not high end!i  ? IBM fromting for a Alpha Arch licence would be 'interesting' tor? say the least. The Q-untel deal is meant to be non-exclusive...   H > The problem would be with compilers.  We don't have a Power target forB > GEM and with most of the compiler folks heading off to Intel, itG > wouldn't likely happen.  So unless IBM has a BLISS and MACRO compilerh+ > lying around that generates Power code...   ? So what DID happen to the CMU BLISS compiler and it's humungousg set of backends?   -- a< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.o@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------    Date: 26 Nov 2001 07:48:22 +0800, From: Paul Repacholi <prep@prep.synonet.com>D Subject: Re: VMS on IBM power chip would make IBM No. 1 in high end!- Message-ID: <877kse4dkp.fsf@prep.synonet.com>d  / "John Eisenschmidt" <jeisensc@aaas.org> writes:   C > And the port would have to pay for itself. Compaq can port VMS to @ > Itanium and justify the cost - people who run VMS on IA64 will? > almost assuredly buy their Itanium Servers from Compaq. SincepC > they've hacked off their Alpha division, they're banking on theiri! > high end IA64 stuff doing well.   f4 This little black duck will buy from anyone BUT Q...   -- e< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.s@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------   End of INFO-VAX 2001.657 ************************