1 INFO-VAX	Fri, 02 Jul 2004	Volume 2004 : Issue 362       Contents: Re: A lint Utility for OpenVMS Re: A lint Utility for OpenVMSP Re: Announcing - The June 2004  issue of  The OpenVMS Technical Journal  - PleasP Re: Announcing - The June 2004  issue of  The OpenVMS Technical Journal - Please Re: DECC /VAXC Compiler  Re: DECC /VAXC Compiler  Re: DECC /VAXC Compiler  Re: DECC /VAXC Compiler  Re: DECC /VAXC Compiler  Re: DECC /VAXC Compiler * Re: FTP client to understand ODS-5 volumes= Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article = Re: Intel Itanium's very survival in doubt - inquirer article * Re: Memory test diags for Alphastation 255+ Re: More LAT questions on LAT$SYSTARTUP.COM  Re: OpenVMS .... no news? ' OT: Industrial Espionnage/data security  Re: Secondary DNS problem ' Re: slap in the face again... thanks HP ' Re: slap in the face again... thanks HP 1 Re: When to use INIT/WINDOWS, SET VOLUME /WINDOWS 1 Re: When to use INIT/WINDOWS, SET VOLUME /WINDOWS 1 Re: When to use INIT/WINDOWS, SET VOLUME /WINDOWS   F ----------------------------------------------------------------------  # Date: Thu, 01 Jul 2004 18:43:46 GMT 5 From: "Ed Vogel" <edward.vogel_stop_the_spam.@hp.com> ' Subject: Re: A lint Utility for OpenVMS 1 Message-ID: <CXYEc.5192$z43.935@news.cpqcorp.net>   9 "Keith A. Lewis" <lewis@PROBE.mitre.org> wrote in message ( news:cc12cq$k84$1@newslocal.mitre.org... > I > Nobody "needs" lint.  As others have pointed out, DEC C has some pretty  goodL > checks built into the compiler.  They get "better" with every release.  SoJ > much so that upgrading C and C++ compilers has become more work than our+ > reduced VMS programming staff can handle.  > ? Interesting...this is one of the very few complaints I've heard : about the additional diagnostics the compiler will output.B Are there certain diagnostics that you think should not be output? We do value any feedback.   : Also, it should be simple to just disable any new messages9 you don't want to see.  They should not present difficult ; compiler upgrade problem.  On the other hand, maybe there's  something we don't understand.   Ed Vogel HP C Engineering.    ------------------------------  % Date: Thu, 01 Jul 2004 21:24:07 -0500 2 From: David J Dachtera <djesys.nospam@comcast.net>' Subject: Re: A lint Utility for OpenVMS + Message-ID: <40E4C747.779609C7@comcast.net>    Colin Butcher wrote: > I > Now that we have C# (C sharp) as well as C++ I guess we'd be better off  > describing C as "C blunt"?  D I was going to say, "C Natural", but there's precious little that is even REMOTELY natural about C!  / > I certainly find a blunt instrument handy for / > dealing with ill-disciplined C programmers...    ...and stealth-marketers...    D.J.D.   ------------------------------   Date: 1 Jul 2004 11:52:02 -0700 1 From: susan_skonetski@hotmail.com (Sue Skonetski) Y Subject: Re: Announcing - The June 2004  issue of  The OpenVMS Technical Journal  - Pleas < Message-ID: <857e9e41.0407011052.96ef9bd@posting.google.com>  ! Folks let me know what you think.    thanks,    Sue    ------------------------------  $ Date: Thu, 1 Jul 2004 18:35:10 -0400# From: "John Smith" <a@nonymous.com> Y Subject: Re: Announcing - The June 2004  issue of  The OpenVMS Technical Journal - Please , Message-ID: <UtqdnYMRW-UCDHndRVn-sA@igs.net>   Sue Skonetski wrote:
 > Dear Folks,  > F > It is my pleasure to announce the availability of the newest copy ofG > the OpenVMS Technical Journal.  This issue is 180 pages in length and > > contains 11 different articles written by technical experts. > G > All articles are available in PDF and HTML and combined documents are  > available in both PDF and PS.  > F > As with any project this is the result of many hours of hard work byF > both the Authors, Writing and Web team, my deepest thanks for making > this happen. > G > Please visit http://h71000.www7.hp.com/openvms/journal for the latest  > VTJ  >  > Warm Regards,  > Sue      Another great effort - thanks.  H I found the "HP OpenVMS Clusters and IBM MQSeries Failover Sets" article# most interesting and timely for us.    ------------------------------  % Date: Thu, 01 Jul 2004 12:12:25 -0700  From: Z <z@no.spam>   Subject: Re: DECC /VAXC Compiler0 Message-ID: <10e8og05u41sia4@corp.supernews.com>   Ed Vogel wrote:   M > "Z" <z@no.spam> wrote in message news:10e757f68jt6u54@corp.supernews.com...  > > >>Which can make badly written code break in rather mysterious? >>ways, like having -1 be greater than 100 in a comparison, for 
 >>example. >>( >>And /STANDARD=VAXC doesn't "fix" this. >> > ( >     Would you post an example of this?  :  From memory: the promotion rules for different width/type, data elements in VAX C differed from ANSI C.  < IIRC, the situation was: comparing a signed char (value < 0,; eg: -1) to an unsigned short/int (value > 0, eg: 100) would : "work" on VAX C - the -1 would be less than the 100 but on, DEC C, the -1 would be greater than the 100.  < This wasn't a flaw in DEC C or VAX C, the rules had changed.   ------------------------------  # Date: Thu, 01 Jul 2004 20:03:48 GMT 5 From: "Ed Vogel" <edward.vogel_stop_the_spam.@hp.com>   Subject: Re: DECC /VAXC Compiler1 Message-ID: <E6_Ec.5209$%n3.158@news.cpqcorp.net>   K "Z" <z@no.spam> wrote in message news:10e8og05u41sia4@corp.supernews.com... < >  From memory: the promotion rules for different width/type. > data elements in VAX C differed from ANSI C. > > > IIRC, the situation was: comparing a signed char (value < 0,= > eg: -1) to an unsigned short/int (value > 0, eg: 100) would < > "work" on VAX C - the -1 would be less than the 100 but on. > DEC C, the -1 would be greater than the 100. > > > This wasn't a flaw in DEC C or VAX C, the rules had changed.   Thank you for the reply.  < I expect you are refering to the difference between what the: standard calls "unsigned preserving" vs "value preserving"  ? It generally requires a situation more complex than the one you : list, but this is a difference between K & R C (VAX C) and standard C.   1 While the initial releases of DEC C did not match 6 the VAX C behavior in this regard when /STAND=VAXC was8 specified.  This was fixed in 1998.  So, when /STAND=VAXD is used, the DEC/Compaq/HP C compiler should use unsigned preserving semantics just as VAX C did.   Ed Vogel HP C Engineering   ------------------------------  # Date: Thu, 01 Jul 2004 20:04:23 GMT   From: nobody <nobody@nobody.org>  Subject: Re: DECC /VAXC Compiler@ Message-ID: <1f0333a7983992af7295d34207ac45ea@news.teranews.com>   a few people wrote:   ? > :Which can make badly written code break in rather mysterious @ > :ways, like having -1 be greater than 100 in a comparison, for > :example.   3 Pardon my ignorance, what exactly is that problem ?    you mean code such as A 	if (-1 > 100) printf("Laws of mathematics have been revoked\n");    ??  > > :A few other common gotchas with DEC C are leaving the VAX C. > :.OPT around and linking with VAXCRTL (bad!)   On VAX 7.2:   L SEARCH/WINDOW=0 SYS$SYSTEM:*.EXE VAXCRTL reveals that the VMS engineers needJ to spend a lot of time updating the build procedures for a lot of programs, that are still being linked against VAXCRTL.    L It may be parity errors in my memory, but I seem to recall finding one imageH that was linked against both VAXCRTL and DECCRTL. (probably some modulesJ compiled with vaxc and some with decc). But I can,t remember which one (or" perhaps they fixed this with 7.2).    D >   There have been extensive changes in newer C run-time libraries,B >   as well -- I hadn't read the manual in some time and was quiteC >   surprised at the number and the scale of the added routines and 
 >   features.   N Correct, when with VAXC, I had to write my own set of missing routines (strdupG comes to mind), and when I moved to DECC, I found myself with plenty of 8 duplicate definitions (but that was easy enough to fix).   ------------------------------  # Date: Thu, 01 Jul 2004 20:20:01 GMT   From: nobody <nobody@nobody.org>  Subject: Re: DECC /VAXC Compiler@ Message-ID: <5925f3d836caef6d53facb13776f6e88@news.teranews.com>   Z wrote:> > IIRC, the situation was: comparing a signed char (value < 0,8 > eg: -1) to an unsigned short/int (value > 0, eg: 100)   M Ahh, OK. Yes, I agree.  But that is why I always use /UNSIGNED when I compile J with DECC. This allows a "char" value to be treated as a full byte. (BeingM french cnandian, this is necessary when you wish to habdle strings containing  accented characters).   U It was absolutely stupid to decide that a "char" should be a signed value by default.    ------------------------------  # Date: Thu, 01 Jul 2004 19:31:21 GMT   From: nobody <nobody@nobody.org>  Subject: Re: DECC /VAXC Compiler@ Message-ID: <2cff9cd1e1824828d5cc083c0cce982e@news.teranews.com>  @ > > Which can make badly written code break in rather mysteriousA > > ways, like having -1 be greater than 100 in a comparison, for  > > example.  E I bitched a lot when I moved from VAXC to DECC since DECC is far more F pedantic, especially with regards to character strings being passed byL reference by default, which causes countless errors in any code that made it9 clear it was being passed by reference by using &string .   N DECC also wants you to prototype all your routines and does argument checking.K However, the /PROTO=IDEN , although undocumented, does exist on VAX. (it is K documented on ALPHAs). This generates a .CH file that contains all function M prototypes for that compilation unit. It needs to be edited to remove some of J the crud, but that is very helpful. And you also need to edit it when, forE instance, inside a compilation unit, you expect a pointer to internal N structure, but from the outside world, you are just passing a opaque value, soJ in the prototype, you need to edit that function's declaration to expect a/ void * instead of structure chocolate_struct *.   K DECC does point to tiny mistakes that you would have never caught and which D eventually get you on some odd situations you had not tested before.  H When I converted to DECC, I bitched and was told that I would eventuallyK appreciate it. Now I am at a point where I would tell someone the same :-)    N DECC forces greater discipline in coding compared to VAXC. Perhaps takes a bitN longer to do simple stuff, but in the end, I really feel that it forces you to* produce more robust code compared to VAXC.   ------------------------------  % Date: Thu, 01 Jul 2004 17:23:31 -0700  From: Z <z@no.spam>   Subject: Re: DECC /VAXC Compiler0 Message-ID: <10e9an7b020l71a@corp.supernews.com>  
 nobody wrote: ? >>:Which can make badly written code break in rather mysterious @ >>:ways, like having -1 be greater than 100 in a comparison, for >>:example.   5 > Pardon my ignorance, what exactly is that problem ?  > you mean code such as C > 	if (-1 > 100) printf("Laws of mathematics have been revoked\n");     $ Something like this was the problem:   ...  char c = -1; unsigned int i = 100; 3     if (c > i) printf("-1 is greater than 100!\n");  ...   > Ed Vogel indicates this was fixed in 1998, if you compile with= /STANDARD=VAXC.  I ran into it in 1995 or 1996 doing a rather " large VAX/VAXC -> Alpha/DECC port.  ( That was a real head scratcher at first!   ------------------------------  # Date: Thu, 01 Jul 2004 23:22:21 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")3 Subject: Re: FTP client to understand ODS-5 volumes 6 Message-ID: <00A34310.0C9C3E7D@SSRL.SLAC.STANFORD.EDU>  l In article <1JUL04.14074949@thuria.waisman.wisc.edu>, karcher@thuria.waisman.wisc.edu (Carl Karcher) writes:K >In a previous article, David J Dachtera <djesys.nospam@comcast.net> wrote:  >.G >->Would that not be more a function of the VMS-side server than of the 
 >->client? > I >You mean like having a switch to tell the server to format the output so H >it looks like unix to the client? Sure that would be great and MultiNetF >has it (TCPIP doesn't). I didn't want to wait for hell to freeze over5 >though so I thought I'd inquire about clients first.  > H >If WS_FTP can handle the output as some have indicated I'd be thrilled.1 >I've tried an old version of WS_FTP that didn't.  >  >Thanks for the responses.  N I'm under the impression that HGFTP can do this (that is, make the output lookO like Unix to the client), although I've never tried it because Multinet FTP has K done everything I've needed so far.  But the HGFTP server can sit on top of 2 TCP/IP Services / UCS and serve FTP URLs and such.  , Don't remember whether it understands ODS-5.   -- Alan    --  O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056 M  Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA   94025 O ===============================================================================    ------------------------------  $ Date: Thu, 1 Jul 2004 13:52:46 -0400* From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article2 Message-ID: <aOadnTWqwp6q0nndRVn-sQ@metrocast.net>  4 "David Svensson" <icerq4a@spray.se> wrote in message7 news:734da31c.0407010414.40dc7918@posting.google.com...    ...   ? > When I watched Intel presentations in 1997/1998 there were no G > sightings that Intel wanted to discontinue x86. IA64 was at that time H > not planned to be a desktop CPU. There may have been hopes before that3 > time that IA64 would dominate the desktop though.   H I've heard multiple people state that around 1994-5 Intel was suggestingC that at least verbally (though does not seem to have committed such K statements to the Web for posterity).  IIRC 2003 was the year they expected ) the change-over to be nearing completion.    > ; > About 8086 inside, "spent so much effort" is not correct.   K While I don't happen to have information about how much effort was involved L in developing the original Merced hardware emulator (which I don't think hasJ since changed), said emulator did - and still does - take up a significantL percentage of the Itanic core area.  Just designing something with that many  transistors takes *some* effort.    They could G > have spent a whole lot more time/money on doing it better, apparently , > they didn't want to or were short of time.  ! <Choke!><Wheeze!><Gulp!><Guffaw!>   L Short of time?  Developing Itanic?  After slipping 3+ years from its initialC target just to ship a non-product like Merced, despite increasingly  Herculean development efforts?  G More likely, they actually believed their early projections that Itanic L would offer 2x - 3x the performance of its RISC contemporaries.  And did notL expect their x86 buddies to accomplish as much in the area of performance as they actually did.  K Let's see:  the Itanic hardware-emulation box seems to achieve around 10% - K 15% of native Itanic performance running x86 code (and in some ways this is K not entirely unworthy of respect when you take Itanic's radically different H approaches to ILP into account:  it has no compiler to help it out here,I which is one reason why the new software emulator can do so much better a I job).  If Itanic *had* actually debuted at 2x - 3x the performance of its G RISC competition, some time in the late '90s (instead of in 2002, since D Merced really turned out not to count as far as a usable product wasJ concerned), its x86 emulation should have been at least acceptable even if4 not necessarily impressive compared with native x86.   >  > > B > > When they realised that IA64 was an uncompetitive architecture
 (cost/time to L > > develop, heat generation, compiler complexity etc), Intel did admit that IA64L > > would not become industry standard (aka: would not replace the 8086). ToH > > anyone without any financial ties to Intel, that was a clear message	 that IA64 J > > had little future and gave much more credibility to all the statements pre @ > > June 25 from Digital Alpha engineers on how flawed IA64 was. > A > I think you are confusing the IA64 architecture and the current E > Itanium implementation. Yes, there have been problems, but the heat ? > generation and being "uncompetitive" are not tied to the IA64  > architecture.   K Could you provide evidence for that last statement?  While any architecture I can be emulated underneath by something rather significantly different in L order to avoid some of its weaknesses (witness x86), those weaknesses remainB tied to the upper architecture - they're just being worked around.  B The IA64 'architecture' seems pretty inextricably tied to the EPICK philosophy of in-order execution.  I haven't yet seen any evidence, real or F theoretical, that this approach can achieve competitive performance onL typical commercial workloads (i.e., those without the regularity of FP-styleC code) without excessive power (and, for that matter, on-chip cache) L requirements when compared with existing OoO architectures (POWERx, Opteron,L Alpha, PA-RISC, and even IA32 - though its power requirements have increasedJ lately - come to mind; I might include SPARC64 as well, but don't know howF much power it requries).  And the fact that both hardware and compilerB development efforts significantly exceeded those of other existingK architectures (if for no other reason than that Itanic was breaking so much J new ground, though I'd suggest in an absolute sense as well) is really not in question.   ...   K > > Companies who have a financial stake in IA64 (HP, INTEL and a couple of H > > others) cannot publicly tell the truth since it would ruin their own companmyJ > > if they admitted that they had made a wrong technological decision and bet the J > > company of a failed architecture. So naturally, you'll continue to see spin. > > from the likes of HP and Intel about IA64. > G > The problem with IA64 has very little do with the architecture or how / > it performs. There is no major problem there.   H Bullshit.  The failure of Itanic to come anywhere near the 2x - 3x hypedG performance advantage is a major problem:  being *much better* than the K competition was its original rationale for existence (and is also usually a I requirement for displacing existing entrenched products).  The failure of H Itanic to provide even competitive performance *today* without excessive& power requirements is a major problem.  L Of course, disappointing performance (which, as noted above, seems to have aL great deal indeed to do with the architecture) isn't the *only* problem withF Itanic.  The failure of Itanic to come anywhere near its promised shipK dates - even after effectively cancelling its first release due to abjectly H unacceptable performance - is a major problem.  The failure of Itanic toK achieve anything like the market penetration it was projected to have (even K after taking all the other delays into account) is a major problem (I think L it was IDC who as recently as 2000 projected a $30 billion market for ItanicK by 2004; their current projection is for a $7.5 billion market by 2007, and L if current projection trends continue even that will prove optimistic).  TheD failure of Itanic to be able to leverage the pricing efficiencies ofK commodity-level volumes is a major problem (Intel is working on that one by E moving toward common chipsets, but whether they'll be used in desktop L environments or just in Xeon servers will determine the degree to which thisG will help - and the processor chips themselves will still be relatively K low-volume products whose rather significant development costs will need to  be recovered).   - bill   ------------------------------  # Date: Thu, 01 Jul 2004 19:35:46 GMT & From: Rick Jones <foo@bar.baz.invalid>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article2 Message-ID: <mIZEc.5203$zi3.1295@news.cpqcorp.net>  ) Bill Todd <billtodd@metrocast.net> wrote: F > Let's see: the Itanic hardware-emulation box seems to achieve around9 > 10% - 15% of native Itanic performance running x86 code   B Always a good idea to be explicit about what that code is doing.    > For example, some rather moldy data on DNS server performance:  	 <excerpt>   $ 		    DNS Server Performance SummaryA      netperf DNS_RR test requesting across 1000 out of cup.hp.com 0                      "A" Transactions Per Second& 		  hp server rx2600, 2x 1GHz Itanium2% 		   Red Hat Advanced Workstation 2.1  			     HP-UX 11.22     2                              Native     Emulated  B        Flavor                 IPF      x86/PA-RISC     % of native3                           +===========+===========+ <      rh bind 8.3.4 O2     |   8,620   |   3,206   |       37<      rh bind 9.2.2 O2     |   6,967   |   1,710   |       25<      rh bind 9.3.0s O2    |   3,695   |   1,637   |       44<      rh bind 9.3.0s O2 st |   4,722   |   2,279   |       48<      rh bind 9.3.0s O2 mr |  33,012   |   9,265   |       283                           +===========+===========+ 3      ux bind 4.9.11 O2    |  14,225   |    n/a    | <      ux bind 8.3.4 O2     |   9,768   |   3,102   |       32<      ux bind 9.3.0s O2 st |   4,880   |   1,489   |       31<      ux bind 9.3.0s O2 mr |  16,797   |   1,301   |       083                           +===========+===========+   B The magic decode for the "Flavor" column is rh == Red Had AdvancedC Workstation 2.1, bind == the named from the specified distribution, > 8.3.4 and 4.9.11 are full releases from the ISC, 9.3.0s is the< December 17th "snapshot" of the 9.3.0 development version of> BIND. "O2" is the compiler optimization level - either -O2 forC gcc/linux or +O2 for HP. A "st" means that the bits were configured F and compiled single-threaded rather than multi-threaded. An "mr" means< that the named.conf file included a "minimum-responses true"C directive, which is a relatively new feature of the BIND named that E minimized the quantity of possibly extraneous information placed into  the DNS reply.  
 </excerpt>  E Interpreting the middle column, if the row is "rh" then the emulation D is x86 (IIRC given the box and the bits, that would be HW emulation)< if the row is ux then the emulation is PA (aries, software).  C One of these days I hope to have a chance to run with newer bits as C the bits there are indeed rather old. I am not sure when that might  be.   
 rick jones --  . a wide gulf separates "what if" from "if only"F these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...    ------------------------------  # Date: Thu, 01 Jul 2004 20:12:10 GMT   From: nobody <nobody@nobody.org>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article@ Message-ID: <00ddf8b805873e3af87ef8158d681f42@news.teranews.com>   Bill Todd wrote:M > Sun clearly still does:  otherwise, under its current pressures it would be L > heading full-tilt toward AMD64 rather than pressing forward on 3 differentG > SPARC fronts (two internally for the future, plus one using Fujitsu's 9 > current - and eminently respectable - SPARC64 product).   M Hasn't sunb for all practical purposes abandonned in-house development of new M cores for Sparc, with only tweaks of exsiting generations still planned, with G reliance on Fujitsu to provide the development of the new generations ?   I > Let's not forget AMD, either.  So far, there's no significant area that - > Opteron doesn't address better than Itanic    L My view os Opteron and intels version of 64 bit 8086 is that they still lackL some of the enterprise features that allow not only for large scale systems,: but also specific functiosn (such as lockstep for Tandem).  N Intel has a vested interest not to include those features in its 8086 in orderJ to save face with IA64 for at least the next 3 years. But AMD has a vested@ interest to include those features ASAP to cause Intel problems.  L > While the x86 ISA carries a quarter-century's worth of historical baggage,C > I'll suggest that it still manages to move it along right smartly   M In fairness, Intel recently admitted that it will slow down the "higher clock H speeds" on its 8086s because it had reached some payback limits and willJ instead start to concentrate on higher throughput per cycle (either better* design, more cache and/or multiple cores).  N Nevertheless, the 8086's architecture has allowed it to reach the 3ghz (if notN higher this week, I don't check this often) clock speed while the more complex. architectures are still at about half of that.   ------------------------------  $ Date: Thu, 1 Jul 2004 16:03:43 -0400* From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article2 Message-ID: <J8SdnR2tkcl18HndRVn-uA@metrocast.net>  5 "Bill Todd" <billtodd@metrocast.net> wrote in message , news:j6WdnTLZXa_B8XndRVn-hw@metrocast.net...   ...   J > Still, since the current software emulation is being touted as providingI > such a dramatic performance improvement over the hardware x86 emulation K > while only being about equivalent to a 1.5 GHz Xeon when running on a 1.5 J > GHz Madison, (i.e., only about half the performance of a current Itanic, atC > least to a first approximation), suggesting that the hardware x86 	 emulation F > averaged better than 1/3 the native performance of the Itanic it was running I > on (as the raw numbers above do) seems a bit inconsistent (and at least J > somewhat inconsistent with 300 - 450 MHz PPro equivalence on McKinley asH > well).  So unless the Itanic folks are deliberately (and consistently)C > understating emulated performance (an attitude toward performance K > projections that is rather rare in Itanic's history, one might note), the K > figures that you've provided are (for reasons I cannot guess at) not very J > representative of average behavior (or I'm still muddled about something > here).  J This thought just crossed my mind:  surely, the numbers you were providingF represented running 32-bit operating systems, rather than just runningF 32-bit Red Hat or HP-UX applications under a native Itanic OS - right?   - bill   ------------------------------  $ Date: Thu, 1 Jul 2004 15:57:06 -0400* From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article2 Message-ID: <j6WdnTLZXa_B8XndRVn-hw@metrocast.net>  3 "Rick Jones" <foo@bar.baz.invalid> wrote in message , news:mIZEc.5203$zi3.1295@news.cpqcorp.net...+ > Bill Todd <billtodd@metrocast.net> wrote: H > > Let's see: the Itanic hardware-emulation box seems to achieve around; > > 10% - 15% of native Itanic performance running x86 code  > B > Always a good idea to be explicit about what that code is doing.  1 At least when one has access to such information.    > @ > For example, some rather moldy data on DNS server performance: >  > <excerpt>  > $ >     DNS Server Performance SummaryC >      netperf DNS_RR test requesting across 1000 out of cup.hp.com 2 >                      "A" Transactions Per Second& >   hp server rx2600, 2x 1GHz Itanium2% >    Red Hat Advanced Workstation 2.1  >      HP-UX 11.22 >  > 2 >                              Native     EmulatedD >        Flavor                 IPF      x86/PA-RISC     % of native5 >                           +===========+===========+ > >      rh bind 8.3.4 O2     |   8,620   |   3,206   |       37> >      rh bind 9.2.2 O2     |   6,967   |   1,710   |       25> >      rh bind 9.3.0s O2    |   3,695   |   1,637   |       44> >      rh bind 9.3.0s O2 st |   4,722   |   2,279   |       48> >      rh bind 9.3.0s O2 mr |  33,012   |   9,265   |       285 >                           +===========+===========+ 5 >      ux bind 4.9.11 O2    |  14,225   |    n/a    | > >      ux bind 8.3.4 O2     |   9,768   |   3,102   |       32> >      ux bind 9.3.0s O2 st |   4,880   |   1,489   |       31> >      ux bind 9.3.0s O2 mr |  16,797   |   1,301   |       085 >                           +===========+===========+  > D > The magic decode for the "Flavor" column is rh == Red Had AdvancedE > Workstation 2.1, bind == the named from the specified distribution, @ > 8.3.4 and 4.9.11 are full releases from the ISC, 9.3.0s is the> > December 17th "snapshot" of the 9.3.0 development version of@ > BIND. "O2" is the compiler optimization level - either -O2 forE > gcc/linux or +O2 for HP. A "st" means that the bits were configured H > and compiled single-threaded rather than multi-threaded. An "mr" means> > that the named.conf file included a "minimum-responses true"E > directive, which is a relatively new feature of the BIND named that G > minimized the quantity of possibly extraneous information placed into  > the DNS reply. >  > </excerpt>  I Interesting.  My own comment was predicated on HP's observation in one of C its white papers associated with McKinley's nominal launch that x86 G emulation ran at approximately the speed of a 300 MHz Pentium Pro (plus L later comments that under some circumstances it might be more like a 450 MHzG PPro), plus some muddle-headedness in roughly equating Itanic's current H performance with its 3 GHz x86 siblings' without taking note of the factG that the current Itanic is clocked 50% faster than McKinley was and has L double the on-chip cache (of course Pentium technology has advanced somewhatK since the PPro days as well, but improvements in its ILP may well have been 0 offset by its more recent headlong rush to MHz).  H Still, since the current software emulation is being touted as providingG such a dramatic performance improvement over the hardware x86 emulation I while only being about equivalent to a 1.5 GHz Xeon when running on a 1.5 K GHz Madison, (i.e., only about half the performance of a current Itanic, at K least to a first approximation), suggesting that the hardware x86 emulation L averaged better than 1/3 the native performance of the Itanic it was runningG on (as the raw numbers above do) seems a bit inconsistent (and at least H somewhat inconsistent with 300 - 450 MHz PPro equivalence on McKinley asF well).  So unless the Itanic folks are deliberately (and consistently)A understating emulated performance (an attitude toward performance I projections that is rather rare in Itanic's history, one might note), the I figures that you've provided are (for reasons I cannot guess at) not very H representative of average behavior (or I'm still muddled about something here).   - bill   ------------------------------  # Date: Thu, 01 Jul 2004 21:23:13 GMT & From: Rick Jones <foo@bar.baz.invalid>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article2 Message-ID: <5h%Ec.5217$%m3.2724@news.cpqcorp.net>  ) Bill Todd <billtodd@metrocast.net> wrote: 5 > "Rick Jones" <foo@bar.baz.invalid> wrote in message A >> For example, some rather moldy data on DNS server performance:   D > Interesting.  My own comment was predicated on HP's observation inC > one of its white papers associated with McKinley's nominal launch @ > that x86 emulation ran at approximately the speed of a 300 MHzC > Pentium Pro (plus later comments that under some circumstances it D > might be more like a 450 MHz PPro), plus some muddle-headedness inB > roughly equating Itanic's current performance with its 3 GHz x86F > siblings' without taking note of the fact that the current Itanic isA > clocked 50% faster than McKinley was and has double the on-chip E > cache (of course Pentium technology has advanced somewhat since the C > PPro days as well, but improvements in its ILP may well have been 2 > offset by its more recent headlong rush to MHz).   Clearly, YMMV.  @ > Still, since the current software emulation is being touted asE > providing such a dramatic performance improvement over the hardwareiC > x86 emulation while only being about equivalent to a 1.5 GHz Xeong? > when running on a 1.5 GHz Madison, (i.e., only about half thesF > performance of a current Itanic, at least to a first approximation),E > suggesting that the hardware x86 emulation averaged better than 1/3CD > the native performance of the Itanic it was running on (as the rawC > numbers above do) seems a bit inconsistent (and at least somewhat A > inconsistent with 300 - 450 MHz PPro equivalence on McKinley as : > well).  So unless the Itanic folks are deliberately (andE > consistently) understating emulated performance (an attitude towardeF > performance projections that is rather rare in Itanic's history, oneB > might note), the figures that you've provided are (for reasons IF > cannot guess at) not very representative of average behavior (or I'm& > still muddled about something here).  C Whether the performance of a caching-only DNS server is "average" ItE do not know :) I do though look forward to trying the newer emulation  just for personal curiousity.e   -- lG oxymoron n, Hummer H2 with California Save Our Coasts and Oceans platesnF these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...'   ------------------------------  # Date: Thu, 01 Jul 2004 21:25:16 GMTr& From: Rick Jones <foo@bar.baz.invalid>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article2 Message-ID: <0j%Ec.5218$%m3.5109@news.cpqcorp.net>  ) Bill Todd <billtodd@metrocast.net> wrote: A > This thought just crossed my mind: surely, the numbers you were E > providing represented running 32-bit operating systems, rather than/B > just running 32-bit Red Hat or HP-UX applications under a native > Itanic OS - right?  F Native OSes.  I do not believe that 32-bit OSes have been supported onE Itanium since Merced (but could be wrong). And there has never been aE0 32-bit HP-UX _OS_ supported on Itanium hardware.  
 rick jones -- tD The glass is neither half-empty nor half-full. The glass has a leak.) The real question is "Can it be patched?">F these opinions are mine, all mine; HP might not want them anyway... :)A feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...    ------------------------------  $ Date: Thu, 1 Jul 2004 16:51:59 -0400# From: "John Smith" <a@nonymous.com>CF Subject: Re: Intel Itanium's very survival in doubt - inquirer article, Message-ID: <_LSdnQCYdM3y5HndRVn-hg@igs.net>   Paul Repacholi wrote:o/ > young_r@encompasserve.org (Rob Young) writes:s >s; >> So how soon before we read the above OEMs are abandoningt= >> Itanium?  Sure... and we will hear about that soon, right?  >oF > Well, I don't know if you will, but I've read those reports already. >e$ > Seen a M$ 64 bit roadmap recently?  2 Last one I saw was for 64-bit Windows on Alpha ;-)   ------------------------------  # Date: Thu, 01 Jul 2004 19:43:46 GMT   From: nobody <nobody@nobody.org>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article@ Message-ID: <38f3fbc80f2d555135ce4af64b8a96c5@news.teranews.com>   David Svensson wrote:9? > When I watched Intel presentations in 1997/1998 there were noCG > sightings that Intel wanted to discontinue x86. IA64 was at that time H > not planned to be a desktop CPU. There may have been hopes before that3 > time that IA64 would dominate the desktop though.i  I Yes, the plan was that IA64 would eventually replace the 8086 as industryrN standard. And it is that sales pitch which made Capellas piss in his pants andP start his long term journey to kill Alpha as soon as he took over from Pfeiffer.  F > About 8086 inside, "spent so much effort" is not correct. They couldG > have spent a whole lot more time/money on doing it better, apparentlyp, > they didn't want to or were short of time.  L From what I was told, they took whatever 8086 core was available at the timeJ and put into the IA64 chip real-estate. Problem is that it too so long forG IA64 to come to market that in the meantime , the real 8086 had sped upe@ considerably and what was inside the IA64 was old and very slow.  M And It was also because Merced had 2 chips inside, requiring a lot more space I that intel had serious yield problems since the bigger the chip, the moree7 chances of a defect that renders the chip unmarketable.n  A > I think you are confusing the IA64 architecture and the currentTE > Itanium implementation. Yes, there have been problems, but the heat ? > generation and being "uncompetitive" are not tied to the IA64  > architecture.t  L Then why is it that Intel has no problems with the 8086 which isn't that farM from IA64 in terms of performance and Intel has tons of problems with IA64 ?    F > it performs. There is no major problem there. The problem is that itB > is a new archicture and it is in todays environment very hard to > introduce a new archicture.   L Had IA64 not been delayed by years, and not first come out as a real dog, itC may have succeeded, intel certaintly had the clout of push that new 5 architecture to everyone, had it not been such a dog.   N And IA64 is no longer such as "new" architecture. It has been around for yearsK now. The problem is that even with all of Intel's marketing might, and HP's M push, IA64 has yet to take serious roots. Even HP-UX customers are continuing   to buy PA-RISC based superdomes.  K IA64 just doesn't bring the performance advantage that is worth the upgradeo headaches and costs.    * > All the other current architecture would- > have exactly the same problems of adoption.a  L Which is why AMD's decision to go with a 64 bit 8086 was a stroke of genius.  K But back in 1999, had Compaq really worked to get Alpha into mainstream, it-M could have succeeded because back then, Compaq still had a lot of clout. (andu/ remember that NT was still available on Alpha).-   ------------------------------  $ Date: Fri, 2 Jul 2004 00:11:54 +0200  From: "Dr. Dweeb" <dr@dweeb.com>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article- Message-ID: <cc226v$1sap$1@news.cybercity.dk>8   David Svensson wrote:s< > JF Mezei <"jfmezei"@spamnot@teksavvy.com> wrote in message> > news:<ab9909d6c39f96583acb3ea53bf77f9a@news.teranews.com>... >> David Svensson wrote: --- chop  A >> When they realised that IA64 was an uncompetitive architecture D >> (cost/time to develop, heat generation, compiler complexity etc),E >> Intel did admit that IA64 would not become industry standard (aka:wG >> would not replace the 8086). To anyone without any financial ties tohG >> Intel, that was a clear message that IA64 had little future and gave G >> much more credibility to all the statements pre June 25 from Digitaly* >> Alpha engineers on how flawed IA64 was. > A > I think you are confusing the IA64 architecture and the currenttE > Itanium implementation. Yes, there have been problems, but the heatA? > generation and being "uncompetitive" are not tied to the IA64s > architecture.8 >S  I There are technical "problems" associated with the nature of EPIC.  These G were spelled out very clearly, unequivocally and irrefutably and in the H Digital IA64 v. Alpha paper.  These issues have nothing to do with "heatL generation" or intrinsic "competitiveness" of the IA64 implementation. SadlyB my copy went south with a disk crash, so I cannot quote it to you.  E > That the Alpha team people disliked IA64 was pretty understandable,uF > they had a different view on how things should be done and they were > competitors. >n --- chop   ------------------------------  % Date: Thu, 01 Jul 2004 16:16:57 -06000" From: GreyCloud <mist@cumulus.com>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article0 Message-ID: <-qednePXkLmbEHndRVn-ig@bresnan.com>   Paul Repacholi wrote:X  / > young_r@encompasserve.org (Rob Young) writes:r >  > ; >>	So how soon before we read the above OEMs are abandoningh= >>	Itanium?  Sure... and we will hear about that soon, right?l >  > F > Well, I don't know if you will, but I've read those reports already. > $ > Seen a M$ 64 bit roadmap recently? >    No I haven't.  What's on it?   --  ! ---------------------------------d4 They made M$ windwoes to keep idiots away from UNIX.   ------------------------------  $ Date: Thu, 1 Jul 2004 23:34:09 -0400* From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article2 Message-ID: <asCdnftefL7mSnndRVn-hw@metrocast.net>  3 "Rick Jones" <foo@bar.baz.invalid> wrote in messaget, news:0j%Ec.5218$%m3.5109@news.cpqcorp.net...+ > Bill Todd <billtodd@metrocast.net> wrote: C > > This thought just crossed my mind: surely, the numbers you wereyG > > providing represented running 32-bit operating systems, rather than0D > > just running 32-bit Red Hat or HP-UX applications under a native > > Itanic OS - right? > H > Native OSes.  I do not believe that 32-bit OSes have been supported onG > Itanium since Merced (but could be wrong). And there has never been an2 > 32-bit HP-UX _OS_ supported on Itanium hardware.  J Then if the applications spent any significant time in the OS code (ratherE than running mostly without OS intervention after being started), thenK performance values you obtained were not for 32-bit x86 emulation but for acG mixture of 32-bit x86 emulation and native OS code execution - which ofs3 course would be higher than for pure x86 emulation.-   - bill   ------------------------------  $ Date: Thu, 1 Jul 2004 23:41:11 -0400* From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article2 Message-ID: <lOednXqVj8m8RHndRVn_iw@metrocast.net>  + "Dr. Dweeb" <dr@dweeb.com> wrote in messagen' news:cc226v$1sap$1@news.cybercity.dk...    ...c  K > There are technical "problems" associated with the nature of EPIC.  TheseeI > were spelled out very clearly, unequivocally and irrefutably and in theuJ > Digital IA64 v. Alpha paper.  These issues have nothing to do with "heatH > generation" or intrinsic "competitiveness" of the IA64 implementation.  K True, but those are nonetheless legitimate issues as well, even though theyaE were not clearly foreseeable at the time the Alpha paper was written..    SadlyD > my copy went south with a disk crash, so I cannot quote it to you.  K Google is your friend:  search for alpha_ia64.pdf, and about the 4th hit ise# a copy still available at Raytheon.    - bill   ------------------------------  $ Date: Fri, 2 Jul 2004 00:46:17 -0400* From: "Bill Todd" <billtodd@metrocast.net>F Subject: Re: Intel Itanium's very survival in doubt - inquirer article2 Message-ID: <q8KdnZasgLb-dXndRVn-vA@metrocast.net>  - "nobody" <nobody@nobody.org> wrote in messagee: news:00ddf8b805873e3af87ef8158d681f42@news.teranews.com... > Bill Todd wrote:L > > Sun clearly still does:  otherwise, under its current pressures it would beD > > heading full-tilt toward AMD64 rather than pressing forward on 3	 differentaI > > SPARC fronts (two internally for the future, plus one using Fujitsu'sc; > > current - and eminently respectable - SPARC64 product).r > K > Hasn't sunb for all practical purposes abandonned in-house development of  newrJ > cores for Sparc, with only tweaks of exsiting generations still planned, withI > reliance on Fujitsu to provide the development of the new generations ?l  K No.  Sun is still pursuing two different internal SPARC efforts in additionh5 to its collaboration with Fujitsu:  'Rock' (I think a = high-performance-per-core product) and 'Niagara' (its 8-core,fF 4-way-SMT-per-core project).  Both are scheduled for 2006 IIRC (though& possibly for large values of 2006...).   >)K > > Let's not forget AMD, either.  So far, there's no significant area that . > > Opteron doesn't address better than Itanic >tI > My view os Opteron and intels version of 64 bit 8086 is that they stilld lackE > some of the enterprise features that allow not only for large scale  systems,< > but also specific functiosn (such as lockstep for Tandem).  L Opteron certainly has reasonably comprehensive on-chip RAS facilities.  IA32I is currently available in systems up to 32 processors from Unisys (and ifTG not from IBM yet it soon will be), and Intel's AMD64 products will slipnH right into those boxes (though Opteron is currently available only up toC 4-processor systems and while 8-processor boxes are scheduled to be F available before year's end larger configurations may not be by then).  E The only platform that cares about lock-step is Tandem.  AMD long agodL supported it in their 29000 series and found so little demand for it that itJ never reappeared elsewhere.  And Tandem shows no more signs of taking over the world than it ever did.e  L I suspect that there was a good reason why DEC never bothered with this kindH of thing after VAXft, and Compaq's only interest was likely because theyJ owned NSK and needed a new hardware home for it.  Please be specific about0 any other features that you believe are lacking.   >SJ > Intel has a vested interest not to include those features in its 8086 in order 7 > to save face with IA64 for at least the next 3 years.i  L As I noted earlier, Intel's x86 products have at least *some* RAS features -I I'm not not conversant with the details.  Again, please be specific about// any of importance that you believe are lacking.     But AMD has a vested B > interest to include those features ASAP to cause Intel problems.   That's why it already did.   >=E > > While the x86 ISA carries a quarter-century's worth of historicals baggage,E > > I'll suggest that it still manages to move it along right smartlyr >iI > In fairness, Intel recently admitted that it will slow down the "higher= clock=J > speeds" on its 8086s because it had reached some payback limits and willL > instead start to concentrate on higher throughput per cycle (either better, > design, more cache and/or multiple cores). >lL > Nevertheless, the 8086's architecture has allowed it to reach the 3ghz (if notRH > higher this week, I don't check this often) clock speed while the more complex70 > architectures are still at about half of that.  C I was not referring to clock speeds above, but to actual (measured)eH performance.  Both Intel's and AMD's x86 (and AMD64) equal or exceed theL best performance that the rest of the industry can offer (save for Itanic onH regular FP-style code), often by rather large margins.  Intel so far hasF done it largely by brute-force clock rates and long pipelines, but AMDG equals that performance at less than 2/3 the clock rate (and using less A cache, though its on-chip memory controller must be considered ann advantage).    - bill   ------------------------------   Date: 1 Jul 2004 23:58:37 -0500c+ From: young_r@encompasserve.org (Rob Young)rF Subject: Re: Intel Itanium's very survival in doubt - inquirer article3 Message-ID: <9V5G8btuN7fU@eisner.encompasserve.org>c  _ In article <1cGdnc3uNb7upHnd4p2dnA@metrocast.net>, "Bill Todd" <billtodd@metrocast.net> writes:r > : > "Rob Young" <young_r@encompasserve.org> wrote in message   >>B >> But that would be very difficult given that Intel is projectingB >> 50-100% greater performance Itanium vs. Xeon.  Xeon64 certainly7 >> won't be a candidate to run the much faster Itanium.r > L > You're confused as usual, Rob.  If you read the article which you yourselfH > cited, it makes it clear that Itanic is not anticipated to have betterL > *per-core* performance than Xeon (even 3 years from now, and given Intel'sL > rather abysmal history of predicting relative Itanic performance one mightM > take that with a large grain of salt) - it will just have more cores on the D > chip, hence higher *aggregate* chip performance for those who have; > readily-partitionable loads suitable for multi-threading.t >   @ 	And so my mistake was to not to highlight per-chip?  After all,= 	the article states what you point it.  It wasn't as if I wasn; 	trying to do some misdirection.  And by the way, how couldlD 	Itanium NOT have better SpecFp and better tpmC per-core performance 	than Xeon?t  M > Many servers do run such loads.  But for single-thread loads, it's entirely I > possible that Xeon could emulate Itanic with acceptable performance (at N > least if Xeon's 64-bit performance is somewhere nearly as good as Opteron's,- > something which has yet to be ascertained).c    < 	Okay.  But the target market is HPC and commercial.  Codes B 	suitable for SMT or CMP to gain an advantage (for the most part).> 	And for stubbornly single threaded - the jury is still out on$ 	that.  "There is ILP on the table."   	Here is Paul's read:   j http://www.realworldtech.com/forums/index.cfm?action=detail&PostNum=2468&Thread=15&entryID=34292&roomID=11  4 But the improvements that will be made in pipelining9 efficiency, cache hierarchy, and system level infrastruc-n7 ture can improve IPF SPECint performance significantly. 7 The ILP is there to be had in SPECint2k and current IPF46 compilers are finding much more of it than can be used by current hardware.   ---m  6 	Catch that "much more" ILP there that future hardware 	will take advantage of?  ; 	And he speculates he may do a RWT article on the ILP anglea< 	(see follow-ups).  Now what is interesting is Linus hops in= 	and attempts to refute Paul's "much more" ILP pronouncement:s  j http://www.realworldtech.com/forums/index.cfm?action=detail&PostNum=2468&Thread=30&entryID=34317&roomID=11   	Linus Torvalds writes:A   >r6 >I claim that the "ILP=1" answer is the right one, and8 >your inflated IPF-ILP is nothing but _stupid_. It's not: >user-meaningful ILP, it's just "ILP if we add in a lot of" >crap that ends up being useless". > 4 >And I seriously suspect that when you say "there is; >enough ILP in SpecInt to feed IPF", then it's only becausem/ >of your totally incorrect way of counting ILP.d   	Paul DeMone writes:  7 It is not *my* way. Stop incorrectly personalizing this 2 to me this out of your own abundant and apparently9 willful ignorance. It is the way the architects at HP and 4 Intel who design next generation IPF processor cores5 look at the problem of identifying and removing basicc4 bottlenecks and impediments in the current design to4 improve architectural performance in future designs.   ---   9 	Of course Linus doesn't have much of a comeback in these); 	technical back and forths with Paul over there.  Many havee; 	found they are up against the best and end up on the shortt' 	end of the debate ;-).  But I digress.e  C 	Itanium gets much stronger in SpecInt2000 - probably in Montecito.mC 	I'd hazard to guess Paul isn't referring to a follow-on generationi( 	beyond Monty and surely not Madison 9M.  @ 	With this in mind, it appears to me that per-core Itanium couldC 	very well pull equivalent to Xeon in performance and as mentioned o/ 	before "twice as many Itanium cores as Xeons":t  8 http://www.midrangeserver.com/mid/mid032404-story04.html  / Garrison said that the Itanium core is half themK size of the Xeon core, which means that Intel will be able to cram twice astE many Itanium cores on a single chip for a given chip making process. g   ---n  9 	Would hit the high-water mark of 100% better performancevA 	Itanium vs. Xeon (after all the article says 50-100% better.  Ifm@ 	100% better and 4 Itanium cores and 2 Xeon cores it would implyC 	that the Itanium core = Xeon core in performance - and surely theyt. 	aren't comparing SpecFp for this discussion).  > 	Circling back to the silly point of Xeon emulating Itanium...= 	Speculating on Itanium being emulated by Xeon is a worthlesssA 	exercise.  The architectural advantages are clearly in Itanium's B 	favor versus Xeon.  As fast or faster (especially SpecFp, TPC and> 	I'll wager it exceeds Xeon come Montecito in SpecInt with ILP: 	gains), smaller and pricing parity (2007 if what we read  	comes to pass).  ? 	That Itanic moniker is going to be real funny a year from now.r   > M >> Intel says flat out that the goal for Itanium is for the family of serversnE >> based on it to use as many of the same components that there is noo > disparity inM >> pricing. By 2007, Intel wants Itanium machines to have pricing parity, andn > toK >> have twice the cores on a die, twice the performance, and twice the bangb > fori >> the buck. > K > Of course, that projection doesn't take into account competitive pressureh > from Opteron.  s   	That will show up when?    ) http://www.theinquirer.net/?article=16955a  P The roadmaps we've seen show that in August [IBM] will release three flavours ofL the e326 - these support Opteron 250s, 248s and 246s, with support for up toO 12GB of ECC DDR memory, and Ultra 320SCSI drives. But no four way [IBM] Opteron D system appears to be on the cards, at least for the next six months.   [snip]  J What is interesting is that [IBM] still appears to be wedded to the Intel N Itanium platform. In October it is likely to launch four way Intel Itanium 2s M dubbed the x455 machines, in 1.5GHz/4MB, 1.6GHz/6MB and 1.7GHz/9MB flavours.  D The first of these is uniprocessor, the second are two ways systems.    G 	IBM - missing that tremendous 4-way Opteron market that is taking off qA 	all around us - instead ships a 4-way Itanium box.  Shocker.  Ora@ 	doesn't want to risk Xeon discount pricing?  Ouch!  Surely more? 	money can be made selling 4-way Xeons versus 4-way Opterons.   . 	Wouldn't want to kill that Golden Xeon Goose.   > @ >> Hey... if nothing else it will put the remaining RISC CPUs inD >> a brutal position (Power + SPARC and maybe I'm being presumptuous@ >> anticipating SPARC being "not canceled" in 3 years) with very? >> high performance and much cheaper cost (versus Power/SPARC).  > J > Selling futures as usual, Rob.  IIRC Itanic was supposed to have put itsL > RISC competition in a brutal position some years ago, and when that didn'tL > happen it was predicted certainly to have done so by now.  Plus ca change, > plus c'est la meme chose.  >   F 	Yep.  And some day these posts will be a chuckle.  For one of us ;-).   				Rob    ------------------------------  % Date: Thu, 01 Jul 2004 12:07:31 -0700  From: Z <z@no.spam> 3 Subject: Re: Memory test diags for Alphastation 255 0 Message-ID: <10e8o6pcoch6p0a@corp.supernews.com>   Nic Clews wrote:2 >>What's the best way to test the system's memory?   > Power on. J > If you were seeing memory errors, you'd likely see MACHINECHECK crashes.F > VMs does a good job of maintaining data integrity, and in particularE > it's memory structures, and distinguishing the difference between at0 > software corruption and a hardware corruption.  < Is it possible MACHINECHECK is being signaled and written to? the console, but by the time I get to look at the display, onlyt2 the Kernel Stack Not Valid error is on the screen?   ------------------------------  % Date: Thu, 01 Jul 2004 13:39:51 -0500d% From: Neil Cherry <njc@wolfgang.uucp> 4 Subject: Re: More LAT questions on LAT$SYSTARTUP.COM. Message-ID: <slrnce8mir.na4.njc@wolfgang.uucp>  ; On Tue, 29 Jun 2004 21:48:03 -0500, David J Dachtera wrote:h > Neil Cherry wrote:	 >> [snip]eR >> OPENVMS-ALPHA-USER DEC             0  0     100    0.0  30-NOV-2004 30-NOV-2004R >> OPENVMS-HOBBYIST   DEC             0  0     100    0.0  30-NOV-2004 30-NOV-2004	 >> [snip]gR >> VAX-VMS            DEC             0  0     A      0.0  30-NOV-2004 30-NOV-2004 > ! > O.K. There's your VMS licenses.o > J > That said, I re-read the earlier post about dynamic rating and I believe1 > the comment was made about interactive logins. r  1 > $ SET LOGINS/INTERACTIVE	! No value expression!a   MV3100$ SET LOGINS/INTERACTIVEA %SET-I-INTSET, login interactive limit = 100, current interactivet	 value = 2>  * > $ WRITE SYS$OUTPUT F$GETSYI( "IJOBLIM" )    > $ MCR SYSMAN PARA SHOW IJOBLIM  / MV3100$  WRITE SYS$OUTPUT F$GETSYI( "IJOBLIM" )4 100e$ MV3100$ MCR SYSMAN PARA SHOW IJOBLIM@ %SYSMAN-I-USEACTNOD, a USE ACTIVE has been defaulted on node VAX% Node VAX:   Parameters in use: ACTIVEpP Parameter Name            Current    Default    Minimum    Maximum Unit  DynamicP --------------            -------    -------    -------    ------- ----  -------P IJOBLIM                       100         64          1       8192 Jobs        D  F Above are the various outputs, I included all of them just in case.  IE tried the manual setting of the LAT configs that Paul (?)  suggested. F I still can't bring it up even after changing it to static.  I've beenC able to get a Xyplex server to do some LAT adverts just I could see E soemthign on the net. But I'd really feel better getting the LAT backm up and running.   F BTW, thanks everyone for the help so far. I'm sure that this will turn out to be something weird.   -- eD Linux Home Automation         Neil Cherry        ncherry@comcast.net; http://home.comcast.net/~ncherry/               (Text only) = http://linuxha.sourceforge.net/                 (SourceForge)t8 http://hcs.sourceforge.net/                     (HCS II)   ------------------------------  $ Date: Thu, 1 Jul 2004 15:34:28 -0400* From: "Bill Todd" <billtodd@metrocast.net>" Subject: Re: OpenVMS .... no news?2 Message-ID: <r4mdnQYxDsqQ-nndRVn-sw@metrocast.net>  . "Nigel Barker" <nigel@hp.com> wrote in message2 news:00e8e01t97pqkjns6ok71rmp5em5hbs900@4ax.com...I > On Thu, 1 Jul 2004 00:22:34 -0400, "Bill Todd" <billtodd@metrocast.net>c wrote: >nK > >Gee - I can so clearly remember the time when it was stated that the VMSfL > >head count would be doubled precisely to avoid any negative impact of theK > >port on on-going development (such as it was - back in 2001 there was atvJ > >least a continuing pretense that reasonably robust development activity wasr > >still on the agenda). >l > You are wrong on this.   Actually, technically not.  8  Nobody ever promised to double the headcount of OpenVMS > Engineering.  G It is indeed possible that no one *at Compaq* promised this, precisely.vC Fred Kleinsorge, however, did state the following on the day of thev
 Alphacide:  K "...we also were told our headcount would increase by a number that we wille9 be hard pressed to find engineers to fill quickly enough"o  L ( http://www.google.com/groups?q=+%22actually,+the+engineers%22+group:comp.oL s.vms&hl=en&lr=&ie=UTF-8&safe=off&scoring=r&as_drrb=b&as_mind=25&as_minm=6&aL s_miny=2001&as_maxd=26&as_maxm=6&as_maxy=2001&selm=UiKZ6.100%24rc5.3751%40ne ws.cpqcorp.net&rnum=1 ).  K My recollection was likely of a subsequent comment in a different thread byt a non-Compaq source:  C "While it is a really great thing to have the head count of the VMS  engineering group doubled..."rL ( http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&selm=3B391188. 6857D040%40infopuls.com ).   ...n  J > >My, what an interesting document this continues to be.  Double-speak at itsgF > >best.  For example, it's so encouraging to see that the VMS port to ItanicF > >is 'exceeding expectations', despite a projected production-quality release G > >date that has now slipped to Q4 (which itself is still not the 'full ; > >functionality' release:  that's 8.3, some time in 2005).2 > H > The production quality release has always been targeted for the second half ofi > 2004.   E I think not.  According to the Compaq announcement at the time of the@I Alphacide reproduced here, "The first Itanium-based system for Tru64 UNIXs  and OpenVMS is planned for 2003"  L http://www.google.com/groups?q=+engineering+group:comp.os.vms&hl=en&lr=&ie=UL TF-8&safe=off&scoring=r&as_drrb=b&as_mind=25&as_minm=6&as_miny=2001&as_maxd=L 27&as_maxm=6&as_maxy=2001&selm=tjf31fal1esi97%40corp.supernews.com&rnum=2 ).K And while I remember later roadmaps with later dates, I do not remember one = suggesting that the release would appear later than mid-2004.f  F Funny how easily one forgets initial target dates when they're changed/ frequently but by sufficiently small amounts...    ...h  E > The kind of level of detail on enhancements to OpenVMS is as in the 	 paragraph1 > below.  I I'm afraid that minor enhancements to the C RTL are not the kind of thing K that I was talking about (however much they may have been needed to address E minor deficiencies therein).  You might have picked a more impressive=  example, if one actually exists.  I  I really urge you to actually read the notes accompanying the Powerpoint G > presentation rather than rely on me regurgitating the details in this9
 newsgroup.  G Well, some of the readers of this newsgroup just don't run systems that L support ppt, so if you want to reach people who might actually be influencedL in their purchasing decisions you might be wise to make the effort here.  IfL I have the time and inclination I may satisfy my own curiosity, but since itK will be a cold day in hell before I touch any HP hardware save possibly for  printers that won't mean much.   - bill   ------------------------------  # Date: Fri, 02 Jul 2004 03:39:35 GMT - From: JF Mezei <jfmezei.spamnot@teksavvy.com>i0 Subject: OT: Industrial Espionnage/data security@ Message-ID: <2529c61f5f2c4b0192287c408998acb3@news.teranews.com>  N Not long ago, someone was asking about the need to erase drives before handing a system to a 3rd party.  F Earlier this year, I mentioned a tidbit about someone hacking into AirN Canada's web site to obtain proprietary information. Turns out that former AirJ Canada employees had negotiated deals to retain access to the employee webK site so that they could use the flight reservation system to pick out whichaL flights they had a high chance of stand by or booking at very reduced rates.K Westjet hired a former Air Canada employee and allegedly wrote scripts that L performed continueous searches for load factors on AC's web site to find out+ how many pax AC was carrying on each route.i    L Here is a cut/paste from a AC related newssite, it should give you some ideaL to what extent corporations will go to to obtain competitor's information. (* and thus the need to protect information).  J 2)  WestJet Airlines  (WS/WJA)   ...on June 29th WestJet announced that itN will file its Statement of Defence to Air Canada's claim in a Toronto court onJ June 30, 2004.  WestJet will also seek leave of the court to counter-claimH against Air Canada, ZIP and their private investigators for the unlawfulN seizure of WestJet's confidential financial information.  Leave is required asJ Air Canada is currently under bankruptcy protection.   In the Statement ofM Defence, WestJet states the information on the Air Canada employee website isoM not confidential and in fact is available to the public through many sources, N including counting passengers and other public websites.  In addition, WestJetN states no information from the Air Canada website was ever used by WestJet forM any purpose, and the loss of revenue, profits and goodwill Air Canada allegessJ it has suffered arises not from any use of information on the website, butK from Air Canada's mismanagement of its business, its decision to persist inuL selling seats on flights for less than cost, its high-cost structure and theD poor treatment of its customers.  It goes on to say that the privateH investigators seized confidential financial information from Mark Hill'sF recycling material at his home in Oak Bay BC.  Air Canada sent privateN investigators to Hill's home in Oak Bay BC on two occasions this spring.  HillJ states they trespassed on his private property to unlawfully seize WestJetM documents that had been shredded and placed in a recycling container for pickiI up by municipal employees.  Air Canada then hired a Houston Texas firm toeM reconstitute the shredded documents, which include WestJet's confidential andnN sensitive business and financial information unrelated to Air Canada's claim. J These documents consist of financial statements, fleet planning documents,K capital budgets, variances of actual against budget performance, and profit M and loss statements.   WestJet will be seeking $5 million in punitive damagesr  and injunctive and other relief.   ------------------------------  * Date: Thu, 1 Jul 2004 18:55:00 +0000 (UTC)6 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOEGER)" Subject: Re: Secondary DNS problem0 Message-ID: <newscache$4ls60i$pjt$1@news.sil.at>   In article <1037270357C4D411A1C900A0C9D4BFCB0114593A@hqnts40div01.academy.kiev.ua>, "Oleksii Krykun" <krikun@academy.kiev.ua.no.spam> writes: L >I used my old VAX4000-200 as secondary DNS in our LAN about 7 years. NT 4.0 >DNS server was primary.  G I did it the other way. VMS was more reliable as primary, I could use awF (very good) text editor (EVE) and scripts (DCL) for zone updates and IG had umpteen NT systems as secondary (and file/print/application) servereG in remote locations (until the AD came out before BIND9 on VMS came)...   3 >Now I've replaced MS DNS on NT server with BIND 9.,    By what ? Upgrading to Win2003 ?  4 >On BIND named.conf there is allow-transfer for VAX.  ; Do you have security keys in use (wouldn't make sense ;-) ?   " >Event Log shows events like this: >oA >client 10.0.4.2#1166: transfer of 'BLA.BLA.BLA/IN': AXFR startedw  # and 10.0.4.2 is the IP of the VAX ?c   >But on VMS side I see:l >  >$ ucx sh host/nolocal5 >%SYSTEM-E-REJECT, connect to network object rejectede' >%UCX-W-NORECORD, Information not founda5 >-SYSTEM-F-REJECT, connect to network object rejected,  ? That means, you can't connect your DNS client to the DNS serveroF (which I assume is LOCALHOST as you wrote the VAX is a secondary DNS).G So, this only shows a nonworking secondary on the VAX (which you know).f  F If youever you specified the primary DNS as the first (or only) server> in the DNS client, then it is proof that the problem is on M$.  F If there is already a NSLOOKUP utility in UCX V3.2 (which I doubt) you can use this for more digging.   $ NSLOOKUP name server   and/or  
 $ NSLOOKUP Default Server:  localhost Address:  127.0.0.1.   >LS -D domain. >SET SERVER <primary>- >LS -D domain.  G Alternatively you can use the NSTEST freeware which was written exactlya( for this reason (not having a NSLOOKUP).   >UCX$BIND_STARTUP.LOG says:c > : >UCX BIND Server Error message -- Wed Jun 30 13:34:14 2004& >secondary zone "'BLA.BLA.BLA" expired< >UCX BIND Server Warning message -- Wed Jun 30 13:34:14 2004- >recvfrom: connect to network object rejecteda< >UCX BIND Server Warning message -- Wed Jun 30 13:34:17 2004= >zoneref: Masters for secondary zone 'BLA.BLA.BLA unreachablee: >UCX BIND Server Error message -- Wed Jun 30 13:34:24 2004& >secondary zone "'BLA.BLA.BLA" expired >oM >How to investigate this problem? I can't find any information about UCX BINDr	 >logging.j  H In UCX V3.2 there is no logging (AFAIK - that's more than a decade ago)., I'm surprised to see even a BIND in V3.2 ;-)  E But you already have a message (see above). The VAX is not allowed to)? connect to the primary DNS. Check there again (Event Viewer)....  > How about TELNET to port 53 and see if a connection is allowed to the primary.    >P.S.t >< >$ ucx show versionj >:A >  DEC TCP/IP Services for OpenVMS VAX Version V3.2 - ECO Level 7s- >  on a VAX 4000-200 running OpenVMS V5.5-2H4l >pL >Unfortunately I can not upgrade to newer version of TCP/IP on VMS because I- >have not enough physical memory on VAX (16M)n  6 Then buy one on the used market for a couple of bucks.D Or subscribe to a rescue list. A lot of people would be happy to notE scrap their old equipment and know that you are a good home for it...I   -- s Peter "EPLAN" LANGSTOEGERa% Network and OpenVMS system specialist  E-mail  peter@langstoeger.atF A-1030 VIENNA  AUSTRIA              I'm not a pessimist, I'm a realist   ------------------------------  # Date: Thu, 01 Jul 2004 19:22:28 GMT3  From: nobody <nobody@nobody.org>0 Subject: Re: slap in the face again... thanks HP@ Message-ID: <68d9ac8c51da13ab7a14422a9712a00f@news.teranews.com>   Paul Sture wrote:eH > I am not familiar with the latest versions, but as Bill Todd mentioned> > in this thread, Partition Magic can do image backups. And at > - > http://www.ultrabac.com/products/45pricing/o > G > there is a range of solutions from single workstation image backup top% > file by file server backups and DR.n  E Thanks for the tip. Have passed this on to my cycling friends who are @ (unfortunatly) relying on a windows laptop during their travels.   ------------------------------  $ Date: Thu, 1 Jul 2004 22:04:33 -0400# From: "John Smith" <a@nonymous.com> 0 Subject: Re: slap in the face again... thanks HP, Message-ID: <yOSdnfYS094vX3ndRVn-gg@igs.net>  
 nobody wrote:n > Paul Sture wrote:h? >> I am not familiar with the latest versions, but as Bill ToddtF >> mentioned in this thread, Partition Magic can do image backups. And >> ata >>. >> http://www.ultrabac.com/products/45pricing/ >>H >> there is a range of solutions from single workstation image backup to& >> file by file server backups and DR. >hG > Thanks for the tip. Have passed this on to my cycling friends who arenB > (unfortunatly) relying on a windows laptop during their travels.    C Also ... many brand name DVD writers (Plextor and others) come withb2 backup/DR software to create DR sets on CD or DVD.  I I recenly purchased a Maxtor external drive and a Plextor DVD burner. The L Maxtor drive came with a 'light' version of Dantz Retrospect which creates aL bootable system image that can be burned onto a CD. That coupled with eitherJ the backup set on hard disk or on DVD will restore a Windows system pretty fast.d  L You just have to make sure that most processes are shut down in order to get a 'clean' image.   ------------------------------  % Date: Thu, 01 Jul 2004 20:27:50 +0200i+ From: Wilm Boerhout <w3.boerhout@planet.nl>c: Subject: Re: When to use INIT/WINDOWS, SET VOLUME /WINDOWS5 Message-ID: <40e4577a$0$2736$ba620dc5@nova.planet.nl>u   Alan E. Feldman wrote:F > When is it appropriate to use the /WINDOWS qualifier for INIT or SETF > VOLUME? If this affects performance, why isn't it in the Performance
 > Manaual?  E  From the obscure but supposedly still valid "OpenVMS and Windows NT g6 Integration Manual", Section IV, Uninstall Procedures:  G "The $ INIT /[NO]WINDOWS and SET VOL /[NO]WINDOWS command are used for sD the occasion that the system manager defines sharable drives on his B OpenVMS system, but does not want those drives to be populated by  Windows system or user files.,  G The command $ INIT DKA100: /NOWINDOWS ensures that no file originating uE from a Windows system will ever be added to the file system on drive - DKA100:.  H The non-negating form (e.g.: SET VOLUME /WINDOWS) is rarely seen in the  field."    -- :
 Wilm Boerhouti Zwolle, The Netherlandsb   wilmOLD@PAINTboerhout.nl2    (remove OLD PAINT from this address before use)   ------------------------------  $ Date: Thu, 1 Jul 2004 15:39:52 -0400 From: norm.raphael@metso.com: Subject: Re: When to use INIT/WINDOWS, SET VOLUME /WINDOWSQ Message-ID: <OFD3328DCF.27C195D5-ON85256EC4.006B92DC-85256EC4.006C4334@metso.com>   E Nic Clews <sendspamhere@[127.0.0.1]> wrote on 07/01/2004 07:14:50 AM:I   > David J Dachtera wrote:d > >b > > "Alan E. Feldman" wrote: > > >uJ > > > When is it appropriate to use the /WINDOWS qualifier for INIT or SETJ > > > VOLUME? If this affects performance, why isn't it in the Performance > > > Manaual? > > 
 > > It isn't?p > >nJ > > Seriously - I'm sure there are references to other doc.'s in the GuideE > > to Performance Mgt. The books try to be "one size fits all" not am$ > > "cookbook" for high-performance. > >,F > > There's a few tuning tricks that aren't in *ANY* of the doc.'s! Ya gottas2 > > go digging for DECUS presentations on the web. >"> > http://h71000.www7.hp.com/doc/731FINAL/4506/4506pro_026.html >  > Section 9.2.3.   Quote >r 9.2.3.2 Window Size J If the file is extended repeatedly, the extensions may be scattered on theK disk. Each extension is called an extent---a pointer to each extent residesyE in the file header. For retrieval purposes, the pointers are gatheredh togetherJ in a structure called a window. The default window size is 7 pointers, but youvI can establish the window size to contain as many as 127 pointers. You canp alsoJ set the window size to --1, which makes a window that is just large enough to map the entire file. < End quote:  K Is the size value here intended to be "minus one == -1" and not "--1" whicheH looks like someone used a "dash" character and it was converted into theF equivalent "double-hyphen" in the retrieved text?  If so, it should be fixed., If not, can the size really be set to "--1?"   >dI > from askq.compaq.com: tick high performance systems, use "INIT /WINDOWS  > OPENVMS" as search > F > [OpenVMS] What is the /WINDOWS Qualifier on INIT, MOUNT, SET VOLUME? >nE > Dave is right, there's a wealth of information out there. Also somedI > t-shirt* wearing specialists for hire, of which Dave does fit into that- > category.h >1G > * I don't mean he turns up in a t-shirt, I mean he's been there, seenj@ > it, done it, and ready to let you benefit from his experience. > --A > Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Sciences@ > nclews at csc dot com    ------------------------------  % Date: Thu, 01 Jul 2004 21:22:06 -0500d2 From: David J Dachtera <djesys.nospam@comcast.net>: Subject: Re: When to use INIT/WINDOWS, SET VOLUME /WINDOWS+ Message-ID: <40E4C6CE.325DFF77@comcast.net>a   Wilm Boerhout wrote: >  > Alan E. Feldman wrote:H > > When is it appropriate to use the /WINDOWS qualifier for INIT or SETH > > VOLUME? If this affects performance, why isn't it in the Performance > > Manaual? > F >  From the obscure but supposedly still valid "OpenVMS and Windows NT8 > Integration Manual", Section IV, Uninstall Procedures: > H > "The $ INIT /[NO]WINDOWS and SET VOL /[NO]WINDOWS command are used forE > the occasion that the system manager defines sharable drives on histC > OpenVMS system, but does not want those drives to be populated by  > Windows system or user files.i > H > The command $ INIT DKA100: /NOWINDOWS ensures that no file originatingF > from a Windows system will ever be added to the file system on drive
 > DKA100:. > I > The non-negating form (e.g.: SET VOLUME /WINDOWS) is rarely seen in the 	 > field."a >  > -- > Wilm Boerhoutq > Zwolle, The Netherlandse >  > wilmOLD@PAINTboerhout.nl4 >    (remove OLD PAINT from this address before use)   ROFLMFAO!!!!   D.J.D.   ------------------------------   End of INFO-VAX 2004.362 ************************