1 INFO-VAX	Tue, 09 Jul 2002	Volume 2002 : Issue 375       Contents:1 Re: .scn files (Using the VAX Debugger with SCAN) 1 Re: .scn files (Using the VAX Debugger with SCAN) + Re: Alphaserver 1200 Configuration Question + Re: Alphaserver 1200 Configuration Question + Re: Alphaserver 1200 Configuration Question + Re: Alphaserver 1200 Configuration Question  Copy Printing Question.  Re: Copy Printing Question.  RE: Copy Printing Question.  Re: Copy Printing Question.  Re: Cost of $CONNECT/DISCONNECT % CPU time for batch job 4-MAY-1859 ??? ) Re: CPU time for batch job 4-MAY-1859 ???   Disk drives for Digital PW 433au$ Re: Disk drives for Digital PW 433au$ Re: Fearless IPF Prognostications...$ Re: Fearless IPF Prognostications... Re: Lynx & SSL Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh...+ Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts = Re: New web-page dedicated to ports of PD software to OpenVMS = Re: New web-page dedicated to ports of PD software to OpenVMS + Re: Only 20% drop in VMS systems (was: wow) + Re: Only 20% drop in VMS systems (was: wow) + Re: Only 20% drop in VMS systems (was: wow) + Re: Only 20% drop in VMS systems (was: wow) + Re: Only 20% drop in VMS systems (was: wow) + Re: Only 20% drop in VMS systems (was: wow) + RE: Only 20% drop in VMS systems (was: wow) + Re: Only 20% drop in VMS systems (was: wow) + RE: Only 20% drop in VMS systems (was: wow) + Re: Only 20% drop in VMS systems (was: wow) A Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!) A Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!)  Re: Pascal Editor ) Problems to load OpenVMS V7.3 on DEC 4610 - Re: Problems to load OpenVMS V7.3 on DEC 4610 - Re: Problems to load OpenVMS V7.3 on DEC 4610   Re: SET FILE/TRUNCATE equivalent  Re: SET FILE/TRUNCATE equivalent  Re: SET FILE/TRUNCATE equivalent Re: SMTP 8bit hack not working Re: SMTP 8bit hack not working Re: SMTP 8bit hack not working TOKENS CASELESS  Re: TOKENS CASELESS  (VAX Scan)  Re: TOKENS CASELESS  (VAX Scan)  Re: TOKENS CASELESS  (VAX Scan)  Re: TOKENS CASELESS  (VAX Scan)  VS4000VLC hardware information. # Re: VS4000VLC hardware information. # RE: VS4000VLC hardware information.  WRQ #2 in Web-to-host market$ XP1000 667Mhz USD2995 !!!!! Incoming  F ----------------------------------------------------------------------  $ Date: Tue, 9 Jul 2002 13:49:45 +0530# From: "Vivek Soni" <visoni@bmc.com> : Subject: Re: .scn files (Using the VAX Debugger with SCAN)/ Message-ID: <uil71k5e444hc2@corp.supernews.com>    Larry,  ) I have a debug build of these .scn files.   2 I have also set the language to SET LANGUAGE SCAN.  6 But still I get the error...source code not available.   Am I missing something.    Thanks Vivek     8 Larry Kilgallen <Kilgallen@SpamCop.net> wrote in message- news:bWTmk+YJq$o4@eisner.encompasserve.org... > > In article <uiapu0t388oja7@corp.supernews.com>, "Vivek Soni" <visoni@bmc.com> writes: > > Hi,  > > J > > Encountered one more type of files (.SCN files). These were programmed in	 > > 1988.  > > H > > These file have Token sections,  Type section,  Declaration SECTION,( > > PROCEDURE SECTION and MACRO Section. > > F > > PROCEDURE SECTIONS contians the external declarations of functions defined  > > in other .scn files. > > L > > The functions defined in this file ( Called MACRO's here) are defined in the  > > MACRO section. > > 5 > > PROCEDURE PARSE( file_name: varying STRING(256));  > > DECLARE status > > .  > > .  > > . 5 > > These functions get called from the .C files like  > >  > > parse(&argument);  > > B > > Obviously the OpenVMS debugger cannot debug in to these files. > F > Certainly the VMS debugger _can_ debug these files.  Try the command( > SET LANGUAGE SCAN in the VAX debugger.   ------------------------------   Date: 9 Jul 2002 05:29:03 -0600 - From: Kilgallen@SpamCop.net (Larry Kilgallen) : Subject: Re: .scn files (Using the VAX Debugger with SCAN)3 Message-ID: <K9qggJQPau$k@eisner.encompasserve.org>   U In article <uil71k5e444hc2@corp.supernews.com>, "Vivek Soni" <visoni@bmc.com> writes:   + > I have a debug build of these .scn files.  > 4 > I have also set the language to SET LANGUAGE SCAN. > 8 > But still I get the error...source code not available. >  > Am I missing something.   4 This should be no different from any other language.   	SCAN/DEBUG ...  	LINK/DEBUG ...   C and ensure that when you RUN the same logical names, etc. are still % available to locate the source files.    ------------------------------  % Date: Tue, 09 Jul 2002 09:45:48 +0200 9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> 4 Subject: Re: Alphaserver 1200 Configuration Question' Message-ID: <3D2A94AC.29931EEF@aaa.com>   & The AS1200 runs with one or two CPU's.3 There is realy no "memory board" to add. All memory 6 is added by DIMM's modules. Configure according to the$ User Guide or other rellevant docs.   = I have a PDF version of the AS1200 User Guide. Can't remember A where I found it. Could mail it to you if you whan't to (680 kb).    Jan-Erik Sderholm.    dittman@dittman.net wrote: > ? > Can an Alphaserver 1200 work with only one CPU and one memory ( > board, or does it require two of each? > -- > Eric Dittman > dittman@dittman.net ? > Check out the DEC Enthusiasts Club at http://www.dittman.net/    ------------------------------  # Date: Tue, 09 Jul 2002 12:53:58 GMT  From: dittman@dittman.net 4 Subject: Re: Alphaserver 1200 Configuration Question6 Message-ID: <G1BW8.6804$aL6.5940@nwrddc03.gnilink.net>  ' Jan-Erik Sderholm <aaa@aaa.com> wrote: ( : The AS1200 runs with one or two CPU's.5 : There is realy no "memory board" to add. All memory 8 : is added by DIMM's modules. Configure according to the& : User Guide or other rellevant docs.   ' The DIMMs install on the memory boards.  --   Eric Dittman dittman@dittman.net = Check out the DEC Enthusiasts Club at http://www.dittman.net/    ------------------------------  % Date: Tue, 09 Jul 2002 15:16:27 +0200 9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> 4 Subject: Re: Alphaserver 1200 Configuration Question' Message-ID: <3D2AE22B.31E0AD16@aaa.com>   4 Yes, but each DIMM pair, is installed on both cards.5 One card (called "riser card" or "memory card" in the = manual) is for the "lower" bytes and the other for the "high" A bytes of each "word". So, both cards must be installed and having 0 at least one DIMM module to get the box running.  	 Jan-Erik.    dittman@dittman.net wrote: > ) > Jan-Erik Sderholm <aaa@aaa.com> wrote: * > : The AS1200 runs with one or two CPU's.7 > : There is realy no "memory board" to add. All memory : > : is added by DIMM's modules. Configure according to the' > : User Guide or other rellevant docs.  > ) > The DIMMs install on the memory boards.  > -- > Eric Dittman > dittman@dittman.net ? > Check out the DEC Enthusiasts Club at http://www.dittman.net/    ------------------------------  # Date: Tue, 09 Jul 2002 17:58:01 GMT  From: dittman@dittman.net 4 Subject: Re: Alphaserver 1200 Configuration Question6 Message-ID: <JuFW8.6415$I02.5445@nwrddc04.gnilink.net>  ' Jan-Erik Sderholm <aaa@aaa.com> wrote: 6 : Yes, but each DIMM pair, is installed on both cards.7 : One card (called "riser card" or "memory card" in the ? : manual) is for the "lower" bytes and the other for the "high" C : bytes of each "word". So, both cards must be installed and having 2 : at least one DIMM module to get the box running.  9 That's what I needed to know.  I'll need two of the riser  cards. --   Eric Dittman dittman@dittman.net = Check out the DEC Enthusiasts Club at http://www.dittman.net/    ------------------------------  $ Date: Tue, 9 Jul 2002 13:06:34 +0100* From: Andrew Robinson <arobinson@hspg.com>  Subject: Copy Printing Question.M Message-ID: <CDA4BAD1E10ED41181AC00508B6051D3C3E7F2@grumpy.internal.hspg.com>    Please could you help ?   L Is at all possible to setup printer queues, both Telnet or Lat which will do? a copy print of anything sent to them to another printer queue?  I'm running OVMS7.2-2 & TCPIP J I'm unable to change the method by which the print command is sent as this& is imbedded in a compiled application. Example of queue entry : 5004120  740_000270_DESP_NOTE D                         BACKGROUND        5  Pending (queue stopped)?         Submitted  4-JUL-2002 09:31:58.65 /NOFEED /FORM=DEFAULT 
 /PRIORITY=100 
         File: E _DSA1:[VANTAGE_FILES.COMPANY_1.SPOOL_FILES]740_000270_DESP_NOTE.XXX;1  /DELETE /NOFEED    Ta   Andrew Robinson    ------------------------------  % Date: Tue, 09 Jul 2002 14:17:41 +0200 9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> $ Subject: Re: Copy Printing Question.' Message-ID: <3D2AD465.89985AD4@aaa.com>   ; If your use TCPIP/LPD queues, you could setup your PRINTCAP : file to "redirect" output from one queue to another queue.  % But what are you trying to do realy ? / What "method" is embedded in your application ?   8 With a batch job it should be able to scan any queue for; entries, PRINT them on some other queue and then remove the  entry from the first queue.    Jan-Erik Sderholm.    Andrew Robinson wrote: >  > Please could you help ?  > N > Is at all possible to setup printer queues, both Telnet or Lat which will doA > a copy print of anything sent to them to another printer queue?  > I'm running OVMS7.2-2 & TCPIP L > I'm unable to change the method by which the print command is sent as this( > is imbedded in a compiled application. > Example of queue entry : > 5004120  740_000270_DESP_NOTE F >                         BACKGROUND        5  Pending (queue stopped)A >         Submitted  4-JUL-2002 09:31:58.65 /NOFEED /FORM=DEFAULT  > /PRIORITY=100  >         File: G > _DSA1:[VANTAGE_FILES.COMPANY_1.SPOOL_FILES]740_000270_DESP_NOTE.XXX;1  > /DELETE /NOFEED  >  > Ta >  > Andrew Robinson    ------------------------------  $ Date: Tue, 9 Jul 2002 14:09:53 +0100* From: Andrew Robinson <arobinson@hspg.com>$ Subject: RE: Copy Printing Question.M Message-ID: <CDA4BAD1E10ED41181AC00508B6051D3C3E7F3@grumpy.internal.hspg.com>   H I have an issue where a copy print is wanted of everything printed via = a E certain queue or queues, for both auditing and security reasons. It =  needs toD be a hardcopy - as a physical time stamped proof copy is essential = (This is done by the copy printer).   Regards   	 Andrew R.    -----Original Message-----2 From: Jan-Erik S=F6derholm [mailto:aaa@aaa.com]=20 Sent: 09 July 2002 13:18 To: Info-VAX@Mvb.Saic.Com $ Subject: Re: Copy Printing Question.    C If your use TCPIP/LPD queues, you could setup your PRINTCAP file to 2 "redirect" output from one queue to another queue.  % But what are you trying to do realy ? / What "method" is embedded in your application ?   I With a batch job it should be able to scan any queue for entries, PRINT =  themC on some other queue and then remove the entry from the first queue.    Jan-Erik S=F6derholm.    Andrew Robinson wrote: >=20 > Please could you help ?  >=20I > Is at all possible to setup printer queues, both Telnet or Lat which=20 E > will do a copy print of anything sent to them to another printer=20 I > queue? I'm running OVMS7.2-2 & TCPIP I'm unable to change the method=20 I > by which the print command is sent as this is imbedded in a compiled=20 ' > application. Example of queue entry :  > 5004120  740_000270_DESP_NOTE F >                         BACKGROUND        5  Pending (queue stopped)C >         Submitted  4-JUL-2002 09:31:58.65 /NOFEED /FORM=3DDEFAULT  > /PRIORITY=3D100  >         File: G > _DSA1:[VANTAGE_FILES.COMPANY_1.SPOOL_FILES]740_000270_DESP_NOTE.XXX;1  > /DELETE /NOFEED  >=20 > Ta >=20 > Andrew Robinson    ------------------------------  % Date: Tue, 09 Jul 2002 15:21:10 +0200 9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> $ Subject: Re: Copy Printing Question.' Message-ID: <3D2AE346.70994B14@aaa.com>    OK. 0 I'd try with printing with /RETAIN=ALWAYS (or by1 setting the queue (INIT /RETAIN=ALL when created) 4 and then have a batch job periodicly scan the queue,8 print a copy and do a DELETE/ENTRY on the primary queue.   Jan-Erik Sderholm.    Andrew Robinson wrote: > J > I have an issue where a copy print is wanted of everything printed via aN > certain queue or queues, for both auditing and security reasons. It needs toM > be a hardcopy - as a physical time stamped proof copy is essential (This is  > done by the copy printer). > 	 > Regards  >  > Andrew R.  >    ------------------------------  # Date: Mon, 08 Jul 2002 12:11:16 GMT * From: "Mark Buda" <buda_NO@SPAM.yahoo.com>( Subject: Re: Cost of $CONNECT/DISCONNECT= Message-ID: <EjfW8.14087$071.3612248@news1.news.adelphia.net>   K > Looking at the doc, it seems that $CONNECT does result in internal blocks E > being allocated.  Is there much waste or impact in performance if I  $CONNECTH > more RABs than is needed, and some of the RABs remain unused ? Or am I better1 > $CONNECTing/$DISCONNECTing the RABs on demand ?   I You are better off doing the $connect one time and letting it stay across F the possible usage.  $DISCONNECT when no longer needed.  The amount of, memory used is quite low in the big picture.  G > Also, once a RAB has been $CONNECTed, can it be relocated or must its  address  > remain the same ? L > (for instance, if I grow an array of RABs and with a realloc, the location of > the array changes).   K Create an array of pointers to RAB's and allocate the RAB's on demand.  You ; can grow the array of pointers to your hearts content then.    mark   ------------------------------  % Date: Tue, 09 Jul 2002 12:04:02 +0200 3 From: Theo Jakobus <Theo.Jakobus@iaf.fraunhofer.de> . Subject: CPU time for batch job 4-MAY-1859 ???0 Message-ID: <3D2AB512.6070207@iaf.fraunhofer.de>   Hi!   R We use an Alpha2100 with 2 CPUs for our production data base, which is Rdb V7.0-1.  Z I take part in searching for extraterrestrial intelligence "SETI" by running 2 batch jobs. My actual status: c http://setiathome.ssl.berkeley.edu/fcgi-bin/fcgi?email=theo.jakobus%40iaf.fhg.de&cmd=user_stats_new   # I'm really amazed by the following:    026AXP$ SHOW SYSTEM/BATCH O OpenVMS V7.1-1H2  on node IAF026   9-JUL-2002 11:29:30.26  Uptime  340 01:04:21 G                                                                     ^^^ Y Yeah, on this server maintenance is done once a year only. Next appointment is August 10.   N    Pid    Process Name    State  Pri      I/O       CPU       Page flts  PagesO 2120011A SETI@home 54%   CUR  1   1 57563516 4-MAY-1859 04:     87961   2372  BeO 2120011B SETI@home 88%   COM      1 57460489 3-MAY-1859 19:     91649   2340  BC<                                               ^^^^^^^^^^^^^^<                                               ??????????????  / The field CPU shows the CPU time used normally.i  9 Did the extraterrestrial intelligence change the numbers?o  / 3-MAY-1859: Was the batch started at this date?s  [ 4-MAY-1859: Both batch jobs are started at the same time, why does the 2nd CPU waste a day?N     Regards, Theo Jakobus   ------------------------------  % Date: Tue, 09 Jul 2002 12:30:11 +0100o% From: Alan Greig <a.greig@virgin.net> 2 Subject: Re: CPU time for batch job 4-MAY-1859 ???8 Message-ID: <i5iliu0p9llm3lvoe6chud2i4klj5iorqt@4ax.com>  0 On Tue, 09 Jul 2002 12:04:02 +0200, Theo Jakobus' <Theo.Jakobus@iaf.fraunhofer.de> wrote:.   >Hi! >l >C >026AXP$ SHOW SYSTEM/BATCHP >OpenVMS V7.1-1H2  on node IAF026   9-JUL-2002 11:29:30.26  Uptime  340 01:04:21H >                                                                    ^^^Z >Yeah, on this server maintenance is done once a year only. Next appointment is August 10. >cO >   Pid    Process Name    State  Pri      I/O       CPU       Page flts  PagesmP >2120011A SETI@home 54%   CUR  1   1 57563516 4-MAY-1859 04:     87961   2372  BP >2120011B SETI@home 88%   COM      1 57460489 3-MAY-1859 19:     91649   2340  B= >                                              ^^^^^^^^^^^^^^D= >                                              ??????????????  > 0 >The field CPU shows the CPU time used normally. >y: >Did the extraterrestrial intelligence change the numbers? >S0 >3-MAY-1859: Was the batch started at this date? >c\ >4-MAY-1859: Both batch jobs are started at the same time, why does the 2nd CPU waste a day?  F Reminds me of TOPS-20 stating IDLE: +INF if the system had been up forE more than a few months and giving an UP2LNG (Up to long) BUGHLT if upeE for over a year. Hey the hardware couldn't be that reliable  in theseD days :-)   >  >e	 >Regards,t
 >Theo JakobusS   -- Alan   ------------------------------   Date: 9 Jul 2002 10:46:02 -0700p+ From: david.m.gray@bigfoot.com (David Gray)p) Subject: Disk drives for Digital PW 433au = Message-ID: <4da983bf.0207090946.370bb4fc@posting.google.com>t   Hi all,   E I have just bought a Digital PW 433au and am intending to run OpenVMSSF on it via the hobbyist program.   The machine has a 2gb SCSI drive andF I would like to add a further 18gb or 36gb disk to it but am wondering: if, space permitting I can add standard SCSI drives to it.  F Has anyone got one of the 433/500/600au series that has gone thru this
 route before.a  E Also I have joined CUO-UK to get the license but wonderee where I cann buy the installation CDs.V   Thanks in advance.     David Gray.o   ------------------------------  $ Date: Tue, 9 Jul 2002 14:04:00 -0400# From: "Island" <sales@islandco.com>a- Subject: Re: Disk drives for Digital PW 433au:/ Message-ID: <uim8lnit0lsre1@news.supernews.com>w  6 Yes you can add several - Hitachi has been pretty good (And we  sell them)e   Davidw      8 "David Gray" <david.m.gray@bigfoot.com> wrote in message7 news:4da983bf.0207090946.370bb4fc@posting.google.com...r	 > Hi all,s >aG > I have just bought a Digital PW 433au and am intending to run OpenVMS:H > on it via the hobbyist program.   The machine has a 2gb SCSI drive andH > I would like to add a further 18gb or 36gb disk to it but am wondering< > if, space permitting I can add standard SCSI drives to it. >tH > Has anyone got one of the 433/500/600au series that has gone thru this > route before.t >rG > Also I have joined CUO-UK to get the license but wonderee where I canE > buy the installation CDs.L >  > Thanks in advance. >C
 > David Gray.c   ------------------------------   Date: 9 Jul 2002 08:02:56 GMTc( From: nmm1@cus.cam.ac.uk (Nick Maclaren)- Subject: Re: Fearless IPF Prognostications...L0 Message-ID: <age5bg$1ei$1@pegasus.csx.cam.ac.uk>  ? In article <ZdtW8.333174$6m5.336974@rwcrnsc51.ops.asp.att.net>,- Bill <billmuy@attbi.com> wrote:-= >"Terry C. Shannon" <terryshannon@attbi.com> wrote in messageV) >news:1uiW8.438734$352.62167@sccrnsc02....8 >> "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message- >> news:agcc06$ajf$1@pegasus.csx.cam.ac.uk...  >> >G >> > This has been a feature of the larger British companies for a long F >> > time, and it is clear that some of the USA ones are attempting to& >> > emulate the UK computer industry. >>J >> I don't believe that marketing expertise is a prerequisite to corporateK >> governance, but it would seem to me that at least several members of theu >BoDK >> of a technology company should have a clue about technology. In the casee >of J >> HPQ, it would be nice to see such technological expertise extend beyond >the >> president and CEO...t >sL >Just out of curiosity, what kind of technology representation would you and& >Nick consider adequate for HPQ's BoD?  0 This is a generic response, and not HP specific.  C At least 15% of a board should be people who were actively involved(C in the (technical) business of a similar company within the past 10 B years.  And a similar proportion should have comparable experience? in the financial and marketing management.  Ditto for personnelo: management, though I would expect those people to overlap.  L >FWIW, a quick Google search on the current board shows at least 6 out of 12G >technologists, with engineering or science degrees (including a formerAK >science advisor to the US president, a wireless pioneer with a engineering K >school named after him, the first GM of HP's computer business, the father:H >of HP's printer business, and a PhD in engineering who runs the biggestK >aerospace company on the planet).  And this does not include the presidento >or CEO :-)n  F I was responding to the posting - I was surprised, but took it at faceE value.  My guess is that the difference between viewpoints is whether D the people have been active RECENTLY, which by the sound of it isn'tD the case.  That is a mistake, because people with outdated expertise( are more dangerous than those with none.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679?   ------------------------------  # Date: Tue, 09 Jul 2002 13:34:44 GMTo1 From: "Terry C. Shannon" <terryshannon@attbi.com> - Subject: Re: Fearless IPF Prognostications...r? Message-ID: <UDBW8.290722$R61.186180@rwcrnsc52.ops.asp.att.net>M  5 "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in messagee* news:age5bg$1ei$1@pegasus.csx.cam.ac.uk...A > In article <ZdtW8.333174$6m5.336974@rwcrnsc51.ops.asp.att.net>,a! > Bill <billmuy@attbi.com> wrote:k? > >"Terry C. Shannon" <terryshannon@attbi.com> wrote in message + > >news:1uiW8.438734$352.62167@sccrnsc02...U: > >> "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message/ > >> news:agcc06$ajf$1@pegasus.csx.cam.ac.uk...h > >> >I > >> > This has been a feature of the larger British companies for a long-H > >> > time, and it is clear that some of the USA ones are attempting to( > >> > emulate the UK computer industry. > >>L > >> I don't believe that marketing expertise is a prerequisite to corporateI > >> governance, but it would seem to me that at least several members of  ther > >BoDH > >> of a technology company should have a clue about technology. In the case > >ofdL > >> HPQ, it would be nice to see such technological expertise extend beyond > >the > >> president and CEO...n > >tJ > >Just out of curiosity, what kind of technology representation would you and ( > >Nick consider adequate for HPQ's BoD? >,2 > This is a generic response, and not HP specific. >-E > At least 15% of a board should be people who were actively involvedrE > in the (technical) business of a similar company within the past 10cD > years.  And a similar proportion should have comparable experienceA > in the financial and marketing management.  Ditto for personnele< > management, though I would expect those people to overlap. > K > >FWIW, a quick Google search on the current board shows at least 6 out of  12I > >technologists, with engineering or science degrees (including a former>A > >science advisor to the US president, a wireless pioneer with ar engineeringrF > >school named after him, the first GM of HP's computer business, the fatherJ > >of HP's printer business, and a PhD in engineering who runs the biggestC > >aerospace company on the planet).  And this does not include the 	 president 
 > >or CEO :-)a > H > I was responding to the posting - I was surprised, but took it at faceG > value.  My guess is that the difference between viewpoints is whether:F > the people have been active RECENTLY, which by the sound of it isn'tF > the case.  That is a mistake, because people with outdated expertise* > are more dangerous than those with none. >a  C Yep, recent involvement is a good thing. From what I have seen, biglI corporations generally appoint middle-aged (e.g. >50 years old) people towJ their boards, in many cases these folks are no longer actively involved inI the oversight of technological undertakings. One exception: Jesse Lipcon,oJ who left CPQ a couple of years ago. His post-CPQ career plan was to sit on+ the boards of several technology companies.n   ------------------------------  * Date: Tue, 9 Jul 2002 12:48:30 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: Lynx & SSL + Message-ID: <agem2u$rkn$1@aquila.mdx.ac.uk>D  \ In article <agd6at$hcu$1@news1.Radix.Net>, Thomas Dickey <dickey@saltmine.radix.net> writes:  >david20@alpha1.mdx.ac.uk wrote:Q >> Yes that explains it. I was following the instructions in the INSTALL.VMS filei >> which just specifies :- >.6 >> @MAKEVMS <option> <rsaref-p> <debug-p> [<compiler>] >p" >> no mention of any p5 parameter. >eP >> I've just now been to Robert Byer's excellent site where it does document the >> p5 parameter. > 6 >a url would help (google shows me only defunct links) >    As requested :-2  E http://www.ourservers.net/openvms_ports/openssl/OPENSSL_CONTENTS.HTMLD   and in particular   C http://www.ourservers.net/openvms_ports/openssl/openssl2.html#ss2.4     
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------   Date: 9 Jul 2002 09:43:16 GMT?( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: McKinley Cometh...60 Message-ID: <ageb7k$68h$1@pegasus.csx.cam.ac.uk>  B Well, McKinley may be announced, but there is little evidence that: HP are backing up their fine words with buttered parsnips.  D HP's "buy online" for the USA has only the zx2000 (plus its 6 MercedD configurations) and says "There is no stock currently available" for all of them.  E Neither the zx2000 nor the zx6000 are in HP's UK list yet.  And, yes,m$ we are a serious potential customer!  ? If anyone manages to buy one using a normal mechanism, I shouldu@ appreciate hearing what, for delivery when and in which country.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679e   ------------------------------   Date: 9 Jul 2002 05:32:22 -0600 - From: Kilgallen@SpamCop.net (Larry Kilgallen)  Subject: Re: McKinley Cometh...93 Message-ID: <OqzEjXTF696d@eisner.encompasserve.org>   [ In article <ageb7k$68h$1@pegasus.csx.cam.ac.uk>, nmm1@cus.cam.ac.uk (Nick Maclaren) writes:L > D > Well, McKinley may be announced, but there is little evidence that< > HP are backing up their fine words with buttered parsnips. > F > HP's "buy online" for the USA has only the zx2000 (plus its 6 MercedF > configurations) and says "There is no stock currently available" for > all of them. > G > Neither the zx2000 nor the zx6000 are in HP's UK list yet.  And, yes, & > we are a serious potential customer!  D The web pages I read from the announcement said "Available in July".4 In vendorese that is different from "Available now".   ------------------------------  % Date: Tue, 09 Jul 2002 11:35:46 +0100-& From: Ken Green <Ken.Green@kgcc.co.uk> Subject: Re: McKinley Cometh...n* Message-ID: <3D2ABC82.5BB52E84@kgcc.co.uk>   Nick Maclaren wrote:  D > Well, McKinley may be announced, but there is little evidence that< > HP are backing up their fine words with buttered parsnips. >tF > HP's "buy online" for the USA has only the zx2000 (plus its 6 MercedF > configurations) and says "There is no stock currently available" for > all of them. > G > Neither the zx2000 nor the zx6000 are in HP's UK list yet.  And, yes,S& > we are a serious potential customer! >0A > If anyone manages to buy one using a normal mechanism, I shouldrB > appreciate hearing what, for delivery when and in which country. >n
 > Regards, > Nick Maclaren,, > University of Cambridge Computing Service,@ > New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. > Email:  nmm1@cam.ac.uk1 > Tel.:  +44 1223 334761    Fax:  +44 1223 334679o  E Well the register this morning said that the boxes where due to start  shipping in August.   1     http://theregister.co.uk/content/3/26097.htmlL  > For UK pricing, I'm sure that there must be a sales team at HP3 that focus on Universities, try giving them a call.L   Cheers   Ken_   ------------------------------   Date: 9 Jul 2002 10:45:48 GMTb( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: McKinley Cometh... 0 Message-ID: <ageess$9ho$1@pegasus.csx.cam.ac.uk>  3 In article <OqzEjXTF696d@eisner.encompasserve.org>, / Kilgallen@SpamCop.net (Larry Kilgallen) writes: 3 |> In article <ageb7k$68h$1@pegasus.csx.cam.ac.uk>,t- |> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:  |> > nG |> > Well, McKinley may be announced, but there is little evidence thatE? |> > HP are backing up their fine words with buttered parsnips.b |> > rI |> > HP's "buy online" for the USA has only the zx2000 (plus its 6 MercedtI |> > configurations) and says "There is no stock currently available" for. |> > all of them.a |> > pJ |> > Neither the zx2000 nor the zx6000 are in HP's UK list yet.  And, yes,) |> > we are a serious potential customer!n |> RG |> The web pages I read from the announcement said "Available in July".17 |> In vendorese that is different from "Available now".c   From HP's own Web pages:  A hp part #    product name             unit price    usually ships   A A8081A   hp zx2000 w/900MHz Intel     $5,834.00     backordered n  "          Itanium 2 processor, ATI"          Radeon 7000 graphics, 1GB          DDR-SDRAM, 40GB HD,          HP-UX 11i          (Lease at $171.87/mo2)?$                                     @ ?Usually ships? provides our best estimate of when products will ship to you. Options are: 	  1-2 dayss9                 'Usually ships' within 1-2 business days. 	  3-5 days 9                 'Usually ships' within 3-5 business days. 	  8-9 daysh9                 'Usually ships' within 8-9 business days.s
  1-2 weeks1                 'Usually ships' within 1-2 weeks.f  backordered6                 There is no stock currently available.    A "Available in July" seems unlikely.  "Orderable in July" perhaps.      Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679c   ------------------------------  # Date: Tue, 09 Jul 2002 12:40:57 GMTa( From: "Alberto" <uapalbertobu@libero.it> Subject: Re: McKinley Cometh...i7 Message-ID: <tRAW8.13228$K_4.329460@twister1.libero.it>c  h "Nick Maclaren" <nmm1@cus.cam.ac.uk> ha scritto nel messaggio news:ageb7k$68h$1@pegasus.csx.cam.ac.uk... >sD > Well, McKinley may be announced, but there is little evidence that< > HP are backing up their fine words with buttered parsnips. >WF > HP's "buy online" for the USA has only the zx2000 (plus its 6 MercedF > configurations) and says "There is no stock currently available" for > all of them. > G > Neither the zx2000 nor the zx6000 are in HP's UK list yet.  And, yes,p& > we are a serious potential customer! >sA > If anyone manages to buy one using a normal mechanism, I should0B > appreciate hearing what, for delivery when and in which country.   You have too hurry :-).e. Itanic performs very well now, but 2 years are5 necessary to penetrate a full of difficulties market. + How many years are necessary to Opteron for  same things? (10?).  Bye. Alberto.   ------------------------------   Date: 9 Jul 2002 13:09:49 GMTt( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: McKinley Cometh...t0 Message-ID: <agenat$gsj$1@pegasus.csx.cam.ac.uk>  7 In article <tRAW8.13228$K_4.329460@twister1.libero.it>,a* "Alberto" <uapalbertobu@libero.it> writes: |> -G |> > Well, McKinley may be announced, but there is little evidence thatG? |> > HP are backing up their fine words with buttered parsnips.- |> >I |> > HP's "buy online" for the USA has only the zx2000 (plus its 6 Merced I |> > configurations) and says "There is no stock currently available" forw |> > all of them.  |> >J |> > Neither the zx2000 nor the zx6000 are in HP's UK list yet.  And, yes,) |> > we are a serious potential customer!  |> >D |> > If anyone manages to buy one using a normal mechanism, I shouldE |> > appreciate hearing what, for delivery when and in which country.t |>   |> You have too hurry :-).   Perhaps :-)   1 |> Itanic performs very well now, but 2 years areE8 |> necessary to penetrate a full of difficulties market.  @ Considering that we have been getting an earful of how wonderfulA the imminent IA-64 systems will be for over 5 years now, I am not @ sympathetic.  More seriously, this is IA-64's last chance; if it3 isn't established within 12-18 months, it will die.t  > My belief is that HP got Intel to 'launch' so that HP can sell= into one or more large USA military/HPC sites without forcings; every user to sign an Intel NDA.  It is quite possible thata= even HP will not start selling IA-64 systems seriously on theS; open market until the autumn.  Or they might start to do soa' tomorrow.  Any information appreciated.o  . |> How many years are necessary to Opteron for |> same things? (10?).  A Much less.  It is an incremental solution, not a replacement one. ? In particular, it is reported to run legacy (IA-32) code nearly:@ as fast as x86-64 code, so developers and customers have an easy
 upgrade path.f  ; Most observers believe that serious Opteron servers will be@@ available by March 2003, and that the performance will be betterC than the McKinley for most work, though worse for number crunching.r= If McKinley has failed to establish by then, Madison may also 7 fail to establish, and the IA-64 project will collapse.p     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679    ------------------------------  # Date: Tue, 09 Jul 2002 13:27:52 GMT ( From: "Alberto" <uapalbertobu@libero.it> Subject: Re: McKinley Cometh...r7 Message-ID: <sxBW8.15370$7N3.339230@twister2.libero.it>v  = "Nick Maclaren" <nmm1@cus.cam.ac.uk> ha scritto nel messaggioe    = > Most observers believe that serious Opteron servers will be B > available by March 2003, and that the performance will be betterE > than the McKinley for most work, though worse for number crunching.o? > If McKinley has failed to establish by then, Madison may also39 > fail to establish, and the IA-64 project will collapse.i  @ Ummm...... Madison = 1.7-1.8Ghz cpu + 6Mb L3, with 1450+ specintC and 2430+specfpu, an other class of cpu respect Opteron ( no serius  compiler yet ).aK This numbers are explicit and other consideration are only pessimistic :-). 1 Itanium do not collapse, shure. Give him 2 years.r Bye. Alberto.   ------------------------------  # Date: Tue, 09 Jul 2002 13:36:34 GMTt1 From: "Terry C. Shannon" <terryshannon@attbi.com>i Subject: Re: McKinley Cometh...-? Message-ID: <CFBW8.337959$6m5.348722@rwcrnsc51.ops.asp.att.net>.  5 "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in messaget* news:agenat$gsj$1@pegasus.csx.cam.ac.uk... >.9 > In article <tRAW8.13228$K_4.329460@twister1.libero.it>,., > "Alberto" <uapalbertobu@libero.it> writes: > |>I > |> > Well, McKinley may be announced, but there is little evidence thatWA > |> > HP are backing up their fine words with buttered parsnips.a > |> >K > |> > HP's "buy online" for the USA has only the zx2000 (plus its 6 MercediK > |> > configurations) and says "There is no stock currently available" fora > |> > all of them.o > |> >L > |> > Neither the zx2000 nor the zx6000 are in HP's UK list yet.  And, yes,+ > |> > we are a serious potential customer!p > |> >F > |> > If anyone manages to buy one using a normal mechanism, I shouldG > |> > appreciate hearing what, for delivery when and in which country.u > |> > |> You have too hurry :-). > 
 > Perhaps :-)d > 3 > |> Itanic performs very well now, but 2 years ared: > |> necessary to penetrate a full of difficulties market. >hB > Considering that we have been getting an earful of how wonderfulC > the imminent IA-64 systems will be for over 5 years now, I am notiB > sympathetic.  More seriously, this is IA-64's last chance; if it5 > isn't established within 12-18 months, it will die.a >w  $ Sounds like a reasonable assessment.   ------------------------------  # Date: Tue, 09 Jul 2002 13:47:01 GMTe( From: "Alberto" <uapalbertobu@libero.it> Subject: Re: McKinley Cometh...h7 Message-ID: <pPBW8.15442$7N3.340525@twister2.libero.it>   D "Terry C. Shannon" <terryshannon@attbi.com> ha scritto nel messaggio9 news:CFBW8.337959$6m5.348722@rwcrnsc51.ops.asp.att.net...v >r7 > "Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in messagen, > news:agenat$gsj$1@pegasus.csx.cam.ac.uk... > >o; > > In article <tRAW8.13228$K_4.329460@twister1.libero.it>,a. > > "Alberto" <uapalbertobu@libero.it> writes: > > |>K > > |> > Well, McKinley may be announced, but there is little evidence that C > > |> > HP are backing up their fine words with buttered parsnips.a > > |> >M > > |> > HP's "buy online" for the USA has only the zx2000 (plus its 6 MercedvM > > |> > configurations) and says "There is no stock currently available" fors > > |> > all of them.t > > |> >N > > |> > Neither the zx2000 nor the zx6000 are in HP's UK list yet.  And, yes,- > > |> > we are a serious potential customer!  > > |> >H > > |> > If anyone manages to buy one using a normal mechanism, I shouldI > > |> > appreciate hearing what, for delivery when and in which country.- > > |> > > |> You have too hurry :-). > >  > > Perhaps :-)y > >h5 > > |> Itanic performs very well now, but 2 years are < > > |> necessary to penetrate a full of difficulties market. > >nD > > Considering that we have been getting an earful of how wonderfulE > > the imminent IA-64 systems will be for over 5 years now, I am notdD > > sympathetic.  More seriously, this is IA-64's last chance; if it7 > > isn't established within 12-18 months, it will die.b > >> >o& > Sounds like a reasonable assessment.  # Catastrophic assessment............e+ The chip in question is a Intel's chip ;-).>- Opteron is a outsider's chip (or HT's chip?).  Bye. Alberto.   ------------------------------   Date: 9 Jul 2002 14:41:44 GMT ( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: McKinley Cometh...>0 Message-ID: <agesn8$lbr$1@pegasus.csx.cam.ac.uk>  7 In article <sxBW8.15370$7N3.339230@twister2.libero.it>,o* "Alberto" <uapalbertobu@libero.it> writes:@ |> "Nick Maclaren" <nmm1@cus.cam.ac.uk> ha scritto nel messaggio |> h@ |> > Most observers believe that serious Opteron servers will beE |> > available by March 2003, and that the performance will be bettereH |> > than the McKinley for most work, though worse for number crunching.B |> > If McKinley has failed to establish by then, Madison may also< |> > fail to establish, and the IA-64 project will collapse. |> nC |> Ummm...... Madison = 1.7-1.8Ghz cpu + 6Mb L3, with 1450+ specintpF |> and 2430+specfpu, an other class of cpu respect Opteron ( no serius |> compiler yet ).N |> This numbers are explicit and other consideration are only pessimistic :-).4 |> Itanium do not collapse, shure. Give him 2 years.  ? I said better than the McKinley.  My current guess is a SpecInt < of 800-900 in x86-64 mode and 700-800 in IA-32 mode in 1Q03. But time will tell.o  = If the Madison runs at 1.7-1.8 GHz and delivers 1450+ SpecInt = and 2430+ SpecFP within 12 months, I shall be most impressed. = I suspect that 1.5 GHz and 1200 SpecInt on HP systems and 950i7 on Intel ones at this time next year is more plausible.      Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679    ------------------------------  # Date: Tue, 09 Jul 2002 15:11:45 GMTe( From: "Alberto" <uapalbertobu@libero.it> Subject: Re: McKinley Cometh...Y7 Message-ID: <R2DW8.15719$7N3.345305@twister2.libero.it>m  = "Nick Maclaren" <nmm1@cus.cam.ac.uk> ha scritto nel messaggioo    A > I said better than the McKinley.  My current guess is a SpecInt.> > of 800-900 in x86-64 mode and 700-800 in IA-32 mode in 1Q03. > But time will tell.s  ( Yes but.....where is sw for x86-64 mode?   >s? > If the Madison runs at 1.7-1.8 GHz and delivers 1450+ SpecIntn? > and 2430+ SpecFP within 12 months, I shall be most impressed.Q? > I suspect that 1.5 GHz and 1200 SpecInt on HP systems and 950h9 > on Intel ones at this time next year is more plausible.-  < 1.8Ghz, i think, is the target for 0.13u process....Q4 2003?; After this, go to 0.09u process ( 60/35nm=1.71......3Ghz ?)s8 With this process, Itanium is more powerfull of Opteron.; The Intel choice is process, Amd have little chance in thisa arena in future........... Hpq know that. But time will tell ;-).i Bye. Alberto.   ------------------------------   Date: 9 Jul 2002 15:31:43 GMTc( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: McKinley Cometh...>0 Message-ID: <agevkv$nsi$1@pegasus.csx.cam.ac.uk>  7 In article <R2DW8.15719$7N3.345305@twister2.libero.it>,u* "Alberto" <uapalbertobu@libero.it> writes:@ |> "Nick Maclaren" <nmm1@cus.cam.ac.uk> ha scritto nel messaggio |> tD |> > I said better than the McKinley.  My current guess is a SpecIntA |> > of 800-900 in x86-64 mode and 700-800 in IA-32 mode in 1Q03.n |> > But time will tell. |> a+ |> Yes but.....where is sw for x86-64 mode?d  D Where the software for IA-64 was at the same stage.  In development.# We shall know more in a few months.k  B |> > If the Madison runs at 1.7-1.8 GHz and delivers 1450+ SpecIntB |> > and 2430+ SpecFP within 12 months, I shall be most impressed.B |> > I suspect that 1.5 GHz and 1200 SpecInt on HP systems and 950< |> > on Intel ones at this time next year is more plausible. |> t? |> 1.8Ghz, i think, is the target for 0.13u process....Q4 2003?n  < Very likely.  Hence my remark.  By the time that the MadisonB reaches 1.8 GHz, it is likely that the Opteron will be at 2.5 GHz,? perhaps 3.0 GHz.  If AMD introduce a large cache version at thea= latter speed, Opteron, too, could reach 1200 SpecInt.  Maybe.v  > It is also rumoured that two Opterons will cost about the same; as one Madison, in terms of dollars, square centimetres andb? watts.  If that is so, the small server performance comparisons 3 swing solidly into Opteron's favour.  We shall see.-  > |> After this, go to 0.09u process ( 60/35nm=1.71......3Ghz ?)  = Before that comes, the battle will have been lost and won, orn? at least fought to an inconclusive result.  0.1 micron will notg< be relevant before 2004, and we shall know the result before then.c  ; |> With this process, Itanium is more powerfull of Opteron.n> |> The Intel choice is process, Amd have little chance in this |> arena in future...........n  @ Really?  Intel used to have a 12 months lead in the introduction< of new processes, but it is down to about 6 months now.  You> must remember that AMD can buy in fab capacity from (say) IBM.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679e   ------------------------------  % Date: Tue, 09 Jul 2002 11:44:21 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>  Subject: Re: McKinley Cometh... , Message-ID: <3D2B04D1.91F07628@videotron.ca>   Alberto wrote:0 > Itanic performs very well now, but 2 years are7 > necessary to penetrate a full of difficulties market.w- > How many years are necessary to Opteron forn > same things? (10?).n  M Considering that a full Windows won't be available on IA64 until next year, IuL think that software availability on IA64 will be the major issue in the next couple of years.  L On the other hand, Hammer, being compatible with the 8086, should be able toI run existing software and benefit from a much greater wealth of software.w  L Now, if Windows on 32 bits has a reliability factor of "1", what will be itsM relative reliability on IA64 ? A new architecture, and a change from 32 to 64eN bits does lead on to have much confidence that microsoft would be able to make( thew new version for IA64 more reliable.  M Intel will have to have a lot of staying power to sustain IA64 until there is G sufficient software to allow that platform to start to taken seriously.    ------------------------------  % Date: Tue, 09 Jul 2002 11:47:57 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>- Subject: Re: McKinley Cometh...a, Message-ID: <3D2B05A9.48DF90CE@videotron.ca>   Nick Maclaren wrote:? > If McKinley has failed to establish by then, Madison may alsoa9 > fail to establish, and the IA-64 project will collapse.p  L IA64 won't collapse. It would simply be scaled back to the Alpha scale whereM it becomes a proprietary low volume chip used by HP to run HP-UX and NSK (andr VMS if still alive).  N If IA64 doesn't take off in sufficient volumes, it will be most interesting toP see Microsoft's reaction with regards to continued Windows availability on IA64.   ------------------------------  % Date: Tue, 09 Jul 2002 11:57:02 -0400a- From: JF Mezei <jfmezei.spamnot@videotron.ca>  Subject: Re: McKinley Cometh... , Message-ID: <3D2B07C9.D28B2D2B@videotron.ca>  J Since one needs special compilers to use EPIC's potential for performance,L what will happen to all the applications (especially public domain) that are, designed to be compiled with GNU compilers ?  L Will GNU compilers be made to adapt to IA64's EPIC requirements or will theyC just generate "vanilla" code that will greatly slow down the chip ?$   ------------------------------  # Date: Tue, 09 Jul 2002 16:11:35 GMT ( From: "Alberto" <uapalbertobu@libero.it> Subject: Re: McKinley Cometh...i7 Message-ID: <XWDW8.13988$K_4.342777@twister1.libero.it>   = "Nick Maclaren" <nmm1@cus.cam.ac.uk> ha scritto nel messaggion  A > |> 1.8Ghz, i think, is the target for 0.13u process....Q4 2003?  >U> > Very likely.  Hence my remark.  By the time that the MadisonD > reaches 1.8 GHz, it is likely that the Opteron will be at 2.5 GHz,A > perhaps 3.0 GHz.  If AMD introduce a large cache version at the ? > latter speed, Opteron, too, could reach 1200 SpecInt.  Maybe.   * 2.5G or 3G with 0.13u ? Naaaa.............# Yes, when it go to 0.09u, but when?n< Intel's process leadership is clear, and the other companies are hungry.r   >o@ > It is also rumoured that two Opterons will cost about the same= > as one Madison, in terms of dollars, square centimetres and4A > watts.  If that is so, the small server performance comparisons-5 > swing solidly into Opteron's favour.  We shall see.b  > Speculation..............sure in terms of watts i don't agree.   >g@ > |> After this, go to 0.09u process ( 60/35nm=1.71......3Ghz ?) > ? > Before that comes, the battle will have been lost and won, oreA > at least fought to an inconclusive result.  0.1 micron will nott> > be relevant before 2004, and we shall know the result before > then.u  A The 0.13u node is sufficent for battle. Amd is now in difficoult,22 and Umc don't have aggressive process in schedule.  B > Really?  Intel used to have a 12 months lead in the introduction> > of new processes, but it is down to about 6 months now.  You@ > must remember that AMD can buy in fab capacity from (say) IBM.  I Outsourcing ? bad job if porpouse is frequency scaling.....Sun know that.f Bye. Alberto.   ------------------------------  % Date: Tue, 09 Jul 2002 18:12:41 +0200l( From: Bernd Paysan <bernd.paysan@gmx.de> Subject: Re: McKinley Cometh...t, Message-ID: <p12fga.9uo.ln@miriam.mikron.de>   Nick Maclaren wrote:> > Very likely.  Hence my remark.  By the time that the MadisonD > reaches 1.8 GHz, it is likely that the Opteron will be at 2.5 GHz,A > perhaps 3.0 GHz.  If AMD introduce a large cache version at thea? > latter speed, Opteron, too, could reach 1200 SpecInt.  Maybe.>  J I thought the current Athlons (at 1.8GHz, end 0.18u/initial 0.13u) should K already be in the ~700 SpecInt range. The Hammer has several improvements, rJ which should give about 25% per-clock improvement. Also, it's a SOI chip, F which reduces gate delay by about 30% - and since other things didn't I change much, you can expect a 30% higher clock. 1200 SpecInt should be a >H target you can easily get with initial chips, without larger caches and 
 such like.  L The downside is that the available x86-64 compiler now is a real production K compiler (GCC), and not some hot speed special tuning compiler nobody uses nK to compile their apps. This gives lower SpecInt numbers. But for the user, I this is barely relevant.   --   Bernd Paysan7 "If you want it done right, you have to do it yourself"  http://www.jwdt.com/~paysan/   ------------------------------  # Date: Tue, 09 Jul 2002 16:41:53 GMTf% From: "Alberto" <albertobu@libero.it>e Subject: Re: McKinley Cometh...67 Message-ID: <lnEW8.16059$7N3.351013@twister2.libero.it>n  d "Bernd Paysan" <bernd.paysan@gmx.de> ha scritto nel messaggio news:p12fga.9uo.ln@miriam.mikron.de... > Nick Maclaren wrote:@ > > Very likely.  Hence my remark.  By the time that the MadisonF > > reaches 1.8 GHz, it is likely that the Opteron will be at 2.5 GHz,C > > perhaps 3.0 GHz.  If AMD introduce a large cache version at theaA > > latter speed, Opteron, too, could reach 1200 SpecInt.  Maybe.  >eK > I thought the current Athlons (at 1.8GHz, end 0.18u/initial 0.13u) shouldtL > already be in the ~700 SpecInt range. The Hammer has several improvements,4 > which should give about 25% per-clock improvement.   In all application? :-).   > Also, it's a SOI chip,G > which reduces gate delay by about 30% - and since other things didn'ty1 > change much, you can expect a 30% higher clock.r  3 I don't expect over a 10-15% higher clock with Soi.b   > 1200 SpecInt should be aI > target you can easily get with initial chips, without larger caches ande > such like.   You are very very optimistic.i  M > The downside is that the available x86-64 compiler now is a real productionoL > compiler (GCC), and not some hot speed special tuning compiler nobody usesL > to compile their apps. This gives lower SpecInt numbers. But for the user, > this is barely relevant.   Shure? Bye. Albertol   ------------------------------   Date: 9 Jul 2002 16:37:08 GMTs From: Dan.Pop@ifh.de (Dan Pop) Subject: Re: McKinley Cometh...m* Message-ID: <agf3fk$atr$1@sunnews.cern.ch>  S In <3D2B07C9.D28B2D2B@videotron.ca> JF Mezei <jfmezei.spamnot@videotron.ca> writes:h  K >Since one needs special compilers to use EPIC's potential for performance,rM >what will happen to all the applications (especially public domain) that arey- >designed to be compiled with GNU compilers ?a  A The Intel compilers (whose Linux versions are available for free)hB are front end compatible with the GNU compilers (i.e. they support the GNU extensions).  M >Will GNU compilers be made to adapt to IA64's EPIC requirements or will theyoD >just generate "vanilla" code that will greatly slow down the chip ?   Time will tell.l   Dan  -- Dan Pop- DESY Zeuthen, RZ group Email: Dan.Pop@ifh.de:   ------------------------------  # Date: Tue, 09 Jul 2002 16:45:55 GMTR% From: "Alberto" <albertobu@libero.it>B Subject: Re: McKinley Cometh...s7 Message-ID: <7rEW8.16078$7N3.351340@twister2.libero.it>o  i "JF Mezei" <jfmezei.spamnot@videotron.ca> ha scritto nel messaggio news:3D2B04D1.91F07628@videotron.ca.... > Alberto wrote:2 > > Itanic performs very well now, but 2 years are9 > > necessary to penetrate a full of difficulties market.d/ > > How many years are necessary to Opteron foro > > same things? (10?).s > O > Considering that a full Windows won't be available on IA64 until next year, IeN > think that software availability on IA64 will be the major issue in the next > couple of years. > N > On the other hand, Hammer, being compatible with the 8086, should be able toK > run existing software and benefit from a much greater wealth of software.m >gN > Now, if Windows on 32 bits has a reliability factor of "1", what will be itsO > relative reliability on IA64 ? A new architecture, and a change from 32 to 64 P > bits does lead on to have much confidence that microsoft would be able to make* > thew new version for IA64 more reliable. >rO > Intel will have to have a lot of staying power to sustain IA64 until there ishI > sufficient software to allow that platform to start to taken seriously.e  # Yes but where are x86-64 compilers?a( Do you hope a Intel 6.0 C++ for x86-64 ? Sorry don't exist. Bye. Alberto.   ------------------------------  # Date: Tue, 09 Jul 2002 16:49:12 GMT % From: "Alberto" <albertobu@libero.it>  Subject: Re: McKinley Cometh...e7 Message-ID: <cuEW8.14150$K_4.346076@twister1.libero.it>B  d "Bernd Paysan" <bernd.paysan@gmx.de> ha scritto nel messaggio news:p12fga.9uo.ln@miriam.mikron.de... > Nick Maclaren wrote:@ > > Very likely.  Hence my remark.  By the time that the MadisonF > > reaches 1.8 GHz, it is likely that the Opteron will be at 2.5 GHz,C > > perhaps 3.0 GHz.  If AMD introduce a large cache version at the.A > > latter speed, Opteron, too, could reach 1200 SpecInt.  Maybe.> > K > I thought the current Athlons (at 1.8GHz, end 0.18u/initial 0.13u) should L > already be in the ~700 SpecInt range. The Hammer has several improvements,4 > which should give about 25% per-clock improvement.   In all application? :-).   > Also, it's a SOI chip,G > which reduces gate delay by about 30% - and since other things didn't 1 > change much, you can expect a 30% higher clock.0  3 I don't expect over a 10-15% higher clock with Soi.    > 1200 SpecInt should be aI > target you can easily get with initial chips, without larger caches and  > such like.   You are very very optimistic.e  M > The downside is that the available x86-64 compiler now is a real production L > compiler (GCC), and not some hot speed special tuning compiler nobody usesL > to compile their apps. This gives lower SpecInt numbers. But for the user, > this is barely relevant.   Shure? Bye. Alberton   ------------------------------   Date: 9 Jul 2002 16:50:31 GMT,( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: McKinley Cometh...i0 Message-ID: <agf48n$riu$1@pegasus.csx.cam.ac.uk>  7 In article <7rEW8.16078$7N3.351340@twister2.libero.it>,n' "Alberto" <albertobu@libero.it> writes:e |>  & |> Yes but where are x86-64 compilers?+ |> Do you hope a Intel 6.0 C++ for x86-64 ?) |> Sorry don't exist.-  > Look, the first IA-64 products were nominally available a year: ago.  The first x86-64 products aren't due until 4Q02.  It= isn't surprising that software for the former is more readily ? available - if it were not so, it would be clear that the IA-64r platform was dead.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679w   ------------------------------  % Date: Tue, 09 Jul 2002 17:58:32 +0100eU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>f Subject: Re: McKinley Cometh...r0 Message-ID: <agf4mn$l4s$1@new-usenet.uk.sun.com>   JF Mezei wrote:6   > Alberto wrote: > 0 >>Itanic performs very well now, but 2 years are7 >>necessary to penetrate a full of difficulties market.b- >>How many years are necessary to Opteron forl >>same things? (10?).I >> > O > Considering that a full Windows won't be available on IA64 until next year, IcN > think that software availability on IA64 will be the major issue in the next > couple of years. >   @ The availability of IA-64 compiled software is the major problemB compounded by the fact that it needs to be compiled with the right compiler (HP's for HP-UX).  A HP's own benchmarks show pretty conclusively that IA-64 emulating D in this case HP-PA is not a good thing but that is what particularlyC in the x86->IA-64 space will be what most ISV's will be relying on.r Binary emulation.n  A Intels and HP's need not to break binary compatibility or perhaps3@ their lack of confidence that they could carry the ISV's is bothB an advantage, it does allow you to say that apps will run and also the IA-64's achilles heal.  F Most ISV's want an easy life and presented with an option of compiling@ and possibly having to modify their code to run on IA-64 or justC allowing the binary compatibility to do its work many will take the8C latter option despite its rather horrible performance consequences.   A If I was a hardware vendor being courted by Intel I would be verynA wary of IA-64 unless I could be sure that Intels compilers that It@ would have access to will deliver a similar level of performance on my box as it does on HP's.m  @ Its rather extraordinary that HP/Intel have set out to create anB industry standard CPU and a commodity 64 bit platform and straight@ away have tilted the playing field so that in fact the platforms are not commodities.  = How long will it be before HP starts to market the benefit ofh= buying boxes that run apps compiled with their compiler basedw6 on the performance advantage provided by the compiler.  9 Is it suprising that Dell/IBM etc are less than enthused.    Regardsc Andrew Harrisonk   ------------------------------  % Date: Tue, 09 Jul 2002 17:14:57 -0000a% From: gavin@allegro.com (Gavin Scott). Subject: Re: McKinley Cometh...i/ Message-ID: <uim6ghm92mjec6@news.supernews.com>    Nick wrote:e  F > HP's "buy online" for the USA has only the zx2000 (plus its 6 MercedF > configurations) and says "There is no stock currently available" for > all of them.   You might find more info at:  "    https://www.e-solutions.hp.com/  G which lets you configure and price all the new I2 systems.  The optionsaD are rather limited it seems, especially in terms of choosing a videoH card for the workstation models, but for HP this is way more information* than you used to be able to get online :-)   G.   ------------------------------  * Date: Tue, 9 Jul 2002 17:17:22 +0000 (UTC)7 From: dsiebert@excisethis.khamsin.net (Douglas Siebert)l Subject: Re: McKinley Cometh...k+ Message-ID: <agf5r2$j8e$1@sword.avalon.net>n  * nmm1@cus.cam.ac.uk (Nick Maclaren) writes:  @ >I said better than the McKinley.  My current guess is a SpecInt= >of 800-900 in x86-64 mode and 700-800 in IA-32 mode in 1Q03.c >But time will tell.    B I'd be very, very, very surprised if it doesn't easily exceed 1000G Specint in IA-32 at first release.  If your predictions are correct, it B will be barely beating .18u Athlons (749 Specint for the XP 2100+)G Surely the shift to .13u SOI, two more pipeline stages, and two on chipfE DDR controllers can add performance, if your expectations are correct1A AMD should have cancelled Hammer and had all their good engineerss* working on the Athlon .13u shrink instead!  G I don't think compilation is the problem people make it out to be.  AMD A will be hindered slightly by the fact they'll get their best SPECmF results in IA-32 mode using Intel's compiler (which they currently useD for Athlon)  But given the immaturity of IA64 support in GCC, HammerI will clean McKinley's (and its successors') clock on Linux.  Hammer losesiF performance using GCC, but not nearly as much as McKinley loses.  EvenD a .09u McKinley with 6MB cache probably has no chance against a .13u@ Hammer where GCC is concerned.  So goodbye Linux market on IA64.  H IA64's problem is that its performance advantage is most significant forF FP (which far fewer server customers care about than int) and it won'tE be very competitive on Linux.  People don't use Windows for FP numberoH crunching, so the platform of choice for that market will be HP-UX.  ButG a good segment of the big FP market has already decided it is better toaE fill a few racks with cheap x86 systems running Linux.  For int work, D IA64 doesn't look to keep ahead of P4 & Hammer.  At .18u, it is onlyE about 15% ahead of the fastest .18u P4, and slower than AMD's fastestrF .18u Athlon.  P4 & Athlon/Hammer will be constantly improved, it looksE like IA64 gets only shrinks and some additional L3 cache for the nexti couple years.  Oops!   --H Douglas Siebert                          dsiebert@excisethis.khamsin.net  J A good friend will help you move, a true friend will help you move a body.   ------------------------------   Date: 9 Jul 2002 17:22:08 GMTd( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: McKinley Cometh...c0 Message-ID: <agf640$t0r$1@pegasus.csx.cam.ac.uk>  7 In article <cuEW8.14150$K_4.346076@twister1.libero.it>,a' "Alberto" <albertobu@libero.it> writes: g |> "Bernd Paysan" <bernd.paysan@gmx.de> ha scritto nel messaggio news:p12fga.9uo.ln@miriam.mikron.de...- |>   |> > Also, it's a SOI chip,5J |> > which reduces gate delay by about 30% - and since other things didn't4 |> > change much, you can expect a 30% higher clock. |> >6 |> I don't expect over a 10-15% higher clock with Soi.  A Well, considering AMD get 1733 MHz with a 0.18 process, don't you4C think that 2500 MHz with a 0.13 SOI process is fairly conservative?c   |> > 1200 SpecInt should be aeL |> > target you can easily get with initial chips, without larger caches and |> > such like.a |> .  |> You are very very optimistic.  6 The mind boggles.  If I remind you of what you posted:  B   Ummm...... Madison = 1.7-1.8Ghz cpu + 6Mb L3, with 1450+ specintE   and 2430+specfpu, an other class of cpu respect Opteron ( no serius    compiler yet ).z<   This numbers are explicit and other consideration are only   pessimistic :-).  C You are assuming that Intel can get an almost 80% increase in clocko? speed (and hence performance) by shrinking to 0.13, but you arehA claiming that expecting AMD to get a 45% increase in the same wayc is very, very optimistic.?  B Yes, of course, AMD could make a complete pig's ear of the Opteron@ or could be lying through their teeth that the Opteron is fasterA than the Athlon at the same clock speed, but you are assuming oneu
 or the other.      Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679>   ------------------------------  % Date: Tue, 09 Jul 2002 10:41:02 -0700l& From: Greg Cagle <gregc@gregcagle.com> Subject: Re: McKinley Cometh...,, Message-ID: <3D2B202E.2070108@gregcagle.com>   Douglas Siebert wrote:   <snip>  I > I don't think compilation is the problem people make it out to be.  AMDcC > will be hindered slightly by the fact they'll get their best SPEC.H > results in IA-32 mode using Intel's compiler (which they currently useF > for Athlon)  But given the immaturity of IA64 support in GCC, HammerK > will clean McKinley's (and its successors') clock on Linux.  Hammer losesrH > performance using GCC, but not nearly as much as McKinley loses.  EvenF > a .09u McKinley with 6MB cache probably has no chance against a .13uB > Hammer where GCC is concerned.  So goodbye Linux market on IA64.  K But gcc isn't the only Linux compiler for IA-64. Intel has a gcc-compatible B compiler. Granted it's not producing the same results as the HP-UX* compilers, but it's still better than gcc.   <snip>   -- o
 Greg Cagle gregc at gregcagle dot com   ------------------------------  # Date: Tue, 09 Jul 2002 17:44:42 GMTa% From: "Alberto" <albertobu@libero.it>m Subject: Re: McKinley Cometh...n7 Message-ID: <eiFW8.16434$7N3.357910@twister2.libero.it>e  h "Nick Maclaren" <nmm1@cus.cam.ac.uk> ha scritto nel messaggio news:agf640$t0r$1@pegasus.csx.cam.ac.uk... >D9 > In article <cuEW8.14150$K_4.346076@twister1.libero.it>,a) > "Alberto" <albertobu@libero.it> writes:Si > |> "Bernd Paysan" <bernd.paysan@gmx.de> ha scritto nel messaggio news:p12fga.9uo.ln@miriam.mikron.de...  > |> > |> > Also, it's a SOI chip,dL > |> > which reduces gate delay by about 30% - and since other things didn't6 > |> > change much, you can expect a 30% higher clock. > |>8 > |> I don't expect over a 10-15% higher clock with Soi. >lC > Well, considering AMD get 1733 MHz with a 0.18 process, don't youtE > think that 2500 MHz with a 0.13 SOI process is fairly conservative?l >e > |> > 1200 SpecInt should be ahN > |> > target you can easily get with initial chips, without larger caches and > |> > such like.I > |>" > |> You are very very optimistic. >,8 > The mind boggles.  If I remind you of what you posted: >iD >   Ummm...... Madison = 1.7-1.8Ghz cpu + 6Mb L3, with 1450+ specintG >   and 2430+specfpu, an other class of cpu respect Opteron ( no seriusS >   compiler yet ). > >   This numbers are explicit and other consideration are only >   pessimistic :-). >hE > You are assuming that Intel can get an almost 80% increase in clockoA > speed (and hence performance) by shrinking to 0.13, but you arenC > claiming that expecting AMD to get a 45% increase in the same way. > is very, very optimistic.  >eD > Yes, of course, AMD could make a complete pig's ear of the OpteronB > or could be lying through their teeth that the Opteron is fasterC > than the Athlon at the same clock speed, but you are assuming oneb > or the other.l  9 Sorry, but i think that Amd have eat gate length in 0.18uE process and now.........A I know that this is only an internet speculation but is credible,eE after the Palomino ''miracle'' and Tbird's high o.c. characteristics;t; 2.2G are a good top freq. for standard 0.13u Amd's process.M$ But in future...................???? Bye. Alberto.   ------------------------------  # Date: Tue, 09 Jul 2002 07:27:27 GMTc* From: "Bill Todd" <billtodd@metrocast.net>4 Subject: Re: McKinley tops SpecFP AND SpecInt chartsB Message-ID: <zfwW8.636531$%y.39568809@bin4.nnrp.aus1.giganews.com>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:TCEipOaeAcY9@eisner.encompasserve.org...uI > In article <dWpW8.35549$Im2.1187845@bin2.nnrp.aus1.giganews.com>, "BillS& Todd" <billtodd@metrocast.net> writes:   ...0  ) > You don't have much use for EPIC?  Why?m  J Because I strongly suspect that an Alpha with anywhere nearly as much (andL as fast) on-chip cache would blow it completely out of the water.  Even EV7,H with only a bit over half as much (and likely noticeably slower) on-chipK cache seems likely to offer significantly better performance:  some of thatnL will be due to the improved main-memory access times, but I suspect that theI other boost McKinley got was from improvements in that area due to the HP J chip set, so it still looks like a four-year-old OoO core can whup a brandH new 2002 EPIC core in the same process (too bad we'll never see what EV8 could have done).e   ...o  G > > There's still just a bit of doubt in my mind because of some of then other E > > benchmark figures HP released that just don't seem to make sense.. >  > They make a lot of sense.s >i >   ForeL > > example, its 4-processor TPC-C performance came in about 55% higher than theiJ > > ES45's despite no better (perhaps considerably lower) system bandwidth >p" > That isn't the key to high tpmC.  G I didn't say it was, but included it for completeness.  You snipped thehL other possible reasons that I included, two of which - SQL Server vs. OracleE performance and test configuration - have nothing to do with Itanic'seJ relative performance to (in this case) Alpha.  Having gobs of fast on-chipI cache certainly doesn't hurt, but is hardly an advertisement for EPIC per  se.-  I My point was that it was not at all clear that the 55% better (than ES45)rK TPC-C result actually reflected Itanic architecture or chip-set superiorityEL simply because it did not appear to correlate with the 20% better SPECint orD any other (e.g., bandwidth) processor/chip-set characteristics (saveI possibly the cache).  Given the degree to which TPC-C is sensitive to the H storage setup, my inclination is to suspect that the result may say more0 about that than anything related to the new box.   >) > > F > > Indeed, even given McKinley's "surprisingly good" (Terry's phrase)L > > performance, it's still not 'meaningfully different' from that availableE > > from existing IA32 hardware (let alone Hammer) except in the veryg high-endI > > niche areas which IA32 can't (and Hammer *may* not be able to) reach.m > >c >rH > Ummm... for meaningfully different, how about a metric everyone loves?	 > $/tpmC.   G If you'll go to www.tpc.org, you'll find that several IA32 systems (therK systems being referred to in the discussion you snipped part of above) havehK $/tpmC figures lower than those HP reported for McKinley.  Hammer is likely. to be even lower.h   >o > > L > > Itanic will have to live with whatever performance McKinley offers todayH > > through both Madison and Montecito, modulo process shrinks that seemG > > unlikely to more than double its current performance when Montecito  comes F > > along in 2004 (assuming that heat dissipation problems don't limitJ > > performance to an even lower value) - and likely through 2005 as well, >  > That's a bold prediction.8  L Not at all:  the technical information and dates (through 2004, and even theG mention of a Montecito 'bump' in 2005 which I suspect may refer to somecI added on-chip memory and/or MP support) come straight from Intel's publicsH statements, and the relative performance improvements due to shrinks and& added cache track existing experience.  K For example, the consensus expectation for Madison clock speed is 1.2 - 1.60L GHz (presumably lower at introduction and gradually rising via tweaks later,K so at introduction nothing more than 1.4 GHz seems likely, especially givensG the unrealisticly high clock-speed predictions both Merced and McKinleynI had).  Since IIRC Madison is when the process moves to Cu, the subsequent J percentage clock boost with Montecito may be a bit less, making 2 GHz seemG about the limit of what one can expect for Montecito at introduction inlE 2004.  Yes, cache will be boosted too, but it *has* to be for SPECinteE performance to increase linearly with clock rate (which I've assumed,r perhaps a bit generously).     Here is another one: >a >bL http://groups.google.com/groups?selm=SONm8.117351%241g.9103926%40bin3.nnrp.a us1.giganews.com&output=gplain >b, > From: "Bill Todd" <billtodd@metrocast.net> > Newsgroups: comp.os.vmsf0 > Subject: Predictions - just for the hell of it% > Date: Fri, 22 Mar 2002 21:59:14 GMT- >-K > "McKinley's 1 GHz SPECint2K numbers will also be unimpressive, especiallyaG > given that this is the core users will have to live with (with only a.K > process shrink/cache bump) until at least 2005:  700 max, possibly as lowA as > 600, probably around 650."  J Yup.  If HP's claimed numbers actually materialize at spec.org, they'll beK about 25% higher than what Intel's statements (upon which I based the abovewL estimates, together with ancillary material from Paul DeMone's realworldtechL articles) suggested - so I'll be quite curious to see whether Intel can post+ comparable numbers using its own chip sets.e  K However, the future *beyond* McKinley is far less subject to surprises thanyJ the Merced/McKinley transition was, since no further architectural changesG are publicly planned through at least 2004 (and no *core* architecturalaL changes likely before 2006 - 7); the fact that no noticeable Alpha influenceA will appear before at least 2005 was confirmed privately as well._   >m > ---o >eD > Now maybe there are some pretty substantial compiler optimizations > left on the table.  L My guess is that at least part of the delay in releasing McKinley was causedF by waiting for compiler tweaks to raise its performance to respectableK levels.  If that's so, the low-hanging fruit has likely already been picked(L pretty well clean (and about time, given that they've had the better part of a decade to grab it).h  -   Especially with that 6MB L3.  After all, ifeJ > guesses are consistent, we can expect at least a 40% SpecInt performance? > improvement McKinley to Madison, would be a reasonable guess.t > You agree?  6 Change 'at least' to 'about' and it sounds reasonable.   >sK > > though it may get better on-chip support in 2005 similar to what POWER4H andiJ > > USIII got last year and EV7 and Hammer will get this year.  Next monthL > > McKinley will be matched by EV68 at 1.25 GHz, then next quarter eclipsed byI > > EV7 in virtually all respects (SPECint, memory latency and bandwidth,eJ > > scalability, ...), and then would have been dealt an even heavier blow byK > > EV8's advantages of a process-shrink plus a completely new core and SMTnK > > support (with interesting things in EV9 yet to come).  These few monthsmL > > right now are as close as Itanic would ever have come to catching Alpha:K > > when EV8 rolled around, Montecito would have offered *at most* half theeL > > per-processor performance in server-style activity, despite being a full > > process generation ahead.  >e >IC > Yeah but... at $5 per tpmC for McKinley, no one is going to touchl* > that until Madison and Madison for sure.  L As I said, check out tpc.org:  they've already got results under $5/tpmC forK IA32 systems, and I suspect that Hammer will drive them even lower.  If onetE is cost-driven and has no real need for a 64-bit address space (or issH willing to wait and see how Hammer develops), Itanic isn't going to look very attractive any time soon.  D How Itanic will compete with the existing RISC architectures is moreD problematic.  Sun's 4-processor box pricing is comparable to Intel'sL reported price structure for Itanics (and IIRC somewhat lower than HP's), soH they'll have to slug it out in performance and other areas.  IBM and forL that matter HP itself aren't as used to aggressive RISC pricing as Sun seemsJ to be, so they may have to make some adjustments.  But the current absenceB of Dell in the fray may make *everyone* a bit slow to lower prices drastically.     Also, don't overlookD > $/Specfp that will help a great deal for folks looking at a number > cruncher on a tight budget.y  J Only those who miss the fact that Pentium 4 is even more cost-effective in
 that respect.p   - bill   ------------------------------   Date: 9 Jul 2002 08:31:51 GMTr( From: nmm1@cus.cam.ac.uk (Nick Maclaren)4 Subject: Re: McKinley tops SpecFP AND SpecInt charts0 Message-ID: <age71n$2nv$1@pegasus.csx.cam.ac.uk>  3 In article <TCEipOaeAcY9@eisner.encompasserve.org>, , Rob Young <young_r@encompasserve.org> wrote:o >In article <dWpW8.35549$Im2.1187845@bin2.nnrp.aus1.giganews.com>, "Bill Todd" <billtodd@metrocast.net> writes:t; >> "Rob Young" <young_r@encompasserve.org> wrote in message-0 >> news:XSeIODJ+jnlW@eisner.encompasserve.org... >>> / >>> That's right.  Time to eat crow all around.  >> iL >> Nope.  The only crow I'm about to eat is my guess at McKinley's SPECint2KH >> performance - *assuming* that the numbers reported by HP are actually >> accepted by SPEC. >)  >	That would be a hold out hope.  C Less than you appear to think.  Intel's record here is ghastly; forrD 20 years, Intel has had a reputation for quoting figures that nobodyE else can reach, or that use unreasonable (and often unsold) features.n> In academia, journals stop publishing authors who do that ....  E The question is whether HP have descended to that level.  I doubt it, D but it isn't implausible.  A more serious point is that we have VERYG good grounds for believing that BOTH HP's zx1 chipset AND HP's compiler A are worth 10-20% on SpecInt.  That would make a best guess at then@ McKinley's SpecInt performance using Intel's compiler on BanderaB 600-650.  And, lastly, ask your HP salesman about the availability' of the HP compiler on other than HP-UX.e  L >> That said, if HP's numbers are even close to correct McKinley has come inM >> considerably better than I expected it to, and there may be some reason toc? >	You don't have much use for EPIC?  Why?  Performs much betternA >	than expected?  Is there a lurking contradiction I am not quite  >	highlighting?e  B I don't, and have posted my reservations for 8 years.  I shall notC repeat them here, except one I refer to below, but please note that C they will be proved only when real IA-64 systems are used with real A loads by real users.  Benchmarks are notorious for not showing upf% performance and reliability problems.a  J >	Ummm... for meaningfully different, how about a metric everyone loves?  	 >	$/tpmC.   B Yes.  WHEN IA-64 systems are in full production.  At present, theyE are in introduction, and the prices are more than usually artificial.x  1 >	That's a bold prediction.  Here is another one:o+ >From: "Bill Todd" <billtodd@metrocast.net>  >-J >"McKinley's 1 GHz SPECint2K numbers will also be unimpressive, especiallyF >given that this is the core users will have to live with (with only aM >process shrink/cache bump) until at least 2005:  700 max, possibly as low ast >600, probably around 650."o  D That is what almost everyone thought then, and may still be true for@ Intel's compiler on Bandera.  My guess still is that it will be.  D >	Now maybe there are some pretty substantial compiler optimizationsA >	left on the table.  Especially with that 6MB L3.  After all, if J >	guesses are consistent, we can expect at least a 40% SpecInt performance? >	improvement McKinley to Madison, would be a reasonable guess.o >	You agree?  B I should be flabberghasted.  The IA-64 software project as a wholeB was the largest one since the Sytem/360, and the compiler work was? probably 2/3 of that.  8 years of well-funded work following on @ from 25 years of ubiquitous research doesn't leave many cherries6 to pick, and you can't produce breakthroughs to order.  C Remember that the problem is primarily in program analysis, and nothD in code generation.  Now, one aspect that could have MASSIVE effectsC on SpecInt is with the adoption of C99 (mainly if it used restrict,iC but there is also type-controlled aliasing).  However, any compileriC that uses the latter will cause HUGE numbers of widespread programs B to break, so it isn't a 'fair' optimisation.  But was it used?  We don't know yet.r  C >	Yeah but... at $5 per tpmC for McKinley, no one is going to touchf@ >	that until Madison and Madison for sure.  Also, don't overlookD >	$/Specfp that will help a great deal for folks looking at a number >	cruncher on a tight budget.   A Maybe.  Those of us who are deeply into number-crunching are less = convinced by the IA-64 line than we were 5+ years ago, as the B interesting little "gotchas" emerge.  When and if McKinley systems= become available to independent HPC people, evidence of their24 desirability (or the converse) will start to emerge.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679d   ------------------------------  # Date: Tue, 09 Jul 2002 14:16:18 GMT25 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> 4 Subject: Re: McKinley tops SpecFP AND SpecInt charts2 Message-ID: <SeCW8.25$8Y5.382042@news.cpqcorp.net>   Bill Todd wrote in message ...   > ...   % You want some cheese with your whine?s  G Oh my, Itanium-2 doesn't suck.  Let me see if I can throw in a bunch ofaL other unsupported speculation to show why I wasn't wrong, or maybe someone'sE lying, or maybe the Intel reference platform won't be as fast as HP'stJ system, or anyway - it will still suck later.  And if that isn't enough, IK can always complain that the mythical EV8 would still have kicked it's ass.o   ------------------------------  % Date: Tue, 09 Jul 2002 11:33:55 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>A4 Subject: Re: McKinley tops SpecFP AND SpecInt charts, Message-ID: <3D2B0260.C7C12E9E@videotron.ca>   Nick Maclaren wrote:F > but it isn't implausible.  A more serious point is that we have VERYI > good grounds for believing that BOTH HP's zx1 chipset AND HP's compiler6 > are worth 10-20% on SpecInt.  K Who does what compiler for IA64 ? Does HP have its own compilers or does ita rely on the Intel compilers ?f  J Have the ex-Digital compiler folks who were donated to Intel begun to makeM significant changes to Intel's compilers or are they still just settling intoaH their new job ? is there a feeling that Intel's compilers are poised forM significant improvements or have they pretty well reached "maturity" in termst9 of generating code that makes best possible use of EPIC ?0   ------------------------------  # Date: Tue, 09 Jul 2002 14:47:02 GMTb5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>p4 Subject: Re: McKinley tops SpecFP AND SpecInt charts2 Message-ID: <GHCW8.27$FZ5.440370@news.cpqcorp.net>  " Nick Maclaren wrote in message ... >sD >Less than you appear to think.  Intel's record here is ghastly; forE >20 years, Intel has had a reputation for quoting figures that nobody F >else can reach, or that use unreasonable (and often unsold) features.? >In academia, journals stop publishing authors who do that ....u >gF >The question is whether HP have descended to that level.  I doubt it,E >but it isn't implausible.  A more serious point is that we have VERYtH >good grounds for believing that BOTH HP's zx1 chipset AND HP's compilerB >are worth 10-20% on SpecInt.  That would make a best guess at theA >McKinley's SpecInt performance using Intel's compiler on BanderaiC >600-650.  And, lastly, ask your HP salesman about the availabilitym( >of the HP compiler on other than HP-UX. >i  I You know, this is a bit less than fair.  You make a statement designed tot6 imply you think HP may be lying about the performance.  = Then you complain that Itanium-2 still may suck in some otherrE implementation.  Hey, guess what - Spec results vary from platform to K platform.  Other than the whine about IBM's turning off a CPU core on their-K Power-4 results, you seldom see people all up in arms that 2 platforms with@. the same CPU chip have different Spec results.  @ Well, what it shows is that the Itanium-2 chip *is* capable highK performance.  The fact that the Intel reference platform "might" have loweraL performance numbers doesn't mean the CPU sucks.  It means that HP is serious! about getting the best out of it..  K And hey, the GNU people walk on water right?  So have them make GCC better.eI Was/is there some obligation on HP's part to make Linux on somebody elses  box run faster?s  J >>> That said, if HP's numbers are even close to correct McKinley has come inK >>> considerably better than I expected it to, and there may be some reasonh to@ >> You don't have much use for EPIC?  Why?  Performs much betterB >> than expected?  Is there a lurking contradiction I am not quite >> highlighting? > C >I don't, and have posted my reservations for 8 years.  I shall noteD >repeat them here, except one I refer to below, but please note thatD >they will be proved only when real IA-64 systems are used with realB >loads by real users.  Benchmarks are notorious for not showing up& >performance and reliability problems. >o  H Ah yes.  We will.  And if "real life" performance backs up the claims, IL assume that you will acknowledge that you were wrong?  Just a few weeks ago,F some people here were claiming that the customer testimonial of betterJ performance than Sun was something being used to cover up bad Spec scores.  I >> Ummm... for meaningfully different, how about a metric everyone loves?c
 >> $/tpmC. >oC >Yes.  WHEN IA-64 systems are in full production.  At present, they-F >are in introduction, and the prices are more than usually artificial. >o  L What makes the prices artificial?  You think when it is in "full production"I the prices will rise?  I can understand your frustration that the systemstJ appear not to be available in the normal time (it took about a week to getE Itanium-1's when we ordered them - pre-merger).  Which, frankly isn'ttK anything new.  Look at Alpha's - we announced them and make them orderable,iL but generally speaking they are initially backordered while production ramps up.t    2 >> That's a bold prediction.  Here is another one:, >>From: "Bill Todd" <billtodd@metrocast.net> >>K >>"McKinley's 1 GHz SPECint2K numbers will also be unimpressive, especiallynG >>given that this is the core users will have to live with (with only aeK >>process shrink/cache bump) until at least 2005:  700 max, possibly as lowa as >>600, probably around 650." >bE >That is what almost everyone thought then, and may still be true forrA >Intel's compiler on Bandera.  My guess still is that it will be.t >   F Who cares?  Except as a way of mitigating Bill's lowball guess.  Fine.G Let's assume he is right on some other platform box, heck I can make anuG Alpha EV6 score a 153 if I build a bad system around it.   It would noteK suprise me if the Intel reference parts were not as fast.  The fact is that K you can buy a HP system with that CPU with a SpecInt of 810.  Admit that it F is pretty good score, and that the CPU - even with the despised EPIC -1 apparently doesn't suck as bad as some had hoped.o  E >> Now maybe there are some pretty substantial compiler optimizationspB >> left on the table.  Especially with that 6MB L3.  After all, ifK >> guesses are consistent, we can expect at least a 40% SpecInt performancee@ >> improvement McKinley to Madison, would be a reasonable guess.
 >> You agree?a > C >I should be flabberghasted.  The IA-64 software project as a wholetC >was the largest one since the Sytem/360, and the compiler work was @ >probably 2/3 of that.  8 years of well-funded work following onA >from 25 years of ubiquitous research doesn't leave many cherries 7 >to pick, and you can't produce breakthroughs to order.  >   J I'm not in a position to even guess.  But I love it when people say thingsI like this, because inevitably the breakthrough does come.  How many "hardoH barriers" in many fields that people believed would never be broken have fallen.e  D >Remember that the problem is primarily in program analysis, and notE >in code generation.  Now, one aspect that could have MASSIVE effectseD >on SpecInt is with the adoption of C99 (mainly if it used restrict,D >but there is also type-controlled aliasing).  However, any compilerD >that uses the latter will cause HUGE numbers of widespread programsC >to break, so it isn't a 'fair' optimisation.  But was it used?  Wee >don't know yet. >   D Frankly, I expect when/if some breakthrough does occur, Spec will be5 obsolele - and some other measurement will be needed.a  D >> Yeah but... at $5 per tpmC for McKinley, no one is going to touchA >> that until Madison and Madison for sure.  Also, don't overlooksE >> $/Specfp that will help a great deal for folks looking at a numberK >> cruncher on a tight budget. >lB >Maybe.  Those of us who are deeply into number-crunching are less> >convinced by the IA-64 line than we were 5+ years ago, as theC >interesting little "gotchas" emerge.  When and if McKinley systemso> >become available to independent HPC people, evidence of their5 >desirability (or the converse) will start to emerge.  >t  J Well, it's orderable.  So order one.  Or wait until you can get a deliveryH date on your order.  If the Spec figures hold up, and the prices are notL "articifical" - it looks like you would get a respectable UNIX (HP-UX) and a fast box, for a good price.e   ------------------------------  # Date: Tue, 09 Jul 2002 15:35:13 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>r4 Subject: Re: McKinley tops SpecFP AND SpecInt charts? Message-ID: <RoDW8.291766$R61.190257@rwcrnsc52.ops.asp.att.net>   @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message, news:GHCW8.27$FZ5.440370@news.cpqcorp.net... >e$ > Nick Maclaren wrote in message ... > >rF > >Less than you appear to think.  Intel's record here is ghastly; forG > >20 years, Intel has had a reputation for quoting figures that nobodyaH > >else can reach, or that use unreasonable (and often unsold) features.A > >In academia, journals stop publishing authors who do that ....  > >pH > >The question is whether HP have descended to that level.  I doubt it,G > >but it isn't implausible.  A more serious point is that we have VERYeJ > >good grounds for believing that BOTH HP's zx1 chipset AND HP's compilerD > >are worth 10-20% on SpecInt.  That would make a best guess at theC > >McKinley's SpecInt performance using Intel's compiler on BanderaaE > >600-650.  And, lastly, ask your HP salesman about the availabilitym* > >of the HP compiler on other than HP-UX. > >a >nK > You know, this is a bit less than fair.  You make a statement designed tod8 > imply you think HP may be lying about the performance.  L Well, I wouldn't go that far. I read the statement as an allusion to some ofA the obscure and irreproducible metrics INTC has used in the past.   J And yep, the zx1 chipset and HPQ compilers are responsible for some of theG performance. To me this is not a Bad Thing... on the contrary, it shedsmJ light on one of the ways in which HPQ hopes to differentiate itself in theJ "industry standard" space. Note that CPQ did the same thing with the 8-way# ProLiant and its ProFusion chipset.aK IBM of course has a chipset of its own; have to see how things pan out withe our friends in Armonk.    L Whether you like INTC or not, you have to admit, the initial HPQ numbers forG McKinley are a helluva lot better than the numbers for Itanic 1. And ittF appears that there's more ISV buy-in to McKinley than there was to theL first-generation chip. I wouldn't rush out and buy a McKinley platform todayJ (assuming that such was available today) but it seems awfully early in the" cycle to doom the chip to failure.   ------------------------------   Date: 9 Jul 2002 15:47:32 GMTI( From: nmm1@cus.cam.ac.uk (Nick Maclaren)4 Subject: Re: McKinley tops SpecFP AND SpecInt charts0 Message-ID: <agf0ik$on8$1@pegasus.csx.cam.ac.uk>  2 In article <GHCW8.27$FZ5.440370@news.cpqcorp.net>,7 "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:e% |> Nick Maclaren wrote in message ...e |> >G |> >Less than you appear to think.  Intel's record here is ghastly; forBH |> >20 years, Intel has had a reputation for quoting figures that nobodyI |> >else can reach, or that use unreasonable (and often unsold) features.iB |> >In academia, journals stop publishing authors who do that .... |> >I |> >The question is whether HP have descended to that level.  I doubt it,fH |> >but it isn't implausible.  A more serious point is that we have VERYK |> >good grounds for believing that BOTH HP's zx1 chipset AND HP's compilerjE |> >are worth 10-20% on SpecInt.  That would make a best guess at thenD |> >McKinley's SpecInt performance using Intel's compiler on BanderaF |> >600-650.  And, lastly, ask your HP salesman about the availability+ |> >of the HP compiler on other than HP-UX.e |> mL |> You know, this is a bit less than fair.  You make a statement designed to9 |> imply you think HP may be lying about the performance.e  B I said explicitly that I think that they AREN'T lying, but that it2 cannot yet be ruled out.  Please reread the above.  @ |> Then you complain that Itanium-2 still may suck in some otherH |> implementation.  Hey, guess what - Spec results vary from platform toN |> platform.  Other than the whine about IBM's turning off a CPU core on theirN |> Power-4 results, you seldom see people all up in arms that 2 platforms with1 |> the same CPU chip have different Spec results.n  B Few architectures have such dependence on the chipset and compiler? as the IA-64 does.  Furthermore, HP themselves have made claimse? that much of their performance advantages are PRECISELY becauseA1 of their chipset and compiler!  See, for example:n  1 http://www.theregister.co.uk/content/3/26097.htmlc  @ I cannot offhand remember the similar compiler reference, but it= is around somewhere, and its truth is immediately apparent by ; looking at the published results on www.spec.org CAREFULLY.  I suggest that you do so.   C |> Well, what it shows is that the Itanium-2 chip *is* capable highnN |> performance.  The fact that the Intel reference platform "might" have lowerO |> performance numbers doesn't mean the CPU sucks.  It means that HP is serious $ |> about getting the best out of it.  C All of that is true.  But it is also true that it is much harder to A get performance out of it than out of many other chips.  And thatt@ is a relevant point to those of us who have to work with limited? effort, horrible applications and source not under our control.i  K |> Ah yes.  We will.  And if "real life" performance backs up the claims, IeO |> assume that you will acknowledge that you were wrong?  Just a few weeks ago, I |> some people here were claiming that the customer testimonial of bettereM |> performance than Sun was something being used to cover up bad Spec scores.   D I will.  And you are misremembering.  It isn't hard to select a goodC testimonial if you are prepared to choose the best out of hundreds.i  O |> What makes the prices artificial?  You think when it is in "full production"hL |> the prices will rise?  I can understand your frustration that the systemsM |> appear not to be available in the normal time (it took about a week to getnH |> Itanium-1's when we ordered them - pre-merger).  Which, frankly isn'tN |> anything new.  Look at Alpha's - we announced them and make them orderable,O |> but generally speaking they are initially backordered while production rampsa |> up.  A Every heard of selling below a viable price to get a product line 4 introduced?  No?  Most vendors of most things do it.  M |> I'm not in a position to even guess.  But I love it when people say thingshL |> like this, because inevitably the breakthrough does come.  How many "hardK |> barriers" in many fields that people believed would never be broken have8
 |> fallen.  @ Well, I am.  "Inevitably the breakthrough does come"?  Oh, yeah?> Remember the repeated claims that new designed would mean that; memory latencies would start to fall as fast as cache ones?i7 Software has similar problems, and this is one of them.n  M |> Well, it's orderable.  So order one.  Or wait until you can get a delivery(K |> date on your order.  If the Spec figures hold up, and the prices are notoO |> "articifical" - it looks like you would get a respectable UNIX (HP-UX) and ap |> fast box, for a good price.  B Oh, is it?  I tried to get a quote, just this morning.  Nope.  Not? on our list.  And got the same response from HP's "buy online".      Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679u   ------------------------------  % Date: Tue, 09 Jul 2002 08:51:50 -0700 & From: Greg Cagle <gregc@gregcagle.com>4 Subject: Re: McKinley tops SpecFP AND SpecInt charts, Message-ID: <3D2B0696.7020807@gregcagle.com>   JF Mezei wrote:( > Nick Maclaren wrote: > F >>but it isn't implausible.  A more serious point is that we have VERYI >>good grounds for believing that BOTH HP's zx1 chipset AND HP's compiler. >>are worth 10-20% on SpecInt. >  > M > Who does what compiler for IA64 ? Does HP have its own compilers or does itu > rely on the Intel compilers ?m > L > Have the ex-Digital compiler folks who were donated to Intel begun to makeO > significant changes to Intel's compilers or are they still just settling intolJ > their new job ? is there a feeling that Intel's compilers are poised forO > significant improvements or have they pretty well reached "maturity" in termst; > of generating code that makes best possible use of EPIC ?y  J HP has its own set of compilers on HP-UX for Itanium 2. Intel has a set as well for Windows and Linux.t   -- t
 Greg Cagle gregc at gregcagle dot com   ------------------------------   Date: 9 Jul 2002 15:59:38 GMTc( From: nmm1@cus.cam.ac.uk (Nick Maclaren)4 Subject: Re: McKinley tops SpecFP AND SpecInt charts0 Message-ID: <agf19a$p8a$1@pegasus.csx.cam.ac.uk>  ? In article <RoDW8.291766$R61.190257@rwcrnsc52.ops.asp.att.net>,63 "Terry C. Shannon" <terryshannon@attbi.com> writes:u |> iO |> Whether you like INTC or not, you have to admit, the initial HPQ numbers forbJ |> McKinley are a helluva lot better than the numbers for Itanic 1. And itI |> appears that there's more ISV buy-in to McKinley than there was to theeO |> first-generation chip. I wouldn't rush out and buy a McKinley platform todaylM |> (assuming that such was available today) but it seems awfully early in thei% |> cycle to doom the chip to failure.t  @ Definitely.  The signs are very mixed.  Yes, HP has got the chip? to perform, if not up to the wildest claims, enough to say thate@ it is a (or even the) leader.  Hence my interest in getting one.  > But the support from other OEMs is minimal (so far, at least),: there are no McKinley servers, we don't know if HP will be= licensing its chipset and compiler, and so on.  Especially ifc: HP's systems outperform others by 25%, this is not a minor matter.k  > Most of all, we don't yet know how well such systems will both? perform and work in the field.  There are some very disquietinga< rumours, as well as my doubts due to analysis of the design.> For example, most HPC people are at least as interested in MPI2 or OpenMP latency as we are in scalar performance.  8 How well will it work, when typically revolting programs; are compiled and tuned by people who are NOT IA-64 experts?o  ? And will it mean an increase in the number of 'insoluble' bugs,T- such as those that bedevil us in HPC already?h  
 And so on.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679t   ------------------------------  # Date: Tue, 09 Jul 2002 16:00:35 GMTt0 From: prune@ZAnkh-Morpork.mv.com (Paul Winalski)4 Subject: Re: McKinley tops SpecFP AND SpecInt charts9 Message-ID: <3d2b0843.2648651990@proxy.news.easynews.com>   ? Hmm.  Doesn't match the numbers at the HP website, which showedt@ a top-end IA-32 system ruling the roost on SpecINT. McK was tops on SpecFP, though.  B What is clear is that McKinley isn't the performance disaster that8 Merced was.  McK's integer numbers are comparable to the> current competition and the FP numbers look quite good indeed.= McK has done a lot better than I, for one, expected it to do.c  B Whether this is good enough to sustain the IPF architecture in the2 face of the competition is still an open question.  C On 8 Jul 2002 13:30:01 -0600, young_r@encompasserve.org (Rob Young)e wrote:   >a< >	That's right.  Time to eat crow all around.  Perhaps there0 >	may not be enough platters, but who cares, eh? >s> >	According to the PPTs and HTMLs found at www.openvms.org oneG >	can find (in the notes field) the Spec numbers embargoed until today.u >u> >	Following are base numbers.  So maybe their is a tiny bit of, >	glory left for Power4 in SpecInt2000 peak?	 >       	t >		Itanium 2		Power4 at 1.3 GHze >y >SpecInt2000	810			804 >SpecFp		1356			1202 >  >m >				Rob >   
 ---------- Remove 'Z' to reply by email.t   ------------------------------  # Date: Tue, 09 Jul 2002 16:07:44 GMTs0 From: prune@ZAnkh-Morpork.mv.com (Paul Winalski)4 Subject: Re: McKinley tops SpecFP AND SpecInt charts9 Message-ID: <3d2b099e.2648999209@proxy.news.easynews.com>   3 On Tue, 09 Jul 2002 14:47:02 GMT, "Fred Kleinsorge" $ <kleinsorge@star.zko.dec.com> wrote:  A >Well, what it shows is that the Itanium-2 chip *is* capable hight >performance.  h  @ With a good tail wind behind it, anyway (i.e., extensive profile< feedback to a compiler designed specifically to win spec and other benchmarks).  ; But that's the way everyone does Spec and other benchmarks.sC It's like qualifying for the Indy 500.  You tune the car and engineyA for top speed, you put in only as much fuel as you need to do theeB 6 laps in the qualifying run, and sometimes you even go to lengths@ such as taking all the gears out of the gearbox except top gear.> Nobody would ever set up their car that way for the real race,B but they all do it for qualifying.  Benchmark runs are a similarly artificial situation.   > >The fact that the Intel reference platform "might" have lowerM >performance numbers doesn't mean the CPU sucks.  It means that HP is seriousd" >about getting the best out of it.  @ The benchmark that I'll be interested to see is McK's web server performance.
 ---------- Remove 'Z' to reply by email.n   ------------------------------  # Date: Tue, 09 Jul 2002 16:12:31 GMTe0 From: prune@ZAnkh-Morpork.mv.com (Paul Winalski)4 Subject: Re: McKinley tops SpecFP AND SpecInt charts9 Message-ID: <3d2b0b27.2649391523@proxy.news.easynews.com>n  , On Tue, 09 Jul 2002 11:33:55 -0400, JF Mezei% <jfmezei.spamnot@videotron.ca> wrote:   L >Who does what compiler for IA64 ? Does HP have its own compilers or does it >rely on the Intel compilers ?  F IIRC, Intel's compiler was used, but the benchmark runs were on HP/UX.  K >Have the ex-Digital compiler folks who were donated to Intel begun to make N >significant changes to Intel's compilers or are they still just settling intoI >their new job ? is there a feeling that Intel's compilers are poised foreN >significant improvements or have they pretty well reached "maturity" in terms: >of generating code that makes best possible use of EPIC ?  = Generating the best possible code for EPIC is still very mucha- unexplored territory for compiler technology.t  
 ---------- Remove 'Z' to reply by email.f   ------------------------------  # Date: Tue, 09 Jul 2002 16:18:04 GMT.0 From: prune@ZAnkh-Morpork.mv.com (Paul Winalski)4 Subject: Re: McKinley tops SpecFP AND SpecInt charts9 Message-ID: <3d2b0c4c.2649685205@proxy.news.easynews.com>p  F On Tue, 09 Jul 2002 03:04:08 GMT, "John Smith" <a@nonymous.com> wrote:  L >My bet is that HP will NOT publish any SPEC performance numbers for EV68 or >EV7.c >rL >Why, you ask? Because they have no need to. And why would they want to make: >their multi-billion dollar investment in Itanic look bad?  D I think you're right about this.  Alpha is conspicuously absent from3 the performance charts published at the HP website.e  ; From a marketing standpoint, it makes no sense for HP to be,= showcasing Alpha performance.  Why promote a CPU architecture @ that you're trying to shut down?  Especially when it would stealF the limelight from the architecture you're touting as its replacement.B From HP's perspective, there is no reason to promote Alpha.  ThoseC who are stuck with the Alpha platform will buy it because they haveBE no choice.  By throwing all its promotional effort behind Itanium, HP 4 hopes to lure those who do have a choice to Itanium.  E I therefore fully expect to see Alpha studiously ignored from now on.t  
 ---------- Remove 'Z' to reply by email.>   ------------------------------  # Date: Tue, 09 Jul 2002 16:26:30 GMTe1 From: "Terry C. Shannon" <terryshannon@attbi.com>t4 Subject: Re: McKinley tops SpecFP AND SpecInt charts? Message-ID: <W8EW8.339218$6m5.352724@rwcrnsc51.ops.asp.att.net>n  = "Paul Winalski" <prune@ZAnkh-Morpork.mv.com> wrote in messager3 news:3d2b0c4c.2649685205@proxy.news.easynews.com... H > On Tue, 09 Jul 2002 03:04:08 GMT, "John Smith" <a@nonymous.com> wrote: >sK > >My bet is that HP will NOT publish any SPEC performance numbers for EV68e or > >EV7.n > >rI > >Why, you ask? Because they have no need to. And why would they want tos make< > >their multi-billion dollar investment in Itanic look bad? >lF > I think you're right about this.  Alpha is conspicuously absent from5 > the performance charts published at the HP website.2 >:= > From a marketing standpoint, it makes no sense for HP to be ? > showcasing Alpha performance.  Why promote a CPU architecture B > that you're trying to shut down?  Especially when it would stealH > the limelight from the architecture you're touting as its replacement.D > From HP's perspective, there is no reason to promote Alpha.  ThoseE > who are stuck with the Alpha platform will buy it because they havefG > no choice.  By throwing all its promotional effort behind Itanium, HPd6 > hopes to lure those who do have a choice to Itanium. >uG > I therefore fully expect to see Alpha studiously ignored from now on.  >t  K Umm, when the ES80 and GS1280 come out, do you think they will be devoid ofuH performance metrics? And what of the 1.25GHz ES45 and GS320 due out in a month or so?   ------------------------------  # Date: Tue, 09 Jul 2002 16:31:48 GMTa0 From: prune@ZAnkh-Morpork.mv.com (Paul Winalski)4 Subject: Re: McKinley tops SpecFP AND SpecInt charts9 Message-ID: <3d2b0d9e.2650023061@proxy.news.easynews.com>s  , On Tue, 09 Jul 2002 00:53:37 -0400, JF Mezei% <jfmezei.spamnot@videotron.ca> wrote:   
 >Question: >nM >IA64 is "EPIC" where it expects the compiler to do all the work to make besto  >use of the chip's architecture. >fK >In the Intel released results for IA64, was it done with normal commercial L >applications compiled using whatever commercially available compilers existG >for IA64, was was it done with specially tweaked applications designedf8 >carefully to generate the best possible speed results ?  < The benchmarks in question are industry-standard benchmarks,> using code approved by an industry-wide committee in which allD the vendors and other interested parties participate.  The code thatC is compiled is exactly the same for all the systems that are tested @ and for which results are published.  The benchmark applications are not allowed to be tweaked.  A The vendor or other party that runs the benchmarks does have sometE latitude in choice of compiler, compilation options, and hardware andtB OS platform.  For the "base" Spec numbers, there are limits on the? number of special options that one can use in the compilations.aD Furthermore, all components of the platform (hardware, OS, compiler)E must be available to the public within 6 months of the publication of2 the benchmark numbers.  A So there is some tweaking, in that the numbers don't have to comeNA from using the compiler's default options, but everything used to = create the benchmark numbers has to be off-the-shelf hardwarei@ and software, such that anyone in the general public could build; the benchmark configuration and reproduce the same results..  L >If the Intel released specs don't reflect what commercial applicatiosn willJ >deliver, then the question is how big a gap there will be between Intel'sB >"dream" specs, and what real world performance will be delivered.  F That's always the big question.  It's kind of like the EPA MPG numbersF for automobiles--the numbers are useful for comparing different modelsA of car, but whether you'd ever achieve that performance in actuall driving is often doubtful.  O >Will Intel's commercial compilers really be able to take code not specifiacllygG >designed for IA64 and generate assembler that makes best use of IA64'sn >potential ?  C Again, the benchmarks aren't specifically designed for IA64, or for>F any other architecture, for that matter.  The Spec test suite is a setB of moderately-sized real world applications specifically chosen toC test the integer (in the case of SpecINT) or floating point (in thet1 case of SpecFP) performance of a computer system.t  A Whether IA64 can deliver as good performance as its rivals in thet< absence of profile-directed feedback and other such advancedD optimization techniques is an interesting question.  An awful lot ofF application developers just build their apps with the default compilerB options, or compile with optimization turned off (a habit acquiredC due to the buggy nature of the optimizers in early UNIX compilers).t  
 ---------- Remove 'Z' to reply by email.n   ------------------------------  % Date: Tue, 09 Jul 2002 12:56:59 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca> 4 Subject: Re: McKinley tops SpecFP AND SpecInt charts, Message-ID: <3D2B15D1.1C201A2A@videotron.ca>   Nick Maclaren wrote:D > Few architectures have such dependence on the chipset and compilerA > as the IA-64 does.  Furthermore, HP themselves have made claimskA > that much of their performance advantages are PRECISELY because 3 > of their chipset and compiler!  See, for example:e    H I am perplexed as to why HP still has its own IA64 compiler(s) ? On whatD platform does HP's compiler(s) run ? Just HP-UX or also on Windows ?  N When the time comes to have VMS, NSK HP-UX and Widnows on IA64,  which OS will get whose compilers ?t  M I was under the impression that VMS would inherit the Intel compilers. If thehC HP compilers are superior, doesn't this mean that VMS would be at ao; disadvantage versus the HP products thathave HP compilers ?i         > 3 > http://www.theregister.co.uk/content/3/26097.htmln > B > I cannot offhand remember the similar compiler reference, but it? > is around somewhere, and its truth is immediately apparent by>= > looking at the published results on www.spec.org CAREFULLY.f > I suggest that you do so.  > E > |> Well, what it shows is that the Itanium-2 chip *is* capable highyP > |> performance.  The fact that the Intel reference platform "might" have lowerQ > |> performance numbers doesn't mean the CPU sucks.  It means that HP is serious & > |> about getting the best out of it. > E > All of that is true.  But it is also true that it is much harder tosC > get performance out of it than out of many other chips.  And that B > is a relevant point to those of us who have to work with limitedA > effort, horrible applications and source not under our control.c > M > |> Ah yes.  We will.  And if "real life" performance backs up the claims, IoQ > |> assume that you will acknowledge that you were wrong?  Just a few weeks ago,cK > |> some people here were claiming that the customer testimonial of better.O > |> performance than Sun was something being used to cover up bad Spec scores.h > F > I will.  And you are misremembering.  It isn't hard to select a goodE > testimonial if you are prepared to choose the best out of hundreds.k > Q > |> What makes the prices artificial?  You think when it is in "full production"?N > |> the prices will rise?  I can understand your frustration that the systemsO > |> appear not to be available in the normal time (it took about a week to getdJ > |> Itanium-1's when we ordered them - pre-merger).  Which, frankly isn'tP > |> anything new.  Look at Alpha's - we announced them and make them orderable,Q > |> but generally speaking they are initially backordered while production rampsb > |> up. > C > Every heard of selling below a viable price to get a product linet6 > introduced?  No?  Most vendors of most things do it. > O > |> I'm not in a position to even guess.  But I love it when people say thingsvN > |> like this, because inevitably the breakthrough does come.  How many "hardM > |> barriers" in many fields that people believed would never be broken have  > |> fallen. > B > Well, I am.  "Inevitably the breakthrough does come"?  Oh, yeah?@ > Remember the repeated claims that new designed would mean that= > memory latencies would start to fall as fast as cache ones?09 > Software has similar problems, and this is one of them.: > O > |> Well, it's orderable.  So order one.  Or wait until you can get a deliverygM > |> date on your order.  If the Spec figures hold up, and the prices are not Q > |> "articifical" - it looks like you would get a respectable UNIX (HP-UX) and an  > |> fast box, for a good price. > D > Oh, is it?  I tried to get a quote, just this morning.  Nope.  NotA > on our list.  And got the same response from HP's "buy online".m > 
 > Regards, > Nick Maclaren,, > University of Cambridge Computing Service,@ > New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. > Email:  nmm1@cam.ac.uk1 > Tel.:  +44 1223 334761    Fax:  +44 1223 334679e   ------------------------------  % Date: Tue, 09 Jul 2002 13:02:10 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>l4 Subject: Re: McKinley tops SpecFP AND SpecInt charts, Message-ID: <3D2B1708.2ED3F16A@videotron.ca>   Paul Winalski wrote:D > Whether this is good enough to sustain the IPF architecture in the4 > face of the competition is still an open question.  I Also, McKinley is brand spanking new, and currently being compared agaist@L older existing chips. When those chips get their upgrades, how will McKinley fare ?  E Is everyone just planning speed bumps for the next few years, or is auN competitor to IA64 planning a more significant improvement to their chip which would widen the gap ?   A Speed bumb may make a chip faster, but it won't really change itsgK competitiveness since everyone will get the same speed bumps roughly at thes
 same time.   ------------------------------   Date: 9 Jul 2002 17:05:08 GMTc( From: nmm1@cus.cam.ac.uk (Nick Maclaren)4 Subject: Re: McKinley tops SpecFP AND SpecInt charts0 Message-ID: <agf544$s5c$1@pegasus.csx.cam.ac.uk>  , In article <3D2B15D1.1C201A2A@videotron.ca>,/ JF Mezei <jfmezei.spamnot@videotron.ca> writes:  |> Nick Maclaren wrote:s |> mG |> > Few architectures have such dependence on the chipset and compilerPD |> > as the IA-64 does.  Furthermore, HP themselves have made claimsD |> > that much of their performance advantages are PRECISELY because6 |> > of their chipset and compiler!  See, for example: |> lK |> I am perplexed as to why HP still has its own IA64 compiler(s) ? On whatoG |> platform does HP's compiler(s) run ? Just HP-UX or also on Windows ?s |>Q |> When the time comes to have VMS, NSK HP-UX and Widnows on IA64,  which OS wille |> get whose compilers ?  ? You would have to ask HP.  Don't forget there is also Linux :-)d> Now the relevant products are announced, it is a fair question to ask an HP salesman.  P |> I was under the impression that VMS would inherit the Intel compilers. If theF |> HP compilers are superior, doesn't this mean that VMS would be at a> |> disadvantage versus the HP products thathave HP compilers ?  ? At the OpenVMS meeting, the strategic C compiler was said to be4< Intel's, but most of the others were Compaq's (ported).  The@ Fortran was under consideration for being changed to use Intel's Electron back end. e  > I was extremely surprised that there was no reference to using; HP's compilers under VMS, though it was and is not directly  relevant to us.,     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679c   ------------------------------   Date: 9 Jul 2002 12:05:51 -0600o+ From: young_r@encompasserve.org (Rob Young) 4 Subject: Re: McKinley tops SpecFP AND SpecInt charts3 Message-ID: <xQO8B0clAD80@eisner.encompasserve.org>   l In article <3d2b0843.2648651990@proxy.news.easynews.com>, prune@ZAnkh-Morpork.mv.com (Paul Winalski) writes:A > Hmm.  Doesn't match the numbers at the HP website, which showedrB > a top-end IA-32 system ruling the roost on SpecINT. McK was tops > on SpecFP, though. >   9 	An oversight on your part.  All about sourcing and I getf# 	mine turned around too often also.l  4 http://www.hp.com/hpinfo/newsroom/press/08jul02b.htm  L Commercial compute core: Itanium 2-based systems from HP with the HP ChipsetJ zx1 outperformed the best from IBM and Sun. HP achieved a SPECintbase_2000F score of 810 and 807 on an HP Server rx2600 and HP Workstation zx6000, respectively.(5) -    D > What is clear is that McKinley isn't the performance disaster that > Merced was.  (  G 	Right.  Leading in many metrics as far as I can tell and substantiallyg3 	in several (TPC-C 4 processor boxes for instance.)   + McK's integer numbers are comparable to thes@ > current competition and the FP numbers look quite good indeed.? > McK has done a lot better than I, for one, expected it to do.h > D > Whether this is good enough to sustain the IPF architecture in the4 > face of the competition is still an open question. >   < 	I think very good pricing is the angle.  Expensive and fast7 	isn't the way to overtake a segment.  Fast and cheaper. 	is probably the only way.   				Rob    ------------------------------  # Date: Tue, 09 Jul 2002 17:15:34 GMT 5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>u4 Subject: Re: McKinley tops SpecFP AND SpecInt charts2 Message-ID: <WSEW8.31$026.630907@news.cpqcorp.net>  " Nick Maclaren wrote in message ... >f >qC >I said explicitly that I think that they AREN'T lying, but that it 3 >cannot yet be ruled out.  Please reread the above.a >l  L I did.  Your statements were designed to imply that HP might be lying, in anK effort to discount the credibility of the numbers.  What would you say if IsJ wrote:  "There is this fellow "XX" in the UK who writes in newsgroups, andJ who is a lying bag of wind.  It remains to be seen if his fellow contrymanH "NM" who recently wrote in the same newsgroup also stoops to his level."  I See.  I didn't call you anything.  But I implyed that by association, youo( would certainly be capable of something.   >1D >All of that is true.  But it is also true that it is much harder toB >get performance out of it than out of many other chips.  And thatA >is a relevant point to those of us who have to work with limitedu@ >effort, horrible applications and source not under our control. >m  L Is it?  Perhaps the guys at HP are just better at designing for performance.G It also sounds to me that if the compiler is really a large part of the J issue (and I tend to doubt it, knowing some of the compiler people that we> sent to Intel) then I guess the companies who are supplying SWH binaries/objects should get themselves HP systems to do the compiles on.   >oE >I will.  And you are misremembering.  It isn't hard to select a goodiD >testimonial if you are prepared to choose the best out of hundreds. >-  J Sure.  Nonetheless, my point is that "some" people want to create a movingG bar, so that as each possible complaint/suspicion is answered, they can G continually not be satisfied.  At least put a stake in the ground as topJ exactly what it will take... and perhaps that is even having the system inK your hands running your code.  I believe that if you had the system in yourrJ hands, and it did perform flawlessly - you would concede that despite it'sJ potential faults, it was a good system.  There are others in here who willI probably stop writing in these groups before they make such a concession.    >rB >Every heard of selling below a viable price to get a product line5 >introduced?  No?  Most vendors of most things do it.a >r  I It's an interesting concept, but it doesn't match up with anything I have K heard since becoming part of HP.  These guys (the guys building the systemsuI in the UNIX market) don't build a system unless they can make a profit onoD it.  They don't lose money to buy market share from what I can tell.   > A >Well, I am.  "Inevitably the breakthrough does come"?  Oh, yeah?n? >Remember the repeated claims that new designed would mean thatu< >memory latencies would start to fall as fast as cache ones?8 >Software has similar problems, and this is one of them. >   L We'll see.  In your case above, I think that looking out for profits is whatI is driving things, not technology.  Look at the EV7 RAMBUS design.  ThereeH isn't much out there that can touch it's performance.  But I don't think/ you'll see a stampede to follow the technology.r  E >|> Well, it's orderable.  So order one.  Or wait until you can get ae deliveryL >|> date on your order.  If the Spec figures hold up, and the prices are notJ >|> "articifical" - it looks like you would get a respectable UNIX (HP-UX) and a  >|> fast box, for a good price.B >uC >Oh, is it?  I tried to get a quote, just this morning.  Nope.  Notm@ >on our list.  And got the same response from HP's "buy online". >'  I Hmm.  That is suprising.  I didn't follow the links all the way to makinghJ the purchase, but it all seemed to be on the web site.  I assume/hope thatK it's just a screw up someplace.  I know that we are now working on our planUB to start buying them and dumping the Itanium-1's we were using for development.   ------------------------------  # Date: Tue, 09 Jul 2002 17:14:27 GMT.1 From: "Terry C. Shannon" <terryshannon@attbi.com>o4 Subject: Re: McKinley tops SpecFP AND SpecInt charts? Message-ID: <TREW8.339464$6m5.352527@rwcrnsc51.ops.asp.att.net>l  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:xQO8B0clAD80@eisner.encompasserve.org...  <snip>= > I think very good pricing is the angle.  Expensive and fast 8 > isn't the way to overtake a segment.  Fast and cheaper > is probably the only way.f >a > Robr    K A damned shame the Alpha advocates at DECpaq never came to this conclusion.-   ------------------------------  # Date: Tue, 09 Jul 2002 17:21:49 GMTn5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>K4 Subject: Re: McKinley tops SpecFP AND SpecInt charts2 Message-ID: <NYEW8.33$216.590970@news.cpqcorp.net>  L Frankly, I couldn't tell you if there is a HP-UX-specific C/C++ compiler.  II was under the impression that the Intel compiler and the MS compiler wereh the ones everyone used.e  H In the VMS case, we have a number of compilers required for the OS.  TheL initial ones are based on the DEC developed GEM back end, and the DEC/CompaqK compiler front ends.   Why?  Well, for compatability for the most part.  So 5 right now it doesn't matter even if HP had their own.t  G Long term, the C/C++ compiler would be the one from Intel, and Intel is-J making changes in it needed for VMS as well.  Long term, I expect that theI Intel compiler will be the best compiler - especially knowing some of thehI people that we sent them (and at least one was almost immediately made ann Intel Fellow).      " Nick Maclaren wrote in message ... >s- >In article <3D2B15D1.1C201A2A@videotron.ca>,o0 >JF Mezei <jfmezei.spamnot@videotron.ca> writes: >|> Nick Maclaren wrote: >|>pH >|> > Few architectures have such dependence on the chipset and compilerE >|> > as the IA-64 does.  Furthermore, HP themselves have made claimsoE >|> > that much of their performance advantages are PRECISELY becausea7 >|> > of their chipset and compiler!  See, for example:p >|> L >|> I am perplexed as to why HP still has its own IA64 compiler(s) ? On whatH >|> platform does HP's compiler(s) run ? Just HP-UX or also on Windows ? >|>'J >|> When the time comes to have VMS, NSK HP-UX and Widnows on IA64,  which OS willf >|> get whose compilers ?o >a@ >You would have to ask HP.  Don't forget there is also Linux :-)? >Now the relevant products are announced, it is a fair questione >to ask an HP salesman.f >tJ >|> I was under the impression that VMS would inherit the Intel compilers. If theG >|> HP compilers are superior, doesn't this mean that VMS would be at ac? >|> disadvantage versus the HP products thathave HP compilers ?d > @ >At the OpenVMS meeting, the strategic C compiler was said to be= >Intel's, but most of the others were Compaq's (ported).  TheaA >Fortran was under consideration for being changed to use Intel'sW >Electron back end.l >m? >I was extremely surprised that there was no reference to usingo< >HP's compilers under VMS, though it was and is not directly >relevant to us. >, >e	 >Regards,  >Nick Maclaren,l+ >University of Cambridge Computing Service,t? >New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.t >Email:  nmm1@cam.ac.uki0 >Tel.:  +44 1223 334761    Fax:  +44 1223 334679   ------------------------------  % Date: Tue, 09 Jul 2002 18:00:48 +0100aU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>s4 Subject: Re: McKinley tops SpecFP AND SpecInt charts0 Message-ID: <agf4qu$l4s$2@new-usenet.uk.sun.com>   JF Mezei wrote:    > Nick Maclaren wrote: > F >>but it isn't implausible.  A more serious point is that we have VERYI >>good grounds for believing that BOTH HP's zx1 chipset AND HP's compilert >>are worth 10-20% on SpecInt. >> > M > Who does what compiler for IA64 ? Does HP have its own compilers or does it- > rely on the Intel compilers ?2 >     6 HP do their own compiler, Intel do one as well. Unless6 you have the HP compiler you cannot get the SPECint/fp4 results being posted for the platform. Estimates for6 the Intel compilers performance vary but are all lower6 than the numbers being delivered by the current boxes.   More confusion for ISV's.a   Regards  Andrew Harrisone   ------------------------------  # Date: Tue, 09 Jul 2002 17:36:07 GMTc5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>w4 Subject: Re: McKinley tops SpecFP AND SpecInt charts2 Message-ID: <baFW8.34$p26.652387@news.cpqcorp.net>  ? Not confusion for ISV's, just more FUD from SAndy our proud Sund
 spokesperson.w  H So, SAndy - exactly what *is* the Sun response?  How about "perhaps someK other compiler will make it as slow as a Sun"?  Or maybe "well, to actuallytL get that performance you can't run Solaris".  Or "well, they haven't run theK benchmark that our internal committee decided yesterday was the best way to7 compare systems".n   Yeah.  That''ll do.   J Keep up the good work, and pray for Hammer to deliver Solaris from defeat.   _Fred     6 Andrew Harrison SUNUK Consultancy wrote in message ... >g >R >JF Mezei wrote: >  >> Nick Maclaren wrote:> >>G >>>but it isn't implausible.  A more serious point is that we have VERYoJ >>>good grounds for believing that BOTH HP's zx1 chipset AND HP's compiler >>>are worth 10-20% on SpecInt.  >>>P >>K >> Who does what compiler for IA64 ? Does HP have its own compilers or does  it  >> rely on the Intel compilers ? >> >  >t7 >HP do their own compiler, Intel do one as well. Unlesso7 >you have the HP compiler you cannot get the SPECint/fp 5 >results being posted for the platform. Estimates for 7 >the Intel compilers performance vary but are all lower 7 >than the numbers being delivered by the current boxes.e >c >More confusion for ISV's. >m >Regards >Andrew Harrison >t   ------------------------------   Date: 9 Jul 2002 12:36:53 -0600c+ From: young_r@encompasserve.org (Rob Young)e4 Subject: Re: McKinley tops SpecFP AND SpecInt charts3 Message-ID: <Ni$Zka3up4Db@eisner.encompasserve.org>u  s In article <TREW8.339464$6m5.352527@rwcrnsc51.ops.asp.att.net>, "Terry C. Shannon" <terryshannon@attbi.com> writes:e > : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:xQO8B0clAD80@eisner.encompasserve.org...l > <snip>> >> I think very good pricing is the angle.  Expensive and fast9 >> isn't the way to overtake a segment.  Fast and cheapert >> is probably the only way. >> >> Rob >  > M > A damned shame the Alpha advocates at DECpaq never came to this conclusion.u >   F 	That was left unsaid but my exact thoughts.  All about scale, really.  D 	Instead of giving NT away (via MS sweetheart deal), they might haveB 	gone to Intel early on and literally given Alpha away.  I do know@ 	talks took place but the talk should have been: "Here, take it.@ 	The only way this will take off is if you take it."  That wouldE 	have been a career killer for several so of course it didn't happen.a  C 	Instead, Intel bided their time and waited for the second go roundr= 	of knocks on the door where what they got that time was somee@ 	interesting technology to stuff into EPIC instead of owning and@ 	growing a tremendous architecture with EV6/EV7/EV8/EV9 futures.   				Roba   ------------------------------  % Date: Tue, 09 Jul 2002 10:36:40 -0700m& From: Greg Cagle <gregc@gregcagle.com>4 Subject: Re: McKinley tops SpecFP AND SpecInt charts, Message-ID: <3D2B1F28.7080506@gregcagle.com>  ( Andrew Harrison SUNUK Consultancy wrote: >  >  > JF Mezei wrote:u >  >> Nick Maclaren wrote:- >>H >>> but it isn't implausible.  A more serious point is that we have VERYK >>> good grounds for believing that BOTH HP's zx1 chipset AND HP's compilers  >>> are worth 10-20% on SpecInt. >>>e >>G >> Who does what compiler for IA64 ? Does HP have its own compilers or  
 >> does it  >> rely on the Intel compilers ? >> >  > 8 > HP do their own compiler, Intel do one as well. Unless8 > you have the HP compiler you cannot get the SPECint/fp6 > results being posted for the platform. Estimates for8 > the Intel compilers performance vary but are all lower8 > than the numbers being delivered by the current boxes. >  > More confusion for ISV's.r > 	 > Regards  > Andrew Harrison  >   C "More confusion?" No more than normal 8^). Use the compiler for thea+ platform/OS combination that is the target:p  * Itanium 2 running HP-UX - use HP compiler.$ Itanium 2 running Linux - use Intel.& Itanium 2 running Windows - use Intel.  N Are you implying that Sun has the *same compiler* for Sparc *and* x86 targets? -- o
 Greg Cagle gregc at gregcagle dot com   ------------------------------  % Date: Tue, 09 Jul 2002 09:21:55 +0200m' From: JOUKJ <joukj@hrem.stm.tudelft.nl>yF Subject: Re: New web-page dedicated to ports of PD software to OpenVMS0 Message-ID: <3D2A8F13.30809@hrem.stm.tudelft.nl>   Hoff Hoffman wrote:  > JOUKJ wrote:G > : I created a new web page (http://nchrem.tnw.tudelft.nl/openvms/) on  > H >   Please don't mess with the browser-selected color maps.  Just don't.H >   Particularly when the page (sorry) looks like "angry fruit salad".  F >   Blue and gray and red text on a fuscia background are, well, very  >   hard to read.hD I'm just trying to get something that suits myself and others. Most I modern programs/webpages give me a headache since they use black letters cI on a white screen. That's too light intensive for my eyes. I always look eI for ways to avoid that but not always I succeed. This pinkish page is my   answer to that.w3 I changed the page a little so that you can choose.-   > H > : The page consists of link to where to get it, what to patch and what= > : software it depends on (and links to these dependencies).oH > : I hope this page will help to make it easier to find/install/run the > : software on OpenVMS. > E >   With your permission, I'll add a pointer to your page to the nextp >   edition of the OpenVMS FAQ.eC Please do that. The page is intended to help the OpenVMS community.m     > H >   Also, if you have new or newer ports, please consider following the % >   submission guidelines at the URL:  > B >     http://www.openvms.compaq.com/openvms/freeware/cd_guide.html > H >   This will get your ports of the packages onto other sites, and onto I >   the OpenVMS Freeware distribution.   Versions of bzip and ImageMagickeI >   and such are already on the Freeware, though probably older versions.n > G   I know. As I did before. I'll have to ask permission to the original a/ authors. When is the next deadline for this CD?b                             Jouk   ------------------------------  % Date: Tue, 09 Jul 2002 19:17:51 +00104% From: paddy.o'brien@zzz.tg.nsw.gov.au F Subject: Re: New web-page dedicated to ports of PD software to OpenVMS5 Message-ID: <01KJWHFCD84I0009AZ@tgmail.tg.nsw.gov.au>   
 Jouk J wrote:D   >Hoff Hoffman wrote: >> JOUKJ wrote: H >> : I created a new web page (http://nchrem.tnw.tudelft.nl/openvms/) on >> rI >>   Please don't mess with the browser-selected color maps.  Just don't.HI >>   Particularly when the page (sorry) looks like "angry fruit salad".  IG >>   Blue and gray and red text on a fuscia background are, well, very   >>   hard to read.E >I'm just trying to get something that suits myself and others. Most pJ >modern programs/webpages give me a headache since they use black letters J >on a white screen. That's too light intensive for my eyes. I always look J >for ways to avoid that but not always I succeed. This pinkish page is my  >answer to that.4 >I changed the page a little so that you can choose. >s >>  I >> : The page consists of link to where to get it, what to patch and whatL> >> : software it depends on (and links to these dependencies).I >> : I hope this page will help to make it easier to find/install/run ther >> : software on OpenVMS.  >> nF >>   With your permission, I'll add a pointer to your page to the next  >>   edition of the OpenVMS FAQ.D >Please do that. The page is intended to help the OpenVMS community. >c >e >>  I >>   Also, if you have new or newer ports, please consider following the k& >>   submission guidelines at the URL: >> nC >>     http://www.openvms.compaq.com/openvms/freeware/cd_guide.html  >> bI >>   This will get your ports of the packages onto other sites, and onto ,J >>   the OpenVMS Freeware distribution.   Versions of bzip and ImageMagickJ >>   and such are already on the Freeware, though probably older versions. >> 3H >  I know. As I did before. I'll have to ask permission to the original 0 >authors. When is the next deadline for this CD?  M Your compromise is good.  I went on and could read comfortably, as I am sure   many who commented will agree.   Nice page/content.  Thanks   Regards, Paddy   ------------------------------  # Date: Tue, 09 Jul 2002 07:36:22 GMT * From: "Bill Todd" <billtodd@metrocast.net>4 Subject: Re: Only 20% drop in VMS systems (was: wow)> Message-ID: <WnwW8.1215$Bt1.29577@bin5.nnrp.aus1.giganews.com>  2 "Main, Kerry" <Kerry.Main@hp.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF40266080C@kaoexc01.americas.cpqcorp.net. .. Bill,o  E <<< Almost all single applications execute more efficiently on an SMPBF (or slightly NUMA) system than on a cluster, up to the point where the( SMP/NUMA system runs out of headroom.>>>  ! It depends on the application(s).h   ***t No, usually it does not. ***h  C Again, tuning large SMP boxes can be a challenge as well unless theeC application(s) was designed to be partitioned with large numbers oftF CPU's. Just ask any DBA how he would setup their DB for max efficiencyF in a 50 cpu SMP server. Do you think he might have to do some planning here?t   ***eL Duh.  Do you think he'd also have to do some planning to 'clusterize' such a DB?m  L In terms of performance (the context in which the comment was made above) anH SMP box always beats a cluster, since at worst it can be partitioned andG used like a cluster with exceptionally fast links (but also offers more 0 tightly-coupled options that a cluster doesn't).   - bill   ------------------------------  # Date: Tue, 09 Jul 2002 07:27:19 GMT * From: "Bill Todd" <billtodd@metrocast.net>4 Subject: Re: Only 20% drop in VMS systems (was: wow)A Message-ID: <rfwW8.41414$Im2.1499105@bin2.nnrp.aus1.giganews.com>I  2 "Main, Kerry" <Kerry.Main@hp.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF40266080B@kaoexc01.americas.cpqcorp.net. .. Bill,w   Re: grammar school ..a  D I am sorry if I offended the comp.os.vms moderator / grand teacher -" I'll try to behave in the future..   :-)y  A Sigh ... Lots of theory about what might be possible "if xyz wereuF implemented.."  and "if xyz system implemented a log-protected scheme"   ***pL More bullshit:  the *only* point I ventured such a guess on was the issue ofK robust batch queues, since I'm not familiar with Solaris support or lack ofu? it for that or equivalent facilities (nor, I suspect, are you).o  L As for file systems, I gave two examples on Solaris that *are* log-protectedK (and hence well-suited to fail-over situations, both planned and unplanned)hL but failed to point out that for *planned* outages even that's not required:I you just have to stop accepting updates, 'sync' the file system, and then H fail over indicating that the file system is 'clean' (again, a matter of seconds from start to finish). ***n  < and "I suspect that the same could be implemented if ......"  C Lets talk specifics here - and let Andrew explain about how SolarissE implements all of the "what might be possible if scenarios's .." thate you raised.i   *** J Since you chose to repeat that allegation, I'll choose to repeat that it'sG bullshit:  in all but one case I presented specifics, not suppositions.e ***e  H >>> suggesting that other approaches that have recently become availableF can't solve most of the same problems VMS clusters can reflects either ignorance or FUD.<<<  H Stay focussed - my question to Andrew was on how a single SMP box (not aF cluster - remember Andrew is promoting big SMP boxes over clusters forH IT Consolidation) can maintain application availability when servers are shut down proactively.   ***kJ That's true, and I have no idea why Andrew chose to focus on large SMP *toH the apparent exclusion of* clustering rather than on how they complementK each other.  But since that was the obvious response he should have made, Iu made it for him. ***s  G >>> IOW, there is no (more) application restarting than occurs on a VMSo< cluster when a node exits (in both cases, one should migrate% applications elsewhere beforehand)<<<r  G Ok, switch to clusters mode .. Remember to focus on proactive shutdownsE here.e  H You do not need to "move" OpenVMS cluster applications at all since theyA are already running in full read-write mode on other nodes in thevF cluster. What do you mean by this statement "in both cases, one should$ migrate applications elsewhere .." ?   *** H I mean that likely the vast majority of applications that execute in andF benefit from the robustness of cluster environments are not themselvesJ cluster-aware, either on VMS or on Solaris.  You yourself gave examples ofH migrating activity off a VMS node to other nodes prior to a planned nodeE shutdown, and the same kind of thing applies to activity on a Solaris,
 cluster node.e  I Of course, cluster-aware applications *can* be run on Solaris clusters ase< well as on VMS clusters, so that's not a distinction either. ***y  F I know you know this already, but the shared everything clustered fileF system and DLM in an OpenVMS cluster ensures that users and batch jobsG on other servers have direct (not served) read-write access to the same / data from all the other systems in the cluster.p   ***lJ 'Direct (not served)' file access is not a functional difference:  at mostI it's a performance optimization (if inter-node communication is leisurely I and/or access activity exceeds the capability of a single server to servevJ it, though this latter can be avoided by dispersing different parts of the@ file system to different servers as both Solaris and Tru64 can).  L And when file access is served, you don't need a DLM to coordinate it, sinceJ locks are local to the server (though you do need a lock rebuild mechanismL when the server fails, and NFS has one, as does - IIRC - the new Sun clusterJ file system).  While Sun does not provide a DLM for the use of distributedI applications wishing to coordinate their activities, the distributed filesI system (using dummy locks the significance of which is agreed upon by the4E cooperating applications) can substitute in a manner already somewhataJ traditional in the Unix environment (yes, it's a bit of a kludge, but onceF again *functionally* it does the job and its performance isn't too bad either). ***m  H So, in this scenario, since all of the work and processing is being doneE on other servers (was moved transparently before hand) a server goingnG down proactively has zero impact on application availability. There are F no application connections open to that server and all batch jobs haveH completed and/or directed to other nodes in the cluster. (yes, I realizeD those users that stay logged into servers for days on end need to be& asked to logout and log back in again)   ***tL Once again, just the same approaches that work in a Solaris cluster as well. ***o  * Hey - I am willing to have my eyes opened,   ***tA If that were true, I wouldn't have had to repeat several of thesee  explanations a half-dozen times. ***l    but lets get specific. Forget
 the "theory".x   ***1J Learn to read:  I already *was* specific.  Let's stop the bullshit, Kerry. ***0  E Lets document (or provide pointers) exactly how Solaris can implementoG proactive server shutdowns with zero impact on application availability . i.e. no broken connections or work restarting.   ***ME You mean as you've provided pointers to exactly how VMS supports such H activity?  Unless you're completely Internet-incompetent you can find asH much 'exact' information as you feel you need at www.sun.com - just as IL have when so inclined.  And of course anyone else who might actually want toF *learn* about such facilities for some reason or another would be wellL advised to go to the source anyway rather than depend upon newsgroup chatter to make deployment decisions.    - bill   ------------------------------  % Date: Tue, 09 Jul 2002 09:15:00 +0100a% From: Alan Greig <a.greig@virgin.net>r4 Subject: Re: Only 20% drop in VMS systems (was: wow)8 Message-ID: <uj5liugp2f5ap4ojrgslpdsb60f0efp3h4@4ax.com>  4 On Mon, 08 Jul 2002 14:53:49 GMT, "Terry C. Shannon" <terryshannon@attbi.com> wrote:z     >cM >I would ask that question of Sybase and SAP. SAP dropped VMS support because3M >the addressable market rendered continued support a non-starter. Now, if HPQAM >shareholders supported the notion of HPQ giving a few hundred million USD top9 >SAP to fund a new port, perhaps SAP would be interested.   C At a Compaq VMS session in Edinburgh  three or four years ago,(justy@ after Compaq took over), the IT manager of a large multinationalD chemicals company stood up and complained that they had been advisedB (by DEC) to move away from SAP on VMS to SAP on OSF/1 (Tru64).  HeB complained that he felt DEC had misled them  as they "still missed1 there VMS clusters" and Unix just wasn't as good..  F I Wonder how many other VMS SAP sites received the same advice. I alsoD wonder how  many new sites DEC pitched VMS as the prime candidate OS0 for SAP during sales pitches. Not many I guess.   F Just as today when you call Compaq and ask them in for a discussion of; SAP on Tru64 they also give you prices (unasked) for SAP oneF Intel/Windows hardware which undercut the Alpha/Tru64 prices. And theyC are not allowed to suggest that the Tru64 solution is more reliable  than NT/W2K.  E But then again when they commit themselves to Alpha one week, drop iteF the next, then commit to a Trru64 port to Itanium, then drop that, allE during the course of discussions, who would want to buy anything from * them? This is exactly what happened to us.  F Thus Compaq (or more likely Dell) sell more low margin PC hardware and> MS can boast that most new SAP implementations are on Windows.
 Brilliant eh?   5 It remains  to be seen if HP will change this policy.g   -- Alan   ------------------------------  % Date: Tue, 09 Jul 2002 10:23:29 +0100"U From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com> 4 Subject: Re: Only 20% drop in VMS systems (was: wow)0 Message-ID: <agea1f$cgd$1@new-usenet.uk.sun.com>   David J. Dachtera wrote:  * > Andrew Harrison SUNUK Consultancy wrote: >  >>Main, Kerry wrote: >> >> >>>JF -a >>>>F >>>Re: measuring numbers of systems Customers have as a measure of how >>>popular they were vs now .. >>> J >>>Fwiw, the total numbers of systems in almost all med to large CustomersJ >>>is shrinking a huge amount these days. Almost every one of these Cust'sK >>>is either considering, investigating or implementing an IT consolidationh4 >>>project as a means to reduce their overall costs. >>>sF >>>And this applies to all platforms. We bid on one RFP here in CanadaI >>>whereby the Govt wanted to reduce the number of small Sun systems fromiJ >>>150 down to less than 10. Another Customer has over 1100 NT servers andH >>>wanted this number to shrink to 250 range. Another Customer in CanadaK >>>has approx 115 small VAX and Alpha servers across the country and wantesV1 >>>to reduce that overall number to less than 10.- >>> K >>>All of these have the same thing in common. Reduce the overall number ofoB >>>servers with much bigger, higher availability and in many casesJ >>>multi-site as well... (IT consolidation 101 says a single site is not a >>>wise move.) >>>i >>>e >>Motherhood and Apple pie.e >>= >>But how will you address this with OpenVMS. Lets get a tiny  >>weeny dose of reality here.f >> >>1.3 >>Unless you cluster which can drag your SW licence < >>costs up to a level that makes you wince OpenVMS currentlyF >>doesn't have a platform that will support very large consolitations. >> > 8 > I'm surprised no one lambasted you for that statement! > J > In the past, I've had VAX 6600-series machines with upwards of 200 usersJ > running All-in-1 (the hog of hogs), while current "Citrix servers" don'tC > seem to be able to handle much more than 15 users without seriousg > performance degradation. >     G Well I wouldn't single Citrix out as being an example of a particularly E efficient product there are others that do the same job which I wouldl
 select first.n  B But you arn't exactly comparing like with like, Citrix server is aF product that takes RDP/X11 and translates it into an adaptive protocol for use with the Citrix client.   C All-in-1 is an office suite, and it may well have relatively been agC performance pig, a role that on UNIX boxes was fufilled by Uniplex,aA we ran 100+ Uniplex users on a Sun 4-280, I would not like to tryuF the same excercise with the same system and any modern Office product,@ just the memory footprint alone would kill the 4-280 stone dead.   Regardsw Andrew Harrisonr   ------------------------------  % Date: Tue, 09 Jul 2002 10:39:54 +0100oU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>a4 Subject: Re: Only 20% drop in VMS systems (was: wow)0 Message-ID: <ageb08$cor$1@new-usenet.uk.sun.com>   Bob Ceculski wrote:w   > Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com> wrote in message news:<agc2cp$jqc$1@new-usenet.uk.sun.com>...i >  >>Main, Kerry wrote: >>= >>	If the attempts at TCO studies that you have published arew@ >>	anthing to go by and we all know now that they don't actually= >>	show OpenVMS to be a lower cost environment because of thet? >>	miss-categorisation of your systems, then the answer to this ; >>	question unless you can come up with something better ise >>	also no.  >> > G > the less computers involved in a solution, the less chips involved intC > a solution means lower TCO in the long run ... add VMS clusteringe > and you lose Andrew ...r    = No Bob you lose, "the less computers involved, the less chipse- in a solution means lower TCO" is your claim.V  > We all know and you better than most that you need fewer CPU's; on large Sun's to get the same throughput as a large Alpha.t  ; Or had you forgotten that you have failed miserably in youra< attempts to justify the SPARC slower ALpha faster claims you# have been making for large servers.   8 We all know that because of this you need 2-3 GS320's to: deliver the same throughput as one F15000, so our solution; will require you to buy fewer CPU's and fewer servers whichl& I agree with you delivers a lower TCO.       >  > ? >>Add Sybase into the mix and you have a very difficult task on 0 >>your hands if OpenVMS is your chosen platform. >> > D > Sybase is garbage compared to RDB ... maybe that's why they are noE > longer on VMS Andrew, it's called competition, and the best productsC > wins, except for those who buy Sun or IBM or Windoze garbage over C > Alpha/VMS, then they love paying TCO thru their nose, or they buyg1 > the kind of TCO lies you and others put out ...  >     D Right, so you have a consolidation project that has 20 Sybase DBMS'sE how are you going to address this with OpenVMS. Telling the owners ofIE the apps that the tool they chose was garbage isn't going to move they consolidation forward one inch.   E Bob, the only TCO lies being told are the ones you read where OpenVMSgC always comes first, I havn't ever claimed that Solaris TCO is lower B than OpenVMS, I have just pointed out that the so called "studies"? that show OpenVMS to have the lowest TCO are so badly flawed byp7 incorrect platform comparisons that they are worthless.e  D If anyone in the OpenVMS camp had been able to justify the inclusionC of the GS160 in a group of servers that have twice its capacity andaG the GS320 in another group of servers that also have twice its capacity * then you would be justified in your claim.  A But as you know, none of the OpenVMS choir have been able to pulle	 this off.a    A It is always a pleasure to converse with you, but please rememberp> not to make any more SPARC slower Alpha faster BS claims until= you can come up with a jusification for them. It is more thani< a little tiresome that you keep persisting with this despite? a total failure on your part to provide any relevant supporting> evidence to justify your BS.   regardsp Andrew Harrisonr   ------------------------------  % Date: Tue, 09 Jul 2002 11:39:27 +0100zU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>r4 Subject: Re: Only 20% drop in VMS systems (was: wow)0 Message-ID: <ageeft$dta$1@new-usenet.uk.sun.com>   Main, Kerry wrote:  	 > Andrew,  >  > E >>>>Why would you need to shut it down, I can remove CPU's memory and  >>>>0 > I/O controllers on any Sun in the F3800-F15000F > range without any downtime, I can add them and I can add for example/ > faster CPU's/more memory without downtime.<<<t > 9 > So what happens when the load exceeds a single server? w >     6 Well of course thats a problem, but then your issue in7 a cluster of little GS boxes arrives much earlier, whens; should I start paying 50% more for my DBMS licenses so thata* I might if I am lucky get 70% scalability.  > Your model is hardly a good deal, 50% more per CPU and at best8 70% scalability provided you are prepared to work at it.    G > Perhaps an application that does not scale in an SMP environment (youlJ > know as well as I do that there are application and OS issues with largeH > SMP tuning like cache thrashing), or the business load all of a sudden$ > becomes much higher than expected? >     6 Well interesting thought, but then an app that doesn't8 scale in an SMP environment is a highly likely candidate7 not to scale in a cluster as well, or had you forgottenu that.h  9 Of course there are apps or rather services that do scalem; really well on clusters, web services for example, but then 7 you don't need anything like an OpenVMS cluster to make 8 this work and very few people have bothered in practice.  < And thats the problem, all the good examples of apps scaling: in a "cluster" tend to be ones that have an minimal set of8 requirements from the cluster infrastructure itself. The9 favourite example TPC-C scales wonderfully on clusters as:9 primitive as MS-Cluster server for the simple reason that8& it uses virtually no cluster services.    G > Replace that single production server with a bigger one? Sure, that'sAH > one option. Course, now you have to replace the backup server (the oneH > that is hardly used) as it also needs to be capable of handling larger( > loads in the event of a failover etc.. >     ? You seem to take a very rigid view of the world, many customers @ I work with use their standby servers for DR in a campus cluster@ plus devt, UAT etc. If they have to they kick the developers/UAT> users off and give the production users all of the system, its quite a common setup.m     > C >>>Tuning, some tuning does require a re-boot but a great deal does( >>>I	 > not,<<<r > J > As far as your system tuning patching notes - all OS platforms have someA > dynamic patching capabilities and some static ones that requirenA > rebooting the system. Same goes for OpenVMS. Same for Solaris. g > C > The advantage clusters provides is that you can do planned systemyF > reboots like these with ZERO application availability impact. SimplyJ > allow current work to complete while directing new work to other systemsJ > in the cluster. When no work is left on that server, it can be shutdown,E > upgraded, replaced with a bigger server, whatever - again with ZEROo& > impact on application availability.  >     A Of course you can but then this isn't a unique feature of OpenVMSt is it.    % > Re: online hot swap capabilities ..  > G > Imho, who cares if one can add additional CPU's (you can do this withsH > OpenVMS / GS Series as well btw) or IO controllers online, if you haveI > the capability to add and/or replace entire systems in a cluster onlineF* > with no application availability impact? >     > As you can with most UNIX clusters, you take a node out of the> cluster, patch it, maintain it or whatever reason you have forA doing this and then bring it back into the cluster. Its a featurev of most cluster software.a     > H >>>if you can do the upgrade while the system is online only requiring a >>>*E > reboot to run the new image then the bulk of your downtime has beent
 > avoided.<<<i > E > Any planned reboot (no matter how short) causes huge issues i.e. iseH > typically very visible and hence needs to be scheduled and approved byE > the business groups. These "reboots" are typically planned weeks ore > months in advance. >     = Right as are OS upgrades, we generally don't expect customers ; to just turn around and upgrade their OS during their luncho break.  @ In case you hadn't worked it out its a bit more complicated thanC that, much more if you are unfortunate enough to have OpenVMS sincesB upgrading from say 7.2 to 7.2-2 would mean in some cases upgrading
 apps as well.e    E > When combined with previous method of moving users, and dual systemnG > disks, Clusters provide the capability to do rolling OS upgrades withVH > ZERO impact on application availability - do not even need to tell theE > end users you are doing it. Application folks of course have testede > their stuff previously.c > I > Fwiw, the future is to establish infrastructures that allow OperationalcD > folks to do what they have to do while providing a seamless alwaysH > available application infrastructure to the end users and/or business. > I > Again, clusters are not the answer to all requirements and do not solvetJ > world hunger, but they do offer excellent capabilities for those looking% > at large IT Consolidation projects.h >     ? Of course they do but they are your hammer, you don't do reallys= big SMP machines running OpenVMS, we have both options and weo> have a decent software portfolio without which this discussion is pointless anyway.  ; With the kind of software availability OpenVMS suffers fromaC it is inevitable that it will be a donor platform in consolidations  rather than the recipient.     RegardsT   Andrew Harrisonh   ------------------------------  $ Date: Tue, 9 Jul 2002 09:09:04 -0400' From: "Main, Kerry" <Kerry.Main@hp.com>o4 Subject: RE: Only 20% drop in VMS systems (was: wow)T Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF40266080D@kaoexc01.americas.cpqcorp.net>  
 G'day Andrew,    Here we go again ..t  F >>> Well interesting thought, but then an app that doesn't scale in an, SMP environment is a highly likely candidate? not to scale in a cluster as well, or had you forgotten that.<<   @ Nope. Different issues. Again, large SMP approaches are good forE applications designed to be broken up into many small pieces or for aiG variety of mixed loads. However, in large SMP environment you also mustnF deal with the issue of cache invalidations among many CPU's when thereB is a relatively low number of memory references that constantly isC getting updated. Yes, there are ways to reduce this problem, but itr( really boils down to application design.  B >>> As you can with most UNIX clusters, you take a node out of theD cluster, patch it, maintain it or whatever reason you have for doingC this and then bring it back into the cluster. Its a feature of most  cluster software.<<<  E Great. Now tell me how you do this without disconnecting any users or*H even telling them that a server is being taken down - say for example at@ 09:00AM (prime time) to avoid overtime costs for staff involved.  D >>> In case you hadn't worked it out its a bit more complicated thanC that, much more if you are unfortunate enough to have OpenVMS since G upgrading from say 7.2 to 7.2-2 would mean in some cases upgrading apps  as well.<<<m  G Nope. Unless one is doing a major upgrade (e.g. V6.x to V7.x or V7.x tobG V8.x etc), then most applications are typically not impacted. Again, asaF I stated earlier, application testing is done previously to make sure.  H >> Right as are OS upgrades, we generally don't expect customers to just= turn around and upgrade their OS during their lunch break.<<<a   Why not?=20i  G Reduce overtime costs by doing work like this during regular hours. Allu? support staff (including vendor staff remotely) is available ifoE problems. Key here is that end users do not even know the OS is beingm1 upgraded, so why not do the upgrade during lunch?-  > Again - future of IT is in establishing an environment wherebyG Operations staff can do whatever they need to do and yet not impact thet end users or the business.=205   :-)5   Regardss  
 Kerry Main Senior Consultant8 Hewlett-Packard Canada! Consulting & Integration Servicest Voice: 613-592-4660  Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----' From: Andrew Harrison SUNUK Consultancyi7 [mailto:andrew_nospam.harrison_remove_this@sun#.com]=20u Sent: July 9, 2002 6:39 AM To: Info-VAX@Mvb.Saic.ComU4 Subject: Re: Only 20% drop in VMS systems (was: wow)         Main, Kerry wrote:  	 > Andrew,n >=20 >=20E >>>>Why would you need to shut it down, I can remove CPU's memory and  >>>>0 > I/O controllers on any Sun in the F3800-F15000I > range without any downtime, I can add them and I can add for example=20M/ > faster CPU's/more memory without downtime.<<<e >=208 > So what happens when the load exceeds a single server? >=20    6 Well of course thats a problem, but then your issue in7 a cluster of little GS boxes arrives much earlier, when ; should I start paying 50% more for my DBMS licenses so that * I might if I am lucky get 70% scalability.  > Your model is hardly a good deal, 50% more per CPU and at best8 70% scalability provided you are prepared to work at it.    G > Perhaps an application that does not scale in an SMP environment (younD > know as well as I do that there are application and OS issues with large H > SMP tuning like cache thrashing), or the business load all of a sudden$ > becomes much higher than expected? >=20    6 Well interesting thought, but then an app that doesn't8 scale in an SMP environment is a highly likely candidate7 not to scale in a cluster as well, or had you forgotten  that.k  9 Of course there are apps or rather services that do scalet; really well on clusters, web services for example, but thenh7 you don't need anything like an OpenVMS cluster to makey8 this work and very few people have bothered in practice.  < And thats the problem, all the good examples of apps scaling: in a "cluster" tend to be ones that have an minimal set of8 requirements from the cluster infrastructure itself. The9 favourite example TPC-C scales wonderfully on clusters ast9 primitive as MS-Cluster server for the simple reason that & it uses virtually no cluster services.    G > Replace that single production server with a bigger one? Sure, that'swH > one option. Course, now you have to replace the backup server (the oneH > that is hardly used) as it also needs to be capable of handling larger( > loads in the event of a failover etc.. >=20    ? You seem to take a very rigid view of the world, many customerso@ I work with use their standby servers for DR in a campus cluster@ plus devt, UAT etc. If they have to they kick the developers/UAT> users off and give the production users all of the system, its quite a common setup.d     >=20C >>>Tuning, some tuning does require a re-boot but a great deal doesh >>>m	 > not,<<<n >=20E > As far as your system tuning patching notes - all OS platforms havel someA > dynamic patching capabilities and some static ones that requirebC > rebooting the system. Same goes for OpenVMS. Same for Solaris.=20m >=20C > The advantage clusters provides is that you can do planned systemiF > reboots like these with ZERO application availability impact. SimplyB > allow current work to complete while directing new work to other systemsA@ > in the cluster. When no work is left on that server, it can be	 shutdown, E > upgraded, replaced with a bigger server, whatever - again with ZEROc( > impact on application availability.=20 >=20    A Of course you can but then this isn't a unique feature of OpenVMSw is it.    % > Re: online hot swap capabilities ..' >=20G > Imho, who cares if one can add additional CPU's (you can do this withaH > OpenVMS / GS Series as well btw) or IO controllers online, if you haveB > the capability to add and/or replace entire systems in a cluster online* > with no application availability impact? >=20    > As you can with most UNIX clusters, you take a node out of the> cluster, patch it, maintain it or whatever reason you have forA doing this and then bring it back into the cluster. Its a feature  of most cluster software.r     >=20H >>>if you can do the upgrade while the system is online only requiring a >>> E > reboot to run the new image then the bulk of your downtime has beenn
 > avoided.<<<a >=20E > Any planned reboot (no matter how short) causes huge issues i.e. isbH > typically very visible and hence needs to be scheduled and approved byE > the business groups. These "reboots" are typically planned weeks orn > months in advance. >=20    = Right as are OS upgrades, we generally don't expect customerse; to just turn around and upgrade their OS during their lunch  break.  @ In case you hadn't worked it out its a bit more complicated thanC that, much more if you are unfortunate enough to have OpenVMS since B upgrading from say 7.2 to 7.2-2 would mean in some cases upgrading
 apps as well.>    E > When combined with previous method of moving users, and dual systempG > disks, Clusters provide the capability to do rolling OS upgrades with-H > ZERO impact on application availability - do not even need to tell theE > end users you are doing it. Application folks of course have testeda > their stuff previously.  >=20= > Fwiw, the future is to establish infrastructures that allowh OperationalaD > folks to do what they have to do while providing a seamless alwaysH > available application infrastructure to the end users and/or business. >=20C > Again, clusters are not the answer to all requirements and do noto solvemB > world hunger, but they do offer excellent capabilities for those looking % > at large IT Consolidation projects.m >=20    ? Of course they do but they are your hammer, you don't do reallya= big SMP machines running OpenVMS, we have both options and wer> have a decent software portfolio without which this discussion is pointless anyway.  ; With the kind of software availability OpenVMS suffers fromtC it is inevitable that it will be a donor platform in consolidationsr rather than the recipient.     Regardso   Andrew Harrison    ------------------------------  % Date: Tue, 09 Jul 2002 14:01:20 +0100lU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>o4 Subject: Re: Only 20% drop in VMS systems (was: wow)0 Message-ID: <agempu$gm2$1@new-usenet.uk.sun.com>   Main, Kerry wrote:   > Bill,. > G > <<< Almost all single applications execute more efficiently on an SMPoH > (or slightly NUMA) system than on a cluster, up to the point where the* > SMP/NUMA system runs out of headroom.>>> > $ > It depends on the application(s).  > E > Again, tuning large SMP boxes can be a challenge as well unless thesE > application(s) was designed to be partitioned with large numbers ofnH > CPU's. Just ask any DBA how he would setup their DB for max efficiencyH > in a 50 cpu SMP server. Do you think he might have to do some planning > here?' >     = Arrg, of course tuning a large SMP box isn't simple but it is > much easier than tuning an app to work and scale in a cluster.  > Of course a DBA may need to do some planning, for example withC Sybase he/she will need to start ~50 DBMS server processes in ordert to make use of all the CPU's.t  = But don't you think that a DBA may have to do just a tiny bit = more planning in order to take his/her DBMS and run it acrossa multiple nodes in a cluster.  ? For a start he/she needs to go and buy some new Oracle licensesa< then they need to think how best to partion the DBMS etc etc etc.  ? The best I can glean from your responses is that you don't haveo@ any idea about tuning apps for clusters or large SMP machines if at all.     E > <<< IOW, large SMP/NUMA boxes are good.  So is clustering.  Neithern > makes the other irrelevant.>>B > H > Agreed. I also agree that using fewer bigger SMP capable boxes is whatH > IT Consolidation is all about. However, when doing IT Consolidation orD > eWhatever type external applications, the expected loads are oftenJ > seriously underestimated. A properly configured OpenVMS cluster providesJ > one with the flexibility to simply add or remove an entire system to the@ > overall processing with zero application availability impact.  >     @ But does it, you yourself have suggested that DBA's need to planA carefully for scaling on an SMP machine, everyone knows that this>9 is a much more complex task in a cluster and more costly.m  A So most customers would prefer to buy a system that has 2-3 x thea@ capacity and plan to scale the system as an SMP box, rather thanG pay 50% more upfront and work much harder in your clustered environment 9 because you need to cluster for scalability 2-3x earlier.o  E Even you can see that what you are proposing makes no business sense.s    E > Anyway, this is a rat-hole. Both single large SMP and clusters havecI > pro's-n-con's. Where the expected loads are not easy to estimate, imho, F > the best approach is to cluster fewer large SMP servers and only add! > additional servers as required.  >     B You seem to think that they are mutually exclusive, they arn't how@ about taking 2 very large SMP machines and cluster them wow what
 a concept.  D The point is that because of the historical and current deficienciesE in the AlphaServer range the break point at which you have to clustertA to acheive the required throughput has always been lower than theg? industry leaders, since the mid 90's by a fairly constant 2-3x.o  D Sun, HP and IBM have concentrated on SMP scalability with clustering6 Compaq clustering with SMP scalability a distant 2and.  G  From an apps/cost of ownership standpoint the SMP scalability approach @ is more efficient than the cluster approach, particularly if theB cluster protagonist insists in charging a premium for the building blocks.o    I > What started this discussion was Andrew stating SMP servers were betteruI > for IT Consolidation than clusters. However, imho, SMP servers on their I > own do not typically provide the level of availability that is requiredl' > when doing IT Consolidation projects.t >     C No that isn't what I said. I said that the lack of a very large SMPrC platform for OpenVMS made it less suitable for server consolidationd> because it forces people to cluster much earlier than on other platforms to get scalability.e  > I would always for DBMS's recommend the people scale their SMP> systems rather than scale using a cluster because the outcomes0 are more reliable from a performance standpoint.  ; This is Oracle's view and probably a straw poll in HP wouldo; also elicite a majority of respondants in favour of my view  rather than yours.  > These issues and the lack of software support for OpenVMS make9 is one of the least suitable platforms I can think of for  cross platform consolidation.i  > I assume from your silence on the software availability points4 that you agree however reluctantly with my analysis.   Regards  Andrew Harrisonl   ------------------------------  $ Date: Tue, 9 Jul 2002 11:57:39 -0400' From: "Main, Kerry" <Kerry.Main@hp.com> 4 Subject: RE: Only 20% drop in VMS systems (was: wow)T Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF40266080F@kaoexc01.americas.cpqcorp.net>   Andrew,u  F >>> But don't you think that a DBA may have to do just a tiny bit moreG planning in order to take his/her DBMS and run it across multiple nodesu in a cluster.<<<  H Sure. However, any Oracle DBA will also tell you that the amount of workH and/or planning something like a OPS environment is on the same scale asE planning a 50 cpu SMP config. Both need careful attention to what theiA workload is expected to be, how server shutdowns, backups will ben handled etc...  F >>> You seem to think that they are mutually exclusive, they arn't howB about taking 2 very large SMP machines and cluster them wow what a concept.<<<h  ? Andrew, try reading before writing. Now that's a great concept.t   :-)t  H Here is what I said - "imho, the best approach is to cluster fewer large9 SMP servers and only add additional servers as required."   E Anyway, this "big SMP is better than clusters" discussion could go on @ forever. Both have advantages and disadvantages. Performance andE availability design decisions should always be made on a case by cases basis.  " Time to move on to something else.  
 Kerry Main Senior Consultantp Hewlett-Packard Canada! Consulting & Integration Servicese Voice: 613-592-4660r Fax   : 613-591-4477 Email: Kerry.Main@hp.com     -----Original Message-----' From: Andrew Harrison SUNUK Consultancyw7 [mailto:andrew_nospam.harrison_remove_this@sun#.com]=20m Sent: July 9, 2002 9:01 AM To: Info-VAX@Mvb.Saic.Coms4 Subject: Re: Only 20% drop in VMS systems (was: wow)         Main, Kerry wrote:   > Bill,h >=20J > <<< Almost all single applications execute more efficiently on an SMP=20H > (or slightly NUMA) system than on a cluster, up to the point where the  * > SMP/NUMA system runs out of headroom.>>> >=20# > It depends on the application(s).  >=20E > Again, tuning large SMP boxes can be a challenge as well unless thewH > application(s) was designed to be partitioned with large numbers of=20H > CPU's. Just ask any DBA how he would setup their DB for max efficiency  H > in a 50 cpu SMP server. Do you think he might have to do some planning   > here?r >=20    B Arrg, of course tuning a large SMP box isn't simple but it is much9 easier than tuning an app to work and scale in a cluster.   E Of course a DBA may need to do some planning, for example with SybaseaH he/she will need to start ~50 DBMS server processes in order to make use of all the CPU's.a  B But don't you think that a DBA may have to do just a tiny bit moreG planning in order to take his/her DBMS and run it across multiple nodess
 in a cluster.t  D For a start he/she needs to go and buy some new Oracle licenses then< they need to think how best to partion the DBMS etc etc etc.  H The best I can glean from your responses is that you don't have any idea? about tuning apps for clusters or large SMP machines if at all.     H > <<< IOW, large SMP/NUMA boxes are good.  So is clustering.  Neither=20 > makes the other irrelevant.>>  >=20H > Agreed. I also agree that using fewer bigger SMP capable boxes is what  H > IT Consolidation is all about. However, when doing IT Consolidation or  G > eWhatever type external applications, the expected loads are often=20eD > seriously underestimated. A properly configured OpenVMS cluster=20H > provides one with the flexibility to simply add or remove an entire=20H > system to the overall processing with zero application availability=20	 > impact.f >=20    @ But does it, you yourself have suggested that DBA's need to planF carefully for scaling on an SMP machine, everyone knows that this is a4 much more complex task in a cluster and more costly.  A So most customers would prefer to buy a system that has 2-3 x the H capacity and plan to scale the system as an SMP box, rather than pay 50%G more upfront and work much harder in your clustered environment because 1 you need to cluster for scalability 2-3x earlier.N  E Even you can see that what you are proposing makes no business sense.i    H > Anyway, this is a rat-hole. Both single large SMP and clusters have=20F > pro's-n-con's. Where the expected loads are not easy to estimate,=20H > imho, the best approach is to cluster fewer large SMP servers and only  % > add additional servers as required.i >=20    H You seem to think that they are mutually exclusive, they arn't how aboutE taking 2 very large SMP machines and cluster them wow what a concept.x  G The point is that because of the historical and current deficiencies in E the AlphaServer range the break point at which you have to cluster to G acheive the required throughput has always been lower than the industryo6 leaders, since the mid 90's by a fairly constant 2-3x.  D Sun, HP and IBM have concentrated on SMP scalability with clustering6 Compaq clustering with SMP scalability a distant 2and.  G  From an apps/cost of ownership standpoint the SMP scalability approachhH is more efficient than the cluster approach, particularly if the clusterB protagonist insists in charging a premium for the building blocks.    E > What started this discussion was Andrew stating SMP servers were=20dJ > better for IT Consolidation than clusters. However, imho, SMP servers=20I > on their own do not typically provide the level of availability that=20a3 > is required when doing IT Consolidation projects.- >=20    C No that isn't what I said. I said that the lack of a very large SMPrC platform for OpenVMS made it less suitable for server consolidationsH because it forces people to cluster much earlier than on other platforms to get scalability.p  F I would always for DBMS's recommend the people scale their SMP systemsH rather than scale using a cluster because the outcomes are more reliable from a performance standpoint.  H This is Oracle's view and probably a straw poll in HP would also eliciteA a majority of respondants in favour of my view rather than yours.w  H These issues and the lack of software support for OpenVMS make is one of> the least suitable platforms I can think of for cross platform consolidation.  G I assume from your silence on the software availability points that youf+ agree however reluctantly with my analysis.    Regards0 Andrew Harrison    ------------------------------  % Date: Tue, 09 Jul 2002 17:22:36 +0100lU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>t4 Subject: Re: Only 20% drop in VMS systems (was: wow)0 Message-ID: <agf2ja$kim$1@new-usenet.uk.sun.com>   Main, Kerry wrote:   > G'day Andrew,n >  > Here we go again ..l >  > F >>>>Well interesting thought, but then an app that doesn't scale in an >>>>. > SMP environment is a highly likely candidateA > not to scale in a cluster as well, or had you forgotten that.<<  > B > Nope. Different issues. Again, large SMP approaches are good forG > applications designed to be broken up into many small pieces or for axI > variety of mixed loads. However, in large SMP environment you also must H > deal with the issue of cache invalidations among many CPU's when thereD > is a relatively low number of memory references that constantly isE > getting updated. Yes, there are ways to reduce this problem, but itr* > really boils down to application design. >     = Sorry this is total BS. Large SMP machines are good at singlefA queries on very large DBMS's this is totally unlike your example, A and if you need confirmation of this look at something like TPC-H,C where the fastest SMP systems are faster than the fastest clusters.r The classic big batch job.  A They are also as you say good at running lots of very small jobs,nH but you totally miss the point by disappearing down a cache red-herring.  @ Very big SMP machines are good when you need to hold state, callA it a DBMS if you like. Somewhere in almost every environment is a = place where state resides. State has to be managed to prevent = it being corrupted or modified when it should not be, this is @ most done using some sort of locking mechanism. SMP machines due< to their very bandwidths and low latency (excluding GS boxes= obviously) are better places to hold state that needs to havec+ multiple simultaneous access than clusters.b  A Big SMP machines are also generally better for big single queriesm@ than large clusters because they don't have the same issues that% clusters do processing complex joins.E  < Yes cache coeherancy is an issue, but it isn't an issue thatB any applications developers expect to have to solve. Interestingly7 clustering does expect applications developers and alsoh< administrators to design their way arround issues introduced; by being in a cluster. The best practical example being the . need for a DBA to partition data in a cluster.     > B >>>>As you can with most UNIX clusters, you take a node out of the >>>>F > cluster, patch it, maintain it or whatever reason you have for doingE > this and then bring it back into the cluster. Its a feature of most  > cluster software.<<< > G > Great. Now tell me how you do this without disconnecting any users orcJ > even telling them that a server is being taken down - say for example atB > 09:00AM (prime time) to avoid overtime costs for staff involved. >  > D >>>>In case you hadn't worked it out its a bit more complicated than >>>>E > that, much more if you are unfortunate enough to have OpenVMS sinceeI > upgrading from say 7.2 to 7.2-2 would mean in some cases upgrading apps 
 > as well.<<<b > I > Nope. Unless one is doing a major upgrade (e.g. V6.x to V7.x or V7.x tomI > V8.x etc), then most applications are typically not impacted. Again, ashH > I stated earlier, application testing is done previously to make sure. >     < Wrong, you really arn't good at this are you, check Oracle'sB certification page (metalink.oracle.com if you have never used it)? its your friend if you are seriously doing consolidations whicha from the previous post I doubt.t  ; If you do you will find that 7.2, 7.2-1, 7.2-1H1, 7.2-2 alle< have different Oracle certification matrixes, or put another: way its a very good idea to check this before even doing a! minor version upgrade on OpenVMS.i  : Now I am sure that the uncertified Oracle DBMS is probably8 going to work on the uncertified platform, but you do at6 least want to propose something to your customers that/ is endorsed by the ISV in question don't you !!p       > H >>>Right as are OS upgrades, we generally don't expect customers to just >>>u? > turn around and upgrade their OS during their lunch break.<<<o >  > Why not? e > I > Reduce overtime costs by doing work like this during regular hours. AllrA > support staff (including vendor staff remotely) is available ifrG > problems. Key here is that end users do not even know the OS is being 3 > upgraded, so why not do the upgrade during lunch?o >     / Really so do you have actual examples of this ?      Regardsy   Andrew Harrisonu   ------------------------------  # Date: Tue, 09 Jul 2002 11:35:48 GMT # From: "mhr" <mreilly36@comcast.net>oJ Subject: Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!)C Message-ID: <oUzW8.351430$_j6.16654918@bin3.nnrp.aus1.giganews.com>t  J Can you say Intraserver 4280 ? Remember, the controller that could boot anK obsolete os (Winnt), a non-existent os (Win2k-server and XP), various Linux I and T64 5.0 (granted, "unsupported") but required a 39-cent rom which wasaJ evidently sewn on with golden thread by monks living in caves in New Hamp.H for VMS? So, of course you were left with the Qlogic boards-you rememberF those "well, we suggest you don't use the external scsi when using theI internal connector, rather buy a second card..."  Surely you were winkingh with this answer.  mhre? "Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in message $ news:agcmo7$qav$1@web1.cup.hp.com... > E > In article <uhffd6cos3vqa4@news.supernews.com>, "Island (hpaq.net)"  <dbturner@islandco.com> writes:bJ > :I can guarantee you that HPAQ will do something to the main logic board andpF > :patent/copyright every circuit and firmware on it to prevent others gettinge: > :a share of the profitable VMS hardware/licensing market >aE >   The following assumes compliance with the applicable national andtB >   international intellectual property and copyright regulations,E >   laws, conventions, etc.  If you do choose to clone and/or to copy I >   (or even to export or sometimes import certain) hardware or software, G >   you will need the appropriate authorizations and/or licenses and/ort >   permissions. >nG >   OpenVMS Engineering has historically implemented nothing that wouldsH >   explicitly prevent OpenVMS from bootstrapping on third-party VAX andI >   third-party Alpha platforms, and OpenVMS Engineering has specificallysE >   provided mechanisms to add platform support for new and otherwiselI >   unrecognized Alpha platforms via the (documented) SHIP kit mechanism.d >SG >   I know of folks running (licensed copies of) OpenVMS on third-partydE >   Alpha boxes and on third-party VAX boxes -- there were folks thatCH >   were building ruggedized VAX boxes for special applications for manyD >   years, and ruggedized third-party Alpha boxes have been shown atD >   various customer events), and we went as far as extending formalD >   product support to the Tadpole Alpha boxes.  (There were OpenVMSG >   license part numbers that these folks could order.)  More recently, G >   we have worked with SRI to provide a VAX emulator package, allowingaF >   OpenVMS VAX to bootstrap and operate on various HP and third-party >   platforms. >sG >   In keeping with this tradition, OpenVMS Engineering has no plans to G >   implement (technical) restrictions preventing the use of OpenVMS on C >   third-party IA-64 platforms.  Of course, issues around customeruE >   requirements and customer expectations for the testing of and the-C >   support of the platforms can and will exist, as OpenVMS will be G >   tested only on specific HP IA-64 platforms and (potentially) tested F >   for specific customer situations and configurations.  (And has hasF >   been the case with VAX and Alpha third-party platforms, all issuesI >   around adapter and platform support are left to the integrator and/ormI >   platform vendor.)  These (tested) platforms will comprise the list ofv= >   platforms supported by HP OpenVMS Engineering, of course.  > L > :Quite easy really - just find a reliable obsure SCSI controller and stuffK > :some VERY proprietary firmware on it - then stuff it on the motherboard.qK > :Just like the KZPCA Ultra LVD controller - use a generic and VMS dumps a " > :coupl eof minutes into loading. > J >   No two SCSI controllers are ever alike, as anyone that has ever workedJ >   with this stuff can attest.  (If you got as far as a couple of minutesF >   into the OpenVMS bootstrap, that's actually fairly impressive.  WeG >   recently found a case were a SCSI disk's state machine visited "thenF >   weeds" simply because we had not read the SCSI check as the disk'sF >   state machine had expected.  The state machine ignored all inboundI >   SCSI packets until the check condition was completed, and became, um,pC >   catatonic.)  As an old computer joke states, "compatible" meansiG >   "different" -- if the devices were actually "identical", well, they , >   would not have been called "compatible". >OL >   As I have repeatedly stated here in the newsgroups, testing does provide5 >   direct customer value.  And testing is not cheap.g >sH >   As for generics, these are tested with the platforms that the vendorJ >   expects the device to be used with.  We have found any number of theseK >   that don't actually work.  Some USB testing I was involved with severalbH >   weeks back found that a brand-new "USB" camera was violating the USBK >   specifications, and worked on its target platforms (apparently) by luck F >   or (possibly) by a host-based "increase in tolerance for standards" >   variations".  But I digress... >iK >   These are not third-party lock-outs, these are the usual joys of deviceyH >   support.  (And folks wonder why adding and testing and releasing new3 >   platform or new adapter support takes a while?)J >2 > ( >  ---------------------------- #include' <rtfaq.h> -----------------------------pL >       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com, >  --------------------------- pure personal# opinion ---------------------------A1 >    Hoff (Stephen) Hoffman   OpenVMS Engineeringr hoffman#xdelta.zko.dec.com >n   ------------------------------   Date: 9 Jul 2002 05:53:08 -0700a) From: P.Young@unsw.EDU.AU (Patrick Young)oJ Subject: Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!)= Message-ID: <55f85d77.0207090453.14a37996@posting.google.com>   d hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) wrote in message news:<agcmo7$qav$1@web1.cup.hp.com>...  H >   In keeping with this tradition, OpenVMS Engineering has no plans to H >   implement (technical) restrictions preventing the use of OpenVMS on D >   third-party IA-64 platforms.  Of course, issues around customer   D Or devices. Dave, you thinking of Intraserver who ship their driversF with OpenVMS and *do* have this attitude, "ROM checksum failure" comes to mind? :-)  @ I agree strongly with Hoff's posting - The OpenVMS folks go *outG of their way* to make many widgets work. I've tried a number of widgetsgH and found some that do work in my travels - some of which I've tried forK home use and found fit for production - not that you should expect support,a- but quite rightly so - as per the disclaimer.:  D OpenVMS unlike Intraserver will let the driver swim or sink with theF widget you wish to try - if you *tell* OpenVMS to use that driver. TheD driver will try and if it won't work die - and give you some clue as? to why - the way it should be - not display a "license banner".i  / I'm not sure what the question/problem is here.:   Go OpenVMS engineering!!   ------------------------------  % Date: Tue, 09 Jul 2002 09:30:13 -0400l! From: Jim Agnew <jpagnew@vcu.edu>e Subject: Re: Pascal Editor' Message-ID: <3D2AE565.E9BEE946@vcu.edu>m  A This EDT is freeware, but no longer supported...  "works for me" n   Jim Agnew wrote: > H > Are you looking for EDT to run on a Pc?  do a www.google.com search on > SEDT, or anker sonneI > (not sure about spelling of last name) he has an sedt page for windows,i > dos, linux, etc. > J > the dos sedt runs ok under all windows platforms, including XP, but it's > a little flakier under xp..l >  > jimx >  > Shiva MahaDeva wrote:  > >rD > > Which Editor can I use im my PC to open Vax Pascal files exactlyB > > how I see these files using Edit/EDT files in the VMS system ?D > > Id like transfer VAX Pascal files from the VMS system to my PC,0 > > and vice versa, keeping the Edit/EDT format.   ------------------------------  / Date: Tue, 09 Jul 2002 12:40:45 +0200 (MET_DST)c From: system@msia02.msi.se2 Subject: Problems to load OpenVMS V7.3 on DEC 4610* Message-ID: <02070912404572@msia02.msi.se>  7 I have a DEC 4610 onto which I want to load OpenVMS 7.3I! VMS PALcode V.56A  Console V4.0-1h   When I try to boot the CD I getu  5     OpenVMS (TM) Alpha Operating System, Version V7.3     and after a while messages like:    % Failed to send Read to dke400.4.0.4.0 G %SYSBOOT-F-LDFAIL,unable to load SYS$BASE_IMAGE.EXE,  status = 00000054e   or  % Failed to send Read to dke400.4.0.4.0nA %EXECINIT-F-LOADERR, error loading SYS$NTA.EXE, status = 00000054     ! and after that the CPU is halted.   $ If I instead try V7.2-1 it works ok.= I have used the V7.3 CD on other systems without any problem.    Carl Gunnar Lindin   ------------------------------  # Date: Tue, 09 Jul 2002 11:24:08 GMTl$ From: "labadie" <labadie_g@decus.fr>6 Subject: Re: Problems to load OpenVMS V7.3 on DEC 46102 Message-ID: <sJzW8.11$rS5.247903@news.cpqcorp.net>  L <system@msia02.msi.se> wrote in message news:02070912404572@msia02.msi.se... > 9 > I have a DEC 4610 onto which I want to load OpenVMS 7.3l# > VMS PALcode V.56A  Console V4.0-1  >h! > When I try to boot the CD I gets >e7 >     OpenVMS (TM) Alpha Operating System, Version V7.3r >u" > and after a while messages like: >  >a' > Failed to send Read to dke400.4.0.4.0 I > %SYSBOOT-F-LDFAIL,unable to load SYS$BASE_IMAGE.EXE,  status = 00000054i Hellon   exit %X54 gives ) %system-f-ctrlerr, fatal controller errorn  $ This seems to be a hardware problem.   Regardsc   Grard   ------------------------------  % Date: Tue, 09 Jul 2002 12:39:00 +0100 ( From: Nic Clews <sendspamhere@127.0.0.1>6 Subject: Re: Problems to load OpenVMS V7.3 on DEC 4610) Message-ID: <3D2ACB54.37D7D35B@127.0.0.1>t   system@msia02.msi.se wrote:  > 9 > I have a DEC 4610 onto which I want to load OpenVMS 7.3 # > VMS PALcode V.56A  Console V4.0-1    I can't see a "4610" in:  7 http://www.openvms.compaq.com/openvms/supportchart.htmlu  G Please refine. If you mean a DEC 4000 Model 600 then this should be OK.d  r! > When I try to boot the CD I geta > 7 >     OpenVMS (TM) Alpha Operating System, Version V7.3n > " > and after a while messages like: > ' > Failed to send Read to dke400.4.0.4.0nI > %SYSBOOT-F-LDFAIL,unable to load SYS$BASE_IMAGE.EXE,  status = 00000054c  F Another respondent has identified what the error status translates to.G Perhaps there is a problem with the controller being supported. Perhaps G there is no CPU specific image for your system, but you get a different C error IIRC (but equally cryptic). I won't rule this out as we don'tr# definitively know what your CPU is.   v > or > ' > Failed to send Read to dke400.4.0.4.0eC > %EXECINIT-F-LOADERR, error loading SYS$NTA.EXE, status = 00000054t  > I'm tending towards the fact that there is a problem with yourH controller and the version of VMS. If you boot up the 7.2, in SDA a CLUEA CONFIG will tell you controller revisions, check with the SPD fora. supported configurations (firmware revisions).   See the thread titled:    e?         Re: OpenVMS on third-party platforms (was: Re: VMS portr	 delayed!)   G Hoff puts in a definition of "compatible" that I believe is worthy of awE dictionary entry. It will give you a feel for the issues you could bem seeing.t   # > and after that the CPU is halted.l > & > If I instead try V7.2-1 it works ok.   --  ? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Scienceso nclews at csc dot come   ------------------------------   Date: 9 Jul 2002 00:39 CDT' From: carl@gerg.tamu.edu (Carl Perkins)s) Subject: Re: SET FILE/TRUNCATE equivalent-, Message-ID: <9JUL200200395593@gerg.tamu.edu>  D "Antony Wardle" <antony.wardle@nospammmmm.optusnet.com.au> writes...* }let me know if you find out how to do it. } / }I have a file that is a 2.2 million lines longg( }and I only want the first 11 characters" }from each line, I will have to do% }this every few days, so I guess that % }dcl is out for me, and I don't speakh }programming languages ;-( }  }ant  ) Of course you can do it in DCL. Try this:i   $ create first11.sortspecs$ /field=(name=textdata,pos:1,size:11) /key=1 /data=textdataK $ sort/spec=first11.sortspec/stable really_big_file.txt smaller_output.txt    B Tada. Well, technically it isn't exactly all in DCL - it also uses% the sort specification file langauge.   > You only need to create the sort specification file once, then= reuse it every time. The miracle of the nonsorting sort - ther? key is a constant, so the /STABLE on the command line makes thea@ records all appear in the output in the same order they appeared
 in the input.   = Of course this has nothing to do with SET FILE/TRUNCATE. ThatlB deallocates allocated but unused clusters off the end of the file. It doesn't touch the data.   --- Carl   ------------------------------   Date: 9 Jul 2002 11:49:30 +0200t+ From: huber@vms.mppmu.mpg.de (Joseph Huber)i) Subject: Re: SET FILE/TRUNCATE equivalento+ Message-ID: <RQVl+K7iF7O+@vms.mppmu.mpg.de>o  z In article <7f15589f.0207081101.3279f2f2@posting.google.com>, craig.berry@SignalTreeSolutions.com (Craig A. Berry) writes:t > "John.Malmberg" <Malmberg@dskwld.zko.dec.compaq> wrote in message news:<3D299FD9.3040706@dskwld.zko.dec.compaq>... >> Antony Wardle wrote:t >> gH >>  > I have a file that is a 2.2 million lines long and I only want theJ >>  > first 11 characters from each line, I will have to do this every fewL >>  > days, so I guess that dcl is out for me, and I don't speak programming >>  > languages ;-(u >> e: >> Please see the documentation on the SORT/MERGE utility. >>  = >> That task should be easily done with a small specificatione >> file. > ) > Or a really, really small Perl program:r > @ > $ perl -lne "print substr $_, 0, 11;" infile.dat > outfile.dat  & Also a one-liner (cut is part of GNV):  " $ pipe cut -b -11 in.dat > out.dat   ------------------------------  $ Date: Tue, 9 Jul 2002 12:26:24 -0400- From: "Peter Weaver" <peter.weaver@stelco.ca>d) Subject: Re: SET FILE/TRUNCATE equivalenti5 Message-ID: <agf2rm$l2ce3$1@ID-141708.news.dfncis.de>a  4 "Carl Perkins" <carl@gerg.tamu.edu> wrote in message& news:9JUL200200395593@gerg.tamu.edu... >...? > Of course this has nothing to do with SET FILE/TRUNCATE. ThatgD > deallocates allocated but unused clusters off the end of the file. > It doesn't touch the data. >...  K I posted the same solution yesterday and after I thought that I should havelH changed the subject since using SORT or MERGE has nothing to do with SETJ FILE/TRUNCATE. But then I noticed that we are talking about over 2 millionI records being cut down from some number to 11 bytes. So with our solution F you will get an output file with a size of something like 45000/150000I blocks. Then you will need the SET FILE/TRUNCATE! Or make sure you changel the command to;e  7 $ sort/spec=first11.sortspec/stable really_big_file.txt 9 smaller_output.txt/ALLOCATION=45000 ! Using Carl's syntax  orI $ merge infile.txt outfile.txt/ALLOCATION=45000/spec=sys$input:/nocheck !o Using the syntax I posted " field=(name=first11,pos:1,size:11)
 /data=first11    -- Peter WeaverL Opinions are my own, and do not reflect the opinions of my employer, nor theK company that it sub-contracts to, nor the company that it sub-contracts to.t   ------------------------------  % Date: Tue, 09 Jul 2002 09:54:31 +0200e9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> ' Subject: Re: SMTP 8bit hack not workingn' Message-ID: <3D2A96B7.F0A73ACC@aaa.com>S    About "wiring" and telegraphy...  ? During the goldrush in Alaska, most people going for gold whentfH by boat to a small port at the coast of Alaska, can' remember it's name.  C In the town, there was a telagraph company with a large sign sayinga  7 "Last change to wire your family !! 1 USD per telegram"u  H Lots of people whent in, wrote down there message, payed 1 USD and whent on to the gold fields.  E The trouble was that the actual wires that whent out of the building,  justD lasted a few hundred meters into the woods. There was nothing at the other  end...   Jan-Erik Sderholm   "David J. Dachtera" wrote: > C > > In the 1880's "wiring" someone was equivalent to today's email.y >h   ------------------------------  # Date: Tue, 09 Jul 2002 09:05:44 GMT-L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")' Subject: Re: SMTP 8bit hack not workinge8 Message-ID: <00A10A75.9922947A@SSRL04.SLAC.STANFORD.EDU>  c In article <3D2A96B7.F0A73ACC@aaa.com>, Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> writes:?! >About "wiring" and telegraphy...d >o@ >During the goldrush in Alaska, most people going for gold whentI >by boat to a small port at the coast of Alaska, can' remember it's name.n  J Skagway, probably.  (That's the port from which you could start walking toI the Yukon, where the gold was, and it's where they built the railroad.)  -   >eD >In the town, there was a telagraph company with a large sign saying >g8 >"Last change to wire your family !! 1 USD per telegram" >yI >Lots of people whent in, wrote down there message, payed 1 USD and whenta >on to the gold fields.  >sF >The trouble was that the actual wires that whent out of the building, >justwE >lasted a few hundred meters into the woods. There was nothing at theb >other >end...t  J Funny, they didn't tell _that_ story on the tour I took.  (But, as before,O the economy of the town is 100% dependent on people passing through - tourists,o though, not miners.)   -- Alane  O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056aM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210 O ===============================================================================o   ------------------------------  % Date: Tue, 09 Jul 2002 12:04:54 +0200t9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> ' Subject: Re: SMTP 8bit hack not working ' Message-ID: <3D2AB546.EA1A34AE@aaa.com>E  A Well, actualy, I read the story in a swedish photo magazine in an 
 article about H a Swedish photographer who took most of the pictures left today from theE Skayway area from the goldrush days. I remember it as beeing a "true"O
 story, but it's a *good* story anyway.n   Jan-Erik Sderholm.   * Alan Winston - SSRL Admin Cmptg Mgr wrote: >  > L > Skagway, probably.  (That's the port from which you could start walking toI > the Yukon, where the gold was, and it's where they built the railroad.)  > L > Funny, they didn't tell _that_ story on the tour I took.  (But, as before,Q > the economy of the town is 100% dependent on people passing through - tourists,r > though, not miners.) >o   ------------------------------  $ Date: Tue, 9 Jul 2002 13:55:25 +0530# From: "Vivek Soni" <visoni@bmc.com>  Subject: TOKENS CASELESS/ Message-ID: <uil7c7mf69df46@corp.supernews.com>   , In the .scn files I have the following entry   filename: PARSE.SCNt  SET hyp_or_und     ('-' OR '_');     filename: PARSE_TOKENS.SCN8 TOKEN T_disk_label CASELESS {'disk' hyp_or_und 'label'};  < Also what would 'disk' & 'label' here in tokens refer to....  * Will it be default set to string???  or...   Thanks in Advance  Viveko   ------------------------------   Date: 9 Jul 2002 05:27:08 -0600 - From: Kilgallen@SpamCop.net (Larry Kilgallen).( Subject: Re: TOKENS CASELESS  (VAX Scan)3 Message-ID: <BY0pfzjffkbB@eisner.encompasserve.org>u  U In article <uil7c7mf69df46@corp.supernews.com>, "Vivek Soni" <visoni@bmc.com> writes: . > In the .scn files I have the following entry >  > filename: PARSE.SCNe" > SET hyp_or_und     ('-' OR '_'); >  >  > filename: PARSE_TOKENS.SCN: > TOKEN T_disk_label CASELESS {'disk' hyp_or_und 'label'}; > > > Also what would 'disk' & 'label' here in tokens refer to.... > , > Will it be default set to string???  or...  B You should not attempt this until you have read and understood theB VAX Scan manual.  I presume that is on the Freeware along with the	 compiler.i   ------------------------------  $ Date: Tue, 9 Jul 2002 16:20:16 +0530# From: "Vivek Soni" <visoni@bmc.com>t( Subject: Re: TOKENS CASELESS  (VAX Scan). Message-ID: <uilfrrk9vp109@corp.supernews.com>  2 Do we have this manual available on the net....???    8 Larry Kilgallen <Kilgallen@SpamCop.net> wrote in message- news:BY0pfzjffkbB@eisner.encompasserve.org...C> > In article <uil7c7mf69df46@corp.supernews.com>, "Vivek Soni" <visoni@bmc.com> writes:0 > > In the .scn files I have the following entry > >d > > filename: PARSE.SCNe$ > > SET hyp_or_und     ('-' OR '_'); > >  > >l > > filename: PARSE_TOKENS.SCN< > > TOKEN T_disk_label CASELESS {'disk' hyp_or_und 'label'}; > >e@ > > Also what would 'disk' & 'label' here in tokens refer to.... > >p. > > Will it be default set to string???  or... >tD > You should not attempt this until you have read and understood theD > VAX Scan manual.  I presume that is on the Freeware along with the > compiler.    ------------------------------   Date: 9 Jul 2002 06:15:29 -0600U- From: Kilgallen@SpamCop.net (Larry Kilgallen)t( Subject: Re: TOKENS CASELESS  (VAX Scan)3 Message-ID: <wTIczFD21K39@eisner.encompasserve.org>e  T In article <uilfrrk9vp109@corp.supernews.com>, "Vivek Soni" <visoni@bmc.com> writes:4 > Do we have this manual available on the net....??? >  > : > Larry Kilgallen <Kilgallen@SpamCop.net> wrote in message/ > news:BY0pfzjffkbB@eisner.encompasserve.org... ? >> In article <uil7c7mf69df46@corp.supernews.com>, "Vivek Soni"  > <visoni@bmc.com> writes:1 >> > In the .scn files I have the following entrya >> > >> > filename: PARSE.SCN% >> > SET hyp_or_und     ('-' OR '_');- >> > >> > >> > filename: PARSE_TOKENS.SCN-= >> > TOKEN T_disk_label CASELESS {'disk' hyp_or_und 'label'};n >> >A >> > Also what would 'disk' & 'label' here in tokens refer to....a >> >/ >> > Will it be default set to string???  or...A >>E >> You should not attempt this until you have read and understood the E >> VAX Scan manual.  I presume that is on the Freeware along with theo >> compiler.  8 1. Please never send me email copies of newsgroup posts.  F 2. I have been doing VMS long enough that I have a complete collectionD    of Freeware discs, so I always look there.  (In the case of SCAN,D    however, I was using it as a paid product before it was Freeware,    so I use those manuals.)   F 3. BMC has been doing VMS long enough that _they_ must have a complete     collection of Freeware discs.  G 4. Others have said the Freeware disc contents are available on the VMSe    Development web site.   ------------------------------  % Date: Tue, 09 Jul 2002 13:50:21 +0200I9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com> ( Subject: Re: TOKENS CASELESS  (VAX Scan)' Message-ID: <3D2ACDFD.1D9C8424@aaa.com>    Check :y  : http://www.openvms.compaq.com/freeware/freeware40/vaxscan/   Jan-Erik Sderholm.   ; In article <uilfrrk9vp109@corp.supernews.com>, "Vivek Soni"i <visoni@bmc.com> writes:4 > Do we have this manual available on the net....???   ------------------------------   Date: 9 Jul 2002 06:34:56 GMT-) From: bill.stivers@sun.com (Bill Stivers)n( Subject: VS4000VLC hardware information./ Message-ID: <age06g$9ar$2@engnews1.eng.sun.com>!  M Do there exist any good sites or archives for divining how which serial portsmJ when, and how to get around using a video console?  I've got 6 of the sonsP of guns, but unfortunately my experience with newer vaxen like these is somewhatQ limited.  Am I missing something I'm going to kick myself for?  Thanks in advance : for any help, and many, -many- apologies for my ignorance.   ------------------------------  % Date: Tue, 09 Jul 2002 09:48:32 +0100l( From: Nic Clews <sendspamhere@127.0.0.1>, Subject: Re: VS4000VLC hardware information.) Message-ID: <3D2AA360.63F81FEE@127.0.0.1>i   Bill Stivers wrote:a > O > Do there exist any good sites or archives for divining how which serial ports L > when, and how to get around using a video console?  I've got 6 of the sonsR > of guns, but unfortunately my experience with newer vaxen like these is somewhatS > limited.  Am I missing something I'm going to kick myself for?  Thanks in advance1< > for any help, and many, -many- apologies for my ignorance.  3 This is a good source for older information (specs)   H http://www.compaq.com/products/quickspecs/soc_archives/SOC_Archives.html  & (Didn't see the 4000VLC listed though)  E Then there is the Golden Eggs which *may* have details that you need.eG Alternatively someone else here may provide a pointer to the electronicl& version of the hardware documentation.  D In summary, the VLC is a low powered VAX, it is a full VAX, but onlyE space for a single hard drive. You can put a large enough one to holdrH VMS (IME 245 MB / RZ24L) but RZ25L is preferable. Alternatively, you canH network boot them into a cluster using the local disk for page and swap.G In the performance stakes, not too hot I'm afraid by today's standards,-, equivalent in raw CPU to a 4000-200 (5 VUP).  E I'd hardly call them new, and I'd be tempted to consider even some of F the second generation 3100 (-30,40,48 ...) as better as there are more options for expansion.  F GOlden eggs (visual configurations) *may* include this model (I've not checked)  ' http://www.compaq.com/info/golden-eggs/   - Good reference is here (as the name suggests)    http://vaxarchive.org/  H Didn't find a direct reference to the VLC, but you need minimum 5.5 VMS.  E One other point, the switch S3 determines video or serial console, UP.H usually means SERIAL, DOWN usually means graphical, I remember the orderF as the graphics is usually "on-board" (sic), and the switch is in that general direction.  H More questions, ask here, I'm sure someone will know. Hope this helps... -- -? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciencess nclews at csc dot com    ------------------------------  $ Date: Tue, 9 Jul 2002 08:26:39 -0400* From: WILLIAM WEBB <WWEBB1@email.usps.gov>, Subject: RE: VS4000VLC hardware information.- Message-ID: <0033000071718726000002L062*@MHS>.  ( =0A     See my indented responses below.        WWWebbw   -----Original Message-----/ From: Info-VAX-Request@Mvb.Saic.Com at INTERNETa$ Sent: Tuesday, July 09, 2002 2:54 AMB To: Webb, William W Raleigh, NC; Info-VAX@Mvb.Saic.Com at INTERNET( Subject: VS4000VLC hardware information.    H Do there exist any good sites or archives for divining how which serial=  ports when,O  @      I'm afraid that I don't understand what you're asking here-  , and how to get around using a video console?  B      Are you asking about how to set them up with a serial consoleA      instead of a graphics console?  That's understandable, sinceuF      most of the graphics options (not to mention the cables involved)      were somewhat arcane.  H I've got 6 of the sons of guns, but unfortunately my experience with ne=	 wer vaxen0 like these is somewhat limited.,  H      This is the first time I've seen *newer* and VLC in the same sente= nce.,      I've got a VLC manual around somewhere.  B      First of all, post a list of model numbers so we can tell youB      what the systems came with when they were purchased.  It will-      help a lot in determining what you need.   4 Am I missing something I'm going to kick myself for?  H      Well, they're memory-limited (24MB max), some models suffer from t= heH      ~=3D1GB system disk limitation [see the FAQ if you don't know abou= tfH      this], and they're pretty darn slow by today's     standards.  Oth= er thanl<      that, they were pretty nifty little boxes in their day.  H Thanks in advance for any help, and many, -many- apologies for my ignor= ance.=   ------------------------------  $ Date: Tue, 9 Jul 2002 10:03:04 -04005 From: "Sue Skonetski" <susan.skonetski@hp.nospam.com>N% Subject: WRQ #2 in Web-to-host market0* Message-ID: <ageqef$iju$1@web1.cup.hp.com>  	 Hi Susan,n   Thanks for your quick reply.  K Yes, we do have a seperate section that lists our offerings on OpenVMS. You2 can access it using this linko  > http://www.wrq.com//products/reflection/host_type/openvms.html  8 The press release on the IDC report can be accessed here4 http://www.wrq.com/aboutwrq/news/2002/061702cpr.html  
 Best regards,s   Roger    -----Original Message-----  6 From: Skonetski, Susan [mailto:Susan.Skonetski@hp.com]  ) Subject: RE: WRQ #2 in Web-to-host markets   Dear Roger,a  J Is there a WRQ web site that talks about VMS, I would like to add it prior0 to sending this message to a broad distribution?  
 Thank you,   Sueu   -----Original Message-----  1 From: Roger Raemaekers [mailto:RogerR@eu.wrq.com]e  # Sent: Monday, July 08, 2002 5:42 AMs  * Subject: FYI: WRQ #2 in Web-to-host market      E WRQ CAPTURES #2 RANKING IN WEB-TO-HOST MARKET ACCORDING TO IDC REPORTo  I SEATTLE, June 17, 2002 - In the recent IDC Worldwide Host Access SoftwareEL Market Forecast and Analysis, 2001-2006, WRQ, Inc. was named as the number 2K vendor for Web-to-host, according to worldwide revenue market share. WRQ, a-L 21-year veteran in host integration and access, overtakes competitors and is< now second to IBM on this leading Web-to-host provider list.  F IDC's yearly report for this market sizes and segments the host accessJ software opportunity and forecasts the five-year outlook. Data procurementJ is conducted via surveys and discussions with vendors. IDC splits the hostJ access market into traditional and Web-to-host segments, and considers howK each of these performs across four geographic areas: North America, Europe,lK Asia Pacific, and Rest of World. Vendor market share is ranked by shipmentseH for the traditional segment, and by revenue for the Web-to-host segment.  I The new IDC ranking adds to a growing record of milestones for WRQ in thetL Web-to-host segment, including significant license growth of WRQ ReflectionG for the Web in 2001 and the June release of version 5.0, also announced  today.  G "By growing its customer base through competitive displacement, WRQ haslD ascended to second place in terms of market share for Web-to-host inJ 2001,"said Max Flisi, Associate Analyst for Datacenter Networks at IDC. HeL adds,"This achievement is all-the-more noteworthy at a time when competitionJ is intense and when some vendors exhibited flat or negative growth in thisI space. WRQ should continue in this vein by focusing on ease of management.J and security within its products, and by working closely with its existingL customer base - breeding loyalty with current customers is what will prevent defection to competitors."  G "We are proud of this accomplishment, not only because it validates ourdK success in this segment, but because it motivates us to continue to deliverSJ the best host access solutions for our customers and the enterprise sectorK overall," said Randy Robinson, vice president and manager of the Reflection  Business Unit at WRQ.t  L WRQ Products Supported by quality consulting services and technical support,C WRQ Reflection and WRQ Verastream(tm) transform IT obstacles intooK opportunities. Reflection solutions are designed to simplify and reduce theCI costs of accessing applications and data on host systems. These solutionsCK offer important added value by allowing businesses to take advantage of newm@ technologies for increased security, broader access and improvedK administration. Building on WRQ's expertise in host-intensive environments,pI Verastream solutions are designed to help customers integrate vital data, 7 applications, and business logic across the enterprise.0  	 About WRQe  A WRQ provides integration software and services for host-intensive:G environments. For 21 years, we've been helping our customers access andSK integrate information to transform the way they do business. With more thaneK 26,000 customers representing over six million users, we are one of the topaJ software companies in the U.S. Our award-winning Reflection and VerastreamE products are sold in 51 countries. For more information, please visite! www.wrq.com <http://www.wrq.com>.w   Roger Raemaekers  % European Business Development Managerd   WRQ Software, Europe   T. +31 (0)30 229 5489    M. +31 (0)653 239393   rogerr@wrq.com  G We specialize in integration software and services that let you quickly   A adapt your host-intensive environment to meet new business needs.n   ------------------------------  $ Date: Tue, 9 Jul 2002 12:03:16 -0400# From: "Island" <sales@islandco.com>u- Subject: XP1000 667Mhz USD2995 !!!!! IncomingL/ Message-ID: <uim1jd5ddshc5a@news.supernews.com>p  " Order now - only 30 coming in !!!!     Configured as follows:   XP1000 667Mhz 4MB CacheC
 1GB Memory 18GB Disk Drive< CDROM7% 3DLabs VX1 Oxygen 32MB PCI Video Card- Floppy Keyboard Mousea   Only $2995* E (*FYI - the cpu daughter card - dealer to dealer price is over $3000)     , Add a new Viewsonic E70 17" Monitor for $230 (Not flatpanel)o     -- David B Turner	 Sales Dpta Island Computers US Corporation' 2700 Gregory Street 	 Suite 180t Savannah GA 31404  Tel: 912 447 6622l Fax: 912 201 0096r sales@islandco.com www.islandco.com' http://www.islandco.com/legal-email.htmn   We sell Alpha's !a* All emails are checked for Virus and Worms   ------------------------------   End of INFO-VAX 2002.375 ************************